김신건의 로그 - 위키 / concurrency

Pub/Sub Bus

koa (김신건) — Thu, 16 Jul 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

sequenceDiagram
    participant CA as "Client A"
    participant S1 as "Server 1"
    participant BUS as "Redis / Kafka"
    participant S2 as "Server 2"
    participant CB as "Client B"

    CA->>S1: "B 에게 메시지"
    S1->>BUS: publish("channel-B", payload)
    BUS->>S2: push (구독 중)
    S2->>CB: send(payload)

서버는 자기 클라이언트만 관리하면 됨. 서버 간 라우팅은 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 라우팅을 투명하게 처리한다.

Redis Pub/Sub vs Redis Streams

Redis 에는 두 가지 메시지 메커니즘이 있다.

flowchart LR
    subgraph PS["Redis Pub/Sub"]
        P1["Publisher"] -->|"즉시 전달"| CH["Channel"]
        CH -->|"구독 중인 경우만"| S1["Subscriber A"]
        CH -->|"구독 중인 경우만"| S2["Subscriber B"]
    end
    subgraph ST["Redis Streams"]
        P2["Producer"] -->|"영구 저장"| STR["Stream (log)"]
        STR -->|"Consumer Group 1"| CG1["Consumer"]
        STR -->|"Consumer Group 2"| CG2["Consumer"]
        STR -->|"ID 기반 replay"| RPL["새 Subscriber"]
    end

항목	Redis Pub/Sub	Redis Streams
메시지 보관	없음 (fire-and-forget)	영구 로그
오프라인 수신자	메시지 유실	나중에 읽기 가능
Consumer Group	없음	있음 (at-most-once / at-least-once)
순서 보장	채널 내 순서 보장	Stream ID 순서 보장
사용처	실시간 브로드캐스트	이벤트 소싱, 감사 로그

// Redis Streams (Kafka 대안)
await redis.xAdd('user-events', '*', { userId: '42', action: 'login' });

// Consumer Group 으로 읽기 (at-least-once)
const [stream, messages] = await redis.xReadGroup(
  'myGroup', 'consumer-1', 'user-events', '>', { COUNT: 10 }
);

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).

Kafka: Pub/Sub 과 Consumer Group

Kafka 는 두 패턴을 동시에 지원한다.

flowchart TB
    TOPIC["Topic: order-created\n(partition 0, 1, 2)"]
    TOPIC --> GRP1["Consumer Group A\n(결제 서비스)\n각 partition 을 1 consumer 가 처리"]
    TOPIC --> GRP2["Consumer Group B\n(알림 서비스)\n동일 메시지 복제 수신"]
    GRP1 --> C1["Consumer A-0 (partition 0)"]
    GRP1 --> C2["Consumer A-1 (partition 1)"]
    GRP1 --> C3["Consumer A-2 (partition 2)"]
    GRP2 --> N1["Consumer B-0"]

같은 Group 내: partition 마다 1 consumer 배정 (큐 방식, 메시지 1회 처리)
다른 Group: 독립 오프셋, 같은 메시지를 각 Group 이 개별 수신 (Pub/Sub 방식)

순서 보장

Redis Pub/Sub: 채널 내 단일 subscriber 에 대한 순서는 보장
              하지만 여러 서버에 broadcast 시 도달 순서는 보장 안 함

Kafka:        partition 내 순서만 보장
              여러 partition 에 걸치면 순서 보장 안 함
              → 같은 key 를 같은 partition 으로 라우팅해서 순서 보장

// Kafka: key 로 partition 고정 → 순서 보장
await producer.send({
  topic: 'user-events',
  messages: [{ key: userId.toString(), value: JSON.stringify(event) }]
  //          ↑ 같은 userId 는 항상 같은 partition
});

부하 특성

구성 요소	부하
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}"
  → 모든 서버가 자기 로컬 캐시 무효화

함정

[!WARNING] subscriber 가 오프라인이면 Redis Pub/Sub 메시지는 유실된다. 장애 복구 후 재구독해도 그 사이 메시지는 없다. 내구성이 필요하면 Redis Streams 또는 Kafka 사용.

[!WARNING] Hot channel 문제: 특정 채널에 메시지가 폭발적으로 몰리면 bus 에 부하가 집중된다. 채널을 partition 단위로 분리하거나 [[backpressure]] 적용.

[!CAUTION] Kafka consumer lag: Consumer 가 처리 속도를 따라가지 못하면 lag 가 쌓인다. kafka-consumer-groups.sh --describe 로 모니터링 필수.

대안과 trade-off

gRPC streaming + 서비스 디스커버리

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

Service mesh (Istio 등)

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

Database notification

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

-- Publisher (PostgreSQL)
NOTIFY user_events, '{"userId": 42, "action": "login"}';

-- Subscriber (psycopg2)
conn.set_isolation_level(ISOLATION_LEVEL_AUTOCOMMIT)
cur.execute("LISTEN user_events;")
select.select([conn], [], [])
conn.poll()
for notify in conn.notifies:
    print(notify.payload)

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

koa (김신건) — Wed, 15 Jul 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 폭증	없음

연결 생명주기

flowchart TD
    Created["생성 (TCP + TLS + auth)"] --> Idle[Idle]
    Idle -->|acquire| Active[Active]
    Active -->|release| Idle
    Active -->|에러| Expired[폐기]
    Idle -->|idle timeout| Expired
    Idle -->|max lifetime| Expired
    Expired -->|"min_size 유지"| Created

연결이 max_lifetime 에 달하기 전에 교체되어야 LB / firewall 의 idle disconnect 로 인한 stale 에러를 피할 수 있다.

흐름

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"]

HikariCP 설정 (Java)

Java 생태계에서 가장 빠른 JDBC pool. Spring Boot 의 기본값이다.

HikariConfig config = new HikariConfig();
config.setJdbcUrl("jdbc:postgresql://host:5432/mydb");
config.setUsername("app_user");
config.setPassword("password");

// 핵심 파라미터
config.setMinimumIdle(5);             // 최소 idle 연결
config.setMaximumPoolSize(20);        // 최대 연결
config.setConnectionTimeout(3_000);   // acquire 대기 최대 3s
config.setIdleTimeout(600_000);       // idle 연결 10분 후 만료
config.setMaxLifetime(1_800_000);     // 연결 최대 수명 30분
config.setLeakDetectionThreshold(2_000); // 2s 반환 안 되면 경고

