본문 바로가기

카테고리 없음

Investigation of a Cross-regional Network Performance Issue

원문글: https://netflixtechblog.medium.com/investigation-of-a-cross-regional-network-performance-issue-422d6218fdf1

 

Investigation of a Cross-regional Network Performance Issue

Hechao Li, Roger Cruz

netflixtechblog.medium.com

*커널업데이트로 인한 장애 발생

네트워크 성능 문제를 일으킨 리눅스 커널 내부의 TCP 구현 방식 변경은 TCP 수신 윈도우의 크기를 계산하는 방식의 변화에 관련되어 있습니다. 이 변경은 데이터 전송 속도와 성능에 직접적인 영향을 미쳤습니다. 다음은 변경된 부분에 대한 자세한 설명입니다:

TCP 수신 윈도우(TCP Receive Window)

TCP 수신 윈도우는 TCP/IP 네트워크 통신에서 수신자가 송신자에게 "나는 이만큼의 데이터를 받을 수 있어"라고 알리는 메커니즘입니다. 이 윈도우 크기는 네트워크의 데이터 흐름을 제어하고, 네트워크 혼잡을 관리하는 데 중요한 역할을 합니다.

이전 구현 (sysctl_tcp_adv_win_scale)

리눅스 커널은 SO_RCVBUF 소켓 옵션을 사용하여 애플리케이션이 TCP 수신 버퍼에 사용할 메모리 양을 설정할 수 있게 합니다. 커널은 이 값을 두 배로 증가시켜 실제 내부 버퍼 크기를 설정합니다. 이전에는 tcp_adv_win_scale 시스템 변수를 사용하여 수신 윈도우 크기를 결정했습니다. 이 변수는 버퍼링 오버헤드를 계산하는 데 사용되며, 수신 윈도우 크기 계산에 영향을 미칩니다.

변경된 구현

커널 업데이트에서는 tcp_adv_win_scale 옵션이 폐지되고, scaling_ratio라는 새로운 메커니즘이 도입되었습니다. 이 새로운 계산 방식은 TCP 수신 윈도우 크기를 더 정확하게 계산하기 위해 skb->len과 skb->truesize의 비율을 사용합니다. 여기서 skb->len은 TCP 데이터의 길이를 나타내고, skb->truesize는 전체 데이터 구조의 크기를 나타냅니다. 이 비율을 사용함으로써, 커널은 실제 데이터와 오버헤드 사이의 보다 정확한 비율을 계산할 수 있게 되었습니다.

문제 발생

커널 업그레이드 후 수신 윈도우의 초기 크기가 이전보다 작아졌습니다. 초기 scaling_ratio 값이 보수적으로 0.25로 설정되어 있었기 때문에, 전체 수신 가능한 데이터의 양이 감소했습니다. 따라서 TCP 연결을 통해 데이터를 전송하는 데 더 많은 시간이 소요되었습니다. 이 문제는 특히 데이터 볼륨이 크고 네트워크 지연이 큰 환경에서 두드러졌습니다.

해결 방안

최종적으로 scaling_ratio와 함께 window_clamp 값도 업데이트하여 수신 윈도우가 필요에 따라 적절히 확장될 수 있도록 조정하는 것으로 문제를 해결했습니다. window_clamp는 광고될 수 있는 최대 수신 윈도우 크기를 제한하는 변수입니다. 초기 scaling_ratio를 25%에서 50%로 조정하여 이전과 호환되도록 수신 윈도우 크기를 조정했습니다.

이러한 변경은 TCP 네트워크 성능에 중대한 영향을 미치며, 소프트웨어 및 시스템 아키텍처에 대한 깊은 이해를 요구합니다. 이 경우에는 커널의 변경이 예상치 못한 성능 저하를 초래했으며, 세밀한 디버깅을 통해 이를 해결할 수 있었습니다.