김신건의 로그 - 위키 / devops

[Observability] OpenTelemetry: 표준화된 trace/metric/log

koa (김신건) — Sat, 18 Jul 2026 00:00:00 GMT

정의

OpenTelemetry (OTel) = observability 의 vendor-neutral 표준. CNCF. trace + metric + log 의 SDK + protocol (OTLP) + collector. 2019 출범 (OpenTracing + OpenCensus 합병).

OTel 이전에는 회사마다 Datadog, New Relic, Jaeger, Zipkin 각각 SDK 를 붙여야 했다. OTel 은 하나의 SDK, 어떤 backend 로도 라우팅 을 가능하게 한 표준이다.

문제 상황과 동기

마이크로서비스 환경에서 하나의 요청이 수십 개 서비스를 거칠 때:

A 서비스에서 에러가 났는데 B, C, D 어디서 느려진 건지 모름
각 서비스 로그를 별도로 조회해야 하며 상관관계를 수동으로 찾아야 함
모니터링 vendor 를 바꾸면 모든 서비스 SDK 를 재작성해야 함

OTel 은 이 세 문제를 trace ID 로 연결 + vendor-neutral SDK + collector 라우팅 으로 해결한다.

3 signal

flowchart LR
    OTel[OpenTelemetry]
    OTel --> T[Trace]
    OTel --> M[Metric]
    OTel --> L[Log]
    T --> Span["Distributed span tree"]
    M --> Hist["Counter, Gauge, Histogram"]
    L --> Structured["Structured log + trace context"]

Signal	용도	질문
Trace	요청의 전체 경로 추적	”왜 이 요청이 느린가?”
Metric	수치 집계 (latency, error rate)	“지금 시스템 상태는?”
Log	이벤트 기록 (trace context 포함)	“그 시점에 정확히 무슨 일이?”

아키텍처

flowchart LR
    App["App + OTel SDK"] -->|"OTLP gRPC/HTTP"| Coll[OTel Collector]
    Coll --> Jaeger["Jaeger / Tempo"]
    Coll --> Prom["Prometheus / Mimir"]
    Coll --> Loki["Loki / ELK"]
    Coll --> DD[Datadog]
    Coll --> NR["New Relic"]

Vendor lock-in 없음. SDK 는 표준. 어떤 backend 라도 collector 가 라우팅.

Collector 의 역할

App → [Receiver] → [Processor] → [Exporter] → Backend

Receiver: OTLP, Prometheus, Jaeger 등 다양한 입력 형식 수신
Processor: batch, 필터, redact (PII 제거), attribute 추가
Exporter: 각 backend 형식으로 변환 후 전송

Trace = Span Tree

flowchart TB
    R["Root span: HTTP GET /api/order/42"]
    R --> A["Span: auth.verify (15ms)"]
    R --> B["Span: db.query orders (50ms)"]
    R --> C["Span: db.query items (40ms)"]
    R --> D["Span: payment.charge (200ms)"]
    D --> E["Span: stripe.api (180ms)"]

각 span:

{
  "traceId": "abc123...",
  "spanId": "def456",
  "parentSpanId": "xyz789",
  "name": "db.query",
  "kind": "CLIENT",
  "startTime": "...",
  "endTime": "...",
  "attributes": {
    "db.statement": "SELECT * FROM orders WHERE id=?",
    "db.system": "postgresql"
  },
  "events": [...],
  "status": { "code": "OK" }
}

Span Kind

Kind	설명	예시
`SERVER`	들어오는 요청 처리	HTTP 서버 handler
`CLIENT`	나가는 요청 생성	HTTP client call
`PRODUCER`	메시지 큐 발행	Kafka publish
`CONSUMER`	메시지 큐 소비	Kafka consume
`INTERNAL`	내부 처리	함수 내부 로직

Context Propagation (W3C)

traceparent: 00-abc123def456789...-1111222233334444-01
tracestate: vendor1=value1,vendor2=value2

모든 HTTP 호출에 traceparent 헤더. 다른 service 가 같은 trace 의 child span 생성.

traceparent 구조:

00: 버전
abc123def456789...: trace ID (16 byte hex)
1111222233334444: parent span ID (8 byte hex)
01: flags (01 = sampled)

Auto-instrumentation

# Java agent (코드 변경 없이)
java -javaagent:opentelemetry-javaagent.jar \
  -Dotel.service.name=order-service \
  -Dotel.exporter.otlp.endpoint=http://collector:4317 \
  -jar app.jar

# Python
opentelemetry-instrument --traces_exporter otlp python app.py

# Node
NODE_OPTIONS="--require @opentelemetry/auto-instrumentations-node/register" \
OTEL_SERVICE_NAME=order-service \
node app.js

코드 1 줄 변경 없이 HTTP/gRPC/DB 호출이 자동 instrumented.

자동 계측 지원 범위 (Java 기준):

HTTP/gRPC 서버 및 클라이언트
JDBC, MongoDB, Redis, Elasticsearch 등 DB
Kafka, RabbitMQ, AWS SQS 등 메시지 큐
주요 프레임워크 (Spring, Quarkus, Micronaut)

Manual Instrumentation


const tracer = trace.getTracer('my-service');

async function processOrder(orderId: string) {
  const span = tracer.startSpan('processOrder', {
    attributes: { 'order.id': orderId },
  });
  try {
    const order = await fetchOrder(orderId);
    span.setAttribute('order.total', order.total);
    await charge(order);
    span.setStatus({ code: SpanStatusCode.OK });
  } catch (e) {
    span.recordException(e);
    span.setStatus({ code: SpanStatusCode.ERROR });
    throw e;
  } finally {
    span.end();
  }
}

OTel Collector

receivers:
  otlp:
    protocols:
      grpc:
      http:
  prometheus:
    config:
      scrape_configs: [...]

processors:
  batch:
  memory_limiter:
  attributes:
    actions:
      - key: env
        value: prod
        action: insert

exporters:
  otlp/jaeger:
    endpoint: jaeger:4317
  prometheus:
    endpoint: 0.0.0.0:8889
  loki:
    endpoint: http://loki:3100/loki/api/v1/push

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch, attributes]
      exporters: [otlp/jaeger]
    metrics:
      receivers: [otlp, prometheus]
      processors: [batch]
      exporters: [prometheus]
    logs:
      receivers: [otlp]
      exporters: [loki]

Sampling

flowchart TD
    Q[Sampling 종류]
    Q --> Head["Head sampling: 요청 시작 시 결정"]
    Q --> Tail["Tail sampling: 모든 span 모은 후 결정"]
    Q --> Adaptive["Adaptive: traffic 비례"]

Head: 100% trace 보존 불가능 → 1-10%.
Tail: 에러 / 느린 trace 만 보존 → 더 의미있는 데이터.

Tail Sampling 설정 예시

processors:
  tail_sampling:
    decision_wait: 10s
    num_traces: 100000
    policies:
      - name: errors-policy
        type: status_code
        status_code: { status_codes: [ERROR] }
      - name: slow-policy
        type: latency
        latency: { threshold_ms: 500 }
      - name: low-rate-policy
        type: probabilistic
        probabilistic: { sampling_percentage: 5 }

OpenTelemetry vs Vendor

	OTel	DataDog APM	New Relic
표준	예 (CNCF)	proprietary	proprietary
Lock-in	없음	강함	강함
기능	표준 기능	advanced UI/AI	동일
가격	자체 호스팅 무료	비쌈	비쌈
추세	2026 표준	OTel 통합 진행	OTel 통합

흔한 함정

[!WARNING]

모든 trace 보존 = 비용 폭증. sampling 필수.

PII (이메일, password) 가 attribute 에 = log 노출. redact processor 필수.

Context propagation 미구현 = trace 가 service 경계에서 끊김. SDK 의 instrumentation 확인.

OTel SDK + vendor SDK 동시 사용 = 충돌. OTel only 권장.

함정 5: Collector 없이 직접 backend 전송

App → Backend 직접 전송은 구성 변경 시 모든 서비스를 재배포해야 한다. Collector 를 sidecar 또는 daemonset 으로 두면 backend 변경 시 Collector 설정만 수정하면 된다.

함정 6: Span attribute semantic convention 무시

OTel 은 db.statement, http.method, net.peer.name 같은 Semantic Conventions 를 정의한다. 이를 무시하고 임의 attribute 이름을 쓰면 backend UI 의 자동 분석 기능이 동작하지 않는다.

Shell Script: bash 기본과 실전 패턴

koa (김신건) — Thu, 16 Jul 2026 00:00:00 GMT

정의

Shell Script 는 shell (bash, zsh, sh) 커맨드를 파일로 저장하여 자동화하는 스크립트. DevOps, CI/CD, sysadmin 필수.

안전한 시작

#!/usr/bin/env bash
set -euo pipefail
IFS=$'\n\t'

-e: 명령 실패 시 즉시 종료
-u: 정의 안 된 변수 참조 시 오류
-o pipefail: pipe 안의 실패도 캐치
IFS: 안전한 word splitting (공백/탭/개행 문자만)

실행 흐름

flowchart TD
    Start["스크립트 시작"] --> Init["shebang + set -euo pipefail"]
    Init --> Parse["인자 파싱"]
    Parse --> Main["main 로직 실행"]
    Main --> Err{"오류?"}
    Err -->|"예 (exit code != 0)"| Trap["trap cleanup 실행"]
    Err -->|아니오| End["exit 0"]
    Trap --> Clean["임시 파일 제거, 로그 기록"]
    Clean --> End