HikariDataSource dataSource = new HikariDataSource(config);

[!TIP] maxLifetime 은 DB 또는 LB 의 idle timeout 보다 짧게 설정. 그렇지 않으면 LB 가 서버 측 연결을 끊었을 때 stale connection 에러가 난다.

# application.yml (Spring Boot)
spring:
  datasource:
    hikari:
      minimum-idle: 5
      maximum-pool-size: 20
      connection-timeout: 3000
      idle-timeout: 600000
      max-lifetime: 1800000

PgBouncer 설정

PostgreSQL 전용 외부 connection pooler. 여러 app 인스턴스의 연결을 PG 의 작은 pool 로 압축한다.

[databases]
mydb = host=postgres-host port=5432 dbname=mydb

[pgbouncer]
listen_port     = 6432
listen_addr     = *
auth_type       = md5
auth_file       = /etc/pgbouncer/userlist.txt

pool_mode           = transaction
max_client_conn     = 1000
default_pool_size   = 20
min_pool_size       = 5
reserve_pool_size   = 5
reserve_pool_timeout = 3

server_idle_timeout  = 600
server_lifetime      = 3600

transaction mode 가 효율이 가장 높다. 단, prepared statement 와 일부 세션 변수 (SET LOCAL, LISTEN/NOTIFY) 는 transaction 경계를 넘으면 동작하지 않는다.

Python SQLAlchemy 풀 설정

from sqlalchemy import create_engine

engine = create_engine(
    "postgresql+psycopg2://user:pass@host:5432/db",
    pool_size=10,          # 기본 pool 크기
    max_overflow=5,        # pool_size 초과 허용 (임시)
    pool_timeout=3,        # acquire 대기 최대 3s
    pool_recycle=1800,     # 30분마다 연결 재생성 (stale 방지)
    pool_pre_ping=True,    # acquire 전 SELECT 1 validation
)

pool_pre_ping=True 가 stale connection 에러를 대부분 제거한다. 비용은 acquire 시 SELECT 1 1회.

모니터링 지표

메트릭	의미	주의 신호
`active_connections`	현재 사용 중인 연결 수	`max_size` 의 90% 이상 지속
`idle_connections`	대기 중인 연결 수	`min_size` 아래로 떨어지면 부족
`wait_queue_length`	acquire 대기 요청 수	0 을 초과하면 pool 부족
`connection_create_rate`	초당 새 연결 생성 수	높으면 pool 크기 부족 또는 leak
`checkout_timeout_rate`	acquire 실패율	어느 값이든 즉각 조치
`connection_error_rate`	연결 에러율	DB 이슈 또는 stale 연결

HikariCP: Prometheus endpoint 또는 JMX 로 위 지표 모두 노출 가능.

gRPC 연결 풀

gRPC 는 HTTP/2 multiplexing 으로 단일 채널에서 수천 동시 스트림 처리가 가능하다. DB 처럼 대규모 pool 이 필요 없다.

// Go: grpc.ClientConn 재사용 (pool 없이도 됨)
conn, err := grpc.Dial("service:50051", grpc.WithTransportCredentials(insecure.NewCredentials()))
if err != nil {
    log.Fatal(err)
}
defer conn.Close()

// 여러 goroutine 에서 같은 conn 동시 사용 가능
client := pb.NewUserServiceClient(conn)

pool 이 필요한 경우는 백엔드 인스턴스가 여럿이라 여러 address 로 분산할 때다.

흔한 함정

[!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] Retry + Exponential Backoff + Jitter

koa (김신건) — Wed, 15 Jul 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 시간.

재시도 상태 머신

sequenceDiagram
    autonumber
    participant C as Client
    participant S as Service

    C->>S: 1차 요청
    S-->>C: 503 Unavailable
    Note over C: wait 1s + jitter
    C->>S: 2차 재시도
    S-->>C: 503 Unavailable
    Note over C: wait 2s + jitter
    C->>S: 3차 재시도
    S-->>C: 200 OK
    Note over C: 성공, 응답 반환

각 retry 사이에 sleep 을 두고, sleep 은 attempt 가 늘어날수록 exponentially 커진다. jitter 로 동일 시각 재시도를 분산한다.

비교 시뮬레이션

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.

Deadline 전파

분산 시스템에서는 클라이언트가 설정한 deadline 을 모든 하위 서비스로 전파해야 한다. 그렇지 않으면 클라이언트는 이미 timeout 되었는데 하위 서비스는 계속 retry 한다.

import grpc
from datetime import datetime, timedelta

# gRPC: deadline 을 context 로 전파
with grpc.insecure_channel("service:50051") as channel:
    stub = ServiceStub(channel)
    deadline = datetime.utcnow() + timedelta(seconds=10)
    # timeout 이 남은 시간으로 자동 설정
    resp = stub.CallMethod(request, timeout=10.0)

HTTP 에서는 X-Request-Deadline 같은 커스텀 헤더 또는 X-B3-Deadline 로 전파한다.

[!CAUTION] deadline 전파 없이 retry 하면 zombie retry 가 발생한다. 클라이언트는 504 를 받고 떠났는데 서버 내부에서는 수 분간 재시도가 계속된다. 자원 낭비 + 부하 증폭.

구현 예시

Python: tenacity

from tenacity import (
    retry,
    stop_after_attempt,
    wait_exponential,
    wait_random,
    retry_if_exception_type,
)
import requests

@retry(
    stop=stop_after_attempt(5),
    wait=wait_exponential(multiplier=1, min=1, max=16) + wait_random(0, 2),
    retry=retry_if_exception_type((requests.ConnectionError, requests.Timeout)),
    reraise=True,
)
def call_api(url: str) -> dict:
    resp = requests.get(url, timeout=5)
    resp.raise_for_status()
    return resp.json()

Java: Resilience4j

RetryConfig config = RetryConfig.custom()
    .maxAttempts(5)
    .intervalFunction(IntervalFunction.ofExponentialRandomBackoff(500, 2.0, 0.5))
    .retryOnException(e -> e instanceof HttpServerErrorException)
    .build();

Retry retry = Retry.of("api-call", config);
Supplier<String> decorated = Retry.decorateSupplier(retry, () -> callDownstream());
Try.ofSupplier(decorated).recover(ex -> fallback()).get();

