Project/Partnerd

[Partnerd] API 요청 시 초기연결이 1분이상 지연되는 현상 해결

작소율 2025. 4. 7. 21:23

 

 

성능 개선을 한 후 API 를 요청했을 때, 서버 응답은 확연히 빨라졌으나 ( prometheus 와 grafana 를 통해 해당 요청 응답시간을 봐도 빨라진 걸 알 수 있었다.) 초기 연결에서 평균 1.3분이 걸리는 이상한 현상이 발생했다.

 

 

서버측의 연결풀 부족으로 인한 것인가 해서, HikariCP 대시보드를 확인해보았지만 

 

  • Pending: 0
    → 커넥션을 기다리는 요청도 없음 (병목 없음)
  • Connection Timeout Count: 0
    → 커넥션 획득에 실패한 적도 없음
  • Connection Acquire Time: 7~13ms 수준
    → 커넥션 획득 속도도 매우 양호함
  • Usage Time: 1.2초 이하
    → 사용 시간도 짧은 편

위 이유로 DB 커넥션 풀은 병목 원인이 아닌 것을 알 수 있었다.

 

그럼 CPU 사용량이 너무 높아서 커넥션 수립조차 하지 못하는가? 하면 CPU 사용량은 API 요청 시, 40퍼센트 이하로 문제가 없었기 때문에 해당 원인 또한 아니였다.

 

 

그렇다고 스프링 부트 애플리케이션내에 스레드 병목이 있는가 하면? 그것도 아니였다.

애꿎은 리액트 코드만 계속 수정해도 브라우저에 캐시가 남아있지 않을 때 초기연결은 계속해서 1.3분 이상이 걸렸다. 

 

서버 내부의 문제는 아니였고, 코드에 문제도 아니였다. 그럼 네트워크에서 문제가 생겨 병목이 생긴다는 건데...

도저히 감이 잡히질 않았다. 네트워크 흐름을 보면, 일단 Route53 에서 API 요청 도메인의 A레코드를 ALB 로 설정해주었다. 

그런다음 ALB 에서 서로 다른 가용 영역의 서브넷을 설정해주었다. 그리고 ALB 의 대상그룹을 애플리케이션이 배포되어있는 EC2 로 설정해둔 상태였다.

 

위 상황에서 curl -v https://api.your-domain.com/health 요청을 보냈는데 

 

 

첫 번째 IP 52.78.237.9 로의 연결이 Connection Timeout 발생 하는 것을 볼 수 있었다.

이후, 다른 ALB IP (52.78.133.206)로 fallback 연결 성공 하였다.

 

아차 싶어 ALB 서브넷들의 라우팅 테이블을 보니 첫번째 IP 에 해당하는 서브넷의 라우팅 테이블에 인터넷 게이트 웨이가 연결되어 있지 않았다.. 라우팅 테이블에 인터넷 게이트를 설정해주니 다시 curl 요청을 보냈을 때, 로드밸런서의 라운드 로빈 방식으로 요청이 잘 가는 것을 확인할 수 있었다. 

 

이후에 다시 요청을 보내보니 네트워크 초기 연결 병목 없이 서버 응답을 받아 올 수 있었다.

 

 


 

ALB 대상 그룹의 상태가 모두 healthy로 표시되어 있었고, 컨테이너도 살아 있어서 처음에는 네트워크 지연의 원인이 애플리케이션 성능이나 R2DBC 커넥션 풀, 쓰레드풀 등의 내부 문제일 거라고 판단했다.

하지만 실제 문제는 ALB의 가용영역 설정과 서브넷 구성, 그리고 해당 서브넷의 IGW 연결 여부와 같이 VPC 네트워크 인프라의 설정 미비였다.

ALB가 여러 가용영역에 퍼블릭 IP를 부여해 로드밸런싱을 수행한다는 구조적 특성을 이해하지 못한 것이 병목의 원인을 놓친 결정적인 이유였던 것 같다. 

또한, 단순한 curl 명령을 통해 실제 어느 IP로 연결되는지, 연결 타임아웃이 발생하는지를 확인해보는 기초적인 네트워크 디버깅 절차를 처음부터 시도하지 않았던 것도 큰 실수였다.

 

이번 이슈를 통해 알게 된 점 정리:

  1. ALB는 가용영역을 2개 이상 설정해야 하고, 각 서브넷은 IGW 연결이 반드시 되어 있어야 한다.
  2. ALB는 각 서브넷에 네트워크 인터페이스(ENI)를 생성하고, 퍼블릭 IP를 할당받는다.
  3. 사용자의 요청은 라운드로빈 방식으로 각 퍼블릭 IP(=ALB ENI)에 분산되며, 해당 서브넷의 네트워크가 미완성일 경우 응답 지연이 발생한다.
  4. Target Group의 상태가 healthy하더라도, 서브넷 레벨에서의 네트워크 장애는 감지되지 않을 수 있다.
  5. curl 등 로우 레벨 테스트 도구를 이용한 진단은 문제 원인을 빠르게 좁히는 핵심 수단이다.