developer_Ryu

AWS 2026 컨퍼런스 후기

Ry- — Tue, 9 Jun 2026 22:51:42 +0900

되게 늦게 후기글을 작성합니다.

AWS 2026년 컨퍼런스

AWS 컨퍼런스는 5월20~21일 삼성 코엑스에서 진행되었습니다.

이번에 친구 회사가 거기서 부스를 열게되서 구경도하고 기업들이 AWS의 서비스를 어떻게 사용하는지를 알아보기 위해 갔습니다.

신청 당시에 21일로 잡혔는데 다시 신청하게 되어 20일까지 확정 받았습니다.

아침 8시 30분쯤인데 벌써 사람들이 많이 서 있었다.

다시 한번 AWS의 위엄을 느꼈다..

여기를 들어가게 되면 기조연설하는 장소로 넘어오게됩니다.

의자가 엄청 많이 깔려있었는데 그 많은 의자들이 연설 시작하자 다 채워졌습니다.

기조 연설장에는 의자에 헤드셋을 통해 자동 통역을 해주었습니다. 그 밖에도 바로바로 화면에서 번역되어 나오기 때문에 큰 걱정없이 발표를 들을수 있었습니다.

Upstage에서는 절차형 AI와 자율형 AI에 대한 내용을 소개하면서 Upstage가 가고자 하는 방향과 AWS를 서비스에 도입한 결과를 설명해주었다.

주된 포인트가 AI-DLC 라는 SDLC의 개념을 넘는 AI-DLC의 세계가 오면서 현재 우리 IT 업계가 도입해야될 방법론에 대해서 잘 알려준거 습니다.

그리고 이어서 작년 12월 라스베가스에서 소개되었던 새롭게 개발된 AWS 서비스 기술들이 소개 되었습니다.

이런 부분에서 대해서 따로 알아보며 나의 스킬을 높여보는것도 좋은 기회가 될거 같습니다.

연설을 다 듣고나서 C룸으로 이동해 다양한 기업들의 부스들을 살펴보았습니다.

부스들 돌아다니면서 관심있었던 모니터링, 보안쪽 파트를 위주로 살펴보았고 궁금했던 내용도 물어보면서 다녔습니다.

마지막으로 POSCO 광양제철소 설비 예지정비 혁신: AWS KiroS- MLOps 세션을 듣고 나왔습니다.

처음으로 AWS 컨퍼런스에 참석하느냐 제대로 즐기질 못했던거 같습니다.

다음에 또 컨퍼런스를 하게된다면 또 오고 싶고 다들 한번씩 경험해보면 좋을거 같습니다!

정리하고 공부할게 많다는걸 다시 한번 배운 하루였습니다

Grafana Mimir 아키텍처

Ry- — Wed, 3 Jun 2026 20:44:32 +0900

Prometheus 호환 대규모 TSDB 4대장(Thanos, Cortex, VictoriaMetrics, Mimir) 비교 및 Mimir 내부 원리 정리.

4대장 비교

제품 핵심 정의 최대 장점 최대 단점

VictoriaMetrics	쓰기/저장/읽기 3개 컴포넌트의 초단순 아키텍처	압도적 관리 편의성, 높은 성능	Block Storage 종속 → 장기 보관 비용·확장성 저하. Hash ring 없어 rebalancing 수동
Thanos	기존 Prometheus 위에 Sidecar를 얹는 확장형	기존 Prometheus 환경 재사용 가능	신규 구축 시 아키텍처 기형. 실시간 분산 집계 병목
Grafana Mimir	처음부터 대규모를 타깃한 Object Storage 네이티브 분산 클러스터	무한 확장성, Query Frontend 조회 속도, 철저한 멀티테넌시	마이크로서비스 컴포넌트 多 → 운영 복잡도 높음
Cortex	Mimir의 모태인 1세대 분산 TSDB	검증된 아키텍처	Grafana Labs의 Mimir 집중으로 사실상 deprecated

Mimir를 선택한 이유:

Cortex co-author + 주요 contributor가 Grafana 소속 → Cortex 기여 87%가 Grafana
Prometheus 확장에서 진화한 Thanos와 달리 처음부터 대규모 설계
Grafana(metric consumer 압도적 1위)와의 유착 관계
Loki, Tempo와 아키텍처·컴포넌트 이름을 공유 → 운영 지식 재사용
PromQL 100% 호환 (VictoriaMetrics는 74%)

전체 파이프라인 구조

쓰기
[Prometheus scrape / OTEL Collector]
          │ remote_write
          ▼
    ┌─── Distributor ───┐     ← stateless. 유효성 검사 + 복제 분산
    │    Hash Ring 조회  │
    └───────────────────┘
       │           │         │
       ▼           ▼         ▼
  Ingester-1  Ingester-2  Ingester-3   ← stateful (RF=3, Quorum=2)
  WAL + Mem   WAL + Mem   WAL + Mem
       │
  2h flush
       ▼
  Object Storage (S3 / GCS)
       │
  Compactor ─── 수직 압축(dedup) → 수평 압축(merge)
       │
  Store Gateway ─── index 캐시, bucket view 유지

읽기
[Grafana PromQL]
       ▼
 Query Frontend  ── ① Results Cache (memcached) 확인
       │             ② 캐시 미스 → FIFO Queue
       ▼
 Query Scheduler (optional) ── 큐 부하 분산
       ▼
    Querier  ── 최근: Ingester 직접 / 장기: Store Gateway → S3
       │
 결과 반환 → Query Frontend 병합 → Grafana

https://grafana.com/docs/mimir/latest/get-started/about-grafana-mimir-architecture/about-ingest-storage-architecture/#how-ingest-storage-architecture-works

Write Path 상세

Distributor — 분산 + 복제

Hash Ring 동작:

Tenant ID + Metric Name + Labels 조합을 해시 → 토큰 생성
Memberlist(Gossip 프로토콜) 기반 Hash ring 조회 → 담당 Ingester 3대 선택
3대에 동시 전송 → 과반수(2대) 응답 시 클라이언트에 성공 반환 (Mimir의 고가용성)

Quorum 일관성: RF=3, Quorum=2 (N/2+1). Ingester 1대 죽어도 읽기/쓰기 모두 정상.

Ingester — 이중 기록과 플러시

수신 샘플
    ├── in-memory Head Block (빠른 읽기용)
    └── WAL on EBS (장애 복구용)

2시간마다:
    Head Block → 압축 → Chunk 블록 파일
    → S3 업로드 완료 후 WAL truncate

StatefulSet 배포 이유 2가지:

WAL을 EBS 같은 영구 디스크에 유지해야 함
Pod 고유 네트워크 Identity 유지 → Querier가 2시간 이내 최신 데이터를 끊김 없이 읽어갈 수 있어야 함

→ 책 이론의 "Kafka 유실 방지 버퍼" = Mimir에서는 Ingester의 WAL이 동일 역할 수행

Read Path 상세

Query Frontend — Spiky Read 제어

책 5장의 "High Write / Spiky Read" 요구사항을 query-frontend가 해결한다.

① 쿼리 슈레딩 (Query Splitting):

"지난 30일 P99 레이턴시" 요청
    ↓ query-frontend가 1일 단위 30개 서브쿼리로 분할
    ↓ 30개 병렬 실행
    ↓ S3 블록도 일 단위로 분할되어 있음 → 30 Querier가 각자 다른 파일 블록 읽기
    ↓ Share-Nothing: 병목 전무

② Results Cache:

memcached 기반 (results-cache, chunks-cache, index-cache 3종)
캐시 히트 시 TSDB 조회 없이 즉시 반환
책의 "Redis 캐시" 역할

③ FIFO Queue + Query Scheduler:

출근 시간 수백 명 동시 대시보드 로딩 (Spiky Read)
    ↓
FIFO Queue에 적재 (TSDB로 바로 던지지 않음)
    ↓
Querier가 CPU/메모리 여유 있을 때만 Pull
    ↓
OOM 방지, 시스템 안정성 유지

Query Scheduler 없으면: query-frontend 수평 확장 시 큐가 인스턴스마다 분산 → 불균형. Scheduler가 큐를 단일 관리.

Querier — 데이터 소스 2원화

데이터 출처

최근 2시간 이내	Ingester 직접 조회 (in-memory)
2시간 이상 장기	Store Gateway → S3 블록 조회

Store Gateway는 stateful — bucket index를 로컬 디스크에 캐싱, 주기적으로 S3와 동기화.

Compactor 상세

→ 책 이론의 "저장소 계층 최적화"를 두 단계로 구현

수직 압축 (Vertical Compaction) — 중복 제거

동일 시간대(2h) 블록이 Ingester RF=3 때문에 3개 존재
→ 타임스탬프+값 완전 일치 샘플 2개 제거
→ 스토리지 1/3으로 압축

수평 압축 (Horizontal Compaction) — 블록 병합

2h 블록 여러 개 → 12h 블록 → 24h 블록
인접 시간 블록 병합 → 인덱스 크기 감소 → 쿼리 스캔 범위 축소

Split-and-Merge — 64GiB 한계 돌파

Prometheus 기본 규격: 인덱스 파일 최대 64GiB 제한.
장기 블록(24h 이상)은 이 한계를 초과할 수 있음.

Mimir 해결책:
블록 병합 시 series.hash() mod 32 → 32개 샤드 블록으로 분할 출력
각 샤드는 64GiB 이하 유지
→ 인덱스 크기 제한 없이 무한 수평 확장 가능

Multi-tenancy

HTTP Header: X-Scope-OrgId: tenant-id

각 Ingester가 테넌트별 독립 TSDB 유지
Compactor도 테넌트별 독립 압축
Grafana datasource에 custom header 설정으로 테넌트 격리

실용 활용: dev / stage / prod를 tenant로 분리 → 단일 Mimir 클러스터로 3개 환경 운용 가능.

Loki, Tempo와의 공통 아키텍처