Go: backoff 라이브러리

import "github.com/cenkalti/backoff/v4"

b := backoff.NewExponentialBackOff()
b.InitialInterval = 1 * time.Second
b.MaxInterval = 16 * time.Second
b.MaxElapsedTime = 60 * time.Second

err := backoff.RetryNotify(
    func() error {
        return callAPI(ctx)
    },
    backoff.WithContext(b, ctx),
    func(err error, d time.Duration) {
        log.Printf("retry after %v: %v", d, err)
    },
)

Hedged Requests

Retry 와 다른 전략: 첫 요청이 일정 시간 내에 응답 안 오면 두 번째 요청을 병렬로 보내고, 먼저 오는 응답을 사용. 실패 없이 tail latency 를 낮추는 패턴.

t=0:   → request 1
t=50ms → (응답 없음) → request 2 병렬 시작
t=80ms ← response 2 도착 → response 1 취소

import asyncio

async def hedged_call(url: str, hedge_delay=0.05) -> dict:
    async with aiohttp.ClientSession() as session:
        task1 = asyncio.create_task(session.get(url))
        await asyncio.sleep(hedge_delay)
        task2 = asyncio.create_task(session.get(url))
        done, pending = await asyncio.wait(
            [task1, task2], return_when=asyncio.FIRST_COMPLETED
        )
        for t in pending:
            t.cancel()
        return await done.pop()

[!IMPORTANT] Hedging 은 non-idempotent 요청 (POST 결제 등) 에는 금지. 멱등 읽기 (GET, SELECT) 에만 사용.

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 폭증. 한 곳에서만.

Deadline 미전파 = 클라이언트 timeout 후에도 하위 서비스가 계속 재시도.

Stateful

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

정의

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

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

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

핵심 특성

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

수평 확장 시각화

Sticky Session 구성

flowchart LR
    LB[Load Balancer]
    C1[Client 1] --> LB
    C2[Client 2] --> LB
    C3[Client 3] --> LB
    LB -->|sticky A| SA[Server A]
    LB -->|sticky B| SB[Server B]
    SA --> MemA[Session A]
    SB --> MemB[Session B]

LB 가 쿠키 또는 IP hash 로 클라이언트를 특정 서버에 고정한다. Server A 가 다운되면 그 세션들이 모두 손실된다.

WebSocket 클러스터 (Pub/Sub 버스)

flowchart LR
    C1[Client 1] --> SA[Server A]
    C2[Client 2] --> SB[Server B]
    SA -->|publish| Bus["Redis Pub/Sub"]
    SB -->|subscribe| Bus
    Bus -->|"broadcast"| SA
    Bus -->|"broadcast"| SB

서버 A 가 클라이언트 B 에게 메시지를 전달해야 할 때, Redis Pub/Sub 버스를 통해 서버 B 가 대신 전달한다. Socket.IO + Redis Adapter 패턴이 전형.

어디에 상태가 사는가

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 패턴이 전형.

Kubernetes StatefulSet

Stateful 워크로드는 Kubernetes StatefulSet 으로 운영한다. Deployment 와 달리 각 pod 에 안정적인 이름과 순서가 보장된다.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: chat-server
spec:
  serviceName: "chat"
  replicas: 3
  selector:
    matchLabels:
      app: chat-server
  template:
    spec:
      containers:
        - name: chat-server
          image: chat:latest
          volumeMounts:
            - name: data
              mountPath: /data
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 10Gi

StatefulSet 이 생성하는 pod 이름: chat-server-0, chat-server-1, chat-server-2. DNS 이름: chat-server-0.chat.default.svc.cluster.local.

[!IMPORTANT] StatefulSet 은 삭제 순서도 역순으로 보장한다. 데이터베이스처럼 replica 순서가 중요한 시스템에 필수.

[[k8s-statefulset]] 에서 더 자세한 설명을 볼 수 있다.

세션 어피니티 (Sticky Session) 상세

upstream backend {
    ip_hash;              # IP 기반 고정
    server server1:8080;
    server server2:8080;
}

# 또는 쿠키 기반
upstream backend {
    server server1:8080;
    server server2:8080;
    sticky cookie srv_id expires=1h;
}

AWS ALB sticky session

{
  "TargetGroupAttributes": [
    { "Key": "stickiness.enabled", "Value": "true" },
    { "Key": "stickiness.type", "Value": "lb_cookie" },
    { "Key": "stickiness.lb_cookie.duration_seconds", "Value": "86400" }
  ]
}

고정이 너무 강하면 특정 서버에 트래픽이 쏠린다. ip_hash 보다 least_conn + sticky cookie 조합이 부하 분산에 유리하다.

그레이스풀 드레인

Stateful 서버를 재배포할 때 활성 세션을 잃지 않으려면 graceful drain 이 필수다.

1. LB 가 해당 인스턴스를 풀에서 제거 (신규 트래픽 차단)
2. 기존 연결이 자연스럽게 끝나길 대기 (drain timeout: 보통 30-60s)
3. drain timeout 초과 → 강제 종료 (SIGKILL)

# Kubernetes: terminationGracePeriodSeconds
spec:
  terminationGracePeriodSeconds: 60
  containers:
    - name: chat-server
      lifecycle:
        preStop:
          exec:
            command: ["/bin/sh", "-c", "sleep 5"]

WebSocket 의 경우 drain 신호를 받으면 클라이언트에게 close frame 을 보내 재연결을 유도한다.

실무 예시

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

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

정의

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

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

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

핵심 특성

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

수평 확장 아키텍처

flowchart LR
    C1[Client 1] --> LB[Load Balancer]
    C2[Client 2] --> LB
    C3[Client N] --> LB
    LB --> S1[Server 1]
    LB --> S2[Server 2]
    LB --> S3[Server N]
    S1 & S2 & S3 --> Redis[(Redis)]
    S1 & S2 & S3 --> DB[(Database)]

모든 서버가 동일한 Redis 와 DB 를 바라본다. LB 가 어느 서버로 요청을 보내도 같은 결과가 나온다. 서버 추가는 인스턴스 수만 늘리면 끝이다.

Health check 로 고장 난 서버를 풀에서 제거해도 나머지 서버가 즉시 트래픽을 흡수한다. 사용자에게는 무영향이다.

