[Claude] 무중단 배포(Blue/Green), 시크릿 관리, Valkey 캐시

안녕하세요. AI 시대에 개발자가 알아야 할 인프라 구성 배포 with 클로드 코드 책을 읽고 학습한 내용을 정리했습니다.

 

이전 실습을 통해 관측 가능성을 구축하면서 클러스터 안에서 무슨 일이 일어나는지 한 화면에서 볼 수 있게 되었습니다. 

 

프로메테우스는 메트릭을 수집하고 Loki는 로그를 쌓고 Alertmanager는 이상이 생기면 알려줍니다. 아직 개선할 부분이 남았습니다. 배포할 때마다 잠깐씩 서비스가 끊깁니다.

 

3장에서 구현한 Rolling Update는 Pod를 하나씩 교체하는 방식이라 '완전 중단'이라고 할만큼 오래 끊기지는 않습니다. 다만 운이 나쁜 사용자가 교체되는 그 순간 요청을 보내면 connection refused를 보게 됩니다. 더 중요한 문제가 있습니다. 새 버전에 문제가 있을 때 롤백하는 동안에도 사용자는 계속 새 버전으로 연결된다는 점입니다. 

 

여기까지 오면서 한 번도 해결하지 못한 다른 문제도 있습니다. 지금까지 Notiflex API에 접근하려면 kubectl port-forward 명령을 사용해야 했습니다. 외부 IP가 없습니다. 실제 서비스라면 도메인과 로드밸런서가 있어야하는데 아직 로컬에서만 접근 가능한 상태입니다. 

 

이를 해결하기 위해 Gateway API로 외부 진입점을 만들고 그 위에 Argo Rollouts로 Blue/Green 배포를 얹습니다. 배포 전략은 Rolling Update에서 나아가 Blue/Green으로 발전하고 뒤에 Canary로 더 나아갑니다. 이 실습을 통해 브라우저에서 외부 IP Notiflex에 접속할 수 있고 새 버전을 배포해도 사용자는 끊김을 느끼지 못합니다.

 

롤링 업데이트의 한계를 이해하고, Gateway API로 외부 트래픽을 관리합니다. Argo Rollouts와 Gateway API를 연동하여 Blue/Green 무중단 배포를 구현합니다.

 

5장. [SMB] 무중단 배포

 

스토리: 배포할 때마다 서비스가 끊긴다 → 무중단 배포

 

5.1 Rolling Update는 왜 서비스가 끊기는가

• RollingUpdate는 잘 설계된 메커니즘입니다. 새 Pod가 Ready 상태가 될 때까지 기다린 다음에야 기존 Pod를 내리고 그 사이에 서비스가 두 버전 모두에 트래픽을 분배합니다. 문제는 'Ready'와 '실제로 요청을 받을 준비가 됐다'는 항상 같지 않다는 점입니다. readinessProbe가 /health에서 200을 돌려주는 순간 Pod는 Ready가 되지만 그 직후 첫 요청이 들어올 때 커넥션 풀 초기화나 캐시 워밍업이 아직 끝나지 않았을 수 있습니다. 첫 요청 몇 개는 느리거나 5XX를 받습니다. 
• 더 큰 문제는 검증 시점입니다. Rolling Update는 배포가 시작되지마자 신규 트래픽의 일부가 곧바로 새 버전으로 갑니다. '먼저 10분 동안 새 버전을 관찰한 다음 트래픽을 보낸다'는 개념이 없습니다. 롤백을 결정할 즈음에는 사용자 일부는 이미 문제 버전을 경험한 뒤입니다.
• 롤백 자체도 빠르지 않습니다. kubectl rollout undo 명령을 썼을 때를 생각하면 이전 ReplicaSet을 다시 띄우고 새 ReplicaSet을 내리는 그 과정도 결국 또 한 번의 Rolling Update입니다. '잘못됐으니까 되돌려'라고 외친 시점부터 실제로 트래픽이 기존 버전으로 완전히 돌아오기까지 수십 초가 걸립니다. 그 사이에 문제는 계속되고 있습니다. 

Blue/Green으로 넘어가는 이유는 바로 두 가지 입니다. 

• 첫째, 새 버전을 완전히 띄운 다음 원하는 만큼 확인하고 나서 트래픽을 한번에 전환한다는 것
• 둘째, 문제 발견 시 기존 버전으로 즉시 돌려놓을 수 있다는 것

이 두가지 성질을 얻으려면 '트래픽을 어디로 보낼지'를 유연하게 바꿀 수 있어야 하고 그래서 외부 진입점부터 고쳐야 합니다.

 

 

5.2 외부 트래픽 관리: Gateway API

 

