학습일지/workflows

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

inspirit941 2024. 8. 2. 14:01
반응형

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

스크린샷 2024-07-30 오전 10 25 12스크린샷 2024-07-30 오전 10 26 01

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

스크린샷 2024-07-30 오전 10 26 15스크린샷 2024-07-30 오후 3 12 40

  • 목적: 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

스크린샷 2024-07-30 오후 3 16 28

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

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

스크린샷 2024-07-30 오후 3 18 30

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

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

스크린샷 2024-07-30 오후 3 18 48

여기서 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 발생.

진단

스크린샷 2024-07-30 오후 3 25 03

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

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

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

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

해결

스크린샷 2024-07-30 오후 3 25 10

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

스크린샷 2024-07-30 오후 4 07 39

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

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

ArgoCD Controller Sharding

스크린샷 2024-07-30 오후 5 19 30

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

스크린샷 2024-07-30 오후 5 26 01

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

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

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

아키텍처 구조 변경

스크린샷 2024-07-30 오후 5 29 15

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

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

스크린샷 2024-07-30 오후 5 29 21

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

Scalability Test

스크린샷 2024-07-30 오후 5 41 49

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

스크린샷 2024-07-30 오후 5 45 36

ArgoCD와 Argo Workflow의 Control plane 분리

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

github Action 도입

스크린샷 2024-07-30 오후 5 45 42

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

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

Key Takeaway

스크린샷 2024-07-30 오후 5 49 49

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

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

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

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

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

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

스크린샷 2024-07-30 오후 5 56 55

반응형
저작자표시 비영리 변경금지