김신건의 로그 - 위키 / concurrency

[Concurrency] Backpressure: 흐름 제어로 시스템 보호

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

정의

Backpressure = 생산자가 소비자 속도에 맞춰 자기 속도 조절. 분산 시스템의 cascade failure 방지.

[!IMPORTANT] Backpressure 의 핵심: “받는 쪽이 처리 못 함” 을 주는 쪽이 알아야 한다. 모르면 버퍼 폭발 + OOM + 시스템 다운.

문제: 비대칭 속도

flowchart LR
    Fast[Fast Producer<br/>10000 msg/s] -->|push| Buf[Unbounded Buffer]
    Buf -->|consume| Slow[Slow Consumer<br/>100 msg/s]
    Buf -.OOM.-> Crash[💥]

{}

Producer-Consumer 에서 Producer 가 항상 빠르면 buffer 가 무한 으로. backpressure 의 본질적 시나리오.

4가지 전략

flowchart TD
    Q[Producer > Consumer]
    Q --> Buf[1. Bounded buffer + Block]
    Q --> Drop["2. Drop (lossy)"]
    Q --> Sample[3. Sampling]
    Q --> Pull["4. Pull-based (demand)"]

1. Bounded Buffer + Block

queue = BoundedQueue(maxsize=1000)

# Producer
queue.put(msg)   # 가득 차면 block 또는 timeout

단순.
Producer 가 blocking → 상위 backpressure 자동 전파.

2. Drop (Lossy)

try:
    queue.put_nowait(msg)
except QueueFull:
    pass  # 드롭

metrics / log 같은 손실 OK 데이터.
Drop policy: oldest, newest, sample.

3. Sampling

if random.random() < 0.1:   # 10% 만 처리
    queue.put(msg)

대규모 telemetry.
통계적으로 유의미.

4. Pull-based (Reactive Streams)

sequenceDiagram
    autonumber
    participant P as Producer
    participant C as Consumer

    C->>P: request(10) (demand)
    P->>C: next(msg) × 10
    C->>P: request(5) (more demand)
    P->>C: next(msg) × 5

Consumer 가 요청한 만큼만 전송. Producer 가 자기 속도 자동 조절.

라이브러리: Project Reactor (Java), RxJava, ReactiveX, Akka Streams.

시스템 레벨 Backpressure

flowchart LR
    LB --> Sv1[Service 1]
    Sv1 --> Sv2[Service 2]
    Sv2 --> DB[(DB)]
    DB -.포화.-> Sv2
    Sv2 -.503.-> Sv1
    Sv1 -.429.-> LB
    LB -.queue.-> Client

레이어	신호
LB	429 Too Many Requests
Service	503 Service Unavailable
DB	connection pool 고갈
Network	TCP window 축소

HTTP/2, QUIC 의 flow control

flowchart LR
    Sender -->|DATA| Receiver
    Receiver -->|WINDOW_UPDATE +N| Sender
    Note[Sender 는 window 안에서만]

자세한 건 [[HTTP/2]] 의 flow control 절.

TCP 의 flow control

TCP 의 sliding window 가 전송 레이어 backpressure. 자세한 건 [[tcp]].

Bulkhead

flowchart TB
    Pool1["Pool A (10 threads)<br/>→ service A"]
    Pool2["Pool B (10 threads)<br/>→ service B"]
    Pool3["Pool C (10 threads)<br/>→ service C"]
    Fail["service A 다운"]
    Fail --> Pool1
    Pool1 -.포화.-> Pool1
    Note[Pool A 만 영향. B/C 는 정상]

Thread pool 을 service 별로 분리 → 한 service 다운이 전체 다운 안 되게.

Shedding (Load Shedding)

flowchart TD
    Q[현재 부하 > 한도?]
    Q -->|예| Shed["일부 요청 거절 (503)"]
    Q -->|아니오| Process[정상 처리]

모든 요청을 느리게 처리 하는 것보다 일부 거절하고 나머지는 빠르게. Google SRE 의 graceful degradation.

Adaptive Concurrency

