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 잘 할것. 환경 갖춰둘 것.