어떻게 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 만 읽고 응답.

JWT 인증 플로우

sequenceDiagram
    autonumber
    participant C as Client
    participant S as Server
    participant DB

    C->>S: POST /login, credentials
    S->>DB: SELECT user
    DB-->>S: user found
    S-->>C: 200 OK, JWT signed
    Note over C: 클라이언트 JWT 보관
    C->>S: GET /api/profile, Authorization Bearer JWT
    S->>S: JWT 서명 검증
    S-->>C: 200 OK, profile

서버는 요청 사이에 아무것도 기억하지 않는다. JWT 서명 키만 있으면 어느 인스턴스든 동일한 검증이 가능하다.

실무 예시

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 등에 위임 필수.

Redis 세션 스토어 구현

JWT 대신 서버 측 세션 ID 를 유지해야 할 때도, 외부 store 에 세션을 두면 서버 자체는 stateless 로 운영할 수 있다.

import uuid, json
import redis

r = redis.Redis(host="redis-host", port=6379)
TTL = 3600  # 1 hour

def create_session(user_id: str) -> str:
    sid = str(uuid.uuid4())
    r.setex(f"session:{sid}", TTL, json.dumps({"user_id": user_id}))
    return sid

def get_session(sid: str) -> dict | None:
    raw = r.get(f"session:{sid}")
    return json.loads(raw) if raw else None

def delete_session(sid: str) -> None:
    r.delete(f"session:{sid}")

Redis Sentinel 또는 Redis Cluster 로 단일 장애점을 제거해야 한다. Redis 다운 = 전체 서비스 인증 불능이 되기 때문이다.

# Redis Sentinel docker-compose 간략 예시
services:
  redis-master:
    image: redis:7
  redis-replica:
    image: redis:7
    command: redis-server --replicaof redis-master 6379
  redis-sentinel:
    image: redis:7
    command: redis-sentinel /etc/sentinel.conf

Kubernetes에서의 Stateless

Stateless 서버는 Kubernetes Deployment 로 운영한다. [[k8s-statefulset]] 이 필요 없다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api-server
  template:
    spec:
      containers:
        - name: api-server
          image: myapp:latest
          env:
            - name: REDIS_URL
              valueFrom:
                secretKeyRef:
                  name: redis-secret
                  key: url

HPA 로 CPU / RPS 기반 자동 스케일도 가능하다.

kubectl autoscale deployment api-server --cpu-percent=70 --min=2 --max=20

pod 에 순서나 안정적인 네트워크 ID 가 없어도 상관없다. stateless 서버에는 이게 오히려 장점이다.

언제 Stateless를 선택하는가

상황	권장
REST API, 배치 처리	Stateless
퍼블릭 마이크로서비스	Stateless
Serverless / Lambda	Stateless
실시간 채팅, 게임 서버	[[Stateful]] 고려
비디오 스트리밍 세션	[[Stateful]] 고려
P2P 협업 도구	[[Stateful]] 고려

수평 확장·배포 단순성이 목표면 stateless 가 기본 선택이다. 저지연 양방향 통신이 핵심이면 [[Stateful]] 을 고려한다.

함정과 한계

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.

[Concurrency] Circuit Breaker: cascade failure 방어

koa (김신건) — Tue, 14 Jul 2026 00:00:00 GMT

정의

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

[[backpressure]]와 함께 cascade failure 방어의 핵심 패턴. 호출 실패가 연쇄적으로 전파되는 것을 막는다.

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: 200
    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)	50%
Slow call rate	N초 이상 응답 비율 > X%	100ms 초과 50%
Consecutive failures	연속 N회 실패	5회
Minimum calls	통계 유효 최소 호출 수	10회

실전 파라미터 상세

flowchart LR
    subgraph Window["Sliding Window (count 기반, 10개)"]
        R1[req] --> R2[req] --> R3[req] --> R4[FAIL] --> R5[FAIL]
        R5 --> R6[req] --> R7[FAIL] --> R8[req] --> R9[FAIL] --> R10[FAIL]
    end
    Window -->|"실패율 50% > 임계"| Open[OPEN]

파라미터	의미	기본값
`slidingWindowSize`	통계 집계 요청 수 (count) 또는 시간 (time)	100
`failureRateThreshold`	Open 전환 실패율 (%)	50
`slowCallDurationThreshold`	slow call 기준 시간	60s
`slowCallRateThreshold`	slow call 비율 임계 (%)	100
`waitDurationInOpenState`	Open 유지 시간	60s
`permittedNumberOfCallsInHalfOpenState`	Half-Open 시 허용 호출 수	10
`minimumNumberOfCalls`	통계 유효 최소 호출 수	100

Resilience4j 설정 예시

application.yml

resilience4j:
  circuitbreaker:
    instances:
      payment-service:
        slidingWindowType: COUNT_BASED
        slidingWindowSize: 10
        minimumNumberOfCalls: 5
        failureRateThreshold: 50
        slowCallDurationThreshold: 2000ms
        slowCallRateThreshold: 80
        waitDurationInOpenState: 30s
        permittedNumberOfCallsInHalfOpenState: 3
        automaticTransitionFromOpenToHalfOpenEnabled: true
        recordExceptions:
          - java.io.IOException
          - java.util.concurrent.TimeoutException
        ignoreExceptions:
          - com.example.BusinessException

Java 코드

@Service
public class PaymentService {

    private final CircuitBreaker cb;
    private final ExternalPaymentClient client;

    public PaymentService(CircuitBreakerRegistry registry, ExternalPaymentClient client) {
        this.cb = registry.circuitBreaker("payment-service");
        this.client = client;
    }

    public PaymentResult charge(ChargeRequest req) {
        return cb.executeSupplier(() -> client.charge(req));
    }

    // Fallback 포함
    public PaymentResult chargeWithFallback(ChargeRequest req) {
        return Try.ofSupplier(
            CircuitBreaker.decorateSupplier(cb, () -> client.charge(req))
        ).recover(ex -> PaymentResult.queued(req.getId())).get();
    }
}

이벤트 리스너 (모니터링)

