Bulkhead란? 한 기능의 장애가 다른 기능까지 번지지 않게 자원을 분리하는 방법 쉽게 이해하기
Bulkhead는 Thread·Connection·Worker를 기능별로 나눠 한 기능의 장애가 다른 기능까지 번지지 않게 하는 장애 격리 패턴입니다. Circuit Breaker·Starvation·Queue 분리까지 초보 기준으로 정리합니다.
배의 격벽처럼 자원을 나누기
결제·추천·이메일·업로드가 같은 Connection·Thread·Worker를 쓰면, 추천 API가 30초씩 기다릴 때 그 요청들이 자원을 가득 채워 결제까지 멈출 수 있습니다. Bulkhead(벌크헤드)는 배의 격벽처럼 구역을 나눠, 한 기능이 장애·과부하여도 다른 기능의 몫을 빼앗지 못하게 하는 장애 격리(Fault Isolation)입니다. 서버를 무조건 여러 대로 쪼개야 하는 것은 아니고, Pool·Queue·동시성 한도만으로도 가능합니다.
공용 Pool 100 → 추천이 전부 점유 → 결제 대기 결제 30 · 추천 20 분리 → 추천만 막혀도 결제 가능
Pool · Queue · Breaker와 함께
Connection·Thread Pool을 기능별로 나누거나, Semaphore로 「동시 최대 N개」만 허용할 수 있습니다. Queue·Worker를 결제/마케팅/이미지로 분리하면 FIFO 한 줄에 급한 작업이 묻히지 않습니다 — 한 유형이 Worker를 독점하면 Starvation이 납니다. Circuit Breaker는 「계속 실패하면 흐름을 끊음」, Bulkhead는 「애초에 쓸 수 있는 자원 범위를 제한」입니다. Timeout·Backoff와 한 세트로: Bulkhead 한도 → Timeout → 실패 누적 → Breaker Open. Rate Limit(초당 횟수)과도 다릅니다 — Bulkhead는 동시 진행량·격리에 가깝습니다.
Bulkhead = 피해 범위 제한 Circuit Breaker = 실패 지속 시 차단 Rate Limit = 단위 시간당 시작 횟수
균형 · 공통 병목 · 운영
완전 분리는 한쪽 Pool이 놀고 다른 쪽은 부족한 낭비가 생길 수 있어, 전용 최소량(Reserved Capacity)+공용 여유를 섞기도 합니다. 앱만 나눠도 DB·Redis·공용 Broker가 남으면 추천의 무거운 쿼리가 결제까지 칩니다 — Failure Domain을 통째로 봅니다. 한도가 찼을 때는 즉시 거절·짧은 대기·제한 Queue 중 고르고, 무한 Queue는 Backpressure 실패입니다. Active·Queue·Rejected를 모니터링하고, 추천에 부하를 준 뒤 결제가 사는지 테스트합니다. 서비스별 Pool은 로드밸런싱·오토스케일과도 맞물립니다. 그런데 Pool을 나눠도 서버 처리량 자체를 넘는 요청이 계속 오면 Queue만 불어 전체가 무너질 수 있습니다 — 일부 요청을 의도적으로 버려 나머지를 살리는 전략이 Load Shedding입니다.
핵심·일반·부가로 그룹 한도 초과 → 거절/짧은 대기 공유 DB·Cache도 점검
자주 묻는 질문
Bulkhead란?
한 기능이 Thread·Connection·Worker를 독점하지 못하도록 자원을 분리해 장애 확산을 줄이는 패턴입니다.
이름이 격벽인 이유는?
배 내부를 구역으로 나눠 한곳 침수가 전체로 퍼지지 않게 하는 원리에서 왔습니다.
Circuit Breaker와 차이는?
Breaker는 실패가 계속되면 요청을 끊고, Bulkhead는 쓸 수 있는 자원 상한을 나눠 다른 기능을 보호합니다. Circuit Breaker 가이드를 참고하세요.
Concurrency Limit와 같나?
관련은 있지만 Limit는 「동시에 몇 개」, Bulkhead는 「기능끼리 자원을 침범하지 못하게」에 초점이 있습니다.
완전 분리의 단점은?
한쪽 자원이 놀고 다른 쪽은 부족해질 수 있어 활용률이 떨어질 수 있습니다.
작은 사이트에도?
정보형만이면 필수는 아닙니다. 결제·대량 작업·AI·이미지처럼 성격이 다른 작업이 있으면 간단한 동시성 제한만으로도 도움이 됩니다.
정리
Bulkhead = 한 기능의 장애·과부하가 다른 기능 자원까지 빼앗지 못하도록 격리하는 설계입니다. 공용 Pool이면 추천 장애가 결제 장애로 번지고, 나누면 추천만 실패해도 결제는 살릴 수 있습니다. Breaker·Timeout·Backoff와 역할이 다르며, 공유 DB·Cache도 함께 봅니다. 그런데 자원을 나눠도 서버가 감당할 처리량을 넘는 요청이 계속 들어오면 Queue와 메모리가 불어 전체가 무너질 수 있습니다. 일부 요청을 의도적으로 버려 나머지를 보호하는 전략이 Load Shedding(로드 셰딩)입니다.