flowchart LR
    Lat[현재 latency 측정] --> Calc[Little's Law 로<br/>적정 동시성 계산]
    Calc --> Cap[concurrency 한도 조정]
    Cap --> Limit[새 요청 제한]

Netflix Concurrency Limits.
Envoy adaptive concurrency.
latency 가 늘면 동시성 줄임.

흔한 함정

[!WARNING]

Unbounded queue = OOM 보장. 모든 buffer 는 bounded.

Drop 정책 명확하지 않음 = 운영자가 어떤 데이터 사라지는지 모름. 메트릭 필수.

Backpressure 전파 안 됨 = 한 계층만 잡고 위에서 압박 지속. cascade fail.

Pull-based 의 너무 큰 request(N) = 사실상 push 와 같음. 적절한 batch size.

[Concurrency] Circuit Breaker: cascade failure 방어

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

정의

Circuit Breaker = 전기 회로의 차단기처럼, 백엔드 다운 / 느림 시 호출 자체를 차단 → 빠른 실패 + 백엔드 회복 시간.

3가지 상태

stateDiagram-v2
    [*] --> Closed
    Closed --> Open: 실패율 임계 초과
    Open --> HalfOpen: 대기 시간 경과
    HalfOpen --> Closed: 성공 N회
    HalfOpen --> Open: 실패 1회

상태	의미	동작
Closed	정상	모든 호출 통과, 실패 카운트
Open	차단	호출 안 함, 즉시 fail (또는 fallback)
Half-Open	시험	제한된 호출 시도, 성공/실패로 다음 상태

시나리오

sequenceDiagram
    autonumber
    participant Client
    participant CB as Circuit Breaker
    participant Backend

    Note over CB: Closed
    Client->>CB: call
    CB->>Backend: ✓ OK
    Backend-->>CB: ✓
    Client->>CB: call
    CB->>Backend: ✗ Fail
    Note over CB: 실패 누적 (3/10)
    Client->>CB: call
    CB->>Backend: ✗ Fail
    Note over CB: 실패율 50% > 임계 → OPEN
    Client->>CB: call
    CB-->>Client: ❌ fail-fast (호출 안함)
    Note over CB: 30초 대기 (Open)
    Note over CB: Half-Open 으로 전환
    Client->>CB: call
    CB->>Backend: ✓ OK
    Note over CB: 성공 → Closed

트리거 조건

옵션	의미
Failure rate	실패율 > X% (sliding window)
Slow call rate	N초 이상 응답 비율 > X%
Consecutive failures	연속 N회 실패

라이브러리

라이브러리	언어	비고
Resilience4j	Java	Hystrix 후계
Polly	.NET	표준
Sentinel	Java/Go	Alibaba
pybreaker	Python	단순
opossum	Node	EventEmitter 친화
Envoy outlier detection	proxy	sidecar 자동

Hystrix vs Resilience4j

	Hystrix (2018 EOL)	Resilience4j
Thread pool 격리	기본	옵션
Semaphore	OK	OK
Reactive	일부	기본
Lightweight	X	O (8 MB)
활성 개발	X	O

Fallback

@circuit_breaker(name="payment")
def call_payment():
    return external.charge()

@call_payment.fallback
def cached_response():
    return { "status": "queued" }   # degraded but usable

단순 fail-fast 보다 부분적이라도 응답 이 사용자 경험 에 좋다. 단 잘못된 캐시 응답이 위험 한 영역 (결제 / 재고) 은 금지.

Bulkhead 와의 조합

flowchart TB
    subgraph App
        TPA["Thread Pool A (CB-A)<br/>→ Payment Service"]
        TPB["Thread Pool B (CB-B)<br/>→ Inventory Service"]
        TPC["Thread Pool C (CB-C)<br/>→ Shipping Service"]
    end
    Note[하나 다운 = 자기 Pool 만 영향]

자세한 건 [[backpressure]] 의 Bulkhead.

Envoy / Istio outlier detection

서비스 메시 레벨에서 자동 CB. 코드 변경 없이 적용:

# Istio DestinationRule
spec:
  trafficPolicy:
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 30s
      baseEjectionTime: 30s

흔한 함정

[!WARNING]

임계가 너무 민감 = 일시 jitter 로 false open. 짧은 window 에서 조심.

Half-Open 호출 다수 동시 = 한 번에 모든 호출 통과 → 다시 다운. 동시 호출 1개 또는 적은 수.

Fallback 이 다른 backend 호출 = fallback 도 다운되면 재귀 fail. fallback 은 로컬 / 캐시 only.

CB 메트릭 누락 = open 상태인지 운영자가 모름. 알림 필수.

[Concurrency] Connection Pool: DB, HTTP, gRPC 의 공통 패턴

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

정의

Connection Pool = 연결을 미리 만들어 두고 재사용. 매 요청마다 TCP + TLS + auth 비용을 회피.

{}

Pool 의 동작 = producer (request) / consumer (worker thread) 의 blocking queue 직관과 일치.

왜 필요?

매 요청 새 연결	Connection Pool
TCP handshake (~ms)	0 (재사용)
TLS handshake (~수십 ms)	0
DB auth + session 설정	0
OS file descriptor 한도 부담	제한적
TIME_WAIT socket 폭증	없음

흐름

sequenceDiagram
    autonumber
    participant App
    participant Pool
    participant DB

    App->>Pool: acquire()
    alt 가용 연결 있음
        Pool-->>App: connection
    else 모두 사용 중
        Pool->>Pool: 새 연결 생성 (max 까지)
        alt max 미도달
            Pool->>DB: 새 TCP/TLS/auth
            Pool-->>App: 새 connection
        else max 도달
            Pool-->>App: wait queue
        end
    end
    App->>DB: SELECT ...
    DB-->>App: rows
    App->>Pool: release()
    Pool-->>Pool: 연결 풀에 반환

주요 파라미터

파라미터	의미
`min_size` / `idle`	최소 idle 연결
`max_size`	최대 연결
`acquire_timeout`	acquire 대기 한도
`idle_timeout`	idle 연결 만료
`max_lifetime`	연결의 최대 수명
`validation_query`	health check (`SELECT 1`)
`leak_detection`	반환 안 된 연결 추적

Pool 크기 계산

Pool size ≈ (cores × 2) + effective_spindle_count

CPU 가 N 코어 면 동시 처리 가능한 작업 ~ 2N.
너무 큼 = context switch / lock 경쟁 / DB 부담.
너무 작음 = wait queue 길어짐.

Little’s Law

L = λ × W
연결 수 = 처리량 (req/s) × 응답 시간 (s)

예: 1000 req/s, 100ms 응답 → 100 connections 가 충분.

[!IMPORTANT] 대부분의 운영 사고는 pool size 가 너무 크기 때문. PG 의 max_connections=200 에 50 app instance × pool=10 = 500 시도 → DB 거절.

DB Connection Pool 구조

flowchart TB
    subgraph App[App instances]
        A1[App 1<br/>pool 10]
        A2[App 2<br/>pool 10]
        A3[App N<br/>pool 10]
    end
    App --> PgB[PgBouncer<br/>session/transaction pool]
    PgB --> PG[(PostgreSQL<br/>max 100)]

PgBouncer 같은 external pooler 가 N × app pool 을 PG 의 작은 pool 로 압축.

Mode	의미
`session`	클라이언트가 disconnect 할 때까지 연결 점유
`transaction`	트랜잭션 동안만 (가장 효율)
`statement`	매 statement (위험, prepared 안 됨)

HTTP Connection Pool

flowchart LR
    Client["HTTP Client<br/>(axios, OkHttp, ...)"] -->|pool| Conn1[connection 1]
    Client -->|pool| Conn2[connection 2]
    Client -->|pool| Conn3[connection 3]
    Conn1 & Conn2 & Conn3 --> Server[Server]
    Note["HTTP/1.1: per-host pool<br/>HTTP/2: 1 connection 의 multiplexing"]

흔한 함정

[!WARNING]

Pool size 너무 큼 = DB 거절 + thrashing. Little’s Law 로 계산.

max_lifetime 없음 = LB / firewall 의 idle disconnect 후 stale connection 시도 → 에러.

Leak (release 안 함) = pool 고갈. try-with-resources / context manager 강제.

Validation query 부재 = stale 연결로 간헐적 에러. SELECT 1 또는 pool 자체의 keep-alive.

HikariCP / 표준 라이브러리

라이브러리	언어
HikariCP	Java (가장 빠름)
pgx / pgxpool	Go
psycopg pool, SQLAlchemy	Python
node-postgres	Node
ActiveRecord	Ruby

[Concurrency] Rate Limiting: token bucket, sliding window

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

정의

Rate Limiting = 시간당 요청 수 제한. API 보호, fair use, 비용 제어, DDoS 완화.

5가지 알고리즘

flowchart LR
    A[Fixed Window]
    B[Sliding Log]
    C[Sliding Window Counter]
    D[Token Bucket]
    E[Leaky Bucket]
    F[GCRA]

1. Fixed Window

[00:00 ~ 00:01] count = 100 (한도)
[00:01 ~ 00:02] count 리셋 → 100

key = f"rl:{user}:{minute_bucket}"
count = redis.incr(key)
redis.expire(key, 60)
if count > 100: deny()

단순.
경계 burst: 00:00:59 에 100 + 00:01:00 에 100 = 2초 안에 200.

2. Sliding Log

모든 요청의 timestamp 저장 → 윈도우 안 카운트.

key = f"rl:log:{user}"
now = time.time()
redis.zadd(key, { req_id: now })
redis.zremrangebyscore(key, 0, now - 60)
count = redis.zcard(key)
if count > 100: deny()

정확.
메모리 큼 (요청마다 entry).

3. Sliding Window Counter

Fixed Window + 이전 window 비율.

current_count + previous_count * (1 - elapsed_in_current/window)

근사.
적은 메모리 + Fixed 의 burst 완화.

4. Token Bucket

flowchart LR
    Refill[1초마다 토큰 N개] --> Bucket[(Bucket: max 100)]
    Bucket -->|토큰 1개 소비| Request[요청 통과]
    Bucket -->|토큰 없음| Deny[429]

Burst 허용 (bucket 차있을 때).
평균 rate 보장.
AWS / GitHub / Discord API 표준.

5. Leaky Bucket

flowchart TB
    Req[요청] -->|채움| B[Bucket]
    B -->|일정 rate 로 소비| Output[처리]
    B -.넘침.-> Drop[Drop]

완전 평탄화. burst 흡수 + 일정 출력.
queue 기반.

6. GCRA (Generic Cell Rate Algorithm)

TAT (Theoretical Arrival Time) 계산
요청 시각이 TAT 보다 충분히 앞이면 허용

Token Bucket 수학적 변형.
단일 변수 로 표현. Redis 1 명령 으로 가능.
Cloudflare, Stripe 가 사용.

비교 매트릭스

알고리즘	메모리	정확도	Burst	구현
Fixed Window	적음	낮음 (경계 burst)	큼	가장 단순
Sliding Log	큼	정확	없음	Sorted Set
Sliding Window Counter	적음	보통	작음	2 counter
Token Bucket	적음	좋음	허용	간단
Leaky Bucket	중간	좋음	평탄	Queue
GCRA	최소 (단일 변수)	정확	가능	수학적

분산 환경 구현 (Redis)

# Token Bucket (Lua atomic)
TOKEN_BUCKET_LUA = """
local key = KEYS[1]
local now = tonumber(ARGV[1])
local rate = tonumber(ARGV[2])         -- tokens per sec
local capacity = tonumber(ARGV[3])

local last = redis.call('HMGET', key, 'tokens', 'last')
local tokens = tonumber(last[1]) or capacity
local last_ts = tonumber(last[2]) or now

local delta = math.max(0, now - last_ts) * rate
tokens = math.min(capacity, tokens + delta)
local allowed = tokens >= 1
if allowed then tokens = tokens - 1 end

redis.call('HMSET', key, 'tokens', tokens, 'last', now)
redis.call('EXPIRE', key, math.ceil(capacity / rate * 2))

return allowed and 1 or 0
"""

[!IMPORTANT] 분산 rate limit 는 Redis 한 곳 으로 원자적 카운터. 분산 락 없이 Lua 스크립트.

HTTP 응답 표준

HTTP/1.1 429 Too Many Requests
Retry-After: 30
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1719318060

{"error": "rate_limit_exceeded", "retry_after": 30}

어디서?

flowchart LR
    Client --> Edge["CDN / WAF<br/>(IP 단위)"]
    Edge --> GW["API Gateway<br/>(API key 단위)"]
    GW --> App["App<br/>(user 단위)"]
    App --> DB["DB<br/>(쿼리 단위)"]

레이어	단위
CDN	IP, geographic
WAF	의심 패턴
API Gateway	API key, OAuth token
App	user, tenant
DB	query, connection

Tier-based Rate Limit

limits = {
    "free":    {"per_min": 60, "burst": 100},
    "pro":     {"per_min": 600, "burst": 1000},
    "enterprise": {"per_min": 10000, "burst": 50000},
}

Stripe, OpenAI 같은 유료 API 의 표준.

흔한 함정

[!WARNING]

단일 노드 in-memory counter = N 노드면 N배 한도. 분산 store 필수.

IP 기반만 = NAT 뒤 수천 사용자가 한 IP. user + IP 조합.

Retry-After 무시 (클라이언트) = 무한 retry → DDoS 자기 자신.

Burst 너무 큼 = bucket 가득 차면 순간 throughput 폭증. 백엔드 보호 안 됨.

[Concurrency] Retry + Exponential Backoff + Jitter

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

정의

Retry with Exponential Backoff + Jitter = 실패 시 점점 긴 간격으로 재시도, 랜덤 분산. 분산 시스템의 thundering herd / retry storm 방지의 표준.

4가지 전략

flowchart LR
    Linear["Linear<br/>1s, 2s, 3s, 4s, ..."]
    Exp["Exponential<br/>1s, 2s, 4s, 8s, 16s, ..."]
    ExpJ["Exp + Jitter<br/>1s ± random, 4s ± random, ..."]
    DecorJ["Decorrelated Jitter<br/>AWS 권장"]

Exponential

sleep = base * (2 ** attempt)
# attempt 0: 1s, 1: 2s, 2: 4s, 3: 8s, ...

문제: 모든 클라이언트가 같은 시각에 재시도 → thundering herd.

Exponential + Full Jitter

sleep = random.uniform(0, base * (2 ** attempt))

완전 분산. AWS / Stripe 표준.

Decorrelated Jitter

sleep = random.uniform(base, prev_sleep * 3)

과거 sleep 의 함수. 완전 무작위 + 점진 증가. 평균적으로 가장 짧은 retry 시간.

비교 시뮬레이션

Retry 가능한 에러만 retry

flowchart TD
    E[에러 종류]
    E -->|5xx, timeout, conn refused| R[Retry OK]
    E -->|"4xx (400, 401, 403, 404)"| NoR[Retry 금지]
    E -->|429 Too Many Requests| Special[Retry-After 헤더 따름]
    E -->|"409 Conflict (idempotent 아니면)"| NoR
    E -->|503 + Retry-After| Special

[!IMPORTANT] 4xx 는 클라이언트 오류. retry 해도 같은 결과. 5xx / network 만 retry 가치.

Idempotency 와 짝

flowchart LR
    Retry --> Need[Idempotent operation 필수]
    Need --> Idem[Idempotency-Key 또는<br/>at-most-once 보장]

비-멱등 (POST 결제) 은 retry 가 중복 처리 위험. [[idempotency-keys]] 가 짝.

상한 설정

설정	권장
Max attempts	3-5
Max total time	30-60s
Per-attempt timeout	5-10s
Max sleep	16-32s

무한 retry = 사용자 영원히 대기. 빠른 deadline + fallback.

Retry-After 헤더

HTTP/1.1 429 Too Many Requests
Retry-After: 30

또는

Retry-After: Wed, 25 Jun 2026 12:30:00 GMT

서버가 client 에게 얼마 후 다시 시도 알림. 클라이언트는 반드시 존중.

SDK / Library

도구	언어
AWS SDK	모든 언어 (자동 retry)
Polly	.NET
Resilience4j Retry	Java
tenacity	Python
node-fetch + retry	Node
backoff (Go)	Go

Retry Budget

flowchart LR
    Calls[전체 호출 수] --> Budget[Retry 예산: 20%]
    Budget --> Limit[1000 호출 → 최대 200 retry]
    Limit --> Reject[초과 시 fast fail]

한 service 의 retry 가 전체 호출의 큰 비중 이면 retry storm. 예산 한도 로 보호. gRPC 의 retry budget, Envoy retry policy.

흔한 함정

[!WARNING]

Jitter 없음 = thundering herd. 전체 fleet 동시 retry.

모든 에러 retry = 4xx 도 retry → 의미 없는 부하.

Idempotent 아닌데 retry = 결제 중복. Idempotency-Key 필수.

Max attempt 무한 = 사용자 영원히 대기. timeout + fallback.

Nested retry = 계층마다 retry (client → SDK → SDK 내부) → retry × retry 폭증. 한 곳에서만.

Asynchronous (비동기)

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

정의

Asynchronous (비동기) 는 호출자가 결과를 즉시 기다리지 않고 다음 줄로 진행하는 실행 모델. 결과는 나중에 콜백, Future, Promise, 이벤트 등의 메커니즘으로 전달된다.

[[Synchronous]] 의 정반대 개념. [[Non-Blocking]] 과 자주 같이 쓰이지만 별개의 차원이다.

가장 단순한 형태

// Asynchronous, with Future
CompletableFuture<String> future = client.getAsync("/api/users");
// 다음 줄로 즉시 진행, 결과를 안 기다림
doOtherWork();

// 나중에 결과가 필요할 때
String result = future.get();   // 그 때 결과를 기다림 (다시 sync 가 됨)

또는 콜백 스타일:

client.getAsync("/api/users", (err, result) -> {
    if (err != null) handle(err);
    else process(result);
});
// 즉시 다음 줄로
doOtherWork();

비동기 호출 흐름

[caller]                    [callee or scheduler]
   │
   │── call ───────────────►│ (작업 시작, 별도 컨텍스트)
   │◄─── 즉시 return ───────│
   │
   │ 다른 일 수행            │ (작업 진행 중)
   │ doOtherWork()           │
   │                         │
   │                         │ (작업 완료)
   │◄─────── callback ──────│
   │ 결과 처리
   │

호출자의 일직선 흐름이 두 갈래 로 갈라진다. callback 이 진입하는 시점은 호출자의 스택과 다른 context.

콜백, Future, 이벤트, 세 가지 패턴

1. Callback (콜백)

service.callAsync(arg, (err, result) -> {
    if (err != null) onError(err);
    else onResult(result);
});

가장 원시적. 깊게 중첩되면 “콜백 지옥” ([[콜백 지옥]]).

2. Future / Promise / CompletableFuture

CompletableFuture<String> f = service.callAsync(arg);
f.thenApply(this::transform)
 .thenAccept(this::publish)
 .exceptionally(this::handle);

체이닝이 가능해 콜백 지옥을 해결. Java 의 CompletableFuture, JavaScript 의 Promise, C# 의 Task 가 같은 개념.

3. Event / Reactive Stream

publisher.subscribe(new Subscriber<>() {
    public void onNext(String item) { ... }
    public void onError(Throwable t) { ... }
    public void onComplete() { ... }
});

여러 결과가 시간에 걸쳐 도착하는 경우. Reactor, RxJava, Akka Streams, Project Reactor (Spring WebFlux) 등이 이 방식.

Async 의 두 형태, blocking vs non-blocking

비동기 모델도 [[Blocking]] / [[Non-Blocking]] 두 가지로 갈라진다.

Async + Non-Blocking (가장 흔함, 진짜 비동기)

client.getAsync(url).thenAccept(this::process);
// 호출 스레드는 즉시 풀려나 다른 작업 수행

호출 스레드는 등록만 하고 즉시 반환. OS 또는 framework 가 I/O 완료 시 callback 을 실행. Node.js, Netty, Vert.x, Spring WebFlux 등이 이 모델.

Async + Blocking (안티패턴, 자주 발견됨)

new Thread(() -> {
    String r = http.get(url);   // blocking I/O
    callback.accept(r);
}).start();

호출자 입장에서는 비동기지만, 실제로는 다른 스레드에서 blocking. 그래도 호출자 스레드가 즉시 풀려난다는 점은 비동기.

[!CAUTION] 이 패턴은 스레드를 많이 만든다. 동시 1000 요청이면 1000 스레드. 대부분의 sync API 를 async 화하는 ExecutorService 패턴이 이렇게 동작. Virtual Threads (JEP 444) 가 이 문제를 줄여준다.

Java 의 비동기 API

CompletableFuture

CompletableFuture.supplyAsync(() -> fetchData())
    .thenApply(this::parse)
    .thenCombine(other, (a, b) -> merge(a, b))
    .thenAccept(System.out::println)
    .exceptionally(t -> {
        log.error("failed", t);
        return null;
    });

비동기 + 체이닝 + 예외 처리 모두 가능.

Reactive (Spring WebFlux, Project Reactor)

Mono<User> user = userRepo.findById(id)
    .switchIfEmpty(Mono.error(new NotFoundException()))
    .map(this::enrich)
    .timeout(Duration.ofSeconds(5));

backpressure (생산자 / 소비자 속도 조절) 까지 자연스럽게 다룸.

Virtual Threads (Java 21+)

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    Future<String> f = executor.submit(() -> {
        return http.get(url);    // sync 같은 코드, virtual thread 에서
    });
}

