세상이 멈춘 듯했던 순간들··· 2022년 디지털 중단 사고 톱10

2022년 발생한 주요 중단 사고의 주인공으로는 AWS, 브리티시 항공, 구글, 트위터 등이 있었다. 시스코 소유의 네트워크 인텔리전스 기업 사우전드아이스가 선정한 2022년 중단 사고 톱10 리스트를 살펴본다.

지난 2022년 발생한 각종 중단 사고의 영향은 다양했다. 운항이 멈추고 가상회의가 동작하지 않았다. 통신이 차단되기도 했다. 사우전드아이스의 분석에 따르면 원인 또한 다양했다. 캐나다 통신사 로저 커뮤니케이션은 유지 관리 업데이트 문제로 전국적 중단 사고를 일으켰으며, 소프트웨어 제조사 아틀라시안은 유지 관리 스크립트로 문제를 경험했다. 

BGP 구성 오류도 2022년 발생한 주요 중단 사고의 원인이었다. 보더 게이트웨이 프로토콜은 인터넷 트래픽에게 어떤 경로를 택할지 알려주지만 라우팅 정보가 올바르지 않으면 트래픽이 잘못된 경로로 전달된다. 트위터 사고의 원인이었다. 지난해 발생한 10대 중단 사고를 연대순으로 살펴본다. 
 

브리티시 항공(British Airways), 온라인 시스템 상실(2월 25일)
2월 25일, 브리티시 항공의 온라인 서비스에 대한 액세스가 불가능해지면서 수백 편의 항공편이 취소되었고 항공사 운영이 중단됐다. 항공기 예약이 불가능했고, 여행자들은 전자 체크인이 불가능했다. 해당 항공사는 종이 기반 프로세스를 이용해야 했으며, 사고의 여파는 전 세계적으로 영향을 미쳤다. 

사우전드아이즈(ThousandEyes)는 ‘고장 정지 분석’에서 “사고 당시 모니터링 결과에 따르면  해당 항공사의 온라인 서비스(및 서버)에 대한 네트워크 경로에 접근할 수 있었지만 서버와 사이트 응답의 시간이 초과됐다”라며, 고장 정지의 이유로 네트워크 문제보다는 응답이 없는 애플리케이션 서버를 언급했다.

사우전드아이즈는 “이 문제의 속성 그리고 해당 항공사의 대응을 보면 기저 원인은 다수의 전방 서비스가 의존하고 있는 중앙의 백엔드(Backend) 저장소와 관련되었을 가능성이 높다. 이 사고는 브리티시 항공이 단일 장애점을 피하고 재발 가능성을 낮추기 위해 백엔드를 재구성하거나 해체하는 촉매가 될 수 있다”라고 밝혔다.

트위터(Twitter), BGP 하이잭킹(3월 28일)
3월 28일 러시아의 인터넷 및 위성통신 제공사인 JSC RTComm.RU가 트위터의 프리픽스(Prefix, 104.244.42.0/24) 중 하나를 부적절하게 발표함에 따라 트위터로 향하는 트래픽이 고장났다. 이로 인해 약 45분 동안 일부 사용자가 트위터를 이용할 수 없는 사태가 발생했다. RTComm의 BGP 발표 철회 후 트위터의 서비스에 대한 액세스가 복구됐다. 사우전드아이즈는 잘못된 BGP 구성을 활용하여 표적화 된 방식으로 트래픽을 차단할 수 있다는 점을 언급하면서도 사고 상황이 우연인지 아니면 의도적인지 불분명하다고 밝혔다.

사우전드아이즈는 ‘고장 정지 분석’에서 “3월 28일 트위터 사고는 RTComm이 스스로 트위터의 프리픽스의 출처라고 밝혔다가 철회하면서 발생했다. 무엇 때문에 이런 발표를 했는지는 모르지만 BGP의 우연한 구성 실수가 드물지 않다는 점을 이해할 필요가 있다. ISP의 해당 경로 철회를 고려할 때 RTComm이 중단을 의도했던 것은 아닐 가능성이 높다. 특정 지역에서 트래픽을 차단하기 위해 ISP들이 로컬 BGP 조작을 사용하곤 했기 때문이다”라고 밝혔다.

