마이크로서비스 아키텍처 환경에서 플랫폼 서비스 개발하기
행복을 찾기 위한 쿠팡의 여정, 마이크로서비스를 지탱하는 플랫폼 서비스를 개발하다 — Part 2
By 정재훈
본 포스트는 영문으로도 제공됩니다.
마이크로서비스 아키텍처(Microservice Architecture) 기반의 시스템과 서비스들 덕분에 쿠팡 엔지니어들은 매일 개발되는 수백개의 새로운 피처들을 독립적으로 배포하고 테스트할 수 있습니다. 그러나 복잡한 구조를 가진 마이크로서비스 아키텍처를 효율적으로 관리하는 일은 쉽지 않습니다.
이번 포스트에서는 쿠팡이 마이크로서비스 아키텍처를 운영하면서 마주했던 도전들과 그것들을 극복하기 위해 개발했던 플랫폼 서비스에 대해 이야기해보려 합니다.
Configuration Management Database (CMDB)
쿠팡은 모놀리식 아키텍처(Monolithic Architecture)에서 마이크로서비스 아키텍처로 전환하면서 서로 강하게 결합되어 있던(tightly-coupled) 서비스들이 느슨하게 결합(loosely-coupled)된 수백개의 서비스들로 분리되었습니다. 더불어 늘어나는 비즈니스 요구 사항에 따라 새로운 서비스를 매달 새로 개발했습니다. 모든 서비스를 유지 및 운영하기 위해 10,000개 이상의 서버를 사용하게 되었습니다. 서비스가 폭발적으로 늘어나면서, 서비스 및 서비스를 구성하는 자원들 모두의 정보를 한곳에서 관리하고 가시화하기 위해 2015년도에는 Configuration Management Database(CMDB) 시스템을 자체적으로 구축하였습니다.
쿠팡 CMDB 시스템은 내부 서비스 및 서비스를 구성하는 자원을 관리하는 메타 데이터베이스입니다. 계층적 관계를 갖는 키-값(key-value) 쌍 컬렉션(collection)의 메타 데이터가 저장되어 있습니다.
그림 1과 같이 메타 데이터 사이의 관계는 매핑되어 있습니다. 예를 들어, Member 서비스에는 member-api, member-front, member-db 등과 같은 관련 컴포넌트들이 있습니다. 각 컴포넌트는 물리적인 인스턴스로 존재하며 service configuration, DNS, Git repository, LDAP과 같은 다양한 메타 데이터와 관계를 가질 수 있습니다.
CMDB는 리소스 관리뿐만 아니라, 2017년에 쿠팡 서비스를 클라우드 기반으로 전환할 때 매우 큰 역할을 했습니다. 클라우드 환경에서는 서버들이 빈번하게 생성되고, 소멸되기 때문에 이런 서버 리소스의 변화를 지속적으로 트래킹하고, 가시화할 수 있는 시스템이 필요합니다. 이러한 역할을 CMDB가 함으로써, 쿠팡의 모든 서비스들을 클라우드 환경으로 빠르게 이전할 수 있었습니다. CMDB이 RESTful API로 제공함으로써 클라우드서버용 플랫폼 서비스 간의 자동화도 쉽게 구축할 수 있었습니다. 클라우드 환경에서 피처 배포를 하면, 실행 중인 서버 인스턴스가 동적으로 재구성됩니다. 이러한 변화를 CMDB가 감지하고 자동 알람으로 다른 서비스에 알리기 때문에, 알람을 받은 서비스는 변화를 모니터링하고 자동복구를 실행할 수 있었습니다.
쿠팡 배포 시스템
쿠팡에서는 매일 약 100 ~ 200개의 마이크로서비스가 새롭게 배포됩니다. 이 과정에서 2000대 이상의 인스턴스가 새롭게 구성됩니다. 쿠팡은 작은 단위의 기능 변경을 통해 고객의 니즈를 일일히 서비스에 반영합니다. 서비스 생명주기(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 기능 중 어떤 것이 정말 고객이 원하는 방안인지 판단할 수 있는 근거가 필요합니다.
쿠팡은 마이크로서비스 아키텍처로 전환하는 초기부터 A/B 테스트 시스템을 개발하여 주요 기능 변경을 검증하였습니다. 아래 그림은 쿠팡의 A/B 테스트 시스템의 일부 페이지입니다. 특정 기능에 대하여 디바이스(아이폰, 안드로이드, PC)를 선택하고 노출빈도, 기간을 설정하면 A/B 테스트가 자동으로 진행됩니다. 시스템을 통해 총 거래액(Gross Merchandise Volume, GMV), 전환율(Conversion Rate, CRV) 등 다양한 지표가 테스트 도중 어떻게 변하는지도 살펴볼 수 있습니다.
쿠팡 API 게이트웨이
마이크로서비스 아키텍처 환경에서는 다수의 서비스들을 약하게 결합해 하나의 서비스를 구성합니다. 그리고 각 서비스는 수많은 API들을 가지고 있으며, 다른 서비스와 서로 통신하며 데이터를 주고받습니다. 고객 입장에서 쿠팡은 단 하나의 앱 또는 웹사이트이겠지만, 내부적으로 100개 이상의 서비스, 10,000개 이상의 API들이 모여 쿠팡이라는 서비스를 움직입니다. 이렇게 많은 API로 구성되어 있는 서비스는 API 사양 명세, API 소비자, API 버저닝 등 다양한 이유로 관리가 어렵습니다.
무엇보다 저희의 노력이 필요했던 부분은 API에 변경이 일어날 때였습니다. API 변경 시 직접 전체 사용자에게 공지하고, 변경으로 인한 부작용을 일일이 파악해야 했습니다. 전체적으로 서비스가 성장하고 복잡해질수록, API 제공자 및 소비자 모두의 생산성이 떨어졌습니다. 쿠팡은 마이크로서비스 아키텍처 환경에서 이러한 문제를 해결하기 위해 API 게이트웨이를 자체적으로 구축했습니다.
Confidence 시스템
장애의 유형에는 크게 3 가지가 있습니다: 코드 버그, 성능 이슈, 하드웨어 이슈. 내부 리뷰를 통해 쿠팡에서 주로 일어나는 오류는 코드 버그 또는 성능 이슈로 파악되었습니다. 이 두 종류의 장애를 자동으로 제어하기 위해 저희는 Confidence 시스템을 구축했습니다.
쿠팡의 배포 파이프라인은 세 단계로 구성되어 있습니다. 스테이지(Stage), 카나리(Canary), 올(All)입니다. 스테이지 단계에서는 사용자의 트래픽이 들어오지 않은 상태에서 기능을 테스트합니다. 카나리 단계에서는 신규 기능을 서버 1대에만 배포하여 사용자 트래픽을 제한적으로 받으며 테스트합니다. 마지막으로 올 단계에서는 신규 기능을 모든 서버로 배포합니다.
카나리 단계에서 신규 기능의 배포가 이뤄지면 Confidence 시스템은 자동으로 카나리 서버와 기존 서버들의 다양한 지표를 비교하여 해당 배포의 안정성을 모니터링합니다. 만약 해당 배포에 문제가 발생하면 자동으로 신규 기능을 서비스에서 제거하고 그 기능의 전체 배포를 방지합니다. Confidence 시스템을 통해 실제 운영 환경에서 많은 장애를 미리 차단할 수 있었고, 전체 서비스의 업타임(uptime)도 획기적으로 개선할 수 있었습니다.
서킷 브레이커 시스템(Circuit breaker system)
Confidence 시스템은 장애를 예방하는 시스템이라면, Circuit breaker 시스템은 상시 운영 중인 서비스 장애를 차단 또는 회피하는 시스템입니다. 마이크로서비스 아키텍처에서는 수많은 작은 서비스들이 상호 통신하기 때문에, 복잡한 의존성을 갖게 됩니다.
따라서 한 서비스의 장애가 다른 서비스들의 장애(cascading failure)로 이어지는 것을 예방하기 위해, 쿠팡만의 내부 Circuit Breaker 시스템인 Valve를 자체적으로 개발하였습니다. Valve를 통해 365일 24시간 운영 중인 서비스의 장애를 최소화하거나, 회피하게 함으로서 높은 수준의 서비스 안정성을 확보할 수 있었습니다. Valve는 쿠팡의 다양한 플랫폼 서비스와 연계하여 간단한 설정만으로도 인프라 및 서비스를 제어할 수 있도록 되어 있으며, 중앙화된 제어와 관리 또한 가능하도록 되어있습니다. 예를 들면, 운영 중인 특정 서버에 장애가 발생하면, 해당 서버를 자동으로 제거하고 추가 서버를 자동으로 투입하여 특정 서버의 장애가 서비스 전체 장애로 확대되는 것을 방지합니다. 또한 장바구니 서비스에 장애가 발생하면, 상품 페이지에서 장바구니 버튼을 숨겨 고객이 바로 주문으로 이동하도록 유도해 장애를 회피할 수도 있습니다.
마치며
지난 포스트에 이어서 쿠팡의 마이크로서비스 아키텍처에 대한 이야기와 마이크로서비스를 지탱하기 위해 만들어진 플랫폼 서비스들에 대해서 알아보았습니다.
지금도 쿠팡의 마이크로서비스 아키텍처는 여전히 성장하고 있습니다. 누구도 경험하지 못한 기술적 난제들을 매일 겪으며, 하나씩 해결해가고 있습니다. 다양한 시도를 통해 레이턴시 시각화와 모니터링, 릴리스 엔지니어링, 복잡도 관리, 에러의 근본 원인 분석과 같은 것들을 개선하려 합니다.
시리즈 목차
해당 포스트는 쿠팡의 마이크로서비스 아키텍처에 대한 두 번째 포스트입니다.
Part 1 — 마이크로서비스 아키텍처로의 전환
Part 2 — 마이크로서비스 아키텍처 환경에서 플랫폼 서비스 개발하기
도전하고 싶은 과제를 이 글에서 찾으셨다면, 저희 팀에 합류해주세요!
