[책 정리] 인프라 구성 · 배포 with 클로드 코드 - (2)

Chapter 3.    첫 번째 배포 파이프라인

 

배포 자동화(CI/CD) 파이프라인 만들기

 

 

Push 기반 배포의 한계

- 히스토리 관리의 어려움

- 수정 시 복원 불가

 

해결 방안

- 명령형이 아닌 선언형 관리 (쿠버네티스 철학)

- Git 저장소에서 관리되는 YAML이 단일 진실 공급원(Single Source of Truth)이 된다.

 

 

그래서 이번 장 목표는..

 

Git 저장소에 선언된 매니페스트를 기준으로

클러스터 상태를 자동으로 동기화하는 Pull 기반 GitOps 파이프라인 구축하기

 

GitOps의 핵심은

- 모든 변경은 Git commit을 통해 적용

- ArgoCD와 같은 GitOps Controller가 Git 저장소를 주기적으로 Pull하여, 클러스터 상태 동기화 (Reconciliation Loop)

- Git을 통해서 수정하지 않고 직접 수정 시, Git에 저장된 상태로 다시 자동 복원 (Self-Heal)

 

---

 

 

1. ArgoCD 설치 및 GitOps 연결

 

2. ArgoCD로 롤링 업데이트 및 롤백 수행해보기

 

기존 Notiflex API 서버에 "Version 정보 확인" 기능 추가 구현 후,

 

1. Git Push

2. 이미지 빌드 후 Artifact Registry에 Push

3. 매니페스트 이미지 태그도 변경 후 Git Push

--- 여기까지는 수동 작업.

 

4. 이후 ArgoCD가 감지하여 클러스터에 적용

5. 이미지 태그가 변경되었으므로 롤링 업데이트 수행

Deployment 필드 별 수정 사항 반영 작업 차이
변경된 필드	수행되는 작업
이미지 태그 (image)	Rolling Update (새 Pod 생성) → 헬스체크 통과 → 기존 Pod 종료, 순차 반복
replicas	Rolling Update X,  그냥 Pod을 추가 생성 또는 종료
Pod template 내부 필드 값	이미지 태그와 동일하게 Rolling Update 트리거 (template hash가 바뀌었므로)
label selector (spec.selector)	적용 거부, Deployment의 selector는 불변(immutable) 필드라 kubectl apply 에러 발생
strategy.type을 Recreate로 변경	Rolling Update가 아니라 기존 Pod 전부 종료되어 새 Pod 전부 생성. 서비스 중단 발생
namespace, name	새로운 리소스로 취급되어 기존 것과 별개로 생성됨 (기존 것은 그대로 남음)

 

3. ArgoCD 연동을 위한 CI 파이프라인 만들기 (GitHub Action)

1. Git Push

2. 이미지 빌드 후 Artifact Registry에 Push

3. 매니페스트 이미지 태그도 변경 후 Git Push

--- 수동 작업했던 1~3단계 자동화하기

 

4. 완성된 CI+CD 파이프라인 기반으로 실제 동작 마지막 테스트

이제 git push만 하면 build, deploy까지 자동으로

 

 

---

Chapter 4.    관측 가능성 한 번에 구축하기

 

배포는 했는데.. 서비스는 잘 돌아가고 있나?

 

 

 

[서비스 장애 시 "관측 가능성(Observability)" 확보를 위한 핵심 데이터 5가지]

 

1. metrics - 숫자. 상태 확인 [Prometheus, Grafana]

2. logs - 텍스트. 원인 파악 [Loki, Fluent Bit]

3. traces - 요청 흐름. 어디서 느려졌는지 추적

4. profiles - cpu, mem 사용 현황 코드 수준에서 확인

5. alerts - 문제 상황 발생 시 알림 발송 [PrometheusRule]

 

[Helm "kube-prometheus-stack" 설치 시 설치되는 주요 컴포넌트]

 

1. Prometheus - Pull 기반 데이터 수집 (default 30초). 장기 저장을 위해 Thanos 설치 (오브젝트 스토리지에 백업)

2. Grafana - 데이터 시각화 대시보드 구축. 설치 시 20개 이상의 기본 대시보드 자동 생성. PromQL 실행 결과를 보여줌

3. AlertManager - 알림 설정

4. node-exporter - 노드 하드웨어 정보 수집. 모든 노드에 있어야 하므로 Daemonset으로 배포

5. kube-state-metrics  - 쿠버네티스 상태 정보 수집

 

---

 

1. 프로메테우스 및 그라파나 설치 : 메트릭 모니터링

** 목표 - 장애 판단 기준 수립

 

