행복을 찾기 위한 우리의 여정,

쿠팡의 MSA — Part 2

“행복을 찾기 위한 우리의 여정, 쿠팡의 MSA”에 대하여 2가지 주제를 가지고 설명한다.

Micro service architecture를 위한 쿠팡의 여정

Micro service architecture를 지탱하는 쿠팡 플랫폼 서비스

2. Platform Service that sustains micro service architecture

수백개의 micro service를 지탱하는 플랫폼 서비스들은 무엇이고, 우리가 어떠한 문제를 해결하기 위해 이러한 플랫폼을 만들었지에 대하여 이야기하겠다.

Configuration Management Database (CMDB)

Monolithic architecture에서 micro service architecture로 전환하면서 수백개의 서비스가 생성되었고, 이러한 서비스들을 유지하기 위하여 10,000개 이상의 서버들을 사용하고 있다. 이렇게 서비스가 점점 많아지면서, 서비스와 서비스를 구성하는 모든 자원들의 정보를 한 곳에서 관리하고 가시화 하기 위한 시스템이 필요하였고, 이를 위하여 2015년도에 CMDB 시스템을 자체적으로 구축하였다.

쿠팡의 CMDB 시스템은 서비스와 서비스를 구성하는 모든 자원들을 위한 메타 DB이며, Key/Value Collection 으로 구성된 metadata가 상호간 관계를 가지는 구조이다.

CMDB의 metadata에 대한 관계는 위의 그림과 같이 정리할 수 있다. 예를 들어, member 서비스에는 member-api, member-front, member-db 와 같은 여러 개의 Component가 존재하며, 각각의 component들은 물리적인 instance 들을 가지고 있다. 그리고 service configuration, dns, git repository, ldap과 같은 다양한 metadata들과 관계를 가질 수 있다.

CMDB는 특히 쿠팡의 서비스가 cloud 기반으로 전환되면서 매우 강력한 도구가 되었다.

On-Premise 환경에서는 물리적인 서버들로 구성되어 변화가 거의 없으며, 생명 주기가 긴 반면에 cloud 환경에서는 서버들이 빈번하게 생성되고, 소멸된다. 다시말해, 클라우드 환경에서는 리소스들의 변화를 서비스 기준으로 지속적으로 트래킹하고, 가시화를 할 수 있는 시스템이 필수적으로 필요하다. 이러한 역할을 쿠팡의 CMDB가 함으로써, 쿠팡의 모든 서비스들이 빠르게 Cloud 환경으로 이전할 수 있었다.

CMDB의 큰 장점으로는 서비스의 모든 metadata를 RESTful 방식의 API로 제공함으로써 플랫폼 서비스 간의 자동화를 쉽게 구축할 수 있다. 예를들어 클라우드 환경에서 배포할때마다, instance들이 동적으로 재구성된다. 이러한 변화를 CMDB가 다른 플랫폼 시스템에 제공하기 때문에 우리는 서비스 기준으로 쉽게 모니터링하고, 알람을 받고, 자동복구를 할 수 있게 되었다.

Coupang Deployment System

Micro service architecture 환경에서는 서비스 단위의 배포가 매일 빈번히 발생한다. 쿠팡도 수백개의 작은 서비스들에서 매일 100~200회 정도의 배포가 발생하고 있으며, 이 과정에서 2000대 이상의 instance들이 매번 새롭게 구성된다.

작은 단위의 기능 변경을 통하여 고객의 니즈를 서비스에 반영하고, 다시 그 피드백을 받아 개선하는 방식으로 서비스의 life-cycle이 구성되는데, 강력한 배포 시스템은 이러한 서비스의 life-cyle을 가속화하는데 매우 중요한 시스템이다.

쿠팡의 배포시스템은 blue / green deployment strategy를 가진 cloud 기반의 웹 배포 시스템이다.

다음과 같은 주요한 기능을 포함하고 있다.

배포 권한 제어