지금까지는 Kubectl port-forward 명령으로 Notiflex API에 접속했습니다. 실제 서비스라면 외부 IP가 있어야하고 Blue/Green 배포를 붙이려면 트래픽 경로를 선언적으로 바꿀 수 있는 장치가 필요합니다. 두 가지 요구를 동시에 만족시키는게 Gateway API입니다.

 

[프롬프트]

지금은 클러스터 안에서만 접근되는데 외부에서도 API를 호출하려면 어떻게 해?

 

[프롬프트]

Gateway API 설정해줘.

5.3 무중단 전환: Blue/Green 배포

도구를 Argo Rollouts로 결정했으니 Blue/Green 배포 설정을 진행합니다.

 

[프롬프트]

Blue/Green 배포 설정해줘.

 

 

v0.2.0을 배포하고 전환 과정을 살펴봅니다.

 

[프롬프트]

실제로 새 버전을 배포하면 Blue/Green이 어떻게 동작하는지 보고싶어.

 

💡 마무리: 아키텍처 결정 기록하기

5장 실습에서는 세 가지를 결정했습니다. Gateway API(Ingress 대신), Blue/Green(Canary 대신), 리전 로드밸런서(글로벌 대신). 코드와 매니페스트는 '무엇을'했는지 보여주지만 '왜'는 보여주지 않습니다. 시간이 지나거나 새 팀원이 합류하면 "왜"라는 질문이 나옵니다.

 

4장 마무리에서 작업 컨텍스트는 메모리에 적었습니다. 메모리는 이 PC에서 클로드 코드가 자동으로 쌓는 나의 기록입니다. 처음에는 혼자 작업하니 메모리만으로 충분합니다. 그러나 회사와 서비스가 성장하면서 새 팀원이 합류하고 다른 사람이 코드를 이어받기 시작하면 결정의 '왜'는 로컬 머신에 머물러서는 안됩니다. 영구 기록이자 팀의 기록이 되어야 하므로 깃 저장소 안에 두어야합니다.

 

AWS와 Azure 등 글로벌 기업에서 권장하는 패턴이 ADR(Architecture Decision Records)입니다. 팀의 결정을 한 건씩 정리해 번호스타일로 마크다운에 누적하고 같은 파일을 시간 순서대로 채워갑니다. 마크다운이라서 깃에 그대로 들어가 팀원과 공유되고 클로드 코드도 새 대화에서 이 파일을 읽어 결정 컨텍스트를 가져옵니다.

 

3장과 4장에서도 결정이 있었습니다. GitOps는 ArgoCD, CI는 깃허브 액션, 메트릭은 프로메테우스와 그라파나, 로그는 Loki로 결정했습니다. 5장에서 ADR을 처음 도입하면서 이전 장의 결정도 함께 정리합니다.

 

[프롬프트]

이번 장의 아키텍처 결정을 ADR로 기록해줘. 이전 3장과 4장에서도 결정한 것들이 있으니 함께 시간 순서로 정리해줘.

 

[프롬프트]

Ingress가 더 친숙한데 바꾸는게 나을지 의견만 알려줘. 지금 바꾸지는 말고.

 

[프롬프트]

/update-docs

 

 

6장. [전환기] Enterprise를 위한 기반 정비

5장에서 Gateway API로 외부 진입점을 만들고 Blue/Green 배포까지 완성했습니다. 배포할 때 사요자가 끊김을 느끼지 않게 되었고 문제가 생기면 즉시 롤백할 수 있습니다. 

그런데 고객이 늘면서 세 가지 문제가 드러났습니다.

첫번째, API 응답이 느려졌습니다. Pod가 2개인데 각각 독립적인 메모리에 데이터를 저장합니다. Pod A에 POST한 알림이 Pod B의 GET에서는 안보입니다. 

두번째, YAML 파일에 비밀번호가 평문으로 들어 있습니다. k8s secret은 base64 인코딩일 뿐 암호화가 아닙니다. 누구나 디코딩할 수 있습니다. 

세번째, Blue/Green 배포는 새 버전을 한번에 전환합니다. Preview에서는 잘됐는데 실제 트래픽에서 문제가 생기면 전체 고객이 영향을 받습니다.

 

대형 고객사에서 보안 감사 결과를 요청해왔습니다. 엔터프라이즈 고객을 받으려면 지금의 구조로는 부족합니다. 6장에서는 이 세 가지를 순서대로 해결합니다. 

Valkey로 Pod 간 상태를 공유하고 Google Secret Manager로 시크릿을 안전하게 관리하고 Canary 배포로 트래픽을 점진적으로 전환합니다.

 

스토리: 고객이 늘면서 느려지고, 보안도 허술하다 → 대형 고객사를 받기 전에 기반을 정비하자