Pod	역할
prometheus-kube-prometheus-kube-prome-prometheus-0 (2/2)	① Prometheus - Prometheus 본체 - notiflex-api, kubelet, node-exporter 등의 /metrics를 주기적으로 Scrape하여 TSDB(Time Series Database)에 저장 ② config-reloader - Prometheus 설정 파일 변경 감지 - Prometheus Operator가 생성한 설정(prometheus.yml)이 변경되면 Prometheus의 Reload API를 호출하여 무중단으로 설정 반영
kube-prometheus-grafana-xxx (3/3)	① Grafana - Grafana 본체 ② grafana-sc-datasources - grafana_datasource=1 라벨이 있는 ConfigMap을 감시하여 Data Source를 자동 등록 및 갱신 ③ grafana-sc-dashboard - grafana_dashboard=1 라벨이 있는 ConfigMap을 감시하여 Dashboard를 자동 등록 및 갱신 - notiflex-dashboard ConfigMap이 Grafana 재시작 없이 자동 반영된 이유
alertmanager-kube-prometheus-kube-prome-alertmanager-0 (2/2)	① Alertmanager - Prometheus가 PrometheusRule을 통해 생성한 알림을 수신 - 알림을 그룹화(Grouping), 중복 제거(Deduplication), 라우팅(Slack, Email 등) 수행 ② config-reloader - Alertmanager 설정 변경을 감지하여 무중단으로 Reload
kube-prometheus-kube-prome-operator-xxx (1/1)	Prometheus Operator - ServiceMonitor, PodMonitor, PrometheusRule, Prometheus, Alertmanager 등의 CRD를 감시 - 변경 사항을 기반으로 Prometheus/Alertmanager 설정을 자동 생성 및 관리 - servicemonitor.yaml을 Git에 커밋만 해도 Prometheus가 자동으로 메트릭을 수집하게 되는 이유
kube-prometheus-kube-state-metrics-xxx (1/1)	kube-state-metrics - Kubernetes API Server를 조회하여 오브젝트 상태를 메트릭으로 변환 - Deployment Replica 수, Pod 상태, Pod 재시작 횟수(kube_pod_container_status_restarts_total) 등의 메트릭 제공 - 대시보드의 Pod 재시작 횟수 패널에서 사용
kube-prometheus-prometheus-node-exporter-xxx (1/1)	node-exporter - 각 노드에서 CPU, 메모리, 디스크, 네트워크 등 OS·커널 수준 메트릭 수집 - DaemonSet으로 모든 노드에 배포되어 클러스터 전체 리소스 사용량을 모니터링

2. Fluent Bit 및 Loki 설치 : 로그 수집

** 목표 - 장애 원인 분석

 

Loki 란?

Grafana Labs가 만든 로그 저장·조회 시스템.

Prometheus로 메트릭(숫자)은 보고 있지만, "에러가 발생했다"는 것만 알 뿐 "어떤 에러인지"는 알 수 없다. 

로그 분석 시 kubectl logs로 직접 봐야 하고, Pod가 재시작되면 이전 로그는 사라진다 — 이 문제를 해결할 수 있는 게 Loki다.

 

Loki 동작 방식

Loki는 로그 내용을 인덱싱하지 않는다. Label만 인덱싱하고, 실제 검색은 Label 필터링으로 좁힌 뒤 grep 방식으로 훑는다.

 

Label 설정 기준

	Loki	OpenSearch
설계 목적	Kubernetes 로그 수집	범용 검색/로그 분석 엔진
인덱싱	"Label" 인덱싱	"로그 전체" 인덱싱
검색	Label 기반 + 문자열 검색	강력한 Full-text 검색
저장 비용	매우 저렴	상대적으로 높음
메모리 사용량	적음	많음 (JVM 기반)
운영 난이도	쉬움	비교적 어려움
Grafana 연동	매우 좋음	가능하지만 Loki만큼 자연스럽진 않음
대규모 분석	제한적	매우 강력

 

 

3. PrometheusRule 및 Alertmanager : 알림 설정

** 목표 - 장애 발생 시 실시간 알림 체계 구축

 

[PrometheusRule과 Grafana UI 비교]

	PrometheusRule	Grafana UI Alerting
규칙 저장 장소	YAML 파일 생성 → Git 저장소 Push	Grafana 자체 DB
변경 이력 추적	git log, git blame으로 누가 언제 왜 바꿨는지 확인 가능	흐릿함 — UI 클릭 기록은 남지 않음
리뷰 프로세스	PR로 올려서 리뷰 가능	없음 (바로 반영됨)
클러스터 재구축 시	Git에서 다시 apply하면 그대로 복원	Grafana를 새로 설치하면 규칙도 다 날아감
설정 방법	YAML 작성 (약간 손이 감)	화면 클릭 (빠르고 직관적)
생성 추가 비용	없음 (4.2 설치 시 Alertmanager 이미 포함)	없음 (Grafana 내장 기능)

 

[실무에서 자주 사용하는 알림 상황]

1. Pod 재시작 과다

2. CPU/MEM 임계치 초과

3. 5xx 에러율

4. 배포 실패

 

4. Slack으로 알림 받기

 

---

(추가 설명) 클로드 코드 '메모리'

 

결정 컨텍스트 vs 작업 컨텍스트

 

작업 컨텍스트는 클로드 코드의 메모리(MEMORY.md)에 기록

 

(추가 설명) .claude 각 경로 쓰임