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할 것.