아웃바운드 요청이 늘자 일부 연결이 실패하지만 앱의 FD는 여유가 있습니다. NAT 포트 고갈은 어떻게 확인하나요?

클라이언트의 FD와 NAT 장치의 변환 주소·포트·상태 테이블은 별도 자원입니다. 여러 인스턴스가 같은 공인 주소를 공유하면 로컬 자원이 남아도 NAT에서 새 연결을 만들지 못할 수 있습니다.

동작 원리와 전제

목적지별 연결 생성률·동시 연결·TIME_WAIT 유사 상태 보존·NAT 할당 실패 지표를 확인합니다. 사용 가능한 포트 수는 목적지 분포와 매핑 규칙에 따라 달라지므로 공인 IP 하나당 단순 고정 연결 수로 일반화하지 않습니다.

선택과 실패 처리

연결 재사용·HTTP/2 다중화·불필요한 짧은 연결 제거가 먼저 도움이 될 수 있습니다. 공인 주소와 NAT 용량을 늘리는 대안도 있지만 비용·라우팅·고가용성을 봅니다. 요청 재시도가 고갈을 더 증폭하지 않게 전체 동시성을 제한합니다.

구체적인 사례와 검증

수백 Pod가 같은 NAT 주소로 단일 외부 API에 짧은 연결을 계속 만들면 연결 유지·종료 상태가 NAT 자원을 소모할 수 있습니다. 각 Pod의 FD만 보면 여유가 있어 원인을 놓칩니다. 연결 재사용률과 목적지별 생성률을 보고 NAT의 할당 실패·활성 연결 지표와 연결합니다. 재시도가 매번 새 연결을 만들면 장애가 더 오래 지속될 수 있습니다. HTTP/2로 줄일 수 있는 연결 수와 스트림 한도, 원격 서버가 허용하는 유휴 시간을 함께 조정합니다. NAT 증설을 택하더라도 장애 영역·라우팅·비용과 보안 정책을 유지하는지 확인하겠습니다.

단일 목적지 집중과 분산 목적지, 유휴 연결, 짧은 burst를 나눠 시험합니다. 로컬 소켓 오류·NAT 로그·서버 수신 여부를 대조합니다. 앱에서 관측한 timeout만으로 원격 서버 장애라고 단정하지 않겠습니다.