IL-0170 Backpackr · 2025-05-08 (게시일)kubernetesawsnetworking
백패커는 아이디어스와 텀블벅을 Amazon EKS 에서 운영한다. 클러스터 바깥과 안쪽의 트래픽이 모두 istio 전용 노드의 ingressGateway 를 거쳤고, 서비스가 커지고 도메인이 나뉠수록 이 노드가 맡는 몫이 커졌다.
2024년 1월 설날 이벤트 때 트래픽이 평소보다 3배 넘게 늘었다. nf_conntrack 은 네트워크 연결을 기록하고 추적하는 리눅스 커널 모듈로, 컨테이너 환경에서는 NAT 와 포트 포워딩 때문에 켜져 있다. 연결 기록 테이블의 기본 크기는 65536 이고, 이를 넘으면 새로 들어오는 패킷이 버려진다. istio 노드의 nf_conntrack 테이블이 가득 차면서 패킷이 버려졌고, ingressGateway 가 응답하지 못해 웹과 앱 서비스 전체가 멈췄다. istio 노드의 네트워크 성능도 한계에 다다라 있었다.
백패커는 이벤트를 중단했다. 장애 뒤에는 모든 노드의 nf_conntrack_max 를 올리고, 사이드카끼리 ingressGateway 를 거치지 않고 통신하도록 메시 네트워크를 설정했다. 또 istio 노드를 대역폭이 큰 인스턴스로 바꾸고, 네트워크와 istio 지표 모니터링을 늘렸다.
2024년 1월 설날 이벤트 중에 개발자 한 명이 Slack 에 장애가 의심된다고 알렸다. 여러 사람이 상황을 확인하는 사이에 웹과 앱 서비스 전체가 멈췄고, 백패커는 이벤트를 중단하기로 했다.
트래픽은 평소보다 3배 넘게 늘었다. 외부와 내부 트래픽이 모두 istio 노드의 ingressGateway 하나를 거치는 구조였기 때문에 부하가 그 노드에 몰렸다. istio 노드의 nf_conntrack 테이블이 100% 차서 이후 들어오는 패킷이 버려졌고, ingressGateway 가 응답하지 못했다.
istio 노드는 네트워크 성능도 한계에 다다라 있었다. 노드는 c6.xlarge 인스턴스였고 네트워크 대역폭은 12.5Gbps 였다.
증상 ? 서비스 중단
개발자 한 명이 Slack 에 장애가 의심된다고 제보했다. 여러 사람이 확인하는 동안 장애가 웹과 앱 서비스 전체로 번졌다.
모든 트래픽이 노드 하나의 ingressGateway 를 거치면 그 노드가 단일 장애점이 된다. nf_conntrack 테이블은 기본 크기로 두면 트래픽이 갑자기 몇 배로 늘 때 가득 차고, 그 순간부터 패킷이 버려진다. 게이트웨이 노드는 일반 노드보다 conntrack 한도와 네트워크 대역폭을 넉넉하게 잡고, 네트워크 대역폭과 패킷 드롭 지표를 따로 지켜봐야 한다.
같은 원인 · 공통 인그레스 컨트롤러
같은 원인 · 공통 conntrack 테이블
같은 원인 · 공통 인그레스 컨트롤러