Valkey 캐시로 성능을 개선하고, Google Secret Manager로 시크릿을 안전하게 관리합니다. Blue/Green에서 Canary 배포로 전환하여 더 안전한 배포 전략을 적용합니다.

6.1 Pod 간 상태 공유: Valkey 캐시

지금까지 Notiflex APIDML /id 엔드포인트는 인메모리 atomic counter로 ID를 생성했습니다. Pod가 1개일 때는 문제가 없지만, 2개 이상이면 각 Pod가 독립적인 카운터를 갖게 됩니다.

 

Pod 간 상태를 공유할 캐시 도구를 무엇으로 쓸지 클로드 코드에게 먼저 물어봅시다.

 

[프롬프트]

Pod가 여러 개인데 데이터를 어떻게 공유해?

 

[프롬프트]

Valkey 설치해줘.

6.2 시크릿 관리: Google Secret Manager

 

Valkey를 설치했고 비밀번호를 k8s secret으로 관리하고 있습니다. 그런데 K8s secret은 base64 인코딩일뿐 암호화가 앙닙니다. 대형 고객사의 보안 감사를 통과하려면 시크릿을 외부에서 안전하게 관리해야 합니다.

 

[프롬프트]

시크릿을 안전하게 관리하려면 어떻게 해?

 

[프롬프트]

Secret 관리 설정해줘.

 

6.3 점진적 배포: Canary

6장에서 Blue/Green 배포를 도입했습니다. 새 버전을 완전히 띄운 후 한번에 전환합니다. 잘 동작합니다. 하지만 대형 고객사를 서비스하게 되면, '한 번에 전환'이 부담스럽습니다. Preview에서는 잘됐는데 실제 트래픽에서 문제가 생기면 전체 고객이 영향을 받습니다.

 

Canary 배포는 새 버전에 트래픽을 조금씩 보내면서 문제가 없는지 확인합니다. 문제가 생기면 소수의 사용자만 영향을 받고 즉시 롤백됩니다.

 

[프롬프트]

Blue/Green 말고 더 안전한 배포 방법 없어? 새 버전에 트래픽을 조금씩 보내는 방법 말이야.

 

 

[프롬프트]

Canary 배포로 변경해줘.

 

💡 마무리: `claude-context/`로 현재 아키텍처 정리하기

4장에서 메모리에 작업 컨텍스트를 5장에서 ADR에 영구 결정을 기록했습니다. 6장에서는 한 가지가 더 필요합니다. 지금 시스템이 어떤 모양인지 보여주는 그림입니다.

메모리는 작업 흐름에서 떠올려야할 조각이고 ADR은 결정한 건의 이유와 트레이드오프입니다. 이 둘만으로는 '오늘 이 클러스터에서 무엇이 어디에 어떻게 연결되어 있는가'를 한 눈에 보기 어렵습니다. 회사가 SMB에서 엔터프라이즈로 넘어가는 이 시점에는 새 멤버가 합류하기 시작하고 클로드 코드도 점점 더 많은 컴포넌트를 동시에 다뤄야 합니다. 사람과 AI가 같은 그림을 보고 시작할 수 있도록 현재 아키텍처를 한 군데에 정리합니다. 이 그림을 claude-context/에 채웁니다.

 

[프롬프트]

claude-context/에 현재 아키텍처 상태를 정리해줘. 어떤 컴포넌트가 있고 어떻게 연결되어 있고 그리고 어떤 설정을 사용하는지 기록해줘.

 

[프롬프트]

/update-docs

 

6.5 6장 가드레일 살펴보기

- 6장에서는 세 서브챕터 모두 3-프롬프트 패턴을 사용합니다. 각각 캐시, 시크릿 그리고 배포전략에서 탐색, 비교 그리고 실행 단계를 거칩니다. 

- 6.2 가드레일에서 prompt-guardrails/ch6/6.2-secret.md에는 'GKE managed CSI Driver의 driver 이름은 secrets-store-gke.csi.k8s.io이다'라는 경고가 있습니다. 6.2.3에서 SecretProviderClass의 provider를 gke로 볼륨의 driver를 secrets-store-gke.csi.k8s.io로 설정한 이유가 이것입니다. 오픈소스 이름(secrets-store.csi.k8s.io, provider: gcp)을 쓰면 Pod가 시작되지 않습니다.

- 6.3에서는 'Git push를 먼저 한 후 Rollout을 삭제하라'는 순서가 가드레일에 명시되어 있습니다. ArgoCD auto-sync 환경에서 Rollout을 먼저 삭제하면 깃의 이전 버전(Blue/Green)으로 즉시 복원되어 전략 전환이 실패합니다.