IL-0084 Namespace · 2024-10-22kubernetesnetworking
Namespace 는 자체 관리하는 베어메탈 머신에 고객 워크로드를 올린다. 자체 하드웨어로 옮기는 중에도 기존 베어메탈 업체의 용량을 함께 쓰고 있었다. 3분기 말부터 성장이 계획을 앞질렀고, 10월 15일까지 유럽 리전 하나에 들어올 증설 장비가 공급사의 DIMM 주문 실수로 3주에서 4주 늦어졌다. 그 틈을 메우려고 기존 베어메탈 업체에 추가 용량을 주문했다.
이 업체에서는 머신들을 같은 L2 세그먼트로 묶으려고 vSwitch 기능을 썼다. 10월 17일부터 vSwitch 를 지나는 패킷이 무작위로 버려졌다. 업체는 문제를 확인했지만 빨리 해결하지 않았다. 10월 21일에는 패킷 드롭으로 고객 잡이 실패했다. Namespace 는 vSwitch 를 쓰지 않도록 네트워크 구성을 통째로 바꾸기로 했다. 업체의 물리 머신 하나하나를 Wireguard 로 가까운 자체 클러스터에 연결하는 방식이다. 이 머신들이 피크 용량을 맡고 있었으므로 고객 영향을 피할 수 없었다.
10월 22일 09:30 CET 에 fra3 를 zrh1 에 연결하는 형태로 다시 구축하기 시작했다. 12:00 부터 영향받는 리전의 고객 트래픽을 다른 리전으로 돌리자 전 세계 용량이 모자라 그동안 잡을 돌린 모든 고객의 대기 시간이 늘었다. 불변 인프라 방식이라 머신마다 새 신원, 새 인증서, 새 저장 데이터 암호화 키를 받도록 다시 깔아야 했다. 캐시를 다른 리전으로 옮기면 복구가 늦어지므로 캐시를 버렸다. 고객 이미지를 많은 머신에 한꺼번에 나눠 주느라 속도가 더 떨어졌고, 팀 일부가 데이터셋을 더 분산된 방식으로 복제해 작업을 앞당겼다. 18:30 에 70% 가 끝나 대기 시간이 회복되기 시작했고, 20:30 에 대부분이 끝났다.
10월 23일에는 컨트롤 플레인 노드 하나가 느린 NVMe 쓰기 때문에 부분적으로 실패했다. 사용량이 늘면서 쿠버네티스의 변경 속도가 그 노드의 I/O 한계를 넘었다. API 서버는 재시도가 늘며 CPU 사용량이 매우 높아졌다. 이 노드는 다른 리전과 달리 오래된 머신 유형이어서 문제가 더 커졌다. 팀은 이 노드의 핵심 상태를 더 큰 노드로 복제해 같은 IP 주소로 역할을 넘겼다. 쌓인 변경을 처리하고 나자 클러스터가 정상으로 돌아왔고, 각 kubelet 은 아무 일 없던 것처럼 다시 연결됐다. 두 번째 장애는 약 50분 이어졌다.
10월 17일부터 fra3 리전에서 패킷이 드문드문 버려지기 시작했다. 처음 이틀은 TCP 와 QUIC 의 재전송이나 컨트롤 플레인의 재시도로 대부분 넘어갔지만, 시스템이 조금씩 불안정했다. 이런 실패는 비결정적이라 겉으로 잘 드러나지 않았다.
영향은 SLO 기반 모니터링에서 먼저 보였다. 주요 상호작용의 백분위 지연 목표를 잡아 두었는데, SLO 에러 버짓이 줄어들기 시작했다. 드롭은 주말로 갈수록 늘었지만 주말 트래픽이 적어 영향이 덜했다. 월요일인 10월 21일에 SLO 가 크게 떨어졌고, 패킷 드롭 때문에 고객 잡이 실패하기 시작했다.
10월 22일 12:00 CET 에 fra3 를 다시 구축하느라 서비스에서 빼자 전 세계 용량이 모자랐다. linux/arm64 부터 부족해졌고, 16:00 에는 전체 플릿에서 대기 시간이 길어졌으며 일부 원격 빌드가 용량 부족으로 실패했다.
10월 23일 20:10 CET 에 zrh1 의 성능이 떨어지기 시작했다. 20:14 에 zrh1 의 핵심 구성 요소가 실패해 zrh1 로 가는 워크로드가 시작되지 못했다. 컨트롤 플레인 노드 하나에서 느린 NVMe 쓰기로 I/O 가 밀렸고, 쿠버네티스 API 서버의 CPU 사용량이 재시도 증가로 매우 높아졌다. 직전 장애가 네트워크 문제였기 때문에 팀은 처음에 같은 종류의 문제부터 찾았지만, 이번 원인은 전혀 다른 종류였다.
원인 ? 클라우드 제공자 장애
패킷 드롭은 비결정적이라 바로 보이지 않았다. 주요 상호작용에 잡아 둔 백분위 지연 SLO 의 에러 버짓이 줄어드는 것을 보고 영향을 알아챘다.
비결정적인 네트워크 드롭은 재시도에 가려져서 SLO 기반 모니터링으로 긴 시간을 봐야 영향이 드러난다. 핵심 인프라의 문제를 직접 고칠 수단을 갖고 있어야 한다. 큰 장애 직후에는 같은 종류의 원인에 매이기 쉽다. 이번 두 번째 장애는 전혀 다른 종류였다. 미리 해 둔 모의 위기 훈련 덕분에 대응을 바로 체계적으로 시작할 수 있었다.
–