조직들이 경로 유출과 하이잭킹에 대응할 수 있는 방법이 있다. 경로-출처 승인을 수행하기 위한 암호 기법 보안 메커니즘인 RPKI(Resource Public Key Infrastructure) 등의 보안 메커니즘으로 신속 감지 및 안전 BGP를 모니터링하는 것이다. RPKI는 BGP 하이잭킹 및 유출에 대해 효과적이지만 아직 광범위하게 도입되지 않았다. 사우전드아이즈는 “일부 회사는 BGP 위협을 피하기 위해 RPKI를 구현했을 수도 있지만 통신사는 그렇지 않을 가능성이 있다. ISP를 선택할 때 고려해야 한다”라고 밝혔다.

아틀라시안(Atlassian), 고장 정지의 영향을 과장하다(4월 5일)
아틀라시안은 4월 5일 오전 지라(Jira), 컨플루언스(Confluence), 옵스지니(OpsGenie) 등 자사의 여러 주요 개발 도구에 대한 문제를 보고했다. 유지보수 스크립트 오류로 인해 이들 서비스에 며칠 동안 고장 정지가 발생했지만 약 400명의 아틀라시안 고객들만 영향을 받았다.

사우전드아이즈는 고장 정지 분석 보고서에서 문제 발생 시 제공업체의 상태 페이지의 중요성을 강조했다. 아틀라시안의 상태 페이지에는 상당한 고장 정지를 나타내는 ‘주황식 및 빨간색 표시등이 범람’하고 있었다. 해당 기업은 당시 수백 명의 엔지니어를 동원하여 해당 사건을 바로잡을 것이며 대부분의 고객들에게는 문제가 없다고 밝히기도 했다.

흔히 서비스 기업의 상태 페이지는 고장 정지의 범위를 축소하는 경향이 있다. 그러나 반대의 경우도 있다고 사우전드아이즈는 전했다. “균형을 맞추기가 정말로 어렵다. 자칫 고객들은 혼란스러울 수 있다. 과도하게 일일이 밝히면 다수의 영향을 받지 않는 고객들과 이해관계자들이 불필요하게 걱정할 위험이 있다”라고 보고서는 지적했다.

로저스(Rogers), 고장 정지로 인해 캐나다 전역에서 서비스 중지(7월 8일)
잘못된 유지보수 업데이트로 인해 캐나다의 통신사 로저스 커뮤니케이션스(Rogers Communications)의 네트워크가 전국적으로 장기간 고장 정지를 일으켰다. 고장 정지는 약 1,200만 명의 고객들의 전화 및 인터넷 서비스에 영향을 미쳤으며, 뱅킹 거래, 정부 서비스, 긴급 대응 역량 등 전국적으로 여러 주요 서비스에 문제가 나타났다.

사우전드아이즈에 따르면 로저스는 내부적인 라우팅 문제로 인해 프리픽스를 철회했는데, 이로 인해 해당 티어 1(Tier 1) 제공자는 인터넷에서 약 24시간 동안 접속이 불가능했다. 

“이 사고는 로저스의 프리픽스 중 다수가 철회되면서 전 세계 인터넷에서 그들의 네트워크에 접속할 수 없게 되면서 발생한 것으로 보였다. 하지만 이번에 그들의 네트워크에서 관찰된 행동으로 보아 외부 BGP 경로의 철회는 내부 라우팅 문제 때문에 발생한 것으로 보인다”라고 사우전드아이즈가 ‘고장 정지 분석’에서 밝혔다.

