-
[Cloud NAT][운영] mixed gateway 비교 뒤에도 port_usage가 비슷할 때 destination fan-out persistence를 어떤 표로 먼저 남기나기타개발지식/풀스택개발 2026. 7. 21. 20:15
IT 리서치 노트
[Cloud NAT][운영] mixed gateway 비교 뒤에도 port_usage가 비슷할 때 destination fan-out persistence를 어떤 표로 먼저 남기나
Cloud NAT에서 mixed gateway 비교까지 했는데도 `port_usage`가 비슷해서 원인이 안 좁혀질 때가 있다. 2026년 7월 21일 기준 Google Cloud 공식 문서를 다시 보면 Public NAT의 Endpoint-Independent Mapping은 같은 내부 IP·포트 쌍이 여러 destination으로 나갈 때도 같은 NAT source tuple을 계속 재사용할 수 있고, 특정 destination 3-tuple에 연결이 몰리면 conflict 가능성이 커질 수 있다. 이 글은 mixed gateway 비교 뒤에도 port_usage가 비슷할 때 destination fan-out persistence를 어떤 표로 먼저 남기는 편이 빠른지 정리한 것이다.
1. 개요
결론부터 말하면 이 단계에서는 총량보다 분포를 남겨야 한다. port_usage가 비슷해도 destination 3-tuple 집중도와 shared source tuple persistence가 다르면 first-request latency나 intermittent drops는 충분히 달라질 수 있다.
그래서 mixed gateway 비교 뒤 다음 표에는 gateway generation, 상위 destination 3-tuple 비율, shared source tuple 흔적, first-request latency, conflict reason 유무를 같이 적는 편이 좋다. TIME_WAIT 축만으로는 남은 지연을 설명하지 못할 수 있다.
2. 어디서 실제로 막히는가
이 상태에서 흔한 실수는 세 가지다. 첫째, port_usage가 비슷하면 NAT 쪽 차이는 없다고 단정한다. 둘째, TIME_WAIT과 gateway generation만 계속 본다. 셋째, destination 분포를 안 남겨서 나중에 왜 특정 시간대에만 first-request latency가 올랐는지 설명하지 못한다.
Public NAT 문서는 Endpoint-Independent Mapping 아래에서 같은 내부 source tuple이 여러 destination으로 가도 같은 NAT source tuple을 재사용할 수 있다고 설명한다. 또 destination 3-tuple이 한쪽으로 몰릴수록 conflict 가능성이 커질 수 있다고 직접 적고 있다. 즉 총 port_usage만 비슷해도 분포가 다르면 체감 성능은 다를 수 있다.
- 증상: gateway A와 B의 port_usage는 비슷한데 burst 뒤 first-request latency가 다르다.
- 실패: 총량 지표만 보고 destination 분포는 기록하지 않는다.
- 막힘: conflict reason이 0이면 NAT는 문제 없다고 결론낸다.
- 누락: destination 3-tuple 집중도와 shared source tuple 흔적을 안 남긴다.
질문 먼저 볼 축 이유 왜 한쪽만 느린가 destination 3-tuple 집중도 같은 총량이라도 분포가 다를 수 있다 NAT source tuple 재사용이 문제인가 shared source tuple 흔적 EIM persistence를 직접 봐야 한다 실패 신호가 있나 ENDPOINT_INDEPENDENCE_CONFLICT, latency drops가 없어도 latency 분화가 남을 수 있다 3. 실무에서 적용하는 순서
가장 실용적인 순서는 네 단계다. 먼저 mixed gateway 각각의 generation과 TIME_WAIT 상태를 적는다. 두 번째로 상위 destination 3-tuple 비율을 남긴다. 세 번째로 shared NAT source tuple 재사용 흔적과 first-request latency를 같은 시간축에 붙인다. 마지막으로 conflict reason 유무와 dynamic port allocation 설정을 함께 적는다.
- gateway generation과 TIME_WAIT 상태를 적는다.
- 상위 destination 3-tuple 집중도를 기록한다.
- shared source tuple 흔적과 first-request latency를 같은 축에 놓는다.
- conflict reason과 dynamic port allocation 상태를 같이 적는다.
- Google Cloud 콘솔을 연다.
- Cloud NAT 메뉴를 클릭한다.
- 비교할 gateway를 각각 클릭한다.
- 설정 화면에서 generation, TIME_WAIT, dynamic port allocation 값을 확인한다.
- Monitoring에서 port_usage와 dropped packets 로그를 조회한다.
- 로그 또는 추적 파일에서 destination 3-tuple 상위 분포를 저장한다.
- 같은 시간축에 first-request latency 결과를 저장한다.
- 두 gateway의 표를 나란히 비교한다.
가능하면 같은 runbook에 명령과 콘솔 경로를 같이 남긴다. 어떤 메뉴를 클릭했는지, 어떤 설정 값을 확인했는지, 어떤 로그를 조회했는지, 어떤 결과 파일을 저장했는지 적어 두면 다음 비교가 빨라진다. 운영자가 바뀌어도 같은 콘솔 경로와 같은 명령으로 다시 실행할 수 있어야 한다.
예를 들어 콘솔에서 값을 확인한 뒤 로그를 복사해 파일로 저장하고, 같은 시각의 latency 결과를 조회해 붙이면 된다. 이 기록이 있어야 port_usage는 비슷한데 destination fan-out persistence만 다른 상황을 재현할 수 있다.
핵심은 '총량이 비슷하다'를 결론으로 두지 않는 것이다. destination fan-out persistence 표가 있으면 이후에 conflict가 실제로 생겼을 때도 이전 latency 구간과 자연스럽게 이어 붙일 수 있다.
gateway=A(existing), B(new) port_usage_p95=A:0.71, B:0.69 top_destination_3tuple_share=A:0.62, B:0.28 shared_source_tuple_seen=A:true, B:false first_request_latency_p95_ms=A:420, B:180 endpoint_independence_conflict=A:0, B:0이미 packet drop과 NAT allocation errors 시간축 글, min/max ports와 dynamic allocation timeout 글을 읽었다면, 이번 글은 그 다음으로 traffic shape를 기록하는 분기라고 보면 된다.
4. 공식 문서와 예시 화면으로 확인하기
첫 화면은 destination fan-out persistence의 출발점이다. Public NAT 문서는 같은 내부 IP와 포트 쌍이 여러 destination으로 나가도 같은 NAT source tuple을 사용할 수 있다고 설명한다.
즉 port_usage가 비슷해도 어떤 destination 3-tuple로 퍼졌는지에 따라 체감 지연과 충돌 가능성은 달라질 수 있다. 단순 총량만 봐서는 이유를 못 찾는다.
두 번째 자료는 언제 conflict 가능성이 커지는지 짚는다. Google Cloud는 같은 destination 3-tuple에 연결이 몰리고 내부 source IP와 port 조합이 많을수록 충돌 가능성이 커진다고 적고 있다.
그래서 mixed gateway 비교 뒤에도 port_usage가 비슷하다면 다음 질문은 destination 분포다. 어느 VM이 어떤 destination 3-tuple에 얼마나 몰렸는지 기록해야 실제 persistence 차이를 읽을 수 있다.
세 번째 자료는 증상 쪽 근거다. troubleshooting 문서는 Endpoint-Independent Mapping이 켜진 Public NAT에서 packet loss가 있을 때 `ENDPOINT_INDEPENDENCE_CONFLICT` reason을 보라고 안내한다.
하지만 오늘 문제는 drops가 많지 않을 때도 있다. 이 경우에도 같은 reason을 기다리기보다 destination fan-out persistence 표를 먼저 남겨 두면, later conflict와 first-request latency를 한 축에 묶을 수 있다.
mixed gateway 비교 다음 단계에서는 총량 대신 분포를 적는 표가 필요하다. gateway 세대, destination 3-tuple 수, shared source tuple 비율, first-request latency를 같은 줄에 넣어야 이유가 드러난다.
이미 mixed gateway TIME_WAIT 비교 글이 rollout 축을 정리했다면, 이번 표는 그 다음으로 '그래서 실제 트래픽 분포는 어떻게 달랐나'를 남기는 후속편이다.
마지막 자료는 실제 로그 스키마 예시다. port_usage가 비슷하다는 사실만 남기지 말고 destination fan-out과 source tuple persistence를 같이 적어야 다음 회고가 된다.
이 구조가 있으면 port_usage만 치솟을 때의 글과 override 제거 뒤 추가 지연 글을 같은 타임라인에 연결하기 쉬워진다.
5. 주의사항과 리스크
첫 번째 리스크는 port_usage만 비슷하면 NAT가 무관하다고 보는 것이다. 두 번째는 conflict reason이 0이면 destination fan-out까지 볼 필요가 없다고 판단하는 것이다. 세 번째는 gateway generation과 TIME_WAIT 축만 남기고 분포 데이터는 빠뜨리는 것이다.
운영 메모에는 destination 3-tuple 집중도와 shared source tuple 흔적을 남겨 두는 편이 좋다. 그래야 mixed gateway rollout 글과 override 제거 뒤 지연 글의 빈칸을 메울 수 있다.
6. 결론
mixed gateway 비교 뒤에도 port_usage가 비슷하다면 이제 총량보다 destination fan-out persistence를 봐야 한다. destination 3-tuple 집중도, shared source tuple 흔적, first-request latency를 한 표에 남기면 남은 지연이 왜 생기는지 더 빨리 좁혀진다.
같은 가지의 선행 글로는 port_usage와 앱 동시성 글, mixed gateway TIME_WAIT 글, override 제거 뒤 추가 지연 글을 같이 보면 좋다.
오늘 기준 후속으로는 shared source tuple reuse와 first-request latency를 어떤 임계값으로 경고할지 정리한 글도 같이 보면 좋다. 이 글이 fan-out persistence 기록 형식을 먼저 잡아 줬다면, 후속 글은 어떤 수치 변화부터 경고로 분류할지까지 이어 준다.
7. 참고 링크
'기타개발지식 > 풀스택개발' 카테고리의 다른 글