cb.getEventPublisher()
    .onStateTransition(e ->
        log.warn("CB [{}] {} -> {}",
            e.getCircuitBreakerName(),
            e.getStateTransition().getFromState(),
            e.getStateTransition().getToState()))
    .onCallNotPermitted(e ->
        metrics.increment("cb.rejected", "name", e.getCircuitBreakerName()));

라이브러리

라이브러리	언어	비고
Resilience4j	Java	Hystrix 후계, 현재 표준
Polly	.NET	표준
Sentinel	Java/Go	Alibaba, 트래픽 제어 통합
pybreaker	Python	단순
opossum	Node	EventEmitter 친화
Envoy outlier detection	proxy	sidecar 자동
Istio	service mesh	Envoy 기반 자동 CB

Hystrix vs Resilience4j

	Hystrix (2018 EOL)	Resilience4j
Thread pool 격리	기본	옵션
Semaphore	OK	OK
Reactive	일부	기본 (Reactor/RxJava)
Lightweight	X	O (8 MB)
활성 개발	X	O
Spring Boot 통합	Spring Cloud Netflix	Spring Cloud CircuitBreaker
설정 방식	`@HystrixCommand`	`@CircuitBreaker` + yml

[!IMPORTANT] Hystrix는 2018년 EOL. Spring Cloud Netflix Hystrix도 deprecated. 신규 프로젝트는 Resilience4j 사용. 기존 Hystrix 코드는 @HystrixCommand → @CircuitBreaker + Resilience4j 설정으로 마이그레이션.

Fallback

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

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

// Resilience4j + Spring
@CircuitBreaker(name = "inventory", fallbackMethod = "inventoryFallback")
public InventoryStatus checkInventory(String productId) {
    return inventoryClient.check(productId);
}

public InventoryStatus inventoryFallback(String productId, Exception ex) {
    log.warn("Inventory CB open, returning cached: {}", productId);
    return cache.getOrDefault(productId, InventoryStatus.UNKNOWN);
}

단순 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.

resilience4j:
  bulkhead:
    instances:
      payment-service:
        maxConcurrentCalls: 20
        maxWaitDuration: 100ms
  thread-pool-bulkhead:
    instances:
      inventory-service:
        maxThreadPoolSize: 10
        coreThreadPoolSize: 5
        queueCapacity: 100

Envoy / Istio outlier detection

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

# Istio DestinationRule
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: payment-service
spec:
  host: payment-service
  trafficPolicy:
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 30s
      baseEjectionTime: 30s
      maxEjectionPercent: 50
      minHealthPercent: 30

consecutive5xxErrors: 연속 5xx 횟수 → 해당 pod 제외
baseEjectionTime: 제외 기간 (ejection 횟수에 비례해 증가)
maxEjectionPercent: 최대 제외 비율 (전체 다운 방지)

모니터링

CB 상태를 모르면 운영 불가. 필수 메트릭:

resilience4j_circuitbreaker_state{name="payment-service"} 0  # 0=CLOSED, 1=OPEN, 2=HALF_OPEN
resilience4j_circuitbreaker_failure_rate{name="payment-service"} 45.2
resilience4j_circuitbreaker_calls_total{name="payment-service", kind="successful"} 1234
resilience4j_circuitbreaker_calls_total{name="payment-service", kind="failed"} 56
resilience4j_circuitbreaker_not_permitted_calls_total{name="payment-service"} 89

Grafana 대시보드 권장 패널:

CB 상태 타임라인 (CLOSED/OPEN/HALF-OPEN)
실패율 추이
차단된 호출 수 (not_permitted)
응답 시간 p99

흔한 함정

[!WARNING]

임계가 너무 민감 = 일시 jitter로 false open. 짧은 window에서 조심. minimumNumberOfCalls 충분히 설정.

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

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

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

ignoreExceptions 미설정 = 비즈니스 예외 (400 Bad Request)도 실패로 카운트 → false open.

Sticky Session

koa (김신건) — Tue, 14 Jul 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.

아키텍처 시각화

flowchart LR
    C1["Client A<br/>(cookie: srv=A)"] -->|"sticky → Server A"| LB[Load Balancer]
    C2["Client B<br/>(cookie: srv=B)"] -->|"sticky → Server B"| LB
    C3["Client C<br/>(새 요청, 쿠키 없음)"] -->|"round-robin"| LB
    LB -->|"Session A 있음"| SA["Server A<br/>session: A"]
    LB -->|"Session B 있음"| SB["Server B<br/>session: B"]
    LB -->|"신규 배정"| SC["Server C"]

구현 방법

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

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

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

장점: IP 변경에도 세션 유지 (모바일 유리)
단점: 클라이언트가 쿠키를 지우면 세션 끊김, HTTPS가 아니면 탈취 가능

2. IP Hash 기반

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

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

3. URL/Header 기반

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

upstream backend {
    hash $http_x_user_id consistent;
    server 10.0.0.1:8080;
    server 10.0.0.2:8080;
    server 10.0.0.3:8080;
}

로드밸런서별 설정

AWS ALB

ALB는 두 종류의 stickiness를 지원한다:

1. Load balancer generated cookie (AWSALB)
   - ALB가 자동으로 쿠키 생성
   - 기간: 1초 ~ 7일 설정 가능

2. Application-based cookie (AWSALBAPP)
   - 앱이 직접 쿠키 발급
   - 쿠키 이름 직접 지정

{
  "Type": "forward",
  "TargetGroupArn": "...",
  "ForwardConfig": {
    "TargetGroupStickinessConfig": {
      "Enabled": true,
      "DurationSeconds": 86400
    }
  }
}

Nginx (upstream sticky)

upstream app {
    sticky cookie srv_id expires=1h path=/;
    server 10.0.0.1:8080;
    server 10.0.0.2:8080;
}

HAProxy

backend app
    balance roundrobin
    cookie SERVERID insert indirect nocache
    server s1 10.0.0.1:8080 check cookie s1
    server s2 10.0.0.2:8080 check cookie s2

Kubernetes Service sessionAffinity

K8s Service 오브젝트에서 클라이언트 IP 기반 affinity를 설정:

apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  selector:
    app: my-app
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 10800   # 3시간
  ports:
    - port: 80
      targetPort: 8080

[!IMPORTANT] K8s의 sessionAffinity: ClientIP는 kube-proxy (iptables/ipvs) 레벨에서 작동한다. Ingress를 통하면 ingress controller가 별도로 cookie 기반 sticky를 처리해야 한다. Nginx Ingress Controller에서는 nginx.ingress.kubernetes.io/affinity: "cookie" annotation 사용.

