Adaptive Concurrency Control이란? 서버 상태에 따라 동시 요청 수를 자동으로 조절하는 방법 쉽게 이해하기
Adaptive Concurrency Control은 Latency를 보며 동시에 처리할 요청 수를 자동으로 늘리거나 줄이는 동시성 제어입니다. AIMD·Bulkhead·Admission Control·오토스케일까지 초보 기준으로 정리합니다.
서버가 동시에 몇 개의 요청을 처리해야 가장 효율적일까요? 「많이 처리할수록 더 빠르다」고 생각하기 쉽지만, 실제로는 어느 수준을 넘으면 Queue·DB Connection 경쟁·Timeout이 늘며 전체가 나빠질 수 있습니다. 게다가 적절한 동시 요청 수는 항상 고정이 아닙니다. DB가 빠른 날과 외부 API가 느린 순간이 다릅니다. 그래서 상태를 관찰하며 동시 처리량을 자동으로 조절하는 방법이 Adaptive Concurrency Control(어댑티브 컨커런시 컨트롤, 적응형 동시성 제어)입니다.
응답이 빠르면 → 동시 요청 수 조금 증가 응답이 느려지면 → 동시 요청 수 감소 → 적절한 처리량을 자동으로 찾아감
마트 계산대 입장 관리 비유
계산대 직원 5명에게 고객 10~20명은 괜찮지만 100명이 한꺼번에 들어오면 혼잡해져 전체 처리가 느려집니다. 대기줄이 짧으면 입장을 조금 늘리고, 길어지면 줄이는 식입니다. Adaptive Concurrency도 같습니다.
Concurrency와 Limit
Concurrency는 같은 시간대에 함께 진행 중인 요청 수입니다. Concurrency Limit는 그 최대값입니다. 101번째 요청은 Queue에서 기다리거나 즉시 실패할 수 있습니다. 고정 Limit는 서버가 한가해도·느려져도 항상 같은 값이라, 실제 환경 변화에 유연하지 않습니다.
왜 Latency가 신호가 되나
DB Query가 20ms에서 200ms로, 결제 API가 200ms에서 2초로 바뀌면 요청 하나가 시스템 안에 머무는 시간이 늘어납니다. 초당 유입이 같아도 완료가 늦어지면 Active Request가 쌓입니다. CPU만 보면 여유 있어도 DB Connection이 꽉 차 Latency가 5초일 수 있으므로, 서버 모니터링에서도 Latency·오류·Queue를 함께 봅니다.
평균만 보면 소수 매우 느린 요청이 가려질 수 있어 p95·p99를 쓰기도 합니다. 다만 Sample이 적으면 p99는 흔들릴 수 있고, 한 번의 Spike에 과민하지 않으려면 EWMA처럼 최근 추세를 부드럽게 반영합니다.
Saturation과 Headroom
부하를 늘리면 처리량이 늘다가 Saturation Point를 넘으면 Latency·오류가 급증합니다. CPU 100%로 꽉 채우면 작은 트래픽 증가에도 Queue가 폭발할 수 있어 Headroom(여유)을 남기는 편이 안전합니다. Adaptive Control도 「최대값 한 점」보다 안정 운영 범위를 찾는 것이 핵심입니다.
고정 Limit vs Adaptive Limit
고정: 항상 Concurrency = 100 Adaptive: 빠름 → 120 → 140 / 느림 → 110 → 70
밤처럼 여유가 있으면 Limit를 올리고, 배치로 DB가 느려지면 낮춰 회복 여유를 줍니다.
AIMD와 Control Loop
괜찮을 때는 조금씩 늘리고(Additive Increase), 문제가 생기면 크게 줄이는(Multiplicative Decrease) 방식이 AIMD와 비슷한 형태입니다. 급증하면 포화점을 크게 넘고, 감속을 너무 작게 하면 회복이 늦습니다. TCP 혼잡 제어와 아이디어는 비슷하지만, Adaptive Concurrency는 앱·서비스의 동시 요청 수를 조절합니다.
측정 → 판단 → 조정 → 재측정을 반복하는 Control Loop입니다. 너무 빠르면 Limit가 흔들리고(Oscillation), 너무 느리면 과부하에 늦습니다. Hysteresis(올리기/내리기 임계값 분리)·Cooldown으로 안정성을 높일 수 있습니다. Min·Max Limit·Cold Start 시 Slow Start도 안전장치입니다.
Bulkhead·Circuit Breaker·Load Shedding과 함께
상품 조회·검색·AI 생성을 하나의 Limit에 넣으면 무거운 요청이 전체를 잡아먹습니다. Bulkhead로 구역을 나눈 뒤 각각 Adaptive Limit를 두는 편이 낫습니다. 외부 API가 계속 실패하면 Circuit Breaker가 차단하고, Limit를 줄여도 Queue가 가득하면 Load Shedding으로 거절합니다. 입구에서 받을지 판단하는 Admission Control과도 한 흐름입니다.
요청 → Admission → Adaptive Concurrency → Bulkhead → 외부 서비스 문제 시 → Timeout / Retry / Circuit Breaker / Load Shedding
오토스케일링·Rate Limit과의 차이
Auto Scaling은 서버 대수를 늘리고, Adaptive Concurrency는 현재 서버가 받을 동시 요청 수를 조절합니다. 스케일이 느린 동안 기존 서버 보호에 특히 유용합니다. Rate Limit은 「초당 시작 횟수」, Adaptive Concurrency는 「현재 진행 중 개수」이며 Limit가 상태에 따라 변합니다. 처리 시간이 길면 같은 Rate에서도 Active가 폭증할 수 있어(Little’s Law 직관) Latency 기반 Concurrency 조절이 의미 있습니다.
로드밸런싱의 Least Connections와도 목적이 겹칠 수 있으나, Connection 수만으로는 Capacity를 다 알 수 없어 앱 Latency 기반 제어가 더 정확할 때가 있습니다. Warm-up 중인 새 인스턴스는 낮은 Concurrency부터 올리는 것이 안전합니다.
보호 장치 ≠ 근본 최적화
Limit 하락은 건강 신호일 수 있지만 원인은 알려주지 않습니다. 분산 추적으로 DB·외부 API를 찾고 Query를 고쳐야 합니다. Adaptive는 붕괴를 막고, 성능 최적화는 일을 빠르게 만듭니다. 부하 테스트로 Max·Initial을 잡고, 운영에서는 RUM·실제 트래픽으로 세밀 조정합니다.
언제 쓰나
API·AI·검색·외부 연동·결제처럼 처리 시간이 변하고 과부하 위험이 클 때 검토합니다. 정적 소개 페이지·동시 요청 1~5개 수준이면 고정 Limit가 더 단순합니다. SEO 전용 기술은 아니며, 과부하로 인한 장시간 지연·5xx를 줄이는 안정성 기법입니다.
자주 묻는 질문
Adaptive Concurrency Control이란?
응답 시간과 상태를 보며 동시에 처리할 요청 수를 자동으로 늘리거나 줄이는 방식입니다.
고정 Limit와 차이는?
고정은 항상 같은 값, Adaptive는 Latency·부하에 따라 Limit가 변합니다.
요청을 많이 받으면 왜 느려지나?
CPU·DB·Network는 한정되어 있어 한계를 넘으면 자원 경쟁과 Queue가 늘기 때문입니다.
Rate Limit·오토스케일과 같은가?
아닙니다. Rate는 시간당 시작 수, Adaptive는 진행 중 개수 조절, 오토스케일은 서버 대수입니다.
모든 홈페이지에 필요한가?
아닙니다. 트래픽이 적은 단순 사이트는 고정 제한으로 충분한 경우가 많습니다.
정리
Adaptive Concurrency Control = 응답이 빠르면 조금 더 받고, 느려지면 덜 받는 자동 동시성 제어입니다. 고정 Limit는 단순하지만 상태 변화에 약하고, Adaptive는 Latency·오류·Queue를 보며 Capacity를 탐색합니다. 다만 자동 제어만으로 실제 처리 한계가 사라지지는 않습니다. 어느 순간부터 요청을 더 늘려도 처리량은 거의 안 늘고 응답 시간만 폭증할 수 있는데, 용량에 가까워질수록 Queue 대기 시간이 급격히 늘어나는 현상을 이해하는 데 Queueing Theory(대기행렬 이론)이 중요합니다.