-
[Cloud NAT][운영] destination fan-out persistence를 남긴 뒤 shared source tuple reuse와 first-request latency를 어떤 임계값으로 경고하나기타개발지식/풀스택개발 2026. 7. 24. 20:16
IT 리서치 노트
[Cloud NAT][운영] destination fan-out persistence를 남긴 뒤 shared source tuple reuse와 first-request latency를 어떤 임계값으로 경고하나
Cloud NAT에서 destination fan-out persistence를 이미 남기기 시작했는데도, shared source tuple reuse와 first-request latency를 어디서 경고로 볼지 애매한 경우가 많다. 2026년 7월 24일 기준 Google Cloud 공식 문서를 다시 보면 Endpoint-Independent Mapping, TCP TIME_WAIT, dynamic port allocation, port_usage는 서로 다른 제약이다. 이 글은 destination fan-out persistence를 남긴 뒤 shared source tuple reuse와 first-request latency를 어떤 임계값으로 경고하는 편이 빠른지 정리한다.
1. 개요
결론부터 말하면 port_usage 총량만으로는 부족하다. destination 3-tuple 집중도, shared source tuple reuse 흔적, first-request latency p95를 같은 시간축에 두고, gateway가 EIM인지 dynamic port allocation인지 먼저 적어야 한다.
경고 기준도 절대값 하나보다 상대 비교가 낫다. 평소 대비 상위 destination 집중도가 급격히 오르고, 같은 burst 창에서 first-request latency가 튀며, tuple reuse 흔적이나 conflict reason이 보이면 NAT 패턴 이슈로 좁히기 쉽다.
2. 어디서 실제로 막히는가
이 단계에서 흔한 실수는 세 가지다. 첫째, port_usage가 비슷하면 NAT 차이는 없다고 단정한다. 둘째, first-request latency가 튀면 바로 min ports나 timeout부터 수정한다. 셋째, fan-out 로그와 dropped reason과 latency를 서로 다른 시간축에 두어 비교가 안 된다.
하지만 Google Cloud 문서는 Endpoint-Independent Mapping 아래에서 같은 NAT source tuple이 여러 destination 3-tuple에 재사용될 수 있다고 설명하고, troubleshooting 문서는 같은 destination 3-tuple로 빠른 TCP 재연결이 필요하면 TIME_WAIT를 같이 보라고 안내한다. 즉 fan-out, tuple reuse, latency는 서로 끊어진 값이 아니라 연결해서 봐야 하는 값이다.
또 EIM과 dynamic port allocation은 동시 사용이 안 된다. 이 사실을 안 적고 경고 숫자만 보면, 어떤 gateway는 EIM conflict를 의심해야 하고 어떤 gateway는 allocation latency를 먼저 봐야 하는데 둘을 같은 runbook으로 처리하게 된다. 그래서 경고 임계값에도 설정 축이 함께 들어가야 한다.
- 증상: port_usage는 비슷한데 burst 직후 first-request latency가 특정 시간대만 튄다.
- 실패: NAT 설정 축과 애플리케이션 destination 집중도를 같은 원인으로 뭉친다.
- 막힘: fan-out, tuple reuse, latency가 서로 다른 로그에 있어 비교가 안 된다.
- 누락: EIM enabled 여부와 dynamic port allocation 여부를 같이 적지 않는다.
보이는 현상 먼저 볼 값 질문 port_usage 비슷함 destination 3-tuple 분포 총량이 아니라 집중도 차이인가 latency 급증 TIME_WAIT, tuple reuse, burst 창 재사용 지연인가 allocation 지연인가 conflict 드롭 일부 발생 EIM 설정과 source tuple 재사용 endpoint independent conflict 축인가 3. 실무에서 적용하는 순서
가장 실용적인 순서는 다섯 단계다. 먼저 gateway generation, EIM enabled 여부, dynamic port allocation 여부를 적는다. 두 번째로 burst 창마다 상위 destination 3-tuple 비율을 저장한다. 세 번째로 shared source tuple reuse 흔적과 dropped reason을 붙인다. 네 번째로 같은 창의 first-request latency p95를 비교한다. 마지막으로 경고 기준을 넘었을 때만 min/max ports, timeout, app connection pooling 같은 조정 단계로 넘어간다.
- gateway 설정 축을 먼저 적는다.
- fan-out 분포를 burst 창 기준으로 남긴다.
- shared source tuple reuse와 dropped reason을 붙인다.
- 같은 창의 first-request latency를 비교한다.
- 경고 기준을 넘길 때만 실제 설정을 손본다.
임계값은 팀마다 다르지만, 기본 원칙은 동일하다. 상위 destination 집중도가 평소보다 크게 높고, first-request latency가 평소 대비 2배 이상 튀며, shared source tuple reuse 흔적이나
ENDPOINT_INDEPENDENCE_CONFLICT가 보인다면 NAT 패턴 경고로 분류한다. 반대로 latency만 튀고 fan-out이나 tuple reuse 흔적이 없다면 앱 또는 downstream 대기부터 본다.이때 운영자는 burst 창을 먼저 조회하고, top destination share를 저장하고, dropped reason을 확인하고, p95 변화를 비교한 뒤에만 설정 변경을 실행한다. 같은 순서로 로그를 남겨야 이후 회고에서 NAT 경고와 앱 경고를 다시 분리할 수 있다.
if top_destination_share > 0.60 and latency_p95_ms > baseline_p95_ms * 2: warn("fanout_hotspot") if dropped_reason == "ENDPOINT_INDEPENDENCE_CONFLICT": warn("eim_conflict") if latency_p95_ms high and no reuse/no fanout skew: investigate("app_or_downstream")이미 destination fan-out 로그 글, mixed gateway TIME_WAIT 비교 글을 읽었다면, 이번 글은 그 둘을 경고 정책으로 묶는 단계라고 보면 된다.
4. 공식 문서와 예시 화면으로 확인하기
첫 화면은 destination fan-out과 shared source tuple reuse가 왜 같은 문맥에 나오는지 보여 준다. Google Cloud 문서는 Endpoint-Independent Mapping 아래에서 동시에 여러 destination 3-tuple에 같은 NAT source tuple이 재사용될 수 있다고 설명한다.
즉 port_usage 총량이 비슷해도 destination 분포와 tuple 재사용 패턴은 다를 수 있다. 이번 글의 질문도 여기서 시작한다.
두 번째 자료는 first-request latency와 tuple 재사용 지연이 왜 같은 표에 들어가야 하는지 보여 준다. troubleshooting 문서는 같은 destination 3-tuple로 빠르게 TCP 연결을 반복해야 한다면 TCP TIME_WAIT를 검토하라고 적고 있다.
따라서 latency 임계값을 볼 때도 단순히 p95 지연만 적지 말고, 같은 시간대의 fan-out과 tuple reuse 흔적을 같이 남겨야 한다. 그래야 설정 문제와 앱 패턴 문제를 분리할 수 있다.
세 번째 자료는 임계값을 해석할 때 dynamic port allocation 축을 왜 따로 적어야 하는지 보여 준다. Google Cloud는 Endpoint-Independent Mapping과 dynamic port allocation을 동시에 쓸 수 없다고 명시한다.
즉 fan-out 경고를 만들 때도 gateway가 EIM인지, dynamic port allocation인지 먼저 적어야 한다. 같은 port_usage 숫자라도 의미가 다르기 때문이다.
실무에서는 무엇을 경고로 볼지 숫자 기준을 정해 두어야 한다. destination 3-tuple 집중도, shared source tuple reuse, first-request latency를 같은 표에 두면 과도한 NAT 수정과 앱 수정의 경계를 잡기 쉽다.
이미 destination fan-out persistence를 어떤 표로 남길지 정리한 글이 기록 형식을 열어 줬다면, 이번 표는 그다음 단계인 경고 기준이다.
임계값만 적으면 부족하고, 같은 시간축에 무엇을 묶을지도 정해야 한다. fan-out 로그와 latency 결과와 dropped reason을 분리하지 않으면 경고만 쌓이고 설명이 안 된다.
이 스키마가 있어야 later conflict가 실제로 났을 때 과거의 무증상 구간과 비교가 가능해진다. port_usage만 적어 두는 메모보다 훨씬 재현성이 좋다.
경고가 떴을 때 조치 순서도 짧게 고정하는 편이 좋다. 바로 NAT 값을 건드리기보다 관찰값을 먼저 분리하면 불필요한 롤백이 줄어든다.
이 순서를 쓰면 NAT 설정과 애플리케이션 connection pattern을 같은 회의에서 섞어 말하지 않게 된다. 증상과 원인 후보를 분리하는 데 도움이 된다.
5. 주의사항과 리스크
첫 번째 리스크는 NAT 값을 바꾸기 전에 관찰값을 분리하지 않는 것이다. 두 번째는 EIM gateway와 dynamic port allocation gateway를 같은 기준표로 보는 것이다. 세 번째는 first-request latency가 애플리케이션이나 downstream 원인일 수 있는데도 NAT로 바로 몰아가는 것이다.
운영 문서에는 최소한 gateway generation, EIM 여부, dynamic port allocation 여부, top destination share, tuple reuse 흔적, first-request latency, dropped reason을 함께 남기는 편이 좋다. 그래야 경고가 발생한 뒤에도 '무엇이 달라졌는가'를 같은 시간축에서 바로 재현할 수 있다. 메트릭 조회 경로와 확인 순서와 설정 변경 전후 결과도 같이 기록해야 재발 구간을 비교하기 쉽다.
6. 결론
destination fan-out persistence를 남기기 시작했다면, 다음 단계는 shared source tuple reuse와 first-request latency를 같은 시간축에서 경고로 읽는 것이다. port_usage 총량만 보지 말고 destination 집중도, tuple reuse 흔적, latency, dropped reason을 함께 남겨야 설정 문제와 앱 패턴 문제를 분리할 수 있다.
같은 가지의 선행 글로는 destination fan-out persistence 표 글, override 제거 뒤 지연 시간축 글, mixed gateway TIME_WAIT 글을 같이 보면 좋다.
경고를 본 뒤 실제로 min ports per VM과 max ports per VM 중 무엇을 먼저 조정할지까지 이어서 보려면 first-request latency 경고 뒤 min/max ports 조정 순서를 정리한 글을 함께 읽는 편이 좋다. 임계값을 세우는 단계와 값을 바꾸는 단계를 분리해 두면 포트 설정 변경이 훨씬 덜 헷갈린다.
7. 참고 링크
'기타개발지식 > 풀스택개발' 카테고리의 다른 글