Grafana에서 만든 3개 백엔드가 동일한 컴포넌트 구조를 공유한다.

컴포넌트 Mimir (Metrics) Loki (Logs) Tempo (Traces)

수신	Distributor	Distributor	Distributor
저장	Ingester	Ingester	Ingester
압축	Compactor	Compactor	Compactor
조회	Querier	Querier	Querier
쿼리 최적화	Query Frontend	Query Frontend	Query Frontend
장기 저장	S3	S3	S3

→ Mimir 운영 지식이 Loki, Tempo에 그대로 전이됨. Loki 데이터 모델도 Prometheus와 동일 (value만 float → string).

책 이론 → Mimir 구현 매핑 요약

책 5장 이론 Mimir 구현체

지표 수집기	Distributor
Kafka 유실 방지 버퍼	Ingester WAL (EBS)
수집기 해시 링 샤딩	Memberlist 기반 Hash ring + Quorum
TSDB	Ingester(최근) + Store Gateway + S3(장기)
질의 서비스	Querier
Redis 캐시	memcached (results/chunks/index 3종)
스파이크 읽기 제어	Query Frontend FIFO Queue + Query Scheduler
데이터 압축	Compactor 수직 압축 (dedup)
다운샘플링	Compactor 수평 압축 + Split-and-Merge

해당 글을 작성하기 위해 참고한 글 입니다.

https://joeunvit.tistory.com/19

Grafana mimir overview

Grafana mimir에 대한 전반적인 자료 수집 내용을 정리해봤습니다. Grafana Labs에서 Cortex 개발을 주도하고 있었지만, Mimir를 출시하면서 Cortex는 더 이상 개발하지 않습니다. https://grafana.com/blog/2020/01/16/

joeunvit.tistory.com

https://www.anyflow.net/sw-engineer/prometheus-large-scale-comparison

Prometheus: 대용량 처리 제품 비교

대용량 메트릭 운용을 위한 Prometheus 호환 제품 비교로 Thanos, Cortex, VictoriaMetrics, Mimir를 중심으로 다룬다. Prometheus는 대용량 처리를 위해 Federation 아키텍처를 제안하나 여러모로 제한이 있기에, 대

www.anyflow.net

[대규모 시스템 설계2] 5장 지표 모니터링 및 경보 시스템

Ry- — Wed, 3 Jun 2026 20:40:28 +0900

책의 이론 아키텍처 + 네이버 검색 SRE + 당근마켓 SRE 실제 구현 비교 정리

설계 범위 및 요구사항

처리 스케일

DAU 1억 명 기준
서버 풀 1,000개 × 풀당 서버 100대 × 서버당 지표 100개 = 천만 개 지표 수집
데이터 보관 및 다운샘플링 정책:

~ 7일    : Raw 그대로 보관 (실시간성 확보)
7 ~ 30일 : 1분 단위로 롤업(Roll-up) 후 보관
30일 ~ 1년: 1시간 단위로 다운샘플링 후 콜드 스토리지

비기능 요구사항

High Write / Spiky Read: 초당 수백만 건 쓰기, 읽기는 대시보드 조회/경보 시점에만 일시 폭증
낮은 질의 레이턴시: 대시보드 로딩과 경보 평가 신속 처리
안정성: 과부하 상태에서도 중요 경보 절대 누락 금지

데이터 모델

// 지표 이름 + 라벨(Key-Value) + 타임스탬프 + 값
cpu.load {host: "server-i631", env: "prod", zone: "us-west"} -> [1685670000, 65%]

⚠️ 카디널리티 폭발 (Cardinality Explosion) — 반드시 주의

라벨에 user_id, request_id 같이 무한히 변하는 값을 넣으면 TSDB 인덱스가 메모리를 초과(OOM)해서 전체 모니터링 시스템이 다운된다. 라벨의 고유 조합은 반드시 제한해야 한다. (샘플링 or mimir -> 컴팩터 이용)

전체 아키텍처 파이프라인

[지표 출처 / 에이전트]
        │
   (Pull / Push)
        ▼
[지표 수집기] ──(해시 링으로 샤딩)──> [수집기 클러스터]
        │
   (안전한 버퍼링)
        ▼
[Apache Kafka] ──> [스트림 처리 서비스] ──> [TSDB]
                                                │
                              ┌─────────────────┴──────────────────┐
                              ▼                                     ▼
                    [질의 서비스 + 캐시]                    [경보 관리자]
                              │                                     │
                              ▼                                     ▼
                     [시각화 (Grafana)]                  [Kafka] ──> [알림 채널]

수집 모델: Pull vs Push

항목 Pull 모델 (Prometheus) Push 모델 (CloudWatch, Datadog)

방식	수집기가 대상 서버를 주기적으로 스크랩	에이전트가 수집기로 직접 전송
상태 진단	쉬움 (안 오면 죽은 것)	별도 헬스체크 필요
짧은 생명주기 프로세스	불리 (스크랩 전 종료 가능)	유리
방화벽 복잡 환경	불리	유리
프로토콜	TCP (오버헤드 낮음)	UDP (지연 낮음)
데이터 신뢰성	미리 정의된 지표만 수집	인증 강제 필요

대규모 Pull 모델의 확장법: 수집기를 일관된 해시 링(Consistent Hashing Ring)으로 묶어 특정 수집기가 특정 서버군만 전담하도록 분산 샤딩.

카프카 — 유실 방지 버퍼

수집기와 TSDB 사이에 Kafka를 두는 이유:

TSDB 장애 시에도 데이터 유실 없이 Kafka가 보관
수집/처리 컴포넌트 사이의 결합도 감소
지표 이름/라벨 기준으로 파티션 분리 → 컨수머 그룹 병렬 처리

데이터 집계 지점 3가지

방식 특징 단점

수집 에이전트에서 집계	클라이언트 측, 단순 집계만 가능	복잡한 집계 불가
파이프라인에서 집계	저장 전 처리	원본 데이터 소실
질의 시 집계	Raw 보관 후 필요할 때 집계	속도 느림

1. 클라이언트(에이전트)에서 집계

앱 프로세스 안에서 이미 집계된 값을 노출하는 방식.

Prometheus client library

# SDK가 내부적으로 버킷별 카운트를 누적 집계
histogram = Histogram('http_request_duration_seconds',
                       buckets=[0.1, 0.5, 1.0, 2.0])
histogram.observe(0.3)  # SDK가 0.1~0.5 버킷 카운트 +1

Prometheus가 /metrics를 스크랩하면 이미 집계된 _bucket, _sum, _count만 받음. raw 요청 데이터는 존재하지 않음.

OTEL SDK

views:
  - selector:
      instrument_name: http.server.duration
    aggregation:
      type: explicit_bucket_histogram
      boundaries: [0.1, 0.5, 1.0]

한계: 각 인스턴스가 자기 것만 집계 → 서비스 전체 합산 불가. 퍼센타일 정밀도 낮음.

2. 파이프라인에서 집계

데이터가 TSDB에 들어가기 전 중간 단계에서 집계.

OTEL Collector — 파이프라인 집계의 대표 도구

processors:
  groupbyattrs:           # 수천 개 파드를 service 단위로 합산
    keys: [service.name, env]
  metricstransform:
    transforms:
      - include: http_requests_total
        action: update
        operations:
          - action: delete_label_value
            label: pod_id   # 고카디널리티 라벨 제거

[파드 1000개 → http_requests{pod_id="xxx"}]
        ↓  OTEL Collector groupbyattrs
[service="order-api" 단위 시계열 1개]
        ↓  TSDB

Prometheus Recording Rules (Prometheus의 파이프라인 집계에 해당)

groups:
  - name: aggregations
    interval: 1m
    rules:
      - record: service:http_requests:rate5m   # 미리 계산해 새 시계열로 저장
        expr: sum(rate(http_requests_total[5m])) by (service)

Grafana가 service:http_requests:rate5m을 조회하면 raw 데이터를 건드리지 않음 → 네이버 VictoriaMetrics Pre-calculate에서 10배 성능 개선.

한계: 저장 전 집계면 원본 소실 → 나중에 "파드별로 다시 보고 싶다"가 불가능.

3. 질의 시 집계

Raw 데이터를 그대로 저장해두고, 조회할 때마다 집계.

Prometheus PromQL

# Grafana 대시보드 로딩 시마다 실행
sum(rate(http_requests_total[5m])) by (service)
# 1000개 파드 × 5분치 raw 데이터를 매번 스캔해서 합산

Thanos / Cortex (대규모 분산 Prometheus)

[Prometheus 샤드 A] ──┐
[Prometheus 샤드 B] ──┼──→ Thanos Querier ──→ PromQL 실행 (질의 시 합산)
[Prometheus 샤드 C] ──┘

각 샤드는 raw를 보관, Thanos가 조회 시점에 분산 집계 → 당근마켓 Cortex가 이 패턴.

한계: 조회할 때마다 수백만 포인트 스캔 → 대시보드 로딩 느림. 아키텍처에서 Redis 캐시로 흡수하는 이유.

3가지 비교 정리

클라이언트 집계 파이프라인 집계 질의 시 집계

도구 예시	Prometheus SDK, OTEL SDK	OTEL Collector, Recording Rules	PromQL, Thanos Querier
원본 보존	❌	❌	✅
TSDB 부하	낮음	낮음	높음
유연성	낮음	중간	높음
속도	빠름	빠름	느림

실제 운용 패턴 (혼합 사용)

소규모 — Prometheus 단독

앱(SDK 집계) → Prometheus scrape → PromQL 질의 시 집계

중간 규모 — Prometheus + Recording Rules

앱(SDK 집계) → Prometheus scrape → Recording Rules 선행 계산 → PromQL

→ 네이버 VictoriaMetrics Pre-calculate 패턴

대규모 — OTEL + Thanos/Cortex

앱(OTEL SDK) → OTEL Collector(파이프라인 집계, 라벨 정리) → Prometheus 샤드(raw) → Thanos(질의 시 분산 집계)

