당근마켓은 왜 배포 시스템을 만드는가? (SRE 밋업 2회)

주요 구간

• 02:00 배포 시스템의 범위와 당근의 상황
• 03:30 기존 배포 방식과 문제
• 09:30 달라진 규모와 풀어야 할 문제
• 15:00 GoCD 앞에 서버를 둔 Kontrol 구조
• 22:30 배포 완료의 정의, 게이트키퍼와 가드레일
• 32:00 비침투적 마이그레이션

기존 배포 방식이 어려워진 이유

당근마켓의 기존 배포는 CI가 Docker 이미지를 빌드해 ECR에 올리는 데서 시작했습니다. GitOps 모노레포의 서비스 디렉토리에서 이미지 태그를 바꾸면 Argo CD가 동기화하는 방식입니다. 매니페스트는 Kustomize의 base와 환경별 patch로 관리했습니다. Ruby on Rails, Go, Node.js로 만든 서비스들은 하나의 큰 클러스터에서 네임스페이스를 나눠 썼고, SRE 팀이 AWS 리소스와 Kubernetes 클러스터 전체를 관리했습니다.

서비스마다 디렉토리를 복사하면서 매니페스트가 파편화됐습니다. 필요한 설정과 복사할 때 따라온 설정을 구별하기 어려웠고, 여러 팀이 모노레포에 push하다 충돌해 CI가 실패하는 일도 잦았습니다. 새 프로젝트를 시작하려면 개발팀이 Jira 티켓을 올리고 SRE가 매번 매니페스트를 만들어 줘야 하는 방식입니다. 개발자와 SRE가 같은 저장소를 쓰다 보니 SRE의 일괄 설정 변경에도 개발자 동의나 공지가 필요했습니다.

규모도 달라졌습니다. 슬라이드 기준 엔지니어는 150명 이상, 서비스는 120개 이상이며, 4개 리전에서 클러스터 8개를 운영했습니다. 업그레이드할 때는 새 클러스터를 만들어 교체하는 멀티 클러스터 방식을 썼습니다. 이 과정에서 클러스터가 일시적으로 8개를 넘을 수 있었고, 그만큼 Argo CD 설정도 복잡해졌습니다.

Kontrol의 설계와 배포 흐름

발표자는 기존 방식을 고칠지 판단하기 전에 배포 시스템의 조건부터 세웠습니다. 배포 시스템이나 Kubernetes를 몰라도 누구나 SRE의 개입 없이 문제없이 배포할 수 있어야 했습니다. 문서 없이 쓸 만큼 편해야 한다는 조건도 포함했습니다. SRE와 개발자의 관심사를 분리해 인프라 정책을 자동으로 강제하고, SRE의 클러스터 작업이 개발자에게 주는 영향을 줄이는 것도 목표입니다. 기존 방식을 고쳐서는 이 조건을 맞추기 어렵다고 보고 Kontrol을 새로 만들었습니다.

Kontrol은 자체 서버와 UI 뒤에서 GoCD(ThoughtWorks의 오픈소스 CI/CD)를 사용합니다. 거의 모든 기능을 API로 제공한다는 점이 GoCD를 선택한 이유입니다. UI가 낡아 보였고 프로젝트 100여 개를 맡기기에 적합한지 확신하기 어려워, 처음부터 자체 서버로 감쌌습니다. 개발자에게는 Kontrol만 보이게 하고 GoCD는 나중에 교체할 가능성도 고려했습니다.

클러스터마다 설치한 GoCD 에이전트가 매니페스트를 만들고 kubectl apply를 실행합니다. 에이전트가 클러스터 안에 있으므로 Kontrol이나 GoCD가 클러스터 인증 정보를 따로 보관하지 않습니다. kubectl apply는 원하는 상태를 제출하면 끝나지만, 배포 완료는 구버전 파드가 모두 신버전으로 바뀐 시점으로 정했습니다. 이를 확인하려고 kubectl rollout status를 실행한 뒤 완료를 표시합니다. 배포를 하나의 단위로 다루면서 “어제 오후 2시에 무엇이 나갔는지"도 한 화면에서 확인할 수 있게 됐습니다.

정책을 지키게 하는 장치로는 게이트키퍼보다 가드레일을 택했습니다. 승인 절차가 많아지면 일이 느려지므로, 배포를 계속 진행하면서 정책을 벗어나지 못하게 하는 방식입니다. Kontrol이 이미지 빌드와 ECR 푸시, 태그 규칙을 맡아 개발팀은 Dockerfile만 준비하면 됩니다. IRSA의 IAM Role도 저장소에 정책 JSON을 두면 Kontrol이 SDK로 만들고 갱신합니다. 와일드카드는 금지하고 Action은 허용 목록으로 관리하며, EKS 신뢰 관계도 Kontrol이 관리합니다.

도입 결과

Kontrol은 7월 중순쯤 공개했으며, 영상 시점에는 공개 후 3개월 남짓 지났다고 합니다. 전체 프로젝트의 약 15%가 새 배포 시스템으로 넘어왔다고 합니다(자막 기준).

이전 방식은 기한을 정하지 않는 비침투적 마이그레이션으로 바꿨습니다. 새 기능을 계속 만들고 사내 행사와 슬랙으로 알려, 팀이 직접 찾아오게 하는 방식입니다.

직접 만들면서 남은 고민

발표자는 새로 만드는 일이 대개 좋은 선택은 아니어서 고민이 많았다고 말합니다. Kontrol은 기능이 부족해도 Kubernetes 배포가 가능하면 공개하고, 피드백을 받아 키우기로 했습니다. 사용 편의성과 다양한 설정 지원, 엔지니어의 편의와 SRE의 편의 사이에서 균형을 계속 고민한다고 설명합니다.

모든 프로젝트를 빠르게 옮기려던 초기 방침도 반복 작업이 많고 개발팀에 마감 부담을 주어 바꿨습니다. 이 발표는 2021년 시점의 이야기입니다. 이후의 변화는 당근 개발자 플랫폼은 어떻게 발전하고 있을까에서 이어집니다.