서비스의 resource stack을 자동으로 구성

빠른 배포가 가능하여 개발자들이 배포에 소요되는 비용을 최소화

10초 이내 롤백을 지원하여 서비스 장애가 발생하더라도 빠르게 복구가 가능

Target Tracking 기반의 Auto Scaling Group을 지원하여 resource를 효율적으로 사용

성공한 배포만 master branch에 merge될 수 있도록 git repository를 자동으로 제어

Graceful shutdown 지원

Health check & service warm-up 지원

AB Test

Micro service architecture 환경에서는 기존의 전통적인 방식으로 제품이 출시되지 않고, 점진적인 방식으로 서비스의 개선이 일어난다. 이를 효과적으로 진행하려면 기존의 A안과 신규로 개발한 B안 중 어떤 것이 정말 고객이 원하는 방안인지 판단할 수 있는 근거가 있어야 한다. 이렇게 A안 / B안을 전체 또는 일부 고객에게 노출하여 검증하는 시스템을 AB Test라고 부른다.

쿠팡은 micro service architecture로 전환하는 초기부터 A/B 테스트 시스템을 만들어 사용해 왔으며, 주요한 feature 변경이 있을 때마다 어떤 것이 보다 더 고객의 요구에 부합하는지 검증하는 방식으로 서비스를 개선시켜왔다.

아래 그림은 쿠팡의 AB Test System의 일부 페이지이다. 특정 A/B에 대하여 디바이스(아이폰, 안드로이드, PC)를 선택하고 노출빈도, 기간을 설정하면 자동으로 A/B 테스트가 진행된다. 이 테스트를 통하여 Gross Merchandise Volume, Conversion Rate 등의 지표가 어떻게 변화하는지 판단한다.

API Gateway

Micro service architecture 환경에서는 다수의 서비스들이 모여 하나의 서비스를 구성한다. 그리고 각 서비스는 수많은 API들을 가지고 있으며, 다른 서비스와 서로 통신하여 데이터를 주고 받는다. 쿠팡도 고객입장에서 볼때는 단 하나의 웹사이트이지만, 내부적으로 100개 이상의 서비스, 10,000개 이상의 API들이 모여 쿠팡이라는 웹사이트를 살아 움직이게 한다. 이렇게 많은 API들로 구성된 서비스들은 다음과 같은 문제를 발생시킨다.

각 서비스에는 어떤 API가 존재하는지?

각 API의 명세는 어떻게 되는지?

누가 API들을 소비하는지?

어떤 버전의 API들을 사용하는지?

API의 변경을 다른 소비자들에게 어떻게 효과적으로 전달할지?

어떤 consumer에게 얼마 만큼의 요청을 허용할 것인지?

무엇보다 우리의 노력이 필요했던 부분은 API의 변경이 발생할 때였다. 변경시마다 직접 전체 사용자(개발자)에게 공지하고, 변경으로 인한 부작용을 파악해야 했다. 변경 사항이 전달되는 대상은 광범위했고, 사용자들은 자신의 서비스에 영향이 있는지 알기 위하여 모든 공지를 파악해야 했다. 전체적으로 서비스가 성장하고, 복잡해질수록 API 제공자/소비자 모두에게 많은 낭비를 초래하게 만들었다. 쿠팡은 micro service architecture 환경에서 이러한 문제를 해결하기 위하여 API Gateway를 자체적으로 구축함으로써 이러한 문제를 해결하였다.

.

Confidence System

Confince system을 설명하기 전에, 장애의 유형에 대하여 먼저 이야기하고자 한다.

장애 발생 유형

Code Bug

Performance Issue

Hardware Failure

쿠팡에서는 오류가 있는 코드/설정이 배포되거나, 오류는 없지만 성능에 문제가 있는 코드가 배포될 때 집중적으로 장애가 발생하는 것을 파악하고, 이러한 2가지 종류의 장애를 자동으로 제어하기 위하여 confidence 시스템을 구축하였다.

