MTU 최적화 (단편화, MSS 클램핑, 점보 프레임)

MTU(Maximum Transmission Unit) 최적화 가이드

AWS Direct Connect로 온프레미스와 EC2를 연결했을 때 대용량 쿼리 응답이 2~3배 느려지는 현상, 저도 실제로 겪었습니다. 인스턴스 사양도 충분하고 대역폭도 여유가 있었는데 처리량이 기대치에 한참 못 미쳤습니다. 원인은 MTU 불일치로 인한 대규모 단편화였습니다. 설정 하나가 전체 성능을 망칠 수 있다는 걸 그때 처음 체감했습니다. 그리고 그 설정을 찾아내는 데 예상보다 훨씬 오랜 시간이 걸렸습니다.

환경마다 MTU 기본값이 다르다

일반적으로 MTU는 1500바이트라고 알려져 있습니다. 실제로 이더넷 표준이 그렇습니다. 그런데 클라우드와 터널링 기술이 섞이는 순간 이 상식이 무너집니다.

MTU(Maximum Transmission Unit)란 네트워크에서 한 번에 전송할 수 있는 최대 데이터 단위를 말합니다. 이 값이 경로상 장비마다 다르면, 큰 패킷을 잘게 쪼개는 단편화(Fragmentation)가 발생합니다. 단편화가 반복되면 헤더 처리 오버헤드가 누적되어 성능이 눈에 띄게 저하됩니다.

문제는 환경마다 이 기본값이 제각각이라는 점입니다. AWS EC2는 점보 프레임(Jumbo Frame)을 지원하여 최대 9001바이트까지 설정할 수 있습니다. 점보 프레임이란 표준 이더넷 MTU인 1500바이트를 초과하는 대형 패킷 전송 방식으로, 대용량 데이터를 처리할 때 패킷 수를 줄여 효율을 높입니다. Azure는 최대 3900바이트 수준입니다.

터널링 기술이 추가되면 문제는 더 복잡해집니다. GRE 터널은 24바이트, IPsec ESP는 모드에 따라 50~60바이트, VXLAN은 50바이트의 헤더 오버헤드가 붙습니다. 쿠버네티스 클러스터에서 파드 MTU를 1500으로 그냥 두면 실제 유효 페이로드는 1450바이트로 줄어드는데, 이걸 모르고 운영하다가 지속적인 단편화를 유발하는 경우를 주변에서 꽤 봤습니다. 제 경험상 이 문제는 트래픽이 적을 때는 증상이 잘 안 나타나다가 부하가 걸리는 순간 갑자기 드러납니다. 부하 테스트 없이 운영에 올렸다가 트래픽 몰리는 순간에야 발견하는 최악의 패턴입니다. ip link show 명령으로 전체 경로 인터페이스의 MTU를 처음부터 일일이 확인하는 것이 사실상 유일한 출발점입니다.

환경별 MTU 기본값을 정리하면 다음과 같습니다. 이더넷 표준은 1500바이트이고, AWS EC2 점보 프레임은 최대 9001바이트, Azure 가상 네트워크는 최대 3900바이트입니다. 터널링 오버헤드는 GRE가 24바이트 감소, VXLAN이 50바이트 감소, IPsec ESP가 50~60바이트 감소입니다.

제가 직접 겪었던 케이스로 돌아가면, 온프레미스 쪽 MTU는 1500, AWS 쪽 점보 프레임 설정은 9001이었습니다. 경계에서 두 값이 충돌하면서 대규모 단편화가 쏟아지고 있었습니다. 솔직히 이건 예상 밖이었습니다. Direct Connect라는 전용선을 쓰니까 당연히 최적화되어 있을 거라고 안일하게 생각했거든요. 전용선이 높은 대역폭을 보장해주는 것과 MTU 설정이 올바른 것은 전혀 별개의 문제라는 걸 그때 배웠습니다.

