면접, 단일 장애점을 예방하는 Microservice Architecture 개념 분해

안녕하세요
K-인사이트 입니다. 

 

 
안정적인 시스템 운영과 유지보수는 모든 개발자들이 도달하기 위해 분투를 하는 영역입니다. 완벽은 존재하지 않지만 그 완벽에 다가가기 위해 여러 방법론들이 새롭게 등장하고 문제를 해결해 나가고 있습니다. 이 과정에서 과거 모놀리식 아키텍처(monolithic architecture)의 단점들을 극복하는 마이크로서비스 아키텍처(microservices architecture, 이하 MSA)가 등장하게 되었습니다. 이 글을 쓰는 시점에 수많은 대규모 서비스들이 MSA로 개발되고 있습니다. MSA란 무엇이며 어떤 효용이 있을지를 알아보겠습니다.

 

 

모놀리식 아키텍처란?

모놀리식 아키텍처(이하, 모놀리식)는 하나의 코드 베이스를 사용하여 여러 비즈니스 기능을 수행하는 전통적인 소프트웨어 개발 모델입니다. 예를들어 여러분이 쇼핑몰 프로젝트에 결제, 댓글, 상품관리 등의 기능을 단일 코드 베이스에서 진행한다는 의미입니다.

 

모놀리식은 상대적으로 소규모 프로젝트 단위에서 빠르게 개발 효율을 보일 수 있는 장점이 있습니다. 그러나, 결제, 댓글, 상품관리 등의 기능들이 한 시스템 내에서 데이터 교환을 하기 때문에 상호 의존성이 매우 높은 상태를 유지하게 됩니다. 즉, 댓글 API를 간단하게 수정을 하였는데 전체 쇼핑몰 시스템에서 장애가 발생하는 상황이 올 수 있다는 의미가 됩니다. 여기서 댓글 API를 단일 실패점(Single Point Of Failure, SPOF)라고 부를 수 있습니다.

 

이러한 점 때문에 초기 개발 단계에서는 발생하지 않았던 이슈들이 서비스가 성숙해지고 많은 사용자들이 유입되는 대규모 서비스로 발전하게 되면서 수 많은 장애를 일으키고 모듈(결제)을 수정하기 위해 여러 모듈(회원관리, 상품관리 등)의 코드를 검토하고 수정해야하는 진퇴양난의 상황에서 개발자들의 수 많은 의사소통을 요구하는 상황이 발생하게됩니다. 즉, 장애를 막기 위해 여러 검증 절차들이 도입되고 모두 서비스 전체 도메인을 검토하는 수준의 노력을 요구하게됩니다.

 

아래의 그림을 통해 좀 더 직관적으로 이해가 가능합니다.

출처: AWS

따라서, 모놀리식 아키텍처의 장단점을 간략하게 요약하면 아래와 같습니다.

• 장점: 서비스 초기에 빠른 개발이 가능
• 단점: 서비스 복잡성이 높아질수록 모듈 간 높은 상호의존성으로 단일 실패점이 발생하고 유지보수 비용이 상승

 

 

마이크로서비스 아키텍처란?

모놀리식의 장점과 단점을 알아보았습니다. 여러분이 만약 1인 사업자이고 비교적 간단한 시스템을 만든다면 모놀리식은 최적의 방안입니다. 하지만 언젠가 여러분의 사업이 커지게되고 관리해야 될 요소들이 많아진다면 마이크로서비스 아키텍처(이하 MSA)라는 용어를 여러 채널을 통해 접하게 될 것입니다.

 

MSA는 모놀리식과 다른 전략을 취합니다. 앞서 쇼핑몰 예시에서 결제, 회원관리, 댓글, 상품관리 등의 기능들이 여러 개의 작은 서비스로 구성되는 구조입니다. 그리고 각 마이크로한 서비스들이 독립적으로 개발되고 배포되게 됩니다. 이러한 서비스를 분산하는 방식은 개발, 배포의 독립성을 보장하기에 확장성과 유지관리가 쉬워진다는 장점이 있습니다.

 

또한, 결제 API 기능을 여러벌 복제해서 Scale Out(스케일 아웃)하는 전략도 용이해집니다. 여기서 스케일 아웃이란 결제 API 서버(컨테이너)를 복제하여 여러개로 서버를 늘리는 것을 말합니다. 대량의 트래픽을 처리하는 상황에 놓인다면 수많은 요청들을 처리해야되는 상황에 놓일 수 있습니다. 이때 예상되는 트래픽 병목지점을 분석해서 선택적으로 관련 서비스를 스케일 아웃이 가능합니다. 티켓팅 서비스를 제공하는 서비스들이 BTS와 같은 대규모 예매 이벤트에 미리 서버를 늘리는 처리를 합니다.

 