세션 수명 주기 시퀀스

sequenceDiagram
    autonumber
    participant C as Client
    participant LB as LoadBalancer
    participant SA as ServerA
    participant SB as ServerB

    C->>LB: GET /login, no cookie
    LB->>SA: 신규 배정, round-robin
    SA->>SA: 세션 생성, sess_id=abc
    SA-->>LB: 200 OK, Set-Cookie sess_id=abc
    LB-->>C: 200 OK, Set-Cookie AWSALB=hash_A + sess_id=abc

    C->>LB: POST /order, Cookie AWSALB=hash_A
    LB->>SA: AWSALB 쿠키로 A로 라우팅
    SA->>SA: 세션 조회 OK, 주문 처리
    SA-->>LB: 200 OK

    Note over SA: Server A 장애 발생
    C->>LB: GET /cart, Cookie AWSALB=hash_A
    LB->>SB: A 다운, B로 재배정
    SB->>SB: sess_id=abc 없음, 세션 소실
    SB-->>C: 302 /login, 재로그인 필요

Sticky Session의 함정

1. 부하 불균형

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

flowchart LR
    Heavy["Heavy User<br/>(동영상 업로드 중)"] -->|sticky| SA["Server A<br/>CPU 95%"]
    Light1["Light User"] -->|sticky| SB["Server B<br/>CPU 10%"]
    Light2["Light User"] -->|sticky| SC["Server C<br/>CPU 10%"]

2. 서버 장애 시 세션 손실

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

3. 확장 시 재분배 필요

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

4. 운영 복잡도 증가

배포/롤링 업데이트 시 활성 세션을 안전하게 다른 서버로 옮기는 절차 필요. Blue-green 배포 시 세션 드레이닝이 필수.

[!WARNING] ALB의 deregistration_delay (기본 300초) 동안 기존 연결이 서서히 다른 서버로 이전된다. 이 시간 내에 서버가 강제 종료되면 세션이 그냥 끊긴다. 충분한 draining 시간을 설정하거나 외부 store로 전환하는 것이 안전하다.

대안: Sticky를 피하는 방법

1. 외부 세션 store

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

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

# Flask + Redis session
from flask_session import Session
import redis

app.config["SESSION_TYPE"] = "redis"
app.config["SESSION_REDIS"] = redis.from_url("redis://redis:6379")
Session(app)

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

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

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

Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...

장점: 완벽한 stateless, 서버 수평 확장 자유
단점: 토큰 만료/취소가 어려움 (revocation list 필요), 토큰이 커짐

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	장애 내성	복잡도	비용
Sticky session	X	낮음	낮음	낮음
외부 세션 store	O	높음	중간	Redis 비용
JWT	O	높음	중간	없음
Pub/Sub bus	O (WebSocket)	높음	높음	Redis 비용

실무 권고

시나리오	권장
Stateless REST API	Sticky 불필요
인메모리 세션 + 단일 서버	처음엔 sticky, 곧 외부 store로 마이그레이션
WebSocket / SSE	외부 store + Pub/Sub bus 패턴 권장
단기 캠페인 / 트래픽 작음	Sticky session으로 빠르게 시작 OK
K8s 롤링 배포 빈번	외부 store 필수 (Pod 재시작마다 세션 소실)
게임 서버	지속 연결 특성상 sticky 불가피, 장애 시 재접속 설계

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

Synchronous (동기)

koa (김신건) — Tue, 14 Jul 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);                          // 그 다음 진행

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

4가지 조합

동기/비동기와 블로킹/논블로킹은 독립적인 두 축이다. 조합하면 4가지가 나온다.

flowchart TD
    subgraph Sync["Synchronous (호출자가 결과를 기다림)"]
        SB["Sync + Blocking\n가장 흔함\nthread sleep"]
        SNB["Sync + Non-Blocking\n드묾\nbusy-wait / spin"]
    end
    subgraph Async["Asynchronous (호출자가 결과를 기다리지 않음)"]
        AB["Async + Blocking\n안티패턴\ncallback 안에서 sleep"]
        ANB["Async + Non-Blocking\n고성능 IO\nNIO, epoll, io_uring"]
    end

조합	호출자 대기	스레드 상태	예시
Sync + Blocking	O	sleep	`socket.read()`, `Thread.sleep()`
Sync + Non-Blocking	O	active (spin)	`Thread.onSpinWait()`, busy-loop
Async + Blocking	X	sleep (안티패턴)	callback 안에서 `Thread.sleep()`
Async + Non-Blocking	X	active (event loop)	Node.js, Netty, epoll

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를 낭비하므로 거의 안 쓴다. 매우 짧은 대기에만 쓰이는 마이크로 최적화.

동기 호출 흐름

sequenceDiagram
    participant Caller
    participant Callee

    Caller->>Callee: call()
    Note over Caller: waiting (blocked)
    Callee->>Callee: 작업 수행
    Callee-->>Caller: return result
    Note over Caller: 결과 처리 시작

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

동기 vs 비동기 대비

sequenceDiagram
    participant C1 as "Caller (Sync)"
    participant S as "Service"
    participant C2 as "Caller (Async)"

    C1->>S: call()
    Note over C1: blocked (대기)
    S-->>C1: result
    Note over C1: 처리 재개

    C2->>S: call(callback)
    Note over C2: 즉시 다음 작업 진행
    S-->>C2: callback(result)
    Note over C2: 콜백에서 처리

장점

읽기 쉽다: 위에서 아래로 흐름이 명확
에러 처리가 자연스럽다: 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

언어별 동기 IO 패턴

Python (requests)

import requests

# 동기 (기본)
response = requests.get("https://api.example.com/users")
data = response.json()   # 응답 올 때까지 block

# 비동기 대안: httpx + asyncio
import httpx, asyncio

async def fetch():
    async with httpx.AsyncClient() as client:
        response = await client.get("https://api.example.com/users")
        return response.json()

Node.js

// 동기 (fs.readFileSync) - 이벤트 루프 블로킹
const data = fs.readFileSync("data.txt", "utf8");   // 블로킹!

// 비동기 (권장)
const data = await fs.promises.readFile("data.txt", "utf8");

