컨테이너 이미지 하나 올리는데 자꾸 몇 분씩 걸렸다. 새 레이어가 100MB쯤이긴 했는데, 기가 회선 쓰는 집에서 이 정도로 굼뜰 일인가 싶더라. 하필 apt update, apt upgrade까지 같이 답답해서 처음엔 배포 스크립트나 레지스트리 쪽을 먼저 의심했다.
더 헷갈렸던 건, 느린 게 그냥 체감이 아니라 로그에도 너무 노골적으로 보였다는 점이다. 스모크 테스트 지나고 푸시 단계에서 한참 멈춰 있었고, 한 레이어만 오래 붙잡고 있었다. 100MB 레이어가 매번 새로 올라가는 구조인 건 맞았다. 그런데 그래도 몇 분은 좀 이상했다. 이쯤 되면 이미지 구조만 탓하기엔 뭔가 안 맞는다 싶었다.
100MB가 몇 분 걸리길래
처음엔 레이어 크기부터 봤다. 실제로 런타임 이미지 안에서 .next/standalone이 꽤 컸고, 그 안에 node_modules가 100MB 가까이 들어 있었다. 그러니까 배포할 때마다 가변 레이어 하나가 크게 다시 올라가는 그림 자체는 맞았다.
그런데 문제는 숫자였다. 100MB 업로드가 몇 분씩 걸린다? 기가 환경이면 납득이 잘 안 된다. 여기서 내가 첫 번째로 틀렸다. 이미지가 크니까 느린 거라고 반쯤 결론내리고 들어갔는데, 그건 현상 설명은 돼도 속도 자체를 설명하진 못했다.
게다가 스모크 테스트 로그에 연결이 한 번 끊긴 흔적도 보여서, 잠깐 컨테이너 기동 쪽도 의심했다. 근데 그건 중간 재시도 흔적일 뿐이었고, 실제 서비스는 바로 올라왔다. 옆길로 좀 샜다.
스위치 설정 탓으로 몰아갔다
다음으로는 물리 장비를 의심했다. 관리형 스위치가 있었고, 예전에 건드렸던 설정도 조금 떠올라서 괜히 그쪽을 뒤졌다. 포트 속도 강제 설정이 있나 보고, Loop Prevention 같은 항목도 봤다. 문구만 보면 뭔가 큰일 날 것 같아서, 이게 속도를 떨군 건가 싶었다.
근데 이쪽은 결국 헛발이었다. Loop Prevention은 루프 감지하면 포트를 막았다가 다시 여는 쪽이지, 링크를 10Mbps로 협상시키는 기능은 아니었다. 더 웃긴 건 한참 뒤에야 서버가 그 스위치가 아니라 공유기에 직접 물려 있다는 걸 다시 확인했다는 거다. 물리 구성을 정확히 안 보고 장비 설정부터 의심한 거였다. 결국 문서 안 읽고 삽질한 거랑 비슷한 류다.
OS를 의심했는데 링크가 10M였다
그래서 진짜로 OS 단 제한인지 보기 시작했다. 이때부터는 감보다 숫자 위주로 갔다.
먼저 봤던 건 이거였다.
ethtool enp3s0
cat /sys/class/net/enp3s0/speed
fast --upload문제 있을 때 출력은 거의 이렇게 나왔다.
Speed: 10Mb/s
Duplex: Full
Auto-negotiation: on
Link partner advertised link modes: 10baseT/Half 10baseT/Full
10
-> 8.90 Mbps이쯤 되니까 그림이 너무 단순해졌다. fast가 느리게 나온 게 문제가 아니라, 애초에 NIC가 10Mb/s로 붙어 있었다. 업로드 8.9Mbps는 링크 한계에 거의 딱 맞는 숫자였다.
그래도 찜찜해서 몇 개를 더 봤다. tc qdisc는 기본 fq_codel이었고, sysctl 쪽도 특별한 셰이핑 흔적은 없었다. 드라이버는 tg3였고, EEE 상태도 애매하게 속도를 누르는 그림은 아니었다. 인터페이스 에러 카운터도 완전 깨끗하진 않았지만, OS가 트래픽을 인위적으로 8Mbps대로 잘라버리는 설정은 안 보였다. 커널 로그에도 링크가 오락가락한 흔적이 있었는데, 이런 건 소프트웨어 제한보다는 물리 계층 쪽 냄새가 훨씬 진하다.
여기서 또 하나 결정적인 힌트가 나왔다. 같은 회선에 붙은 윈도우 PC로 속도 측정을 해보니 다운로드는 거의 1Gbps, 업로드도 400Mbps 넘게 나왔다. 같은 공인 IP를 타고 있는데 다른 PC는 멀쩡했다. 그 순간 회선, ISP, 비대칭 이런 쪽 의심은 거의 접었다. 남는 건 서버와 공유기 사이 링크뿐이었다.
그제야 랜선이 수상해졌다
이상한 건, 랜선도 그대로 쓰던 거였고 체결도 멀쩡해 보였다는 점이다. 눈으로 봐선 멀쩡한데 갑자기 이러니까 자꾸 OS 쪽을 의심하게 된다. 근데 이더넷은 그런 식으로 사람을 속이더라.
기가비트는 4쌍 8가닥을 다 제대로 써야 한다. 선 하나가 완전히 끊어지지 않아도, 접점이 애매하거나 내부가 눌리거나 열화되면 고속 협상이 실패하고 100Mbps, 심하면 10Mbps까지 내려가 붙는다. 그러니까 랜선이 느려진다가 아니라, 고속 링크를 유지 못해서 낮은 모드로 재협상되는 거다. 이 차이를 그때 좀 늦게 이해했다.
새 랜선 꽂자 너무 허무하게 끝났다
랜선을 새 걸로 바꾸고, 한 번은 스위치 경유로, 한 번은 다시 공유기 직결로 붙여봤다. 결과가 너무 깔끔하게 나왔다.
fast --upload
-> 834.99 Mbps스위치를 빼고 다시 공유기 직결로 바꾼 뒤에도 비슷했다.
-> 828.10 Mbps이쯤 되면 공유기 설정 문제도 아니고, OS 제한도 아니고, 기존 랜선 쪽이 가장 자연스럽다. 같은 서버, 같은 회선, 같은 공유기인데 랜선만 바꾸고 8.9Mbps에서 800Mbps대로 튀어 오르면 더 설명할 게 없다. 허무하긴 한데, 이런 허무한 원인이 제일 사람 진 빠지게 한다.
생각해보니 다운로드랑 업로드가 같이 죽었던 것도 딱 맞아떨어졌다. 처음엔 업로드만 느린 줄 알고 비대칭 회선 비슷한 걸 떠올렸는데, 둘 다 같이 낮아졌다면 제일 먼저 링크 속도 강등을 봤어야 했다. 그 판단이 늦었다.
이후로 비슷한 증상이 나오면 제일 먼저 이 두 줄부터 볼 생각이다.
ethtool enp3s0 | rg 'Speed|Duplex|Link detected'
cat /sys/class/net/enp3s0/speed여기서 10Mb/s가 보이면, 이제는 OS 튜닝이나 레지스트리 속도부터 의심 안 한다. 랜선, 포트, 단자부터 본다. 겉보기엔 멀쩡한데 속도를 반토막도 아니고 1/100로 만들어버리는 게 생각보다 흔하더라. 이번에 안 건, 느린 배포보다 그런 애매한 고장이 더 사람 헷갈리게 만든다는 거였다.
