쿠팡 이커머스 앱의 CI/CD 파이프라인을 개선하다

6가지 해결책을 통해 만들어낸 CI/CD 2.0

쿠팡 엔지니어링
Coupang Engineering Blog

--

By Johnson Li

CI/CD를 표현하는 일러스트

본 포스트는 영문으로도 제공됩니다.

지속적 통합/지속적 제공(Continuous Integration/Continuous Delivery, CI/CD)을 활용하면 품질 저해 없이 제품을 효율적으로 시장에 출시할 수 있습니다. 수작업으로 이뤄지던 부수적인 일들을 줄이고 요구사항, 코드 품질, 보안 등과 같은 중요한 작업에 더 집중할 수 있게 됩니다. 이런 엔지니어링 생산성의 향상을 위해 쿠팡이 어떻게 기존 모바일 앱 CI/CD 파이프라인을 물리 머신에서 AWS EC2로 이전했는지를 이 포스트를 통해 공유드리고자 합니다.

목차

  1. 초기 CI/CD 파이프라인
  2. 초기 파이프라인의 문제점
  3. CI/CD 2.0
  4. 패밀리 서비스로 확장
  5. 프로젝트 성과
  6. 향후 계획

초기 CI/CD 파이프라인

저희는 2020년에 처음으로 쿠팡 이커머스 앱에 사용할 모바일 CI/CD 파이프라인을 설계했습니다. 기능 중심 개발(Feature-Driven Development, FDD) 방법론을 채택해, 분리된 브랜치에서 코드를 작성한 뒤 이후 메인 브랜치로 통합하는 방식으로 개발했습니다. 이러한 캡슐화(Encapsulation)를 통해 서로 다른 지역에 위치한 다수의 풀스택 팀이 신규 기능 개발을 동시에 진행할 수 있었습니다. (쿠팡의 풀스택 팀은 서로 다른 스킬셋을 가진, 서로 다른 도메인과 지역의 팀원들로 구성되어 있으며, 서로 협력하여 프론트엔드부터 백엔드까지 담당할 수 있는 팀을 말합니다.)

AWS CI/CD 파이프라인 개요
그림 2. AWS CI/CD 파이프라인 개요

초기 파이프라인에서 엔지니어는 릴리스 후보(Release Candidate, RC) 브랜치에서 복제한(Git Fork)한 개인 리포지토리의 피처 브랜치(Feature Branch)에서 코드 작업을 한 뒤 수작업으로 QA 테스트를 실행하고 코드 리뷰 및 피드백(Pull Request, PR)을 요청했습니다. 수동 통합 테스트와 코드 리뷰을 통과하면, 해당 코드는 배포(Deploy)용 프로덕션 리포지토리에 위치한 RC 브랜치에 병합(Merge)되었습니다. 이 파이프라인을 위해 맥 미니가 물리 서버로 사용되었습니다.

모바일 팀 모두 검증되고 체계화된 방식으로 업무를 완수하기 위하여 이 통합 워크플로우를 준수하였습니다. 하지만 수작업으로 진행되는 단계가 많아 이커머스 앱이 아닌 기타 서비스의 지원 용도로 확장하는데 어려움이 있었습니다.

초기 파이프라인의 문제점

매일 3천건 이상의 빌드를 수행하고 매주 신규 버전의 앱을 릴리스하는 전세계 쿠팡 엔지니어들을 지원하다보니, 파이프라인의 개선이 필요하다는 걸 깨닫는 데까지 그리 긴 시간이 걸리지 않았습니다.

프로덕션 리포지토리에서 코드를 다운로드할 때 시간이 많이 낭비되었습니다. 안드로이드와 iOS 코드가 너무나 많았고, 엔지니어들 수백명이 매일 코드베이스에서 동시 작업을 하고 있었습니다.

효율성이 낮았습니다. 저희 CI 프로세스에 과정들이 너무 많다 보니 코드의 체크아웃, 컴파일, 정적 분석, 유닛 테스트, 심지어 자동화 테스트까지도 수동으로 시작해야 했습니다. CI/CD 프로세스는 또한 디바이스 팜(Device Farm), 모니터링 시스템, A/B 테스팅 플랫폼과 더 잘 연동되어 전반적인 효율성이 향상될 필요가 있었습니다.

