복세편살 개발라이프대규모 GitOps의 갈림길: LinkedIn 자체 엔진, Meta는 Argo CD+Kargo
3줄 요약
- LinkedIn은 250개 이상의 쿠버네티스 클러스터에서 Argo CD를 걷어내고, 배포마다 독립된 파드에서 동작하는 자체 GitOps 엔진으로 옮겼습니다[2].
- Meta는 반대로 Argo CD와 Kargo를 기반으로 약 100개 클러스터용 GitOps 플랫폼을 만들어, 4시간 넘게 걸리던 일상 배포를 몇 분 수준으로 줄였습니다[1].
- 두 사례의 차이는 도구의 좋고 나쁨보다 규모와 운영 모델에서 나옵니다. LinkedIn이 짚은 managedFields 잘림과 watch 경합은 지금 Argo CD를 쓰는 팀도 바로 점검할 수 있습니다[2].
무엇이 바뀌었나
Meta: 이전에는 Terraform이 인프라 프로비저닝과 앱 배포를 모두 맡았습니다. 그래서 사소한 앱 업데이트도 긴 인프라 릴리스 절차를 따라야 했습니다[1]. 배포 경로를 함께 쓰다 보니 한 롤아웃이 멈추면 관계없는 릴리스까지 늦어졌고, 앱 상태를 확인하는 자동 헬스 체크도 없었습니다[1].
새 구조에서는 역할을 나눴습니다. 인프라는 계속 Terraform이 관리합니다. 앱은 Argo CD가 Git에 저장된 설정과 실제 상태를 맞추는 조정(reconcile)을 담당합니다. 환경 간 릴리스 승격(promotion)은 Kargo가 맡습니다[1]. 개발자는 짧은 애플리케이션 정의만 작성하고, Argo CD와 Kargo 설정은 플랫폼이 자동으로 만들어 줍니다[1]. 이 플랫폼은 15명 남짓한 팀이 여러 클라우드와 가속기 계열에 걸친 클러스터를 지원하는 환경에서 나왔고, CNCF 엔드유저 사례 공모에서 수상했습니다[1].
LinkedIn: 처음에는 클러스터마다 Argo CD 인스턴스를 하나씩 두었습니다. 클러스터 하나는 최대 5,000노드 규모입니다[2]. 규모가 커지면서 일곱 가지 문제가 드러났고, 그중 두 가지는 구조적인 문제였습니다[2].
- watch 경합: Argo CD는 리소스 종류(group-version-resource)마다 watch를 하나씩 공유합니다. 그래서 한 앱이 만든 etcd 변동이 모든 앱의 동기화를 느리게 만들 수 있습니다. 테스트에서 파드 6만 개 클러스터의 sync는 3분 이내였지만, 8만 개를 넘으면 10분 이상 걸렸습니다[2].
- managedFields 잘림: 서버 사이드 어플라이 PATCH를 쓰는 환경에서 필드 매니저가 10개를 넘으면 쿠버네티스가 managedFields를 잘라냅니다. 이렇게 되면 매니페스트에서 지운 컨테이너가 실제 파드에 오류 없이 남을 수 있었습니다[2].
이 밖에도 observedGeneration이 없어 sync·health 상태를 특정 배포와 연결할 수 없는 문제, 오래된 repo-server 캐시 때문에 의도하지 않은 리비전이 적용되는 문제가 있었습니다[2].
LinkedIn은 Flux도 검토했지만 같은 컨트롤러 방식이라 제외했습니다. 대신 엔진을 라이브러리 형태로 만들었습니다[2]. 배포마다 별도 파드에서 실행되고, 컨트롤러 상태는 공유하지 않습니다. 업데이트는 PATCH가 아니라 PUT 전체 교체로 처리하며, resourceVersion 충돌이 나면 지수 백오프로 재시도합니다[2]. 드리프트(실제 상태가 선언과 어긋나는 것)는 라이브 객체, 직전 배포 매니페스트, 새로 렌더링한 매니페스트를 비교하는 3-way diff로 잡아내고, 실제 드리프트가 있으면 배포를 실패 처리합니다[2].
운영 관점에서 볼 점
- 효과와 해석상 주의: 배포량이 3.7배 늘었는데도 배포 인프라 장애는 925건에서 63건으로 줄었습니다. 실패 감지·종료까지 걸리는 시간의 중앙값도 16.1분에서 2.45분으로 짧아졌습니다[2]. 다만 LinkedIn은 이 개선이 새 엔진만의 효과는 아니라고 밝혔습니다. 같은 기간 오케스트레이터의 오류 분류와 안정성도 좋아졌고, 성공 배포 시간의 중앙값은 두 시스템이 비슷했습니다[2].
- 업그레이드 비용: Argo CD 인스턴스를 200개 넘게 유지하다 보니 업그레이드 한 번이 몇 주짜리 프로젝트가 됐습니다[2]. Meta도 유지 부담을 줄이려고 중앙 관리형 Argo CD 서비스로 옮길 계획입니다[1].
- 보안·변경 통제: LinkedIn은 운영 환경의 파괴적 작업에 승인을 요구했기 때문에 pruning(불필요 리소스 자동 삭제)을 꺼 두었습니다. 이 설정이 managedFields 문제와 겹치면서 고아 컨테이너가 생겼습니다[2]. 새 엔진에서는 렌더링 결과에 없는 객체를 삭제 후보로 두되, 삭제 보호를 적용합니다[2].
- 가용성: LinkedIn 엔진은 내부용이며, 오픈소스 공개 계획은 언급되지 않았습니다[2]. 클러스터 애드온과 시스템 서비스에는 여전히 Argo CD를 씁니다[2].
적용해 보려면
- 필드 매니저 수 점검: 오래 유지되는 객체의 필드 매니저 수를 세어 봅니다. managedFields 잘림은 오류 없이 고아 컨테이너를 남길 수 있습니다[2].
- sync 지연과 파드 수의 상관관계 확인: 공유 클러스터에서 sync 지연이 전체 파드 수에 따라 늘어난다면 watch 경합을 의심해 볼 수 있습니다[2].
- 배포와 인프라 경로 분리: Meta처럼 Terraform 같은 인프라 도구에서 앱 배포를 떼어 내고, 앱은 Argo CD로 조정하며 승격은 Kargo로 관리하는 방식을 검토합니다[1].
- 정의 단순화: 개발자에게는 짧은 정의만 받고, 복잡한 설정은 플랫폼이 생성하도록 추상화합니다[1].
정리
LinkedIn은 자체 구축이냐 기존 도구 확장이냐는 결정이 운영 모델에 달려 있다고 결론 내렸습니다. 또 컴퓨트 규모에 맞춰 확장할 수 있게 해 준 것은 컨트롤러 튜닝이 아니라 배포 단위 격리였다고 설명합니다[2]. Uber와 Airbnb도 범용 GitOps 컨트롤러 대신 자체 배포 로직을 만든 사례로 함께 소개됐습니다[2]. 반면 Meta는 커뮤니티 도구 위에 자사 시스템을 연결하고, 레지스트리 인증과 대규모 클러스터에서의 Argo CD 성능 개선을 업스트림에 기여하는 방안을 검토하고 있습니다[1]. 대부분의 팀에게는 당장 엔진을 다시 만드는 것보다, 위에서 소개한 두 가지 점검부터 해 보는 편이 현실적인 출발점입니다.