흥미로운 점, 코드는 sync 처럼 보이지만 underlying 은 비동기적으로 스케줄 된다. Java 의 새로운 동시성 모델.

장점

확장성, 같은 스레드 풀로 수만 동시 요청 처리 가능
자원 효율, I/O 대기 중 스레드를 풀어둠
UI 응답성, 메인 스레드를 멈추지 않음
자연스러운 병렬, 여러 작업을 동시에 진행

단점

읽기 어렵다, 콜백 지옥, 비순차적 흐름
디버깅이 힘들다, stack trace 가 단편적
에러 처리가 복잡, 어디서 catch 할지 분명하지 않음
테스트가 어렵다, race condition, timing 의존

sync 코드를 async 로 만드는 흔한 방법

Java 의 `CompletableFuture.supplyAsync`

CompletableFuture<String> future = CompletableFuture.supplyAsync(
    () -> {
        return blockingCall();    // 원래 sync 였던 코드
    },
    threadPool
);

호출자에게는 비동기지만 내부적으로는 별도 스레드에서 sync 호출. 진짜 non-blocking 으로 만들려면 라이브러리 자체가 NIO 기반으로 다시 작성돼야 한다.

Spring 의 `@Async`

@Service
public class EmailService {
    @Async
    public CompletableFuture<Void> sendAsync(String to) {
        // sync 코드
        smtpClient.send(...);
        return CompletableFuture.completedFuture(null);
    }
}

annotation 으로 손쉽게 비동기화. 내부는 thread pool 으로 위임.

비동기와 동시성 (Concurrency) 의 관계

비동기 ≠ 병렬 (Parallel) ≠ 동시 (Concurrent)

Concurrent: 동시에 여러 일이 진행 중 (실제 동시 실행 여부 무관)
Parallel: 실제로 동시에 실행 (멀티 코어)
Asynchronous: 호출자가 결과를 즉시 기다리지 않음

비동기 모델은 single thread 에서도 concurrent 일 수 있다 (Node.js, JS 의 event loop). 비동기는 동시성을 가능하게 하는 도구일 뿐.

참고

[[Synchronous]]
[[Blocking]]
[[Non-Blocking]]
[[비동기와 타이밍, 콜백부터 async/await까지의 발전사]]
[[콜백 지옥]]
[[Promise]]
[[async/await]]

Blocking (블로킹)

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

정의

Blocking 은 호출이 결과가 준비될 때까지 호출 스레드를 멈춰두는 실행 방식. 멈춰 있는 동안 그 스레드는 다른 일을 할 수 없다. OS 가 스레드를 sleep 상태로 만들고 CPU 를 다른 스레드에게 넘겨준다 (대부분의 경우).

[[Non-Blocking]] 의 반대 개념. [[Synchronous]] 와 자주 같이 쓰이지만 별도의 차원.

시각화

{}

Thread T 가 blocking I/O 를 호출하면 BLOCKED 상태로 들어가 CPU 를 양보한다. OS scheduler 는 그 사이 Thread U 에게 CPU 를 돌리고, I/O 가 끝나면 T 를 깨워 다시 CPU 를 할당한다. 호출자의 코드 흐름에서는 “한 줄짜리 sync 호출” 로 보이지만, 스레드 입장에서는 깊은 잠에 든 시간이 존재한다.

같은 흐름을 텍스트로 요약하면 다음과 같다.

Thread T:  [────── blocking call ──────][다음 작업]
           │                            │
           │ ← CPU 다른 스레드에 양보     │
           │   (block 동안 idle)         │
           │
           작업 결과 도착, 깨어남

T 스레드는 결과가 도착할 때까지 어떤 코드도 실행하지 않는다. CPU 는 다른 스레드를 처리한다.

가장 흔한 예

파일 I/O (blocking)

String content = Files.readString(Path.of("data.txt"));
// 파일을 다 읽을 때까지 스레드 block

네트워크 I/O (blocking)

ServerSocket ss = new ServerSocket(8080);
Socket client = ss.accept();              // 연결이 올 때까지 block
String line = reader.readLine();          // 데이터 한 줄 올 때까지 block

락 대기 (blocking)

synchronized (obj) {                      // 다른 스레드가 락을 갖고 있으면 block
    ...
}

lock.lock();                              // ReentrantLock, 락을 얻을 때까지 block

잠 자기 (blocking)

Thread.sleep(1000);                       // 1초 block
TimeUnit.SECONDS.sleep(1);                // 같음