변수

name="Alice"
echo "Hello, $name"
echo "Hello, ${name}"

# 기본값
echo "${port:-8080}"           # $port 없으면 8080

# 없으면 대입
: "${port:=8080}"

# 필수값 강제
echo "${API_KEY:?API_KEY is required}"

# 배열
arr=(a b c)
echo "${arr[0]}"
echo "${arr[@]}"
echo "${#arr[@]}"              # 길이

# 연관 배열 (bash 4+)
declare -A map
map["host"]="localhost"
map["port"]="5432"
echo "${map[host]}"

조건과 반복

if [[ -f "$file" ]]; then
    echo "exists"
fi

if [[ "$env" == "prod" ]]; then
    set_prod_vars
elif [[ "$env" == "dev" ]]; then
    set_dev_vars
fi

for f in *.log; do
    echo "$f"
done

while read -r line; do
    echo "$line"
done < input.txt

# C-style for
for ((i=0; i<10; i++)); do
    echo "$i"
done

파일 테스트 연산자

연산자	의미
`-f $f`	파일 존재 (regular file)
`-d $d`	디렉토리 존재
`-e $p`	경로 존재 (파일/디렉토리 모두)
`-r $f`	읽기 가능
`-z $s`	빈 문자열
`-n $s`	비어있지 않은 문자열
`$a -lt $b`	정수 비교 (less than)

함수

greet() {
    local name="$1"
    echo "Hello, $name"
}

greet "World"

# exit code 로 불리언 역할
is_healthy() {
    curl -sf "http://localhost:8080/health" > /dev/null
}

if is_healthy; then
    echo "서비스 정상"
fi

에러 처리

trap 'cleanup' EXIT ERR INT TERM

cleanup() {
    local exit_code=$?
    rm -f "$temp_file"
    exit "$exit_code"
}

# 특정 명령 실패 허용
some_command || true

# 실패 시 대안 실행
some_command || fallback_command

# 에러 위치 기록 (디버그용)
set -E
trap 'echo "Error at line $LINENO in ${FUNCNAME[0]}"' ERR

파일과 경로

# 스크립트 자신의 디렉토리
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"

# 임시 파일 (자동 정리)
temp_file="$(mktemp)"
trap 'rm -f "$temp_file"' EXIT

# 경로 분리 (순수 bash, dirname/basename 없이)
path="/var/log/app/error.log"
filename="${path##*/}"          # error.log
extension="${filename##*.}"     # log
basename_no_ext="${filename%.*}" # error
dir="${path%/*}"                # /var/log/app

텍스트 처리

# grep: 패턴 검색
grep -E "^ERROR" app.log
grep -c "pattern" file          # 매칭 줄 수
grep -n "error" file            # 줄 번호 포함

# awk: 필드 파싱
awk '{print $1}' file           # 첫 번째 필드 (공백 구분)
awk -F: '{print $1}' /etc/passwd # 콜론 구분자

# awk 집계
awk '{sum += $1} END {print sum}' numbers.txt
awk 'NR==5' file                # 5번째 줄

# sed: 치환
sed 's/foo/bar/g' file          # 모든 foo -> bar
sed -i 's/foo/bar/g' file       # in-place 수정
sed '/^#/d' file                # # 로 시작하는 줄 삭제
sed -n '10,20p' file            # 10-20번째 줄 출력

# 파이프 조합: 상위 10 에러 유형
grep "ERROR" app.log \
    | awk '{print $NF}' \
    | sort \
    | uniq -c \
    | sort -rn \
    | head -10

stdin/stdout 처리

cat file.txt | grep pattern | wc -l
grep pattern < file.txt
grep pattern file.txt > out.txt 2>&1

# 표준 에러만 버림
command 2>/dev/null

# 표준 에러를 표준 출력으로
command 2>&1 | tee output.log

# heredoc (멀티라인 입력)
cat <<'EOF'
line 1
line 2
EOF

# process substitution (subshell 없이 while read)
while read -r line; do
    echo "$line"
done < <(some_command)

병렬 실행

# & 로 백그라운드, wait 로 완료 대기
for host in host1 host2 host3; do
    ssh "$host" "uptime" &
done
wait

# 개별 pid 추적 + 실패 감지
pids=()
for item in "${items[@]}"; do
    process_item "$item" &
    pids+=($!)
done
for pid in "${pids[@]}"; do
    wait "$pid" || echo "pid $pid failed"
done

# xargs -P (병렬 프로세스 수 지정)
find . -name "*.csv" | xargs -P 4 -I{} process.sh {}

로깅 패턴

LOG_FILE="script-$(date +%Y%m%d-%H%M%S).log"

log_info()  { echo "[$(date +%T)] INFO  $*" | tee -a "$LOG_FILE"; }
log_warn()  { echo "[$(date +%T)] WARN  $*" | tee -a "$LOG_FILE" >&2; }
log_error() { echo "[$(date +%T)] ERROR $*" | tee -a "$LOG_FILE" >&2; }

# 컬러 (터미널)
RED='\033[0;31m'
GREEN='\033[0;32m'
NC='\033[0m'
echo -e "${GREEN}Success${NC}"
echo -e "${RED}Failed${NC}"

인자 파싱

while getopts "hi:o:v" opt; do
    case $opt in
        h) echo "usage: script.sh [-i input] [-o output] [-v]" ; exit 0 ;;
        i) input="$OPTARG" ;;
        o) output="$OPTARG" ;;
        v) verbose=1 ;;
        *) exit 1 ;;
    esac
done
shift $((OPTIND - 1))
# 나머지 positional args: "$@"

실전 패턴: 배포 스크립트

#!/usr/bin/env bash
set -euo pipefail

readonly ENV="${1:?ENV required (prod|staging)}"
readonly DEPLOY_LOG="deploy-$(date +%Y%m%d-%H%M%S).log"
temp_dir=""

log()     { echo "[$(date +%T)] $*" | tee -a "$DEPLOY_LOG"; }
cleanup() { [[ -n "$temp_dir" ]] && rm -rf "$temp_dir"; }
trap cleanup EXIT

deploy() {
    temp_dir="$(mktemp -d)"

    log "Pulling latest image..."
    docker pull "myapp:latest"

    log "Stopping old container..."
    docker stop myapp 2>/dev/null || true
    docker rm   myapp 2>/dev/null || true

    log "Starting container (ENV=$ENV)..."
    docker run -d \
        --name myapp \
        --env-file "/config/$ENV.env" \
        -p 8080:8080 \
        "myapp:latest"

    log "Health check..."
    local max=30
    for i in $(seq 1 "$max"); do
        if curl -sf "http://localhost:8080/health" > /dev/null; then
            log "Health OK after ${i}s"
            return 0
        fi
        sleep 1
    done
    log "Health check FAILED after ${max}s"
    return 1
}

deploy

함정

[!WARNING]

quoting: $var 는 항상 "$var" 로 감싸야 공백 처리 안전. 배열은 "${arr[@]}" (원소별 개별 인자).

