[Cloud NAT][운영] nat_allocation_failed와 dropped_sent_packets_count가 같이 뜰 때 destination fan-out까지 어떤 콘솔 순서로 확인하나

IT 리서치 노트

[Cloud NAT][운영] nat_allocation_failed와 dropped_sent_packets_count가 같이 뜰 때 destination fan-out까지 어떤 콘솔 순서로 확인하나

Cloud NAT 운영에서 nat_allocation_failed와 dropped_sent_packets_count가 같이 뜨면 많은 팀이 NAT IP 추가부터 하거나, 반대로 port reduction만 반복한다. 하지만 2026년 7월 26일 기준 Google Cloud 공식 문서를 다시 보면 allocation 경고, dropped packets, destination fan-out은 서로 다른 층이다. 이 글은 alert가 한 번에 몰렸을 때 Cloud NAT 콘솔과 Monitoring과 Logs Explorer를 어떤 순서로 열어야 port 부족, 실제 손실, distribution 문제를 짧게 나눌 수 있는지 정리한다.

목차

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

1. 개요

결론부터 말하면 Cloud NAT alert triage는 경고, 손실, 분포 순서로 가는 편이 가장 빠르다. 먼저 nat_allocation_failed 시각과 gateway 범위를 적고, 그다음 dropped_sent_packets_count와 port_usage를 같은 시간축으로 조회하고, 마지막에 destination fan-out까지 내려가면 된다.

즉 콘솔 순서는 gateway details, metrics, per-VM table, logs, fan-out memo다. 이 순서를 고정해 두면 metric 허브 글과 fan-out persistence 글을 같은 incident flow 안에서 함께 쓸 수 있다.

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

현장에서 제일 많이 섞이는 실수는 네 가지다. 첫째, nat_allocation_failed만 보고 바로 NAT IP를 추가한다. 둘째, dropped packets를 따로 조회하지 않아 실제 손실 여부를 모른다. 셋째, port_usage를 평균으로만 보고 특정 VM 편향을 놓친다. 넷째, 그래프는 봤지만 destination 3-tuple 분포를 기록하지 않아 다음 회고 때 이유를 복기하지 못한다.

Google Cloud 문서는 역할을 분리한다. troubleshooting 문서는 allocation 경고 뒤 분기를 안내하고, monitoring 문서는 dropped packets와 logs를 अलग 축으로 제공하고, Public NAT와 ports-and-addresses 문서는 destination 분포와 EIM 충돌 가능성을 설명한다. 즉 alert triage는 지표 하나의 문제가 아니라 조회 순서의 문제다.

특히 dropped_sent_packets_count가 같이 올랐는데도 분포를 안 보면, 전체 공급 부족인지 특정 destination 쏠림인지가 안 갈린다. 반대로 경고만 있고 dropped packets가 거의 없으면 사용량 분포와 fan-out을 먼저 볼 여지가 생긴다. 이 구분을 콘솔 순서에 녹여 두지 않으면 매번 똑같은 회의를 반복하게 된다.

• 증상: nat_allocation_failed와 dropped packets alert가 같은 창에 몰린다.
• 실패: Cloud NAT 화면만 보고 Monitoring과 Logs Explorer 조회를 건너뛴다.
• 막힘: per-VM port_usage와 destination fan-out을 남기지 않아 공급 부족과 편향을 분리 못 한다.
• 누락: 로그 시각과 alert 시각을 같은 메모에 적지 않는다.

신호	다음으로 열 화면	판단 기준
nat_allocation_failed만 반복	Metric Explorer	dropped packets가 실제로 동반되는지 본다
dropped packets까지 같이 오른다	per-VM chart와 Logs Explorer	특정 VM 편향인지 전체 공급 부족인지 나눈다
port_usage는 비슷한데 지연이 남는다	fan-out 메모와 destination 분포 표	destination 3-tuple 집중과 shared tuple 흔적을 본다

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

가장 짧은 triage는 다섯 단계다. 1단계에서 Cloud NAT gateway details를 열어 alert 시각과 범위를 적는다. 2단계에서 Monitoring에서 dropped_sent_packets_count와 port_usage를 같은 시간축으로 조회한다. 3단계에서 per-VM 표를 열어 상위 VM 몇 개를 저장한다. 4단계에서 Logs Explorer로 error log와 drop reason을 확인한다. 5단계에서 그래도 이유가 안 좁혀지면 destination fan-out 표를 만든다.

1. Cloud NAT gateway details에서 alert 시각을 기록한다.
2. Monitoring에서 dropped_sent_packets_count와 port_usage를 조회한다.
3. per-VM chart와 table을 열어 상위 VM을 저장한다.
4. Logs Explorer에서 drop reason과 error log를 확인한다.
5. 필요하면 destination fan-out 메모를 추가한다.

여기서 중요한 건 NAT IP 추가를 마지막까지 미루라는 뜻이 아니라, 추가 결정을 하기 전에 분포를 먼저 기록하라는 뜻이다. 상위 VM 몇 개만 ceiling 근처라면 reduction이나 connection reuse가 먼저일 수 있고, 대표 VM 다수가 높고 dropped packets도 많다면 NAT IP 추가가 빨라질 수 있다. console order는 이 결정을 근거로 남기기 위해 존재한다.

