스프링캠프 2018: 희망을 찾기 위한 우리의 여정, Coupang MSA

우연히 유튜브에서 "SPRING CAMP 2018" 동영상을 보게 되었다. 세미나 가기도 힘든 환경에서 일하느라 점점 뒤처지는 느낌이었는데, 이런 걸 보며 귀동냥이나 해야겠다.


발표 내용 중 라우팅 전략과 Confidence System은 좋은 사례인 것 같다. 기억해 두자.

3줄 요약
- 쿠팡 시스템은 Java 기반의 MSA로 구축했다.
- 플랫폼, API, 메시지 큐는 MSA 기반 구축의 핵심 기술이다.
- 신규 기능의 빠른 배포와 장애 시간의 최소화를 위해 쿠팡의 기술은 진화하고 있다.




전체 요약

- 희망을 찾기 위한 우리의 여정, Coupang MSA
    ○ 발표자: 정재훈
- 쿠팡의 3가지 변곡점
    ○ PHP -> Java
    ○ Monolithic Architecture -> MSA
    ○ 전사 서비스를 Cloud로 이관
- Monolithic Architecture의 pain point
    ○ 부분의 장애로 전체 서비스의 장애를 초래
    ○ 일부 서비스 수정 -> 전체 유닛 테스트 필요
        § 시스템 규모 확장 -> 감당 못할 지경
    ○ 공통 서비스의 관리 부담
    ○ Scale out 이슈
        § 일부 서비스만 적용 불가 -> 전체 아키텍처 변경 필요
    ○ 배포 = 병목 지점
        § 시스템 규모의 확장을 수용하지 못하는 배포 환경
- Vitamin Project
    ○ Monolithic Architecture -> MSA (5년 전 시작)
    ○ 전략
        § 플랫폼 제공 -> 비즈니스 서비스 자동 관리
        § API 서비스를 만들기 쉽도록 Helper 라이브러리 제공
            □ MSA로 전환하기 위한 핵심 기능
        § 메시지 큐 도입 -> 트랜잭션 간 의존성 고리 약화
- 쿠팡을 지탱하는 기술
    ○ CMDB: Configuration Management DataBase
        § 서비스 메타정보, 서비스 인프라 스트럭처 등의 메타정보를 관리
        § 클라우드 환경에서는 서비스 인스턴스가 동적으로 변화하는 환경에 대응
            □ 클라우드 이전 시 강력한 기능을 제공
            □ 인스턴스의 자동 적용, 복구 등 메타정보를 활용하여 자동화
    ○ 배포시스템
        § Blue/Green 배포 전략
        § Bolt2: 쿠팡의 배포 시스템 -> 전체가 자동으로 수행됨
            □ 배포 전 락을 잡고,
            □ 스테이징 서버에 배포
            □ 카나리 배포 -> 새로운 피처가 담긴 첫번째 서버만 적용
            □ 전체 적용
    ○ A/B 테스트
        § 매출이 어떻게 변하는지 등 조사 가능
        § 매우 중요한 역할
    ○ API Gateway
        § 기존에는 API 식별, 변경 등을 수동으로 관리
        § 현재는 서비스 전체에 대한 API를 관리 (스펙, 소유자 등)
            □ 1만개 이상의 API가 일 30억건 처리
        § 라우팅 전략
            □ 초기: 모든 컨슈머가 API Gateway를 경유
                ® 트래픽 증가, 장비 증가, 레이턴시 증가
            □ 현재: 엔드투엔드 라우팅 전략 적용
                ® 컨슈머는 API Gateway에서 프로바이더 정보를 정기 수집
                ® 엔드투엔드 호출을 구현
        § API Gateway에 한번 호출 -> 병렬로 관련 서비스들을 호출하여 레이턴시 감소
        § Public 영역에 External API Gateway 배치
            □ 내부 서비스를 Private 영역으로 이전
        § 트래픽 throttling
            □ 한 개의 서비스에 장애가 발생해도 전체로 번지지 않도록 조정
    ○ MSA에서 장애 최소화 방안
        § 장애 원인
            □ 코드 버그
            □ 성능 이슈
            □ 하드웨어 장애
        § 발생 시기
            □ 경험적으로 배포 직후 발생이 대부분
        § Confidence System
            □ 카나리 배포 시 카나리 서버와 나머지 다른 서버를 비교
                ® CPU, 메모리, 주문, 결제 수 등 측정 가능한 항목 값을 수집
                ® 기본 서버와 비교 -> 문제 여부를 판정
            □ 서비스 가동 시간이 획기적 증가
        § Circuit Breaker
            □ 상시 운영 중인 시스템을 모니터링 해서 복구하는 방안
            □ 특정 장애 발생 -> 서킷 브레이커에 노티
                ® 장애 발생한 노드, 서비스를 자동으로 대체
                ® Ex) 카트, 주문 버튼 -> 주문 장애 -> 주문버튼은 비활성화 처리
        § Site Reliability Engineering
            □ 장애 원인, 재발 방지 방안 활동 -> 쿠팡 서비스 안정화 기여
    ○ 쿠팡의 고려사항 for MSA
        § MSA에서 인티그레이션 테스트
            □ 서비스는 다른 서비스에 의존성을 가지고 있음
            □ 하나의 서비스 테스트를 위해 전체 서비스가 필요함
                ® 굉장히 어려운 숙제
                ® 데이터 무결성 유지 등 서비스 별 특화된 기능이 필요
            □ API Gateway
                ® 서비스는 API Gateway에만 의존성
                ® API Gateway에서 Mocking Object를 제공하면 테스트 가능
        § 다이나믹 프로퍼티
            □ 설정을 다이나믹하게 변경할 수 있어야 한다.
            □ 클라우드 환경에서 동적인 변경사항 적용은 필수


댓글 쓰기

0 댓글