BlockingQueue (blocking)

BlockingQueue<Task> q = new LinkedBlockingQueue<>();
Task t = q.take();                        // 원소가 들어올 때까지 block
q.put(task);                              // 큐가 가득 차면 block

이름에 “Blocking” 이 명시적으로 들어있다.

blocking 의 코드 특징

호출 후 즉시 결과 처리 가능, return 값을 바로 쓸 수 있다
stack trace 가 일직선, 디버깅이 쉽다
에러는 그 자리에서 throw, try/catch 가 자연스럽다

try {
    String result = blockingCall();   // sync + blocking
    process(result);                  // 결과 즉시 처리
} catch (IOException e) {
    handle(e);                        // 같은 메서드에서 catch
}

blocking 의 비용

스레드가 block 됐다고 CPU 가 노는 건 아니다. OS 가 다른 스레드를 스케줄링한다. 하지만:

1. 스레드 자체가 비싸다

JVM 의 platform thread 는 OS 스레드와 1:1
스레드 1개당 메모리 ~1MB (스택)
100,000 스레드 → ~100GB RAM, 비현실적

따라서 blocking 코드 + 많은 동시 요청 은 스레드 풀로 제한해야 한다. 풀이 꽉 차면 요청들이 큐에서 기다린다.

2. context switch 가 잦다

스레드가 block 되면 OS scheduler 가 다른 스레드로 전환. 이 비용은 마이크로초 수준이지만 누적되면 무시 못 한다.

3. 응답성 손실

UI 스레드가 block 되면 화면이 멈춘다. Android 의 NetworkOnMainThreadException, Swing 의 EDT (Event Dispatch Thread) 보호가 모두 이 문제를 막기 위한 것.

blocking + [[Synchronous]] 가 가장 흔하다

String r = http.get(url);          // sync + blocking

sync: 호출자가 결과를 기다린다
blocking: 스레드가 멈춘다

대부분의 전통적 Java 코드 (HttpURLConnection, JDBC, JPA, file I/O) 가 이 모델.

blocking + [[Asynchronous]] 도 가능

new Thread(() -> {
    String r = http.get(url);         // 별도 스레드에서 blocking
    callback.accept(r);
}).start();

호출자는 즉시 풀려나지만, 새 스레드가 block. 자주 보는 안티패턴.

blocking 의 대안, NIO 와 비동기 I/O

전통적 Java I/O (java.io.*) 는 모두 blocking. Java NIO (java.nio.\*) 는 non-blocking I/O 를 지원한다.

// NIO non-blocking
ServerSocketChannel channel = ServerSocketChannel.open();
channel.configureBlocking(false);
SocketChannel client = channel.accept();   // null 즉시 반환 (연결 없으면)

이 모델로 Netty, Vert.x, Spring WebFlux 같은 high-throughput 서버가 가능.

자세히는 [[Non-Blocking]] 참고.

Virtual Threads, blocking 의 의미가 바뀌다

Java 21+ 의 Virtual Thread (JEP 444) 는 blocking 코드를 저비용으로 만든다.

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    executor.submit(() -> {
        String r = http.get(url);   // blocking call, 그러나 virtual thread 라 OK
        process(r);
    });
}

Virtual thread 는:

스택을 힙에 저장 (KB 수준)
block 되면 carrier thread 에서 unmount → carrier 는 다른 virtual thread 처리
결과 도착 시 carrier 에 다시 mount

수백만 동시 연결을 blocking sync 코드로 처리 가능. 사실상 “blocking 의 비용” 을 거의 0 으로 만든다.

blocking 의 장단점 요약

장점

코드가 직관적, 위→아래
디버깅, stack trace 일관
에러 처리 자연스러움
기존 코드 재사용 쉬움 (대부분의 JDK / 라이브러리가 blocking)

단점

스레드 자원 소모 (platform thread 기준)
동시 요청 수 한계
UI 스레드를 block 하면 응답성 손실

언제 blocking 이 적절한가

순차 흐름이 본질 (DB 트랜잭션 안 여러 쿼리 순차)
CPU 바운드 작업 (계산 위주, 어차피 스레드가 일함)
동시 요청 수가 적당 (수백 ~ 수천)
Virtual Thread 사용 환경 (Java 21+)
단순함이 우선 (스크립트, 마이그레이션, 배치)

언제 [[Non-Blocking]] 이 더 나은가

수만 ~ 수십만 동시 연결
I/O 가 매우 느리고 가변적 (외부 API 등)
백프레셔 제어 필요 (스트림 처리)
함수형 / reactive 패러다임 채택

참고

[[Non-Blocking]]
[[Synchronous]]
[[Asynchronous]]
[[ReentrantLock]]
[[volatile]]
[[비동기와 타이밍, 콜백부터 async/await까지의 발전사]]
Brian Goetz, Java Concurrency in Practice, §5 Building Blocks

Non-Blocking (논블로킹)

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

정의

Non-Blocking 은 호출이 결과를 기다리지 않고 즉시 반환 하는 실행 방식. 결과가 준비되지 않았다면 “아직 안 됐다” 라는 신호 (null, false, -1, Optional.empty() 등) 를 반환하고, 호출 스레드는 다른 일을 계속 한다.

[[Blocking]] 의 반대 개념. [[Asynchronous]] 와 자주 같이 쓰이지만 별개 차원.

두 가지 의미, I/O 와 동시성

“Non-Blocking” 은 두 분야에서 미묘하게 다른 뜻으로 쓰인다.

1. Non-Blocking I/O

OS 의 I/O 호출 시, 데이터가 준비되지 않았으면 즉시 “준비 안 됨” 으로 반환.

// Java NIO non-blocking mode
SocketChannel ch = SocketChannel.open();
ch.configureBlocking(false);            // ← non-blocking 모드

ByteBuffer buf = ByteBuffer.allocate(1024);
int n = ch.read(buf);                   // 즉시 반환
if (n == 0) {
    // 아직 데이터 없음, 다른 일 할 수 있음
} else if (n > 0) {
    // n 바이트 읽음
}

Selector 또는 epoll / kqueue 등의 OS 메커니즘과 결합해 한 스레드가 수만 소켓을 동시 처리 가능.

2. Non-Blocking 동시성 (lock-free)

스레드가 락을 기다리지 않고 진행하는 알고리즘. CAS (Compare-And-Swap) 같은 atomic 연산으로 구현.

AtomicInteger counter = new AtomicInteger();
counter.incrementAndGet();              // CAS 루프, lock-free

ConcurrentHashMap, ConcurrentLinkedQueue, AtomicReference 등이 이 카테고리.

이 글에서는 두 의미를 다 다룬다.

Non-Blocking I/O 의 흐름

{}

Thread T 한 개가 selector.select() 로 준비된 소켓 집합을 받아 순차적으로 read/process/write 한다. 각 소켓 작업은 즉시 반환되므로 한 소켓의 지연이 다른 소켓의 처리를 막지 않는다. 작업이 끝나면 다시 select() 로 돌아가 다음 ready 이벤트를 기다린다.

같은 흐름을 텍스트로 요약하면 다음과 같다.

Thread T (1 개):
  ┌─────────────────────────────────────────────┐
  │ for each ready socket:                       │
  │   socket.read(buf)   // 즉시 반환             │
  │   process(buf)       // CPU 작업              │
  │   socket.write(...)  // 즉시 반환             │
  └─────────────────────────────────────────────┘
        ▲
        │ Selector.select() 가 준비된 소켓을 알려줌

핵심: OS 가 어떤 소켓이 read/write 가능한지 알려주고, 우리는 그 소켓에만 작업한다. block 되지 않는다.

가장 단순한 Non-Blocking I/O 코드

Selector selector = Selector.open();
ServerSocketChannel server = ServerSocketChannel.open();
server.bind(new InetSocketAddress(8080));
server.configureBlocking(false);
server.register(selector, SelectionKey.OP_ACCEPT);

while (true) {
    selector.select();   // 이벤트 있을 때까지 대기 (이건 block 임)
    Set<SelectionKey> keys = selector.selectedKeys();
    for (SelectionKey key : keys) {
        if (key.isAcceptable()) {
            SocketChannel client = server.accept();   // non-blocking
            client.configureBlocking(false);
            client.register(selector, SelectionKey.OP_READ);
        } else if (key.isReadable()) {
            SocketChannel client = (SocketChannel) key.channel();
            client.read(buf);   // non-blocking
            // process buf
        }
        keys.remove(key);
    }
}

단일 스레드가 수천 ~ 수만 소켓을 처리하는 패턴. Netty, Vert.x, Node.js 의 사상 기반.

Non-Blocking 동시성 (lock-free) 예

CAS 기반 atomic 연산

AtomicInteger counter = new AtomicInteger();
// 내부 구현 (단순화)
public int incrementAndGet() {
    int prev, next;
    do {
        prev = get();
        next = prev + 1;
    } while (!compareAndSet(prev, next));   // CAS 실패 시 재시도
    return next;
}

락을 잡지 않고 atomic 하게 증가. 실패하면 그냥 다시 시도.

{}

두 스레드가 같은 값을 읽고 동시에 CAS(prev, next) 를 시도하면 한 쪽만 성공한다. 실패한 쪽은 어떤 락도 걸지 않은 채 다시 get() 부터 시작해 재시도한다. 이 “비관적 lock 없음 + 낙관적 retry” 가 non-blocking 동시성의 핵심.

Michael & Scott 알고리즘 (ConcurrentLinkedQueue)

ConcurrentLinkedQueue.offer(x):
  newNode = Node(x)
  loop:
    tail = currentTail
    next = tail.next
    if (next == null) {
      // tail 의 next 를 newNode 로 CAS
      if (CAS(tail.next, null, newNode)) {
        CAS(currentTail, tail, newNode)   // tail 도 이동 (best effort)
        return
      }
    } else {
      CAS(currentTail, tail, next)         // 다른 스레드가 추가 중, tail 따라잡기
    }

여러 스레드가 동시에 offer 해도 락 없이 일관성 유지. 다만 같은 자리에서 CAS 가 실패하면 재시도하므로 고경합 시 성능 저하 (livelock 까지 갈 수 있음).

