예제 소스 코드
이번 블로그에 사용되는 코드는 아래 링크 통해 확인 할 수 있습니다.
https://github.com/syh8088/MSA_project/tree/main/paymentMsa
모놀리스 아키텍처 (Monolithic Architecture) VS MSA (Micro Service Architecture)
모놀리스 아키텍처 (Monolithic Architecture)
모놀리스 아키텍처 (Monolithic Architecture) 는 여러 모든 종류 서비스가 하나의 애플리케이션으로 구성되어 있는 아키텍처 입니다.
즉 예를들어 하나의 서버내에 결제 서비스, 정산 서비스 등 모든 서비스가 하나의 애플리케이션으로 구성되어 있다고 볼 수 있습니다.
이러한 특징으로는 만약 결제 서비스에서 코드 수정 통해 다시 배포하게 된다면 그외 서비스들까지도 다시 배포 하게 됩니다. 즉 해당 애플리케이션에 속하는
모든 서비스가 다시 배포 된다는 의미 입니다.
모놀리스 아키텍처 (Monolithic Architecture) 장점
이렇게 단순함 때문에 장점 또한 있는데요. 하나의 애플리케이션으로 구성 되어서 관리 포인트가 MSA (Micro Service Architecture) 비해 적다는 것 입니다.
특히 스타트업 경우 빠르게 개발하고 빠르게 서비스를 검증 해야 하는 과정이 필요해서 모놀리스 아키텍처 (Monolithic Architecture) 경우 큰 장점이 됩니다.
빠르게 개발 하고 소수의 개발자 인원과 기본적인 개발 지식으로 서비스 유지 관리가 가능 합니다.
MSA (Micro Service Architecture) 경우는 전문적인 Devops 개발자가 필요하고 서버 리소스에 있어서 비용이 많이 발생하지만 이와 반대로 모놀리스 아키텍처 (Monolithic Architecture) 경우
단조로운 구조 아키택처로 개발자의 역량이 비교적 낮은 경우 그리고 낮은 비용으로만으로 유지가 가능한다는 점 입니다.
모놀리스 아키텍처 (Monolithic Architecture) 단점
애플리케이션 Scale-Out 통해 서버 확장을 한다고 해도 DB 부하로 인한 문제로 DB 서버 확장시에도 고려해야 될 사항이 있습니다.
DB 서버 부하로 인해 DB 서버 확장 한다고 했을때 DB 경우는 데이터 일관성을 지켜야 하기 때문에 분산(Distribution)식 서버 확장은 큰 어려움이 있습니다. 분산(Distribution) 방식 서버 확장은 각 DB 서버에서 데이터를 분할하여 저장하는 방식 입니다.
데이터를 여러 샤드로 고르게 분배 하는것이 중요하고, 잘못해서 데이터 일관성에도 문제가 발생 할 수도 있습니다. 또한 여러 샤드에 걸친 데이터를 조인하는 것이 어렵습니다.
물론 장점은 있지만 상황에 따라 적절하게 선택 하면 좋은 선택지가 됩니다.
또하 나 방법은 Replication 방식의 분리 방법 입니다. 두 개의 이상의 DB 를 Mater, Slave 로 나눠서 동일한 데이터를 저장하는 방식 입니다.
Master 역활을 하고 있는 DB 서버는 쓰기 작업만 처리, Slave 는 Read 용도로만 사용해서 부하를 분산 하도록 합니다.
다시 본론으로 들어가서 모놀리스 아키텍처 단점을 더 이야기 하자면 서비스가 확대되고 개발자 인원이 증가되면 이에 따른 유지 보수 측면에서 단점이 될 수 있습니다. 하나의 애플리케이션에서 관리 하다보니 특정 서비스에서 코드 수정시 다른 서비스에서도 영향이 미칠수가 있습니다.
규모가 커지면 커질수록 복합성이 증가되어 수정에 대한 부담이 증가 됩니다.
그리고 점점 서비스가 무거워지면 배포까지 시간이 많이 지체됩니다.
단일 장애 지점(SPOF) 있어서도 문제가 발생됩니다. 특정 서비스에서 장애가 발생시 동일한 서버내에 다른 서비스까지 장애가 미치면서 전체적인 서비스 불능으로 빠질수 있습니다.
모놀리스 문제로 인한 SOA(Service Oriented Architecture) 등장
지금까지 모놀리스 단점을 확인 해보았습니다. 그래서 이러한 문제를 해결하기 위해 나온 아키택처가 SOA(Service Oriented Architecture) 입니다.
SOA(Service Oriented Architecture) 는 서비스 단위로 개발하고 서비스 간 규격화된 프로토콜 (인터페이스) 를 사용하여 통신 하는 방식 입니다.
일반적으로 동일한 기술 스택을 이용해서 서비스 단위로 개발 한다는 것이 특징입니다. 가장 큰 특징 중 하나는 서비스들간 재사용 목적으로 사용 됩니다.
ESB(Enterprise Service Bus) 라는 개념을 통해 요청에 대해 어떤 서비스들을 호출 되는지 캡슐화 된 Layer 존재 합니다.
MSA (Micro Service Architecture) 등장
SOA(Service Oriented Architecture) 경우는 서비스간 재사용은 지향했지만 MSA (Micro Service Architecture) 는 지양 하고 있습니다. 왜냐하면
서비스간 결합도는 낮추기 위함 입니다.
이러한 낮은 결합도로 구축 해서 서비스 변화에 신속하게 배포 할수 있습니다. 즉 MSA 경우는 신속한 애자일을 통해서 고객에게 원하는 서비스를 제공 한다는 점 입니다. 고객에게 애자일 제공을 위해 서비스간의 결합도를 낮추게 되고
이는 MSA 로 발전 하게 되었습니다.
기존 모놀리스, SOA 에서 단점으로 지적되는 서비스간의 높은 결합도, 배포, 유연성 등 문제점으로 인해 변화에 빠르게 반영을 즉각적으로 대응을 할 수 없으니 이를 개선하고자 MSA 가 탄생 하게 되었습니다.
MSA 특징 Business Capabilities
지금까지 MSA 에 대해 장점을 알아보았습니다. 개인적으로 MSA 가장 큰 장점 중 하나로 생각하는 것은 Business Capabilities 특징에 가장 적합 하다고 생각 합니다.
Business Capabilities 는 얼마나 빠르게 유연하고 신속하게 비지니스 변화에 대응 할 수 있는 능력을 말합니다.
기존 모놀리스 경우는 “기능 조식” 에 적합한 목적을 가졌지만 MSA 경우는 “목적 조직” 에 초첨을 맞춰져 있습니다.
MSA 는 단점이 없을까?
서비스간 독립적 구성인 MSA 가 Monolithic 비교해서 어렵고 복잡한 것 입니다. MSA 도 분명 단점은 존재하지만 이제 설명하는 단점에 대해
MSA 단점 비해 장점이 부각되어 많은 회사들이 사용되고 있는 것 같습니다.
일단 단점에 대해 설명 하도록 하겠습니다.
MSA Transaction 문제
만약 사용자가 결제 시도를 할 경우 결제 서버에서 정산 서버 그리고 회원 서버까지 모든 비니지스 로직이 실행 되어야 전체적인 결제 시도가 완료 됩니다.
하지만 결제 시도 -> 정산 시도 -> 회원 정보 DB 정보 업데이트 하는 과정에서 DB 문제가 발생되면 이전에 진행되었던 DB 상태 업데이트를 모두 롤백을 해야 합니다.
결제 서비스 및 정산 서비스 등 각각 독립적인 DB 서버로 연결하고 있기 때문에 회원 서비스에서 DB 문제가 발생되면 이전에 진행되었던 ‘결제’, ‘정산’ 관련 DB 업데이트 된 것은 이미 commit
되었기 때문에 보상 트랜잭션 또는 Saga 방식 통해 다시 이전 상태로 DB 업데이트를 해야 합니다.
하지만 이미지를 보시면 결제 프로세스 진행 하는 과정에서 외부 PG 사와 결제 승인을 이루어지고 결제 관련 결과 DB 상태를 업데이트를 했다면 또 이야기는 달라집니다.
외부 결제 승인 경우는 다시 이전 상태로 되돌리기가 어렵기 때문입니다.
MSA Data Query 문제
만약 특정 A 이라는 고객이 결제 내역(결제 내역 + 정산 내역 + 회원 정보) 을 조회 한다고 했을시 기존 Monolithic 경우는 하나의 DB 서버로 통해 구성되어 있으니
결제 테이블 + 정산 테이블 + 회원 테이블 을 JOIN 통해 쉽게 조회가 가능 할 것 입니다.
하지만 MSA 경우는 각각 서비스 별로 DB 서버로 구성되어 있기 때문에 결제 내역, 정산 내역, 회원 정보 각각 DB 호출해서 추출한 데이터를 조합해 고객에게 전송 해야 합니다.
이러한 데이터 조합 처리가 필요하고 기본 보다 호출 횟수로 보았을때 기존 Monolithic 방식 보다 더 많아 지는 경우가 발생 됩니다.
MSA Monitoring 문제
기존 Monolithic 경우는 대체적으로 하나의 서버로 통해 모니터링 하면 됩니다. 즉 Monolithic 아키텍쳐 경우 단조로움 덕분에 JVM 상태, 메모리, CPU 등
모니터링 경우에도 단조롭게 해결이 가능 합니다.
하지만 MSA 로 보았을때는 서로 다른 각각의 서비스간 별도 노드로 구성되어 있다보니 각각의 노드들의 서버 상태 등 확인 해야 하고 또한 노드들간의 네트워크 상태 및 서비스간 요청 응답 Latency 시간 등
많은 것들을 확인 해야 합니다.
예를들어 결제 시도를 진행 하는 과정에서 결제 서버 -> 정산 서버 -> 회원 서버 흐름이 있을때 회원 서버에 문제 발생시 회원 서버까지 진행되는 흐름을 전체적으로 파악 하고 있어야 합니다.
그리고 특정 위치에 호출 요청 응답 Latency 너무 늦어지는 현상이 발생시 단순히 지표로 확인하는 것으로 넘어서 어디서 부터 파생되는 문제인지 전체적인 흐름도 파악 해야 합니다.
지금까지 MSA 단점에 대해 알아보았습니다. 이러한 단점이 있는데도 MSA 를 사용해야 한다는 것은 단점을 상쇄 할만한 장점이 있다는 것 입니다. 즉 앞써 이야기 한 Business Capabilities 장점이 있다는 것 입니다.
그리고 이것을 재대로 효과를 얻기 위해서는 지금까지 이야기 한 단점을 보안 해야 합니다.
지금부터 단점을 어떻게 극복하고 MSA 를 어떻게 구성 및 구현 해야 하는지 알아보도록 하겠습니다.
Copyright 201- syh8088. 무단 전재 및 재배포 금지. 출처 표기 시 인용 가능.