확장성이 좋지 않았습니다. 초기의 CI/CD는 고정된 개수의 물리 머신을 기반으로 하였기 때문에, 자동으로 작업을 확장(scaling)할 수 없었습니다.

강화된 보안 정책에 대응해야했습니다. 쿠팡의 보안 정책 강화로 저희가 해결해야 할 이슈가 다양하게 있었습니다. 가장 주요한 이슈로는 오피스의 네트워크 환경과 프로덕션 환경을 엄격히 분리하는 것이었습니다.

유지보수 비용이 높았습니다. 물리 머신의 유지보수 관련 비용이 높았습니다. 또한 엔지니어로서는, 원격 근무로 업무가 전환되면서 정기 및 긴급 현장 진단(on-site checkups)의 수행이 점점 더 어려워졌습니다.

CI/CD 2.0

2021년 초 저희는 시스템의 버전 2.0을 기획하기 시작했습니다. 시스템 업그레이드를 위해 저희가 채택한 몇 가지 핵심 방안은 다음과 같습니다.

1. 다운로드 시간 축소를 위해 Git 레퍼런스 리포지토리 사용

초기 CI 파이프라인 사용시 필요한 첫번째 단계는 특정 버전의 코드를 개인 리포지토리로 다운로드하는 것입니다. 이때 코드 볼륨 때문에 네트워크 트래픽 및 시간이 많이 걸렸고, 추후 코드의 양은 계속 증가할 수 밖에 없다는 점이 저희의 고민거리였습니다. 따라서 전체 리포지토리를 한번에 다운로드하지 않고 필요한 부분들을 하나씩 점진적으로 다운로드해 오기 위해, 각 물리 빌드 머신에 미러링된 Git 리포지토리를 생성하는 방식으로 Git 레퍼런스 리포지토리를 도입했습니다.

2. 점진적 정적 분석 도입

저희는 GitFlow를 브랜치 모델로 사용하고 있었고, 개인 리포지토리에서 개발된 코드가 풀 리퀘스트(Pull Request, PR)되었을 때 정적 코드 분석을 수행했습니다. 하지만 코드 분석을 통해 해결이 필요한 이슈가 많이 리포팅되거나 장애를 일으킬 확률이 높은 이슈(blocker)가 탐지되면, 해당 이슈들을 주어진 짧은 릴리스 간격과 코드 프리즈 기간 동안 해결하는 데 큰 어려움이 있었습니다.

엔지니어들이 개발 도중 각종 이슈를 확인 가능하게끔, 개인 리포지토리 대신 피처 개발 용도의 전용 브랜치를 서버 쪽에 만들어 사용할 수 있도록 하였습니다. 또한 Git 커밋에 의해 트리거되는 전용 멀티 브랜치(multi-branch) CI 파이프라인을 구축하였습니다. 따라서 풀 리퀘스트 전에 리포지토리의 피처 브랜치에 변경 시, 파이프라인이 자동으로 트리거되어 정적 코드 분석을 수행하고 결과를 엔지니어에게 보낼 수 있게 되었습니다.

3. 병행 작업이 가능하도록 파이프라인 구성

기존 파이프라인에는 많은 작업들이 무겁고 순차적으로 연결되어 있었습니다. 그래서 CI 파이프라인을 재구성해 다른 업무에 의존성이 없는 업무 같은 경우 병렬 실행(parallel execution)이 가능하도록 만들었습니다. 이로 인해 CI 파이프라인의 처리량과 빌드의 정확도가 증가하였으며 분석 리포트의 생성도 빨라졌습니다.

4. 확장성과 안전성을 위해 AWS로 이전

안정성, 확장성 그리고 물리 머신의 유지보수 비용을 고려해 저희는 CI/CD 파이프라인을 물리 머신에서 AWS 프로덕션 존(Production Zone)으로 이전하기로 결정하였습니다. 원래 macOS EC2를 지원하지 않던 AWS가 2020년도에 macOS 기반의 EC2 인스턴스를 출시했습니다. 그래서 저희는 2021년에 Android 및 iOS용 파이프라인 전체를 AWS로 이전하고 물리 머신의 사용을 중단할 수 있게 되었습니다.