Non-Blocking 의 장점

자원 효율

스레드 1개로 수만 동시 연결
메모리, context switch 비용 절감

응답성

빠른 요청이 느린 요청에 막히지 않음
“fail-fast” 가능 (즉시 사용 불가 응답)

백프레셔 자연스러움

큐가 가득 차면 즉시 “꽉 참” 반환
Reactive Streams 의 핵심 메커니즘

Non-Blocking 의 단점

코드 복잡도

상태 머신 같은 흐름, 직선형이 아님
callback hell 의 원조

디버깅 어려움

stack trace 가 callback 마다 끊김
“어떤 요청이 이 callback 을 호출했나” 추적 어려움

CPU 바인드 작업과 충돌

non-blocking 스레드가 무거운 계산을 하면 이벤트 루프가 멈춤
“이벤트 루프를 절대 블록하지 말라” 가 원칙

Java 의 Non-Blocking API

영역	API
I/O	`java.nio.channels.*` (Channel + Selector + ByteBuffer)
HTTP	`java.net.http.HttpClient` (`sendAsync()`)
Network	Netty, Vert.x, Reactor Netty
Atomic	`java.util.concurrent.atomic.*` (AtomicInteger 등)
Concurrent collections	`ConcurrentHashMap`, `ConcurrentLinkedQueue`
Reactive	Project Reactor, RxJava
WebFlux	Spring 5+ Reactive web stack

non-blocking + [[Asynchronous]] = 진짜 비동기

대부분의 “비동기 라이브러리” 가 이 조합.

HttpClient client = HttpClient.newHttpClient();
CompletableFuture<HttpResponse<String>> f = client.sendAsync(
    request,
    BodyHandlers.ofString()
);
f.thenApply(HttpResponse::body)
 .thenAccept(System.out::println);
// 호출자는 즉시 풀려나고, response 가 오면 callback 실행

이 모델로 단일 스레드가 수만 요청을 동시 처리 가능.

non-blocking + [[Synchronous]] (드뭄)

while (!queue.isEmpty() == false) {
    Thread.onSpinWait();   // 짧게 양보
}
Task t = queue.poll();

busy-waiting 또는 spin-wait. CPU 를 점유하므로 매우 짧은 대기에만 적절. Atomic* 의 CAS 루프가 이 패턴.

Virtual Threads 와의 관계

Java 21+ Virtual Thread (JEP 444) 는 흥미로운 입장. 코드는 blocking 처럼 보이지만 underlying 은 non-blocking 으로 작동한다.

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    executor.submit(() -> {
        String r = http.get(url);     // 코드는 blocking
        // 실제로는 virtual thread 가 unmount 됨
    });
}

이제 개발자는 non-blocking 의 복잡함 없이 그 효율을 누린다. 다만 java.io.* 의 일부는 여전히 native blocking (file I/O 일부) 이라 carrier thread 가 잡힐 수 있다.

자주 헷갈리는 표현 정리

표현	의미
blocking	호출 스레드가 결과 올 때까지 멈춤
non-blocking	즉시 반환, 결과는 다른 방법으로
synchronous	호출자가 결과를 기다린다 (control flow)
asynchronous	호출자가 결과를 안 기다린다
lock-free	락 없이 동시성 안전 (CAS 등)
wait-free	모든 스레드가 finite step 안에 완료 (lock-free 의 강한 버전)

특히 lock-free 와 wait-free 는 학술적 구분. 실무에서는 보통 “lock-free” 가 사용됨.

참고

[[Blocking]]
[[Synchronous]]
[[Asynchronous]]
[[volatile]]
[[CopyOnWriteArrayList]]
[[비동기와 타이밍, 콜백부터 async/await까지의 발전사]]
Maurice Herlihy & Nir Shavit, The Art of Multiprocessor Programming, §10-12

Synchronous (동기)

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

정의

Synchronous (동기) 는 호출자가 결과가 나올 때까지 기다리는 실행 모델. 함수를 호출한 코드는 그 함수가 반환할 때까지 다음 줄로 진행하지 않는다.

이 정의는 Java 의 synchronized 키워드와는 별개의 개념 이다. synchronized 는 동시성 제어 (mutual exclusion), Synchronous 는 호출 모델 (control flow).

[[Asynchronous]] 와의 대비, 그리고 [[Blocking]] 과의 관계가 핵심.

가장 단순한 형태

// Synchronous
String result = http.get("/api/users");   // 응답이 올 때까지 대기
process(result);                          // 그 다음 진행

호출자는 응답이 오기 전까지는 다음 줄을 실행하지 않는다. 코드 작성과 디버깅이 가장 쉽다.

Sync 의 두 형태, blocking vs non-blocking

Synchronous 는 호출자가 결과를 기다린다 는 의미이지, 그 동안 CPU 를 점유 하는지는 별개. 따라서 두 가지가 가능.

Synchronous + Blocking (가장 흔함)

호출자가 결과를 기다리는 동안 스레드가 멈춘다 (block). OS 가 스레드를 sleep 상태로 만들고 CPU 를 다른 스레드에게 양보.

// 전형적인 sync + blocking
Socket s = serverSocket.accept();         // 연결이 올 때까지 block
String line = reader.readLine();          // 데이터가 올 때까지 block
Thread.sleep(1000);                       // 1초 block

Synchronous + Non-Blocking (드물지만 가능)

호출자가 결과를 기다리지만 스레드는 활성 상태 로 계속 돈다. busy-waiting 또는 polling.

while (!result.isReady()) {
    Thread.onSpinWait();   // hint, 스레드 양보 안 함
}
String value = result.get();

CPU 를 낭비하므로 거의 안 쓴다. 매우 짧은 대기에만 쓰이는 마이크로 최적화.

동기 호출 흐름

[caller]                    [callee]
   │
   │── call ───────────────►│
   │                         │ 작업 수행
   │ (waiting)              │
   │                         │
   │◄─────────── return ────│
   │
   │ 결과 처리 시작
   │

호출자와 호출자의 스택 프레임이 일직선 으로 이어진다. 디버깅 시 stack trace 가 그대로 보인다.

장점

읽기 쉽다, 위에서 아래로 흐름이 명확
에러 처리가 자연스럽다, try / catch 가 호출자 스택에 닿는다
디버깅이 쉽다, breakpoint 가 작동, stack trace 가 일관
테스트가 쉽다, 순차 실행이라 결과 비교 단순

단점

느린 작업은 스레드를 묶는다, 동시에 1000명 응답하려면 1000개 스레드
CPU 활용도가 낮을 수 있다, I/O 대기 중에는 CPU idle
응답성 저하, 한 요청이 다른 요청의 진행을 막을 수 있다

언제 동기가 적절한가

응답이 빠르고 일관적, 5ms 이내의 DB 쿼리 같은 작업
순차 흐름이 본질, 단계 A 의 결과로 단계 B 를 결정
저부하 시스템, 동시 접속 < 수백 수준
테스트, 스크립트, 마이그레이션 도구

언제 [[Asynchronous]] 가 더 나은가

외부 API 호출 (수 초 걸릴 수 있음)
수만 명 동시 접속을 받는 서버
UI 가 멈추면 안 되는 클라이언트
여러 작업을 병렬로 진행해야 할 때

Java 의 동기 IO 예

HTTP 클라이언트 (sync)

// HttpClient 동기 모드
HttpClient client = HttpClient.newHttpClient();
HttpResponse<String> response = client.send(
    HttpRequest.newBuilder(URI.create("https://api.example.com")).build(),
    BodyHandlers.ofString()
);
// 응답이 도착할 때까지 block

File I/O (sync)

String content = Files.readString(Path.of("data.txt"));
// 파일을 다 읽을 때까지 block

Socket (sync)

ServerSocket server = new ServerSocket(8080);
Socket client = server.accept();           // 연결을 받을 때까지 block
String line = new BufferedReader(...).readLine();   // 데이터를 받을 때까지 block

Sync 모델의 동시성, 스레드 풀

대량 동시성을 위해 sync 코드는 스레드 풀 을 쓴다. 각 요청을 별도 스레드에 할당해 병렬 처리.

ExecutorService pool = Executors.newFixedThreadPool(100);
// 매 요청마다
pool.submit(() -> {
    String r = http.get(url);    // sync call, but in separate thread
    process(r);
});

이 방식의 한계:

스레드 1개당 메모리 ~1MB
100 스레드 ≈ 100MB
10,000 동시 연결 → ~10GB, 비현실적

Java 21+ 의 Virtual Threads (JEP 444) 가 이 한계를 깬다. 동기 코드 그대로 두면서도 수백만 동시 연결을 가능하게 만든다.

sync 와 [[Blocking]] 의 관계

표현	의미
synchronous	호출자가 결과를 기다린다 (control flow)
blocking	그 동안 스레드가 멈춘다 (thread state)

같이 쓰이지만 다른 차원. 대부분의 sync 코드는 blocking 이지만, non-blocking sync 도 가능 (Thread.onSpinWait(), busy-loop) 하다.

반대로 async + blocking 도 가능 (콜백 안에서 다시 sleep 하는 경우, 자주 보는 안티패턴).

참고

[[Asynchronous]]
[[Blocking]]
[[Non-Blocking]]
[[비동기와 타이밍, 콜백부터 async/await까지의 발전사]]

Pub/Sub Bus

koa (김신건) — Sat, 13 Jun 2026 00:00:00 GMT

정의

Pub/Sub Bus (Publish-Subscribe bus)는 메시지 송신자(publisher)와 수신자(subscriber)가 서로를 모르고도 통신할 수 있게 해주는 중간 메시지 라우팅 계층이다.

Publisher: 특정 채널/토픽에 메시지를 발행
Subscriber: 관심 있는 채널을 구독, 발행된 메시지 수신
Bus: 둘 사이의 라우팅 담당 (Redis, Kafka, NATS, RabbitMQ 등)

{}

왜 필요한가, 분산 [[Stateful]] 서버의 확장 문제

