사례3건

3건 중 1~3번째

1. IL-0422 eu-iceland1-a 의 VAST 공유 스토리지가 3주 동안 느려지고 끊기며 I/O 오류와 마운트 실패를 냈다

   Crusoe Cloud2025

   증상

   2025년 12월 16일 17:13 UTC 에 Crusoe Cloud 는 eu-iceland1-a 리전에서 Shared Storage 를 쓸 때 느려지는 문제를 조사하기 시작했다. 17:36 UTC 에는 영향 범위가 넓어져, 고객이 Shared Storage 서비스에서 심한 지연과 간헐적인 접근 문제를 겪었다.

   스토리지 연결 끊김처리량 저하

   원인

   unknown

   구성 요소

   공유 네트워크 파일 시스템

   기여 요인

   수동 조치 악화

   조치

   • 12월 16일 18:26 UTC 에 스토리지 성능 문제를 고치는 수정을 적용해 스토리지 지연과 처리량을 정상 수준으로 되돌렸다.
   • 12월 17일에 메타데이터 불일치를 완전히 없애려고 대상을 좁힌 무결성 검증을 돌렸다. 검사하는 동안 스토리지 클러스터를 보호용 유지보수 상태로 두어 데이터가 바뀌지 않도록 접근을 막았다.
   • 무결성 검증의 핵심 단계를 끝낸 뒤 넓게 걸어 둔 보호용 유지보수 제한을 풀어 대부분의 볼륨과 데이터 경로를 되살렸다.
   • 백그라운드 복구 작업을 고객 워크로드와 떼어 놓도록 설정을 바꿨고, 그 뒤 클러스터 성능이 안정되고 간헐적인 연결 흔들림이 줄었다.
   • VAST 와 함께 무결성 검사로 남은 불일치의 범위를 파악했고, 앞서 제한된 데이터에서 검증한 수동 복구 절차를 바탕으로 만든 자동 복구 절차를 돌렸다.
   • 12월 23일에 복구를 빠르게 하는 자동 도구를 담은 VAST 스토리지 소프트웨어 업그레이드를 배포하고, 남은 볼륨의 복구를 다시 이어 갔다.
   • 12월 26일 밤 VM 작업까지 번진 스토리지 네트워크 문제를 풀려고 VAST 가 클러스터를 재부팅했다.
   • 12월 27일에 VAST 가 기존 복구 작업을 더 빠르게 하는 설정 변경을 스토리지 노드에 적용했다. 작업은 약 15분 걸렸다.
   • 12월 28일에 오프라인이 된 스토리지 노드를 되살려 공유 디스크 성능과 VM 작업을 정상으로 되돌렸다.
   • 12월 28일, 30일, 31일과 1월 1일에 VAST 스토리지 소프트웨어를 더 업그레이드했다.

   후속 조치

   • VAST 는 사후 검토를 하고, 수동 단계에 기대지 않도록 자동화와 안전장치를 더해 비슷한 사고의 위험을 줄인다.
   • Crusoe 와 VAST 는 재발을 막으려고 최근 클러스터 안정성 전반을 빠짐없이 검토한다.

   사례 보기