시스템은 프로덕션 존에 배포하였습니다. 이로 인해 저희는 빠른 확장성 및 서비스 장애 조치에 대한 니즈를 해결할 수 있게 되었으며 맥미니 서버 팜에 대한 유지보수 비용을 줄이고 오피스 환경과 프로덕션 환경 사이의 통신과 관련된 보안 우려를 해소할 수 있었습니다.

쿠팡의 AWS CI/CD 파이프라인 개요를 보여주는 그림
그림 2. AWS CI/CD 파이프라인 개요

5. 모니터링 시스템 구축

AWS EC2 이전 후, 문제 예방 및 탐지를 위해 모든 빌드 에이전트를 모니터링하고 상태(Health) 체크를 실행하는 모니터링 시스템을 구축하였습니다.

저희에게는 다양한 유형의 지표가 필요했습니다. 하드웨어 지표는 CPU 사용률, IOPS, 남은 디스크 용량, 네트워크 지연시간 및 부하 등이 있었습니다. 소프트웨어 지표는 온라인/오프라인 노드 개수, 사용/미사용인 실행자(executor) 개수, 작업(job) 별 또는 작업 대기열(job queue) 별 소요 시간, 현재 대기열(queue) 크기, 작업 실패 비율 등의 여러 핵심 지표가 필요했습니다. 또한 HTTP 2xx비율(%), HTTP 4xx 비율(%), HTTP 5xx 비율(%)와 같은 지표도 필요했습니다.

이러한 지표들을 모니터링 툴에 등록해 수집하였고, 별도의 툴을 통해 수집된 지표를 시각화하고, 알림 규칙을 구성하고, 알림이 적절한 채널로 전송하기 시작했습니다. 이렇게 새롭게 구축된 모니터링 시스템을 통해 엔지니어들은 파이프라인을 모니터링하면서 필요 시 즉각적인 조치를 취할 수 있게 되었습니다.

6. 오토스케일링 적용

클라우드로 이전하니, EC2 오토 스케일링 기능을 활용해 CI 파이프라인을 필요에 따라 민첩하고 유연하게 확장할 수 있게 되었습니다. 필요에 따라 신규 빌드 에이전트를 빌드 마스터에 배포, 등록/해제할 수 있도록 컨테이너 생애 주기 훅(lifecycle hook)을 추가하였습니다.

CI 파이프라인을 위한 오토 스케일링에 대한 그림
그림 3. CI 파이프라인을 위한 오토 스케일링

스케일링할 시점을 판단하기 위해, 빌드 에이전트의 유휴(Idle) 시간 같은 데이터의 분석을 바탕으로 오토 스케일링을 제어할 수 있는 방법들을 만들어 적용하였습니다. 예를 들어, CI 시스템의 처리량은 다음과 같은 공식을 사용해 계산됩니다.

처리량 = 처리된 작업의 개수 / 시간의 단위

처리량이 임계치보다 낮으면 CI 시스템이 병목 상태에 이르러 스케일 아웃이 필요하다는 의미로 해석이 됩니다. 또한 근무 지역이 서로 다른 쿠팡 엔지니어들의 서로 다른 근무 시간대와 근무 시간이 겹치는 엔지니어 수의 증감 등과 같은 다른 요소들도 스케일링 전략에 고려하였습니다.

패밀리 서비스로 확장

