KubeCon2024 - Mastering Argo Workflows at Scale - A Practical Guide to Scalability Excellence

https://youtu.be/grDJ3o2VLUE?si=lgxulUyVNYCDyEOS

 

 

 

발표자

• Tim Collins: Argo Maintainer 4년차
• Alec Stonsell: Argo Maintainer 6개월차

 

본인들 회사 소개

• Argo 기반 서비스 제공 / 인프라 관리해주는 곳. multi cluster serving 같은 거 쉽게 해주겠다.
• 데이터사이언스 회사에서 Argo 쓰고 있다.
  • 파이프라인 실행 -> 2주마다 5천억 개 record 발생
  • mobility pattern 탐지하는 알고리즘 수행
  • 16시간 실행되는 long process
• 문제점?
  • Unreliable / Could be faster / 뭐가 어떻게 돌아가는지 파악하기 쉽지 않았음.
• 어떻게 해결했는지를 소개하고자 함.

 

어떤 고생을 했고, 어떤 결과를 얻었는지.

• Optimal Setup 찾고, 66번의 실험과 15번의 regressors... 열심히 했다.
• Pipeline Run time 확인, reliability 확보, 비용 절감에 성공
  • 4시간 작업을 1시간으로 단축
  • 이제 일요일에 편히 잘 수 있다 - by CTO

How argo workflows works

 

요지: 단순한 workflow 생성에도 k8s API 호출이 많다.

사용자가 workflow manifest를 생성한다.

• kubectl이나 argo cli로 만들어진 yaml은 etcd에 저장됨.

workflow controller에서 k8s API 호출

• pod state 체크를 위해 지속적으로 api 호출... 규모가 커지면 noisy.
• state 변경사항을 manifest에 계속 저장.

사용자가 Ui로 접근하고 상태 확인하는 것도 전부 k8s API 호출.

Potential BreakPoint

 

Scale 시도할 때 발생할 수 있는 BreakPoint

• k8s Control Plain 과부하
• etcd 용량 부족
• argo 리소스의 용량 부족
• 작업을 실행할 k8s 노드 여유분 부족

K8s API

 

Observability: k8s API health 확인해라.

• 리소스 여유 있으면 prometheus + grafana, 없다면 workflow controller 로그

workflow controller와 k8s API 통신 빈도를 낮춰야 한다.

• backoff time을 바꿔주는 DEFAULT_REQUEUE_TIME
• workflow parallel 옵션 조정. (한 번에 최대 몇 개의 workflow를 실행할 것인지.)
  • resourceRateLimit 으로 'how many pods the workflow controller creates at each time it asks to generate using k8s api' 조정.
• k8s버전을 1.27로 올리기만 해도 성능이 세 배는 좋아진다.
• k8s cluster에 workflow 말고 다른 것도 이것저것 올려쓰는 경우가 많은데, 시끄러운 이웃 문제 생길 수 있음.

ETCD limit

 

etcd 부담을 줄여야 한다.

• parameter로 너무 큰 데이터를 넘기면 etcd에 그게 다 올라가야 함. shared disk나 artifact 사용을 권장.
• 큰 workflow 하나는 smaller workflows로 나눌 것.
• 나누는 게 쉽지 않으면, offload to a Database.

workflow controller 관련

 

디폴트로 설치하면, 컴포넌트에 resource request / limit이 없다. 설정해줘야 함.

• 최적값은 본인이 직접 찾아야 한다.
• (논쟁적인 표현이라 생각하지만) controller에 HA 설정 안하는 게 낫다.
  • HA로 controller 세 개 설정하면, leader election 성공한 한 개만 동작.
  • 이 경우, 세 개 pod가 점유하는 리소스 대비 실제 사용이 Max 33% 밖에 안 된다.
  • 10 CPU로 HA 3 pod 설정하는 것보다, 15 CPU 1 pod 설정하고 PriorityClass 써서 healthy 우선순위를 높이는 쪽이 좋다고 생각한다.
  • pod 1개 쓰고 있다면 leader election 설정 꺼둬라. api call 줄여야 함.

workflow server 관련

 

상황따라 다르지만, 1000 workflows 넘어가면 전체적으로 느려질 수 있다.

• ttlStrategy로 old workflows는 정리한다.
• dedicated log aggregation 설정하고, 로그 볼 수 있는 링크를 controller configmap에 설정해서 ui에 보여주는 걸 추천.

node & pod resource

 

리소스 사용량 체크

• 이상적인 그래프: 오른쪽 상단.
• 잘못된 그래프: 오른쪽 하단. 스케줄링 잘 해서 여러 노드로 작업 분산될 수 있도록.

request 명시해서 ensure other pod don't steal your resonse.

sidecar나 driver 같은 녀석이 불필요하게 리소스 점유하지 않게 한다.

 

퍼블릭 클라우드라면, autoscale 활성화해두는 걸 추천한다.

• 단, 노드가 연결되면 노드 사용량에 관계없이 돈 나간다. 필요없으면 노드 꺼라.

ui 대시보드에서 pod가 pending 상태면 노란색으로 표시됨.

• 노드 여유분이 없다던가... 등의 이슈. 노란색 안나오게 해야 한다

비용 줄이려면 amd64보다 ARM. argo workflow 자체는 arm으로도 잘 돈다.

• 실행할 이미지도 arm 버전으로 만들면 됨

Spot instance도 비용절감으로는 고려 대상. eviction event에 대응할 수 있게 하면 됨

 

scale horizontally / easily...

• 스레드 단위, 컨테이너, pod, node 단위의 parallel 세팅에 따라 다르다.
• 프로세스 종류 (long running? 등등...)

Observability

 

잘 만들어진 그라파나 대시보드.

• grafana.com/grafana/dashboards/20348-argo-workflows-metrics/
• Import ID: 20348

 

new metric 추가, 오래된 metric 걷어내는 작업이 v3.6에서 완료될 예정임.

• how long does workflowTemplate 'foo' take to run?
• cronWorkflow가 실행된 마지막 시간 확인
• 지난 주, 얼마나 많은 workflows가 실패했는지 확인
• pod가 pending에서 멈춘 이유
• ...

등 다양한 request에 맞는 metric이 추가될 예정이라고.

 

우리 회사에서 free plugin 만들었다.

• OTEL로 metric 수집하고 대시보드 보여주는 거 같음.

Summary

 

• Observability 확보할 것
• container lifecycle hook 쓰지 말 것. success로 표시되는데 실제 작업은 fail 표시되는 경우 있음.

---

발표영상에는 없고, 발표자료에만 있는 내용

Why is My Workflow Slow?

 

• 이미지 사이즈 줄이거나 캐싱, prefetching
• volume mount에 걸리는 시간
• 노드에 여유는 충분히 있는지?
• container registry의 Rate limit?

 

Workflow Design 관련

• startup time은 최소 30초는 걸린다고 가정하는 게 좋다.
• previous output이 필요한 작업이지만 parallelize가 어렵다면, same pod에서 실행해라 (multiple container?)
• job이 수행시간이 짧고 빠른 실행이 중요하다면, workflow 말고 다른 거 써라.
• short-lived steps은 하나의 containerSet에 포함하는 걸 권장함.

Artifact ouput이 오래 걸리는 것들

• init container의 로그 체크하면, fetch / push artifact 시간 확인할 수 있다.

resource request / limit 설정 잘해야 한다. 실행 끝난 Pod은 GC할 것.