[!WARNING] Node.js에서 *Sync 함수 (예: readFileSync, execSync)는 이벤트 루프 전체를 블로킹한다. 서버 코드에서는 절대 사용 금지. 스크립트나 초기화 코드에서만 허용.

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)**가 이 한계를 깬다. 동기 코드 그대로 두면서도 수백만 동시 연결을 가능하게 만든다.

// Virtual Threads: 동기 코드 그대로, 스레드 수 제한 없음
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    executor.submit(() -> {
        String r = http.get(url);   // 여전히 sync, 하지만 virtual thread
        process(r);
    });
}

sync와 [[Blocking]]의 관계

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

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

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

흔한 함정

[!WARNING]

동기 = 느림이라는 오해: 동기 자체가 느린 게 아니라, 느린 I/O를 동기로 기다리는 것이 문제. 빠른 I/O는 동기가 더 단순하고 충분히 빠르다.

스레드 풀 크기 과소 설정: 동시 요청 수 > 스레드 수 → 큐 대기 → 응답 지연. 모니터링 필수.

Virtual Thread에서 synchronized 블록: Java 21 Virtual Thread는 synchronized 블록 안에서 blocking 시 carrier thread를 점유 (pinning). ReentrantLock 사용 권장.

Node.js에서 Sync 함수 사용: 이벤트 루프 전체 블로킹. 서버 코드에서 절대 금지.

