델타 항공과 사우스웨스트 항공이 지난 여름 기록한 IT 시스템 정지 사례는 모든 IT 전문가들이 참고할 만한 교훈을 시사한다.
지난 몇 달은 항공 IT 시스템 고장 측면에서 이례적인 시기였다. 단순한 부품 고장으로 인한 심각한 고장 정지 사건이 2주 만에 2건이나 발생해 방대한 승객 불편을 야기했으며 이들 두 항공사는 수 백만 달러의 손실을 입었다.
이런 사건은 당사자에게는 무척 고통스러운 일이지만 다른 기업들에게는 절차를 학습하고 개선할 수 있는 엄청난 타산지석의 기회다.
먼저 약간의 사건 개요를 설명하도록 하겠다. 지난 7월 21일 라우터(Router) 문제로 인해 사우스웨스트항공(Southwest Airlines)의 운영에 차질이 발생했다. 고장 정지가 발생했는데, 며칠 동안 영향을 끼쳤다. 참고로 사우스웨스트는 마진의 측면에서 미국 내 최대 규모의 국내 승객 운송사다. 달라스 모닝 뉴스는 당시 이 소식을 상세히 보도했다.
보도 기사에는 “21일 이른 오후 네트워크 라우터에 문제가 발생하고 백업 시스템이 제대로 개입하지 못하면서 고장 정지가 발생했다. 고장 정지는 약 12시간 후에 해결되었지만 혼란의 규모로 인해 사우스웨스트는 이후 며칠 동안 항공기, 승무원, 승객을 관리하느라 엄청난 혼란을 겪어야 했다”라고 기술하고 있다. 이 항공사는 결국 약 2,300편의 항공편(전체의 약 11%)가 취소되는 사태를 맞이해야 했다.
(‘백업 시스템의 개입 실패’는 아마존 웹 서비스(Amazon Web Services)의 고객들에게 익숙한 용어다. 이번 사건은 2011년 아마존(Amazon)의 클라우드 관리 운영의 상당 부분을 앗아갔던 백업 시스템 실패와 유사하다. 당시 클라우드 고객들은 이로 인해 아마존의 가용성 구역 및 내고장성 기능을 사용하기 시작했다.)
그리고 8월 8일에는 델타항공(Delta Air Lines)에서 사고가 발생했다. IT 시스템 고장 정지로 인해 여름 휴가 피크 기간에 수 백 편의 항공기가 취소되거나 지연됐다. 이 모든 것은 그저 한 전기 부품의 고장 때문에 발생했다.
월스트리트저널은 이렇게 보도했다. “동부 시간으로 오전 2:30에 애틀랜타(Atlanta) 본사에서 발생한 전기 문제로 인해 델타항공은 오전 5시부터 출발하는 수 백 편의 항공편을 지연시킬 수 밖에 없었다고 밝혔다. 회사의 고위 임원 에드 배스티앙은 영상을 통해 고객들에 사과했다. 기술 문제로 인해 델타는 수 백만 달러의 수익 손실을 입었을 뿐 아니라 지난 분기 어렵게 얻은 미국에서 가장 신뢰할 수 있는 국제 항공사라는 명성에 피해를 입었다.”
델타 고장 정지 사태에서 문제가 된 기술은 배전 상자(시설의 전원을 담당하는 거대한 퓨즈 박스)였다. 이 기기에 전력을 공급하는 조지아 파워 측은 고장 기기 소재지가 델타의 본사였다고 밝혔다.
이 모든 것들이 의미하는 것?
델타와 사우스웨스트의 IT 고장 정지 사고는 잘못된 시점에 잘못된 곳에서 발생한 IT 고장이 단 수 시간 만에 수 백만 달러의 비용을 발생시킬 수 있는지 보여준다. 또 지난 수 년 동안 이뤄진 재난 복구에 대한 여러 논의에도 불구하고 곳곳에 허점이 있을 수 있다는 사실을 시사한다.
고가용성 옵션은 수십 년 전부터 있었으며 꾸준히 발전해왔다. 비상용 하드웨어가 강력해졌으며 수 백만 분의 1초 만에 여러 지역에서 운영되는 윈도우 및 리눅스(Linux)용 시스템 대체 작동 옵션, 필요에 따라 다른 데이터 센터에서 백업 작업을 실행하는 서비스형 인프라 등이 있다.
이런 옵션은 비용 절감 효과도 가져다줬다. 과거에는 대체 시스템을 구축하기 위해 수 백만 달러의 예산이 필요했지만 이제는 신용카드로 수 시간 분량의 서비스를 손쉽게 구매할 수 있다. 물론 수 십억 달러 규모의 항공사에서는 좀더 복잡할 것이다.
필자가 생각하기에 많은 사람들이 사업 연속성과 IT 연속성를 계획할 때 놓치는 중요한 원칙이 있다. 사업의 운영을 위해 IT에 의존하고 있다면 높은(이상적으로는 연속적인) 가용성을 확보해야한다는 것이다. 그러나 많은 사람들이 재난 복구와 고가용성이 같은 것이며 상호적인 목표라고 생각한다. 이런 생각은 잘못된 것이다.
재난 복구는 기술적 문제나 대자연이 데이터 센터를 허리케인으로 공격하는 등 기술 운영에 어떤 식으로든 문제가 발생했을 때 실시하는 것이다. 이는 조각들을 모아 정상 운영으로 복귀하기 위해 필요한 프로세스와 절차(그리고 필요 인프라)를 설명한다. 하지만 재난 복구 계획을 실행하는 시간 동안 IT 자산은 온라인 상태가 아니기 때문에 기업은 고객들에게 서비스를 제공하지 못할 수 있다.
반면, 고가용성은 기본적으로 항상 온라인 상태로 “시스템 대체 작동”에 대비하는 보상 하드웨어 및 소프트웨어를 추가하여 일부 다운타임에 대비하는 것이다. 시스템 부하 전체를 처리할 수는 없더라도 최소한 활용이 가능하기 때문에 기업에 필수적인 활동이 실제로 지속될 수 있도록 한다.
고가용성을 추구할 때의 장점
고가용성이 중요한 목표인 이유는 무엇일까? 기술을 완전히 오프라인 상태로 두는 것보다 제한적일지라도 운영하는 것이 비즈니스에 덜 치명적이기 때문이다. 거의 모든 경우에 그렇다. 고장 정지 중 정상적인 방식으로 모든 고객에 서비스를 제공하지 못할 수도 있지만 최소한 주요 기능을 수행할 수 있는 역량을 확보하면 다른 쪽에서 수동 또는 대체 프로세스로 복귀해 비즈니스 전체를 운영할 수 있다.
델타항공의 경우 이번 고장 정지로 인해 비행 계획서를 FAA로 제출하지 못했고 이로 인해 다른 모든 프로세스를 자동 또는 수동으로 운영했다 할지라도 항공기가 출발할 수 없었다. 최소한 비행 계획 제출 소프트웨어를 다른 곳에서 사용할 수 있었다면 어땠을까? 승객이 많은 주요 항공편이나 적절한 장비를 적절한 위치로 이동할 항공편이 출발할 수 있었을 것이고 고장 정지로 불리한 영향을 받은 고객들이 더 적었을 것이다.
핵심: 프로세스에서 반드시 이루어지지 않으면 전체가 무너지는 “게이팅(Gating)” 문제가 무엇인지 파악하라. 그리고 이런 것들을 위한 2차 및 3차 백업뿐만이 아니라 1차 고장 시 이런 것들을 온라인으로 유지할 수 있는 계획을 확보하라.
고가용성을 위해 대비할 때 지리적 중복성 또한 고려해야 한다. 델타 고장 정지 사태에서 도출할 수 있는 결론은 해당 항공사의 주요 인프라 전체가 애틀란타의 델타 본사 건물 어딘가에서 운영 중인 하드웨어 또는 소프트웨어 중 일부에 의존하고 있었다는 점이다.
델타의 승객 서비스 시스템 또는 운영 소프트웨어를 다른 곳에서 관리했다 하더라도 뉴스 보도에서 언급했듯이 서버 클로젯(Closet) 또는 해당 건물의 데이터센터에 위치한 일부 하드웨어에서 운용 중인 일부 애플리케이션이 실제로 해당 항공사의 단일 고장점이었다.
가용성 측면에서 기본적인 교훈은 원격적에서 중복 사본이나 버전을 확보함으로써 전기 문제나 날씨 장애 등의 국지적인 문제가 백업 노드의 운영에 영향을 끼치지 않아야 한다는 점이다.
핵심: 재난 계획의 경우 1차 시스템에서 떨어진 곳에 백업 시스템을 확보해야 한다.
시스템 대체 작동 프로토콜은 점검이 필수적이다. 자칫하면 꼭 필요한 상황에 동작하지 않는 상황을 맞이할 수 있다. 사우스웨스트와 델타 고장 정지 사건 모두 이 부분이 공통적이었다. 백업과 대체 시스템이 필요할 때 동작하지 않았다.
뉴욕타임스(The New York Times)는 이렇게 보도했다. “사우스웨스트의 경우 백업 시스템이 마련되어 있었지만 해당 항공사는 라우터에 고장이 발생했을 때 시스템이 제대로 작동하지 않았다고 밝혔다. 그리고 델타 측은 월요일 자체 주요 작업 중 일부가 백업 시스템으로 전환되지 않은 이유를 조사 중이라고 밝혔다.”
재난 복구 및 고가용성에 대한 모드 투자는 필요할 때 효과를 발휘해야 한다. 그것이 존재 이유다.
핵심: 시스템 대체 작동을 엄격하고 일관되게 테스트해야 한다. 대부분의 테스트는 피크 타임을 피해 실시하되 느리지만 정상적인 시간에 스트레스 테스트도 진행해야 한다. 이때 상황 파악을 위해 발생하는 부하와 여파를 기록해둬야 한다.
클라우드라면 도움이 되었을까?
클라우드 옹호론자들이 이번 고장 정지 사건 후에 어김없이 목소리를 높였다. 그들은 “온프레미스 설치로 유지했을 때 어떤 일이 일어나는지 보았는가?”라며 “아마존 웹 서비스나 마이크로소프트 애저(Microsoft Azure)를 사용했더라면 이런 일이 없었을 것이다”라고 입을 모아 말했다. 하지만 정말로 그럴까?
그렇기도 하고 아니기도 하다. 클라우드는 다계층 개념이다. 누군가 클라우드를 이야기할 때 다른 곳에서 운용하는 가상머신에 대해 이야기하는가? 내고장성을 갖추고 플랫폼이 모든 것을 처리하기 때문에 기성의 가용성을 갖춘 완전한 관리형 웹 애플리케이션에 관해 이야기하는가? 기본적으로 다른 곳에서 관리하는 프라이빗 클라우드인 클라우드 데이터센터로의 시스템 대체 작동에 관해 이야기하는가? 누군가는 시나리오에 따라 “클라우드”가 어떤 의미인지 구체적으로 정의해야 한다.
이번 사고 측에서 좀더 자세히 살펴보도록 하자. 세이버(Sabre) 예약 시스템을 AWS로 포팅(Porting)할 수 있는가? 없었을 것이다. 비행 계획서 제출 소프트웨어를 애저에서 웹 앱으로 운용할 수 있는가? 아마도 가능했을 것이다. 항공사 전체를 구글 클라우드(Google Cloud)에서 운영할 수 있을까? 분명 불가능했을 것이다다. 하지만 필자가 앞서 언급한 “게이팅 지점” 등의 주요 부위를 클라우드로 이행할 수 있을까? 그럴 수 있을 것 같다.
항공사는 매우 복잡하게 운영된다. 이 업종보다 부품과 장비에 더 많이 의존하는 사업도 없을 것이다. 이 때문에 특정 공항에서 발생하는 몇몇 뇌우로 인한 사소한 중단도 고객에 엄청난 결과를 안겨줄 수 있다.
필자가 항공사 CTO보다 더 많은 것을 알고 있다거나 어떤 항공사가 클라우드 기술에 투자하고 있는지 강조하려는 게 아니다. 필자는 항공사 IT 투자에 대한 특수한 또는 내부자 지식이 없으며 항공사 고객도 없다.
오늘 이야기의 핵심은 우리가 이런 고장 정지의 원인과 영향을 통해 배울 수 있다는 점이다. 그리고 이 두 사례에서 두 항공사 모두 대체 시스템을 클라우드에 배치해 긴급상황에 대비했다면 상황이 그처럼 악화되지 않았을 가능성이 크다. 물론, 원활하고 완벽한 솔루션이 아니었을 수 있다. 하지만 수 천 명의 고객들이 발이 묶이고 휴가를 망치며 고객 손실 청구 비용을 보상해야 하는 손실은 발생하지 않았을 것이다.
* Jonathan Hassell은 컨설팅 기업 82벤처스의 경영자다.dl-ciokorea@foundryco.com
