KubeCon2024 - Key Takeaways from Scaling Adobe's CI/CD Solutions to Support 50K Argo Cd Apps

https://youtu.be/7yVXMCX62tY?si=N-AivSULV2dG6tjd

Adobe 사내의 GitOps CI/CD 툴 이름이 Flex.

• Source인 Git에 저장된 정보를 Target인 여러 destination에 배포하기 위한 서비스.
• ArgoCD, Argo Workflows, Argo Events, Custom Components... 등 다양한 프로덕트가 통합되어 있음.
• Template 제공, Fully Customizable CI pipeline
• Just-in-Time Provisioning.
• Advanced Deployment Strategy (Argo Rollout같은 거)
• "Single pane of glass": 모든 프로젝트 정보를 볼 수 있는 service Management tool 보유.

Architecture

• 목적: Github의 Manifest를 Target / Remote Cluster에 배포한다. (= FlexBox)
• 서비스 런칭 초기: 무엇이건 문제 없던 시절의 Honeymoon period
• Reality Check: Several Outages 발생. argoCD 앱 대략 2200개일 때 발생
  • Argo 운영경험 미숙
  • k8s Control Plane challenges
• 지금은 16.5K deployment per Month. 11,000 Argo CD 앱 관리중.

Challenge. Argo CD and Argo Workflows interaction

Argo CD와 Argo Workflows를 같은 클러스터에 배포하고 관리했을 때의 이슈

• ArgoCD App 4000개 있을 때
• 분당 Argo Workflow 실행 횟수 (workload 부하)가 늘어날수록 ArgoCD의 Sync 시간이 크게 증가함.

둘다 같은 k8s API server와 ETCD를 쓰고 있었기 때문에, 해당 컴포넌트의 성능저하가 발생하면 크게 영향을 받는다.

• 바로 위 workflows 부하 테스트 수행할 때 발생한 k8s API Server CPU 사용량.
  • 작업 수행할 때 CPU limit에 거의 근접한 수준까지 사용한다고 함.
  • ArgoCD의 read / write Latency도 크게 변동한다. Sync가 오래 걸린 이유

여기서 k8s의 ETCD default size는 2GB, 최댓값이 8GB였던 걸로 아는데 Adobe는 Max값 쓰고 있었음.

• ETCD가 꽉 차면 k8s API server가 unresponsive.
• k8s API server에 문제 생기면, argoCD와 workflows 둘다 동작을 못 한다.
• 위 예시의 경우, reconcile Ops가 끝나질 않음.

ETCD의 defragmentation 발생하면 api server의 latency에 spike 발생.

진단

• Argo Component Tuning 없이 쓰고 있음
• 모든 동작에 Shared k8s Control Plane 쓰고 있음
• 관리해야 할 ArgoCD app은 계속 늘고 있음

Managed ArgoCD 서비스 제공하는 https://akuity.io/ 와 파트너십 체결.

• scalability / stability 이슈 지원해주는 전문조직.

그럼에도 불구하고 여러 이슈가 있어서, 아키텍처를 바꾸는 식으로 대응 (Flex-in-a-box)

해결

General

• 일부 Custom Resource의 경우 K8s API 직접 쓰는 대신, Argo CD API를 사용하도록 변경
  • informer cache 사용.
• VPC의 IP space 확장

ArgoCD

• Controller의 replica 8 -> 12로 증가 (sharding)
• Reconcilation timeout을 3 -> 6 -> 9min으로 점차 증가
• app CRD에서 health status 필드 일부를 삭제. ETCD 부하 줄이기 위함.
• Repo sever의 replica 증가
• QPS 올리고, burst for k8s API client-side ratelimit
• Controller churn 줄이기 위해, resource inclusion / exclusion 변경. <- this is Big One.

Argo Workflows

• Reduce ETCD load by turning off workflow node Events.
• Archive Workflows; Reduce TTL.

Appendix에 자세한 설명 적어두었다.