로저스의 고장 정지는 중요 서비스에 대한 백업의 필요성을 상기시켰다. 1개 이상의 네트워크 제공자를 확보하거나 대기시키고 고장 정지 발생 시의 백업 계획을 마련하며 선제적인 가시성을 확보해야 한다고 사우전드아이즈가 조언했다. “아무리 큰 제공 기업도 고장 정지로부터 자유롭지 못하다. 따라서 병원 및 뱅킹 등의 필수 서비스의 경우 고장 정지의 길이와 범위를 완화할 수 있는 백업 네트워크 제공자에 대한 계획을 세우라”라고 사우전드아이즈가 밝혔다.

AWS, 중단으로 인해 미국 동부 지역 다운(7월 8일)
7월 28일의 정전으로 인해 US-동부-2 지역의 AZ1(AWS Availability Zone 1) 서비스가 중단됐다. 사우전드아이즈는 ‘고장 정지 분석’에서 “이 고장 정지는 해당 지역의 연결성에 영향을 미쳤으며 아마존의 EC2 인스턴스가 붕괴되면서 웹엑스(Webex), 옥타(Okta), 스플렁크(Splunk), 밤부HR(BambooHR) 등의 애플리케이션이 영향을 받았다”라고 밝혔다. 

모든 사용자 또는 서비스가 동일하게 영향을 받지 않았다. 예를 들어, 시스코(Cisco)의 데이터센터에 위치한 웹엑스 요소는 여전히 작동했다. AWS는 고장 정지가 약 20분 정도밖에 지속되지 않았다고 보고했지만 일부 고객의 서비스 및 애플리케이션은 복구에 최대 3시간이 소요됐다.

클라우드 제공 애플리케이션과 서비스를 위해 일정 수준의 물리적인 가외성을 설계하는 것이 중요하다고 사우전드아이즈가 밝혔다. “데이터센터 정전 발생 시에는 연착륙이 없다. 정전이 발생하면 의존하는 시스템이 심각하게 다운된다. 정전 또는 UPS 배터리 등 관련 시스템의 고장 발생 시 디지털 서비스의 아키텍처 탄력성 및 가외성이 중요하다”라고 보고서는 기술했다.

구글 검색(Google Search) 및 구글 맵스(Google Maps) 중단(8월 9일)
짧은 고장 정지가 구글 검색 및 구글 맵스에 영향을 미쳤으며, 이렇게 널리 사용되는 구글 서비스가 전 세계적으로 약 1시간 동안 사용자들에게 제공되지 않았다. 사우전드아이즈는 “이들 서비스에 접속하기 위해 시도하면 구글의 엣지 서버에서 일반적으로 내부 서버 또는 애플리케이션 문제를 나타내는 HTTP 500 및 502 서버 응답 등의 오류 메시지가 발생했다”라고 보고했다.

기저 원인은 잘못된 소프트웨어 업데이트인 것으로 보고됐다. 이로 인해 최종 사용자가 구글 검색 및 구글 맵스에 액세스할 수 없을 뿐 아니라 구글의 소프트웨어 기능에 의존하는 애플리케이션들이 동작을 멈췄다.

해당 고장 정지가 IT 전문가들에게 흥미로운 몇 가지 이유가 있다는 분석이다. 사우전드아이스는 “첫째, 구글 검색 같은 안정적인 서비스도 여전히 다운될 수 있다는 점이 드러났다. 둘째, 해당 이벤트로 서로 연계된 소프트웨어 시스템이 얼마나 흔할 수 있는지 알 수 있었다”라고 전했다.

줌(Zoom), 고장 정지로 무산된 가장 회의(9월 15일)
전 세계 사용자들에게 잘못된 게이트웨이(Bad Gateway)(502) 오류를 표시한 9월 15일 고장 정지로 인해 사용자들은 약 1시간 동안 줌에 로그인하거나 줌 회의에 참여할 수 없었다. 경우에 따라 이미 회의에 참석 중인 사용자들이 쫓겨나기도 했다.

기저 원인은 확인되지 않았으나 “줌의 백엔드 시스템에서 트래픽 해결, 라우팅, 재배포 등의 기능과 관련이 있는 것으로 보였다”라고 사우전드아이즈가 ‘고장 정지 분석’에서 밝혔다.

