TIL

Appearance

CH05 - 무중단 배포 ​

이 저장소는 「AI 시대에 개발자가 알아야 하는 인프라 구성 배포 with 클로드 코드」 책 스터디를 진행하며 정리한 내용을 다룹니다.

5장에서는 외부 게이트웨이를 열어서 port-forward 없이도 서비스에 접근가능게 하고, blue-green 배포로 무중단배포를 구성한다.

외부 트래픽을 클러스터 안으로 라우팅하려면 어떻게 해야할까?

Gateway API, Ingress 차이 ​

Gateway API와 Ingress 둘다 외부 트래픽을 클러스터 안으로 들어오게 하는 역할이지만 설계 방식이 다름.

  • Gateway API가 비교적 최근에 생겼음(K8s 1.28 GA)
  • Ingress는 하나의 리소스에 모든 설정이 다 들어가는 구조
    • 라우팅 규칙이 단순했기 때문에 복잡한 기능을 위해서 어노테이션으로 커버(벤더마다 달라서 이식성 낮음)

반면 Gateway API는 이 문제를 해결하기 위해 나왔다고 할 수 있음

  • 관심사 분리: LB 인프라 설정과 트래픽 라우팅 규칙이 분리됨.
  • 표준 스펙으로 고급기능을 지원하여 이식성 향상

초기 GKE 클러스터 구축 시에 --gateway-api=standard 옵션을 줬기 때문에 GKE가 GatewayClass를 클러스터에 등록하였다.

bash
k get gatewayclass
NAME                               CONTROLLER                  ACCEPTED   AGE
gke-l7-global-external-managed     networking.gke.io/gateway   True       8d
gke-l7-gxlb                        networking.gke.io/gateway   True       8d
gke-l7-regional-external-managed   networking.gke.io/gateway   True       8d
gke-l7-rilb                        networking.gke.io/gateway   True       8d

이미 설치가 된 상황이기도 하고 차후 카나리 배포 가중치 설정을 고려하여 Gateway API를 선택한다

blue-green 배포 ​

현재 배포 방식인 롤링업데이트의 문제는 새 pod로 진입가능한 상황에서 새 버전에 버그가 생기면,
일부 사용자가 이미 에러를 경험한 뒤에 조치를 할 수 있다는 것이다.

이 문제를 블루-그린 배포 방식을 통해 해결한다.

  • 구버전(Blue)와 신버전(Green)을 둘다 띄워서 그린환경에서 테스트를 마친 후 LB를 통해 트래픽을 이동한다.
  • 신 버전에서 오류가 발생하더라도 LB를 통해 블루로 전환이 가능함.
  • 고려할 점은 서버리소스를 2배로 사용한다는 것이다

이를 도와주는 도구가 Argo Rollouts 이다.

  • ArgoCD 통합 가능, ArogCD UI에서 롤아웃 상태를 확인 가능
  • CRD 기반으로 yaml로 선언형, GitOps 원칙에 부합함

blue-green 배포를 위한 작업과정은 아래와 같다.

  • Argo Rollouts Controller 설치
    • kubectl argo-rollout 플러그인 설치
      • kubectl은 플러그인시스템을 지원하여 kubeclt-xxx 라는 이름의 실행파일을 PATH로 등록하면 자동으로 kubectl xxx를 호출한다.
  • deployment -> rollout 전환
  • 프리뷰 서비스 생성

프리뷰 서비스는 그린으로 승격될 서비스를 의미한다.

rollout.yaml을 살펴보면

yaml
strategy:
  blueGreen:
    activeService: notiflex-api
    previewService: notiflex-api-preview
    autoPromotionEnabled: true # 자동 승격 설정
    autoPromotionSeconds: 30 # green 준비 후 30초 뒤 자동 승격

승격 판단은 rollout.yaml에 있는 readinessProbe 설정으로 해당 Pod가 요청을 받을 수 있는지 판단한다.

그러면 이전 게이트웨이 설정시 작성한 healthcheckpolicy.yaml는 무슨 상관이 있을까?

  • Argo Rollout 승격과는 직접 상관이 없다 헬스체크정책은 순전히 GCP LB의 전용 설정임.
  • 하지만 승격이 되도 LB가 헬스체크를 실패할 경우 트래픽을 못보냄 (외부에서 접속 시 502)
    • 해결방안으로 scaleUpDelaySeconds 설정을 추가하여 바로 승격시키지 않고 n초 동안 기다리게 한다.

의사결정 기록하기 ​

코드와 매니페스트 파일은 무엇을 했는지를 보여줄 뿐 왜 그렇게 했는지는 이력을 찾아봐야한다.
혼자 관리하는 서비스라면 상관이 없겠지만, 팀원이 나가고 새로 들어올 때마다 왜 클러스터가 지금 상태인지 항상 질문이 들어온다.

ADR(Architecture Decision Records)는 팀의 결정을 한 건씩 정리하여 팀에게 공유될 수 있는 자산을 만들게 한다.

거창한 워드파일, ppt가 필요한 것이 아니다 마크다운 파일만으로도 충분하다.

회사를 다니기 전에는 몰랐지만, 이력 관리가 얼마나 중요한지 몸소 느끼고 있다. 내가 작성한 코드도 몇 달만 지나면 기억이 흐려지는데, 남이 작성한 코드라면 오죽할까.
기능을 처음부터 만드는 것보다 더 어려운 것은 이 기능이 왜 존재하는지, 왜 지금과 같은 형태로 변경되었는지를 이해하는 일이다. 이런 변경 이력이 제대로 남아 있지 않으면 그 과정을 추적하는 데 많은 시간과 노력이 든다는 것을 실무에서 절실히 느끼고 있다.

차곡차곡 쌓인 기록은 나중 돌아보면 큰 자산이 된다