WebSocket 같은 지속 연결 서버를 여러 인스턴스로 확장하면 새로운 문제가 생긴다.

Client A → Server 1
Client B → Server 2 (다른 서버)

질문: A 가 B 에게 메시지를 보내려면?

서버 1 은 B 와 연결되어 있지 않으니 직접 send 할 수 없다.

해결책: Pub/Sub Bus

1. Server 1 이 A 의 메시지 수신
2. Server 1 → Redis publish "channel-B" with payload
3. Server 2 가 "channel-B" 를 구독 중
4. Redis → Server 2 에 메시지 전달
5. Server 2 → B 에게 send

서버는 자기 클라이언트만 관리하면 됨. 서버 간 라우팅은 bus 가 담당.

동작 패턴

Channel 기반

특정 이름의 채널에 발행/구독.

// Publisher
redis.publish('chat:room:123', JSON.stringify({ from: 'A', text: 'hello' }));

// Subscriber
redis.subscribe('chat:room:123', (message) => {
  const data = JSON.parse(message);
  forwardToClient(data);
});

Pattern 기반 (와일드카드)

redis.psubscribe('chat:room:*', (channel, message) => {
  // chat:room:123, chat:room:456 모두 매칭
});

Topic 기반 (계층화)

Kafka 등에서 토픽을 partition 단위로 분배.

topic: user-events
  partition 0: user_id % 3 == 0 인 이벤트
  partition 1: user_id % 3 == 1
  partition 2: ...

Socket.IO + Redis Adapter 패턴

가장 흔한 실무 패턴.




const io = new Server(httpServer);

const pubClient = createClient({ url: 'redis://localhost:6379' });
const subClient = pubClient.duplicate();

await Promise.all([pubClient.connect(), subClient.connect()]);
io.adapter(createAdapter(pubClient, subClient));

// 이후엔 같은 코드로 서버 간 브로드캐스트가 동작
io.to('room-123').emit('msg', payload);
//   → Redis publish → 모든 서버 인스턴스 → 각자 자기 클라이언트에게 전달

서버 코드는 단일 인스턴스 때와 동일. Bus 가 multi-server 라우팅을 투명하게 처리한다.

Pub/Sub vs Message Queue (차이점)

	Pub/Sub	Message Queue
메시지 보관	즉시 전달 (fire-and-forget)	큐에 보관, 컨슈머가 pull
다중 수신자	모든 subscriber 가 받음	보통 1 consumer 가 받음
메시지 유실	subscriber 가 offline 이면 잃을 수 있음	persistent 가능
예시	Redis Pub/Sub, NATS	RabbitMQ, SQS, Kafka (consumer group 모드)

Redis Pub/Sub 은 단순 Pub/Sub. Kafka 는 두 모드 모두 가능 (broadcast + consumer group).

부하 특성

구성 요소	부하
Publisher 서버	메시지마다 publish 호출 (~0.1 ms)
Bus	모든 publish 가 통과, 가장 부담 큰 단일 지점
Subscriber 서버	수신 + 자기 클라이언트에게 forward

[!IMPORTANT] Bus 가 SPOF (단일 장애점) 가 될 수 있다. 고가용성 클러스터 (Redis Sentinel/Cluster, Kafka multi-broker) 가 필수. 또 다른 함정: 모든 메시지가 bus 를 통과하므로 bus 처리량이 시스템 전체의 상한이 된다.

사용 시나리오

1. WebSocket 클러스터

위에서 설명한 Socket.IO + Redis Adapter 패턴.

2. 마이크로서비스 간 이벤트 전파

주문 서비스 → publish "order.created"
  → 결제 서비스 (subscribe)
  → 재고 서비스 (subscribe)
  → 알림 서비스 (subscribe)

각 서비스가 독립적으로 진화 가능.

3. 실시간 알림 시스템

이벤트 발생 → publish "notify:user-{id}"
  → 사용자가 접속한 서버가 subscribe → 전달

4. Cache invalidation

DB 업데이트 → publish "cache-invalidate:user-{id}"
  → 모든 서버가 자기 로컬 캐시 무효화

대안과 trade-off

gRPC streaming + 서비스 디스커버리

서비스 간 직접 stream. Bus 없음. 더 빠르지만 N×M 연결 관리.

Service mesh (Istio 등)

L7 라우팅으로 메시지 전달. 더 강력하지만 복잡.

Database notification

PostgreSQL LISTEN/NOTIFY 같은 DB 내장 Pub/Sub. 외부 인프라 불필요.

Stateful

koa (김신건) — Sat, 13 Jun 2026 00:00:00 GMT

정의

Stateful (상태유지) 서버는 클라이언트와의 세션·연결 컨텍스트를 메모리에 유지한다. 후속 요청·이벤트는 이 컨텍스트를 활용해 처리된다.

같은 클라이언트의 요청은 같은 서버로 가야 의미가 있다. 그래서 수평 확장이 복잡해진다.

전체 비교는 [[Stateless vs Stateful]] 페이지를 참조.

핵심 특성

측면	동작
세션 상태	서버 메모리에 보관
수평 확장	[[Sticky Session]] 또는 외부 store 필수
장애 복원	서버 다운 시 세션 손실 (외부 store 시 완화)
인증 정보	세션 ID 발급, 서버가 검증
캐싱	사용자별 응답 → 캐시 효율 낮음

어디에 상태가 사는가

1. 인메모리 (가장 흔함)

const sessions = new Map(); // sessionId → user_data

빠르지만 휘발성. 서버 재시작 = 세션 손실.

2. 활성 연결 자체

WebSocket, SSE 의 경우 TCP 연결 자체가 상태 컨텍스트다.

const wss = new WebSocketServer({ ... });
wss.on('connection', (ws) => {
  ws.userId = decodeAuth(ws.upgradeReq);
  ws.rooms = new Set();
  // 이 ws 객체가 사라질 때까지 컨텍스트 유지
});

연결 끊김 = 컨텍스트 손실 → 재연결 + 재인증 필요.

3. 외부 store (사실상 Stateless 화)

세션 데이터를 Redis 같은 외부 store 에 두면 형식상 Stateless 서버가 된다.

// Express + connect-redis
app.use(session({
  store: new RedisStore({ client: redis }),
  secret: 'xxx',
}));

Stateful 서버의 수평 확장

여러 서버로 트래픽을 분산할 때 마주치는 문제.

문제, 같은 클라이언트가 다른 서버로 가면?

Client X 가 Server A 에 로그인 → A의 메모리에 세션 저장
Client X 의 다음 요청 → LB가 Server B 로 라우팅 → B는 세션 모름 → 인증 실패

해결책 1: [[Sticky Session]]

LB 가 같은 클라이언트를 같은 서버로. 가장 흔하고 가장 단순.

단점: 서버 다운 시 세션 손실, 부하 불균형 가능.

해결책 2: 외부 세션 store

세션 데이터를 Redis 등에 두면 어느 서버나 조회 가능. 사실상 Stateless 화.

Client X → 아무 서버 → Redis 에서 세션 조회 → 처리

매 요청마다 store I/O 추가.

해결책 3: [[Pub/Sub bus]] (지속 연결 전용)

서버 간 메시지 라우팅용. WebSocket 같이 연결 자체가 본질적인 경우.

Server A 가 Client X 보유 / Server B 가 Client Y 보유
A 에 'Y 에게 메시지' 도착 → Redis publish → B subscribe → Y 에게 전달

Socket.IO + Redis Adapter 패턴이 전형.

실무 예시

WebSocket 채팅 서버


const rooms = new Map(); // room → Set<ws>

const wss = new WebSocketServer({ port: 8080 });
wss.on('connection', (ws) => {
  ws.on('message', (data) => {
    const { type, room, payload } = JSON.parse(data);
    if (type === 'join') {
      if (!rooms.has(room)) rooms.set(room, new Set());
      rooms.get(room).add(ws);
    } else if (type === 'message') {
      rooms.get(room)?.forEach((peer) => {
        if (peer !== ws) peer.send(payload);
      });
    }
  });
});

rooms Map 이 메모리 상태. 서버 재시작 = 모든 룸 정보 손실.

실시간 게임 서버

플레이어 위치·인벤토리·전투 상태를 서버 메모리에 유지. tick 단위로 업데이트.

수평 확장은 보통 샤딩, “월드 1 은 Server A, 월드 2 는 Server B” 식으로 분할.

협업 도구 (Figma, Notion)

문서 단위로 stateful 서버 1대가 모든 활성 사용자의 변경사항(OT/CRDT)을 메모리에 유지.

함정과 한계

1. 메모리 폭발

활성 연결마다 메모리. WebSocket + Socket.IO 5K 연결 = ~400-500 MB.

2. 서버 다운 = 사용자 인지 가능한 손실

다운 직후 활성 세션 / 연결이 모두 끊김. 재연결 + 재인증 + 잃어버린 메시지 재요청.

3. 운영 복잡도

[[Sticky Session]] 설정
배포·롤링 업데이트 시 세션 마이그레이션 또는 graceful drain
모니터링 (활성 연결 수, 메모리, GC 등)

4. 비용

같은 동접 처리 시 Stateless 보다 더 많은 서버 인스턴스 필요 (메모리 빠르게 소진).

통신 프로토콜과의 관계

프로토콜	Stateful 여부
HTTP 의미상	Stateless
Server-Sent Events	✓ Stateful (지속 연결)
WebSocket	✓ Stateful (지속 양방향)
WebRTC	✓ Stateful (P2P 세션)
Long Polling	의미상 Stateless, 운영상 비슷
WebTransport	✓ Stateful

지속 연결 기반 프로토콜은 본질적으로 Stateful.

참고

[[Stateless]]
[[Stateless vs Stateful]] (전체 비교, 애니메이션 포함)
[[Sticky Session]], 수평 확장의 핵심 회피책
[[Pub/Sub bus]], WebSocket 클러스터 확장 패턴

Stateless

koa (김신건) — Sat, 13 Jun 2026 00:00:00 GMT

정의

