외부 HTTP 호출에서 연결 풀 대기가 늘었습니다. 연결 수를 늘려도 되는 경우와 오히려 줄여야 하는 경우는 어떻게 구분하나요?

연결 풀 대기가 길다는 사실만으로 연결 수를 늘리지는 않겠습니다. 연결을 얻은 뒤 요청 자체는 빠르고 하위 서버의 CPU·연결·큐에 여유가 있다면 풀 상한을 조금씩 늘릴 수 있지만, 하위 응답 시간과 오류율도 함께 늘었다면 연결 증설은 포화를 악화시킵니다. 먼저 풀 대기 시간, 연결 후 응답 시간, 새 연결 생성률을 분리해 원인을 확인하겠습니다.

풀 대기와 하위 지연을 분리한다

연결 풀은 TCP·TLS 핸드셰이크 비용을 줄이기 위해 유휴 연결을 보관하고 재사용합니다. 요청은 풀 슬롯을 기다리고, 슬롯을 얻은 뒤 소켓에서 응답을 기다리며, 연결이 없으면 새 연결을 만듭니다. 이 구간을 하나의 HTTP 호출 시간으로만 기록하면 클라이언트의 풀 제한과 상대 서버의 처리 지연을 구분할 수 없습니다. 이를 자원 대기 시간 분해(wait-time decomposition)로 보고 p50뿐 아니라 p95·p99를 측정합니다.

풀 대기는 길지만 연결 후 요청 시간이 짧고 하위 서비스의 처리량과 연결 한도가 남아 있다면 상한을 단계적으로 올리겠습니다. 반대로 연결 후 지연, 상대의 5xx, 로컬 송신 큐가 함께 증가하면 연결을 줄이고 대기열 상한·타임아웃·백프레셔로 전체 부하를 제한하는 편이 낫습니다. 인스턴스당 100개는 인스턴스가 20개면 하위 서비스에 최대 2,000개의 연결을 만들 수 있으므로 전역 예산으로 환산해야 합니다.

HTTP 버전과 연결 수명

HTTP/1.1에서는 대체로 연결 하나의 동시 요청 수와 풀 슬롯이 가까이 움직이지만, HTTP/2에서는 한 TCP 연결의 여러 스트림이 동시에 진행되므로 연결 수와 요청 동시성은 다릅니다. HTTP/2의 최대 스트림 수, 서버의 스트림 큐, TLS·커널 버퍼를 함께 봅니다. 연결을 무한히 유지하면 로드밸런서·NAT·상대 서버가 먼저 끊은 유휴 연결을 재사용할 수 있습니다. 유휴 수명과 최대 연결 수명을 두되, 모두 같은 시각에 만료하지 않도록 분산합니다.

재사용이 실패한 요청은 새 연결로 한 번 재시도할 수 있지만, 서버가 이미 상태를 변경했을 가능성이 있는 POST를 무조건 재전송하면 중복 작업이 됩니다. 연결 획득 timeout은 전체 요청 deadline 안에 포함시키고, 대기만 하다 deadline을 소진한 요청은 새 연결을 만들지 않게 합니다. 하위 서버 교체, 유휴 후 재사용, 연결 폭증을 부하 테스트하고 풀 대기·새 연결률·소켓 오류·하위 처리량으로 상한을 정하겠습니다. 목표는 가장 많은 연결이 아니라 전체 시스템이 안정적으로 처리할 수 있는 동시성입니다.

연결 풀의 적정치는 단일 클라이언트의 최적값이 아니라 하위 서비스가 감당할 수 있는 전체 동시성에서 역산해야 합니다. 인스턴스가 자동 확장되면 인스턴스당 상한을 고정해도 총 연결 수가 갑자기 늘 수 있으므로 배포 규모별 최악값을 계산합니다. HTTP/2에서는 연결 하나의 스트림 한도에 막혀 풀 대기가 보일 수 있고, 연결을 늘리면 TLS·메모리·혼잡 창이 새로 생깁니다. 따라서 연결 증설 전에는 하위 서버의 active request, queue, reject, CPU를 함께 확인해 병목이 풀인지 상대인지 판정하겠습니다.

풀 상한을 바꿀 때는 연결 획득 timeout이 요청 deadline을 잠식하는지도 봅니다. 대기 중인 요청을 무제한으로 보관하면 풀을 늘리지 않아도 메모리와 사용자 지연이 커지므로, 대기열 상한을 넘으면 빠르게 실패시키거나 호출자가 재시도할 수 있는 오류로 명시하겠습니다. 이렇게 해야 풀 설정이 숨은 무제한 큐가 되지 않습니다.