[ vs [[: bash 는 [[ 가 안전 (short-circuit, no word splitting). [ 는 POSIX sh 용.

backtick vs $(): $( ) 가 nesting 가능, 가독성 좋음. backtick 안에서 백슬래시 규칙이 달라 혼동 유발.

subshell: ( ) 안에서 변경한 변수는 밖에 반영 안 됨. 파이프도 같은 문제 (while read < <(...) 로 해결).

set -e 와 if 조건: 0이 아닌 exit code 를 반환하는 함수가 if/while 조건이나 ||/&& 뒤에 있으면 -e 가 반응 안 함. 명시적 처리 필요.

[!CAUTION] rm -rf "$dir/" 에서 $dir 이 빈 문자열이면 루트 삭제. 반드시 [ -z "$dir" ] 빈 문자열 검사 후 실행.

[GitOps] 패턴: 단일 vs 다중 repo, environment promotion

koa (김신건) — Wed, 15 Jul 2026 00:00:00 GMT

정의

GitOps = Git 을 single source of truth 로 삼아 자동으로 인프라 + 앱 상태를 reconcile 하는 운영 방식.

GitOps 4가지 원칙 (OpenGitOps)

Declarative: 시스템 원하는 상태 가 선언적 (YAML).
Versioned and Immutable: Git 으로 버전 + 불변.
Pulled Automatically: 시스템이 자동 fetch + apply.
Continuously Reconciled: 지속적 desired vs actual 비교 + 수정.

Push vs Pull 모델

flowchart LR
    subgraph "Push-based (전통 CI/CD)"
        CI1[CI] -->|"kubectl apply (cluster 접근 필요)"| Cluster1[K8s Cluster]
    end
    subgraph "Pull-based (GitOps)"
        CI2[CI] -->|"이미지 빌드 + manifest 업데이트"| Git[Git Manifest Repo]
        Agent["ArgoCD / Flux (cluster 내부)"] -->|"pull + apply"| Cluster2[K8s Cluster]
        Git -->|"감시"| Agent
    end

항목	Push-based	Pull-based (GitOps)
Cluster 접근	CI 서버가 직접 접근	에이전트가 내부에서 pull
보안	CI 에 cluster 권한 노출	cluster 권한 외부 노출 없음
자동 복구	없음	drift 감지 + 자동 복구
감사 (audit)	CI history	Git log (PR + 리뷰)
다중 cluster	복잡	에이전트 배포만으로 확장

Repo 구조 패턴

flowchart TD
    Q{"Repo 구조 선택"}
    Q --> Mono["Monorepo (app + manifest 함께)"]
    Q --> Two["2-repo (app / manifest 분리, 권장)"]
    Q --> Multi["Multi-repo (앱별 + 인프라별 분리)"]

1. Monorepo (app + manifest)

my-repo/
├── src/          (app code)
├── k8s/          (manifest)
│   ├── base/
│   └── overlays/
│       ├── dev/
│       └── prod/
└── .github/workflows/
    └── build.yml

장점: 단순. 단점: app PR 이 인프라 변경 동시 일으킴 → 위험.

2. 2-repo (권장)

app-repo/
├── src/
└── .github/workflows/
    └── build.yml  # 이미지 빌드 → registry push

manifest-repo/
├── apps/
│   └── web/
│       ├── base/
│       │   ├── deployment.yaml
│       │   └── kustomization.yaml
│       └── overlays/
│           ├── dev/
│           │   └── kustomization.yaml  # image tag dev
│           └── prod/
│               └── kustomization.yaml  # image tag prod
└── argocd/
    └── applications.yaml

CI 가 새 image → manifest repo 의 image tag 자동 update → ArgoCD 가 cluster 동기화.

CI/CD 통합 흐름

sequenceDiagram
    participant Dev
    participant AppRepo as App Repo
    participant CI as GitHub Actions
    participant Reg as Container Registry
    participant ManRepo as Manifest Repo
    participant Argo as ArgoCD

    Dev->>AppRepo: feature PR merge
    AppRepo->>CI: push trigger
    CI->>CI: test + build
    CI->>Reg: docker push myapp:abc123
    CI->>ManRepo: PR (image tag abc123)
    Dev->>ManRepo: PR review + merge
    ManRepo->>Argo: webhook (또는 polling)
    Argo->>Argo: manifest diff
    Argo->>Argo: kubectl apply

# GitHub Actions: build.yml
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build and push
        run: |
          docker buildx build \
            --platform linux/amd64,linux/arm64 \
            -t ghcr.io/myorg/myapp:${{ github.sha }} \
            --push .
      - name: Update manifest
        run: |
          git clone https://x-token:${{ secrets.MANIFEST_TOKEN }}@github.com/myorg/manifests
          cd manifests
          # yq 로 image tag 업데이트
          yq e '.images[0].newTag = "${{ github.sha }}"' \
            -i apps/web/overlays/prod/kustomization.yaml
          git commit -am "chore: update web image to ${{ github.sha }}"
          git push

Environment Promotion

flowchart LR
    Dev["dev branch"] -->|"PR merge"| Stage["staging branch"]
    Stage -->|"PR merge (manual approval)"| Prod["prod branch"]
    ArgoDev["ArgoCD: dev cluster"] -.->|"watch"| Dev
    ArgoStage["ArgoCD: stage cluster"] -.->|"watch"| Stage
    ArgoProd["ArgoCD: prod cluster"] -.->|"watch"| Prod

또는 디렉토리 분리 (Kustomize overlay):

manifests/
├── base/
│   ├── deployment.yaml    # 공통 설정
│   └── kustomization.yaml
└── overlays/
    ├── dev/
    │   ├── kustomization.yaml  # replica: 1, image: dev-tag
    │   └── patch-resources.yaml
    ├── staging/
    │   └── kustomization.yaml  # replica: 2
    └── prod/
        ├── kustomization.yaml  # replica: 5, HPA
        └── patch-hpa.yaml

# overlays/prod/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ../../base
images:
  - name: myapp
    newName: ghcr.io/myorg/myapp
    newTag: abc123sha
patches:
  - path: patch-hpa.yaml

Image Updater

flowchart LR
    CI -->|push| Registry[("Container Registry")]
    Updater["ArgoCD Image Updater\n(또는 Renovate)"] -.->|poll| Registry
    Updater -->|"PR / direct commit"| Manifest["manifest repo"]
    Argo -->|sync| Cluster

도구	방식	특징
ArgoCD Image Updater	tag 정책 기반 자동 commit	ArgoCD 통합
Renovate	dependency PR	광범위한 ecosystem
Flux Image Automation	Flux 내장	Flux 전용
Keel	자동 deploy	webhook 기반

# ArgoCD Image Updater annotation
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  annotations:
    argocd-image-updater.argoproj.io/image-list: myapp=ghcr.io/myorg/myapp
    argocd-image-updater.argoproj.io/myapp.update-strategy: semver
    argocd-image-updater.argoproj.io/myapp.allow-tags: regexp:^v[0-9]+\.[0-9]+\.[0-9]+$

Secret 처리 (git 안전)

flowchart TD
    Q["Secret 처리 방법"]
    Q --> Sealed["Sealed Secrets\n(kubeseal, cluster 내 복호화)"]
    Q --> ESO["External Secrets Operator\n(AWS SM, GCP SM, Vault)"]
    Q --> SOPS["SOPS + KMS\n(AGE / AWS KMS 암호화)"]
    Q --> Vault["Vault Agent Injector / CSI"]

# Sealed Secrets 예시
kubeseal --fetch-cert > pub-cert.pem
kubectl create secret generic db-pass \
  --from-literal=password=mysecret --dry-run=client -o yaml \
  | kubeseal --cert pub-cert.pem > sealed-secret.yaml
# sealed-secret.yaml 을 git 에 commit 가능

# External Secrets Operator
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: db-password
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-ssm
    kind: ClusterSecretStore
  target:
    name: db-password
  data:
    - secretKey: password
      remoteRef:
        key: /prod/db/password

ArgoCD vs Flux

항목	ArgoCD	Flux
UI	강력	Weave GitOps UI 별도
학습 곡선	중간	낮음
설치 방식	`kubectl apply`	Flux CLI (`flux bootstrap`)
Multi-tenancy	강 (Project 개념)	보통
Image automation	별도 Image Updater	내장
Notification	built-in	Alertmanager 통합
OCI artifact	지원	지원
인기	2026 기준 더 인기	단순함 선호

Multi-cluster GitOps

flowchart LR
    Git["Manifest repo"]
    Git -->|watch| Argo1["ArgoCD (cluster-dev)"]
    Git -->|watch| Argo2["ArgoCD (cluster-prod-us)"]
    Git -->|watch| Argo3["ArgoCD (cluster-prod-eu)"]
    Argo1 --> ClusterDev["Dev Cluster"]
    Argo2 --> ProdUS["Prod US"]
    Argo3 --> ProdEU["Prod EU"]

또는 중앙 ArgoCD + 다중 cluster credential:

# ArgoCD Application: 다른 cluster 배포
spec:
  destination:
    server: https://k8s.prod-us.example.com   # 외부 cluster
    namespace: web

Drift Detection

상황	ArgoCD 동작
수동 `kubectl edit`	Out of Sync 표시 + selfHeal 시 자동 복구
Git update	Sync 트리거 (webhook 또는 3분 polling)
Image tag 변경	Image Updater 가 manifest commit
CRD 삭제	Sync 오류 (finalizer 남음)

흔한 함정

[!WARNING]

수동 hotfix = git 우회. cluster 상태 ArgoCD 가 revert. 항상 git PR.

Branch 정책 부재 = main 직접 push. branch protection + PR 리뷰 필수.

모든 cluster 같은 manifest = 환경별 차이 못 표현. Kustomize overlay / Helm values.

Secret 평문 git commit = 히스토리 영구 노출. SOPS / Sealed Secrets / ESO.

거대한 단일 PR = ArgoCD 가 한 번에 대량 변경 적용. 작은 PR + canary 배포.

Webhook 미설정 = 3분 polling 지연. GitHub webhook 설정 권장.

[Observability] SLI / SLO / SLA / Error Budget

koa (김신건) — Wed, 15 Jul 2026 00:00:00 GMT

정의

	의미
SLI (Indicator)	측정 값 (예: 5xx 비율)
SLO (Objective)	목표 (예: 99.9% 가용성)
SLA (Agreement)	계약 (위반 시 환불 / 페널티)
Error Budget	허용 가능한 실패 양 (SLO 에서 파생)

SRE 와 SLO 의 관계

SRE (Site Reliability Engineering) = Google 이 2003년 시작한 신뢰성 엔지니어링 방법론. SLO + Error Budget 을 신뢰성과 개발 속도의 균형 메커니즘 으로 활용.

flowchart LR
    Reliability["신뢰성 향상"]
    Feature["기능 개발 속도"]
    Budget["Error Budget"]

    Budget -->|"남아 있으면"| Feature
    Budget -->|"소진되면"| Reliability
    Reliability -.->|"재충전"| Budget

SLO + Error Budget = 개발팀과 운영팀의 공통 언어. “서비스가 얼마나 안정적이어야 하는가?”

관계도

flowchart LR
    SLI["SLI 측정\n#quot;5xx rate = 0.02%#quot;"]
    SLO["SLO 목표\n#quot;5xx < 0.1%#quot;"]
    SLA["SLA 계약\n#quot;가용성 99.9%, 미만 시 10% 환불#quot;"]
    EB["Error Budget\n#quot;30일 중 43.2분 다운 OK#quot;"]
    SLI --> Compare{비교}
    SLO --> Compare
    Compare --> EB
    EB -->|"SLO margin 확보"| SLA

내부 SLO 는 SLA 보다 엄격하게 (margin). SLA 99.9% → 내부 SLO 99.95%.

좋은 SLI 4 카테고리

카테고리	예시 SLI	측정 방식
Availability	성공 응답 비율	`sum(rate(2xx+3xx)) / sum(rate(all))`
Latency	p95, p99 응답 시간	`histogram_quantile(0.95, ...)`
Throughput	처리량 (req/s)	`rate(requests_total[5m])`
Correctness	올바른 응답 비율	비교 / sampling

Google SRE: user-facing 측면 → 서버 CPU 같은 내부 metric 보다 사용자 경험 중심.

서비스 유형별 SLI

서비스 타입	주요 SLI
Request / Response (API)	Availability, Latency
Data Processing (batch)	Freshness, Correctness, Coverage
Storage	Durability, Availability, Latency
Pub/Sub (비동기)	Freshness (지연), Correctness

CUJ (Critical User Journey)

SLI 는 사용자 관점 의 여정 (CUJ) 기준으로 정의:

CUJ 예시: "사용자가 상품 검색 → 장바구니 → 결제"

SLI 1: 검색 API p95 < 300ms
SLI 2: 결제 성공률 > 99.99%
SLI 3: 장바구니 API availability > 99.9%

CPU 사용률, 메모리 같은 인프라 metric 이 아닌 사용자가 느끼는 것.

SLO 설정 예시

가용성 SLI = 성공_응답 / 총_응답
SLO = 30일 중 99.9% 이상

Error Budget = 30일 × 24h × 60min × (1 - 0.999)
             = 43,200 분 × 0.001
             = 43.2 분 / 월

SLO	Error Budget (30일)	적합한 서비스
99%	7.2 시간	내부 도구
99.5%	3.6 시간	중요 내부 서비스
99.9%	43.2 분	B2C 서비스
99.95%	21.6 분	결제, 금융
99.99%	4.32 분	핵심 인프라
99.999%	26초	통신, 금융 핵심

[!IMPORTANT] SLO 99.999% (five-nines) = 연간 5분. 매우 비싸고 달성하기 어려움. 비즈니스 임팩트에 맞는 수준 선택.

Error Budget Policy

flowchart TD
    Q{"Budget 소진 상태"}
    Q -->|"0-50% 소진"| Normal["정상 운영\n빠른 기능 개발 가능"]
    Q -->|"50-90% 소진"| Caution["주의: 변경 위험 평가\n릴리즈 신중히"]
    Q -->|"90-100% 소진"| Freeze["신규 기능 동결\n신뢰성 작업만"]
    Q -->|"100% 초과"| Stop["모든 risky 변경 중단\n postmortem 필수"]

Error budget 의 행동 contract. 단순 메트릭이 아닌 조직 정책 이어야 의미 있음.

SLO 계산 (PromQL)

# 30일 가용성 (rolling window)
sum_over_time(
  (sum(rate(http_requests_total{status!~"5.."}[1m]))
    / sum(rate(http_requests_total[1m])))[30d:1m]
)
/ count_over_time((sum(rate(http_requests_total[1m])))[30d:1m])

# Error Budget 남은 비율
1 - (
  (1 - current_availability) / (1 - 0.999)
)

# p95 latency SLI
histogram_quantile(0.95,
  sum by (le) (rate(http_request_duration_seconds_bucket[5m]))
)

Multi-window Burn Rate Alert

단순 threshold alert 보다 burn rate (소진 속도) 가 의미 있음:

flowchart LR
    BurnRate["Burn Rate"]
    BurnRate -->|"1h, 5% 소진 = 14.4x"| Page["즉시 page (PagerDuty)"]
    BurnRate -->|"6h, 10% 소진 = 6x"| Ticket["Ticket (Slack)"]
    BurnRate -->|"3d, 10% 소진 = 1x"| Monitor["모니터링 강화"]

# fast burn (1h 기준 14.4배 초과 소진)
(
  sum(rate(http_5xx[1h])) / sum(rate(http_total[1h]))
) > (14.4 * (1 - 0.999))

# slow burn (6h 기준 6배)
(
  sum(rate(http_5xx[6h])) / sum(rate(http_total[6h]))
) > (6 * (1 - 0.999))

윈도우	배율	알림 종류	의미
1h	14.4x	page	2h 안에 budget 소진
6h	6x	ticket	5일 안에 소진
1d	3x	weekly review	10일 안에 소진

SLA 예시 (실제 SaaS)

SaaS	SLA	위반 시
AWS S3	99.99% (월)	service credit
AWS EC2	99.5% (월)	service credit
GitHub	99.9% (분기)	credit
Stripe	99.999% (결제 API)	credit
Cloudflare	100% (보장)	credit

Postmortem 과 Error Budget

Error budget 소진 후에는 postmortem 필수:

Postmortem 구조
1. 요약: 무슨 일이 일어났는가 (5줄 이내)
2. 타임라인: 언제, 무엇을, 누가 (시간순)
3. 근본 원인 (5 WHY)
4. 영향 범위: 사용자 수, budget 소진량
5. Action items: 재발 방지 (owner + deadline)

blame-free postmortem: 사람이 아닌 시스템과 프로세스 개선 집중. Google SRE 핵심 문화.

SLO 대시보드 권장 항목

1. 현재 SLO 달성률 (rolling 30d): 99.97% ✓
2. Error budget 잔량: 22분 / 43.2분 (51%)
3. 이번 달 장애 이벤트: 3건
4. Burn rate (1h): 0.5x (정상)
5. Burn rate (6h): 1.2x (주의)
6. 다음 배포 예정: 2026-07-20

SLO 도입 단계별 로드맵

SLO 가 처음이면 단계적 도입 권장:

단계	목표	기간
1. 측정	SLI 데이터 수집 (Prometheus)	1-2주
2. 설정	과거 데이터 기반 현실적 SLO 초안	1주
3. 정책 정의	Error budget policy 팀 합의	1주
4. 대시보드	Grafana SLO 대시보드 구축	1주
5. Alert	Burn rate alert 설정	1주
6. 리뷰	월별 SLO review 프로세스	반복

# Grafana SLO plugin 예시
apiVersion: v0alpha1
kind: SLO
metadata:
  name: api-availability
spec:
  objectives:
    - value: 0.999
      window: 30d
  indicator:
    ratio:
      errors:
        source: grafana-cloud-metrics
        metric: http_requests_total{status=~"5.."}
      total:
        source: grafana-cloud-metrics
        metric: http_requests_total

흔한 함정

[!WARNING]

SLO 가 서버 metric (CPU 95%) = 사용자 경험과 무관. user-facing SLI 만.

너무 높은 SLO (99.999%) = 불가능 + 비용 폭증. 비즈니스에 맞는 수준.

SLA = SLO = SLA 는 계약, SLO 는 내부 목표 (더 엄격).

Budget 정책 부재 = SLO 만 측정하고 행동 없음. 무의미.

SLO 를 너무 많이 = 피로감. CUJ 기반 핵심 3-5개.

rolling window vs calendar window = rolling 이 더 정확. calendar 는 월초 buffer 착각.

[CI/CD] GitHub Actions: workflow, action, runner

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

GitHub Actions = GitHub 내장 CI/CD. YAML workflow + marketplace action. 2018 출시 → Travis CI 대체.

구조

flowchart TB
    Trigger[Trigger<br/>push, PR, schedule, ...] --> WF[Workflow]
    WF --> Job1["Job 1<br/>(runner)"]
    WF --> Job2[Job 2]
    Job1 --> Step1["Step 1 (action 또는 script)"]
    Job1 --> Step2[Step 2]

Workflow YAML

name: CI
on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node: [20, 22]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm test
      - run: npm run build

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123:role/gh-deploy
          aws-region: us-east-1
      - run: aws s3 sync ./dist s3://my-bucket

Trigger 종류

Trigger	의미
`push`	branch / tag push
`pull_request`	PR open / sync
`schedule`	cron
`workflow_dispatch`	수동 실행
`workflow_call`	다른 workflow 가 호출
`repository_dispatch`	외부 API
`release`	release published
`issue_comment`	comment

Runner

종류	의미
GitHub-hosted	Ubuntu/Windows/macOS, 매번 fresh
Self-hosted	자체 VM, 빠름, 보안 책임
Larger runners	GitHub-hosted 의 강한 사양
ARC (Actions Runner Controller)	K8s 위 self-hosted

Marketplace Action

- uses: actions/checkout@v4
- uses: actions/setup-python@v5
  with: { python-version: '3.13' }
- uses: docker/build-push-action@v6
- uses: actions/cache@v4
- uses: aws-actions/configure-aws-credentials@v4

OIDC + AWS (long-term key 없이)

자세한 건 [[aws-sts-assume-role]] 의 OIDC.

permissions:
  id-token: write
steps:
  - uses: aws-actions/configure-aws-credentials@v4
    with:
      role-to-assume: arn:aws:iam::123:role/gh-deploy
      aws-region: us-east-1

Matrix Build

strategy:
  fail-fast: false
  matrix:
    os: [ubuntu-latest, macos-latest]
    node: [20, 22]
    include:
      - os: ubuntu-latest
        node: 22
        coverage: true
    exclude:
      - os: macos-latest
        node: 20

N × M 조합 자동 실행.

Reusable Workflow

# .github/workflows/reusable-deploy.yml
on:
  workflow_call:
    inputs:
      env:
        required: true
        type: string

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps: [...]

# 호출
jobs:
  call:
    uses: ./.github/workflows/reusable-deploy.yml
    with: { env: prod }

Composite Action

action.yml:

name: 'Setup Node + cache'
runs:
  using: 'composite'
  steps:
    - uses: actions/setup-node@v4
    - uses: actions/cache@v4
    - run: npm ci
      shell: bash

보안

✓ PR fork 의 secret 노출 방지 (pull_request_target 주의)
✓ Action SHA pinning (uses: actions/checkout@<sha>)
✓ OIDC (long-term key 회피)
✓ Permissions 최소화 (permissions: 명시)
✓ Secrets 환경 분리 (environment)

흔한 함정

[!WARNING]

pull_request_target + checkout PR code = 코드 인젝션 가능. PR 의 코드는 pull_request 만.

Long-term AWS key = 누출 위험. OIDC 권장.

uses: action@main = action 변경에 영향 받음. SHA pinning.

Self-hosted runner 의 fork PR = 임의 코드 실행. fork 차단 또는 GitHub-hosted.

Cache와 Artifact

Cache

- uses: actions/cache@v4
  with:
    path: ~/.npm
    key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-node-

key 가 정확히 매칭되면 cache hit, 아니면 restore-keys 순서로 prefix 매칭.
hashFiles('**/package-lock.json') = lock 파일 변경 시 캐시 무효화.
actions/setup-node@v4 의 cache: npm 은 위를 자동으로 수행.

Artifact

- uses: actions/upload-artifact@v4
  with:
    name: dist
    path: ./dist
    retention-days: 7

# 다른 job 에서 다운로드
- uses: actions/download-artifact@v4
  with:
    name: dist
    path: ./dist

job 간 파일 공유. needs + artifact 로 build → deploy 파이프라인 연결. upload artifact 는 workflow 실행 당 5 GB, 기본 보존 90일.

Concurrency 제어

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

같은 branch 에서 새 push 가 오면 기존 실행 취소.
PR 에서 커밋 계속 올릴 때 이전 CI 낭비 방지.
cancel-in-progress: false 로 배포 job 직렬화 가능.

Environment와 Secret

jobs:
  deploy:
    environment: production       # GitHub Environments 보호 규칙 적용
    steps:
      - name: Use secret
        env:
          API_KEY: ${{ secrets.API_KEY }}        # repository / org secret
          DB_PASS: ${{ secrets.DB_PASS }}
        run: deploy.sh

secrets.XXX 는 로그에 자동 마스킹.
environment = 환경별 secret 분리 + 수동 승인 게이트.
GITHUB_TOKEN 은 Actions 가 자동 발급, 해당 repo 내 작업에만 유효.

permissions:
  contents: read
  pull-requests: write
  id-token: write       # OIDC 필요 시

최소 권한 원칙. workflow 레벨 / job 레벨 모두 선언 가능.

배포 파이프라인 흐름

flowchart LR
    Push["코드 push"] --> CI["CI: lint + test + build"]
    CI -->|"성공"| Stg["staging 배포"]
    CI -->|"실패"| Fail["빌드 실패 알림"]
    Stg -->|"승인 (Environment gate)"| Prod["prod 배포"]
    Stg -->|"E2E 실패"| Rollback["롤백"]

Expressions 와 Context

Context	내용
`github.ref`	현재 branch/tag ref
`github.sha`	commit SHA
`github.actor`	trigger 한 사용자
`github.event_name`	push, pull_request 등
`runner.os`	Linux, macOS, Windows
`env.MY_VAR`	환경변수 접근

# 조건부 실행
if: github.ref == 'refs/heads/main' && success()
if: contains(github.event.pull_request.labels.*.name, 'deploy')

[GitOps] ArgoCD: Kubernetes GitOps

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

ArgoCD = Kubernetes 의 GitOps 컨트롤러. Git 리포지토리의 manifest 가 source of truth → cluster 가 자동 동기화.

GitOps 원칙

flowchart LR
    Dev[Dev] -->|commit / PR| Git["Git repo<br/>(manifest)"]
    Git --> ArgoCD[ArgoCD]
    ArgoCD -->|continuously sync| Cluster[K8s Cluster]
    Cluster -->|state| Compare
    Git -->|desired| Compare
    Compare -->|drift| ArgoCD

원칙	의미
Git = source of truth	모든 변경 이 git 으로
Declarative	YAML / Helm / Kustomize
Auto-sync	git 변경 → cluster 자동 적용
Auto-healing	manual 변경도 git 으로 복구
Observable	UI / API 로 항상 상태 가시

Application 정의

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: web
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/myorg/manifests
    targetRevision: main
    path: apps/web/overlays/prod
  destination:
    server: https://kubernetes.default.svc
    namespace: web
  syncPolicy:
    automated:
      prune: true       # git 에서 제거된 자원 → 삭제
      selfHeal: true    # 수동 변경 → git 으로 복구
    syncOptions:
      - CreateNamespace=true

동작

sequenceDiagram
    Dev->>Git: commit manifest 변경
    loop 매 3분 (또는 webhook)
        ArgoCD->>Git: pull
    end
    ArgoCD->>Cluster: compare desired vs actual
    alt drift
        ArgoCD->>Cluster: kubectl apply
    end
    ArgoCD-->>Dev: UI 에 sync status

App of Apps 패턴

flowchart TB
    Root[Root Application] --> App1[App: web]
    Root --> App2[App: api]
    Root --> App3[App: worker]
    Root --> App4[App: redis]

Application 자체를 git 에서 관리. 새 service 추가 = git PR 만.

ApplicationSet

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata: { name: cluster-bootstrap }
spec:
  generators:
    - clusters: {}    # 모든 등록된 cluster
  template:
    metadata: { name: '{{name}}-monitoring' }
    spec:
      source:
        repoURL: ...
        path: 'clusters/{{name}}/monitoring'
      destination:
        server: '{{server}}'

수많은 cluster / namespace 에 동일 app 자동 배포.

ArgoCD vs Flux

항목	ArgoCD	Flux
UI	강력	없음 (Weave GitOps UI 별도)
학습 곡선	중간	낮음
단순성	중간	높음
Multi-tenancy	강	보통
Notification	built-in	Alertmanager 통합

2026 시점 ArgoCD 가 더 인기. UI + 다양 source (Helm, Kustomize, Jsonnet, …).

Argo Rollouts (Progressive Delivery)

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata: { name: web }
spec:
  replicas: 10
  strategy:
    canary:
      steps:
        - setWeight: 10
        - pause: { duration: 5m }
        - setWeight: 30
        - pause: { duration: 5m }
        - setWeight: 50
        - pause: { duration: 10m }
        - setWeight: 100
      analysis:
        templates:
          - templateName: success-rate

progressive rollout + 자동 metric 분석 + 실패 시 자동 롤백.

CI/CD 분리 (Push vs Pull)

flowchart LR
    subgraph "Push-based (옛)"
        CI1[CI] -->|kubectl apply| Cluster1
    end
    subgraph "Pull-based (GitOps)"
        CI2[CI] -->|update manifest| Git
        Argo[ArgoCD] -->|pull + apply| Cluster2
    end

Pull (GitOps)	Push
안전 (cluster credential 외부 없음)	CI 가 cluster 접근
자동 복구	한 번 실행 후 끝
감사 (git log)	CI history
다중 cluster 쉬움	어렵

흔한 함정

[!WARNING]

수동 kubectl apply = ArgoCD 가 git 으로 복구. 모든 변경은 git PR.

Secret 의 git 평문 = SOPS / Sealed Secrets / External Secrets.

거대한 단일 App = 부분 sync 어려움. 작은 App 으로.

Webhook 미설정 = 3분 polling 지연. GitHub webhook 권장.

RBAC / Projects

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: team-backend
  namespace: argocd
spec:
  sourceRepos:
    - 'https://github.com/myorg/*'
  destinations:
    - namespace: backend
      server: https://kubernetes.default.svc
  clusterResourceWhitelist:
    - group: ''
      kind: Namespace
  roles:
    - name: developer
      description: deploy 권한
      policies:
        - p, proj:team-backend:developer, applications, sync, team-backend/*, allow

Project = 권한 경계. namespace / repo / 리소스 종류 제한. Multi-team 환경에서 필수.

Sync Wave & Hooks

metadata:
  annotations:
    argocd.argoproj.io/sync-wave: "0"     # wave 번호: 낮을수록 먼저 sync
    argocd.argoproj.io/hook: PreSync       # PreSync / Sync / PostSync / SyncFail
    argocd.argoproj.io/hook-delete-policy: HookSucceeded

flowchart LR
    W0["Wave 0: CRD, Namespace"] --> W1["Wave 1: ConfigMap, Secret"]
    W1 --> W2["Wave 2: Deployment"]
    W2 --> W3["Wave 3: Ingress"]

wave 번호 낮은 것부터 sync. 같은 wave 내 리소스는 병렬. Hook 은 lifecycle 지점 지정.

Health Check

ArgoCD 가 리소스 상태를 Healthy / Progressing / Degraded 로 자동 판단. 커스텀 health check:

# argocd-cm ConfigMap
resource.customizations.health.mygroup_myresource: |
  hs = {}
  if obj.status.ready == true then
    hs.status = "Healthy"
  else
    hs.status = "Progressing"
  end
  return hs

상태	의미
Healthy	리소스 정상
Progressing	업데이트 중
Degraded	오류, 복구 필요
Suspended	일시 중단
Missing	클러스터에 없음

Argo Image Updater

annotations:
  argocd-image-updater.argoproj.io/image-list: web=myrepo/web
  argocd-image-updater.argoproj.io/web.update-strategy: semver
  argocd-image-updater.argoproj.io/write-back-method: git

container image 새 버전 자동 감지 → git 에 commit → ArgoCD sync. CI 파이프라인 마지막 단계 자동화.

Notification Controller

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-notifications-cm
data:
  template.app-sync-succeeded: |
    slack:
      attachments: |
        [{
          "color": "#18be52",
          "title": "{{.app.metadata.name}} 배포 완료"
        }]
  trigger.on-sync-succeeded: |
    - when: app.status.operationState.phase in ['Succeeded']
      send: [app-sync-succeeded]

배포 완료 / 실패 / drift 를 Slack / Teams / PagerDuty 로 알림. argocd-notifications-secret 에 webhook URL 저장.

[Observability] Prometheus: pull 기반 메트릭, PromQL

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

Prometheus = pull 기반 시계열 metric 시스템. PromQL 로 쿼리. CNCF graduated. 2026 클라우드 네이티브 메트릭 표준.

아키텍처

flowchart LR
    App1[App + /metrics] -.HTTP GET.-> Prom[Prometheus]
    App2[App + /metrics] -.HTTP GET.-> Prom
    NodeEx[node-exporter] -.HTTP GET.-> Prom
    KSM[kube-state-metrics] -.HTTP GET.-> Prom
    Prom --> TSDB[(Time Series DB)]
    Prom --> AM[Alertmanager]
    AM --> Slack[Slack / PagerDuty / Email]
    Prom --> Grafana

Pull 모델: Prometheus 가 각 target 의 /metrics 정기 scrape. Push 가 아닌 이유: target healthy 자동 확인, scrape interval 통제.

Exposition Format

# HELP http_requests_total Total HTTP requests
# TYPE http_requests_total counter
http_requests_total{method="GET",status="200",path="/api/users"} 1234
http_requests_total{method="POST",status="201",path="/api/orders"} 567

# HELP http_request_duration_seconds Request duration
# TYPE http_request_duration_seconds histogram
http_request_duration_seconds_bucket{le="0.1"} 5000
http_request_duration_seconds_bucket{le="0.5"} 5800
http_request_duration_seconds_bucket{le="1.0"} 5900
http_request_duration_seconds_bucket{le="+Inf"} 6000
http_request_duration_seconds_sum 412.5
http_request_duration_seconds_count 6000

4가지 메트릭 타입

타입	의미	예
Counter	단조 증가	requests_total
Gauge	임의 변동	memory_usage_bytes
Histogram	분포 (bucket)	request_duration_seconds
Summary	quantile (클라이언트 계산)	request_duration_quantile

PromQL 예시

# 요청률 (5분)
rate(http_requests_total[5m])

# 에러 비율
sum(rate(http_requests_total{status=~"5.."}[5m]))
  / sum(rate(http_requests_total[5m]))

# 평균 응답 시간
rate(http_request_duration_seconds_sum[5m])
  / rate(http_request_duration_seconds_count[5m])

# p95 latency (histogram_quantile)
histogram_quantile(0.95,
  sum by (le, service) (rate(http_request_duration_seconds_bucket[5m]))
)

# 메모리 사용량 (gauge)
process_resident_memory_bytes

# CPU 사용률
rate(process_cpu_seconds_total[1m])

# 가용성 (up)
avg_over_time(up{job="api"}[5m])

Exporter

Exporter	메트릭
node-exporter	Linux node (CPU, RAM, disk, network)
kube-state-metrics	K8s 객체 상태
cAdvisor	container metric (K8s 기본 포함)
postgres_exporter	PG 통계
redis_exporter	Redis
blackbox_exporter	HTTP/TCP probe
nginx-exporter	nginx

4 Golden Signals (Google SRE)

flowchart TD
    G[4 Golden Signals]
    G --> Lat[Latency]
    G --> Tra[Traffic]
    G --> Err[Errors]
    G --> Sat[Saturation]

모든 서비스 대시보드의 기본 4. 이 4 가지면 대부분의 문제 발견.

Alertmanager

# Alert rule
groups:
  - name: api
    rules:
      - alert: HighErrorRate
        expr: |
          sum(rate(http_requests_total{status=~"5.."}[5m]))
            / sum(rate(http_requests_total[5m])) > 0.05
        for: 5m
        labels: { severity: page }
        annotations:
          summary: "5xx rate > 5%"

# Alertmanager 설정
route:
  group_by: [alertname, severity]
  receiver: slack
  routes:
    - match: { severity: page }
      receiver: pagerduty
receivers:
  - name: slack
    slack_configs:
      - api_url: https://hooks.slack.com/...
  - name: pagerduty
    pagerduty_configs:
      - service_key: ...

Long-Term Storage

	Local TSDB	Thanos	Mimir	Cortex
Retention	15일 기본	무제한 (S3)	무제한	무제한
HA	없음	있음	있음	있음
Multi-tenancy	없음	있음	있음	있음

수년 retention + 다중 cluster = Thanos / Mimir.

Recording Rule

- record: job:http_requests:rate5m
  expr: sum by (job) (rate(http_requests_total[5m]))

자주 쓰는 쿼리 결과 미리 계산. 대시보드 속도 ↑.

흔한 함정

[!WARNING]

Label cardinality 폭증 = user_id, request_id 같은 고유 값 을 label 로. 메모리 / disk 폭발.

rate() 의 짧은 range = scrape interval 보다 작으면 NaN.

Counter reset 인식 못함 = rate() 가 자동. increase() 와 차이.

Push 가 필요한 경우 = Pushgateway 사용 (batch job 등). 일반 service 는 pull.

Prometheus Operator / ServiceMonitor

Kubernetes 환경에서 kube-prometheus-stack (helm chart) 가 표준.

# ServiceMonitor: app 의 /metrics 를 자동 scrape
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: api
  labels:
    release: kube-prometheus-stack
spec:
  selector:
    matchLabels:
      app: api
  endpoints:
    - port: http
      path: /metrics
      interval: 30s

prometheus.io/scrape: "true" annotation 방식은 레거시. Operator 환경에서는 ServiceMonitor / PodMonitor 를 사용.

Pushgateway (Batch Job 메트릭)

flowchart LR
    Job["Batch Job (짧은 수명)"] -->|push metrics| PG[Pushgateway]
    PG -.scrape.-> Prom[Prometheus]
    Prom --> Grafana

일반 service = pull. Batch job 처럼 짧게 실행 후 종료 = Pushgateway push.

[!WARNING] Pushgateway 는 SPOF: job 실패해도 metrics 가 남음. TTL 설정 또는 job 완료 후 delete API 호출 필수.

PromQL 핵심 함수

함수	설명	예시
`rate(v[d])`	초당 평균 변화율	`rate(http_requests_total[5m])`
`irate(v[d])`	순간 변화율 (최근 2점)	스파이크 민감 탐지
`increase(v[d])`	범위 내 총 증가량	`increase(errors_total[1h])`
`sum by(label)`	레이블로 집계	`sum by (service)`
`topk(n, v)`	상위 N 시리즈	`topk(5, rate(rps[5m]))`
`absent(v)`	시리즈 없을 때 1 반환	서비스 다운 감지
`histogram_quantile`	bucket 에서 quantile 계산	p99 latency
`avg_over_time`	시간 범위 평균	가용성 계산

Histogram vs Summary

항목	Histogram	Summary
다중 인스턴스 집계	가능 (서버 집계)	불가 (클라이언트 계산)
정확도	bucket 오차 존재	정확
quantile 변경	재배포 없이 변경 가능	재배포 필요
권장 상황	대부분, 다중 인스턴스	단일 인스턴스 정확 측정

[!IMPORTANT] 인스턴스 여러 개 = Histogram 필수. Summary quantile 은 인스턴스 간 집계 불가.

Long-term Storage 선택

flowchart LR
    Prom[Prometheus] -->|remote_write| TH[Thanos / Mimir]
    TH --> S3[(S3: 무제한)]
    TH --> GQ["Grafana (통합 쿼리)"]

방식	설명
Federation	상위 Prometheus 가 하위 scrape (레거시)
Remote Write	Prometheus → 외부 저장소 전송 (표준)
Agent Mode	scrape + remote write 만, local TSDB 없음

# Remote Write (Thanos Receiver)
remote_write:
  - url: http://thanos-receive:19291/api/v1/receive
    queue_config:
      max_samples_per_send: 10000

[Voice AI] P50/P95/P99: latency 분포와 SLO

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

P50 / P95 / P99 = latency 분포의 분위수. 평균은 outlier 에 가려져 무의미. 음성 에이전트의 사용자 경험 은 p95/p99 가 결정.

[!IMPORTANT] 평균 응답 시간 800ms 라도 P99 = 5초 면 100명 중 1명은 5초 대기. 음성 = “한 번 깨지면 대화 망함”.

Percentile 정의

정렬된 latency 값 100개 중:
- P50 (median) = 50번째 값
- P95 = 95번째 값
- P99 = 99번째 값
- P99.9 = 99.9번째 값

flowchart LR
    Hist["응답 시간 분포 (긴 꼬리)"] --> P50["P50 = 500ms<br/>(중간값)"]
    Hist --> P95["P95 = 1200ms<br/>(95% 이내)"]
    Hist --> P99["P99 = 3500ms<br/>(99% 이내)"]
    Hist --> P999["P99.9 = 8000ms<br/>(0.1% outlier)"]

분포 시각화

Tail (3초+) 이 작아 보이지만 사용자 입장에서는 치명적.

평균 vs Percentile

# 가상 latency 데이터 (음성 응답)
latencies = [
    *[500] * 95,    # 95명이 500ms
    *[1000] * 4,    # 4명이 1초
    *[5000] * 1,    # 1명이 5초 (timeout 직전)
]

print(f"평균: {sum(latencies) / len(latencies):.0f}ms")
# → 평균: 590ms ← "괜찮네"

import numpy as np
print(f"P50: {np.percentile(latencies, 50):.0f}ms")
print(f"P95: {np.percentile(latencies, 95):.0f}ms")
print(f"P99: {np.percentile(latencies, 99):.0f}ms")
# → P50: 500ms, P95: 500ms, P99: 5000ms ← "1%가 5초!"

측정: HDR Histogram

from hdrh.histogram import HdrHistogram

# 1ms ~ 60s, 3 자리 정밀도
hist = HdrHistogram(1, 60_000, 3)

for latency_ms in latencies:
    hist.record_value(latency_ms)

print(f"P50: {hist.get_value_at_percentile(50)}ms")
print(f"P95: {hist.get_value_at_percentile(95)}ms")
print(f"P99: {hist.get_value_at_percentile(99)}ms")
print(f"P99.9: {hist.get_value_at_percentile(99.9)}ms")

측정 도구	의미
HDR Histogram	정확, 고정 메모리
t-digest	분산 환경, 합치기 좋음
Prometheus Histogram	분산 + 시각화
CloudWatch p metric*	비싸지만 편함

분산 환경: t-digest

from tdigest import TDigest

digest = TDigest()
for v in latencies:
    digest.update(v)

# 여러 노드의 digest 합치기
node1_digest + node2_digest + ...

# percentile query
digest.percentile(95)

각 노드의 digest 를 Redis 에 저장 → 주기적 머지. 전역 percentile.

Coordinated Omission

Gil Tene 의 유명한 문제. 측정 시 느린 요청 동안 측정도 못 하는 → 진짜 latency 보다 좋게 나옴.

# ❌ 잘못된 측정
while True:
    start = time.time()
    do_request()
    elapsed = time.time() - start
    record(elapsed)
    # 만약 request 가 10초 걸렸으면, 그 10초간 *추가 측정 못 함*

# ✓ Coordinated omission 보정
expected_rate_ms = 100  # 100ms 마다 1개
last_send = time.time()
while True:
    target = last_send + expected_rate_ms / 1000
    sleep_until(target)
    start = time.time()

    # *예정된 시간이 지났는데 보내지 못한 시간* 도 latency 에 포함
    expected_start = target
    do_request()
    elapsed = time.time() - expected_start   # ← 보정

    record(elapsed)
    last_send = target

Voice Agent SLO

Metric	P50	P95	P99
End-to-end	700ms	1200ms	2000ms
STT	200ms	400ms	800ms
LLM TTFT	300ms	600ms	1500ms
TTS TTFB	150ms	300ms	700ms
Network RTT	30ms	80ms	200ms

[!IMPORTANT] P99 가 1초 이상 이면 1% 사용자가 어색한 대화. 음성 SLO 는 P99 기준.

단계별 분석

class LatencyTracker:
    def __init__(self):
        self.stages = defaultdict(HdrHistogram)

    def record(self, stage: str, latency_ms: int):
        self.stages[stage].record_value(latency_ms)

    def report(self):
        for stage, hist in self.stages.items():
            print(f"{stage}:")
            for p in [50, 95, 99, 99.9]:
                print(f"  P{p}: {hist.get_value_at_percentile(p)}ms")

# 사용
tracker.record('stt', stt_elapsed)
tracker.record('llm_ttft', llm_ttft)
tracker.record('tts_ttfb', tts_ttfb)
tracker.record('end_to_end', total)

SLO / Error Budget

자세한 건 [[slo-sli-error-budget]].

SLO: 30일 동안 P95 end-to-end < 1500ms
Error Budget = 30일 × 24h × 60min × 5% = 2160분

P95 > 1500ms 인 1분 = budget 1분 소진
budget 소진 → feature freeze + reliability 작업

흔한 함정

[!WARNING]

평균만 봄 = outlier 무시. P95/P99 필수.

Prometheus histogram bucket 부정확 = bucket 범위 밖이면 정확도 손실. HDR / t-digest 권장.

Coordinated omission = 실측이 너무 좋아 보임. 보정 필요.

샘플링 너무 적음 = P99 의미 X. 최소 1000+ 샘플.

[DevOps] 무중단 배포: Blue-Green, Canary, Rolling, Expand-Contract

koa (김신건) — Wed, 24 Jun 2026 00:00:00 GMT

정의

무중단 배포 (Zero-Downtime Deployment) 는 서비스 가동을 멈추지 않고 새 버전을 배포하는 일련의 전략. 핵심 도전 4가지:

트래픽 전환: 어떻게 라우팅을 안전하게?
세션 / 인플라이트 요청: 진행 중 요청 보호
DB 스키마 변경: 두 버전 동시 동작 가능해야
롤백 보장: 실패 시 즉시 이전 버전으로

전략 매트릭스:

전략	인프라 비용	롤백 속도	점진성	복잡도
Blue-Green	2배	즉시 (스위치)	없음 (한 번에)	낮음
Rolling Update	1배	느림 (재배포)	있음 (pod 단위)	낮음
Canary	1.x배	빠름 (canary 제거)	정밀 (트래픽 %)	중간
A/B Test	1.x배	즉시 (flag off)	사용자 segment	높음
Feature Flag	1배	즉시 (flag off)	코드 path 단위	높음

Blue-Green Deployment

두 환경 (Blue, Green) 을 동시에 운영, 라우터로 한쪽만 활성:

[현재 활성: Blue]
Router → Blue (v1, traffic 100%)
         Green (v2, idle, 배포 중)

[배포 완료, smoke test 통과]
Router → Green (v2, traffic 100%)
         Blue (v1, standby for rollback)

[안정 후 다음 배포]
Router → Green (v2, traffic 100%)
         Blue (v3 배포 중)

장점:

즉시 스위치 + 즉시 롤백: 라우터 변경만
운영 환경에서 최종 테스트: 같은 인프라
재해 복구 연습: 매 배포마다 hot-standby 검증

단점:

2배 인프라 비용: 두 환경 항상 가동
DB 공유 처리: 두 버전이 같은 DB → 스키마 호환 필수 (expand-contract)
인플라이트 요청 손실 위험: 스위치 시점에 처리 중이던 요청
all-or-nothing: 점진 배포 불가

인플라이트 요청 처리

# K8s 의 graceful shutdown
spec:
  terminationGracePeriodSeconds: 30
  containers:
    - lifecycle:
        preStop:
          exec:
            command: ["sh", "-c", "sleep 5"]   # readiness 빠지는 시간

readiness false → LB 가 제외 → 신규 요청 안 받음 → 진행 요청 완료 대기 → SIGTERM → graceful shutdown.

Spring Boot 의 server.shutdown: graceful + spring.lifecycle.timeout-per-shutdown-phase: 30s 와 조합 ([[spring-boot-webserver-configuration]] 참고).

Rolling Update (K8s 기본)

pod 를 한 번에 N개씩 교체:

apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%          # 임시로 추가 가능한 pod %
      maxUnavailable: 25%    # 동시 unavailable 허용 %

flow:

새 ReplicaSet 생성, pod 1개 시작
readiness OK → LB 추가, 옛 pod 1개 제거
반복

장점:

인프라 비용 1배 (혹은 약간 +)
K8s native: 추가 도구 없음
점진성: pod 1개씩 = 영향 최소

단점:

두 버전 동시 운영 시간 길다: 5~10분 (큰 cluster 면 30분+)
롤백 느림: 다시 rolling 으로 이전 버전 배포
두 버전 호환성 필수: DB / API contract 양방향

Canary Deployment

일부 트래픽만 새 버전으로 보내 검증:

[Phase 1] 1% canary
Router → 99% v1, 1% v2

[Phase 2] 안정 → 5% → 25% → 50% → 100%
Router → v2 로 점진 증가

[중간 실패 시] canary 즉시 제거
Router → 100% v1

K8s + Istio / Linkerd / Argo Rollouts 같은 service mesh / progressive delivery 도구로 구현:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
spec:
  strategy:
    canary:
      steps:
        - setWeight: 1
        - pause: { duration: 10m }
        - setWeight: 5
        - pause: { duration: 30m }
        - setWeight: 25
        - pause: { duration: 1h }
        - setWeight: 50
        - pause: { duration: 1h }
        - setWeight: 100
      analysis:
        templates:
          - templateName: success-rate
          - templateName: latency

자동 분석: 에러율 / latency / 비즈니스 metric 이 SLO 위반 시 자동 rollback.

장점:

실제 사용자에 미세 검증: 합성 테스트로 못 잡는 버그 발견
빠른 롤백
자동 분석 + 자동 진행

단점:

복잡한 인프라 (service mesh 또는 Argo Rollouts)
두 버전 호환성 필수
canary 가 너무 작으면 통계 의미 없음: 1% 가 충분한 트래픽이어야

A/B Testing vs Canary

항목	Canary	A/B Test
목적	새 코드 안전성 검증	비즈니스 가설 검증
라우팅 기준	트래픽 % (random)	사용자 segment (cookie, user_id)
측정 metric	에러율 / latency / SLO	conversion / CTR / revenue
기간	시간 단위	일~주
결정 주체	SRE / 자동화	PM / data scientist

같은 인프라 위에서 동작하지만 의도가 다름. A/B 가 더 오래 지속.

Feature Flag

코드 path 단위 토글. 배포와 release 분리:

@Service
class CheckoutService {
    private final FeatureFlagClient flags;

    public Order checkout(Cart cart, User user) {
        if (flags.isEnabled("new-checkout-v2", user)) {
            return newCheckoutFlow(cart, user);
        }
        return legacyCheckoutFlow(cart, user);
    }
}

flag 종류 (Martin Fowler 분류):

종류	수명	동적성	예시
Release toggle	짧음 (배포 후 제거)	정적	”new-feature-x”
Experiment toggle	중간 (A/B 끝나면 제거)	사용자별	”checkout-variant-a”
Ops toggle	길음	실시간	”circuit-breaker”, “rate-limit”
Permission toggle	영구	사용자별	”premium-feature”

도구: LaunchDarkly, Unleash, Flagsmith, Split.io, 또는 자체 구현 (DB + Redis 캐시).

spring:
  cloud:
    config:
      enabled: true
# 또는 Redis hash 기반

flag 평가는 hot path 에 있으므로 로컬 캐시 + 백그라운드 sync 가 권장.

DB Migration: Expand-Contract

무중단 배포의 가장 어려운 부분. 두 버전 동시 동작 가능한 스키마 필요.

위험 변경 예: 컬럼 rename `email_addr` → `email`

❌ 위험한 single-step:

ALTER TABLE users RENAME COLUMN email_addr TO email;
-- 배포 동시에: 옛 코드는 email_addr, 새 코드는 email
-- 둘 중 하나 무조건 깨짐

✓ Expand-Contract (4단계):

Step 1: Expand : 새 컬럼 추가 (NULL 허용)

ALTER TABLE users ADD COLUMN email VARCHAR(255);

배포: 없음. 옛 코드 정상.

Step 2: Backfill : 데이터 복사

UPDATE users SET email = email_addr WHERE email IS NULL;
-- 대용량이면 배치 (1000 row 씩)

배포: 없음. 옛 코드 정상.

Step 3: Dual-write : 새 코드 배포 (둘 다 쓰고 새 컬럼 읽기)

user.setEmail(email);
user.setEmailAddr(email);   // 호환을 위해 둘 다 쓰기

배포: 새 코드. 옛 코드 / 새 코드 모두 정상.

Step 4: Contract : 옛 코드 모두 사라진 후 + 충분한 안정 기간

ALTER TABLE users DROP COLUMN email_addr;
-- 옛 컬럼 제거

배포: 없음. 옛 코드 이제 없으므로 안전.

각 step 마다 rollback point. 한 번에 1 단계만, 충분한 검증 후 다음.

NOT NULL 추가

❌ 단일 step:

ALTER TABLE users ALTER COLUMN email SET NOT NULL;
-- 기존 NULL row 가 있으면 실패, lock 발생

✓ 다단계:

backfill (NULL 채우기)
코드가 항상 NOT NULL 으로 쓰도록 배포
constraint 추가 (NOT VALID 으로 lock 없이) → VALIDATE

PostgreSQL 의 ADD CONSTRAINT ... NOT VALID + VALIDATE CONSTRAINT 분리가 lock 없이.

인덱스

-- PostgreSQL
CREATE INDEX CONCURRENTLY idx_users_email ON users(email);

-- MySQL 8+
ALTER TABLE users ADD INDEX idx_email (email), ALGORITHM=INPLACE, LOCK=NONE;

CONCURRENTLY / ALGORITHM=INPLACE 가 lock 회피.

외래키

-- 1. 추가 (validate 없이)
ALTER TABLE orders ADD CONSTRAINT fk_user FOREIGN KEY (user_id) REFERENCES users(id) NOT VALID;
-- 2. 검증 (lock 적음)
ALTER TABLE orders VALIDATE CONSTRAINT fk_user;

Backward / Forward Compatibility

배포 중 두 버전 동시 동작 → 양방향 호환:

API

항상 추가만: 새 field 는 optional default, 제거는 deprecation 후 충분한 시간
버전 prefix (/v1/, /v2/): breaking change 시 새 경로
JSON unknown field 무시: Jackson @JsonIgnoreProperties(ignoreUnknown = true)

Message Queue

Avro / Protobuf schema evolution: 옵션 필드 추가 OK, 제거는 deprecation
새 producer + 옛 consumer: 새 field 무시
옛 producer + 새 consumer: default 값 사용

직렬화 (Java)

serialVersionUID 유지: 옛 클래스 인스턴스 deserialize 가능
field 제거 금지 (충분한 transition 기간 전까지)
Jackson polymorphic deserialization 주의: @JsonTypeInfo

헬스체크 + readiness 분리

K8s 의 3가지 probe:

Probe	실패 시 동작	사용
startupProbe	컨테이너 재시작 (initial delay 길게)	느린 시작 (JVM, DB pool warmup)
livenessProbe	컨테이너 재시작	복구 불가 상태 (deadlock, OOM)
readinessProbe	LB 에서 제외 (재시작 X)	일시적 unavailable (DB 연결 끊김)

Spring Boot 의 /actuator/health/liveness + /actuator/health/readiness 가 표준 매핑 ([[spring-boot-container-deployment]]).

Outbox 패턴 (DB + 메시지 큐 일관성)

DB 트랜잭션 + Kafka publish 가 atomic 하지 않음 (분산 트랜잭션 회피):

[종래 문제]
INSERT order → 성공
kafka.publish(OrderPlaced) → 실패 (네트워크)
→ DB 에 order 있지만 알림 없음 = inconsistent

[Outbox 패턴]
TRANSACTION:
  INSERT order
  INSERT outbox(event=OrderPlaced, status=pending)
COMMIT

[별도 worker]
SELECT outbox WHERE status=pending
  → Kafka publish
  → UPDATE outbox SET status=sent

@TransactionalEventListener(phase=AFTER_COMMIT) 도 비슷한 효과 (단, 워커 인스턴스 죽으면 event 손실 → outbox 가 더 안전).

함정과 베스트 프랙티스

DB schema 변경은 항상 expand-contract: single-step 은 무중단 X
graceful shutdown + preStop sleep: K8s 환경 필수
readiness 와 liveness 분리: 일시 문제로 재시작 폭주 회피
session affinity 최소화: blue-green / rolling 시 세션 분실 위험 → 외부 store (Redis)
canary 자동 분석 + 자동 rollback: 사람의 판단 늦음
feature flag 정리: release toggle 은 배포 후 즉시 제거 (코드 cruft 방지)
API breaking change = 새 버전 endpoint: 옛 endpoint 충분 기간 유지
테스트 환경에서 무중단 시나리오 연습: 진짜 배포 때 처음 보면 늦음
rollback 도 무중단: forward 만 가능하면 디자인 결함

김신건의 로그 - 위키 / devops

[Observability] OpenTelemetry: 표준화된 trace/metric/log

정의

문제 상황과 동기

3 signal

아키텍처

Collector 의 역할

Trace = Span Tree

Span Kind

Context Propagation (W3C)

Auto-instrumentation

Manual Instrumentation

OTel Collector

Sampling

Tail Sampling 설정 예시

OpenTelemetry vs Vendor

흔한 함정

함정 5: Collector 없이 직접 backend 전송

함정 6: Span attribute semantic convention 무시

관련 위키

Shell Script: bash 기본과 실전 패턴

정의

안전한 시작

실행 흐름

변수

조건과 반복

파일 테스트 연산자

함수

에러 처리

파일과 경로

텍스트 처리

stdin/stdout 처리

병렬 실행

로깅 패턴

인자 파싱

실전 패턴: 배포 스크립트

함정

관련 위키

[GitOps] 패턴: 단일 vs 다중 repo, environment promotion

정의

GitOps 4가지 원칙 (OpenGitOps)

Push vs Pull 모델

Repo 구조 패턴

1. Monorepo (app + manifest)

2. 2-repo (권장)

CI/CD 통합 흐름

Environment Promotion

Image Updater

Secret 처리 (git 안전)

ArgoCD vs Flux

Multi-cluster GitOps

Drift Detection

흔한 함정

관련 위키

[Observability] SLI / SLO / SLA / Error Budget

정의

SRE 와 SLO 의 관계

관계도

좋은 SLI 4 카테고리

서비스 유형별 SLI

CUJ (Critical User Journey)

SLO 설정 예시

Error Budget Policy

SLO 계산 (PromQL)

Multi-window Burn Rate Alert

SLA 예시 (실제 SaaS)

Postmortem 과 Error Budget

SLO 대시보드 권장 항목

SLO 도입 단계별 로드맵

흔한 함정

관련 위키

[CI/CD] GitHub Actions: workflow, action, runner

정의

구조

Workflow YAML

Trigger 종류

Runner

Marketplace Action

OIDC + AWS (long-term key 없이)

Matrix Build

위험 변경 예: 컬럼 rename `email_addr` → `email`