day-log

카나리 배포 도구를 다시 고를 일이 생겼다. 원래 팀에서 자체 스크립트로 트래픽을 조금씩 옮기던 방식을 쓰고 있었는데, 서비스가 늘어나면서 이런 로직을 CD 파이프라인에 직접 박아 넣는 게 한계에 왔다. "이제 진짜 프로그레시브 딜리버리 컨트롤러를 붙이자"는 결론에 도달했고, 후보는 사실상 둘이었다. Argo Rollouts와 Flagger.둘 다 CNCF 프로젝트고, 둘 다 production 레퍼런스가 충분하다. 근데 이 둘이 문제를 푸는 방식이 꽤 다르다. 한 달 정도 병렬로 굴려보고 결국 하나를 골랐는데, 그 과정에서 정리한 내용을 남겨둔다.워크로드를 대하는 태도가 다르다가장 큰 구조적 차이는 이거다. Argo Rollouts는 Deployment 리소스를 Rollout이라는 커스텀 리소스로 대체..

작년 이맘때쯤 progressive delivery를 본격적으로 도입하기로 결정했다. 그 때만 해도 우리 팀은 "둘 다 비슷한 거 아니야?"라는 분위기였고, 사실 데모만 보면 정말 비슷해 보였다. 캐너리, 블루그린, 메트릭 기반 자동 promotion. 똑같은 단어들이 양쪽 문서에 다 나온다.그래서 우리는 좀 무책임한 결정을 했다. 둘 다 써보기로 했다. 일부 서비스는 Flagger, 일부는 Argo Rollouts. 1년이 지난 지금, 한쪽으로 통일하기로 했고, 그 과정에서 알게 된 차이들을 정리해 본다.시작 환경우리 환경을 먼저 짧게 적는다. 비교는 결국 환경 의존적이라서.EKS 1.32 클러스터 두 대 (스테이지/프로덕션)서비스 메시는 Istio (ambient 아니고 sidecar)GitOps는 ..

출발점: 우리 환경ArgoCD 이미 운영 중 (2년 차)Istio 1.24, ambient mode는 일부 네임스페이스만마이크로서비스 약 80개, 일주일 배포 횟수 평균 120건옵저버빌리티는 Prometheus + Thanos + Grafana 조합이 시점에서 Flux CD를 쓰고 있었다면 Flagger를 골랐을 가능성이 높다. 두 도구 모두 기술적으로 충분하지만, 같은 진영의 도구를 모으는 게 운영 단순도 측면에서 유리하다는 게 1년 후 더 분명해졌다.매니페스트 마이그레이션 비용Flagger의 가장 강력한 매력은 "기존 Deployment를 그대로 두고 Canary CR만 추가하면 된다"는 점이다. 처음 PoC 할 때 이게 정말 좋았다. 30분 만에 한 서비스가 카나리 배포로 전환됐다. 반면 Argo ..