Admission Control이란? 서버가 요청을 받기 전에 처리 가능한지 먼저 판단하는 방법 쉽게 이해하기
Admission Control은 요청을 처리하기 전에 Capacity를 확인해 감당할 요청만 받아들이는 과부하 제어입니다. Load Shedding·Rate Limit·Waiting Room·Bulkhead까지 초보 기준으로 정리합니다.
놀이공원 입구처럼 입장을 먼저 제어하기
동시에 1,000개까지 안정적인데 이미 1,000개를 처리 중이면, 새 요청을 무조건 받으면 Queue·메모리·Timeout이 불어납니다. Admission Control(어드미션 컨트롤)은 놀이공원 입장 제한처럼 — 처리 시작 전에 「지금 여유가 있는가?」를 보고 감당할 요청만 안으로 들이는 방식입니다. Worker·DB·외부 API까지 들어간 뒤 실패하는 것보다 입구에서 Fail Fast로 거절하는 편이 자원과 사용자 대기 모두에 유리합니다.
요청 도착 → Capacity 확인 여유 있음 → 입장 · 없음 → 대기/거절
Load Shedding · Rate Limit · Bulkhead와 구분
Load Shedding은 「이미 넘치는 부하를 덜어내기」, Admission은 「애초에 받을지 입구에서 판단」에 가깝습니다 — 구현에서는 겹칠 수 있습니다. Rate Limit은 「초당 N개」 공정성·남용 방지이고, Admission은 「지금 서버 Capacity」입니다. Rate는 남았는데 전체가 포화면 Admission Denied가 될 수 있습니다. Bulkhead로 결제 30·추천 10을 나눈 뒤, 각 Pool에 슬롯이 있는지 Admission으로 확인합니다. Semaphore·Concurrency Limit·Bounded Queue가 흔한 구현 도구입니다.
Rate Limit = 단위 시간당 한도 Admission = 현재 Capacity로 입장 여부 실행 100 + Queue 200 가득 → 301번째 Denied
비용 · 우선순위 · Deadline · Waiting Room
요청 비용이 다르면 Weighted Admission(조회 Cost 1, AI Cost 100)으로 Budget을 나눕니다. 부하가 높아질수록 추천·통계부터 막고 결제를 살립니다. Queue 예상 대기가 Deadline을 넘기면 애초에 받지 않는 Deadline-aware 판단도 가능합니다. 티켓 오픈처럼 대기를 감수할 수 있으면 Waiting Room으로 입장 속도를 조절하고, API는 즉시 거절이 더 맞는 경우가 많습니다. 응답은 계약에 맞게 HTTP 상태·사용자별이면 429·전체 Capacity면 503, Retry-After와 Backoff+Jitter를 맞춥니다.
핵심 High · 부가 Low Deadline 초과 확실 → 입장 거부 Waiting Room = 입장 속도 제어
병목 · Adaptive · 운영
앱 CPU가 남아도 DB Connection·외부 결제 API가 병목이면 그 기준으로 입장을 겁니다. Edge Rate Limit → Gateway 전체 제한 → App Worker → DB Pool처럼 계층마다 보호 대상이 다릅니다. Limit가 너무 낮으면 낭비가 나고 너무 높으면 사실상 무제한이니 부하 테스트로 포화 지점을 잡고 Headroom을 남깁니다. 오토스케일이 새 인스턴스를 준비하는 동안 Admission이 기존 서버를 보호합니다. Adaptive로 동시성을 자동 조절할 때 Oscillation을 줄이려면 Hysteresis가 필요하고, Circuit Breaker Flapping과 비슷한 함정입니다. Denied 비율·기능별 거절을 모니터링하고 로드밸런서·Gateway 앞단과도 맞춥니다.
실제 병목 자원 기준 Scale Out 준비 중 → Admission 보호 Limit 민감 → Oscillation · Hysteresis
자주 묻는 질문
Admission Control이란?
새 요청을 처리 시작 전에 Capacity로 판단해 수용 가능한 것만 안으로 들이는 과부하 제어입니다.
Load Shedding과 차이는?
Admission은 입장 전 판단, Shedding은 과부하를 줄이기 위해 부하를 제거하는 쪽에 가깝습니다. Load Shedding 가이드를 참고하세요.
Rate Limit과 같나?
아닙니다. Rate는 시간당 횟수, Admission은 현재 시스템 Capacity입니다.
Waiting Room도?
네. 한꺼번에 모두 넣지 않고 일정 인원만 순차 입장시키는 대표 사례입니다.
오토스케일을 대체하나?
아닙니다. Scale은 Capacity를 늘리고 Admission은 현재 Capacity를 넘지 않게 막습니다.
핵심 요청만 살릴 수 있나?
가능합니다. Priority·Weighted Cost로 결제·주문을 우선 수용할 수 있습니다.
정리
Admission Control = 처리 시작 전에 Capacity를 보고 받을 요청만 입장시키는 제어입니다. Load Shedding이 「넘친 부하를 덜어내기」라면 Admission은 「감당할 만큼만 안으로」입니다. Concurrency·Bounded Queue·Semaphore·Priority·Deadline·Waiting Room으로 구현할 수 있습니다. 그런데 입장 시점에는 여유가 있어도, 처리 중 DB·외부 API가 느려지면 같은 트래픽에서도 서버 안 요청 수가 불어 다시 포화될 수 있습니다. 응답이 빨라지면 동시량을 늘리고 느려지면 줄이는 방식이 Adaptive Concurrency Control(적응형 동시성 제어)입니다.