실무 리더가 정리한 Azure AKS 네트워크 지연: 원인 규명과 MTU 조정 적용 운영 아키텍처와 모범사례
실무 리더 요약 정리
이 글은 실무 리더가 정리한 Azure AKS 네트워크 지연: 원인 규명과 MTU 조정 적용 운영 아키텍처와 모범사례를 둘러싼 현업 의사결정 포인트를 정리해 둔 섹션입니다.
- 이 글에서 짚고 가는 핵심 포인트
- 핵심 요약
- 문제 범위와 배경
- 지연 원인 진단 절차
팀 내 위키나 아키텍처 리뷰 문서에 그대로 옮겨 적고, 우리 조직 상황에 맞게만 수정해도 큰 도움이 됩니다.
몇 년 전 우리 팀은 Azure AKS 네트워크 지연: 원인 규명과 MTU 조정 적용를 제대로 설계하지 못해 장애와 불필요한 야근이 반복되었습니다. 이 글은 그런 상황을 되풀이하지 않기 위해, 리더 입장에서 어떤 구조와 운영 방식을 먼저 정리해야 하는지에 초점을 맞추고 있습니다.
이 글에서 짚고 가는 핵심 포인트
- 핵심 요약
- 문제 범위와 배경
- 지연 원인 진단 절차
- MTU 조정 적용 방법
실제 엔터프라이즈 환경에서 Azure AKS 네트워크 지연: 원인 규명과 MTU 조정 적용를 적용할 때 꼭 체크해야 할 구조와 운영 포인트만 정리했습니다.
핵심 요약
Azure AKS 환경에서 네트워크 지연이 반복적으로 발생할 때, MTU 불일치(패킷 분할/재조립)와 경로상 중간 장치(MTU 제한, VPN/ExpressRoute, NAT 게이트웨이 등)가 주요한 원인입니다. 문제를 해결하려면 측정 → 원인 분리 → 안전한 범위에서 MTU 조정 또는 TCP MSS 클램핑을 적용하는 절차가 필요합니다.
이 글은 진단 프로세스, 적용 가능한 수정 방법(노드 수준, CNI 구성, iptables 설정), 실제 장애 사례와 단계별 해결 과정을 실무 관점에서 정리합니다.
문제 범위와 배경
AKS는 여러 CNI 플러그인(azure-vnet-cni, kube-router, calico 등)을 통해 파드 네트워크를 구성합니다. AKS의 네트워크 전체 경로는 사용자 VNet, 온프레미스 연결(ExpressRoute/VPN), Azure 로드밸런서, NAT 게이트웨이 등 다양한 요소를 포함합니다. 각 요소는 MTU에 영향을 줄 수 있습니다.
특히 VPN 터널이나 IPsec, GRE, VXLAN 같은 오버레이 기술을 사용하는 경우, 원래의 1500 MTU에서 추가 헤더로 인해 실사용 가능한 MTU가 줄어들며, PMTU(Path MTU) 블랙홀이나 조각화(fragmentation)로 인해 TCP 성능 저하 또는 패킷 손실이 발생할 수 있습니다.
지연 원인 진단 절차
문제 진단은 가능한 한 네트워크 경로의 단계별 측정으로 접근해야 합니다. 일반적으로 다음 단계를 권장합니다: (1) 기본 연결/RTT 확인(ping), (2) PMTU 측정(ping -M do -s), (3) 트래픽 재현 및 tcpdump/wireshark로 분절·재전송 확인, (4) 노드/인터페이스 레벨 MTU 및 CNI 설정 확인, (5) 중간 장치(Load Balancer, NAT, VPN 게이트웨이) 정책 점검.
예시 명령: ping과 tcpdump를 이용해 MTU 문제를 확인할 수 있습니다. 다음은 PMTU를 테스트하는 방법입니다.
# PMTU 테스트: 1472 + 28 = 1500 기본 이더넷 MTU
ping -c 3 -M do -s 1472 10.0.0.5
# 노드에서 인터페이스 MTU 확인
ip -d link show eth0
# 트래픽 캡처 (노드/플로우 대상)
sudo tcpdump -i eth0 host 10.0.0.5 -w capture.pcap
캡처에서 "fragmentation needed" 또는 재전송 패턴, 또는 ICMP "Fragmentation needed" 메시지가 보이면 PMTU 문제가 의심됩니다.
MTU 조정 적용 방법
MTU 수정은 여러 레벨에서 가능합니다. 안전한 순서는: 영향 범위를 최소화하기 위해 먼저 테스트 노드/네임스페이스에 적용 후 전체 롤아웃입니다. 적용 대상은 크게 세 가지입니다: 노드 네트워크 인터페이스, CNI 플러그인 설정, 그리고 TCP MSS 조정(iptables).
노드 수준 MTU 변경은 즉시 적용되지만 재부팅/노드 재생성 시 지속성을 확보하려면 이미지/클라우드 이니셜라이저나 DaemonSet을 통해 설정해야 합니다. 아래는 MTU를 노드 인터페이스에 적용하는 예와, iptables로 MSS를 클램프하는 예시 DaemonSet 스크립트입니다.
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: mtu-adjust
namespace: kube-system
spec:
selector:
matchLabels:
name: mtu-adjust
template:
metadata:
labels:
name: mtu-adjust
spec:
hostNetwork: true
hostPID: true
tolerations:
- operator: "Exists"
containers:
- name: mtu-setter
image: ubuntu:22.04
securityContext:
privileged: true
command:
- sh
- -c
- |
# 인터페이스 이름은 환경에 따라 다릅니다: eth0, eth1, ens4 등
IFACE=$(ip route show default | awk '/default/ {print $5}')
echo "setting MTU on $IFACE to 1400"
ip link set dev $IFACE mtu 1400 || true
# TCP MSS 클램프 (예: 외부 VPN/ExpressRoute가 MTU를 제한할 때)
iptables -t mangle -C FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN \
-j TCPMSS --clamp-mss-to-pmtu || \
iptables -t mangle -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN \
-j TCPMSS --clamp-mss-to-pmtu
sleep infinity
nodeSelector:
kubernetes.io/os: linux
위 예시는 MTU를 1400으로 강제하고 TCP MSS를 PMTU에 맞추도록 설정합니다. 실제 값은 네트워크 경로의 최대 허용 MTU에서 안전 마진(예: VPN 헤더 크기)을 빼서 결정해야 합니다.
현업 사례와 단계별 해결
사례 A: 온프레↔AKS ExpressRoute 경로에서 간헐적 패킷 손실 및 지연
상황: 특정 서비스 호출 시 패킷 손실과 TCP 재전송이 관찰되어 응답 지연이 발생했습니다. 고객 트래픽이 온프레에서 ExpressRoute를 통해 AKS로 들어오는 경로에서만 발생했습니다.
원인 규명: PMTU 테스트 결과 온프레측 최대 허용 MTU가 1450임을 확인했습니다. AKS 노드 인터페이스는 1500으로 설정되어 있어 중간에서 조각화가 발생했고, 일부 경로에서 ICMP "Fragmentation needed"가 차단되어 PMTU 블랙홀 현상이 생겼습니다.
해결 과정(단계별): 1) 영향 범위 산정: 특정 서브넷 및 서비스만 영향을 받는지 확인. 2) 테스트 변경: 비프로덕션 노드 하나에 MTU를 1450으로 변경하고 트래픽을 재현하여 개선 여부 확인. 3) 임시 완화: iptables TCPMSS 클램프를 적용하여 세션이 재설정 없이 정상화되는지 확인. 4) 영구 적용: 노드 이미지를 업데이트하고 모든 노드에 DaemonSet으로 MTU 조정 적용. 5) 모니터링: RTO/RPS/패킷 손실을 모니터링하여 재발 여부를 관찰.
사례 B: 내부 서비스 간 p99 지연 상승 (Calico VXLAN 사용)
상황: Calico VXLAN 오버레이를 사용하는 클러스터에서 갑작스러운 p99 레이턴시 상승이 보고되었습니다. 패킷 캡처에서 일부 패킷이 분절되어 처리 시간 증가와 재전송이 발생했습니다.
원인 규명: VXLAN 헤더(50 bytes 가량)로 인해 실제 유효 MTU가 1450 미만으로 줄어들었는데, 일부 노드의 NIC 드라이버가 자동으로 분절하지 않고 패킷을 드롭했습니다. 또한 iptables 설정에 MSS 조정 룰이 없어 TCP 연결이 대역폭을 효과적으로 사용하지 못했습니다.
해결 과정(단계별): 1) VXLAN 오버레이 정책을 재검토하고, calico/node의 MTU 설정을 net-conf에 반영(예: 1400). 2) 노드 재배포 전에 키 시스템(데이터베이스/레디스)에 단계적 트래픽 분리 및 Canary 배포 수행. 3) 모든 노드에 MSS 클램프 iptables 룰을 배포하여 새로운 연결에 대해 MSS가 적절히 설정되도록 함. 4) 결과 모니터링: p99 레이턴시가 정상화되고 재전송/분절 로그가 사라졌음을 확인.
모범사례 / 베스트 프랙티스
- MTU 변경은 전체 클러스터에 한 번에 적용하지 말고, Canary 노드 → 워크로드 → 전체 롤아웃 방식으로 검증하십시오.
- PMTU 문제는 보통 중간 경로의 장치(ExpressRoute, VPN, NAT, LB)와 연관되므로 경계 장치를 함께 진단하세요.
- 노드 재생성(autoscaling, upgrade) 시 설정이 유지되도록 DaemonSet 또는 이미지 빌드 파이프라인에 설정을 포함시키세요.
- iptables TCPMSS 클램프는 클라이언트가 패킷 크기를 줄이지 못할 때 유용한 완화책입니다(특히 외부 VPN 경로에서).
- 모니터링 지표(패킷 손실, 재전송률, p99/p95 레이턴시)를 중앙화하여 MTU 및 네트워크 변경의 영향을 계측하세요.
- CNI 문서를 확인하여 플러그인별 MTU 설정 방법을 숙지하고, 각 환경별(Windows/Linux, Azure CNI/Calico) 차이를 관리하세요.
- 변경 전/후의 트래픽 캡처를 저장해두어 추후 회귀 분석에 활용하십시오.
FAQ
Q1: AKS에서 기본 MTU 값은 무엇인가요? 변경하면 리스크가 있나요?
A1: 기본 이더넷 MTU는 일반적으로 1500입니다. 그러나 오버레이(VXLAN), VPN, ExpressRoute 등 경로 요소로 인해 실효 MTU는 더 낮아질 수 있습니다. MTU 변경은 패킷 단편화/연결 문제를 해결하지만, 잘못 설정하면 패킷 손실을 유발할 수 있으므로 테스트가 필요합니다.
Q2: Azure CNI에서는 MTU를 어디서 설정하나요?
A2: azure-vnet-cni의 경우 CNI 설정 파일에서 "mtu" 옵션을 제공하는 버전이 있습니다. 다만 AKS의 관리형 구성에서는 직접 수정이 제한될 수 있어, DaemonSet으로 인터페이스 MTU를 조정하거나 CNI 설치 시 제공되는 옵션을 사용하는 방법을 권장합니다.
Q3: MTU 문제를 간단히 확인할 수 있는 방법은 무엇인가요?
A3: PMTU 테스트(ping -M do -s SIZE)로 시작하세요. 또한 tcpdump로 재전송/ICMP 메시지를 확인하고, ip -d link show로 인터페이스 MTU를 점검하세요. 문제 재현 시 iperf로 성능 테스트도 병행하십시오.
Q4: MSS 클램프는 언제 사용하는 것이 적절한가요?
A4: 클라이언트가 경로 MTU 변경을 제대로 반영하지 못해 TCP 연결이 큰 패킷을 계속 전송할 때 유용합니다. iptables mangle 테이블의 TCPMSS --clamp-mss-to-pmtu 룰은 터널 헤더로 인한 MTU 감소를 자동으로 보정합니다.
Q5: 노드 MTU와 파드(Mesh/CNI) MTU가 다른 경우 어떻게 관리해야 하나요?
A5: 일반 원칙은 파드 네트워크가 노드 인터페이스 MTU보다 작거나 같아야 합니다. 오버레이의 경우 오버레이 헤더만큼 파드 MTU를 줄여야 하며, CNI 설정에서 그 값을 명확히 하거나, 노드 인터페이스를 더 작은 MTU로 맞추는 방식으로 일관성을 유지하세요.
엔터프라이즈 팀 리더 경험담
에피소드 1 — 프로덕션에서 간헐적 고지연(Inter-pod) 발생
문제
특정 서비스(마이크로서비스 A↔B) 간 호출에서 P95 지연이 300–500ms로 급증하여 SLO(내부 RPC P95 < 100ms)를 지속적으로 위반했습니다. 한 달에 5건의 고객 영향(장애)에 해당하는 사건이 보고되었고, 평균 MTTR은 약 3.2시간이었습니다.
접근
1) 네트워크 측정: pod↔pod 트레이스, tcpdump, iperf로 MTU와 패킷 분할(fragmentation), TCP 재전송률을 확인했습니다.
2) 가설 수립: AKS 클러스터에서 사용 중인 오버레이(VXLAN/Flannel 등)와 Azure VNet 경로(특히 VPN/ExpressRoute 구간)가 중첩되며 MTU 오버헤드가 생기고, 경로 MTU 발견(PMTUD)이 ICMP 차단으로 실패해 단편화/재전송이 발생한다고 판단했습니다.
3) 협업·검증: 네트워크팀과 함께 NSG/방화벽에서 ICMP 차단 여부를 확인하고, 테스트 노드에서 MTU를 낮춘 상태(예: 1450→1400)로 패킷 손실/지연 변화를 관찰했습니다.
4) 적용 계획: 운영 위험을 줄이기 위해 노드풀 단위로 롤링 업데이트(노드 drain → 데몬셋/컨테이너 런타임 MTU 설정 적용 → 검증 → 다음 노드) 절차를 문서화하고 자동화했습니다.
결과
- MTU를 1400으로 조정하고 CNI 설정을 일관화한 뒤 P95 지연이 평균 350–500ms에서 50–80ms로 개선되어 SLO 정상화가 확인되었습니다.
- 매월 발생하던 관련 장애 건수는 5건 → 0–1건으로 감소했고, 평균 MTTR은 3.2시간 → 0.9시간으로 단축되었습니다.
회고
- 문제 원인은 복합적이었고 단순한 앱 튜닝으로는 해결되지 않았습니다. 네트워크 층(오버레이/언더레이/중간 경로 장비)을 함께 보지 않으면 문제 재발 위험이 큽니다.
- ICMP를 차단하는 방화벽 규칙이 PMTUD를 방해할 수 있으니, 정책 검토를 운영 초기 체크리스트에 넣는 것이 필요합니다.
- 노드별 설정을 수동으로 바꾸면 운영 중 설정 불일치가 생기므로, CNI 설정 및 MTU를 인프라 코드로 관리하고 클러스터 생성 시부터 적용하도록 표준화했습니다.
에피소드 2 — 다중 클러스터/네트워크 프로파일에서의 MTU 적용 표준화
문제
여러 AKS 클러스터(테스트·스테이징·프로덕션)가 각각 다른 CNI와 기본 MTU 정책으로 생성되어 있었고, 서비스 이관 시 네트워크 지연/단편화 문제가 환경별로 다르게 발생했습니다. 클러스터별 설정 불일치로 인해 신규 클러스터 배포 후 검증에 평균 5일이 소요되었습니다.
접근
1) 운영 아키텍처 수립: latency-sensitive 서비스용 네트워크 프로파일(예: MTU=1400, 특정 CNI 옵션, 호스트네트워크/전용 노드풀)과 일반 프로파일을 정의했습니다.
2) 자동화·검증: 인프라 코드(Terraform/ARM)와 클러스터 프로비저닝 파이프라인에 네트워크 프로파일을 템플릿화했고, CI 단계에 MTU/패킷 단편화 검증(간단한 iperf + packet capture 스모크 테스트)을 추가했습니다.
3) 운영 문서화: 롤백 절차, 드레인 정책, 모니터링(특히 TCP retransmits, P95 latency)을 표준 운영 메뉴얼에 포함했습니다.
결과
- 신규 클러스터의 네트워크 준수(프로파일 적용) 소요 시간이 평균 5일에서 1일로 단축되었습니다.
- 네트워크 설정 불일치로 인한 인시던트 발생 비율이 눈에 띄게 감소했고, 내부 SLO(지연 관련) 준수율이 전반적으로 개선되었습니다(정량 지표는 컨텍스트에 따라 다르므로 배포 전후 비교 지표를 항상 기록하도록 결정했습니다).
회고
- MTU/네트워크 관련 변경은 클러스터 수준에서 서비스 영향도가 크므로, 변경 전후의 측정(정량적)과 단계적 롤아웃이 필수입니다.
- 네트워크팀·보안팀과의 초기 설계 협업, 그리고 인프라 코드에 의한 일관된 적용이 문제 예방에 가장 효과적이었습니다. 운영 시점에는 모니터링 항목(TCP 재전송률, P95 latency, 패킷 분절 통계)을 표준 대시보드에 포함시켜 조기 경보를 설정했습니다.
문제 vs 해결 전략 요약
| 문제 | 해결 전략 |
|---|---|
| 조직마다 제각각인 Azure AKS 네트워크 지연: 원인 규명과 MTU 조정 적용 운영 방식 | 표준 아키텍처와 운영 상용구를 정의하고 서비스별로 변형만 허용 |
| 장애 후에야 뒤늦게 쌓이는 인사이트 | 사전 지표 설계와 SLO/에러 버짓을 기반으로 한 사전 탐지 체계 구축 |
| 문서와 실제 운영 사이의 괴리 | Infrastructure as Code와 같은 실행 가능한 문서 형태로 관리 |
결론 및 다음 액션
AKS 환경의 네트워크 지연 이슈는 MTU 불일치에서 기인하는 경우가 많습니다. 진단과 적용은 단계적이고 계측기반으로 진행해야 하며, 변경 시 재현 가능한 Canary 절차와 모니터링이 필수입니다.
다음 액션(권장)
- 경계 장치(ExpressRoute/VPN/NAT/LB)의 MTU/터널 헤더 크기를 문서화하고 현재 경로의 PMTU를 측정하세요.
- 비프로덕션 환경에서 MTU 변경과 TCPMSS 적용을 Canary 테스트로 검증하세요(데몬셋 방식 권장).
- 변경 전후의 p95/p99 레이턴시, 재전송률, 패킷 손실률을 계측 및 알람으로 설정하세요.
- CNI별 MTU 구성 가이드를 팀 위키에 정리하고, 신규 클러스터 템플릿에 반영하세요.
- 운영 롤북에 MTU/PMTU 진단 절차(명령, 캡처 경로, 체크리스트)를 추가해 사고 대응 시간을 단축하세요.
댓글
댓글 쓰기