메모리 버그로 Salesforce의 핵심 스위치와 장애 조치가 무너져 90만 명의 가입자가 접속 차단되다

2009년 1월 6일, salesforce.com이 먹통이 되었다. UTC 20시 39분(태평양 시간 정오 무렵)부터 고객들은 로그인하거나 CRM 데이터에 접근할 수 없었으며, The Register는 90만 명이 넘는 가입자가 자신들의 사업을 운영하는 애플리케이션에서 차단되었다고 보도했다. Business Insider는 전체 장애 시간을 30~40분으로 추정했다. 기업이 가장 중요한 데이터를 자사의 클라우드에 맡길 수 있다고 내세우던 회사에게, 거의 한 시간에 가까운 완전한 장애가 업무 시간 중에 발생한 것이다.

이후 Salesforce가 올린 자체 설명은 다음과 같다. '핵심 네트워크 장비가 메모리 할당 오류로 고장 났습니다. 이 고장으로 장비가 데이터 전송을 멈추었지만, 장애 조치 시스템에도 동일한 메모리 할당 오류가 존재했기 때문에 이중화 시스템으로의 정상적인 장애 조치가 제대로 발동되지 않았습니다.' 다시 말해, 이중화 장비가 주 장비와 같은 방식으로 고장 났고, 플랫폼은 수동 절차를 통해 복구해야 했다.

이 사건은 이차적인 실패도 드러냈다. Salesforce의 공개 '신뢰' 상태 대시보드, 즉 자사의 신뢰성을 홍보하는 페이지가 제품과 함께 다운되었기 때문에 고객들은 자신들만 영향을 받은 것인지 알 수 없었다. 수백 명이 트위터로 몰려가 장애를 확인했는데, 이는 SaaS 플랫폼이 실패할 때 의도적으로 영향 범위 밖에 두지 않는 한 그 커뮤니케이션 계층도 함께 실패한다는 것을 보여준 이른 사례였다.

업무 시간 중에 90만 명이 넘는 가입자에게 약 40분간의 완전한 서비스 장애가 발생했으며, 작동하는 장애 조치가 없었다.

장애 조치 장비가 고장 난 주 장비와 동일한 메모리 할당 결함을 갖고 있었기 때문에 '이중화' 경로가 트래픽을 전혀 받지 못했다.

장애 조치가 정상적으로 발동되지 않았고, 전체 서비스를 복구하려면 운영팀의 수동 복구 절차가 필요했다.

공개 신뢰 대시보드가 동일한 장애 영역 안에 있어 고객들은 상황을 볼 수 없었고, 스스로 트위터에서 장애를 진단해야 했다.

동일한 부품으로 구축한 이중화는 동일한 버그를 물려받는다. 대기 장비가 주 장비와 같은 결함을 갖고 있다면 그것은 여유분이 아니라 거울일 뿐이다. 장애 조치 경로를 다양화하라.

Salesforce는 신뢰 사이트에 설명을 게시하고, 근본 원인이 '우회 조치로 해결되었다'고 밝혔으며, 팀이 하드웨어 공급업체와 계속 협력하여 근본 원인을 규명하고 추가 패치를 확인할 것이라고 말했다. The Register와 비즈니스 언론은 이 장애를, 가용성을 설치형 CRM 소프트웨어에 대한 핵심 우위로 판매하던 회사에게 닥친 클라우드 컴퓨팅의 '어두운 이면'으로 규정했다. 신뢰성 관찰자들은 다른 교훈을 이끌어냈다. 모든 것은 실패하며, 운영자를 구별하는 것은 고객이 무슨 일이 일어나는지 알 수 있느냐이다. 실패한 것은 가동 시간이 아니라 커뮤니케이션이었다.