사례2건

2건 중 1~2번째

1. IL-0509 DDoS 뒤 상위 망의 null route 로 SourceHut 의 PHL 데이터센터 망이 끊겨 170시간 동안 장애가 이어졌다

   SourceHut2024

   증상

   2024년 1월 10일 06:00 UTC 무렵 모니터링 시스템이 SourceHut 의 PHL 인프라에 이상이 있다고 경보를 울렸다. 09:00 UTC 무렵에는 PHL 망에 아예 닿을 수 없게 됐다.

   네트워크 도달 불가서비스 중단

   촉발

   2024년 1월 10일 06:00 UTC 무렵 SourceHut 의 PHL 인프라를 노린 layer 3 DDoS 가 시작됐다. 상위 망인 Cogent 가 이에 대응해 SourceHut 의 하위 AS 에 null route 를 걸었다.

   원인

   의존성 장애

   구성 요소

   ISP·트랜짓 망BGP 라우팅

   기여 요인

   단일 장애점디버그 접근 제한미검증 백업

   감지

   06:00 UTC 무렵 모니터링 시스템이 이상을 알아채 경보를 울렸고, 운영팀은 곧 조사를 시작했다.

   조치

   • 코로케이션 사업자가 Cogent 를 설득해 null route 를 /24 전체에서 DDoS 가 노리던 IP 주소 하나인 /32 로 좁혔다.
   • 외부 DNS 로 옮겼다.
   • 새 주 데이터베이스를 띄웠다.
   • FRE 의 백업을 AMS 로 복원했다.
   • 운영 데이터와 마지막 백업 사이의 차이를 손으로 반영했다.
   • 새 메일 시스템을 갖추고 메일 서비스를 그 시스템에 맞게 설정했다.
   • OVH 서버를 두고 트래픽을 OVH 의 DDoS 방어 망을 거쳐 AMS 의 비공개 운영 서브넷으로 NAT 했다. 이 방식으로 종단 간 암호화를 지키면서 임의의 TCP 프로토콜도 서비스했다.
   • 1월 12일 PHL 망 사업자가 임시 서브넷을 내줘 PHL 서버에 대역 외로 접근했고, 이것으로 대체 인프라를 더 빨리 갖췄다.
   • PHL 에서 AMS 로 객체 저장소를 옮기는 동안 pages.sr.ht 를 PHL 로 가는 대역 외 링크로 서비스했다. 성능에는 제약이 있었다.
   • pages.sr.ht 가 새 서브넷과 IP 주소로 옮겨 가면서, apex 레코드가 PHL 서브넷을 직접 가리키던 사용자에게 손으로 고치는 방법을 메일로 보냈다.
   • AMS 의 연산 용량이 모자라 builds.sr.ht 의 빌드 워커를 OVH 의 전용 베어메탈 서버에서 돌렸다.

   후속 조치

   • 새 대기 데이터베이스를 갖춘다. 사고 뒤 작업 가운데 이미 끝난 일이다.
   • AMS 에서 FRE 로 백업을 받도록 설정한다. 이미 끝난 일이다.
   • 새 모니터링 시스템을 설치한다. 진행 중인 일이다.
   • PHL 데이터센터의 설비를 완전히 정리하고, PHL 의 서버를 포장해 AMS 로 보내 용량을 보탠다.
   • 몇 주 안에 빌드용 연산 서버를 PHL 에서 AMS 로 옮긴 뒤 빌드 서비스를 SourceHut 이 운영하는 인프라로 되돌린다.
   • SourceHut 을 온프레미스 쿠버네티스 클러스터에서 돌리는 방법을 연구해 구현한다. 내부 유지 보수 때 사용자가 겪는 중단을 줄이고 이런 사고에 더 잘 견디려는 것이다.
   • 그 작업이 끝나면 두 번째 운영 데이터센터를 계획한다. 두 데이터센터가 함께 부하를 나누고, 한 데이터센터에 장애가 나면 다른 쪽이 전체 서비스를 넘겨받게 한다.

   교훈

   SourceHut 은 데이터센터 전체 장애까지 대비해 둔 운영 계획이 이번 대응에 중요했다고 적었다. 이번 사고는 SourceHut 이 이중화와 복원력 목표를 다 이루기 전에, 알고 고치던 약점을 드러냈다. pages.sr.ht 의 S3 호환 객체 저장소가 오프사이트 백업에 들어 있지 않다는 것도 이번에 알았다. SourceHut 은 이번 일로 비상 절차를 실제로 시험해 볼 수 있었고, 안정성을 더 높일 방법을 많이 배웠다고 적었다. 긴급 이전으로 EU 로 옮기려던 장기 목표 상당수를 빨리 이뤘다.

   사례 보기
2. IL-0508 SourceHut 의 주 데이터베이스 서버 remilia.sr.ht 가 하드웨어 고장으로 연결이 끊겨 모든 서비스가 중단됐다

   SourceHut2023

   증상

   13:40 UTC 무렵 SourceHut 서비스 대부분을 사용할 수 없다는 경보가 한꺼번에 울렸다. 그 가운데 하나는 주 데이터베이스 서버인 물리 호스트 remilia.sr.ht 를 사용할 수 없다는 경보였다.

   서비스 중단

   촉발

   주 데이터베이스 서버 remilia.sr.ht 의 하드웨어가 고장 났다.

   원인

   하드웨어 고장

   구성 요소

   데이터베이스

   기여 요인

   단일 장애점디버그 접근 제한

   감지

   13:38 에 Prometheus 가 remilia 의 지표 수집에 실패했고, 13:40 무렵 대부분의 서비스와 remilia.sr.ht 를 사용할 수 없다는 경보가 울렸다.

   조치

   • 데이터센터 직원에게 연락이 닿지 않아 데이터센터 근처의 비상 연락 담당자를 불렀고, 담당자가 데이터센터로 출발했다.
   • 현장에 도착한 비상 연락 담당자가 데이터센터 직원의 진단을 확인한 뒤 디스크를 cirno1.sr.ht 와 바꿔 끼우고 서버를 띄웠다.

   후속 조치

   • 오프사이트 데이터베이스 백업이 장애 조치용 데이터베이스 호스트로도 쓰일 수 있게 고친다. 이 일은 이미 끝났다.
   • EU 이전 작업 전체의 우선순위를 다시 높인다.
   • 새 데이터베이스 장애 조치 구성을 만든다.
   • 빌드 용량을 메우려고 EU 에 새 빌드 워커를 둔다.
   • 앞으로를 대비해 하드웨어 목록을 더 꼼꼼히 기록한다.

   사례 보기

원인별2