사례2건

2건 중 1~2번째

1. IL-0117 인그레스 업그레이드가 네트워크 컨트롤 플레인 회귀를 일으켜 데이터 플레인이 잠깐 끊겼고, 한꺼번에 재시작한 서비스들이 백엔드 저장소에 과부하를 일으켜 OpenAI API 오류가 늘었다

   OpenAI2024

   증상

   2024년 8월 16일 태평양 시간 오전 11시 38분부터 오후 1시 16분까지 OpenAI 기본 API 의 안정성이 크게 떨어졌다. ChatGPT 대화의 성공률이 낮아졌고 로그인과 계정 생성도 영향을 받았다. 장애는 두 번에 걸쳐 일어났고, 각각 44분과 15분 동안 이어졌다.

   오류율 상승데이터베이스 과부하

   촉발

   예정된 유지 보수와 함께 OpenAI 의 사용자 요청을 받는 클러스터에서 인그레스를 업그레이드했다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   인그레스 컨트롤러애플리케이션 데이터베이스

   기여 요인

   단계적 배포 부재자동화 증폭

   후속 조치

   • 네트워크 컨트롤 플레인 회귀를 완화했고, 컨트롤 플레인을 재시작해도 클러스터의 데이터 플레인에 영향이 없음을 확인했다.
   • 서비스 시작 시간을 줄이고 초기화 쿼리를 없애는 소프트웨어 변경을 넣어, 저장 계층의 부담을 덜고 서비스 시작과 재시작을 빠르게 했다.
   • 네트워크 컨트롤 플레인이 클러스터의 트래픽 처리 능력에 주는 영향을 줄이는 설정 변경을 배포했다.
   • 중요한 시작 경로에서 비용이 큰 데이터베이스 쿼리를 뺐다.
   • 네트워크 컨트롤 플레인 관련 문제를 잡는 모니터링과 알림을 추가했다.
   • 인프라 변경에 단계적 롤아웃과 더 긴 관찰 기간을 도입해, 회귀를 최대한 일찍 잡고 영향을 받는 시스템과 사용자를 줄인다.
   • 서비스 시작 시간에 영향을 줄 수 있는 다른 느린 쿼리가 있는지 시스템을 점검한다.

   교훈

   짧은 연결 끊김이 긴 장애로 번진 것은 복구 자체가 무거웠기 때문이었다. 다시 뜨는 서비스들이 무거운 초기화 쿼리로 백엔드 저장소 하나에 과부하를 주었다. 시작 경로에서 비용이 큰 쿼리를 빼면 복구가 짧아진다. 인프라 변경을 단계적으로 내보내고 관찰 기간을 길게 두면 회귀가 잡히기 전에 영향을 받는 시스템 수를 줄일 수 있다.

   사례 보기
2. IL-0177 다른 팀의 설정 배포로 공유 L7 HAProxy 가 재로드될 때마다 messaging-hub 의 웹소켓 연결이 한꺼번에 끊겼다.

   LINE+2022

   증상

   LINE 의 messaging-hub 는 일본 음식 배달 서비스 Demaecan 의 Merchant 앱과 Driver 앱에 웹소켓으로 메시지를 보낸다. 어느 날 최대 트래픽 시간이 아닌데도 웹소켓 연결 수 그래프가 순간적으로 크게 떨어졌다. 이 현상은 한 번으로 끝나지 않고 불규칙하게 계속 일어났다.

   연결 리셋데이터베이스 과부하간헐적 연결 실패지연 시간 증가

   촉발

   같은 L7 로드밸런서를 공유하는 다른 서비스 담당자가 자기 LB 설정을 배포하면 HAProxy 가 재로드됐다. hard-stop-after 로 정한 30분이 지나 이전 프로세스가 종료되면서 거기 붙어 있던 웹소켓 연결이 모두 끊겼다.

   원인

   설정 변경

   구성 요소

   HAProxy클라우드 로드 밸런서conntrack 테이블인그레스 컨트롤러

   기여 요인

   늦게 드러난 변경과도한 영향 범위재시도 폭주미검증 가정

   감지

   웹소켓 연결 수 그래프에서 최대 트래픽 시간이 아닌데도 연결 수가 순간적으로 뚝 떨어지는 것을 보고 알았다. Nginx 패킷 드롭은 네트워크 모니터링으로 원인을 찾았다.

   조치

   • Merchant 팀이 토큰 발급 API 를 따로 떼어 배포해 토큰 요청이 몰려도 다른 Merchant API 가 지연되지 않게 했다.
   • Nginx 를 늘리고 파드 안티 어피니티와 레이블 셀렉터로 Nginx 파드가 서로 다른 노드에 뜨게 해서 NF_CONNTRACK 테이블 포화로 생기던 패킷 드롭을 없앴다.
   • Ingress Nginx 의 proxy-read-timeout 과 proxy-send-timeout 을 300s 에서 3600s 로, LB timeout 도 3600s 로 올렸지만 웹소켓 드롭은 멈추지 않았다.
   • 공유하던 L7 LB 를 L4 LB 로 바꿔 웹소켓 드롭을 없앴다.

   교훈

   문제의 범위를 미리 단정해 스스로 제한하면 안 된다. 인프라 팀과 네트워크 팀이 문제없다고 답했다는 이유로 직접 다룰 수 있는 영역만 뒤지다가 공유 L7 LB 를 늦게 의심했다. LB 같은 기술 리소스를 다른 서비스와 공유하면 다른 팀의 배포가 내 서비스의 연결을 끊을 수 있다. Nginx 를 늘려 NF_CONNTRACK 부담을 나눌 때는 파드가 서로 다른 노드에 뜨게 해야 하고, 노드 수보다 많이 늘리면 Pending 상태로 남는 파드가 생긴다는 점도 알아야 한다.

   사례 보기

원인별2