→ 당근마켓 Cortex 패턴의 변형

선행 계산 (Pre-aggregation) — 핵심 성능 기법

대시보드를 열 때마다 수만 대 서버 지표를 실시간 합산하면 TSDB가 터진다.
백그라운드에서 무거운 쿼리를 미리 실행해 단일 타임 시리즈로 저장해두는 방식.

Prometheus: 레코딩 룰(Recording Rules)
VictoriaMetrics: 프리컴퓨터(Pre-calculate)
InfluxDB: Continuous Tasks

질의 서비스 + 캐시 계층

[그라파나 / 시각화]
        │
[질의 API 서버] ──> [Redis 캐시] ──(캐시 히트)──> 즉시 반환
        │
   (캐시 미스)
        ▼
      [TSDB]

수많은 개발자가 동시에 같은 대시보드를 열 때 TSDB 부하를 Redis 캐시로 흡수.

경보 시스템

[경보 설정 캐시]
       │
[경보 관리자] ──> [질의 서비스] ──> (이상 감지)
                                          │
                              [경보 저장소 (Cassandra)]
                                          │
                                       [Kafka]
                                          │
                              [경보 소비자] ──> 슬랙/이메일/PagerDuty

경보 관리자 핵심 기능

기능 설명

중복 제거 (Deduplication)	수백 대 파드에서 동일 에러가 동시 발생 → 단 하나의 알람으로 묶어서 전송
침묵 (Silencing)	인지된 점검/작업 중 특정 알람 뮤트 처리
그루핑 (Grouping)	관련 경보들을 하나로 묶어 맥락 파악 용이

저장소 계층 최적화

기법 설명

데이터 압축	Gorilla 압축, 델타 인코딩으로 디스크 I/O·용량 절감
다운샘플링	오래된 데이터는 해상도 낮춰서 저장 (1분 → 1시간 단위)
콜드 스토리지	오래된 다운샘플링 데이터를 S3 등 저렴한 스토리지로 이동

이론 vs 실제 기업 구현 비교

설계 항목 책 이론 네이버 검색 SRE 당근마켓 SRE

규모	DAU 1억, 천만 지표	수만 대 물리 장비, 수백 서비스	MAU 1,800만, 400개 워크로드
TSDB	InfluxDB / Prometheus	VictoriaMetrics	Cortex (프로메테우스 확장)
수집 모델	Pull/Push 선택 가이드	Pull 기반 + 라벨링 커스텀	로컬 프로메테우스 샤딩 + Cortex 집중
선행 계산	파이프라인 집계 권장	VictoriaMetrics Pre-calculate (10배 성능)	로키 레코딩 룰 (로그 캐싱)
경보 방식	배치 기반 주기적 평가	배치 → 스트리밍(Kafka) 전환	Prometheus Alert + Datadog 워치독
질의 서비스	질의 서버 + Redis 캐시	RDB 쿼리 메타 테이블 + WITH 템플릿	그라파나 직접 연동 + 네임스페이스별 대시보드
알람 관리	Alert Manager 중복 제거	스트리밍으로 1분 내 경보	깨진 유리창 법칙 기반 노이즈 관리
로그 저장	별도 파이프라인	Loki	Loki (비용 이유로 Datadog 로그 미사용)
시각화	Grafana 추천	Grafana + 커스텀 쿼리 DB 연동	Grafana + Datadog APM

각 기업이 가장 집중했던 포인트

네이버 검색 SRE — "경보 레이턴시 최소화 + 쿼리 관리 효율화"

문제: 배치 구조로 인한 2분 30초 이상의 경보 지연.
해결: 경보 파이프라인을 메시지 큐 기반 스트리밍 구조로 전환 → 1분 내외 경보.

실증: 2022 카타르 월드컵 당시 트래픽이 7배 폭증하는 순간, 경보 수신 후 3~4분 만에 장애 해소. 기존 시스템이었으면 경보가 오기 전에 다른 시스템으로 장애가 전파될 수 있었던 상황.

쿼리 관리: 200개 이상의 쿼리를 코드에서 분리해 RDB 테이블로 데이터화 + VictoriaMetrics WITH 구문으로 중복 제거 → 쿼리 30% 경량화, API 서버 재배포 없이 쿼리 변경 가능.

Before: 코드에 쿼리 하드코딩 → 변경 시 API 서버 재배포 필요
After:  RDB 쿼리 테이블 조회 → DB Row 수정만으로 실시간 변경

https://www.youtube.com/watch?v=j_5HOboU3lk&t=1486s

당근마켓 SRE — "소수 인원의 확장성 + 비용 절감 인프라 지원"

구조적 선택: 멀티 테넌시 대신 전사 단일 K8s 클러스터 + 프로젝트별 네임스페이스 분리.

역할 분리:

SRE: 인프라/네트워크/K8s 공통 영역 대시보드 (K8s 닥터, Istio 닥터) 구축
개발팀: 비즈니스 지표는 Datadog/Superset으로 직접 관리

깨진 유리창 법칙 기반 알람 관리:

평상시 노이즈 관리 → 진짜 장애 알람이 무시되지 않는 환경 구축
에러 로그가 너무 자주 튀면 개발팀에 "워닝 로그로 내려달라" 요청

비용 절감 + 안정성 동시 달성:

CPU 리밋 해제   → 노드 스로틀링 모니터링 강화
스팟 인스턴스   → 파드 에비션 리스트 대시보드 추가
멀티 AZ         → 리전 스큐(Region Skew) 모니터링 추가

https://www.youtube.com/watch?v=3iLTBBC9ZX4

모니터링 방법론 3가지

방법론 제안자 핵심 지표 적합 대상

USE	Brendan Gregg (Netflix)	Utilization, Saturation, Errors	인프라/시스템 자원
RED	Tom Wilkie (Google)	Rate, Errors, Duration	애플리케이션/서비스
4 Golden Signals	Google SRE Book	Latency, Traffic, Errors, Saturation	분산 시스템 전반

핵심 교훈 정리

네이버는 선행 계산(Pre-aggregation) 원리를 VictoriaMetrics 프리컴퓨터로 구현해 수만 대 검색 장비의 조회 지연을 10배 개선했다.

당근마켓은 안정적 파이프라인 + 포스트모템 문화를 Cortex/Loki 인프라와 매주 목요일 5-Whys 회고로 실현해 지식 공유의 선순환을 만들었다.

두 기업 모두 오픈소스를 그대로 쓰지 않고, 자사 규모와 팀 상황에 맞게 트레이드 오프를 선택하여 커스텀했다.

AWS VPC 물리서버 기준 통신 원리

Ry- — Mon, 1 Jun 2026 20:42:41 +0900

AWS VPC 물리서버 기준 통신 원리

https://gasidaseo.notion.site/AWS-VPC-1f7cdcb19a784e2b97fa73466d269053#a5da4600197f438ea28970580e348c09

해당 내용의 글을 보고 내용을 한번 정리해보았습니다. 이때 추가적으로 나오는 궁금한 사항들을 포함해서 이어서 정리해보았습니다.

핵심 전제 — AWS 네트워크 3대 원칙

1. 브로드캐스트/멀티캐스트 전면 차단

온프레미스에서는 모르는 MAC 주소를 찾기 위해 ffff:ffff:ffff로 브로드캐스트를 뿌린다.
AWS 데이터센터에는 수십만 고객의 EC2가 공존하므로 이를 허용하면 전체 망이 마비된다.

클라우드 3사 모두 동일: AWS(유니캐스트만), GCP(유니캐스트만), Azure(멀티캐스트/브로드캐스트 차단)

영향 받는 온프레미스 기술들 (클라우드에서 그대로 못 씀):

HSRP / VRRP (라우터 이중화)
Tomcat Clustering
Oracle WebLogic Clustering
→ 클라우드에서는 유니캐스트 기반 이중화로 대체 필요

2. 매핑 서버 (Mapping Service / SDN 컨트롤러)

브로드캐스트 없이 주소를 찾기 위한 AWS의 핵심 인프라.
전 세계 EC2의 주민등록 DB 역할:

보유 정보:
  VPC ID + 가상 IP + 가상 MAC + 물리 서버 실제 IP

하이퍼바이저가 ARP 브로드캐스트를 가로채고 → 매핑 서버에 유니캐스트로 질의
권한 없는 통신 차단: 매핑 서버가 보안 그룹(Security Group) / NACL 규칙을 검증(Validation)하여 허용되지 않은 트래픽 차단
결과를 하이퍼바이저 매핑 캐시에 저장 → 이후 통신은 캐시 활용 (매핑 서버 재질의 불필요)

3. 오버레이 네트워크 (Overlay Network)

EC2가 보는 세계 (가상):          실제 물리 세계:
  src: 10.1.1.1 / aa11             src: 192.168.0.1
  dst: 10.1.1.2 / aa12      →      dst: 192.168.0.2
                                    (+ 가상 패킷 캡슐화)

EC2는 가상 IP/MAC만 보고, 하이퍼바이저가 물리 주소로 캡슐화(Encapsulation)하여 실제 전송.
수신 측 하이퍼바이저가 디캡슐화(Decapsulation)하여 EC2에 전달.

캡슐화 프로토콜: Geneve 또는 VXLAN (AWS 내부 구현)

ENI (Elastic Network Interface) — 가상 랜카드

EC2에 붙는 가상 네트워크 인터페이스.

EC2
 └── ENI (가상 랜카드)
       ├── 가상 IP (Private IP)
       ├── 가상 MAC
       ├── 보안 그룹 적용 지점  ← 패킷이 ENI를 통과할 때 SG 검사
       └── EIP 연결 가능

보안 그룹은 ENI 단위로 적용됨
EC2에 ENI 여러 개 붙이기 가능 (멀티홈 구성)

1. 동일 VPC — 동일 서브넷 — EC2 간 통신

상황: 서로 다른 물리 서버에 있는 EC2-1(10.1.1.1) → EC2-2(10.1.1.2) 최초 통신

