[Cloud NAT][운영] timeout과 reuse-delay를 손댄 뒤에도 reconnect burst가 남을 때 fan-out persistence 시간을 어느 메트릭 순서로 다시 묶나

IT 리서치 노트

[Cloud NAT][운영] timeout과 reuse-delay를 손댄 뒤에도 reconnect burst가 남을 때 fan-out persistence 시간을 어느 메트릭 순서로 다시 묶나

Cloud NAT에서 timeout과 reuse-delay를 손본 뒤에도 reconnect burst가 계속 남으면 많은 팀이 같은 timeout 값을 더 키우거나 줄이는 쪽으로만 움직인다. 하지만 2026년 7월 28일 기준 Google Cloud 공식 문서를 다시 보면 timeout 조정은 port reuse 시차에 영향을 줄 뿐이고, 같은 내부 source tuple이 여러 destination으로 퍼지는 fan-out persistence는 다른 시간축 메모가 필요하다. 이 글은 reconnect burst가 남는 상황에서 drop reason, port_usage, destination 3-tuple share, 재확인 시각을 어떤 순서로 묶어야 timeout 잔여와 구조적 fan-out 지속을 짧게 분리할 수 있는지 정리한다.

목차

1. 개요
2. 어디서 실제로 막히는가
3. 실무에서 적용하는 순서
4. 공식 문서와 예시 화면으로 확인하기
5. 주의사항과 리스크
6. 결론
7. 참고 링크

1. 개요

결론부터 말하면 timeout과 reuse-delay를 건드린 뒤에도 reconnect burst가 남으면 다음 순서는 fan-out persistence 시간축을 메트릭에 붙이는 일이다. 먼저 timeout 변경 시각과 dropped_sent_packets_count를 적고, 그다음 reason 라벨과 port_usage를 적고, 마지막에 destination 3-tuple share와 재확인 시각을 붙여야 timeout 잔여와 구조적 분포 지속이 갈린다.

즉 timeout 변경 뒤 남는 burst를 다시 timeout만의 문제로 보면 안 된다. 시간축 메모가 없으면 port reuse 지연과 fan-out persistence가 한 줄로 섞이고, 같은 설정을 반복 변경하는 악순환이 생긴다.

2. 어디서 실제로 막히는가

현장에서 자주 생기는 실수는 네 가지다. 첫째, timeout 변경 시각을 안 적고 drop metric만 본다. 둘째, reconnect burst가 남아도 reason 라벨과 port_usage를 같은 줄에 저장하지 않는다. 셋째, destination fan-out 분포는 보지만 언제까지 지속됐는지 시간을 안 남긴다. 넷째, keepalive나 reconnect batch timing을 보기 전에 다시 timeout 값을 바꾼다.

Google 문서는 timeout 변경이 port reuse를 늦출 수 있다고 설명하고, Public NAT 문서는 같은 내부 source tuple이 여러 destination으로 퍼지는 EIM 동작을 따로 설명한다. 또 packet loss 문서는 drop reason을 세 갈래로 나눠 보라고 한다. 즉 reconnect burst가 남는 상황은 timeout과 fan-out과 reason이 동시에 붙는 구조다.

이 세 축을 분리하지 않으면 증상은 계속 같은 것처럼 보인다. 하지만 실제로는 timeout 조정 직후 잠깐 남는 잔여 지연인지, 특정 destination에 대한 reconnect 패턴이 구조적으로 유지되는지, 아니면 allocation 경고가 아직 끝나지 않은지에 따라 후속 행동이 달라진다.

• 증상: timeout 변경 뒤에도 reconnect burst와 dropped packets가 남는다.
• 실패: 변경 시각 없이 metric만 저장한다.
• 막힘: reason 라벨과 destination 3-tuple 분포를 따로 적어 시간축이 사라진다.
• 누락: 첫 재확인과 두 번째 재확인 시각을 기록하지 않는다.