Stateless (무상태) 서버는 클라이언트의 요청 간 상태를 기억하지 않는다. 각 요청은 완전히 독립적이며, 처리에 필요한 모든 정보는 요청 자체에 담겨 있어야 한다.

같은 요청이라면 어느 서버 인스턴스가 처리하든 결과가 같다는 게 핵심 속성. 이게 수평 확장을 단순하게 만든다.

전체 비교는 [[Stateless vs Stateful]] 페이지를 참조.

핵심 특성

측면	동작
세션 상태	서버 메모리에 없음
수평 확장	무제한, round-robin LB
장애 복원	서버 교체 시 사용자 무영향
인증 정보	매 요청마다 토큰/키 첨부
캐싱	URL 기반 캐시 매우 효율적

어떻게 stateless 를 유지하는가

상태가 정말 필요 없는 경우는 드물다. 보통은 “상태를 서버 메모리에 두지 않는다” 가 핵심이다. 어디에 두는가가 선택이다.

1. 외부 store 위임

세션·캐시·잠금 등을 Redis, DynamoDB, DB 에 둔다. 모든 서버 인스턴스가 같은 store 에 접근.

요청 → 어느 서버든 OK → Redis 에서 세션 조회 → 응답

비용: 매 요청마다 store I/O (보통 1-3 ms). 운영 단순성을 위한 합리적 trade-off.

상태를 클라이언트가 들고 다님. 서버는 검증만.

로그인 → JWT 발급 → 클라이언트가 보관
이후 요청 → Authorization: Bearer <JWT> → 서명 검증으로 사용자 식별

3. URL/Query 에 상태 인코딩

페이지네이션 커서, 필터 조건 등을 URL 에 담는다.

GET /products?cursor=eyJpZCI6MTIzfQ&limit=20

서버는 cursor 만 읽고 응답.

실무 예시

REST API

GET /api/users/42
Authorization: Bearer eyJhbGc...

→ 서버: JWT 검증, DB 에서 user 42 조회, 응답
   메모리에 세션 X

CDN / 정적 자원

GET /static/main.css
→ 어느 edge 서버든 같은 응답
→ 캐시 적중률 매우 높음

Serverless 함수 (AWS Lambda 등)

함수 실행마다 컨테이너가 새로 만들어질 수 있음 → stateless 가 강제됨. 세션은 DynamoDB / Redis 등에 위임 필수.

함정과 한계

1. “Stateless 인데 외부 store 가 단일 장애점”

Redis 다운 → 모든 서버가 세션 조회 실패. Stateless 한 서버를 만들어놓고 외부 store 에 의존하면 그게 SPOF 가 된다. 고가용성 Redis 클러스터, fallback 전략 필요.

2. JWT 즉시 취소 어려움

JWT 는 만료 전까지 유효. 사용자 권한 변경/로그아웃을 즉시 반영하려면 블랙리스트 같은 별도 store 가 필요 → 일부 stateful 화.

3. Per-request 토큰 검증 비용

매 요청마다 JWT 서명 검증 (CPU) + 외부 store 조회 (I/O). 트래픽이 많으면 누적된다.

통신 프로토콜과의 관계

프로토콜	Stateless 친화도
HTTP/1.1, 2, 3	✓ 완벽 (메시지 의미상)
Short Polling	✓
Long Polling	✓ (HTTP 의미상, 운영상은 연결 점유)
Server-Sent Events	✗ Stateful (지속 연결)
WebSocket	✗ [[Stateful]]
WebRTC	✗ Stateful

대부분의 REST API · CDN · 정적 사이트는 자연스럽게 stateless.

Stateless vs Stateful

koa (김신건) — Sat, 13 Jun 2026 00:00:00 GMT

정의

Stateless (무상태): 서버가 클라이언트 요청 간 상태를 기억하지 않음. 각 요청은 완전히 독립적이며 필요한 모든 정보는 요청에 담겨 있다.

Stateful (상태유지): 서버가 클라이언트와의 세션 정보를 메모리에 유지. 후속 요청은 이 컨텍스트를 활용해 처리된다.

{}

위 애니메이션이 같은 인프라(Client + LB + 3 서버)에서 두 모드가 어떻게 다르게 동작하는지, 그리고 장애 시 어떤 차이가 나는지를 한눈에 보여준다.

기본 비교

측면	Stateless	Stateful
서버 메모리	요청 처리에만 필요	활성 세션마다 메모리
수평 확장	매우 쉬움, 어느 서버든 OK	어려움, [[Sticky Session]] 필요
장애 복원	서버 교체 무영향	세션 손실 (외부 store 시 완화)
로드밸런서	단순 round-robin	client → server 일관 라우팅 필요
캐싱	URL 기반 캐시 효율적	캐시 효율 낮음
인증 정보	매 요청마다 보냄 (JWT, API key)	세션 ID 1회 → 서버가 검증

네트워크 계층의 stateless / stateful

각 프로토콜이 명세상 어떤 상태성을 가지는지.

프로토콜	상태성	비고
IP	Stateless	패킷 단위 라우팅, 연결 개념 없음
[[UDP]]	Stateless	비연결
[[TCP]]	Stateful	연결, sequence number, window 등 모두 상태
[[TLS]]	Stateful	세션 키, sequence number, certificate 검증 결과
HTTP/1.0	Stateless	매 요청마다 새 TCP
HTTP/1.1 (keep-alive)	Stateless (HTTP 의미)	TCP 자체는 stateful
HTTP/2	Stateless (HTTP 의미)	TCP + HPACK 동적 테이블은 stateful
HTTP/3 ([[QUIC]])	Stateless (HTTP 의미)	QUIC connection 자체는 stateful
WebSocket	Stateful	지속 연결 + 컨텍스트
Server-Sent Events	Stateful	지속 연결, 단방향
WebRTC	Stateful	P2P 세션, DTLS 키

“HTTP 는 stateless 다” 라는 익숙한 말은 HTTP 메시지 의미 차원의 진실이다. 하부의 TCP·TLS·HPACK 동적 테이블은 모두 stateful 이지만, 응용 계층의 HTTP 가 세션 상태를 기억하지 않는다는 게 핵심 의미.

서버에서 상태를 어떻게 관리하나

Stateless 서버의 구조

요청 도착
  ↓
요청 헤더 검증 (인증 토큰 등)
  ↓
필요시 외부 store 조회 (DB, Redis)
  ↓
응답 생성 → 송신
  ↓
모든 메모리 즉시 해제

서버 프로세스가 가진 상태:

TCP 연결 풀 (네트워크 계층, 응용은 무관)
캐시 (선택)
설정 정보

세션·사용자 데이터 같은 응용 상태는 0. 어떤 인스턴스도 동일하게 동작한다.

Stateful 서버의 구조

연결 수립 (WebSocket / SSE / 로그인)
  ↓
세션 객체 생성 (메모리)
  - user_id, permissions, last_active
  - WebSocket 연결 핸들
  - 미발신 메시지 큐
  ↓
이후 요청·이벤트마다 세션 컨텍스트 조회 (메모리 lookup)
  ↓
연결 종료 시까지 객체 유지

서버 메모리에 활성 세션 수만큼의 객체.

활성 세션 객체의 일반적 크기

종류	일반적 크기	비고
HTTP 인메모리 세션	1~5 KB	user_id, role, 일부 캐시
WebSocket 세션 (raw `ws`)	~3.5 KB	frame buffer + state
WebSocket 세션 (Socket.IO)	6090 KB	룸, 어댑터, ACK 추적
SSE 세션	~1.2 KB	HTTP response stream
WebRTC 세션	큼, 미디어 코덱 상태 포함	수 백 KB ~ MB

(출처: Ark Protocol 2026, Wolf-tech 2026 측정값)

Stateful 서버의 수평 확장 전략

[[Sticky Session]]: LB 가 같은 클라이언트를 같은 서버로
외부 세션 store: Redis 등에 위임 → 사실상 Stateless 화
Pub/Sub bus: 서버 간 메시지 라우팅 (Socket.IO + Redis Adapter)

WebSocket 클러스터 + Redis Adapter:
  Server A 가 Client X 보유
  Server B 가 Client Y 보유
  → Client X 에게 'B 로 가야할 메시지' 가 오면
    Server A → Redis publish "for-Y" → Server B subscribe → Client Y 에게 전달

브라우저(클라이언트)에서 상태를 어떻게 관리하나

서버가 stateless 면 누군가 상태를 보관해야 한다. 보통 클라이언트.

1. Cookies

서버가 Set-Cookie 헤더로 발급, 브라우저가 자동으로 후속 요청에 첨부.

Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Strict; Max-Age=86400

장점: 자동 첨부, HttpOnly 로 JS 접근 차단 가능
단점: 매 요청에 헤더 추가 (페이로드 오버헤드), CSRF 위험

2. LocalStorage / SessionStorage

JavaScript 가 명시적으로 읽고 쓰는 클라이언트 측 키-값 저장소.

localStorage.setItem('token', 'abc123');  // 영구
sessionStorage.setItem('temp', 'xyz');    // 탭 닫으면 사라짐

장점: 5~10 MB 까지 저장, JS 자유 접근
단점: XSS 에 취약, 자동 첨부 안 됨 (직접 헤더 추가 필요)

3. IndexedDB

본격적인 클라이언트 DB. 큰 데이터, 인덱싱, 트랜잭션 지원.

오프라인 PWA, 캐싱 라이브러리 (Apollo cache 등)에 사용

4. JWT (JSON Web Token)

서명된 토큰에 사용자 정보를 담아 클라이언트가 들고 다님. 서버는 토큰만 검증.

header.payload.signature
eyJhbGciOiJI...  .eyJzdWIiOiI...  .Tjw7XYZ...

장점: 완벽한 stateless 서버, 어느 인스턴스도 같은 검증 가능
단점: 토큰 즉시 취소 어려움 (블랙리스트 필요), 토큰 크기

5. WebSocket Open Connection 자체

WebSocket / SSE 가 열려 있는 동안은 TCP 연결 자체가 상태 컨텍스트.

연결 ID 가 곧 사용자 식별자
끊기면 재인증 필요

