오늘, 대형 ISP 겸 인터넷 대역폭 공급업체인 CenturyLink/Level(3)에서 광범위한 서비스 중단 사고가 발생했습니다. 이로 인해 일부 Cloudflare 고객, 많은 인터넷 서비스, 공급업체가 영향을 받았습니다.
Cloudflare는 현재 오늘 사고에 관한 CenturyLink/Level(3)의 사후 분석 결과를 기다리고 있습니다. 그동안 저는 오늘 발생한 사고의 시간대별 기록, Cloudflare 시스템이 문제를 우회한 방법, 완화 조치에도 불구하고 일부 고객이 아직 영향을 받는 이유, 문제의 근본 원인으로 추정되는 이유에 대해 작성해보려고 합니다.
오류 증가
10시 3분(UTC), Cloudflare의 모니터링 시스템이 고객 원본 서버에 수신되는 오류가 증가하는 것을 감지하기 시작했습니다. 이 오류는 "522 오류"로 표시되었고, 이는 Cloudflare 네트워크에서 고객 애플리케이션이 호스팅되는 서버로 연결하는데 문제가 발생했다는 것을 의미했습니다.
Cloudflare는 다양한 대규모 네트워크에 연결되어 있고 CenturyLink/Level(3)은 Cloudflare가 사용하는 다양한 네트워크 공급업체 중 하나입니다. 하나의 네트워크에서 오류가 증가하는 것이 발견되면 Cloudflare 시스템은 자동으로 대체 네트워크를 통해 고객 애플리케이션과 통신합니다. Cloudflare가 액세스할 수 있는 네트워크의 수를 고려하면 일반적으로 하나의 네트워크에서 문제가 발생해도 트래픽을 계속해서 라우팅할 수 있습니다.
자동 완화 조치
오늘 사고의 경우, 522 오류가 증가하는 것을 감지한 지 수 초 이내에 Cloudflare 시스템은 자동으로 트래픽을 CenturyLink/Level(3)에서 Cogent, NTT, GTT, Telia, Tata 등의 대체 네트워크로 경로를 조정하기 시작했습니다.
네트워크 운영 센터에도 이에 관한 경보가 전송되었고, Cloudflare 팀은 10시 9분(UTC)부터 자동 시스템으로 대처할 수 없던 문제를 완화하기 위해 추가적인 조치를 실시하기 시작했습니다. Cloudflare는 CenturyLink/Level(3) 네트워크를 사용할수 없는 와중에도 네트워크에서의 트래픽 흐름을 계속해서 유지했습니다. 그리고 고객과 최종 사용자 대부분이 문제없이 Cloudflare 서비스를 사용할 수 있었습니다.
다음 그래프는 Cloudflare 네트워크와 Cloudflare가 사용하는 6대 주요 1등급 네트워크 간에 이동한 트래픽을 보여줍니다. 빨간색 부분은 CenturyLink/Level(3)의 트래픽을 의미하며, 사고가 발생한 시간 동안 트래픽이 거의 0에 가까운 것을 볼 수 있습니다. 또한, 그래프를 통해 Cloudflare가 사고 발생 시간 동안 서비스 중단의 영향을 최소화하고 트래픽의 흐름을 계속해서 유지하기 위해 트래픽을 다른 네트워크로 전환한 것을 확인할 수 있습니다.
다음 그래프는 사고 발생 시간에 네트워크에 반환된 522 오류(Cloudflare가 고객 애플리케이션에 연결할 수 없음을 의미)를 보여줍니다.
그래프의 기울기가 급격하게 치솟은 10시 3분(UTC), CenturyLink/Level(3) 네트워크에 장애가 발생했습니다. Cloudflare의 자동 시스템은 이에 즉각적으로 대응해 대체 네트워크를 통해 트래픽의 경로를 조정하여 네트워크 간 균형을 맞췄습니다. 그 결과 오류가 즉시 절반으로 줄었고, 트래픽 경로가 자동으로 최적화되어서 정점일 때에 비해 오류가 약 1/4로 감소했습니다.
10시 3분(UTC)부터 10시 11분(UTC)까지 Cloudflare 시스템은 CenturyLink/Level(3)을 사용하는 48개 도시에서 해당 네트워크를 비활성화하고 트래픽을 대체 네트워크로 연결했습니다. Cloudflare의 시스템은 연쇄적인 서비스 중단을 방지하기 위해 트래픽을 전환하기 전에 다른 네트워크의 용량을 고려합니다. 이 때문에 자동화된 시스템임에도 불구하고 장애 조치가 모든 위치에서 즉각적으로 시행되지 않습니다. 이후 Cloudflare 팀이 추가적인 완화 조치를 실시해 오류의 개수를 5% 더 줄일 수 있었습니다.
오류를 0으로 줄이지 못한 이유
안타깝게도 여전히 평소보다 많은 오류가 발생하고 있었습니다. 이로 인해 여전히 일부 고객 애플리케이션과의 통신이 불가능했습니다. CenturyLink/Level(3)은 전 세계에서 가장 큰 네트워크 공급업체 중 하나입니다. 그래서 많은 호스팅 공급업체가 단일 홈 연결을 통해 인터넷에 접속합니다.
인터넷을 "고속도로"로 비유하자면 구식 인터넷은 마을로 가는 출구 차선이 단 하나밖에 없는 고속도로와 같습니다. 출구 차선이 차단되면 마을에 도달할 방법이 없습니다. 이번 사고의 경우, CenturyLink/Level(3)의 네트워크가 라우팅 서비스 중단을 인정하지 않고 서비스가 중단된 후에도 계속해서 Cloudflare 등의 네트워크로 향하는 경로를 안내하여 일부 문제가 악화되었습니다. 고객의 유일한 인터넷 연결 창구가 CenturyLink/Level(3)이거나, 서비스가 중단된 후에도 CenturyLink/Level(3)이 계속해서 잘못된 경로를 안내한 경우 Cloudflare로서는 고객 애플리케이션에 도달할 방법이 없습니다. 결국, 오후 2시 30분경(UTC) CenturyLink/Level(3)이 문제를 해결할 때까지 고객 애플리케이션에는 계속해서 522 오류가 반환되었습니다.
네트워크 반대편에도 동일한 문제가 있었습니다. 인터넷이라는 고속도로에 진입하려면 진입 차선이 필요합니다. 인터넷으로 향하는 이 진입 차선이 바로 ISP가 제공하는 기능입니다. CenturyLink는 미국에서 가장 규모가 큰 ISP 중 하나입니다.
이번 서비스 중단으로 인해 CenturyLink/Level(3)의 모든 네트워크가 오프라인 상태가 되어 CenturyLink를 사용하는 고객의 경우, 문제가 해결될 때까지 Cloudflare나 다른 인터넷 공급업체에 접속할 수 없었습니다. 서비스 중단 시간 동안 전 세계적으로 네트워크 트래픽이 3.5% 감소했고, 이 감소량 중 대부분은 CenturyLink의 미국 내 ISP 서비스가 완전히 중단됨으로 인해 발생했습니다.
사고 현황
CenturyLink/Level(3)이 사후 분석 결과를 발표할 때까지는 정확히 어떤 일이 발생했는지 알 수 없지만, BGP가 교환한 정보와 서비스 중단 시간 동안 BGP가 어떻게 인터넷에 경로를 전파했는지를 살펴보며 몇 가지 힌트를 얻을 수 있습니다. BGP는 Border Gateway Protocol의 약자로, 인터넷상의 라우터끼리 서로 어떤 IP를 사용하며, 어떤 트래픽을 수신하는지 정보를 교환하는 데 사용됩니다.
10시 4분(UTC), BGP 업데이트가 대량으로 발생했습니다. BGP 업데이트는 경로가 변경되었거나 더 이상 경로를 사용할 수 없을 때 라우터가 생성하는 신호입니다. 정상적인 상황에서는 인터넷에서 15분당 약 1.5MB~2MB의 BGP 업데이트가 발생합니다. 사고가 발생한 후, BGP 업데이트가 15분당 26MB 이상으로 급증했고, 사고가 해결될 때까지 계속 높게 유지되었습니다.
이러한 BGP 업데이트는 CenturyLink/Level(3) 백본 내 BGP 경로가 불안정하다는 것을 의미합니다. 문제는 무엇이 이 불안정한 상태를 초래했냐는 것입니다. CenturyLink/Level(3) 상태 업데이트를 살펴보면 Flowspec 업데이트 시 근본적인 원인을 추정할 수 있는 힌트 몇 가지를 얻을 수 있습니다.
Flowspec 소개
CenturyLink/Level(3) 업데이트에는 잘못된 Flowspec 규칙으로 인해 문제가 발생했다고 언급되어 있습니다. 그렇다면 Flowspec이란 무엇일까요? Flowspec은 BGP를 사용해 방화벽 규칙을 하나의 네트워크나 여러 개의 네트워크에 간편하게 분산시킬 수 있는 BGP 확장 프로그램입니다. Flowspec은 방화벽 규칙을 네트워크 전체에 거의 즉각적이면서도 효율적으로 전송할 수 있는 강력한 도구입니다. Flowspec은 공격 등의 악성 활동에 신속하게 대응해야 할 때 유용하게 쓰이지만, 실수할 경우에는 위험할 수 있습니다.
Cloudflare는 설립된 지 얼마 되지 않았을 때, 네트워크 계층 대규모 DDoS 공격 등의 악성 활동을 완화하기 위해 Flowspec을 사용해 방화벽 규칙을 전송했습니다. 그리고 약 7년 전, Flowspec으로 인한 서비스 중단 사고를 경험한 이후 Cloudflare는 더 이상 Flowspec을 사용하지 않습니다. 하지만 Flowspec은 여전히 네트워크 방화벽 규칙을 전송하는 프로토콜로 널리 사용되고 있습니다.
추측에 불과하지만, CenturyLink/Level(3)이 네트워크를 향한 공격이나 다른 형태의 남용을 막기 위해 Flowspec 명령을 내렸다는 사실을 통해 한 가지 그럴듯한 시나리오를 그려볼 수 있습니다. 상태 보고서를 보면 Flowspec 규칙이 BGP의 정보 교환을 막았다는 것이 명시되어 있습니다. 이 Flowspec 규칙이 정확히 어떤 것이었는지는 알 수 없지만, Juniper 서식에 있는 아래와 같은 규칙을 사용했다면CenturyLink/Level(3) 네트워크에서 모든 BGP 통신을 차단할 수 있었을 것입니다.
match {
protocol tcp;
destination-port 179;
}
then discard;
}BGP 업데이트가 대량으로 발생한 이유
하지만 사고 발생 시간 내내 BGP 업데이트의 수가 계속 대량으로 유지되었던 이유는 아직 수수께끼로 남아 있습니다. 규칙이 BGP를 차단했다면 초반에는 BGP의 정보 교환이 증가했다가 다시 평상시 수준으로 돌아와야 정상입니다.
만약 Flowspec 공격 규칙이 BGP 업데이트의 긴 목록이 끝날 즈음에 실행되었다면 설명이 가능합니다. 이것이 사실이라면 CenturyLink/Level(3) 네트워크상의 모든 라우터가 Flowspec 규칙을 수신했을 겁니다. 이후 라우터가 BGP를 차단하면 라우터가 규칙 수신을 중단합니다. 그리고 다시 작동을 시작해 Flowspec 공격 규칙에 도달할 때까지 모든 BGP 규칙을 처리합니다. 그러면 BGP가 감소하고, Flowspec 규칙 수신이 중단됩니다. 그리고 이 과정이 계속해서 반복됩니다.
여기서 한 가지 문제점은 각 사이클마다 CenturyLink/Level(3) 네트워크 내에서 BGP 업데이트 대기열이 계속 증가할 것이라는 겁니다. 이것이 계속되면 라우터의 메모리와 CPU가 과부하되는 지점에 도달하고, 이는 네트워크를 온라인 상태로 전환하는 데 장애물로 작용합니다.
문제를 해결하기까지 그렇게 많은 시간이 걸린 이유
이번 사고는 전 세계적으로 발생한 광범위한 인터넷 중단 사고이며, 당연하게도 CenturyLink/Level(3)은 즉각적인 경고를 받았습니다. 하지만 CenturyLink/Level(3)은 세계 정상급 NOC(네트워크 운영 센터)를 보유한 수준 높은 네트워크 운영업체입니다. 그렇다면 문제를 해결하기까지 왜 그렇게 많은 시간이 걸린 걸까요?
다시 한 번 추측해보겠습니다. 첫째, 라우터에 전달된 Flowspec 규칙과 수많은 BGP 업데이트로 인해 라우터가 자체 인터페이스에 로그인하기가 어려웠을 수 있습니다. 다른 몇몇 1등급 네트워크 공급업체는 CenturyLink/Level(3)의 요청에 따라 네트워크 피어링을 해제한 것으로 보입니다. 이 조치는 CenturyLink/Level(3) 네트워크에서 수신되는 BGP 정보 교환의 횟수를 제한해 CenturyLink/Level(3)에 회복할 시간을 벌어줬을 겁니다.
둘째, Flowspec 규칙을 실행한 주체가 CenturyLink/Level(3)이 아니라 CenturyLink/Level(3)의 고객 중 한 명이었을 수 있습니다. 많은 네트워크 공급업체가 Flowspec 피어링을 허용합니다. Flowspec은 공격 트래픽을 차단하려는 다운스트림 고객에게는 강력한 도구일 수 있지만, 문제가 발생했을 때 Flowspec 공격 규칙을 추적하기란 매우 어렵습니다.
마지막으로, 문제가 발생한 시간이 일요일 아침이라면 빠른 문제 해결에 전혀 도움이 되지 않습니다. CenturyLink/Level(3) 네트워크의 크기와 규모는 극도로 복잡하게 구성되어 있습니다. 사고는 누구에게나 발생합니다. 사고가 발생한 시간 내내 진행 상황을 업데이트하며 정보를 공유한 CenturyLink/Level(3) 팀에 감사의 말씀을 전합니다. #hugops