API 호출 시 매번 새로운 연결을 생성하면 평균 응답 시간이 수백 밀리초씩 늘어납니다. 솔직히 "연결 하나 만드는 게 뭐가 그리 오래 걸리겠어"라고 생각했는데, 실제 프로덕션 환경에서 측정해보니 생각보다 큰 차이가 났습니다. 특히 내부 서비스 간 통신이 빈번한 구조에서는 연결 생성 비용이 전체 성능에 직접적인 영향을 미칩니다. 그래서 많은 개발팀이 Connection Reuse 전략을 도입하는데, 문제는 이게 성능만 좋아지고 끝나는 게 아니라는 점입니다.
성능개선 효과는 확실합니다
네트워크 연결을 새로 만드는 과정에는 TCP 핸드셰이크라는 단계가 필요합니다. 클라이언트와 서버가 SYN, SYN-ACK, ACK 패킷을 주고받으며 연결을 수립하는 과정인데, 이게 보통 수십에서 수백 밀리초 정도 소요됩니다. HTTPS를 사용한다면 여기에 TLS 핸드셰이크 시간까지 추가됩니다. 매 요청마다 이 과정을 반복하면 당연히 전체 응답 시간이 느려질 수밖에 없습니다.
HTTP Keep-Alive 방식의 Connection Reuse를 적용하면 이미 생성된 연결을 그대로 사용하기 때문에 핸드셰이크 과정을 건너뛸 수 있습니다. 필자가 운영했던 프로젝트에서는 이 방식을 도입한 후 평균 응답 시간이 약 30% 정도 단축됐습니다. 특히 짧은 간격으로 여러 번 API를 호출하는 구조에서는 효과가 더 두드러졌습니다. 연결 생성 오버헤드가 사라지니 네트워크 지연도 줄어들고, 전체적인 처리량(Throughput)도 개선됐습니다.
다만 이건 클라이언트 측면에서만 본 결과입니다. 서버 입장에서는 상황이 조금 다릅니다.
리소스관리 측면의 새로운 과제
연결을 재사용한다는 건 곧 연결을 오래 유지한다는 뜻입니다. 클라이언트 수가 적을 때는 문제가 안 되지만, 동시 접속자가 많아지면 서버가 관리해야 할 연결 수가 급격히 증가합니다. 각 연결마다 메모리와 파일 디스크립터 같은 시스템 자원이 할당되는데, 이게 쌓이면 서버 리소스가 빠르게 소진됩니다.
경험상 가장 골치 아팠던 건 Idle 연결 관리 문제였습니다. 클라이언트가 요청을 보낸 후 한동안 추가 요청이 없어도 연결은 살아 있습니다. 이런 연결들이 쌓이면 사용되지 않는데 서버 자원만 점유하는 상황이 발생합니다. 실제로 운영 중인 서버를 모니터링해보니 전체 연결의 60% 이상이 10분 넘게 아무 활동이 없는 상태였습니다. 이 연결들이 자원을 묶어두고 있으니 신규 요청 처리 여력이 줄어들 수밖에 없었습니다.
또 다른 문제는 연결 수 제한입니다. 운영체제마다 프로세스당 열 수 있는 최대 파일 디스크립터 수가 정해져 있습니다. 리눅스 기본값이 보통 1024개 정도인데, Keep-Alive로 연결을 오래 유지하다 보면 이 한계에 쉽게 도달합니다. 그러면 새로운 연결 요청을 받아들일 수 없게 되고, 결국 서비스 장애로 이어집니다.
- Idle Timeout 설정: 일정 시간 동안 사용되지 않는 연결은 자동으로 종료하도록 설정합니다. 보통 30초에서 2분 사이 값을 사용합니다.
- 최대 연결 수 제한: 서버가 동시에 유지할 수 있는 연결 개수에 상한선을 두어 리소스 고갈을 방지합니다.
- 연결 풀(Connection Pool) 크기 조정: 클라이언트 측에서도 연결 풀 크기를 적절히 설정해 불필요하게 많은 연결을 생성하지 않도록 합니다.
Keep-Alive 정책과 모니터링이 핵심입니다
Connection Reuse 전략을 제대로 활용하려면 단순히 Keep-Alive만 켜놓으면 안 됩니다. Idle Timeout과 최대 연결 수 같은 정책을 함께 설정해야 안정적으로 운영할 수 있습니다. 실제 적용했던 설정을 예로 들면, Nginx에서 keepalive_timeout을 60초로, keepalive_requests를 100으로 설정했습니다. 이렇게 하면 하나의 연결이 최대 60초 동안 유지되거나 100개 요청을 처리하면 자동으로 종료됩니다.
클라이언트 쪽에서도 연결 풀 관리가 중요합니다. Java의 HttpClient나 Python의 requests 라이브러리를 쓸 때 연결 풀 크기를 명시적으로 설정하지 않으면 기본값이 너무 작거나 클 수 있습니다. 제 경우엔 내부 서비스 호출용 클라이언트의 연결 풀을 50개로 제한했고, 각 연결의 최대 유지 시간을 5분으로 설정했습니다. 이 값들은 서비스 특성에 따라 달라질 수 있으니 부하 테스트를 통해 최적값을 찾아야 합니다.
모니터링도 빼놓을 수 없습니다. 서버의 활성 연결 수, Idle 연결 비율, 연결 생성/종료 빈도 같은 지표를 지속적으로 추적해야 합니다. 연결 수가 계속 증가하는 패턴이 보이면 Timeout 설정을 조정하거나 연결 풀 크기를 재검토해야 합니다. 처음 설정한 값으로 며칠 운영하다가 연결 누수 패턴을 발견하고 Timeout을 절반으로 줄인 적이 있습니다.
서비스 아키텍처에 따라서는 로드밸런서(Load Balancer) 레벨에서 연결 관리 정책을 적용하는 것도 효과적입니다. AWS ELB나 Nginx 같은 도구들은 자체적으로 Keep-Alive와 연결 풀 관리 기능을 제공하기 때문에, 애플리케이션 코드를 수정하지 않고도 정책을 적용할 수 있습니다.
결국 Connection Reuse는 성능 개선과 리소스 관리라는 두 가지 측면을 모두 고려해야 하는 전략입니다. 연결을 재사용하면 확실히 응답 속도가 빨라지지만, 그만큼 서버 자원을 오래 점유하게 됩니다. 이 균형을 맞추려면 적절한 Timeout 정책과 연결 수 제한, 그리고 지속적인 모니터링이 필수입니다. 이 세 가지를 함께 운영했을 때 성능 개선 효과를 유지하면서도 안정적인 서비스 운영이 가능했습니다. 지금 API 성능 문제로 고민 중이라면, 먼저 현재 연결 관리 방식을 점검해보시길 권합니다.
댓글
댓글 쓰기