[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.

Java: Reactive Streams API 구현

Project Reactor (Spring WebFlux 기반) 를 사용한 pull-based backpressure 예시:

Flux<String> upstream = Flux.generate(sink -> sink.next(fetchNextItem()));

upstream
    .onBackpressureBuffer(1000)           // bounded buffer
    .publishOn(Schedulers.boundedElastic())
    .subscribe(new BaseSubscriber<String>() {
        @Override
        protected void hookOnSubscribe(Subscription subscription) {
            request(50);  // 최초 50개 요청
        }

        @Override
        protected void hookOnNext(String value) {
            process(value);
            request(1);   // 처리 완료 후 1개씩 추가 요청
        }
    });

onBackpressureBuffer / onBackpressureDrop / onBackpressureLatest 로 정책 선택:

연산자	전략	사용 시나리오
`onBackpressureBuffer(n)`	Bounded buffer	순간 burst 허용, OOM 방지
`onBackpressureDrop()`	Drop newest	실시간 센서 데이터, 손실 OK
`onBackpressureLatest()`	Keep latest only	UI 화면 갱신, 최신값만 유의미
`onBackpressureError()`	즉시 오류	손실 불허 파이프라인

자세히는 [[spring-webflux]] 참고.

Kafka Producer 설정

Kafka 에서 producer 의 backpressure 는 max.block.ms 와 buffer.memory 로 제어한다.

# Producer 설정
buffer.memory=33554432        # 총 버퍼 크기 (32 MB)
max.block.ms=60000            # 버퍼가 가득 찼을 때 block 최대 시간
batch.size=16384              # batch 크기
linger.ms=5                   # 배치 대기 시간

버퍼가 가득 차면 KafkaProducer.send() 가 max.block.ms 동안 blocking. 그래도 공간이 안 나면 TimeoutException. 이것이 Kafka producer 레벨의 backpressure. Consumer lag 기반 스케일링은 [[kafka-consumer-group]] 참고.

Resilience4j 와의 연계

Backpressure 는 단독으로 사용하기보다 circuit breaker, rate limiter 와 조합한다.

flowchart LR
    Client["클라이언트 요청"] --> RL["Rate Limiter\n초당 N건 제한"]
    RL --> CB["Circuit Breaker\n실패율 임계 초과 시 차단"]
    CB --> BP["Bulkhead\n동시 실행 수 제한"]
    BP --> Svc["Service"]
    Svc -.실패.-> CB
    CB -.open.-> FBK["Fallback 응답"]

Resilience4j 에서 셋을 조합한 예시:

Supplier<String> decorated = Decorators.ofSupplier(() -> remoteService.call())
    .withRateLimiter(rateLimiter)
    .withCircuitBreaker(circuitBreaker)
    .withBulkhead(bulkhead)
    .decorate();

[[circuit-breaker]] 와 [[rate-limiting]] 함께 설계해야 실질적인 cascade failure 방지가 된다.

관찰 가능성 (Observability)

Backpressure 가 발동하고 있는지 모르면 운영 중에 발견하지 못한다. 필수 메트릭:

메트릭	설명	경보 기준
`queue.size` / `buffer.used`	현재 버퍼 점유율	> 80%
`drop.rate`	초당 드롭된 메시지 수	> 0 (손실 불허 시)
`block.time`	producer block 시간	> SLO 임계
`consumer.lag`	Kafka consumer lag	지속 증가
`http.server.requests` + 429/503 비율	HTTP 레이어 shed 비율	급증 시 알람

Micrometer + Prometheus + Grafana 스택으로 위 메트릭을 시각화하면 backpressure 발동 시점과 원인을 즉시 파악할 수 있다.

[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 폭증. 백엔드 보호 안 됨.

알고리즘 선택 기준

flowchart TD
    Q1["메모리 제약 있음?"] -->|"예"| Q2["Burst 허용?"]
    Q1 -->|"아니오"| SL["Sliding Log 적합"]
    Q2 -->|"예"| TB["Token Bucket"]
    Q2 -->|"아니오"| GCRA["GCRA or Leaky Bucket"]
    TB --> Q3["분산 환경?"]
    GCRA --> Q3
    Q3 -->|"예"| REDIS["Redis Lua 스크립트"]
    Q3 -->|"아니오"| MEM["In-memory"]

클라이언트 구현 패턴

클라이언트 측에서 429 를 올바르게 처리하지 않으면 오히려 서버에 더 큰 부하를 줄 수 있습니다.

import time
import random

def api_call_with_backoff(fn, max_retries=5):
    for attempt in range(max_retries):
        response = fn()
        if response.status_code != 429:
            return response

        retry_after = int(response.headers.get('Retry-After', 1))
        # 지수 백오프 + 지터
        wait = retry_after + (2 ** attempt) + random.uniform(0, 1)
        time.sleep(wait)

    raise Exception("Rate limit 초과: 재시도 실패")

[!IMPORTANT] Retry-After 헤더를 반드시 준수하세요. 무시하고 즉시 재시도하면 자기 DDoS 가 됩니다.

Rate Limit 모니터링

관찰해야 할 핵심 지표:

지표	설명
`rate_limit_hits_total`	총 차단 횟수, spike = 공격 또는 버그
`tokens_remaining`	버킷 잔여 토큰, 낮으면 한도 근접
`p99 latency`	Redis 조회 추가 지연 모니터링
Top-N blocked users	악의적 사용자 또는 버그 클라이언트 탐지

# Prometheus 메트릭 예시
from prometheus_client import Counter

rate_limit_hits = Counter(
    'rate_limit_hits_total',
    'Rate limit 에 걸린 요청 수',
    ['endpoint', 'user_tier']
)

@app.route('/api/resource')
def resource():
    if not rate_limiter.allow(request.user):
        rate_limit_hits.labels(
            endpoint='/api/resource',
            user_tier=request.user.tier
        ).inc()
        return jsonify(error='rate_limit_exceeded'), 429

실전 운영 고려사항

Warm-up 정책: 신규 사용자는 초반 더 관대하게 처리하여 정상 사용 패턴 파악.
Rate Limit 예외: 내부 서비스, health check endpoint 는 화이트리스트 처리.
비동기 카운터: 극한 성능 필요 시 로컬 카운터로 먼저 판단, Redis 는 비동기 동기화 (근사).
다중 버킷: 분당 + 초당 동시 적용.

limits = {
    'per_second': 10,
    'per_minute': 100,
    'per_hour': 2000,
}
# 셋 다 통과해야 허용 (AND 조건)

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 는 다른 스레드를 처리한다.

스레드 상태 전이

Java 스레드 상태 중 blocking 이 발생하는 지점을 요약하면 다음과 같다.

flowchart LR
    NEW --> RUNNABLE
    RUNNABLE -->|"blocking call"| BLOCKED
    BLOCKED -->|"I/O 완료 / 락 해제"| RUNNABLE
    RUNNABLE -->|"Object.wait"| WAITING
    WAITING -->|"notify / 인터럽트"| RUNNABLE
    RUNNABLE -->|"완료"| TERMINATED

BLOCKED: I/O, lock 획득, sleep 시 진입. WAITING: 명시적 wait() / join() 시 진입. 두 상태 모두 CPU 를 점유하지 않는다. OS scheduler 가 다른 스레드에게 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 패러다임 채택

함정

1. blocking + ThreadPoolExecutor 풀 고갈

스레드 풀 안에서 blocking I/O 를 하면 모든 스레드가 block 되는 순간 새 요청은 큐에 쌓인다. 풀 크기를 I/O latency 기준으로 계산하지 않으면 타임아웃과 OOM 로 이어진다.

Little’s Law: N = λ × W (평균 동시 스레드 = 초당 요청 × 평균 응답 시간). I/O 가 느리면 N 이 커진다.

2. synchronized 블록 내부에서 blocking I/O

synchronized (lock) {
    String data = socket.readLine();   // block 동안 lock 을 계속 보유
}

lock 을 보유한 채로 block 되면, 다른 스레드가 같은 lock 을 기다리며 연쇄 block 발생. 가능하면 I/O 완료 후 sync 블록에 진입.

3. Virtual Thread 와 synchronized pinning

Java 21 Virtual Thread 는 blocking call 시 carrier thread 에서 unmount 하지만, native synchronized 블록 안에서는 unmount 하지 못한다 (JDK 23 이전 기본값). 이를 “pinning” 이라 부르며, [[ReentrantLock]] 으로 교체하면 해소된다.

// ✗ Virtual Thread 에서 pinning 발생
synchronized (this) {
    blockingCall();
}

// ✓ Virtual Thread 친화
lock.lock();
try { blockingCall(); }
finally { lock.unlock(); }

4. InterruptedException 무시

try {
    q.take();
} catch (InterruptedException e) {
    // ✗ 무시하면 인터럽트 신호 소실
}

// ✓ 복원 필수
} catch (InterruptedException e) {
    Thread.currentThread().interrupt();
    return;
}

blocking 메서드는 대부분 InterruptedException 을 던진다. 무시하면 스레드 종료 신호가 사라져 graceful shutdown 이 불가능해진다.

참고

[[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

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 을 받아들이는 게 좋다.

김신건의 로그 - 위키 / concurrency

Pub/Sub Bus

정의

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

해결책: Pub/Sub Bus

동작 패턴

Channel 기반

Pattern 기반 (와일드카드)

Topic 기반 (계층화)

Socket.IO + Redis Adapter 패턴

Redis Pub/Sub vs Redis Streams

Pub/Sub vs Message Queue (차이점)

Kafka: Pub/Sub 과 Consumer Group

순서 보장

부하 특성

사용 시나리오

1. WebSocket 클러스터

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

3. 실시간 알림 시스템

4. Cache invalidation

함정

대안과 trade-off

gRPC streaming + 서비스 디스커버리

Service mesh (Istio 등)

Database notification

관련 위키

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

정의

왜 필요?

연결 생명주기

흐름

주요 파라미터

Pool 크기 계산

Little’s Law

DB Connection Pool 구조

HTTP Connection Pool

HikariCP 설정 (Java)

PgBouncer 설정

Python SQLAlchemy 풀 설정

모니터링 지표

gRPC 연결 풀

흔한 함정

HikariCP / 표준 라이브러리

관련 위키

[Concurrency] Retry + Exponential Backoff + Jitter

정의

4가지 전략

Exponential

Exponential + Full Jitter

Decorrelated Jitter

재시도 상태 머신

비교 시뮬레이션

Retry 가능한 에러만 retry

Idempotency 와 짝

상한 설정

Deadline 전파

구현 예시

Python: tenacity

Java: Resilience4j

Go: backoff 라이브러리

Hedged Requests

Retry-After 헤더

SDK / Library

Retry Budget

흔한 함정

관련 위키

Stateful

정의

핵심 특성

수평 확장 시각화

Sticky Session 구성

WebSocket 클러스터 (Pub/Sub 버스)

어디에 상태가 사는가

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

2. 활성 연결 자체

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

Stateful 서버의 수평 확장

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

해결책 1: [[Sticky Session]]

해결책 2: 외부 세션 store