쿠팡의 Production 환경을 위한 배포 파이프라인은 Stage > Canary > All 단계로 구성되어 있다.

Stage : 사용자의 트래픽이 들어오지 않은 상태에서 테스트하는 Stage 단계,

Canary : 신규 feature를 1대만 배포하여 사용자 트래픽을 제한적으로 받아 테스트 하는 Canary 단계

All : 신규 feature를 모든 서버에 배포하는 단계

Confidence System은 Canary 배포가 일어나면 자동으로 Canary 서버와 기존 서버들의 다양한 메트릭을 비교하여 Canary 배포가 안정적인지 모니터링한다. 만약 Canary 배포가 문제가 있다면 자동으로 서비스에서 제거하고 해당 배포 버전의 전체 배포를 blocking한다.

실제로 쿠팡은 confidence system을 운영하면서 많은 장애를 미리 차단할 수 있었고, 전체 서비스의 uptime을 획기적으로 개선하였다.

Circuit Breaker System

Confidence가 배포 직후의 변화를 감지하여 장애를 자동으로 예방하는 시스템이라면, Circuit breaker system은 상시 운영중인 서비스의 장애를 차단하거나, 회피하는 시스템이다.

Micro service architecture에서는 수많은 작은 서비스들이 상호 통신하기 때문에, 복잡한 의존성을 가진다. 따라서, 한 서비스의 장애는 해당 서비스와 연관된 다른 서비스에도 영향을 미쳐 연속적인 장애(cascading failure)를 발생시킨다. 이 경우 문제가 되는 부분을 차단하거나 회피함으로서 연속적인 장애를 막는 시스템을 Circuit Breaker System이라 부른다.

예를 들면, 운영 중인 특정 서버의 장애가 발생하면, 자동으로 해당 서버를 제거하고 추가 서버를 자동으로 투입함으로써 특정 서버의 장애가 서비스의 장애로 확대하지 않도록 한다. 또한 장바구니 서비스의 장애가 발생하면, 상품 페이지에서 장바구니 버튼을 숨겨서 고객이 바로 주문으로 넘어가도록 유도해 장애를 회피할 수 있다

쿠팡은 Valve 라고 불리는 자체적인 Circuit Breaker System을 개발 / 운영하고 있으며, 24시간/365일 운영 중인 서비스의 장애를 최소화 하거나, 회피하게 함으로서 높은 수준의 서비스 안정성을 확보할 수 있었다. Valve는 널리 알려진 Netflix의 hystrix와 다르게, 쿠팡의 다양한 플랫폼 서비스와 연계하여 간단한 설정만으로도 인프라/서비스를 제어할 수 있도록 되어 있으며, 중앙화된 제어와 관리가 가능하도록 되어있다.

In conclusion

지금까지 2회에 걸쳐서 쿠팡의 Micro Service 전환에 대한 이야기와 Micro Service를 지탱하기 위해 만들어진 플랫폼 서비스들에 대해서 알아보았다.

Configuration Management DataBase

Coupang Deployment System

AB Test

Coupang API Gateway

Confidence System

Circuit Breaker System

지금도 쿠팡의 MSA 는 여전히 성장 중이다. 누구도 경험하지 못한 기술적 난제들을 매일 겪으며, 해결해 나가고 있다. 예를 들어 시스템 의존성과 복잡도의 기하급수적인 증가로 발생하는 레이턴시 문제, 테스트의 어려움 등이 있었고 이를 해결하기 위해 다양한 시도를 진행하고 있다.

Latency Visualizer & Monitoring

Release Engineering

Complexity Management

Root cause Analysis

앞으로 블로그 포스트를 통해 쿠팡이 micro service architecture를 운영하면서 발생한 여러 문제들과 그것을 해결하기 위해 도전한 경험들을 계속 공유하도록 하겠다.

정재훈, Sr. Principal, Software Engineering