ARP 단계 (가상 ARP를 유니캐스트로 처리)

EC2-1
 → ARP Request 브로드캐스트 발송
    ↓
 하이퍼바이저가 가로챔 (브로드캐스트 외부 차단)
    ↓
 매핑 캐시 확인 → 없음
    ↓
 매핑 서버에 유니캐스트 질의
 ("vpcA의 10.1.1.2 MAC과 물리 서버 위치는?")
    ↓
 매핑 서버 응답: MAC=aa12, 물리서버=192.168.0.2
    ↓
 매핑 캐시에 저장
    ↓
 EC2-1에 가짜 ARP Response 전달 → aa12 학습 완료

실제 데이터 전송 단계 (캡슐화 통신)

EC2-1
 → ping 패킷 (src: 10.1.1.1/aa11, dst: 10.1.1.2/aa12)
    ↓
 하이퍼바이저: 매핑 캐시 조회 → 캡슐화
 [물리 헤더: src 192.168.0.1, dst 192.168.0.2]
 [VPC ID: vpcA]
 [가상 패킷: 10.1.1.1 → 10.1.1.2]
    ↓
 물리 스위치: FCS(CRC) 에러 검사 → 정상 패킷만 통과
    ↓
 물리서버(192.168.0.2) 도착
    ↓
 하이퍼바이저: 디캡슐화 → VPC ID 확인 → 보안 그룹 검증
    ↓
 EC2-2의 ENI에 최종 전달

FCS (Frame Check Sequence): 물리 장비(광케이블, 스위치) 통과 시 CRC 계산으로 비트 오류 검출.
오류 있으면 패킷 드롭. 물리 계층(L1/L2) 무결성 보장.

이후 통신: 매핑 캐시 활용 → 매핑 서버 재질의 없이 캡슐화 고속 통신 반복

2. 동일 VPC — 다른 서브넷 — EC2 간 통신

상황: 10.1.1.2(EC2-1) → 10.1.2.2(EC2-3) (다른 서브넷)

핵심 차이: L3 라우팅 필요

같은 서브넷은 L2(MAC)로 직접 통신 가능.
다른 서브넷은 라우터(L3)를 경유해야 한다.

EC2-1 (10.1.1.2)
 → 서브넷 마스크 계산: 목적지(10.1.2.2)는 다른 대역
 → 직접 ARP 하지 않고, 기본 게이트웨이(가상 라우터 10.1.1.1)로 전송
    ↓
 AWS 가상 라우터 수신
 → VPC 라우팅 테이블 확인:
   10.1.0.0/16 → Local (VPC 내부)
    ↓
 L2 헤더 변경 (라우터를 경유했으므로 MAC 주소 변경)
    ↓
 하이퍼바이저: 매핑 서버 조회 → EC2-3의 물리 서버(192.168.1.2) 확인
 → 캡슐화하여 물리망 전송
    ↓
 물리서버(192.168.1.2) 도착 → 디캡슐화 → EC2-3 전달

라우팅 테이블 기반 단번 이동: 라우터는 모든 곳을 탐색하지 않고 CIDR 이정표를 보고 목적지를 단번에 결정한다.

3. VPC → (Edge 장비) → 외부 통신

VPC 사설 대역을 벗어날 때는 AWS Edge 장비 (Blackfoot Edge Device)를 무조건 경유.
라우팅 테이블에 전용 가상 장치를 명시적으로 연결해야 통신 성립.

3.1 인터넷 게이트웨이 (IGW) → 일반 인터넷

EC2 (10.1.1.2)
 → 목적지 8.8.8.8
 → 라우팅 테이블: 0.0.0.0/0 → IGW
 → 하이퍼바이저: IGW(Edge 장비, 192.168.0.100)로 캡슐화 전송
    ↓
 IGW(Edge 장비)
 → 캡슐 제거 → VPC ID 검증
 → EC2의 사설 IP(10.1.1.2) → EIP(59.1.1.2)로 NAT 수행
 → 인터넷으로 발송

EIP(탄력적 IP)가 없으면: 인터넷 통신 불가. EC2에 EIP 또는 Public IP 할당 필수.

3.2 관리형 VPN (Virtual Private Gateway) → 온프레미스 본사

EC2 → 온프레미스 사설 대역(172.30.0.0/16)
 → 라우팅 테이블: 172.30.0.0/16 → VGW
 → Edge 장비에서 IPSec 암호화 터널링
 → 인터넷 공용망을 통해 본사 VPN 장비에 안전하게 전달

IPSec: 공용 인터넷을 통해 데이터를 암호화하여 마치 전용선처럼 안전하게 통신.

3.3 다이렉트 커넥트 (Direct Connect) → 본사 물리 전용선

	VPN	Direct Connect
경로	인터넷 공용망	물리 전용선
보안	IPSec 암호화	전용선 자체가 격리
속도/안정성	인터넷 품질에 의존	보장된 대역폭
비용	저렴	고가

EC2 → 본사 전용선
 → Edge 장비에서 Q-in-Q VLAN 태깅 (이중 VLAN 헤더 추가)
 → AWS ↔ 기업 간 물리 광케이블 전용선으로 전송

3.4 게이트웨이 엔드포인트 → S3 / DynamoDB

EC2 → S3 버킷
 → 라우팅 테이블: S3 prefix list → Gateway Endpoint
 → Edge 장비: VPC Endpoint ID를 헤더에 추가
 → AWS 내부 백본망으로 고속 전달 (인터넷 미경유)

장점: 인터넷을 타지 않으므로 더 안전하고 빠름. NAT Gateway 비용 절감.

Gateway Endpoint vs Interface Endpoint 비교

Gateway Endpoint Interface Endpoint (PrivateLink)

대상 서비스	S3, DynamoDB만	나머지 모든 AWS 서비스
구현 방식	라우팅 테이블 기반, Edge 장비 경유	ENI로 VPC 안에 프라이빗 IP 생성
내부 처리	Edge 장비 + Endpoint ID 치환	Hyperplane 인스턴스 경유
비용	무료	시간당 + 데이터 전송 요금

Hyperplane: AWS가 만든 가상 라우팅 칩셋. Interface Endpoint, NAT Gateway, NLB 등의 내부 처리를 담당하는 AWS 내부 분산 시스템.

전체 흐름 요약

[같은 서브넷] EC2 → 하이퍼바이저 ARP 프록시 → 매핑 서버 → 캡슐화 → 물리망 → 디캡슐화 → EC2
[다른 서브넷] EC2 → 가상 라우터 → L2 헤더 교체 → 캡슐화 → 물리망 → EC2
[인터넷]      EC2 → IGW(Edge) → NAT(사설→공인 IP) → 인터넷
[VPN]         EC2 → VGW(Edge) → IPSec 암호화 → 인터넷 터널 → 본사
[전용선]      EC2 → DX(Edge) → Q-in-Q VLAN → 광케이블 → 본사
[S3/DynamoDB] EC2 → Gateway Endpoint(Edge) → AWS 백본 → S3
[기타 AWS 서비스] EC2 → Interface Endpoint(Hyperplane) → AWS 서비스

Docker란?

Ry- — Mon, 1 Jun 2026 10:02:15 +0900

01 Docker 기초

CKA 공부를 시작하면서 기초적인 Docker에 대한 내용을 한번 정리 해보았습니다.

Docker 등장 배경 — Before Docker

개발(Dev) / 테스트(Test) / 운영(Prod) 환경이 각각 독립된 VM으로 운영되던 시절의 문제:

문제 내용

의존성 불일치	Dev는 Python 3.4, Prod는 Python 3.1 → 배포하면 깨짐
비효율적 자원 사용	VM마다 OS 따로 설치 → 스토리지 낭비, 라이선스 비용
복잡하고 오류 잦은 배포	팀마다 수동 설치, 포트/라이브러리 설정이 제각각
격리 부재	같은 VM에 앱 여러 개 → 포트 충돌, 라이브러리 충돌

"내 컴퓨터에서는 되는데요" — Docker 이전의 고질적 문제

Docker란?

컨테이너화(Containerization) 플랫폼 — 애플리케이션을 모든 의존성과 함께 패키징해 어디서든 동일하게 실행되도록 함.

배송 컨테이너 비유

배송 컨테이너 Docker

규격 표준화	Dockerfile로 구조 표준화
어디든 운반 가능	Docker Engine만 있으면 어디서든 실행
내용물 격리	컨테이너별 독립 환경
필요한 만큼 추가	컨테이너 수평 확장

Docker가 해결하는 것

표준화: Dockerfile이라는 통일된 형식
이식성: Docker Engine만 있으면 Mac, Linux, Windows 어디든 동일 동작
격리: 컨테이너마다 독립 환경 → 충돌 없음
효율: 컨테이너는 Host OS 커널 공유 → VM보다 가볍고 빠른 부팅

VM vs Docker 아키텍처

VM 구조                          Docker 구조
─────────────────────            ─────────────────────
물리 서버                         물리 서버
  └── Hypervisor                   └── Hypervisor (선택)
        ├── OS + App 1                   └── VM (Linux OS)
        ├── OS + App 2                         └── Docker Engine
        └── OS + App 3                               ├── Container 1
                                                     ├── Container 2
                                                     └── Container 3

VM: OS를 각각 설치 → 무겁고 느림
Docker: Host 커널 공유 → 가볍고 빠른 부팅
실제로는 VM 위에 Docker Engine 설치해서 사용하는 게 일반적

핵심 개념 3가지

Docker Image

Dockerfile로 만들어진 빌드 결과물
코드 + 모든 의존성(라이브러리, 설정 파일 등) 포함
불변(Immutable) — 한번 만들면 내용이 변하지 않음
생성 명령어: docker build

Docker Container

Image의 실행 인스턴스
Image = 설계도, Container = 실제로 돌아가는 것
실행 명령어: docker run

Docker Registry