쿠팡은 이커머스 플랫폼으로 시작하였지만, 음식 배달, 스트리밍 서비스 그리고 그 이상의 패밀리 서비스로 영역을 확장하고 있습니다. 모바일 CI/CD 파이프라인은 사업 영역과 비즈니스 모델이 다른 패밀리 서비스에도 적용 가능하도록 설계되었습니다. 하나의 CI/CD 파이프라인을 통해 리소스를 공유하고 확장성과 유연성을 증진하고 CI/CD의 장점을 최대한 활용하는 것이 가능합니다.

  • 코드 리포지토리: 브랜치 관리, 코드 동기화, 커밋 메시지에 동일한 표준, 방식, 규칙을 공유합니다.
  • 워크플로우: CI 파이프라인에는 개발 환경, 프로덕션 환경이 각각 분리되어 있습니다. 패밀리 서비스는 두 환경 모두 사용할 수도 있고 개발 환경만 사용할 수도 있습니다.
  • 배포: 패밀리 서비스는 각 서비스가 테넌트(tenant)로 관리되는 배포 환경을 공유합니다. 서비스들 간의 상호 작용을 줄이기 위해 각 서비스 별 분리된 오토 스케일링 그룹을 사용합니다.
  • 유틸리티: 패밀리 서비스에 설정 템플릿(configuration template)과 유틸리티를 공유해 어떤 서비스든지 CI/CD 파이프라인을 사용할 수 있게 지원합니다.

프로젝트 성과

아래는 CI/CD 2.0 출시 한달 후에 대시보스를 통한 분석한 결과입니다.

  • 18개 풀스택 팀의 협업에 소요되는 시간 5% 절약
  • 빌드 타임 45% 감소 및 정적 코드 분석에 걸리는 시간 77% 감소
  • CI 잡(job) 최대 대기시간 1시간에서 15분 미만으로 감소
  • 신규 빌드 에이전트 추가에 걸리는 시간 2시간 절약
  • 오토 스케일링으로 AWS 비용 16% 감소
  • 9x 트래픽 지원 가능
  • 2M/D 이내로 신규 프로덕트 지원 가능
  • 오피스 환경에서 프로덕션 환경에 액세스함으로 인해 발생 가능했던 보안 리스크 해소

향후 계획

모바일 CI/CD는 모바일 개발 워크플로우의 핵심적인 부분입니다. 저희가 항상 진행 중인 과제인 지속적 개선을 통해 저희는 적응하고 요구를 충족하고 성공을 지속해 나갑니다. 모바일 팀에 보다 나은 서비스를 제공하고 생산성 및 사용성 향상을 위해 저희는 다음과 같은 점들을 개선하고자 합니다.

iOS에 오토스케일링 적용

AWS로 이전했지만 macOS 빌드 에이전트의 경우 기술적 어려움으로 인해 수동으로 스케일링을 수행하고 있습니다. 현재 저희는 iOS를 대상으로 개념증명(Proof of Concept, PoC) 테스트를 진행 중입니다.

생산성 향상

모바일 CI/CD의 핵심 가치는 완전한 자동화로 팀의 생산성 및 제품 품질을 높이는 것입니다. CI/CD의 많은 부분이 자동화되었지만 아직 자동화 가능한 작업들이 남아있습니다. 비즈니스와 팀 사이즈는 언제나 확장될 수 있기 때문에 파이프라인의 효율성 향상과 병목구간 제거를 통해 엔지니어 생산성 향상을 돕고 최고 품질의 제품이 제공될 수 있도록 노력할 것입니다.

더 많은 툴의 개발

편리하고 효율적인 툴 그리고 통합된 모바일 CI/CD를 통해 엔지니어가 표준화된 프로세스와 간편화된 개발을 통해 보다 창의적인 작업에 집중할 수 있게 지원하려고 합니다. 이미 저희는 자동 코드 리뷰, 정적 분석, 점진적 정적 분석, A/B 테스트 수정 확인 등 많은 부분을 CI/CD에 구현하였습니다. 그러나 더욱 나아가서 A/B 테스트 자동 클린업, 피처 간의 코드 충돌 자동 탐지, 충돌 오류 시 A/B 테스트 강제 종료 등과 같은 툴 개발과 개선 작업을 진행할 예정입니다.

재미있게 읽으셨나요? 쿠팡은 빠르게 성장하고 있으며, 언제나 저희와 함께 성장할 재능 있는 인재들을 찾고 있습니다. 새롭고 흥분되는 기회가 필요하시다면 여기 현재 채용중인 포지션에서 원하는 정보를 찾아보세요.

--

--

쿠팡 엔지니어링
Coupang Engineering Blog

쿠팡의 엔지니어들은 매일 쿠팡 이커머스, 이츠, 플레이 서비스를 만들고 발전시켜 나갑니다. 그 과정과 결과를 이곳에 기록하고 공유합니다.