남는 신호	먼저 붙일 값	왜 필요한가
변경 직후 dropped packets	timeout 변경 시각	단기 잔여인지 구조적 지속인지 나눈다
burst가 특정 VM에 몰림	port_usage와 reason 라벨	resource 부족과 conflict를 다시 분리한다
drop은 줄었는데 burst 체감이 남음	destination 3-tuple share와 persistence window	fan-out 지속이 keepalive 또는 reconnect 패턴 문제인지 본다

3. 실무에서 적용하는 순서

가장 짧은 메트릭 순서는 다섯 단계다. 1단계에서 timeout 변경 시각과 dropped metric을 적는다. 2단계에서 reason 라벨과 port_usage를 같은 줄에 묶는다. 3단계에서 상위 VM과 destination 3-tuple share를 적는다. 4단계에서 첫 재확인 시각과 두 번째 재확인 시각을 넣는다. 5단계에서 fan-out persistence window를 계산하고 keepalive 또는 reconnect batch timing 후속 조치를 정한다.

1. timeout 변경 시각과 dropped metric을 함께 적는다.
2. reason 라벨과 port_usage를 같은 줄에 묶는다.
3. 상위 VM과 destination 3-tuple share를 적는다.
4. 첫 재확인과 두 번째 재확인 시각을 남긴다.
5. fan-out persistence window를 계산해 후속 조치를 정한다.

이 순서를 쓰면 timeout 조정 뒤 남는 burst를 더 차분하게 설명할 수 있다. 예를 들어 reason이 ENDPOINT_INDEPENDENCE_CONFLICT로 유지되고 destination share가 높게 남으면 fan-out persistence 쪽이 우선이고, 반대로 reason이 OUT_OF_RESOURCES로 되돌아오면 공급량 조치가 충분하지 않았던 쪽으로 다시 간다.

incident checklist

1. timeout 변경 시각 기록
2. dropped_sent_packets_count와 reason 저장
3. port_usage 상위 VM 저장
4. destination 3-tuple share 저장
5. 첫/두 번째 재확인 시각 기록
6. persistence window 계산 후 keepalive 또는 reconnect 후속 조치 선택

특히 동일한 reconnect burst가 여러 차례 반복되는 시스템이라면 이 시간축 메모가 없으면 원인을 계속 설정 diff에서만 찾게 된다. timeout 조정은 필요한 조치일 수 있지만, 그 뒤 남는 persistence는 distribution과 workload 패턴의 문제일 수 있다.

4. 공식 문서와 예시 화면으로 확인하기

첫 화면은 실제 드롭을 보는 기준점이다. Monitoring 화면의 logs and metrics 메뉴를 열고 dropped_sent_packets_count 항목을 표시한 뒤, 결과 표와 로그 화면을 함께 비교해야 timeout과 reuse-delay를 바꾼 뒤에도 무엇이 남는지 분명해진다.

Cloud NAT monitoring 문서는 dropped_sent_packets_count를 실제 전송 드롭 metric으로 제공한다.

즉 reconnect burst가 남을 때도 첫 질문은 여전히 드롭이 resource 부족인지, conflict인지, 아니면 fan-out persistence인지다. metric 자체는 출발점이고, 해석은 다음 축에서 갈린다.

두 번째 자료는 troubleshooting 문서의 port reuse 설명이다. troubleshooting 화면에서 timeout 설명 블록을 열고, 강조된 문장을 확인하고, 변경한 timeout 값과 로그 결과를 같은 표에 입력하면 port reuse 지연 구간을 더 빠르게 비교할 수 있다.

Cloud NAT troubleshooting 문서는 timeout 증가가 port reuse를 늦출 수 있다고 설명한다.

이 문장을 보면 timeout 조정이 reconnect burst를 항상 줄이는 방향만은 아니라는 점이 분명해진다. 이미 TIME_WAIT이나 idle timeout을 건드렸다면, 그 뒤 남는 burst는 시간축 메모 없이 해석하기 어렵다.

세 번째 자료는 fan-out persistence가 왜 따로 남는지를 보여 준다. Public NAT 문서 화면에서 EIM 설명 블록을 찾고, destination 3-tuple 분포를 기록할 필드와 결과 표를 같이 준비해 두면 fan-out persistence 창을 추적하기 쉬워진다.

Public NAT 문서는 EIM이 destination fan-out과 연결된다고 설명한다.

