MSA로 전환2

https://medium.com/coupang-engineering/how-coupang-built-a-microservice-architecture-fd584fff7f2b

마이크로서비스 아키텍처로의 전환

쿠팡에서 모놀리식 아키텍처의 한계를 느껴 MSA 아키텍처로 전환하는 과정과 MSA 운영 과정을 요약한 글입니다.

 

모노리식 아키텍처의 한계

• 부분 장애가 서비스 전체 장애로 확대
• 관심사 분리의 어려움
• 부족한 확장성
• 테스트 비용 증가
• 배포 대기 시간 증가

 

MSA 전환 전략

프레임워크 

팀에 공통적으로 필요한 기술적 토대를 제공하고, 도메인 팀이 비지니스 로직 구현에만 집중할 수 있게 지원

 

클라이언트용 헬퍼 라이브러리

일반적인 마이크로서비스 아키텍처의 경우, 분리되어 있는 도메인들끼리 RESTful API를 통해 상호 통신합니다. 특정 API를 사용하기 위해 모든 클라이언트들은 HTTP 통신을 하는 모듈을 만들고, JSON 형태의 API 요청을 만든 후, 요청을 오브젝트(object)로 매핑해야만 합니다. 이 과정을 모든 도메인마다 구현할 경우 낭비이므로 API 콜 모듈 라이브러리를 개발했습니다.

 

메시지 큐

모놀리식 아키텍처에서는 모든 컴포넌트가 강결합 형태로 존재합니다. 이런 관계를 MSA로 전환 시 트랜잭션 문제가 발생할 수 있습니다. 이를 해결하기 위해서 메시지 큐를 사용했습니다. 안전하고 실수를 방지할(error-proof) 수 있는 방식으로 트랜잭션 분리한 뒤, 마이크로서비스에서 처리가능한 메시지 형태로 변환하여 처리할 수 있도록 했습니다. 그리고 트랜잭션 무결성의 보장을 위해 해당 이벤트 메시지들은 자동으로 배달 못한 편지 큐(Dead Letter Queue)로 전달되고 서비스가 정상 복구되면 전달에 실패했던 이벤트 메시지들을 재처리할 수 있도록 구성하였습니다.

 

이로 인해 도메인 팀은 코드 운영에서 벗어나 비즈니스 도메인에 집중할 수 있게 되었고 마이크로서비스 아키텍처에 빠르게 적응해 갈 수 있었습니다.  또한 서비스 장애가 발생하더라도 메시지가 수신자(consumer)로 전달되는 것을 보장할 수 있었습니다. 

 

MSA 운영

Configuration Management Database (CMDB)

MSA로 인해 1000개 이상의 서버를 사용하게 되었고, 서비스를 구성하는 자원들의 정보를 한곳에서 관리하고 가시화하기 위해 CMDB를 구축했습니다. CMDB 시스템은 내부 서비스 및 서비스를 구성하는 자원을 관리하는 메타 데이터베이스입니다. 계층적 관계를 갖는 키-값(key-value) 쌍 컬렉션(collection)의 메타 데이터가 저장되어 있습니다. 그리고 메타 데이터 사이의 관계는 매핑되어 있습니다.

 

서버 리소스의 변화를 지속적으로 트래킹, 가시화를 통해 클라우드 환경으로 빠르게 이전할 수 있었습니다. 그리고 CMDB이 RESTful API로 제공함으로써 클라우드서버용 플랫폼 서비스 간의 자동화도 쉽게 구축할 수 있었습니다. 클라우드 환경에서 피처 배포를 하면, 실행 중인 서버 인스턴스가 동적으로 재구성됩니다. 이러한 변화를 CMDB가 감지하고 자동 알람으로 다른 서비스에 알리기 때문에, 알람을 받은 서비스는 변화를 모니터링하고 자동복구를 실행할 수 있었습니다.

 

 

배포 시스템

쿠팡은 작은 단위의 기능 변경을 통해 고객의 니즈를 일일히 서비스에 반영합니다. 서비스 생명주기(Lifecycle)를 가속화하는데 있어 강력한 배포 시스템은 매우 중요한 요소입니다. 이런 니즈를 충족시키기 위해, 블루-그린(blue-green) 배포 전략을 수행할 클라우드 기반의 온라인 배포 시스템을 구축했습니다. 저희의 배포 시스템은 다음과 같은 주요 기능을 가지고 있습니다.