하지만 어디에든 함정이 있기 마련입니다. 앞서 모놀리식의 장점으로 서비스 초기에 빠른 개발이 가능한 점을 언급하였습니다. 즉, MSA는 일반적인 모놀리식 개발보다 복잡한 특성이 있습니다. 또한, 수 많은 서비스들을 일괄적으로 관리하는데 많은 도구가 필요합니다.

 

마지막으로 MSA를 위해서는 여러 새로운 기술을 학습해야 합니다. 구성원들이 MSA를 택하기 위해 아래의 요소들을 검토하고 테스트해야 합니다.

• 인프라 환경: 클라우드(AWS, GCP, Azure), 도커, 쿠버네티스
• 배포 및 운영: 데브 옵스, 마이크로 서비스 관리를 위한 자동화 도구, 컨테이너 레지스트리
• 데이터 저장: 스토리지
• 구현을 위한 필수 역량들: Service Discovery, Config Server, API Gateway, SW Defined Load Balancer, Circuit Breaker, Distributed Tracing, Data Lake, Messaging
• 이벤트 기반 아키텍처: AWS SQS, AWS SNS, Kafka, Redis, RabbitMQ

이처럼 배울 내용이 많지만, 그만큼 엔지니어링 측면에서 성장할 수 있습니다. 누군가에겐 장점이겠습니다. 그러나 비용을 집행하고 시간 내에 프로젝트를 끝내야하는 입장에서는 많은 비용과 시간이 소모될 것입니다. 그럼에도 MSA가 인기 있는 이유는 무엇일까요? MSA 장점들을 나열하면 다음과 같습니다.

• 개발 유연성의 한계 극복
• 요구사항 처리 능력 향상
• 장애 등의 이슈에 대한 빠른 대처 가능
• 배포/롤백 리스크의 획기적 감소
• 장애 격리의 신뢰성
• 리소스의 효율적인 사용

마이크로서비스 성공 사례: 배달의 민족

대규모 서비스로 빠르게 발전하여 모놀리식을 MSA로 성공적으로 전환한 예들은 많습니다. 대표적인 케이스로 배달의민족 서비스를 꼽을 수 있습니다. 배달의민족은 초기 스타트업 시절부터 PHP와 루비 DB(MSSQL) 기술을 이용해서 개발되었습니다. 2015년까지 모놀리식 구조를 유지하다가 MSA로 변화를 추진하게 됩니다. “우아콘2020”에서 밝힌 배달의민족이 MSA를 선택하게된 배경은 다음과 같습니다.

• 늘어나는 사업 요구사항을 처리하면서 시스템이 비대해짐
• 모놀리식 구조이기에 각 도메인의 장애가 단일 실패점(SPOF)로 동작

즉, 앞서 배웠던 모놀리식 아키텍처의 단점을 그대로 체감한 끝에 내린 결정입니다. 당시 2015년도 배민의 시스템 구조는 아래의 그림과 같습니다. 리뷰, 정산, 결제 등에서 장애가 발생하면 곧바로 전체 시스템의 장애로 이어지는 것을 반복된 셈입니다.

 

배달의민족은 2016년도부터 MSA를 도입하면서 결제 서비스를 분리하였습니다. 가장 장애가 많이 발생하는 서비스부터 분리한 셈입니다. 이때 기존 IDC 에서 AWS로 이전을 하게됩니다. 단, 결제 DB는 현행법률의 제한으로 IDC에 설치하였습니다. 배민이 MSA로 전환할 때 장애가 많이 발생하는 서비스부터 분리하는 방식을 택하였습니다. 결제 → 주문중계 → 정산, 메뉴 → 쿠폰, 주문, 포인트 독립을 순서로 이전을 하였으며 3년에 걸쳐서 완료하게됩니다. 기존 모놀리식 서비스가 워낙 방대하였기에 이전하는데에도 많은 시간이 소모되었습니다. 아직 신생 회사라면 이러한 비용도 중요하다고 여겨집니다.

 

맺음말

마이크로서비스 아키텍처를 이해하면서 기존 모놀리식 아키텍처의 장점과 단점에 대해서 살펴보았습니다. 모든 것에 양면성이 있듯이 두 구조 모두 장단점이 있습니다. 따라서, 무조건 최신 트렌드를 쫓기보다는 현재 상황에 맞는 구성과 전략을 선택하고 미래를 대비하여 성공적인 서비스를 일구어내시길 기원드립니다.

 

이상입니다.

K-인사이트 올림.

 

참고

• 우아콘 2020, 배달의민족 마이크로서비스 여행기, https://www.youtube.com/watch?v=BnS6343GTkY&t=1987s
• AWS, 클라우드 컴퓨팅 개념 허브, https://aws.amazon.com/ko/compare/the-difference-between-monolithic-and-microservices-architecture
• IBM, 엔터프라이즈 마이크로 서비스 2021, https://www.ibm.com/downloads/cas/OQG4AJAM
• OpsNow, 요즘 대세 MSA, 마이크로 서비스 아키텍처!, https://www.opsnow.com/요즘-대세-msa/