2026년 8월 27일 새벽, Proton에 다수의 사용자 서비스에 영향을 미친 광범위한 장애가 발생했습니다. 근본적인 원인은 프랑크푸르트 데이터 센터의 냉각 시스템 전면 고장이었습니다. Proton의 모든 시스템은 이중화되어 있으며 데이터 센터 전체 장애를 견딜 수 있는 충분한 용량을 보유하고 있지만, 페일오버에 더 오랜 시간이 걸려 사용자 서비스 중단으로 이어질 수 있는 몇 가지 예외적인 시나리오가 있습니다.
이번 장애 발생 당시의 상황과 대응 과정에서 내린 결정 및 그 이유, 그리고 문제가 어떻게 해결되었는지에 대한 타임라인을 공유합니다.
타임라인
8월 26일 수요일 오후 11시(중부 유럽 표준시) 직후, 프랑크푸르트 데이터 센터의 메인 룸에서 냉각 시스템 고장이 발생했습니다. 오후 11시 15분경 온도가 상승하기 시작하여 30분도 채 되지 않아 약 21.8°C(정상 작동 온도)에서 51.9°C까지 치솟았으며, 일부 측정 프로브에서는 실내 공기 온도가 60°C에 달한다고 보고했습니다. 온도가 상승함에 따라 시설 내 서버 및 네트워크 장비가 하나둘씩 작동을 멈추기 시작했습니다.
사용자 서비스 장애는 8월 27일 자정 무렵, 장애가 확대되어 핵심 이중화가 상실되면서 시작되었습니다. 이는 핵심 랙의 기본 및 백업 네트워크 스위치가 모두 고장 나면서 발생했으며, 안타깝게도 이 랙에는 여러 기본 데이터베이스 복사본이 포함되어 있었습니다. 거의 모든 Proton 시스템은 이중화되어 있어 자동으로 즉시 페일오버되지만, 기본 데이터베이스의 페일오버는 엔지니어의 감독 없이 자동으로 수행되지 않습니다.
이러한 제어를 유지하는 이유는 이른바 ‘스플릿 브레인(split brain)’ 상황을 방지하기 위함입니다. 스플릿 브레인은 기본 데이터베이스의 일시적인 사용 불가로 인해 복제본이 일부 업데이트를 놓치고 동기화가 어긋나 나중에 조정하기 어려워지는 현상을 의미합니다. 또한 기본 데이터베이스 페일오버가 발생할 경우 지연 시간과 성능상의 이유로 동일한 데이터 센터 내의 복제본으로 페일오버하는 것이 표준 운영 절차입니다. 그러나 이번 문제의 특성상 동일 데이터 센터 내 복제본 역시 다운될 가능성이 있어, 이는 바람직하지 않은 선택이 될 수 있었습니다.
결정 사항
이 시점에서 Proton의 온콜 엔지니어들은 극심한 압박 속에서 중대한 몇 가지 결정을 내려야 했습니다.
- 서비스를 다시 온라인 상태로 복구하는 것을 우선시할 것인가, 아니면 냉각 문제를 해결하고 데이터 센터 내부의 하드웨어를 보호하는 것을 우선시할 것인가?
- 동일한 프랑크푸르트 건물 내 복제본으로 페일오버할 것인가(더 빠르고 중단이 적지만 과열 문제를 해결하지 못할 경우 임시방편에 불과함), 아니면 취리히로 페일오버할 것인가?
- 모든 것을 페일오버할 것인가, 아니면 현재 중단된 시스템만 페일오버할 것인가? 완전한 데이터 센터 장애에 대비해 시스템이 대부분 자동으로 신속하게 전체 페일오버되는 비상 대책이 마련되어 있지만, 무작위로 서버가 하나씩 다운되는 상황은 기존 페일오버 로직으로 원활하게 처리하기 어렵습니다.
결국 급격한 온도 상승 속도로 인해 서비스를 다시 온라인으로 복구하는 것보다 하드웨어를 보호하는 것을 우선시할 수밖에 없었습니다. 냉각 시스템은 일반적으로 이중화되어 있고 냉각이 완전히 중단되는 일은 매우 드물기 때문에 온도가 위험 수준에 도달하기까지 충분한 시간이 확보되므로, 평소에는 이러한 선택을 할 필요가 없습니다. 하지만 최근 AI용 고전력 CPU 및 GPU 도입으로 서버 전력 밀도가 크게 증가하면서 문제가 더욱 악화되었습니다. 그 결과, 과거에는 위험 수준에 도달하기까지 3~4시간이 걸리던 것이 불과 20분 만에 위험 수준에 도달했습니다.
따라서 온콜 팀은 하드웨어를 보호하기 위해 가능한 한 많은 서버의 전원을 끄는 동시에 현장 데이터 센터 운영팀과 소통하여 냉각을 복원하는 데 집중했습니다. 지속되는 AI 붐과 관련된 서버 장비 부족으로 인해 이러한 장비 중 상당수는 손실될 경우 단기간에 교체하는 것이 불가능했습니다. 서비스 중단 시간이 더 길어질 수 있는 위험을 감수하더라도 장비를 보호하는 것이 최우선 과제였습니다.
00:45 CEST경 냉각을 복원할 수 있었고 시설 온도가 떨어지기 시작하자, 온콜 팀은 서비스 복구로 초점을 전환했습니다. 이 시점에서 트래픽 흐름을 지나치게 변경하여 새로운 불안정성이 발생하는 것을 방지하기 위해, 복제본이 정상 작동 중인 경우 기본 데이터베이스를 프랑크푸르트로 페일오버하고 프랑크푸르트에 정상 작동 복제본이 없는 경우에는 취리히로 페일오버하기로 결정했습니다. 냉각 문제가 해결되었으므로 프랑크푸르트를 다시 온라인 상태로 복구하는 것이 비교적 용이하고 취리히로 전환하는 것보다 빠를 것이라고 판단하여 이 옵션을 선택했습니다.
안타깝게도 상황은 예상대로 흘러가지 않았습니다. 사고 당시 프랑크푸르트 인프라의 수많은 네트워크 카드가 105°C(정상 작동 온도는 45°C)에 도달하여 특수 온도 보호 모드가 트리거되었고, 시스템의 콜드 리셋이 이루어질 때까지 네트워크 카드가 비활성화되었습니다. Proton의 보안 정책상 시스템의 대역 외(out-of-band) 컨트롤러에 대한 접근이 제한되어 있어 복구 지원을 위해 추가 인력을 호출해야 했습니다.
01:30 CEST경에는 대부분의 사용자를 대상으로 대부분의 서비스를 다시 온라인으로 복구할 수 있었습니다. 그러나 푸시 알림이나 결제 처리와 같은 상대적으로 덜 중요한 일부 시스템은 02:00 CEST경이 되어서야 복구되었습니다.
초기 사고 보고서에서 언급했듯이 손실된 이메일은 없었으나, 장애 발생 중에는 수발신 양방향 이메일 전송이 지연되었습니다.
사용자 대상 서비스는 완전히 복원되었지만, 엔지니어들 특히 데이터베이스 팀의 밤샘 작업은 끝나지 않았습니다. 일부 기본 데이터베이스는 취리히에, 다른 데이터베이스는 프랑크푸르트에 위치하고 여러 데이터베이스가 이중화 수준 및/또는 성능이 저하된 상태로 운영되는 등 인프라가 매우 비정상적인 상태로 남아 있었습니다. 팀은 밤을 지새우며 가장 시급한 문제들을 해결했고, 완전한 이중화를 복원하기 위한 작업은 8월 27일 낮 동안에도 계속되었습니다.
대부분의 인프라는 보호할 수 있었지만, 안타깝게도 일부 서버는 과열로 고장 났으며 이번 과열 사고가 살아남은 장비의 수명에 영향을 미칠지는 아직 알 수 없습니다.
근본 원인 및 향후 조치
8월 27일에 진행된 후속 조사 결과, 냉각 시스템에 전력을 공급하는 이중화 공기 압축기 2대 모두에 대한 공기 필터 교체 작업이 냉각 고장의 근본 원인으로 밝혀졌습니다. 안타깝게도 데이터 센터 운영업체는 사전 통지 없이 한밤중에 이 작업을 수행했으며, 냉각 고장이 발생했을 때도 이를 알리지 않아 당사의 대응 가능 시간을 크게 단축시켰습니다. 당사는 이번 사고의 재발을 방지하기 위해 해당 운영업체와 긴밀히 협력하고 있습니다.
그러나 이러한 유형의 장애가 발생할 경우 정상적인 경우보다 복구 과정이 더 길어질 수 있다는 점은 현재 데이터베이스 인프라의 알려진 한계이기도 합니다. 이번 사고로 이어진 일련의 사건들은 일어날 확률이 극히 희박했지만 실제로 발생했습니다.
이러한 고장 모드를 해결하는 데 필요한 데이터베이스 복원력 강화 작업은 이미 진행 중이며 연말까지 완료될 예정입니다. 새로운 데이터 센터 공간을 포함한 추가 인프라 용량도 현재 시운전 중이며 향후 몇 주 내에 사용 가능할 것으로 예상되므로 단일 사이트 의존도가 더욱 낮아질 것입니다.
안타깝게도 이러한 개선 조치가 완전히 적용되기 전에 이번 사고가 발생했습니다. 당사는 중요한 데이터베이스 인프라 변경에 요구되는 신중함을 유지하면서 남은 작업을 안전하게 가속화할 수 있는 방안을 검토하고 있습니다.
당사는 사용자들이 Proton에 매우 높은 수준의 신뢰성을 기대한다는 점을 잘 알고 있으며, 이번 사고를 계기로 인프라 개선 작업을 완료하고 복원력 기준을 지속적으로 높여야 할 중요성을 다시 한번 절감했습니다. 피해를 입으신 모든 사용자분들께 다시 한번 진심으로 사과드립니다.