Image를 저장하고 배포하는 저장소
docker push로 업로드, docker pull로 다운로드

종류 예시

공개 Registry	Docker Hub, Ubuntu 이미지 등
비공개 Registry	AWS ECR, Azure ACR, JFrog Artifactory, Nexus

Docker Engine 구성

Docker CLI  →  REST API  →  Docker Daemon
 (대시보드)      (배선)        (엔진/두뇌)

구성요소 역할

Docker CLI	사용자가 명령을 입력하는 인터페이스 (docker build, docker run 등)
REST API	CLI 명령을 Daemon이 이해하는 HTTP 형식으로 변환
Docker Daemon	실제로 이미지 빌드, 컨테이너 실행 등을 수행하는 핵심 프로세스

Docker 워크플로우

개발자
  1. 코드 작성 + Dockerfile 작성 (버전 관리 시스템에 저장)
  2. docker build → Docker Image 생성 (로컬 저장)
  3. docker push  → Docker Registry에 업로드
  4. docker run   → 로컬 VM에서 컨테이너 실행 (개발 검증)

DevOps 팀
  5. docker pull  → Registry에서 Image 다운로드
  6. docker run   → 테스트/운영 환경에서 동일하게 실행

Dev에서 동작하면 Test, Prod에서도 동일하게 동작 → "내 컴퓨터에서는 되는데요" 문제 해결

의존성(Dependency)이란?

애플리케이션이 실행되기 위해 필요한 모든 것:

Docker Engine (컨테이너 실행 환경)
런타임 (Java 9, Python 3.4 등)
라이브러리
설정 파일 (DB 연결 정보 등)

→ Docker Image 안에 이 모든 것을 함께 패키징

Dockerfile 예시 (최소)

FROM ubuntu:latest       # 베이스 이미지 지정
CMD ["echo", "hello docker"]  # 컨테이너 실행 시 실행할 명령

현대 DevOps에서의 역할 분담

역할 주요 책임

Developer	코드 작성 + Dockerfile 작성 (99% 케이스)
DevOps Engineer	Dockerfile 검토, Registry 관리, 배포 자동화 (CI/CD)

https://www.youtube.com/watch?v=r3QWVLeA5qM&list=PLmPit9IIdzwRjqD-l_sZBDdPlcSfKqpAt&index=2

AI Expo 26 후기

Ry- — Tue, 12 May 2026 20:50:48 +0900

시간: 05/06(수) - 05/08(금) 10:00 - 17:00
장소: 코엑스 Hall A
코엑스 : https://www.coex.co.kr/exhibitions/국제인공지능대전-2/
국제인공지능대전: http://www.aiexpo.co.kr/home/v4.php?s=34

이번에 아는 지인분의 정보공유로 AI Expo에 다녀왔습니다.

5월 6일 부터 8일까지 운영을 했는데 금요일은 일반 관람객들도 다 올 수 있는 형태로 열려있어 저는 금요일날 방문했습니다.

이번 엑스포의 취지는 AI 모델들이 요즘 실생활에서 많이들 볼 수 있는데 이러한 AI 모델을 어떻게 사용하고 있고, 클라우드 부트캠프를 수료하고 보니 AI 모델들이 클라우드 환경에서는 어떻게 사용되고 있는지 궁금해서 찾아가게 되었습니다.

이떄가 11시쯤인데요 박람회가 10시에 시작하는거 치고 사람들이 되게 많이 서있는것을 볼 수 가 있었습니다.

그래도 생각보다 빠르게 줄이 줄어들었고 금방 들어갔습니다.

주요 주제들은 AI 솔루션, AI 인프라 및 플랫폼 , AI + X 융합이 있었습니다.

넥스브이 부스 마음 상담

여러 제품들을 확인하고 궁금했던 내용들을 물어보기도 했었습니다.

컨벤션장 기준으로 오른쪽 부스에서는 대부분 AI를 활용한 비서, RAG 기술, 데이터를 보다 쉽게 처리할 수 있는 솔루션들을 선보이고 있었습니다. 다양한 솔루션을 둘러보면서 가장 크게 든 생각은 이러한 아이템들이 실제로 경쟁력이 있을까 하는 점이었습니다.

특정 도메인에 강점을 갖고 있지 않은 형태라면 해당 솔루션을 선뜻 도입하기 어렵겠다는 생각이 들었습니다. 한 가지 예로 삼일회계법인은 다른 기업들과 동일하게 멀티모달 LLM 솔루션을 운영하고 있었는데, 삼일이 보유한 회계 도메인 전문성이 해당 모델에 잘 녹아든다면 더 큰 시너지를 낼 수 있겠다는 생각이 들었습니다. 그 외의 경우에는 크게 차별점이 느껴지지 않았습니다.

'AI의 끝은 피지컬 AI'라는 말을 들은 적이 있는데, 이번 행사에서도 많은 기업들이 피지컬 AI를 개발하고 도입하고 있는 것을 확인할 수 있었습니다. AI 기술이 점점 고도화되면서 실체 있는 형태로 다양한 산업에 적용될 것 같습니다.

부스를 돌면서 계속 느낀 건 결국 데이터가 핵심이 될 것 같다는 점이었습니다. 클라우드를 공부하고 있는 입장에서 데이터를 안전하고 효율적으로 처리하는 방법(SaaS, 온프레미스 등 다양한 형태)에 대해서도 더 깊이 고민해봐야겠다고 생각했습니다. MinIO 부스에서는 서비스 구현 방식, DR 방식, 서비스 형태 등을 직접 질문하면서 궁금했던 부분들을 해소할 수 있었습니다.

한 가지 아쉬웠던 점은 기업 채용 동향이나 AI 발전에 따른 인력 수요 변화 같은 부분을 대표님께 직접 여쭤보지 못한 것입니다. 다음 기회에는 꼭 물어봐야겠다고 생각했습니다.

[대규모 시스템 설계 기초 2] 4장 분산 메시지 큐

Ry- — Tue, 12 May 2026 20:10:18 +0900

대규모 시스템 설계 공부하다가 생긴 궁금증들

시작하며

《대규모 시스템 설계 기초 2》를 읽으면서 분산 메시지 큐 챕터를 정리하다 보니, 책에 나온 내용보다 오히려

"근데 이건 왜 이렇게 하는 거지?", "이게 그거랑 같은 개념인가?" 싶은 질문들이 계속 쌓였습니다.

이 글은 단순한 요약이 아니라 공부하면서 파생된 궁금증들을 하나씩 짚어보면서 정리한 글입니다.

비슷하게 공부하시는 분들께 도움이 되길 바랍니다.

메시지 큐 vs 이벤트 스트리밍 플랫폼, 뭐가 다른가?

4장 첫 주제 가장 먼저 정리가 필요했던 개념입니다.

항목메시지 큐이벤트 스트리밍 플랫폼

재소비	불가 (소비 후 삭제)	가능 (로그 보관)
소비 형태	1:1	발행-구독
순서 보장	보통 미보장	파티션 내 보장
저장 방식	메모리 기반	디스크 기반
예시	RabbitMQ, SQS	Kafka, Pulsar

가장 큰 차이는 두 가지입니다. 한 번 보낸 메시지를 다시 읽을 수 있냐, 그리고 여러 소비자가 구독 형태로 메시지를 처리하냐입니다.

예를 들어 Kafka는 같은 메시지를 분석 서비스, 알림 서비스, 로그 서비스가 각각 독립적으로 읽을 수 있어요. RabbitMQ는 한 번 소비되면 사라집니다.

1단계. 요구사항 정의

기능적 요구사항

텍스트 메시지만 지원
생산된 순서 그대로 유지 (전통적 메시지 큐는 순서 미보장)
메시지 지속성 보장 (디스크 저장, 장애 후에도 복구 가능)
최소 한 번 전달 지원
소비자 설정에 따라 전달 방식 선택 가능

비기능적 요구사항

높은 처리량(대역폭)과 낮은 전송 지연 동시 지원
수평적 확장 가능
장애 내성 (고가용성)

단대단(End-to-End)이란? 책에서 "단대단 지연"이라는 표현이 나오는데, 이건 생산자가 메시지를 보내는 시점부터 소비자가 받는 시점까지의 전체 구간을 의미합니다. 중간에 거치는 네트워크, 브로커 처리, 디스크 쓰기 등을 모두 합친 시간이 짧아야 한다는 뜻이에요.

2단계. 개략적 설계

발행-구독 모델과 토픽

발행-구독 모델의 핵심은 토픽입니다. 생산자가 특정 토픽에 메시지를 발행하면, 그 토픽을 구독하는 소비자 그룹들이 메시지를 받는 구조예요.

데이터 양이 많아지면 서버 한 대로 처리가 불가능하기 때문에, 파티션 샤딩 기법으로 토픽을 여러 파티션으로 분리합니다.

Topic: orders
  Partition 0 → Broker 1
  Partition 1 → Broker 2
  Partition 2 → Broker 3

같은 키를 가진 메시지 → 항상 같은 파티션 (순서 보장)
키가 없는 메시지 → 무작위 파티션으로 전송
파티션 내 메시지 위치는 오프셋으로 관리

소비자 그룹

같은 그룹 안의 소비자들이 파티션을 나눠서 병렬 처리합니다.

Topic: orders (Partition 0, 1, 2) 

Group A: C1→P0, C2→P1, C3→P2  ← 각각 다른 파티션 담당
Group B: C4→P0, C5→P1, C6→P2  ← Group A와 독립적으로 동일 메시지 소비

"같은 그룹 내 C1, C2가 동일 메시지를 읽을 수 없나요?" 맞습니다. 같은 그룹 안에서는 하나의 파티션을 한 소비자만 담당해요. C1이 P0을 맡으면 C2는 P0을 읽을 수 없습니다. 이게 결국 1:1처럼 보이지만, 같은 메시지를 여러 시스템이 처리해야 한다면 다른 그룹으로 구성하면 됩니다. Group A와 Group B는 서로 독립적으로 같은 메시지를 읽을 수 있거든요.

