목차
25 장

모니터링·알람

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 모델이 본격적인 메트릭 스택으로 이어지는 단계입니다.

설치 #

kube-prometheus-stack 설치
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.yaml
prometheus-values.yaml — 핵심 부분
prometheus:
  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 -A
기대 출력
NAME                                                      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) 라면 다음 한 줄로 시작합니다.

myshop-api/main.py — Prometheus 메트릭 노출
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를 만듭니다.

charts/myshop-api/templates/servicemonitor.yaml
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로 적습니다.

charts/myshop-api/templates/prometheusrule.yaml
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가 라벨을 보고 라우팅을 결정합니다.

alertmanager.yaml — 운영 라우팅
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 — 가벼운 로그 스택"에서 본 모델을 그대로 적용합니다.

Loki + Promtail Helm 설치
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 쿼리가 가능해집니다.

myshop-api의 ERROR 로그
{namespace="myshop", app="myshop-api"} |= "ERROR"
에러율 메트릭으로 환산 (Loki -> 메트릭처럼)
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 콘솔에 익숙하다면 일상 점검 부담이 줄어듭니다.

CloudWatch Container Insights — Helm
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/를 읽어 다음 두 곳에 라우팅하는 게 표준입니다.

Fluent Bit의 두 출구
컨테이너 로그
   |
   |-> Loki (in-cluster, 단기 검색)
   `-> CloudWatch Logs (S3 export, 장기 보관)

같은 로그를 두 곳에 보내는 이유는 책임이 다르기 때문입니다 — Loki는 일상 디버깅, CloudWatch는 컴플라이언스 · 감사 · 장기 분석. 비용 측면에서는 Loki만 쓰는 방식이 더 가볍지만, 규제 환경에서는 CloudWatch가 보통 함께 들어갑니다. 26장 운영 체크리스트의 감사 절차에서 CloudWatch의 로그 보관 정책이 본격적으로 이어집니다.

Grafana 대시보드 표준 #

운영 클러스터의 Grafana에 들어가는 표준 대시보드 셋을 정리합니다.

대시보드출처
Kubernetes / Compute Resources / Clusterkube-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이 자동으로 등록해 주므로 별도 작업 없이 바로 보입니다. 자체 대시보드 한 개만 도메인에 맞춰 만들면 일상 점검의 시야가 거의 완성됩니다.

자체 대시보드의 표준 패널 셋 #

myshop-api 대시보드 — 9개 패널
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분 안에 어디를 봐야 하는지 명확해야 합니다. 운영 표준 흐름입니다.

on-call 알람 받은 직후의 표준 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의 일부 역할을 하게 됩니다.

첫 운영 한 사이클 후 점검 #

스택을 설치하고 며칠 굴려 본 시점에서 점검할 항목들입니다.

Prometheus의 시계열 수 (카디널리티 점검)
kubectl exec -n monitoring prometheus-prometheus-kube-prometheus-prometheus-0 -c prometheus -- \
  promtool tsdb analyze /prometheus/wal | head -50
알람의 발생 빈도 (한 번도 안 운 룰 / 너무 자주 우는 룰)
kubectl exec -n monitoring alertmanager-prometheus-kube-prometheus-alertmanager-0 -c alertmanager -- \
  amtool alert query --alertmanager.url=http://localhost:9093
Loki의 디스크 사용량
kubectl 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)만 두는 게 원칙이고, 자세한 식별자는 로그나 트레이스로 빠집니다.

연습문제 #

  1. 본 챕터의 kube-prometheus-stack을 dev EKS 클러스터에 설치하고, myshop-api에 ServiceMonitor + PrometheusRule 한 묶음을 적용합니다. 일부러 5xx를 한참 발생시켜 MyshopApiHighErrorRate 알람이 for: 5m의 지속 시간을 거쳐 발화하는 모양을 관찰합니다. Alertmanager UI에서 alert의 상태가 pending에서 firing으로 넘어가는 시점을 시각화하고, 24장의 Argo Rollouts AnalysisTemplate이 같은 PromQL을 어떻게 분석에 활용하는지 한 단락으로 비교합니다.
  2. Alertmanager의 라우팅 트리를 본인 조직의 팀 구성에 맞춰 다시 설계합니다. severity (critical / warning / info) × team (backend / platform / data)의 매트릭스를 한 표로 그리고, 각 셀에 어느 채널 (PagerDuty / Slack 채널명)이 들어가는지 채웁니다. inhibit_rules가 어떤 알람 폭주를 막을지 본인 시나리오로 두세 가지 적어 봅니다.
  3. 메트릭 라벨에 사용자 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부 (운영 · 디버깅 · 비용)의 본격 운영 결로 넘어갑니다.

X