현재 Cloudflare Radar는 Outage Center에서 관찰된 인터넷 중단(부분 또는 전체 중단 포함) 목록을 선별합니다. 이러한 중단은 인터넷 서비스 공급자의 상태 업데이트 및 관련 통신을 확인하거나 케이블 절단, 정부 명령, 정전, 자연 재해와 관련된 뉴스 보도를 찾아서 관찰된 트래픽 감소와 연관시킬 수 있는 충분한 맥락이 있을 때마다 기록됩니다.
그러나 현재 Outage Center에서 보고하는 것보다 더 많은 장애가 관찰되고 있는데, 이는 조지아 공대의 IODA와 같은 외부 데이터 소스로 검증할 수 있음에도 불구하고 관찰되는 장애의 원인을 제공할 만한 정보 소스를 찾을 수 없는 경우가 있기 때문입니다. 이 큐레이션 프로세스에는 수작업이 포함되며, 트래픽 양을 분석하고 이상을 자동으로 감지하여 관련 근본 원인을 찾기 위한 워크플로우를 트리거하는 내부 도구의 지원을 받습니다. Cloudflare Radar Outage Center는 귀중한 리소스이지만, 그 주요 단점에는 모든 장애를 보고하지 않는다는 점과 현재 큐레이션 프로세스는 여전히 맥락을 찾아야 하기 때문에 원하는 만큼 시의적절하지 않다는 점이 포함됩니다.
오늘 관련 블로그 게시물에서 발표한 바와 같이 , Cloudflare Radar는 국가 및 자율 시스템(AS)에 대한 이상 트래픽 이벤트를 게시할 예정입니다. 이러한 이벤트는 위에서 언급한 것과 동일하며, 중단을 검증하고 확인하기 위해 저희 내부 워크플로우를 트리거하는 이벤트입니다. (현재 "이상 트래픽 이벤트"는 예기치 않은 트래픽 급증이 아닌 트래픽 감소와 관련이 있음을 유의하세요.) Outage Center에 트래픽 이상 정보를 추가하는 것 외에도 저희는 사용자가 새로운 이상 이벤트가 감지되거나 장애 표에 새로운 항목이 추가될 때마다 위치(국가) 또는 네트워크(자율 시스템) 수준에서 알림을 구독할 수 있는 기능도 출시할 예정입니다. 구독 방법에 대한 자세한 내용은 관련 블로그 게시물을 참조하세요.
감지된 각 이상의 현재 상태는 Outage Center 페이지의 새로운 "트래픽 이상" 표에 표시됩니다.
이상이 자동으로 감지되면 상태는 처음에는 확인되지 않음으로
표시됩니다'확인되지 않음' 항목의 유효성 검사를 시도한 후:
여러 내부 데이터 소스 및 가능한 경우 외부 데이터 소스에서도 이상이 나타나는 것을 확인할 수 있는 경우 상태를 '확인됨'으로 변경합니다. 관련 컨텍스트를 찾으면 중단 항목도 생성합니다.
여러 데이터 소스에서 확인할 수 없는 경우 상태를 '오탐'으로 변경합니다. 이렇게 하면 '트래픽 이상' 표에서 해당 항목이 제거됩니다. (알림이 전송되었지만, 이상이 더 이상 Radar에 표시되지 않으면 '오탐'로 플래그가 지정된 것입니다.)
또한 '확인됨' 상태의 항목을 수동으로 추가할 수도 있습니다. 이는 눈에 띄는 트래픽 감소를 관찰하고 검증하지만, 알고리즘이 포착할 수 있을 만큼 크지 않은 경우 발생할 수 있습니다.
인터넷 트래픽 양, 한눈에 살펴보기
Cloudflare에는 특정 엔터티의 트래픽에 대한 인사이트를 제공할 수 있는 여러 내부 데이터 소스가 있습니다. 위치의 경우 IP 주소 지리적 위치를 기반으로, AS의 경우 IP 주소 할당을 기반으로 엔터티를 식별하고, DNS, HTTP, NetFlows, 네트워크 오류 로그(NEL) 등 다양한 소스로부터의 트래픽을 분석할 수 있습니다. 아래 그림에 사용된 모든 신호는 이러한 데이터 소스 중 하나에서 나온 것이며, 이 블로그 게시물에서는 이를 단일 변량 시계열 문제로 취급할 것입니다. 현재 알고리즘에서는 중복성을 추가하고 더 높은 수준의 신뢰도로 이상을 식별하기 위해 두 개 이상의 신호를 사용하고 있습니다. 아래 논의에서는 잠재적인 인터넷 트래픽량 시나리오의 광범위한 스펙트럼을 포괄하기 위해 의도적으로 다양한 사례를 선택했습니다.
1. 이상적으로, 신호는 호주(AU)의 경우 아래 표시된 패턴과 유사합니다. 약간 양의 추세를 보이는 안정적인 주간 패턴이며, 이는 시간이 지남에 따라 추세 평균이 상승하고 있음을 의미합니다(호주 사용자로부터 시간이 지남에 따라 더 많은 트래픽이 발생하고 있음).
시계열을 구성 요소로 분해하여 기본 패턴을 더 잘 이해하고 분석할 수 있는 시계열 분해 분석을 수행하면 이러한 진술을 명확하게 확인할 수 있습니다. 위의 호주 트래픽 양을 LOESS(STL)를 사용한 계절-추세 분해로 주간 패턴을 가정하여 분해하면 다음과 같은 결과를 얻을 수 있습니다.
저희가 언급하는 주간 패턴은 저희가 eyeball /인간 인터넷 트래픽에 관심이 있기 때문에 관찰될 것으로 예상되는 신호의 계절적 부분으로 표현됩니다. 위 이미지에서 볼 수 있듯이 추세 성분은 신호 레벨과 비교할 때 느리게 움직일 것으로 예상되며, 잔여 부분은 이상적으로는 백색소음과 유사한데, 이는 신호의 모든 기존 패턴이 계절 및 추세 성분으로 표현된다는 의미입니다.
2. 아래에는 주간 패턴이 아닌 일별 패턴에 더 가까운 AS15964(CAMNET-AS)의 트래픽 양이 나와 있습니다.
또한 처음 4일(파란색 점선) 직후에 신호의 값이 오프셋되는 것을 관찰했으며, 빨간색 배경은 저희 데이터와 다른 인터넷 데이터 공급자에서 확인된 것 외에 보고되지 않은 중단을 보여줍니다. 여기서 우리의 의도는 이러한 패턴 또는 유사한 패턴이 발견될 때 이벤트를 트리거하는 알고리즘을 개발하는 것입니다.
3. 다음은 프랑스 령 기아나(GF)의 비슷한 예입니다. 일부 데이터 오프셋(8월 9일과 23일), 진폭의 변화(8월 15일~23일), Cloudflare Radar에서 관찰할 수 있으며 저희가 전후 관계를 파악하고 있는 또 다른 중단이 관찰되었습니다.
4. 또 다른 시나리오는 AS203214(HulumTele)에 대한 몇 차례의 예정된 중단으로, 이 역시 저희가 전후 관계를 파악하고 있습니다. 이러한 이상은 트래픽이 정전 시 보이는 고유한 값(일반 트래픽으로 오인할 수 없음)을 보이므로 가장 쉽게 감지할 수 있지만, 또 다른 문제가 있습니다. 즉, 저희 계획이 주간 패턴만 확인하는 것이었다면 이러한 정부 주도 정전이 동일한 빈도로 발생하므로 알고리즘이 이를 예상된 트래픽으로 간주한다는 것입니다.
5. 케냐의 정전 사태도 위와 비슷하게 볼 수 있는데, 트래픽 양이 이례적인 값까지 감소했지만, 그 정도로 큰 규모는 아니었습니다. 또한 시계열을 모델링하는 데 사용하는 접근 방식에 따라 특정 패턴을 따르지 않는 데이터(이상치일 수 있음)가 일부 상승하는 것을 관찰할 수 있습니다.
6. 마지막으로, 다음은 이 게시물 전체에서 이 문제에 접근하는 방법의 예로 사용될 데이터입니다. 마다가스카르(MG)의 경우 뚜렷한 주말(파란색 배경)이 있는 명확한 패턴을 관찰할 수 있습니다. 또한 녹색 배경으로 강조 표시된 휴일(성모 승천 대축일)과 빨간색 배경으로 강조 표시된 정전이 있습니다. 이 예에서는 주말, 휴일, 정전 모두 트래픽 양이 거의 같은 것처럼 보입니다. 다행히도 장애는 정상 근무일과 마찬가지로 증가하려다가 갑자기 감소한 것으로 나타나므로 이 글의 뒷부분에서 자세히 살펴보겠습니다.
요약하자면, 약 700개(현재 자동으로 이상을 감지하고 있는 엔터티 수) 중 6개의 사례를 살펴본 결과 다양한 변동성을 확인할 수 있었습니다. 이는 시계열을 효과적으로 모델링하기 위해서는 모델링 전에 많은 전처리 단계를 실행해야 함을 의미합니다. 이러한 단계에는 이상치 제거, 장단기 데이터 오프셋 감지 및 재조정, 분산, 평균, 크기 변화 감지 등이 포함됩니다. 시간도 전처리의 한 요소인데, 이는 트래픽이 감소할 것으로 예상되는 이벤트/공휴일을 미리 알고, 데이터의 시간 이동을 유발하는 서머타임 조정을 적용해야 하며, 여러 시간대가 있는 위치 및 여러 시간대에 걸쳐 공유되는 AS 트래픽을 처리하는 등 각 주체에 대해 현지 시간대를 적용할 수 있어야 하기 때문입니다.
이 문제가 더 어려운 이유는 이러한 단계 중 일부는 실시간에 가까운 방식으로 수행할 수도 없기 때문입니다(예: 새로운 패턴을 관찰한 후 일정 시간이 지난 후에야 계절의 변화가 있다고 말할 수 있음). 앞서 언급한 문제를 고려하여 Cloudflare에서는 기본적인 전처리와 통계를 결합한 알고리즘을 선택했습니다. 이 접근 방식을 이용하면 데이터의 특성에 대한 기대치에 부합하고, 해석이 용이하며, 오탐율을 제어할 수 있고, 앞서 설명한 많은 전처리 단계의 필요성을 줄이면서 빠른 실행을 보장할 수 있습니다.
앞서, 출시 시 약 700개의 엔터티(위치 및 자율 시스템)에 대해 이상을 감지하고 있다고 언급했습니다. 이는 분명히 전체 국가와 네트워크를 대표하지 않으며, 그럴 만한 이유가 있습니다. 이 게시글에서 설명하는 것처럼, 관련 모델을 구축하고 이후 이상을 감지하려면 특정 엔터티에서 충분한 트래픽을 확인해야 합니다(신호가 충분히 강해야 합니다). 일부 소규모 국가나 인구 밀도가 낮은 국가에서는 트래픽 신호가 충분히 강하지 않으며, 많은 자율 시스템의 경우 트래픽 양이 거의 없거나 전혀 없으므로 신호가 너무 약해서 쓸모가 없습니다. 저희는 우선 트래픽 신호가 충분히 강력하거나 트래픽 이상 현상이 발생할 가능성이 있는 지역과 해당 지역 인구의 유의미한 비율을 차지하는 주요하거나 주목할 만한 자율 시스템, 그리고 과거에 트래픽 이상 현상의 영향을 받은 것으로 알려진 시스템에 초점을 맞추고 있습니다.
이상 감지
이 문제를 해결하기 위해 저희가 취한 접근 방식은 과거 데이터에서 확인한 내용에 따라 예상에 부합하는 데이터 포인트 집합인 예측을 생성하는 것입니다. 이에 대해서는 예상 생성 섹션에서 설명합니다. 이 예측을 바탕으로 실제로 관측되는 것과 비교하여 관측되는 것이 예상과 크게 다르면 이상이라고 부릅니다. 여기서는 트래픽 감소에 관심이 있으므로 이상은 항상 예측/예상 트래픽보다 낮은 트래픽에 해당합니다. 이 비교는 예측과 실제 트래픽 비교 섹션에서 자세히 설명합니다.
예측을 계산하려면 다음과 같은 비즈니스 요구 사항을 충족해야 합니다.
저희는 주로 인간 활동과 관련된 트래픽에 관심이 있습니다.
이상을 적시에 감지할수록 더 유용합니다. 이는 데이터 수집 및 데이터 처리 시간과 같은 제약 조건을 고려해야 하지만, 일단 데이터를 사용할 수 있게 되면 최신 데이터 포인트를 사용하여 이상인지 감지할 수 있어야 합니다.
낮은 오탐(FP)율은 높은 정탐(TP)율보다 더 중요합니다. 내부 도구로서 이는 반드시 사실은 아니지만, 저희는 공개적으로 표시되는 알림 서비스로서 일부 예외 사항을 보고하지 않는 대신 허위 항목을 제한하려고 합니다.
관찰할 엔터티 선택
위에 제시된 예 외에도 데이터의 품질은 데이터의 양에 따라 크게 달라지며, 이는 우리가 고려하는 엔터티(위치/AS)에 따라 데이터 품질 수준이 달라진다는 것을 의미합니다. 극단적인 예로, 남극 대륙에서 발생한 중단을 안정적으로 감지할 수 있는 데이터가 충분하지 않습니다. 관찰 대상 엔터티를 선택하는 데 사용한 프로세스는 다음과 같습니다.
AS의 경우, 저희는 주로 사람의 활동을 나타내는 인터넷 트래픽에 관심이 있으므로 APNIC에서 제공하는 사용자수 추정치를 사용합니다. 그런 다음 해당 위치에 있는 각 AS의 사용자 수를 합산하여 위치별 총 사용자 수를 계산한 다음 해당 위치에 대한 AS의 사용자 비율을 계산합니다(이 수치는 APNIC 표의 '국가 %' 열에서도 제공됨). 해당 위치의 사용자가 1% 미만인 AS는 필터링합니다. 포르투갈의 경우 목록은 다음과 같습니다. AS15525(MEO-EMPRESAS)는 포르투갈의 전체 인터넷 사용자 수(추정치)의 1% 미만이기 때문에 제외되었습니다.
이 시점에서 우리는 AS의 하위 집합과 위치 집합을 가지고 있지만(가능한 한 많은 위치를 포함하고자 하므로 선험적으로 어떤 위치도 제외하지 않음), 이상을 자동으로 안정적으로 감지하려면 데이터의 품질에 따라 범위를 좁혀야 합니다. 여러 지표를 테스트하고 결과를 시각적으로 분석한 결과, 안정적인 신호를 가장 잘 예측하는 것은 데이터의 양과 관련이 있다는 결론에 도달하여 2주 동안 매일 최소 고유 IP 수라는 기준을 충족하지 못하는 엔터티는 시각적 검사를 기반으로 임계값을 설정하여 제거했습니다.
예상 생성하기
이상을 적시에 감지하기 위해 15분마다 집계되는 트래픽을 사용하기로 결정했고, 실제 데이터와 비교한 1시간 분량의 데이터(4개 데이터 포인트/15분 단위 블록)를 예측하고 있습니다.
이상을 감지할 엔터티를 선택한 후에는 접근 방식이 아주 간단합니다.
1. 예측 기간 직전 마지막 24시간을 살펴보고 그 간격을 기준으로 삼습니다. 지난 24시간에는 다음 날의 형태에 대한 정보가 포함되어 있다고 가정합니다. 아래 그림에서 지난 24시간(파란색)은 금요일에서 토요일로 넘어가는 데이터에 해당합니다. 유클리드 거리를 사용하여 해당 기준과 가장 유사한 6개의 일치 항목(주황색)을 얻는데, 이 6개의 일치 항목 중 4개는 금요일에서 토요일로의 다른 전환에 해당합니다. 또한 월요일(2023년 8월 14일)부터 화요일까지의 휴일도 캡처하며, 기준과 가장 유사하지 않은 일치 항목인 수요일에서 목요일까지의 정규 근무일도 표시됩니다. 예측은 기준과 가장 유사한 24시간의 중앙값이므로 해당 날짜의 데이터는 결국 폐기되므로 기준이 제대로 표현되지 않는 것을 캡처하는 것은 문제가 되지 않습니다.
이 접근 방식이 작동하도록 저희가 사용하는 두 가지 중요한 매개 변수가 있습니다.
마지막 28일을 고려합니다(기준일은 29일과 같음). 이렇게 하면 주간 계절성을 최소 4회 이상 확인할 수 있고, 시간에 따른 추세 변화와 관련된 위험을 제어하며, 처리해야 하는 데이터의 양에 상한선을 설정할 수 있습니다. 위의 예시를 보면 첫날이 금요일에서 토요일로 넘어가는 시점에 해당하기 때문에 첫날이 기준과 가장 유사성이 높은 날입니다.
또 하나의 매개변수는 가장 유사한 날짜 수입니다. 저희는 경험적 지식의 결과로 6일을 사용하고 있습니다. 주별 계절성을 고려할 때 6일을 사용할 경우 같은 평일과 최대 4일이 일치할 것으로 예상되며, 그 외 2일은 완전히 다른 요일일 수 있습니다. 예측을 생성할 때 중앙값을 사용하므로 여전히 과반수가 4일이므로 남는 날은 기준으로 사용되지 않습니다. 또 하나의 시나리오는 아래 예시와 같이 공휴일인 경우입니다.
이 경우 주중 휴일은 금요일에서 토요일로 넘어가는 것처럼 보입니다. 마지막 28일을 사용하고 있고 휴일이 화요일에 시작되므로, 일치하는 전환이 세 번만 표시되고(주황색) 그 다음에는 정규 근무일이 세 번 더 표시됩니다. 이러한 패턴이 시계열의 다른 곳에서는 찾을 수 없고 가장 가깝게 일치하기 때문입니다. 바로 이것이 짝수 값의 중앙값을 계산할 때 하위 사분위수를 사용하고(데이터의 우수리를 잘라 더 낮은 값으로 내린다는 의미) 그 결과를 예측으로 사용하는 이유입니다. 이는 또한 저희가 더 보수적인 태도를 취할 수 있게 해주며 정탐/오탐의 균형을 맞추는 역할을 합니다.
마지막으로 중단 사례를 살펴보겠습니다.
이 경우, 마지막 24시간(기준)이 일요일에서 월요일로 넘어가는 시점에 해당하고 트래픽이 적기 때문에 유클리드 거리가 가장 낮은 시간대(가장 유사한 24시간)는 토요일(2회) 또는 일요일(4회)이므로 일치는 항상 트래픽이 적은 시점에 연결됩니다. 따라서 예측은 일반적인 월요일에 나타날 것으로 예상되는 트래픽 양이므로 예측(빨간색)은 상승 추세를 보이지만, 중단이 발생했으므로 실제 트래픽 양(검은색)은 예측보다 상당히 낮습니다.
이 접근 방식은 다른 여러 모델링 접근 방식과 마찬가지로 규칙적인 계절 패턴에 대해 효과가 있으며, 휴일 및 기타 이동 이벤트(매년 같은 날짜에 오지 않는 축제 등)의 경우에도 해당 정보를 적극적으로 추가하지 않고도 효과가 있는 것으로 나타났습니다. 그럼에도 불구하고 데이터에 오프셋이 있을 때 특히 실패하는 사용 사례가 여전히 존재합니다. 이것이 바로 데이터 아티팩트로 인해 알고리즘이 영향을 받을 가능성을 줄이기 위해 여러 데이터 소스를 사용하는 이유 중 하나입니다.
아래에는 알고리즘이 시간에 따라 어떻게 작동하는지에 대한 예시가 나와 있습니다.
예측과 실제 트래픽의 비교
예측과 실제 트래픽 양을 파악한 후에는 다음과 같은 단계를 수행합니다.
한 값이 다른 값에 비해 얼마나 변화했는지 측정하는 상대적 변화를 계산합니다. 트래픽 감소를 기준으로 이상을 감지하므로 실제 트래픽은 항상 _예측치_보다 낮습니다.
이 메트릭을 계산한 후 다음 규칙을 적용합니다.
실제와 예측의 차이는 신호 크기의 10% 이상이어야 합니다. 이 크기는 선택한 데이터의 95번째 백분위수와 5번째 백분위수의 차이를 이용하여 계산됩니다. 트래픽이 적은 시간대, 특히 하루 중 사용량이 적은 시간대와 실제 트래픽의 작은 변화가 상대적 변화의 큰 변화에 해당하는 시나리오는 예측치도 낮으므로 피하는 것이 좋습니다. 예:
예측값 100Gbps와 실제값 80Gbps를 비교하면 -0.20(-20%)의 상대적 변화가 발생합니다.
예측값 20Gbps와 실제값 10Gbps를 비교하면 총량의 감소는 이전 예제보다 훨씬 작지만 상대적인 변화는 -0.50(50%)이 됩니다.
그런 다음 상당히 낮은 트래픽을 감지하는 두 가지 규칙이 있습니다.
지속되는 이상: 예측 기간 내내 상대적 변화가 주어진 임계값 α 미만입니다(네 개의 데이터 포인트 모두에 대해). 이를 통해 시간이 지남에 따라 확장되는 더 약한 이상(상대적 변화가 더 작은)를 감지할 수 있습니다.
포인트 이상: 예측 기간의 마지막 데이터 포인트의 상대적 변화가 주어진 임계값 β(여기서 β < α - 이 임계값은 음수입니다. 예를 들어 β와 α는 각각 -0.6과 -0.4일 수 있습니다.) 이 경우 데이터의 확률적 특성으로 인해 이상을 트리거하지 않으면서도 갑작스러운 단기간의 트래픽 감소를 감지할 수 있도록 β < α가 필요합니다.
α와 β의 값은 오탐률을 허용 가능한 수준으로 유지하면서 감지율을 최대화하기 위해 경험적으로 선택되었습니다.
이상 이벤트 종료하기
저희가 전달하고자 하는 가장 중요한 메시지는 이상이 시작되는 시기이지만, 인터넷 트래픽 양이 정상으로 돌아가는 시점을 감지하는 것도 중요한데, 그 이유는 두 가지입니다.
_활성 이상_이라는 개념이 필요한데, 이는 이상을 감지했고 그 이상이 여전히 진행 중이라는 것을 의미합니다. 이를 통해 이상이 여전히 활성 상태인 동안에는 기준에 대한 새로운 데이터를 고려하지 않을 수 있습니다. 해당 데이터가 기준 및 가장 유사한 24시간 세트의 선택에 영향을 미칠 수 있다는 점을 고려한 것입니다.
트래픽이 정상으로 돌아간 후 이상이 지속된 기간을 알면 해당 데이터 포인트를 이상치로 표시하고 대체할 수 있으므로 기준으로 사용하거나 기준과 가장 잘 일치하는 데이터 포인트로 대체할 수 있습니다. 중앙값을 사용하여 예측을 계산하고, 대부분의 경우 이것으로 이상 데이터의 존재를 극복하기에 충분하지만, 예제 4로 사용된 AS203214(HulumTele)의 경우와 같이 하루 중 같은 시간에 중단이 자주 발생하여 며칠 후 이상 데이터가 예상되는 시나리오가 있습니다.
이상을 감지할 때마다 데이터가 정상으로 돌아올 때까지 동일한 기준을 유지하며, 그렇지 않으면 기준에 이상이 있는 데이터가 포함되기 시작합니다. 트래픽이 정상으로 돌아오는 시점을 결정하기 위해 α보다 낮은 임계값을 사용하고, 이상이 없어야 트래픽이 종료되는 시간(현재 4시간)을 설정합니다. 이는 트래픽이 감소했다가 다시 정상으로 돌아왔다가 다시 감소하는 상황을 방지하기 위한 것입니다. 저희는 그러한 경우 하나의 이상을 감지하고 이를 집계하여 여러 개의 알림을 보내는 것을 방지하고자 하며, 의미론적 측면에서는 동일한 이상과 관련이 있을 가능성이 높습니다.
결론
인터넷 트래픽 데이터는 일반적으로 예측이 가능하므로 이론적으로는 아주 간단한 이상 감지 알고리즘을 구축하여 인터넷 중단을 감지할 수 있습니다. 그러나 관찰 대상(위치 또는 AS)에 따른 시계열이 이질적이고 데이터에 아티팩트가 존재하므로 실시간으로 추적하려면 많은 컨텍스트가 필요하며, 이는 몇 가지 문제를 야기합니다. 여기에서는 이 문제를 어렵게 만드는 구체적인 사례를 보여드리고, 대부분의 장애물을 극복하기 위해 이 문제에 어떻게 접근했는지 설명했습니다. 이 접근 방식은 트래픽 이상을 감지하는 데 매우 효과적이면서도 오탐률을 낮추는 것으로 나타났으며, 이는 저희의 최우선 과제 중 하나입니다. 정적 임계값 접근 방식이므로 지금까지 설명한 것만큼 급격하지 않은 이상은 감지하지 못한다는 단점이 있습니다.
저희는 더 많은 엔터티를 추가하고 알고리즘을 개선하여 더 광범위한 이상을 다룰 수 있도록 계속 노력할 계획입니다.
인터넷 중단, 라우팅 문제, 인터넷 트래픽 동향, 공격, 인터넷 품질 등에 대한 추가 인사이트를 보려면 Cloudflare Radar를 방문하세요. 소셜 미디어에서 @CloudflareRadar(Twitter), Cloudflare.social/@radar(Mastodon), radar.Cloudflare.com(Bluesky)을 팔로우하거나 이메일을 통해 문의하세요.