전체 구성요소

Application Server
  → Producer (버퍼 + 라우팅)
    → Broker 1 (Leader Partition 0) ─┐
    → Broker 2 (Leader Partition 1)  ├── 각자 팔로워에게 복제
    → Broker 3 (Leader Partition 2) ─┘
      → Consumer Group A (서비스 A)
      → Consumer Group B (서비스 B)

별도로
  → ZooKeeper / KRaft (코디네이터, 리더 선출, 메타데이터)

리더와 코디네이터는 다른 역할입니다. 리더 브로커는 특정 파티션의 읽기/쓰기를 담당하고, 코디네이터는 소비자 그룹 관리와 리밸런싱을 담당해요. 브로커 하나가 여러 파티션의 리더를 맡으면서 동시에 특정 소비자 그룹의 코디네이터 역할도 할 수 있지만, 같은 개념은 아닙니다.

파티션 복제 브로커가 별도로 분리된 게 아닙니다. 브로커 1, 2, 3이 각각 어떤 파티션의 리더이면서 동시에 다른 파티션의 팔로워예요. 리더/팔로워는 브로커의 고정 역할이 아니라 파티션 단위 역할입니다.

Broker 1: Partition 0 리더, Partition 1 팔로워, Partition 2 팔로워
Broker 2: Partition 0 팔로워, Partition 1 리더, Partition 2 팔로워
Broker 3: Partition 0 팔로워, Partition 1 팔로워, Partition 2 리더

3단계. 상세 설계

데이터 저장소 — 왜 DB가 아니라 WAL인가?

읽기/쓰기가 빈번하고, 갱신/삭제는 거의 없는 특성상 일반 DB는 오버헤드가 큽니다.

저장소문제점

RDB	빈번한 읽기/쓰기에 오버헤드, 데이터 모델 부적합
인메모리	용량 한계, 장애 시 유실
WAL 디스크	순차 쓰기로 고성능, 영속성 보장 ✅

WAL + 세그먼트 구조로 저장합니다.

/partition-0/
  00000000.log    ← 실제 메시지 (바이너리)
  00000000.index  ← offset → byte 위치 매핑
  00001000.log
  00001000.index

파일 하나에 계속 쌓으면 OS 파일 핸들링 한계에 부딪히고 오래된 메시지 삭제도 불가능해집니다. 세그먼트로 나누면 오래된 세그먼트를 파일 통째로 삭제할 수 있어요.

실제로 SSD인지 HDD인지, 어떻게 읽고 쓰는지? Kafka는 OS의 sendfile() 시스템 콜과 페이지 캐시를 활용합니다. 클라우드 환경(AWS MSK 등)은 대부분 SSD 기반이에요. 쓰기는 Java의 FileChannel.write()로 순차 append하고, 읽기는 transferTo()(제로카피)를 사용합니다. 제로카피는 디스크→커널 버퍼→네트워크로 유저 공간을 거치지 않아 복사 횟수를 줄여 처리량을 높입니다.

페이지 캐시 활용도 중요한 포인트입니다.

생산자가 방금 쓴 메시지
→ 소비자가 바로 읽으면 디스크 접근 없이 OS 페이지 캐시에서 서빙
→ 디스크 I/O 최소화

Kafka가 JVM 힙 메모리를 작게 쓰는 이유도 이 때문이에요. 대신 OS 페이지 캐시를 최대한 활용합니다.

메시지 구조

필드설명

topic	메시지가 속한 토픽
partition	파티션 번호
offset	파티션 내 위치
timestamp	생성 시각
key	파티션 결정용
value	실제 데이터 (바이너리)
size	메시지 크기
CRC	무결성 검사

CRC 종류가 여러 가지인데 Kafka는 뭘 쓰나요? Kafka는 CRC32C를 사용합니다. 패리티 검사, 해밍 코드 같은 건 오류 정정(FEC)용이라 목적이 달라요. CRC는 오류 탐지만 하고, 해밍 코드는 탐지+정정까지 해요. 메시지 전송 무결성 확인용으로는 CRC32C가 속도와 신뢰성 균형이 좋습니다.

생산자 측 작업 흐름

Producer
  → 메시지 직렬화 (바이너리)
  → 키 해싱으로 파티션 결정 (hash(key) % partitionCount)
  → 사본 분산 계획 캐시 조회 (어느 브로커가 리더?)
  → 리더 브로커에 직접 전송
  → 버퍼에 모아서 배치로 전송

메시지 키 해싱은 누가 처리하나요? 브로커가 아니라 **생산자(Producer)**가 처리합니다. 생산자 내부 라우팅 로직에서 파티션을 결정한 후 해당 파티션의 리더 브로커로 직접 전송해요. 브로커는 그냥 받아서 저장만 합니다.

버퍼가 어떻게 네트워크를 거칠 필요가 없다는 건가요? 원래 라우팅 계층이 별도 서버로 존재하면 생산자→라우터→브로커 2번 네트워크를 거쳐야 해요. 라우팅 로직을 생산자 내부로 편입시키면 생산자→브로커 1번만 거치면 됩니다. 버퍼는 그 내부에서 메시지를 모아서 한 번에 배치 전송하는 역할이에요. 즉 버퍼는 일괄처리(배치)를 위해 두는 것입니다.

linger.ms 높임 → 더 많이 모아서 전송 → 처리량 증가, 지연 증가
linger.ms 낮춤 → 바로 전송              → 처리량 감소, 지연 감소

소비자 측 작업 흐름

방식설명단점

푸시	브로커가 소비자에게 밀어넣음	소비자 처리 속도보다 빠르면 부하 폭증
풀	소비자가 직접 요청	메시지 없어도 계속 폴링 → 자원 낭비
롱폴링	메시지 생길 때까지 연결 유지	풀의 자원 낭비 문제 해결 ✅

Kafka는 풀 + 롱폴링 방식을 채택합니다.

컴퓨터 자원을 어떻게 조절하나요? 소비자 쪽에서 max.poll.records, fetch.max.bytes 같은 설정으로 한 번에 가져올 메시지 양을 조절해요. 브로커는 각 소비자 그룹별로 오프셋만 관리하고, 실제 처리 속도 조절은 소비자가 담당합니다. 이게 풀 모델의 핵심 장점인 백프레셔(backpressure) 제어예요.

소비자 재조정 (Rebalancing)

소비자가 연결이 끊기거나 새로 추가되면 파티션을 재배치합니다.

[재조정 흐름]
1. Group Coordinator가 이상 감지 (하트비트 없음)
2. 모든 소비자에게 JoinGroup 요청
3. 리더 소비자가 파티션 재할당 결정
4. Coordinator가 각 소비자에게 결과 통보
5. onPartitionsRevoked() → onPartitionsAssigned() 콜백

주의할 점은 재조정 중에는 전체 소비가 잠시 중단된다는 거예요. CooperativeStickyAssignor를 사용하면 영향받는 파티션만 점진적으로 재조정해서 이 문제를 최소화할 수 있습니다.

상태 저장소와 메타데이터 저장소

상태 저장소 — 소비자별 파티션 오프셋 정보 저장

지속적 읽기/쓰기 → 데이터 일관성 중요
구버전: ZooKeeper에 저장
현재: __consumer_offsets 토픽 (Kafka 내부)으로 이전

메타데이터 저장소 — 토픽 설정, 파티션 수, 복제 설정 등 저장

변경 빈도 낮고 일관성 중요 → ZooKeeper 또는 KRaft 사용

주키퍼가 계층적이라서 뭐가 좋은 건가요? 파일 시스템처럼 /brokers/ids/1, /topics/orders/partitions/0 형태로 경로 구조를 갖고 있어요. 덕분에 특정 경로에 watch를 걸어 변경사항을 이벤트로 받을 수 있습니다. 브로커가 죽으면 해당 경로가 사라지고, watch 중인 컴포넌트가 즉시 감지하는 방식이에요.

etcd가 Kubernetes에서 쓰는 etcd랑 같은 건가요? 네, 완전히 같은 etcd입니다. 분산 키-값 저장소로 클러스터 상태, 리더 선출, 서비스 탐색 등에 사용돼요. Kubernetes는 클러스터 상태 관리에, Kafka는 브로커 상태/메타데이터 관리에 동일한 etcd를 사용할 수 있습니다.

복제 (Replication)

하드웨어 장애로 데이터가 사라지는 것을 방지하기 위해 복제를 사용합니다.

Partition 0
  Broker 1: Leader  ← 읽기/쓰기 모두 여기서
  Broker 2: Follower (ISR)
  Broker 3: Follower (ISR)

ack 모드

모드설명신뢰성속도

acks=0	응답 안 기다림	낮음	가장 빠름
acks=1	리더만 저장하면 OK	중간	중간
acks=all	ISR 전체 저장해야 OK	높음	느림

ISR(In-Sync Replica)은 리더와 동기화 상태인 복제본 목록입니다. 팔로워가 느리거나 끊기면 ISR에서 제거되고, 리더 장애 시 ISR 중 하나가 새 리더로 선출됩니다.

실제 운영에서는 어떻게 처리하나요? 대부분 acks=all + min.insync.replicas=2 조합을 씁니다. ISR이 2개 이상일 때만 쓰기를 허용해서 리더 장애 시 데이터 손실을 막아요. 결제 같은 민감한 시스템은 여기에 exactly-once까지 추가합니다.

메시지 전달 방식

방식유실중복사용 사례

최대 한 번 (At Most Once)	가능	없음	모니터링, 로그
최소 한 번 (At Least Once)	없음	가능	주문, 알림
정확히 한 번 (Exactly Once)	없음	없음	결제, 재고

java

// 최소 한 번
process(record);       // 처리 먼저
commitOffset();        // 그 다음 커밋 (장애 시 재처리 발생 가능)