따라서 reconnect burst가 timeout 조정 뒤에도 남으면 다음 질문은 포트 재사용 시차만이 아니라 어떤 destination 3-tuple 분포가 계속 유지되는가다. fan-out persistence 시간을 같은 사건 메모에 넣어야 이유가 짧아진다.

네 번째 자료는 drop reason 분기다. reconnect burst가 남아도 Google은 여전히 OUT_OF_RESOURCES, ENDPOINT_INDEPENDENCE_CONFLICT, NAT_ALLOCATION_FAILED를 अलग 원인으로 나누어 보라고 안내한다.

GKE packet loss 문서는 Cloud NAT packet drop을 세 가지 reason으로 분리해 읽으라고 설명한다.

즉 timeout 변경 뒤 남는 burst도 reason 라벨이 어떤 방향을 가리키는지 먼저 적어야 한다. 이 화면에서는 reason 필드, metric 이름, 결과 표를 같이 보고 logs 메뉴에서 같은 시각의 이벤트를 확인해야 한다.

실무에서는 timeout 값과 fan-out 분포를 따로 저장해 두면 나중에 reconnect burst가 계속 남는 이유를 설명하기 어렵다. 이 표는 metric과 시간축을 같은 줄에 고정해 두기 위한 자료다.

reconnect burst가 남을 때 fan-out persistence 시간을 메트릭 순서로 묶는 표다.

이미 timeout과 reuse-delay 재점검 글이 drop reason과 timeout 조정 이력을 잡아 줬다면, 이번 표는 그 다음 단계인 fan-out persistence 시간축을 추가한다.

마지막 자료는 incident 메모 예시다. timeout과 reuse-delay를 바꾼 뒤 남는 reconnect burst는 configuration diff만으로는 설명이 부족하므로, drop reason과 fan-out persistence 시간을 같은 메모에 넣는 편이 좋다.

timeout 변경 뒤 reconnect burst를 추적하는 incident 메모 예시다.

이 메모 구조가 있으면 destination fan-out persistence 글과 add-IP vs reduction 글을 같은 후속 runbook으로 이어 붙이기 쉽다.

5. 주의사항과 리스크

첫 번째 리스크는 timeout 조정 직후 잠깐 남는 잔여 지연을 구조적 문제로 오판하는 것이다. 두 번째 리스크는 fan-out persistence를 보면서도 reason 라벨을 빼서 resource 부족과 conflict를 구분하지 못하는 것이다. 세 번째 리스크는 keepalive와 reconnect batch timing을 보기 전에 timeout을 다시 만지는 것이다.

운영 전에 확인할 때는 최소한 timeout 변경 시각, dropped metric, reason, port_usage, destination share, 재확인 시각을 같은 메모에 넣는 편이 좋다. 이 다섯 값이 있어야 fan-out persistence 시간을 다시 계산할 수 있다.

• timeout 조정과 fan-out persistence는 같은 축이 아니다.
• reason 라벨이 없으면 reconnect burst 해석이 불분명해진다.
• 재확인 시각이 있어야 잔여 지연과 구조적 지속을 나눌 수 있다.

6. 결론

timeout과 reuse-delay를 바꾼 뒤에도 reconnect burst가 남는다면 이제 필요한 것은 더 많은 timeout 조정이 아니라 fan-out persistence 시간축 메모다. dropped metric, reason, port_usage, destination share, 재확인 시각을 같은 순서로 묶으면 timeout 잔여와 구조적 분포 지속을 더 짧게 분리할 수 있다.

• timeout 변경 시각을 metric보다 먼저 적는다.
• reason과 destination share를 함께 기록한다.
• fan-out persistence window가 후속 조치 순서를 정한다.

7. 참고 링크

1. https://docs.cloud.google.com/nat/docs/monitoring
2. https://docs.cloud.google.com/nat/docs/troubleshooting
3. https://docs.cloud.google.com/nat/docs/tune-nat-configuration
4. https://docs.cloud.google.com/nat/docs/public-nat
5. https://docs.cloud.google.com/kubernetes-engine/docs/troubleshooting/cloud-nat-packet-loss