• 배포 권한 제어
• 서비스의 리소스 스택(resource stack) 자동 구성
• 빠른 배포를 통해 배포에 소요되는 개발 비용 최소화
• 10초 이내의 롤백을 지원하여 서비스 장애 시 빠른 복구 지원
• Target Tracking 기반의 Auto Scaling Group을 지원하여 리소스를 효율적으로 사용
• Graceful shutdown 지원
• Health check 및 service warm-up 지원

 

A/B 테스트

마이크로서비스 아키텍처 환경에서는 기존의 전통적 방식처럼 완성된 제품이 한번에 출시되지 않고, 서비스 개선 사항들이 점진적으로 배포됩니다. 어떤 서비스 개선사항을 서비스 전체에 적용하는 게 좋을지 효율적으로 결정하기 위해, 쿠팡은 A/B 테스트를 수행합니다. A/B 테스트는 기존의 A 기능을 사용자 그룹 A에 제공하고, 새로운 B 기능을 사용자 그룹 B에 제공해 두 사용자 그룹이 일정 기간 동안 보여주는 반응을 비교합니다. 이때 기존의 A 기능과 신규로 개발한 B 기능 중 어떤 것이 정말 고객이 원하는 방안인지 판단할 수 있는 근거가 필요합니다.

 

API 게이트웨이

많은 API로 구성되어 있는 서비스는 API 사양 명세, API 소비자, API 버저닝 등 다양한 이유로 관리가 어렵습니다. 무엇보다 저희의 노력이 필요했던 부분은 API에 변경이 일어날 때였습니다. API 변경 시 직접 전체 사용자에게 공지하고, 변경으로 인한 부작용을 일일이 파악해야 했습니다. 전체적으로 서비스가 성장하고 복잡해질수록, API 제공자 및 소비자 모두의 생산성이 떨어졌습니다. 쿠팡은 마이크로서비스 아키텍처 환경에서 이러한 문제를 해결하기 위해 API 게이트웨이를 자체적으로 구축했습니다.

 

Confidence 시스템

코드 버그, 성능 이슈를 예방하기 위해서 Confidence 시스템을 구축했습니다.

 

쿠팡의 배포 파이프라인은 세 단계로 구성되어 있습니다. 스테이지(Stage), 카나리(Canary), 올(All)입니다. 

• 스테이지 단계에서는 사용자의 트래픽이 들어오지 않은 상태에서 기능을 테스트합니다.
• 카나리 단계에서는 신규 기능을 서버 1대에만 배포하여 사용자 트래픽을 제한적으로 받으며 테스트합니다.
• 올 단계에서는 신규 기능을 모든 서버로 배포합니다.

 

카나리 단계에서 신규 기능의 배포가 이뤄지면 Confidence 시스템은 자동으로 카나리 서버와 기존 서버들의 다양한 지표를 비교하여 해당 배포의 안정성을 모니터링합니다. 만약 해당 배포에 문제가 발생하면 자동으로 신규 기능을 서비스에서 제거하고 그 기능의 전체 배포를 방지합니다. Confidence 시스템을 통해 실제 운영 환경에서 많은 장애를 미리 차단할 수 있었고, 전체 서비스의 업타임(uptime)도 획기적으로 개선할 수 있었습니다.

 

 

서킷 브레이커 시스템(Circuit breaker system)

한 서비스의 장애가 다른 서비스들의 장애(cascading failure)로 이어지는 것을 예방하기 위해, 서킷 브레이커 시스템을 개발했습니다. 서킷 브레이커 시스템은 장애가 발생한 서버에 트래픽을 전달하지 않는 시스템입니다.

 

운영 중인 서비스의 장애를 최소화하거나, 회피하게 함으로서 높은 수준의 서비스 안정성을 확보할 수 있었습니다.

다양한 플랫폼 서비스와 연계하여 간단한 설정만으로도 인프라 및 서비스를 제어할 수 있도록 되어 있으며, 중앙화된 제어와 관리 또한 가능하도록 되어있습니다.