모니터링·알람
24장까지 갖춰진 myshop-api는 코드부터 배포까지 자동화됐지만, 그 동작을 보지 못하면 운영이 굴러가지 않습니다. 이번 챕터는 EKS 클러스터의 옵저버빌리티 스택을 본격적으로 얹습니다. kube-prometheus-stack으로 Prometheus · Grafana · Alertmanager를 한 번에 설치하고, ServiceMonitor / PrometheusRule로 myshop-api 메트릭과 4 golden signals 알람을 표준화하고, Loki로 로그를, CloudWatch Container Insights로 AWS 결합 메트릭과 장기 보관을 함께 잡고, severity · team 라우팅으로 Slack / PagerDuty의 on-call 흐름까지 한 사이클로 정리합니다.
24장 CI / CD 파이프라인까지 거쳐 myshop-api는 새 버전이 들어오는 흐름까지 자동화됐지만, 운영 단계의 절반은 그 동작을 관측하는 일입니다. CPU · 메모리 · 요청 latency · 에러율이 어디서 어떻게 변하는지가 보이지 않으면, 카나리 자동 promote도 불가능하고 사고 대응도 늦습니다. 이번 챕터는 옵저버빌리티 스택을 EKS 위에 본격적으로 얹는 흐름입니다.
19장 옵저버빌리티에서 다룬 표준 스택 (Prometheus + Grafana + Loki + Alertmanager)의 모델이 본 챕터에서 본격적인 EKS · AWS 결합 운영 셋업으로 이어지는 단계입니다. 19장이 메트릭 · 로그 · 트레이스의 세 결을 객체 차원에서 짚었다면, 본 챕터는 그 위에 알람 룰셋 · 라우팅 · on-call 절차의 운영 결을 추가합니다. 이번 챕터의 목표는 myshop-api의 4 golden signals 알람이 정착해 critical은 PagerDuty로 호출되고 warning은 Slack으로 통지되는 상태입니다.
두 축의 결합 — in-cluster Prometheus + 매니지드 CloudWatch #
EKS 환경의 옵저버빌리티는 보통 두 축의 결합으로 이뤄집니다.
| 축 | 책임 |
|---|---|
| In-cluster (Prometheus + Grafana + Loki) | 워크로드 메트릭, 비즈니스 메트릭, 알람, 대시보드 |
| CloudWatch (Container Insights + Logs) | AWS 관리형 메트릭, 로그 장기 보관, AWS 콘솔 통합 |
둘 중 하나만 쓰는 방식도 가능하지만, 운영 클러스터의 표준은 둘의 결합입니다. Prometheus가 운영 메트릭과 알람의 기준 소스이고, CloudWatch가 장기 보관과 AWS 자체 자원 (RDS · ALB · EBS) 메트릭의 통합 지점입니다. 21장 EKS 셋업에서 RDS의 enabled_cloudwatch_logs_exports로 PostgreSQL 로그를 CloudWatch로 보낸 결정이 본 챕터의 두 번째 축에서 자연스럽게 합류합니다.
AWS의 매니지드 Prometheus (AMP)와 매니지드 Grafana (AMG)가 in-cluster 운영 부담을 줄이는 옵션으로 자리 잡고 있지만, 본 챕터에서는 가장 흔한 in-cluster 모델을 중심으로 살펴보고, AMP로의 remote write 옵션을 함께 짚습니다.
kube-prometheus-stack — 한 번에 깔리는 표준 묶음 #
19장 옵저버빌리티 §“kube-prometheus-stack"에서 짚었던 표준 Helm 차트입니다. 한 명령에 Prometheus + Grafana + Alertmanager + kube-state-metrics + node-exporter + Prometheus Operator의 CRD가 모두 들어옵니다. 18장 CRD와 Operator의 그 Operator 모델이 본격적인 메트릭 스택으로 이어지는 단계입니다.
설치 #
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install prometheus prometheus-community/kube-prometheus-stack \
-n monitoring --create-namespace \
--values prometheus-values.yamlprometheus:
prometheusSpec:
retention: 30d
retentionSize: "50GB"
storageSpec:
volumeClaimTemplate:
spec:
storageClassName: gp3
accessModes: ["ReadWriteOnce"]
resources:
requests:
storage: 100Gi
serviceMonitorSelectorNilUsesHelmValues: false
podMonitorSelectorNilUsesHelmValues: false
ruleSelectorNilUsesHelmValues: false
additionalScrapeConfigs:
- job_name: ec2-spot-instance
ec2_sd_configs:
- region: ap-northeast-2
remoteWrite:
- url: https://aps-workspaces.ap-northeast-2.amazonaws.com/workspaces/ws-xxx/api/v1/remote_write
sigv4:
region: ap-northeast-2
grafana:
adminPassword: ""
ingress:
enabled: true
ingressClassName: alb
annotations:
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}]'
alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:...
hosts:
- grafana.myshop.example.com
persistence:
enabled: true
storageClassName: gp3
size: 10Gi
alertmanager:
alertmanagerSpec:
storage:
volumeClaimTemplate:
spec:
storageClassName: gp3
resources:
requests:
storage: 10Gi
config:
route:
receiver: default
receivers:
- name: default핵심 설정 셋을 짚습니다.
retention: 30d+storageSpec— 메트릭 30일 보관 + EBS 100GB. 30일 이상 보관하려면remoteWrite로 AMP나 Thanos에 같이 보냅니다. 9장 PV / PVC / StorageClass의 gp3 StorageClass가 본격적인 운영 PV의 출처가 됩니다.serviceMonitorSelectorNilUsesHelmValues: false— 모든 네임스페이스의 ServiceMonitor를 자동 인식합니다. myshop 네임스페이스의 ServiceMonitor가 monitoring 네임스페이스 없이도 작동합니다.remoteWrite— AWS Managed Prometheus (AMP)에 메트릭을 long-term 저장합니다. 30일 이상 분석이 필요한 경우의 옵션입니다.
Grafana의 Ingress는 22장 앱 배포 골격에서 만든 AWS Load Balancer Controller가 ALB로 풀어 줍니다 — 같은 컴포넌트가 myshop-api, ArgoCD, Grafana의 세 진입점을 모두 담당하는 모양입니다.
설치 직후 점검 #
kubectl get pods -n monitoring
kubectl get servicemonitors -A
kubectl get prometheusrules -ANAME READY STATUS RESTARTS
prometheus-grafana-xxx 3/3 Running 0
prometheus-kube-prometheus-operator-xxx 1/1 Running 0
prometheus-kube-state-metrics-xxx 1/1 Running 0
prometheus-prometheus-kube-prometheus-prometheus-0 2/2 Running 0
prometheus-prometheus-node-exporter-xxx 1/1 Running 0
alertmanager-prometheus-kube-prometheus-alertmanager-0 2/2 Running 0기본 PrometheusRule이 약 100 여 개 자동으로 들어옵니다. 노드 다운, etcd 장애, kubelet 문제 같은 K8s 자체의 알람이 그 안에 미리 정의되어 있어서, 클러스터 사고는 별도 작업 없이 바로 알람이 됩니다. 14장 RBAC / NetworkPolicy / ResourceQuota에서 다룬 정책 위반도 kube-state-metrics를 통해 자동으로 메트릭화됩니다.
myshop-api에 메트릭 노출 추가 #
표준 스택이 설치된 클러스터에 myshop-api의 메트릭을 노출하는 한 사이클입니다.
1. 애플리케이션이 /metrics를 노출
#
Prometheus 클라이언트 라이브러리가 거의 모든 언어에 있습니다. Python (FastAPI) 라면 다음 한 줄로 시작합니다.
from fastapi import FastAPI
from prometheus_fastapi_instrumentator import Instrumentator
app = FastAPI()
Instrumentator().instrument(app).expose(app)이 한 줄이 다음 메트릭을 자동으로 노출합니다.
http_requests_total{handler, method, status}— 요청 카운터http_request_duration_seconds_bucket{handler, method}— latency 히스토그램http_request_size_bytes/http_response_size_bytes— 페이로드 크기- 표준 Python runtime 메트릭 (GC, threads, memory)
도메인 메트릭 (주문 생성 카운터, 결제 성공률 등)은 그 위에 추가합니다.
from prometheus_client import Counter, Histogram
orders_created = Counter(
"myshop_orders_created_total",
"Total orders created",
["status"]
)
checkout_duration = Histogram(
"myshop_checkout_duration_seconds",
"Checkout flow duration"
)19장 §“RED · USE · 4 golden signals"에서 짚은 비즈니스 메트릭의 결이 본 챕터에서 실제 코드 한 줄로 이어지는 단계입니다.
2. ServiceMonitor 매니페스트 #
Prometheus Operator가 watch 할 ServiceMonitor를 만듭니다.
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: {{ include "myshop-api.fullname" . }}
namespace: {{ .Release.Namespace }}
labels:
app.kubernetes.io/name: myshop-api
spec:
selector:
matchLabels:
app.kubernetes.io/name: myshop-api
endpoints:
- port: http
interval: 30s
path: /metrics이 매니페스트가 적용된 순간부터 Prometheus가 30초마다 myshop-api의 모든 Pod의 /metrics를 긁어 오기 시작합니다. Grafana의 Explore에서 http_requests_total{namespace="myshop"}로 데이터가 보이면 메트릭 수집이 정상입니다. 18장의 ServiceMonitor CRD가 본격적인 메트릭 파이프라인의 한 매니페스트로 자리 잡는 모양입니다.
4 golden signals — 알람 룰셋의 골격 #
19장에서 다룬 4 golden signals (Latency / Traffic / Errors / Saturation)를 myshop-api의 PrometheusRule로 적습니다.
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: {{ include "myshop-api.fullname" . }}
namespace: {{ .Release.Namespace }}
labels:
release: prometheus
spec:
groups:
- name: myshop-api.golden-signals
interval: 30s
rules:
# Errors — 5xx 비율
- alert: MyshopApiHighErrorRate
expr: |
sum(rate(http_requests_total{app="myshop-api",status=~"5.."}[5m]))
/ sum(rate(http_requests_total{app="myshop-api"}[5m])) > 0.05
for: 5m
labels:
severity: critical
team: backend
annotations:
summary: "myshop-api 5xx rate > 5% ({{ "{{ $value | humanizePercentage }}" }})"
description: "5xx 비율이 5% 넘은 상태가 5분 이상 유지됨."
runbook_url: "https://runbooks.myshop.example.com/myshop-api-5xx"
# Latency — P95
- alert: MyshopApiHighLatencyP95
expr: |
histogram_quantile(0.95,
sum by (le) (rate(http_request_duration_seconds_bucket{app="myshop-api"}[5m]))
) > 1.0
for: 10m
labels:
severity: warning
team: backend
annotations:
summary: "myshop-api P95 latency > 1s ({{ "{{ $value | printf \"%.2f\" }}" }}s)"
# Traffic — 트래픽 급감 (downstream 장애 신호)
- alert: MyshopApiTrafficDrop
expr: |
sum(rate(http_requests_total{app="myshop-api"}[5m]))
< 0.3 * sum(rate(http_requests_total{app="myshop-api"}[5m] offset 1h))
for: 10m
labels:
severity: warning
team: backend
annotations:
summary: "myshop-api traffic 급감 (지난 1시간 대비 30% 미만)"
# Saturation — Pod 메모리 사용률
- alert: MyshopApiPodMemoryHigh
expr: |
sum by (pod) (
container_memory_working_set_bytes{namespace="myshop",pod=~"myshop-api-.*"}
) / sum by (pod) (
kube_pod_container_resource_limits{namespace="myshop",pod=~"myshop-api-.*",resource="memory"}
) > 0.85
for: 10m
labels:
severity: warning
team: backend
annotations:
summary: "myshop-api Pod memory > 85% of limit"각 룰의 핵심 패턴 셋을 짚습니다.
for기간 — 짧은 스파이크에 알람이 울리지 않도록 5~10분의 지속 시간을 요구합니다.severity라벨 —critical은 즉시 호출,warning은 다음 영업일에 검토. Alertmanager 라우팅의 키입니다.runbook_url— 알람을 받은 사람이 즉시 따라갈 수 있는 대응 절차 문서입니다. 알람 한 건 = 명확한 대응 한 가지라는 원칙을 따릅니다.
24장 CI / CD 파이프라인의 Argo Rollouts AnalysisTemplate이 본 챕터의 첫 번째 룰 (5xx 비율)과 같은 PromQL 표현식을 자동화의 입력으로 씁니다. 같은 메트릭이 사람의 알람과 코드의 promote 결정 두 곳에 동시에 쓰이는 모양이 옵저버빌리티의 운영 가치입니다.
Alertmanager 라우팅 — Slack과 PagerDuty의 분기 #
알람의 흐름은 Prometheus → Alertmanager → 채널입니다. Alertmanager가 라벨을 보고 라우팅을 결정합니다.
route:
receiver: default
group_by: ['alertname', 'team', 'namespace']
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
routes:
- matchers:
- severity = "critical"
receiver: pagerduty-backend
continue: true
routes:
- matchers:
- severity = "critical"
- team = "backend"
receiver: pagerduty-backend
- matchers:
- severity = "critical"
- team = "platform"
receiver: pagerduty-platform
- matchers:
- severity = "warning"
receiver: slack-warnings
group_wait: 1m
repeat_interval: 12h
receivers:
- name: default
slack_configs:
- api_url: ${SLACK_WEBHOOK}
channel: '#alerts'
- name: slack-warnings
slack_configs:
- api_url: ${SLACK_WEBHOOK}
channel: '#alerts-warning'
title: '{{ "{{ .GroupLabels.alertname }}" }}'
- name: pagerduty-backend
pagerduty_configs:
- service_key: ${PAGERDUTY_BACKEND_KEY}
- name: pagerduty-platform
pagerduty_configs:
- service_key: ${PAGERDUTY_PLATFORM_KEY}
inhibit_rules:
- source_matchers: [severity = "critical"]
target_matchers: [severity = "warning"]
equal: [alertname, namespace]핵심 패턴 셋입니다.
- severity 별 분기 — critical은 PagerDuty로 호출, warning은 Slack으로 통지합니다.
- team 별 분기 — 같은 critical도 backend / platform 팀 따로 호출합니다.
inhibit_rules— 같은 alertname의 critical이 울리는 동안 같은 namespace의 warning은 묶어서 무음 처리합니다. 알람 폭주 방지의 표준 패턴입니다.
비밀 (SLACK_WEBHOOK, PAGERDUTY_*)은 23장 DB 연동에서 다룬 External Secrets로 주입합니다. Secrets Manager의 myshop/${env}/alerting/* 패턴을 만들어 두면 ESO가 자동으로 K8s Secret으로 풀어 줍니다.
Loki — 로그 스택 추가 #
메트릭 외에 로그도 함께 확보하는 것이 표준입니다. 19장 옵저버빌리티 §“Loki — 가벼운 로그 스택"에서 본 모델을 그대로 적용합니다.
helm repo add grafana https://grafana.github.io/helm-charts
helm install loki grafana/loki-stack \
-n monitoring \
--set promtail.enabled=true \
--set loki.persistence.enabled=true \
--set loki.persistence.storageClassName=gp3 \
--set loki.persistence.size=100Gi설치 후 Grafana에 Loki 데이터 소스가 자동으로 추가되고, Explore에서 LogQL 쿼리가 가능해집니다.
{namespace="myshop", app="myshop-api"} |= "ERROR"sum(rate({namespace="myshop", app="myshop-api"} |= "ERROR" [5m]))장기 보관을 S3에 두려면 Loki의 storage backend를 S3로 설정합니다. 표준 운영 셋업입니다. 28장 비용 최적화에서 Loki의 S3 백엔드가 EBS 대비 비용 결을 어떻게 바꾸는지 본격적으로 짚습니다.
CloudWatch Container Insights — 두 번째 축 #
같은 EKS 클러스터에 CloudWatch Container Insights를 함께 설치하면 AWS 콘솔에서 클러스터 · 노드 · Pod · 컨테이너 메트릭을 즉시 확인할 수 있습니다. 운영 팀이 AWS 콘솔에 익숙하다면 일상 점검 부담이 줄어듭니다.
helm repo add aws-observability https://aws-observability.github.io/helm-charts
helm install amazon-cloudwatch-observability \
aws-observability/amazon-cloudwatch-observability \
-n amazon-cloudwatch --create-namespace \
--set clusterName=myshop-prod \
--set region=ap-northeast-2이 차트가 Fluent Bit을 DaemonSet으로 띄워 각 노드의 stdout / stderr를 CloudWatch Logs로 보내고, CloudWatch Agent로 메트릭도 함께 수집합니다. 8장 StatefulSet · DaemonSet · Job의 DaemonSet 패턴이 본격적인 로그 수집 에이전트의 결로 이어지는 모양입니다.
DaemonSet의 ServiceAccount가 IRSA로 CloudWatch의 PutLogEvents, PutMetricData 권한을 받습니다 — 21장의 EBS CSI IRSA 패턴과 같은 방향입니다.
Fluent Bit의 두 출구 #
Fluent Bit이 노드의 /var/log/containers/를 읽어 다음 두 곳에 라우팅하는 게 표준입니다.
컨테이너 로그
|
|-> Loki (in-cluster, 단기 검색)
`-> CloudWatch Logs (S3 export, 장기 보관)같은 로그를 두 곳에 보내는 이유는 책임이 다르기 때문입니다 — Loki는 일상 디버깅, CloudWatch는 컴플라이언스 · 감사 · 장기 분석. 비용 측면에서는 Loki만 쓰는 방식이 더 가볍지만, 규제 환경에서는 CloudWatch가 보통 함께 들어갑니다. 26장 운영 체크리스트의 감사 절차에서 CloudWatch의 로그 보관 정책이 본격적으로 이어집니다.
Grafana 대시보드 표준 #
운영 클러스터의 Grafana에 들어가는 표준 대시보드 셋을 정리합니다.
| 대시보드 | 출처 |
|---|---|
| Kubernetes / Compute Resources / Cluster | kube-prometheus-stack 기본 (ID 7249) |
| Kubernetes / Compute Resources / Namespace (Workloads) | 기본 (ID 7250) |
| Kubernetes / Compute Resources / Pod | 기본 (ID 7251) |
| Kubernetes / Networking / Cluster | 기본 (ID 7253) |
| Node Exporter / Nodes | 기본 (ID 1860) |
| myshop-api 운영 대시보드 | 자체 작성 — golden signals + 비즈니스 메트릭 |
기본 대시보드 5개는 kube-prometheus-stack이 자동으로 등록해 주므로 별도 작업 없이 바로 보입니다. 자체 대시보드 한 개만 도메인에 맞춰 만들면 일상 점검의 시야가 거의 완성됩니다.
자체 대시보드의 표준 패널 셋 #
Row 1: Latency P50 / P95 / P99
Row 2: Request rate (도메인별, status 별)
Row 3: Error rate (4xx / 5xx)
Row 4: Pod CPU / 메모리 사용률
Row 5: HPA 현재 replicas
Row 6: PgBouncer 활성 연결 / 대기 큐
Row 7: 비즈니스 메트릭 (orders/min, checkout success rate)
Row 8: 상위 ERROR 로그 (Loki)
Row 9: 최근 배포 (annotations)마지막 패널의 “최근 배포 annotations"는 Grafana에 ArgoCD 또는 GitHub Actions 이벤트를 annotation으로 주입한 것입니다. 메트릭 그래프 위에 배포 시점이 세로선으로 표시되어, **“이 latency 스파이크는 어느 배포 직후에 발생했는가”**를 한눈에 볼 수 있습니다. 24장의 CI / CD와 본 챕터의 옵저버빌리티가 한 화면에서 맞닿는 지점입니다.
on-call 흐름 — runbook과 함께 #
알람이 울리는 것 자체가 끝이 아닙니다. 받은 사람이 5분 안에 어디를 봐야 하는지 명확해야 합니다. 운영 표준 흐름입니다.
1. PagerDuty 에서 알람 본문 확인 (alertname, team, severity)
2. annotation 의 runbook_url 클릭
3. Runbook 의 "1차 점검" 섹션 따라가기 — 관련 Grafana 대시보드 / 로그 쿼리 / kubectl 명령 제시
4. 1차 대응 (스케일 업, 재시작, 트래픽 차단 등)
5. Slack 사고 채널에 상태 공유Runbook은 별도 git repo의 마크다운으로 관리하는 게 표준입니다. 알람 룰의 runbook_url이 그 repo의 한 페이지를 가리키고, 새 알람을 추가할 때 Runbook도 같이 PR로 들어옵니다. 20장 GitOps의 git 단일 소스 모델이 알람 정의에서 운영 절차 문서까지 확장되는 모양입니다. 27장 kubectl 디버깅 패턴가 책 차원에서 이 Runbook의 일부 역할을 하게 됩니다.
첫 운영 한 사이클 후 점검 #
스택을 설치하고 며칠 굴려 본 시점에서 점검할 항목들입니다.
kubectl exec -n monitoring prometheus-prometheus-kube-prometheus-prometheus-0 -c prometheus -- \
promtool tsdb analyze /prometheus/wal | head -50kubectl exec -n monitoring alertmanager-prometheus-kube-prometheus-alertmanager-0 -c alertmanager -- \
amtool alert query --alertmanager.url=http://localhost:9093kubectl exec -n monitoring loki-0 -- df -h /data운영 한 달이 지나면 카디널리티 폭증, 알람 SNR (signal-to-noise ratio) 저하, 로그 디스크 압박이 보통 한 번씩 옵니다. 이 점검을 정기 점검으로 두는 게 표준이고, 26장 운영 체크리스트의 월간 점검 절에서 본 챕터의 세 명령이 그대로 들어갑니다.
카디널리티 폭증의 함정 #
가장 흔한 운영 사고는 메트릭 라벨에 고 카디널리티 값 (사용자 ID, 요청 ID, UUID 등)이 들어가는 것입니다. 시계열 수가 폭증해 Prometheus가 OOM으로 죽거나, AMP 비용이 갑자기 수십 배가 됩니다. 라벨에는 유한한 enum 값 (status code, handler 이름, environment)만 두는 게 원칙이고, 자세한 식별자는 로그나 트레이스로 빠집니다.
연습문제 #
- 본 챕터의 kube-prometheus-stack을 dev EKS 클러스터에 설치하고, myshop-api에 ServiceMonitor + PrometheusRule 한 묶음을 적용합니다. 일부러 5xx를 한참 발생시켜
MyshopApiHighErrorRate알람이for: 5m의 지속 시간을 거쳐 발화하는 모양을 관찰합니다. Alertmanager UI에서 alert의 상태가pending에서firing으로 넘어가는 시점을 시각화하고, 24장의 Argo Rollouts AnalysisTemplate이 같은 PromQL을 어떻게 분석에 활용하는지 한 단락으로 비교합니다. - Alertmanager의 라우팅 트리를 본인 조직의 팀 구성에 맞춰 다시 설계합니다. severity (critical / warning / info) × team (backend / platform / data)의 매트릭스를 한 표로 그리고, 각 셀에 어느 채널 (PagerDuty / Slack 채널명)이 들어가는지 채웁니다.
inhibit_rules가 어떤 알람 폭주를 막을지 본인 시나리오로 두세 가지 적어 봅니다. - 메트릭 라벨에 사용자 ID가 들어가는 잘못 설계된 룰을 일부러 만들어 적용한 뒤, 카디널리티 점검 명령으로 시계열 수의 변화를 관찰합니다. Prometheus의 메모리 사용량이 어떻게 변하는지, AMP의 remote write 비용이 어떻게 폭증할 수 있는지를 28장 비용 최적화의 관점에서 한 단락으로 정리합니다.
한 줄 요약: 운영 클러스터의 옵저버빌리티는 in-cluster Prometheus + 매니지드 CloudWatch의 두 축 결합이 표준이고, kube-prometheus-stack이 Prometheus · Grafana · Alertmanager · kube-state-metrics · node-exporter의 다섯 컴포넌트를 한 명령으로 풀어 준다. ServiceMonitor + PrometheusRule로 myshop-api의 4 golden signals 알람을 적고, Alertmanager가 severity · team 라벨로 PagerDuty / Slack을 분기한다. Loki가 일상 디버깅의 로그를, CloudWatch Logs가 장기 보관 · 감사의 로그를 분담한다. 같은 메트릭이 사람의 알람과 코드의 promote 결정에 동시에 쓰이는 모양이 옵저버빌리티의 운영 가치이고, runbook_url로 알람과 대응 절차를 묶는 패턴이 on-call의 표준이다. 라벨의 고 카디널리티가 가장 흔한 운영 사고의 출처다.
다음 챕터 #
이 시점에서 myshop-api는 코드부터 배포 · 운영 · 관측까지 한 사이클이 모두 자동화된 상태입니다. 다음 챕터이자 4부의 마지막 챕터에서는 이 클러스터를 한 달, 한 분기, 한 해 단위로 안전하게 굴리는 정기 운영 사이클을 다룹니다.
26장 운영 체크리스트에서는 EKS 업그레이드, RDS 백업 · 복구, 비용 점검, 보안 점검의 표준 절차를 정리하고, 4부 (EKS 실전) 6장의 회고로 마무리합니다. 그 뒤로는 5부 (운영 · 디버깅 · 비용)의 본격 운영 결로 넘어갑니다.