// 정확히 한 번
producer.initTransactions();
producer.beginTransaction();
producer.send(...);
consumer.commitSync();
producer.commitTransaction();  // 전송+커밋 원자적 처리

실무에서는 대부분 최소 한 번 + 멱등성 처리(중복 방지 로직) 조합을 씁니다. 정확히 한 번은 성능 비용과 구현 복잡도가 큽니다.

세그먼트라는 단어, 어디서나 보이는데 같은 개념인가?

공부하다 보면 세그먼트라는 단어가 여러 곳에서 나옵니다. 헷갈릴 수 있어서 정리해봤어요.

맥락세그먼트 의미레벨

CPU 8086 레지스터	16비트 레지스터로 20비트 주소 접근	하드웨어
OS 메모리 관리	Code/Data/Stack/Heap 영역 분리	OS
TCP 네트워크	전송 단위 패킷	네트워크 4계층
Kafka	로그 파일 분할 단위	애플리케이션

전부 **"나눈다"**는 의미에서 같은 단어를 차용한 것이고, 기술적으로 같은 개념은 아닙니다. 세그먼트(Segment)의 영어 뜻 자체가 "조각, 구간"이라 분야마다 가져다 쓰는 거예요.

마찬가지로 오프셋도 맥락마다 다르게 사용됩니다. Kafka에서 오프셋은 메시지의 고유 순번이고, 세그먼트 파일명이 시작 오프셋이라 어느 파일에서 찾아야 할지 바로 알 수 있어 O(1)에 가까운 탐색이 가능합니다.

바이너리 저장 vs 세그먼트, 같은 개념인가?

이것도 헷갈렸던 부분입니다. 같은 단어를 다른 형태로 많이 사용해서 헷갈렸습니다.

바이너리는 저장 포맷, 세그먼트는 파일 관리 전략으로 독립적인 개념입니다.

Kafka는 두 가지를 함께 씁니다. 바이너리로 직렬화한 메시지를 세그먼트 파일에 저장하는 구조예요.

바이너리 직렬화 포맷 비교

포맷특징

Protocol Buffers (protobuf)	Google 개발, JSON 대비 3~10배 작음, 스키마 필요
Apache Avro	Kafka와 많이 사용, 스키마 함께 저장
MessagePack	JSON을 바이너리로 압축한 형태

파일 관리 전략 비교

방식대표 사례특징

단일 파일	Redis AOF	단순하지만 무한정 커짐
롤링 파일	Logback	날짜/크기 기준 교체
세그먼트	Kafka	offset 기반 탐색 최적화
스냅샷	Redis RDB	특정 시점 전체 상태 저장
WAL	PostgreSQL	장애 복구용
LSM Tree	Cassandra	쓰기 최적화

모니터링은 풀 모델인가, 푸시 모델인가?

책 내용과 연결되는 내용이라 같이 정리했습니다.

Prometheus → 풀(Pull) 모델. 주기적으로 각 서비스의 /metrics 엔드포인트를 직접 scrape
Loki → 푸시(Push) 모델. Promtail 같은 에이전트가 로그를 Loki로 밀어넣음
Grafana → 둘 다 아님. 시각화 도구로 Prometheus/Loki에서 데이터를 조회해서 표시

OpenTelemetry(OTel)는 둘 다 지원합니다.

서비스 → (push) → OTel Collector → (pull) → Prometheus
                                 → (push) → Loki
                                 → (push) → Jaeger (트레이싱)

풀 모델이 부하 제어에 유리한 이유는 수집기가 scrape 간격을 조절할 수 있기 때문입니다. OTel Collector가 중간에서 버퍼링/배치 처리도 해줘서 부하를 완화합니다.

배운 점

공부하면서 느낀 건, 개념을 단순히 외우는 것보다 "왜 이렇게 설계했을까"를 따라가는 게 훨씬 기억에 오래 남는다는 점입니다.

세그먼트를 왜 쓰는지, 버퍼가 왜 필요한지, 풀/푸시 중 왜 풀을 선택했는지를 이해하면 비슷한 상황에서 스스로 판단할 수 있게 됩니다.

마치며

분산 메시지 큐는 처음에는 개념이 많아서 복잡하게 느껴지지만, 전체 흐름을 한 번 잡고 나면 각 컴포넌트가 왜 그 자리에 있는지가 보이기 시작합니다.

이 글이 같은 책을 공부하시는 분들께 도움이 됐으면 좋겠습니다. 잘못된 내용이나 추가할 내용이 있으면 편하게 댓글로 알려주세요!

참고

《대규모 시스템 설계 기초 2》 4장 분산 메시지 큐
Apache Kafka Documentation
Kafka KRaft Mode

진짜 공격인 줄 알았는데 우리가 만든 장애였다

Ry- — Thu, 2 Apr 2026 22:35:29 +0900

안녕하세요

이번에는 KT Cloud Tech Up 과정에서 마지막 실무 프로젝트를 진행하면서 발생했던 문제를 하나 소개하고자 합니다.

저희 팀에서는 CDN을 CloudFlare로 사용하였습니다. 저번 프로젝트에 이미 Cloudfront을 사용해보기도 했고 여러번 경험을 해봤기 때문에 다른 CDN을 사용하고자 했습니다. 찾아보니 Versel 등 여러 CDN 서버들이 있더라고요 그중에 많이들 접근해봤고 알고 있는 CloudFlare을 사용해보자 했습니다.

다들 많이들 보셨을 겁니다.

그래서 본 내용에 들어가기 전에 저희 팀이 CloudFlare을 어떻게 도입했고 어떤 방식으로 사용중인지에 대해 간략하게 소개하고자 합니다.

AWS의 CDN 처럼 프론트 웹 페이지를 S3에 담아서 운영하지 않습니다. 저도 놀랐던게 깃허브에 있는 리퍼지토를 기반으로 바로 서비스를 하는 형태였습니다.

그리고 이제 이 페이지에 WAF 설정을 걸을수가 있습니다.

이렇게 WAF 옵션을 걸을수가 있습니다.

이떄 주요하게 살펴볼것은

OWASP 설정 부분 입니다.

OWASP Top 10은 웹에서 가장 위험한 보안 취약점 10가지 목록 입니다.

실제 공격 데이터를 기반으로 OWASP 재단이 주기적으로 발표하는 가이드 라인입니다.

Top 10:2025 List

하지만 WAF 설정으로도 막을 수없는 항목들이 있습니다.

이게 지금 얘기하려는 중요한 포인트입니다.

당시에 해당 프로젝트에서 보안 공격을 수행하는 기간이 있었습니다.

저희 서비스를 마음대로 공격하고 그거에 대한 취약점을 공격팀이 발견하면 피드백해서 저희는 고치고 개선하는 기간이였죠

실제 이런식으로 계속 공격이 들어왔습니다. 그리고 CloudFlare가 이런식으로 공격이 어떻게 들어오고 있고 이런거를 관제 할 수 있었죠

그 당시 로그인을 수행하던 도중에 갑자기 모든 API가 동작을 하지 않는 겁니다. 그래서 저희는 그 순간 공격을 받고 있는 줄 알고 어떻게 대처하지, 지금 모니터링 관제해서 어디부분을 공격하고 있는 이런거를 부랴부랴 찾기 시작했습니다.

모니터링도 동작하지 않고, 접근은 가능하지만 매트릭을 확인하지 못하는 상황이였습니다.

그러다가 RDS의 상태를 확인해봤는데 RDS의 상태가

현재 활동 세션의 상태가 이상했습니다. 거기 들어가서 확인해보니 특정 쿼리문을 수행하는데 58초가 걸리는 겁니다.

RDS는 야구 더미 데이터를 천만건을 넣어둔 상황이였습니다.

해당 쿼리문이 경기에 대한 모든 데이터를 join형태로 다 가져오는 형태로 구성되어 있었고 , 그 많은 경기가 다 가져와지는 상황이였습니다.

그래서 해당 문제를 백엔드팀과 공유하였고 개선 하였습니다.

그리고 RDS의 성능을 높였더니 이제 제대로 동작하였습니다.

이러한 부분들이 OWASP 10 A6 Insecure Design 부분 입니다.

사실 그 순간에는 정말 공격을 받고 있다고 생각해서 많이 당황했습니다. 하지만 돌이켜보면 외부의 공격보다 우리가 만든 코드가 더 위험했던 순간이었습니다. Cloudflare가 수많은 공격을 막아주고 있었지만, 정작 서비스를 멈추게 한 건 페이지네이션 하나 없이 천만 건을 통째로 조회하던 우리의 쿼리였으니까요. 앞으로는 기능 구현만큼이나 설계 단계에서의 보안 고민도 함께 가져가고 싶습니다.

WAF 성능은 잘되는거 같습니다!!

AWS SAA-CO3 합격 후기

Ry- — Sat, 7 Mar 2026 01:01:51 +0900

시험 개요

AWS SAA(Solutions Architect Associate)는 아키텍처 설계 능력을 평가하는 자격증으로, 아래 4가지 영역을 다룹니다.

보안 아키텍처 설계
복원력을 갖춘 아키텍처 설계
고성능 아키텍처 설계
비용에 최적화된 아키텍처 설계

유효 기간 : 3년
합격 점수 : 720점 이상
130분 동안 65 문제 진행 (ESL +30Minutes를 신청했을 경우, 160분)
- 사실 신청한 시간은 총 140/170분이지만, 실제 문제 풀이 시간은 130/160분이다. 왜냐하면 빠진 10분은 설문지 답변 시간으로 쓰이기 때문이다.
문제 유형 : 4지 택일형(보기 4개 중 1개 정답)과 복수 응답형(보기 5개 이상 중 2개 이상 정답)으로 구성
총 65문제 중 15문제는 채점 안됨 (실제 점수 채점되는 건 총 50문제이다.)

시험 장소 — 안양 앤아버어학원

https://m.place.naver.com/place/938306589/home

앤아버어학원 안양점 : 네이버

방문자리뷰 19 · 블로그리뷰 184

