day-log

Deployment를 Rollout으로 마이그레이션배포할 때마다 심박수가 올라가는 사람 있으면 손. 나만 그런 거 아닐 거다. 특히 트래픽이 몰리는 시간대에 롤아웃 눌러야 할 때는 정말 부담이다. Deployment의 기본 RollingUpdate 전략이 나쁜 건 아닌데, 문제는 "일단 다 밀리고 나면 되돌리기가 귀찮다"는 점이다. HPA에 물려 있는 상황에서 새 버전이 죽으면 롤백 중에도 오토스케일이 계속 돌아서 상황이 더 꼬인다.그래서 우리 팀은 몇 달 전부터 Argo Rollouts를 도입해서 카나리 배포로 옮기고 있다. 이 글은 도입 과정에서 배운 것과, "이건 처음에 알았으면 좋았을 텐데" 싶은 것들을 정리한 실무 가이드다.이달 말에 열리는 ArgoCon Japan 2026 세션 리스트를 훑어보..

작년 말부터 팀 내부에서 카나리 배포 도구 얘기가 계속 돌았다. 우리 서비스는 그동안 그냥 Deployment의 RollingUpdate maxSurge/maxUnavailable 조합으로만 배포해왔는데, 최근에 P99 레이턴시가 순간적으로 튀는 케이스가 반복되면서 "이거 그냥 롤링 업데이트로는 안 잡히겠다"는 얘기가 나왔다. 새 버전이 트래픽을 5%만 받아본 뒤 지표 보고 승격시키는 구조로 가야 한다는 데는 합의가 됐는데, 문제는 Argo Rollouts를 쓸지 Flagger를 쓸지였다.한 달 정도 두 도구를 실제로 스테이징에 붙여보고 최근에 결론을 냈다. 이 글은 그 과정에서 정리한 노트다. 둘 중 하나가 절대 옳다는 얘기가 아니라, 어떤 상황에서 어느 쪽이 덜 아픈지 정도의 이야기다.근본적인 접근 ..

배포 자동화는 다들 잘 해놨는데, 정작 "이 배포 잘 된 거 맞아?"를 판단하는 건 사람이 대시보드 보고 있다. 우리도 그랬다. ArgoCD가 알아서 sync까지는 해주는데, P99가 튀거나 에러율이 올라가면 누군가는 새벽에 깨서 롤백을 해야 했다.올해 초 Argo Rollouts을 본격적으로 도입했고, AnalysisTemplate으로 Prometheus 메트릭을 보고 자동 롤백까지 시키는 데까지 왔다. 이 글은 그동안 정리해둔 셋업 노트다. 처음 도입하는 팀이 보면 30분 안에 동작하는 canary는 만들 수 있게 썼다.왜 Rollout인가 (Deployment로는 안 되나)솔직히 Deployment + RollingUpdate로도 canary 비슷한 흉내는 낼 수 있다. 그런데 두 가지가 안 된다...