console checklist

1. Cloud NAT 페이지를 연다
2. gateway details에서 alert window를 저장한다
3. Monitoring에서 dropped_sent_packets_count를 조회한다
4. 같은 차트에서 port_usage를 겹쳐 본다
5. VM별 표를 저장한다
6. Logs Explorer에서 reason과 시각을 저장한다
7. fan-out 표에 destination 집중도를 적는다

이 순서를 반복해 두면 incident review가 짧아진다. 특히 NAT IP 추가 vs reduction 글과 fan-out persistence 글을 어느 쪽으로 먼저 넘길지 콘솔 단계에서 결정할 수 있다.

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

첫 화면은 nat_allocation_failed가 떴을 때의 공식 출발점이다. troubleshooting 문서는 port usage reduction과 NAT IP 추가를 대표 분기로 제시한다.

Cloud NAT troubleshooting 문서는 nat_allocation_failed 뒤 분기를 port reduction과 NAT IP 추가로 안내한다.

하지만 alert가 실제 손실로 이어졌는지는 여기만으로 모른다. 그래서 콘솔 triage는 allocation 경고 뒤에 dropped packets와 destination 분포를 이어서 봐야 한다.

두 번째 자료는 Monitoring 문서의 dropped_sent_packets_count다. Google Cloud는 경고와 실제 패킷 드롭을 다른 metric으로 제공한다.

Cloud NAT monitoring 문서는 dropped_sent_packets_count를 별도 metric으로 제공한다.

즉 nat_allocation_failed가 곧바로 사용자 영향이라는 뜻은 아니다. 콘솔에서는 경고와 손실을 같은 시간축으로 먼저 비교해야 한다.

세 번째 자료는 destination fan-out을 왜 마지막 분기로 보는지 설명한다. Public NAT 문서는 같은 내부 source tuple이 여러 destination으로 퍼질 수 있는 EIM 동작을 설명한다.

Public NAT 문서는 Endpoint-Independent Mapping이 destination fan-out과 어떤 관계를 가지는지 설명한다.

따라서 port_usage와 dropped packets만으로 이유가 안 좁혀지면 다음 질문은 distribution이다. 어느 destination 3-tuple에 얼마나 몰렸는지 콘솔과 로그에서 같이 봐야 한다.

실무에서 시간을 줄이는 건 무엇을 보느냐보다 어디부터 클릭하느냐다. Cloud NAT, Monitoring, Logs Explorer, fan-out 표를 같은 순서로 보면 다음 작업자가 그대로 복사해 따라갈 수 있다.

Cloud NAT alert를 콘솔에서 확인하는 권장 순서 표다.

이미 metric 허브 글이 경고와 손실과 분기 원칙을 잡아 줬다면, 이번 표는 콘솔에서 그 원칙을 실제로 누르는 순서다.

마지막 자료는 실제 triage 메모 예시다. alert, metric, 로그, fan-out을 한 줄 메모에 같이 붙이면 NAT IP 추가와 reduction과 distribution 조사를 서로 다른 작업으로 분리할 수 있다.

Cloud NAT alert triage 메모 예시다.

이 구조가 있으면 destination fan-out persistence 글과 add-IP vs reduction 글을 같은 사건 안에서 연결하기 쉬워진다.

5. 주의사항과 리스크

첫 번째 리스크는 dropped packets를 안 보고 경고만으로 판단하는 것이다. 두 번째 리스크는 per-VM 분포를 안 보고 평균 usage만 보는 것이다. 세 번째 리스크는 port_usage와 drops가 비슷하다는 이유로 fan-out 분포를 건너뛰는 것이다.

운영 전에 남겨야 할 최소값은 alert window, dropped_sent_packets_count, 상위 VM port_usage, drop reason, destination 3-tuple 집중도다. 이 다섯 줄만 있어도 add-IP, reduction, distribution 조사를 서로 다른 작업으로 나눌 수 있다.

• alert 시각과 metric 시각을 같은 메모에 붙여 둔다.
• per-VM 분포가 없으면 편향형과 공급부족형이 섞인다.
• fan-out 메모가 없으면 port_usage가 비슷한 상황을 설명하기 어렵다.

6. 결론

Cloud NAT에서 nat_allocation_failed와 dropped_sent_packets_count가 같이 뜰 때는 경고 하나만 보고 움직이지 않는 편이 안전하다. gateway details, metrics, per-VM table, logs, fan-out memo를 이 순서로 열면 port 부족과 실제 손실과 distribution 문제를 같은 incident 안에서 짧게 분리할 수 있다.

• 경고를 본 뒤 바로 metrics를 같은 시간축으로 겹쳐 본다.
• per-VM 분포와 logs를 저장한 뒤에 add-IP 여부를 판단한다.
• 다음 단계는 metric 허브 글과 fan-out persistence 글을 이어서 보면 된다.

7. 참고 링크

1. https://docs.cloud.google.com/nat/docs/troubleshooting
2. https://docs.cloud.google.com/nat/docs/monitoring
3. https://docs.cloud.google.com/nat/docs/public-nat
4. https://docs.cloud.google.com/nat/docs/ports-and-addresses