m.place.naver.com

시험은 안양에 위치한 앤아버어학원에서 응시했습니다.

예약 시간은 11시 45분이었는데, 11시 23분쯤 도착하자마자 바로 입실해서 시험을 시작할 수 있었습니다. 시험 전에 복습할 시간을 기대했지만, 예상보다 일찍 시작하게 되었네요.

시험실은 한 방에 약 7개의 개인 칸막이가 있는 구조였고, 저는 4번 자리에 앉았습니다. 히터 소음이 생각보다 있는 편이었는데, 시험에 집중하다 보니 크게 방해가 되지는 않았습니다. 다만 소음에 예민하신 분들은 참고하시면 좋을 것 같습니다.

시험 난이도 & 결과

13시 쯤 제출을 했고, 문제 난이도는 생각보다 평이한 편이었습니다. 65문제를 풀면서 "이 문제는 채점 안 되는 문제겠구나" 싶은 것들도 있었는데, 막상 결과는 턱걸이 합격이었습니다. 방심은 금물이네요

공부 방법 (약 1개월 준비)

약 한 달간 아래 세 가지 방식으로 준비했습니다.

1. 유데미 강의 스테판 마렉(Stephane Maarek)의 "AWS Certified Solutions Architect Associate 시험합격! 2025" 강의를 수강하며 전체 개념을 잡았습니다.

2. 모의고사 풀이(스테판) 모의고사 6세트를 풀면서 모르는 개념을 별도로 정리했습니다. (모의고사 문제가 생각보다 어려웠습니다.)

3. 덤프 문제 풀이 덤프 문제 약 380문제를 풀며 부족한 내용을 보완했습니다.

덤프 오답.pdf

0.87MB

개념 정리한 자료입니다. 여기에 몇 개념들이 빠진게 있으니 공부하면서 부족한 내용을 채워야 할 겁니다.

Terraform으로 EC2 관리하면서 겪은 AMI 필터링과 SSM 연결 이슈

Ry- — Wed, 25 Feb 2026 10:31:57 +0900

시작하며

Terraform으로 인프라를 관리하다 보면 "분명히 코드는 맞는 것 같은데 왜 안 되지?" 싶은 순간이 있습니다. 이번에는 AMI 필터링 설정 하나로 엉뚱한 이미지가 선택된 사건과, NAT Gateway와 EC2 시작 순서 때문에 SSM 연결이 안 됐던 경험을 공유해보려고 합니다.

저처럼 삽질하지 않으셨으면 하는 마음으로 정리했습니다.

문제 1: AMI 필터가 Minimal 버전을 잡아버림

문제 상황

EC2 인스턴스를 프로비저닝할 때, 항상 최신 Amazon Linux 2023 AMI를 자동으로 선택하도록 Terraform 코드를 작성했습니다.

################################################################################
# Amazon Linux 2023 AMI (최신 자동 조회)
################################################################################
data "aws_ami" "amazon_linux_2023" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["al2023-ami-*-x86_64"]  # ⚠️ 문제의 패턴
  }

  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }

  filter {
    name   = "architecture"
    values = ["x86_64"]
  }
}

resource "aws_instance" "main" {
  ami                    = data.aws_ami.amazon_linux_2023.id
  instance_type          = var.instance_type
  subnet_id              = var.private_subnet_id
  vpc_security_group_ids = [var.ec2_security_group_id]
  iam_instance_profile   = var.ec2_instance_profile_name
  monitoring             = true

  user_data = templatefile("${path.module}/user_data.sh.tftpl", {
    project     = var.project
    environment = var.environment
  })

  root_block_device {
    volume_type           = "gp3"
    volume_size           = 30
    delete_on_termination = false
    tags = {
      Name = "${var.project}-${var.environment}-ec2-root"
    }
  }

  tags = {
    Name = "${var.project}-${var.environment}-ec2"
  }

  lifecycle {
    ignore_changes = [ami]
  }
}

언뜻 보면 문제없어 보이지만, 실제로 이 코드를 적용했더니 의도치 않게 Minimal 버전 AMI가 선택됐습니다.

원인

al2023-ami-*-x86_64 패턴은 다음 두 가지를 모두 매칭합니다.

al2023-ami-2023.x.x-x86_64 → 일반 버전
al2023-ami-minimal-2023.x.x-x86_64 → Minimal 버전

most_recent = true 옵션 때문에 가장 최신 AMI가 선택되는데, 타이밍에 따라 Minimal 버전이 가장 최신으로 잡히면서 선택된 것이었습니다.

Minimal 버전은 SSM Agent를 포함한 여러 패키지가 빠져있어서, 이후 SSM 연결이나 자동화 작업에서 예상치 못한 문제가 생길 수 있습니다.

해결 방법

AMI filter의 name 패턴을 조금 더 구체적으로 수정해서 Minimal이 매칭되는 경우를 제외했습니다.

################################################################################
# Amazon Linux 2023 AMI (최신 자동 조회)
################################################################################
data "aws_ami" "amazon_linux_2023" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["al2023-ami-2023*-x86_64"]  # ✅ 수정된 패턴
  }

  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }

  filter {
    name   = "architecture"
    values = ["x86_64"]
  }
}

resource "aws_instance" "main" {
  ami                    = data.aws_ami.amazon_linux_2023.id
  instance_type          = var.instance_type
  subnet_id              = var.private_subnet_id
  vpc_security_group_ids = [var.ec2_security_group_id]
  iam_instance_profile   = var.ec2_instance_profile_name
  monitoring             = true

  user_data = templatefile("${path.module}/user_data.sh.tftpl", {
    project     = var.project
    environment = var.environment
  })

  root_block_device {
    volume_type           = "gp3"
    volume_size           = 30
    delete_on_termination = false
    tags = {
      Name = "${var.project}-${var.environment}-ec2-root"
    }
  }

  tags = {
    Name = "${var.project}-${var.environment}-ec2"
  }

  lifecycle {
    ignore_changes = [ami]
  }
}

al2023-ami-2023* 으로 바꾸면 이름이 반드시 2023으로 시작해야 하므로 minimal이 들어간 AMI는 자연스럽게 제외됩니다.

문제 2: NAT 재생성 후 SSM 연결이 안 됨

문제 상황

비용 절약을 위해 운영 시간 외에는 EC2와 NAT Gateway를 내리도록 관리하고 있었습니다. Terraform으로 compute 모듈(EC2)과 billing 모듈(NAT Gateway)을 분리해서 관리했는데요.

어느 날 아래 순서로 인프라를 올렸더니 SSM 연결이 되지 않는 문제가 생겼습니다.

EC2 인스턴스 실행
NAT Gateway 생성 (terraform apply -target=module.billing)
SSM 연결 시도 → 실패

분명히 NAT도 있고, 라우팅 테이블도 정상인데 SSM이 붙지 않았습니다. EC2를 재시작하니 바로 연결됐습니다.

원인: SSM Agent의 Backoff 메커니즘

SSM 연결 흐름은 다음과 같습니다.

EC2 부팅 → SSM Agent 자동 시작 → SSM 서비스 연결 시도
              (Private Subnet이면 NAT를 통해 인터넷으로)

EC2가 먼저 부팅되면 SSM Agent가 즉시 SSM 서비스에 연결을 시도합니다. 이때 NAT가 없으면 연결에 실패하고, Agent는 Exponential Backoff 방식으로 재시도 간격을 점점 늘립니다.

처음엔 몇 초 간격으로 재시도하다가, 계속 실패하면 최대 수십 분 간격으로 늘어납니다. NAT를 나중에 올려도 Agent가 긴 대기 상태에 있어서 즉시 연결되지 않는 것이었습니다.

재시작을 하면 Agent가 새로 초기화되면서 NAT가 이미 올라가 있는 상태에서 연결을 시도하니 바로 성공하는 것이고요.

해결 방법: 시작 순서 보장

NAT Gateway를 먼저 올리고, EC2를 올려야 합니다.

# 올바른 순서
terraform apply -target=module.billing   # NAT 먼저
terraform apply -target=module.compute   # EC2 나중에

이 순서를 지키면 EC2 부팅 시점에 NAT가 이미 준비되어 있어서 SSM Agent가 첫 시도에 바로 연결됩니다.

main.tf에 주석으로 순서를 명시해두면 팀원 모두가 실수하지 않을 수 있습니다.

# main.tf
# ⚠️ 리소스 생성/시작 순서 주의:
# 1. module.billing (NAT Gateway) 먼저
# 2. module.compute (EC2) 나중에
# NAT 없이 EC2가 먼저 뜨면 SSM Agent backoff로 인해 연결이 지연됩니다.

배운 점

이번 경험을 통해 두 가지를 크게 느꼈습니다.

첫 번째는 와일드카드 패턴은 생각보다 넓게 매칭된다는 점입니다. *는 편리하지만, 의도하지 않은 리소스를 잡을 수 있습니다. AMI 필터처럼 most_recent와 함께 쓸 때는 특히 구체적으로 작성하는 게 안전합니다.

두 번째는 의존성이 없는 리소스도 시작 순서가 중요할 수 있다는 점입니다. Terraform은 명시적 의존성이 없으면 순서를 보장하지 않습니다. SSM Agent처럼 부팅 시 한 번만 연결을 시도하는 컴포넌트는 의존하는 인프라가 먼저 준비되어 있어야 합니다.

++ Cloudfront도 테라폼으로 운영하게되면

마지막 Pay as you go로 설정이 되는 경험을 해서 부하 테스트시 비용이 갑자기 많이 오르는 경험을 했습니다.!!

마치며

작은 설정 하나, 실행 순서 하나가 생각보다 큰 문제로 이어질 수 있다는 걸 다시 한번 느꼈습니다. 비슷한 상황에서 헤매고 계신 분들께 이 글이 도움이 됐으면 좋겠습니다.

혹시 비슷한 경험이 있거나, 더 좋은 방법을 알고 계신다면 댓글로 공유해주세요!