단편화(Fragmentation)란 전송 경로의 MTU 한계를 초과하는 패킷을 라우터가 강제로 분할하는 과정입니다. 분할된 패킷은 목적지에서 다시 조립되어야 하므로, 이 과정에서 CPU 부하와 지연이 발생합니다. RFC 791 명세에 따르면 IPv4에서는 DF(Don't Fragment) 비트를 설정하지 않으면 경로 중간 라우터가 자유롭게 패킷을 분할할 수 있습니다.

최적 MTU를 계산하려면 경로에 추가되는 모든 헤더 오버헤드를 합산해야 합니다. IPsec과 GRE를 이중으로 사용하는 환경이라면 1500에서 IP 헤더 20바이트, GRE 24바이트, 내부 IP 20바이트, UDP 8바이트, ESP 관련 오버헤드를 빼면 약 1410바이트 전후가 됩니다. 이 계산을 건너뛰고 감으로 설정했다가 여전히 단편화가 발생하는 실수를 저도 한 번 했습니다. 숫자를 직접 계산하지 않으면 결국 같은 문제를 반복하게 됩니다. 다소 귀찮더라도 터널 구성을 바꿀 때마다 처음부터 다시 계산하는 습관이 필요합니다.

MSS 클램핑으로 TCP 세션 제어하기

MTU 값을 계산했다면 실제 적용 단계입니다. Linux에서는 ip link set 명령으로 즉시 반영할 수 있고, 재부팅 후에도 유지하려면 netplan 설정이나 NetworkManager에 값을 등록해야 합니다. 쿠버네티스 환경에서는 CNI 플러그인 ConfigMap에서 MTU를 수정해야 파드 네트워크 인터페이스에 정상 반영됩니다. 이걸 빠뜨리면 노드 MTU를 바꿔도 파드 트래픽은 여전히 문제가 생깁니다. 제가 직접 써봤는데, CNI 설정을 빠뜨렸을 때 증상이 절반밖에 해소되지 않아 원인을 찾는 데 추가 시간을 쓴 적이 있습니다. 노드와 파드는 서로 다른 계층이라는 사실을 항상 염두에 두어야 합니다.

TCP 계층에서는 MSS 클램핑을 병행 적용하는 것이 핵심입니다. MSS(Maximum Segment Size)란 TCP 세션에서 한 번에 전송하는 세그먼트의 최대 크기를 말합니다. TCP 연결이 맺어질 때 SYN 패킷에서 MSS 값을 협상하는데, 이 값이 실제 경로 MTU와 맞지 않으면 세션이 수립된 이후에도 단편화가 계속 발생합니다. MSS 클램핑은 방화벽이나 라우터가 SYN 패킷을 가로채 MSS 값을 강제로 낮추는 방법으로, iptables에서 --clamp-mss-to-pmtu 옵션으로 적용할 수 있습니다.

저희 프로젝트에서는 Direct Connect 경계 라우터에 MSS 클램핑을 적용한 후 DB 쿼리 응답 시간이 평균 40% 개선되었습니다. 인스턴스 사양을 업그레이드하거나 쿼리를 튜닝하지 않고도 그 수준의 개선이 나왔습니다. MTU와 MSS가 맞지 않은 상태에서 성능 문제를 잡으려고 다른 곳만 들여다봤다면 시간을 훨씬 더 낭비했을 겁니다. 실제로 그 전에 DB 인덱스를 재설계하는 작업을 먼저 진행했었는데, 그게 별 효과가 없었던 이유가 네트워크 계층의 문제였기 때문이었습니다.

변경 전후 성능 측정과 문서화

설정을 바꿨다면 반드시 수치로 검증해야 합니다. 체감 개선만으로는 부족합니다. 네트워크는 워크로드 패턴에 따라 결과가 달라지기 때문에, 동일한 조건에서 전후를 비교하지 않으면 실제로 MTU 조정이 효과가 있었는지 다른 요인이 개입된 것인지 구분하기 어렵습니다.

iperf3로 지정한 MSS 크기로 TCP 스트림 성능을 측정할 수 있습니다. 처리량(Mbps)뿐 아니라 재전송(Retransmit) 횟수와 레이턴시를 함께 기록하는 것이 중요합니다. 재전송 횟수는 단편화나 패킷 손실이 여전히 발생하고 있는지를 직접적으로 보여주는 지표이기 때문입니다.

문서화도 빠뜨리면 안 됩니다. 저희 팀은 MTU 변경 이력을 분기별 네트워크 헬스체크 항목에 포함시켰습니다. 새로운 터널링 기술이나 클라우드 서비스가 추가될 때마다 MTU 계산을 다시 해야 하는데, 이력이 없으면 현재 값이 어떤 근거로 설정된 것인지 파악하는 데만 시간이 걸립니다. "이 값은 왜 1410이에요?"라는 질문에 즉시 답할 수 있어야 제대로 운영하는 겁니다. 담당자가 바뀌었을 때 이 이력이 없어서 같은 삽질을 반복하는 팀을 여러 번 봤습니다.

점보 프레임(9000바이트)을 도입하면 무조건 성능이 올라간다고 생각하는 분들도 있는데, 실제로는 경로상 모든 장비와 NIC가 점보 프레임을 지원해야 효과가 납니다. 하나라도 1500바이트 제한이 있으면 오히려 역효과가 납니다. 이 제약을 확인하지 않고 점보 프레임을 활성화했다가 오히려 통신 불안정이 생긴 사례를 직접 목격했습니다. 결국 MTU 최적화는 숫자 하나를 바꾸는 작업이 아니라 전체 네트워크 경로를 하나의 시스템으로 이해하는 과정입니다.

MTU 최적화는 한 번 설정하고 끝나는 작업이 아닙니다. 처음 겪으면 당황스럽지만, 환경별 기본값을 파악하고 오버헤드를 직접 계산하고 MSS 클램핑까지 적용한 다음 수치로 검증하는 흐름을 몸에 익히면 다음번에는 훨씬 빠르게 잡을 수 있습니다. 새 서비스나 터널을 추가할 때마다 MTU 계산을 습관처럼 챙기는 것, 그게 결국 예방적 네트워크 운영의 시작입니다.

---

출처 및 참고

• RFC 791 - Internet Protocol (IP Fragmentation): https://www.rfc-editor.org/rfc/rfc791
• RFC 1191 - Path MTU Discovery: https://www.rfc-editor.org/rfc/rfc1191
• Linux ip command man page: https://man7.org/linux/man-pages/man8/ip.8.html