Z스케일러(Zscaler), 100% 프록시 패킷 손실(10월 25일)
10월 25일, Z스케일러 프록시 종점으로 향하는 트래픽에 100% 패킷 손실 사고가 발생했다. 이로 인해 Z스케일러 클라우드(Zscaler Cloud) 네트워크 2에서 ZIA(Zscaler Internet Access) 서비스를 이용하는 고객들이 영향을 받았다. 심각한 패킷 손실은 약 30분 동안 지속되었지만 일부 접속 문제와 패킷 손실 급증은 일부 사용자 위치에서 3시간 이상 간헐적으로 나타났다고 사우전드아이즈가 ‘고장 정지 분석’에서 밝혔다.

Z스케일러는 상태 페이지에서 이 문제를 ‘트래픽 포워딩(Forwarding) 문제’라고 언급했다. 프록시 장치의 가상 IP에 접속할 수 없게 되면서 트래픽을 포워딩 할 수 없게 됐다는 설명이었다.

사우전드아이즈는 이 시나리오로 인해 Z스케일러의 보안 서비스를 이용하는 일부 고객들이 어떻게 중요한 비즈니스 도구와 SaaS 앱에 접속할 수 없게 되었는지에 대해 다음과 같이 분석했다. 

“Z스케일러의 서비스는 웹 프록시뿐 아니라 세일즈포스(Salesforce), 서비스나우(ServiceNow), 마이크로소프트 오피스 365(Microsoft Office 365) 등 다른 중요한 비즈니스 도구 및 SaaS 서비스를 프록시 처리하는 SSE(Secure Service Edge)에서 일반적으로 사용된다. 따라서 Z스케일러의 서비스를 이용하는 기업 고객들은 다양한 애플리케이션에서 영향을 받았다. 해결을 위해 수동으로 개입하여 영향을 받는 사용자를 대체 게이트웨이로 라우팅해야 하는 경우가 흔했다.”

왓츠앱(WhatsApp), 고장 정지로 인해 메시지 교환 중단(10월 25일)
10월 25일, 2시간 동안의 고장 정지로 인해 왓츠앱 사용자들은 해당 플랫폼에서 메시지를 주고받을 수 없었다. 메타(Meta)가 소유한 이 프리웨어(Freeware)는 오늘날 인기 있는 메시지 교환 앱이다. 디지털 정보 플랫폼 시밀러웹(Similarweb)의 2022년 데이터에 따르면 전 세계 인구의 31%가 왓츠앱을 사용하고 있다.

사우전드아이즈의 ‘고장 정지 분석’에 따르면 해당 고장 정지는 네트워크 문제보다는 백엔드 애플리케이션 서비스 문제와 관련되어 있었다. 해당 앱이 수억 명의 사용자 기반을 보유한 인도에서 사고의 영향이 컸다.

AWS, 미국 동부 지역 재공격(12월 5일)
AWS는 12월 초 미국 동부 2 지역에서 2번째 고장 정지를 겪었다. AWS에 따르면 약 75분 동안 지속된 이 고장 정지는 미국 동부 2 지역의 인터넷 연결 문제로 이어졌다.

사우전드아이즈는 2곳의 글로벌 위치와 AWS의 US-동부-2 지역에서 상당한 패킷 손실을 관찰했다. 해당 사고는 ISP를 통해 AWS 서비스에 연결하는 최종 사용자들에게 영향을 미쳤다. “ISP를 통해 연결하는 최종 사용자들 사이에서 손실이 나타났다. 해당 지역 내 인스턴스들 또는 지역들 간의 연결에는 영향을 미치지 않은 것으로 보인다”라고 사우전드아이즈가 ‘고장 정지 분석’에서 밝혔다.

그 날 늦게 AWS는 해당 문제가 해결되었다는 블로그를 게시했다. AWS는 “해당 지역 내 인스턴스들 및 지역들 간의 연결과 직접 연결(Direct Connect) 연결은 이 문제의 영향을 받지 않았다. 문제는 해결되었고 연결은 복구됐다”라고 작성했다. ciokr@idg.co.kr