최근 Docker 사용 시, 특정 상황에서 요청이 Timeout 이 나는 경우가 발생 하였다.
증상을 정리해 보면 아래와 같다
- 간단한 요청을 보내면 응답이 온다(404 오류 등)
- 응답 사이즈가 큰 요청을 보내면 응답이 오지 않는다
- 간헐적으로 응답이 올 때도 있다
- 서버에선 Response 완료후 처리하는 Handler 가 작동 하지 않는다
이 상황을 이해할 수 없어 네트워크 구성을 엄청나게 바꿔 보았다. 위 내용으로 검색하였을때 얻을 수 있는 정보가 거의없었기도 하고, 서비스 구성을 위해 로드밸런싱을 구성 한 다음부터 이슈가 발생 하였기 떄문에 Load Balancer 의 문제라고 생각 하고 있었다.
회사에 남아 있는 문서와 삽질, 그리고 여러 분들의 서포트로 해답을 찾았는데… 정답은 Docker 의 MTU 사이즈 문제였다.
Docker 의 경우 설치시 기본적으로 Bridge Network 의 MTU 를 1500으로 세팅 하는데, Load Balancer 가 들어가면서 통신 중간에 MTU 사이즈가 1500이 안되는 장비가 끼어 들어가게 되었고, 이후 통신에 문제가 생긴 것.
LB 쪽만 열심히 분석하고 있을때는, 자료를 전혀 얻을 수 없었는데 키워드를 얻고 다시 구글링을 해 보니 엄청난 양의 문서를 찾을 수 있었다. 클라우드나 VM 에서 Docker 를 사용 할 때는 환경 구성상 1500 보다 낮은 값으로 통신을 해야 하는 경우가 많은데, Docker 가 무조건 1500으로 잡아서 문제가 생긴 것.
나의 경우는 사내 인프라의 가이드를 받아 1480 으로 세팅 해서 문제가 해결되었는데… 이후 다시 자료를 찾아보니 1400, 1450 등 여러가지가 있었다. GCP는 1460나 1390, Azure는 1500, AWS 는 상황마다 다른데 1300과 1500 둘 중 하나를 사용하게 되는 것 같다. 점보프레임 지원을 제외 할 경우에 말이다.
문제는… 왜인지 모르겠지만 Docker 의 경우 MTU 가 넘는 패킷이 정상적으로 분할되어 처리되지 않았다. 아마 DF Flag가 켜져있거나, 단순히 vxlan 이 지원 안하는거일수도.. 아무튼 이건 나중에 다시 조사해 보려 한다.
MSS clamping 도 제대로 처리되지 않았는데, 이건 NIC 이 여러개 일때 발생하는 현상이라고 설명 된 자료가 있었다. NIC 이 여러개여서 MSS Clamping 한쪽에만 영향을 미쳐, 다른쪽 NIC 는 다른 사이즈로 나가는 케이스의 경우 피지컬 서버에서도 발생할 수 있다는 얘기가 있다.
그래서 Docker 를 사용할 경우, 반드시 MTU 사이즈를 확인하고 조절 하는 작업이 필요 하겠다.
사실 나는 동일한 네트워크 구성을 이미 많이 사용하였었기에, 그동안 같은 구성에 문제가 없었어서 상당히 당황했었는데, 원인을 파악 한 후 다시한번 생각을 정리 해보니 나는 그동안 피지컬 서버와, Azure / AWS 의 VM 만을 써 왔다.
당연하면 당연하게도 클라우드 업체에서 제공하는 Repository 의 Docker Package는 클라우드 업체가 자신들 구성에 맞춰 이미 세팅을 다 해놓은 상태였던 거다.
Docker MTU 라는 키워드를 얻고난 후, 자체 Repository를 제공하지 않는 소규모 VM 업체의 메뉴얼들을 뒤져보니 Docker 를 쓸때 MTU 사이즈를 반드시 얼마로 세팅하라는 경고문구가 붙어 있더라…