2. IL-0591 Gitpod 워크스페이스가 새 클러스터 세대 배포 뒤 열흘 넘게 모든 리전에서 느려지고 시작 실패와 데이터 유실이 났다

   Gitpod2022

   증상

   2022년 4월 11일 13:17 UTC 에 고객과 Gitpod 직원들이 워크스페이스가 간헐적으로 응답하지 않는다고 알렸다. 4월 8일과 9일에 새 세대 워크스페이스 클러스터 ws39 를 모든 리전에 배포한 직후였다.

   처리량 저하노드 CPU 고부하노드 NotReady데이터 유실

   촉발

   2022년 4월 8일과 9일에 새 세대 워크스페이스 클러스터 ws39 를 모든 리전에 배포한 것이 시작이었다.

   원인

   배포 결함

   구성 요소

   노드 루트 디스크컨테이너 CPU 한도

   기여 요인

   단계적 배포 부재자동 테스트 공백스테이징 불일치한계 미인지장애 중첩롤백 무효수동 조치 악화디버그 접근 제한

   감지

   2022년 4월 11일 13:17 UTC 에 고객과 Gitpod 직원들의 신고로 알았고, incident.io 연동으로 Slack 에 장애를 열었다. 4월 12일에도 고객과 직원의 신고로 알았고, 4월 17일에는 엔지니어들이 워크스페이스 노드의 CPU 부하가 오른 것을 보고 내부 장애를 열었다.

   조치

   • IO 제한 기능이 없어 워크스페이스 시작 트래픽을 이전 세대 클러스터 ws38 로 돌렸고, 4월 11일 15:37 UTC 에 마쳤다.
   • t2d 대신 더 빠른 c2d 머신 유형과 로컬 SSD 를 쓰는 새 클러스터 ws39a 를 만들어 트래픽을 옮겼다.
   • Let's Encrypt 속도 제한 문제를 풀고, Let's Encrypt 에 한도를 올려 달라고 요청했다.
   • ws38 클러스터를 쓸 수 없어 EU XL 트래픽을 임시로 리전 EU 클러스터로 보내 워크스페이스를 다시 시작할 수 있게 했다. 그리고 망가진 ws-eu39xl 을 대신할 ws-eu39bxl 클러스터를 새로 만들었다.
   • stopping 상태에 걸린 워크스페이스를 정리해 사용자가 다시 시작할 수 있게 했다.
   • 4월 8일 배포 전처럼 1TB 부트 디스크를 단 노드로 ws40 을 만들어 디스크 IO 대역폭을 늘렸다.
   • 모니터링으로 노드의 작업을 직접 살펴 과도한 CPU 시간을 쓰는 워크스페이스를 찾아 시스템에서 지웠다.
   • 노드를 손으로 뒤지고 채굴 탐지 시스템을 함께 써서 부정 사용자를 찾아 Gitpod 사용을 막았다.
   • ws38 세대에는 없던 ws-daemon 변경을 되돌려 CPU 제한을 다시 안정시켰고, 이 수정을 ws34 클러스터에 담아 배포했다.
   • 새 ws34 배포에서 워크스페이스 포트로 가는 ACME HTTP 요청을 막아 Let's Encrypt 한도에 다시 걸리지 않게 했다.
   • 워크스페이스 사이에 디스크 IO 를 공정하게 나누는 ws41xl 클러스터와 일반 리전용 ws41 클러스터를 만들어 트래픽을 단계적으로 옮겼다.

   후속 조치

   • 테스트 결과가 진행하면 안 되는 배포를 미리 걸러 내도록 테스트 자동화에 계속 투자한다.
   • 새 클러스터로 트래픽 비율을 옮기는 간격을 배포마다 다르게 하고, 큰 배포일수록 단계 사이를 길게 둔다.
   • 워크스페이스 클러스터 배포에 위험 평가 단계를 넣어 변경 묶음의 크기와 배포 속도를 정하고, 이 단계를 자동화하는 것을 목표로 한다.
   • 팀 사이 의존이 롤백을 막지 않도록 팀끼리 주는 영향을 계속 줄인다.
   • PR 을 머지하기 전에 하위 호환이 깨지는 변경을 찾는 리뷰 기준을 더하고, 그런 PR 은 나눠서 배포를 롤백하기 어려운 상황을 피한다.
   • 장애 완화의 첫 수단으로 롤백을 권하도록 절차를 고쳤고, 이 과정을 자동화하는 방법을 논의한다.
   • 상태 페이지의 워크스페이스 서비스가 장애를 주황이나 빨강으로 제대로 표시하도록 고쳤고, 플레이북도 그에 맞게 고쳤다.
   • 장애 중 내부 소통을 Slack 채널 하나와 Google Meet 하나로 모으고, 장애 절차를 그에 맞게 고쳤다.
   • 당번 체계를 다시 짜서 5월 9일부터 엔지니어링 인력의 10% 가 늘 당번을 맡고, 그 시간으로 관측성과 알림과 시스템 안정성을 개선한다.

   교훈

   4월 11일에 롤백을 결정했다면 가장 좋았다. 롤백하지 않고 수정을 계속 만들어 배포하면서 고객은 필요 이상으로 오래 성능 저하를 겪었고 일부는 데이터를 잃었다. 규모가 크고 바로 앞 배포와 가까운 변경을 너무 빨리 내보냈고, 테스트 결과가 배포를 막았어야 했다. 배포 묶음을 작게 하고 배포를 자주 한다는 원칙을 ws39 에서 지키지 못했고, 팀 사이 의존이 롤백을 어렵게 만들었다. 기여 요인 가운데 일부는 막을 수 있었다.

   사례 보기
3. IL-0280 New Relic US 리전의 여러 NRDB 셀에서 Kafka 브로커가 디스크 부족으로 잇따라 멈춰 고객이 몇 시간 동안 데이터 수집과 알림을 쓸 수 없었다

   New Relic2021

   증상

   한 셀의 Kafka 브로커가 응답하지 않았다. 몇 시간 뒤 여러 셀의 Kafka 브로커 디스크가 차면서 브로커가 하나둘 멈췄고, US 리전의 많은 고객이 데이터 수집과 알림을 쓸 수 없었다.

   노드 디스크 가득 참처리량 저하모니터링 중단

   촉발

   엔지니어가 응답하지 않는 Kafka 브로커를 수동으로 재시작했는데, 같은 시각 자동 복구도 돌아 클러스터가 오래 성능 저하 상태에 머물렀다. 엔지니어는 밀린 데이터를 지키려고 장애 대응 도구로 Kafka 데이터 보존 기간을 크게 늘렸고, 이 변경이 문제가 난 셀뿐 아니라 모든 셀에 적용됐다.

   원인

   운영 실수

   구성 요소

   메시지 브로커

   기여 요인

   수동 조치 악화단계적 배포 부재잡음에 묻힌 신호미검증 가정

   감지

   7월 29일 아침 엔지니어링 팀이 한 셀의 Kafka 브로커가 응답하지 않는 것을 봤다. 나중에 디스크 여유 공간이 줄어들 때 모니터링 시스템이 알림을 보냈지만, 같은 시각 다른 여러 시스템이 관계없는 경고를 내고 있어 엔지니어들은 이 알림을 놓쳤다.

   조치

   • 엔지니어링 팀이 응답하지 않는 Kafka 브로커를 수동으로 재시작했다. 같은 시각 자동 복구도 돌았고, 두 작업 모두 결국 무사히 끝났다.
   • 브로커의 디스크 공간 문제를 해결했다. 그 뒤에도 Kafka 문제가 여러 셀에 넓게 퍼져 있어 서비스 복구에 시간이 걸렸다.

   교훈

   셀 격리는 넓은 장애를 막는 가장 강한 보호 수단이다. 평소 운영뿐 아니라 긴급 도구도 이 격리를 지켜야 한다. 긴급 대응 도구는 혼란스러운 상황에서도 안전하게 쓸 수 있어야 하고, 그러면서도 필요한 기능은 빠짐없이 갖춰야 한다. 사람의 주의력은 한정되어 있으므로 장애 대응 절차와 알림을 계속 다시 따져 엔지니어의 주의가 가장 급한 신호로 가게 해야 한다.

   사례 보기

원인별3