클라이언트 상태 보관 비교

방법	자동 첨부	XSS 안전	만료 제어	크기
Cookie (HttpOnly)	✓	✓	서버 제어	~4KB
LocalStorage	✗	✗	영구	5-10MB
SessionStorage	✗	✗	탭 단위	5-10MB
IndexedDB	✗	✗ (XSS 영향)	영구	GB 단위
JWT in Cookie	✓	✓	exp 클레임	~1-2KB
JWT in localStorage	✗	✗	exp 클레임	~1-2KB

실제 예시

예시 1: 인증

Stateless (JWT):

1. POST /login { user, pass }
2. Server: 검증 후 JWT 발급
3. Response: { token: "eyJ..." }
4. Client: LocalStorage 저장
5. 이후 요청마다: Authorization: Bearer eyJ...
6. Server: 토큰 서명 검증만으로 사용자 식별, 메모리에 세션 X

Stateful (Server Session):

1. POST /login { user, pass }
2. Server: 검증 후 메모리에 세션 생성, { sid: "abc123" → user_data }
3. Response: Set-Cookie: session=abc123
4. Client: 쿠키 자동 보관
5. 이후 요청마다: Cookie: session=abc123
6. Server: 메모리에서 sid 로 세션 조회, 서버에 데이터 있음

예시 2: 채팅, 두 가지 설계

Stateful 만으로 (Socket.IO):

- Server 가 모든 활성 연결 보유
- "user-1 이 user-2 에게" 메시지: 서버가 메모리에서 user-2 의 socket 찾아 전달
- 수평 확장 시: Redis Adapter 로 서버 간 라우팅

Stateless + Stateful 혼합 (메시지 큐):

- Stateless 서버가 메시지 수신 → DB 저장 + 큐에 발행
- 별도 Push 서버 (Stateful) 가 활성 연결 보유 → 큐 구독 → 사용자에게 전달
- 메시지 영속화는 Stateless 쪽이 책임, 전달은 Stateful 쪽이 책임

예시 3: 장바구니

Stateless (LocalStorage):

const cart = JSON.parse(localStorage.getItem('cart') || '[]');
cart.push({ productId: 42, qty: 1 });
localStorage.setItem('cart', JSON.stringify(cart));
// 서버는 결제 시점에만 알면 됨

Stateful (Server Session):

POST /cart/add { productId: 42, qty: 1 }
// 서버: 메모리의 사용자 세션에 cart 추가
// 다른 디바이스에서 로그인해도 같은 cart 표시됨 (장점)
// 비로그인 시 작동 안 함, sticky session 필요 (단점)

“Stateless vs Stateful” 의 결정 트리

질문 1: 서버가 클라이언트 간 사이에 기억해야 할 데이터가 있나?
  ├─ NO  → Stateless (REST API)
  └─ YES → 질문 2

질문 2: 그 데이터를 서버 메모리에 두는 게 본질적인가?
  ├─ NO  → Stateless + 외부 store (Redis, DB)
  └─ YES → 질문 3

질문 3: 지속 연결(WebSocket 등) 이 본질적인가?
  ├─ NO  → 재고 (외부 store 로 더 단순해질 수 있음)
  └─ YES → Stateful 수용 + Sticky Session 또는 Pub/Sub bus

[!IMPORTANT] “Stateful 이 필요하다” 라는 판단은 신중해야 한다. 외부 store + Stateless 의 조합이 거의 항상 가능하고 운영이 단순하다. WebSocket 같은 지속 연결이 정말 본질적인 경우만 진짜 Stateful 을 받아들이는 게 좋다.

Sticky Session

koa (김신건) — Sat, 13 Jun 2026 00:00:00 GMT

정의

Sticky Session (= Session Affinity)은 로드밸런서가 같은 클라이언트의 요청을 항상 같은 백엔드 서버로 라우팅하도록 하는 동작이다.

[[Stateful]] 서버, 즉 세션 상태를 메모리에 들고 있는 WebSocket 서버, 인메모리 세션 store 를 쓰는 HTTP 서버 등, 가 수평 확장될 때 필수적이다.

왜 필요한가

[[Stateless]] 서버는 어느 서버가 처리해도 결과가 같으므로 round-robin 으로 분산하면 끝. 하지만 [[Stateful]] 서버는 다르다.

Client X 가 Server A 에 로그인 → A의 메모리에 세션 저장
Client X 의 다음 요청 → Server B 로 라우팅 → B는 세션 모름 → 인증 실패

이를 막으려면 X 의 모든 요청을 A 로 보내야 한다 = sticky session.

구현 방법

로드밸런서가 응답에 쿠키를 심고, 다음 요청의 쿠키 값으로 라우팅 결정.

Server A 가 응답 → LB가 Set-Cookie: LB_ROUTE=server-a 추가
Client 다음 요청 → Cookie: LB_ROUTE=server-a → LB가 A로 라우팅

AWS ALB의 stickiness 옵션, Nginx의 sticky cookie 등이 이 방식.

2. IP Hash 기반

hash(client_ip) % N 으로 서버 선택. 같은 IP 는 같은 서버로.

장점: 쿠키 불필요
단점: 모바일 환경에서 IP 가 자주 바뀜, 회사 NAT 뒤 사용자 다수가 한 서버로 몰림

3. URL/Header 기반

JWT 의 일부, 사용자 ID, 세션 ID 등을 해시해 라우팅.

Sticky Session 의 함정

1. 부하 불균형

특정 사용자/세션이 매우 무거우면 그 서버만 과부하. Round-robin 의 균형 분산 효과가 사라진다.

2. 서버 장애 시 세션 손실

A 가 죽으면 A 에 붙어있던 모든 클라이언트의 세션이 사라진다. 재로그인 / 재연결 필요.

3. 확장 시 재분배 필요

서버를 1개 추가하면 일부 사용자의 라우팅 키가 바뀌어야 함. consistent hashing 등으로 완화 가능.

4. 운영 복잡도 증가

배포·롤링 업데이트 시 활성 세션을 안전하게 다른 서버로 옮기는 절차 필요.

대안, Sticky 를 피하는 방법

1. 외부 세션 store

세션 데이터를 Redis, Memcached, DynamoDB 등에 보관. 모든 서버가 같은 데이터에 접근 가능 → [[Stateless]] 서버처럼 동작.

Client → 아무 서버 → Redis 에서 세션 조회 → 처리

비용: 매 요청마다 store I/O (보통 1-3 ms 추가)

2. JWT (클라이언트 측 세션)

세션 정보를 토큰에 담아 클라이언트가 들고 다님. 서버는 토큰만 검증.

장점: 완벽한 stateless 단점: 토큰 만료/취소가 어려움, 토큰이 커짐

3. [[Pub/Sub Bus]] (WebSocket 등 지속 연결)

각 서버가 자기 클라이언트만 관리하되, 서버 간 메시지는 Redis Pub/Sub 으로 라우팅.

Socket.IO + Redis adapter 패턴:
  Client A → Server 1
  Client B → Server 2 (다른 서버)
  Server 1 이 "A → B 에게 메시지" 처리 시:
    1. Redis publish "msg-to-B"
    2. Server 2 가 subscribe → B 에게 전달

실무 권고

시나리오	권장
Stateless REST API	Sticky 불필요
인메모리 세션 + 단일 서버	처음엔 sticky, 곧 외부 store 로 마이그레이션
WebSocket / SSE	외부 store + Pub/Sub bus 패턴 권장
단기 캠페인 / 트래픽 작음	Sticky session 으로 빠르게 시작 OK

[!IMPORTANT] Sticky session 은 “필요악”이다. 가능하면 외부 store 나 JWT 로 [[Stateless]] 화 하는 게 장기적으로 더 단순하다. 다만 WebSocket 처럼 지속 연결이 본질적인 경우엔 피할 수 없으므로 Pub/Sub 같은 다른 추상화로 대처한다.

김신건의 로그 - 위키 / concurrency

[Concurrency] Backpressure: 흐름 제어로 시스템 보호

정의

문제: 비대칭 속도

4가지 전략

1. Bounded Buffer + Block

2. Drop (Lossy)

3. Sampling

4. Pull-based (Reactive Streams)

시스템 레벨 Backpressure

HTTP/2, QUIC 의 flow control

TCP 의 flow control

Bulkhead

Shedding (Load Shedding)

Adaptive Concurrency

흔한 함정

관련 위키

[Concurrency] Circuit Breaker: cascade failure 방어

정의

3가지 상태

시나리오

트리거 조건

라이브러리

Hystrix vs Resilience4j

Fallback

Bulkhead 와의 조합

Envoy / Istio outlier detection

흔한 함정

관련 위키

[Concurrency] Connection Pool: DB, HTTP, gRPC 의 공통 패턴

정의

왜 필요?

흐름

주요 파라미터

Pool 크기 계산

Little’s Law

DB Connection Pool 구조

HTTP Connection Pool

흔한 함정

HikariCP / 표준 라이브러리

관련 위키

[Concurrency] Rate Limiting: token bucket, sliding window

정의

5가지 알고리즘

1. Fixed Window

2. Sliding Log

3. Sliding Window Counter

4. Token Bucket

5. Leaky Bucket

6. GCRA (Generic Cell Rate Algorithm)

비교 매트릭스

분산 환경 구현 (Redis)

HTTP 응답 표준

어디서?

Tier-based Rate Limit

흔한 함정

관련 위키

[Concurrency] Retry + Exponential Backoff + Jitter

정의

4가지 전략

Exponential

Exponential + Full Jitter

Decorrelated Jitter

비교 시뮬레이션

Retry 가능한 에러만 retry

Idempotency 와 짝

상한 설정

Retry-After 헤더

SDK / Library

Retry Budget

흔한 함정

관련 위키

Asynchronous (비동기)

정의

가장 단순한 형태

비동기 호출 흐름

콜백, Future, 이벤트, 세 가지 패턴

1. Callback (콜백)

2. Future / Promise / CompletableFuture

3. Event / Reactive Stream

Java 의 `CompletableFuture.supplyAsync`

Spring 의 `@Async`