Reconcilation timeout

argoCD에서 reconciliation timeout 도달하기 전에 모든 app의 reconcile을 완료해야 문제가 없는데, timeout이 짧아서 never stop하는 문제 발생.

• default는 3분이었음. 두 배로 늘렸고, Adobe의 경우 9분으로 증가. 위 그래프는 10,000 앱의 reconcilation Ops 지표임.
• 이걸 낮추면, api server 부하도 줄어드는 효과가 있다. (read / write request가 감소한 걸 볼 수 있음)

ArgoCD Controller Sharding

ArgoCD Controller에 Sharding 적용.

• replica 하나가 sync 수행하려면 35min, 10 replica면 6min.
• multi-remote cluster 방식일 경우 좀더 쉬운데, sharding in argoCD is by-cluster.

단, performance는 증가하지만 api server load는 증가한다.

• replica 1개가 요청 보내던 게 10배 늘었기 때문.

App Controller client-go QPS / Burst QPS

app Controller에서 사용하는 k8s Client의 QPS / Burst QPS를 변경한다.

• 50/100 에서 25/50으로 변경할 경우, api server load는 감소하지만 argoCD의 sync time이 증가한다.

즉 api server load를 줄이는 대신 performance를 낮추는 방법.

아키텍처 구조 변경

목적: 50,000 Argo CD 앱을 관리할 수 있을 정도.

• Recreate: 위에서 여러 시행착오를 겪으며 만들어둔 flexbox를 찍어내듯 만들어서 다른 곳에도 적용할 수 있는지.
• Redirect: 모든 앱이 flexbox 1번으로 redirect 강제되고 있는데, load balancer처럼 다른 곳에 트래픽 넘길 수 있는지
• Relocate: flexbox 1에서 관리하던 앱을 flexbox 2로 옮길 수 있는지

• Recreate: 만들면 되니까 문제 없음.
• Redirect: redirection Service 생성. 어떤 service가 어떤 flex box로 전달될지 routing하는 역할. rule은 flex admin이 생성.
• Relocate: 아주 적은 downtime으로 deployment pipeline 구축

Scalability Test

50,000 apps + 300 workflows per Minute를 5 different cluster에 분산한 예시. 즉 단일 클러스터는 10000 app + 60 workflows.

• parallel sync test.
• 가장 오래 걸린 test가 cluster 4에서 대략 24분 정도 걸림.
• 즉 50000 앱 + 300 workflow per minute 작업의 sync에 걸리는 시간은 최대 24이

cf. 단일 클러스터에 90 workflows로 부하 높이니까 control plane crushed.

• 이건 아마 single flexbox의 Vertical Scale이 필요할 것 같음.

Future

ArgoCD와 Argo Workflow의 Control plane 분리

• vCluster로 ArgoCD 배포하고, host cluster는 Argo Workflow에 사용할 듯
• ArgoCD를 vCluster로 올릴 수 있다면, single flexbox에 multiple vCluster도 가능함.
  • mlutiple ArgoCD instances per flexbox.

github Action 도입

vCluster 테스트 예시: sync 4,000 Apps

• workflows per minutes를 150까지 올려도 ArgoCD sync time은 크게 변하지 않음. (상대적으로)
• adobe에서는 가능성을 보고 있는 듯.

Key Takeaway

어떤 metric을 볼 것인지. 이걸 알게 되면

• system이 버틸 수 있는 limit 확인 가능
• knobs and controls that you're changing actually makes difference 확인 가능.

어떤 옵션이나 도구로 어떤 문제를 해결할 수 있는지 알아두기

어떤 상황에 Horizontal vs Vertical Scale 적용해야 할지 이해하기

• adobe가 어려워한 것. 처음에는 vertical scale하려 했다가, 그게 안되는 걸 깨닫고 나서 horizontal scale 가능한 아키텍처를 고안했다.

Experiment 잘 할것. 환경 갖춰둘 것.