Cloudflare 시스템이 전 세계 트래픽을 동적으로 라우팅하는 방법

공항에 도착해 공항 보안 검색대를 통과하는 상황을 상상해 보세요. 탑승권과 여권을 스캔하고 여러분을 탑승구로 보내 주는 직원이 여러 명 있습니다. 갑자기 일부 상담원이 휴식을 취합니다. 검문소 위 천장에 누수가 있을 수 있습니다. 또는 오후 6시에 출발하는 항공편이 많아서 한꺼번에 많은 승객이 몰릴 수도 있습니다. 어느 쪽이든, 국지적인 수요와 공급의 불균형으로 인해 줄을 서서 비행기를 타려고 하는 여행객들이 오래 기다려야 하는 불편함을 겪을 수 있습니다. 공항에서는 이를 어떻게 처리하나요?

일부 공항에서는 아무 조치도 취하지 않고 긴 줄을 서서 기다리게 할 수도 있습니다. 일부 공항에서는 유료로 검색대를 통과하는 패스트 레인 서비스를 제공할 수 있습니다. 하지만 대부분의 공항에서는 탑승구까지 최대한 빨리 통과할 수 있도록 조금 더 멀리 떨어진 다른 보안 검색대로 가도록 안내합니다. 각 줄의 길이를 알려주는 표지판이 있어서 통과할 때 더 쉽게 결정할 수 있는 경우도 있습니다.

Cloudflare에서도 동일한 문제를 겪고 있습니다. 우리는 전 세계 300개 도시에서 모든 제품군에 대한 최종 사용자 트래픽을 수신할 수 있도록 운영하고 있습니다. 이상적인 세계에서는 항상 가장 가까운 위치에서 모든 사람을 처리할 수 있는 충분한 컴퓨터와 대역폭을 갖추고 있습니다. 하지만 유지보수를 위해 데이터 센터를 오프라인으로 전환하거나 데이터 센터 연결이 끊기거나 일부 장비에 장애가 발생하는 등, 세상이 항상 이상적인 것은 아닙니다. 이 경우 모든 위치에서 보안 검색을 통과하는 모든 사람에게 서비스를 제공할 수 있는 직원이 충분하지 않을 수 있습니다. 키오스크가 부족해서가 아니라 데이터 센터에 문제가 발생하여 모든 사람에게 서비스를 제공할 수 없게 된 것입니다.

그래서 전체 글로벌 네트워크에서 수요와 공급의 균형을 맞추는 도구인 트래픽 관리자를 구축했습니다. 이 블로그에서는 트래픽 관리자의 탄생 배경, 구축 과정, 현재 기능에 대해 설명합니다.

현재 트래픽 관리자가 수행하는 작업은 네트워크 엔지니어가 수동으로 수행하는 프로세스로, 특정 데이터 센터에서 사용자 트래픽이 영향을 받는 문제가 발생하기 전까지 네트워크는 정상적으로 작동합니다.

이러한 이벤트가 발생하면 사용자의 요청 부하를 처리할 컴퓨터가 충분하지 않아 사용자 요청이 499 또는 500 오류와 함께 실패하기 시작했습니다. 그러면 네트워크 엔지니어에게 페이지가 전송되고, 엔지니어는 해당 데이터 센터에 대한 일부 Anycast 경로를 제거합니다. 최종 결과: 영향을 받은 데이터 센터에서 해당 접두사를 더 이상 광고하지 않음으로써 사용자 트래픽이 다른 데이터 센터로 우회할 수 있습니다. 사용자 트래픽은 보더 게이트웨이 프로토콜에 의해 결정된 대로 사용자가 연결하려는 접두사를 광고하는 가장 가까운 데이터 센터로 유도되는 것이 애니캐스트의 기본 작동 방식입니다. 애니캐스트에 대해 자세히 알아보려면이 참조 문서를확인하세요.

문제가 얼마나 심각한드에 따라 엔지니어는 데이터 센터의 일부 또는 모든 경로를 제거합니다. 데이터 센터가 다시 모든 트래픽을 흡수할 수 있게 되면 엔지니어는 경로를 다시 설정하고, 트래픽은 자연스럽게 데이터 센터로 돌아오게 됩니다.

네트워크의 하드웨어에 문제가 발생할 때마다 매번 그렇게 해야 했으므로 네트워크 엔지니어에게는 어려운 작업이었습니다. 확장되는 작업이 아니었습니다.

하지만 수작업으로 처리하는 것은 네트워크 운영팀에게만 부담이 되는 일이 아니었습니다. 또한 엔지니어가 트래픽을 진단하고 경로를 재설정하는 데 시간이 걸리기 때문에 고객 경험도 기대 이하로 떨어졌습니다. 이 두 가지 문제를 모두 해결하기 위해 사용자가 Cloudflare 데이터 센터에 연결할 수 없는 경우 즉시 자동으로 감지하고 사용자가 더 이상 문제를 겪지 않을 때까지 데이터 센터에서 경로를 철회하는 서비스를 구축하고자 했습니다. 서비스에서 영향을 받은 데이터 센터가 트래픽을 흡수할 수 있다는 알림을 받으면 경로를 다시 설정하고 해당 데이터 센터에 다시 연결할 수 있습니다. 이 서비스는 (짐작할 수 있듯이) Cloudflare 네트워크로 들어오는 트래픽을 관리하는 역할을 하기 때문에 트래픽 관리자라고 불립니다.

네트워크 엔지니어는 라우터에서 경로를 제거할 때 사용자 요청이 어디로 이동할지 가장 잘 추측하고 장애 조치 데이터 센터에 요청을 처리할 수 있는 충분한 리소스가 있는지 확인할 수 있으며, 그렇지 않은 경우 초기 데이터 센터에서 경로를 제거하기 전에 그에 따라 해당 데이터 센터의 경로를 조정할 수 있습니다. 이 프로세스를 자동화하려면 직관의 세계에서 데이터의 세계로 전환하여 경로가 제거되었을 때 트래픽이 어디로 이동할지 정확하게 예측하고, 이 정보를 트래픽 관리자에게 전달하여 상황을 악화시키지 않도록 해야 했습니다.

어떤 데이터 센터가 경로를 광고할지는 조정할 수 있지만, 각 데이터 센터가 수신하는 트래픽의 비율에는 영향을 미칠 수 없습니다. 새로운 데이터 센터 또는 새로운 피어링 세션을 추가할 때마다 트래픽 분포가 변경되며, 300개 이상의 도시와 12,500개의 피어링 세션이 있기 때문에 사람이 네트워크에서 트래픽이 이동하는 방식을 추적하거나 예측하는 것은 매우 어려워졌습니다. 트래픽 관리자에게는 친구인 트래픽 예측기가 필요했습니다.

트래픽 예측기는 그 역할을 수행하기 위해 트래픽이 실제로 어디로 이동하는지 확인하기 위해 일련의 실제 테스트를 지속적으로 수행합니다. 트래픽 예측기는 데이터 센터를 서비스에서 제거하고 해당 데이터 센터가 트래픽을 처리하지 않을 경우 트래픽이 어디로 이동하는지 측정하는 시뮬레이션 테스트 시스템을 사용합니다. 이 시스템의 작동 방식을 이해하기 위해 뉴질랜드 크라이스트처치에 있는 데이터 센터의 하위 집합을 제거하는 시뮬레이션을 해보겠습니다:

• 먼저 트래픽 예측기는 크라이스트처치에 정상적으로 연결되는 모든 IP 주소 목록을 가져옵니다. 트래픽 예측기는 최근에 요청을 보낸 수십만 개의 IP에 핑 요청을 보냅니다.

• 트래픽 예측기는 IP가 응답하는지 여부와 응답이 트래픽 예측기용으로 특별히 구성된 특수 Anycast IP 범위를 사용하여 크라이스트처치로 반송되는지 여부를 기록합니다.

• 트래픽 예측기가 크라이스트처치에 응답하는 IP 목록을 확보하면, 크라이스트처치에서 해당 특정 범위가 포함된 경로를 제거하고 인터넷 라우팅 테이블이 업데이트될 때까지 몇 분간 기다린 후 테스트를 다시 실행합니다.

• 응답이 크라이스트처치로 라우팅되는 대신 크라이스트처치 주변의 데이터 센터로 전송됩니다. 그런 다음 트래픽 예측기는 각 데이터 센터에 대한 응답 지식을 사용하여 크라이스트처치에 대한 장애 조치로 결과를 기록합니다.

이를 통해 실제로 크라이스트처치를 오프라인으로 전환하지 않고도 크라이스트처치가 오프라인 상태가 되는 시뮬레이션을 할 수 있습니다!

하지만 트래픽 예측기는 한 데이터 센터에서만 이러한 기능을 수행하는 것이 아닙니다. 각 데이터 센터 장애 시나리오에 대해 트래픽 예측기는 장애 시나리오를 계산하고 주변 데이터 센터에 장애가 발생했을 때를 대비한 정책을 생성하는 두 번째 계층의 복원력도 계산합니다.

앞의 예시를 사용하여 트래픽 예측기가 크라이스트처치를 테스트할 때, 크라이스트처치를 포함한 여러 주변 데이터 센터를 서비스에서 제거하는 일련의 테스트를 실행하여 다양한 장애 시나리오를 계산합니다. 이를 통해 한 지역의 여러 데이터 센터에 영향을 미치는 치명적인 상황이 발생하더라도 사용자 트래픽을 계속 제공할 수 있습니다. 이러한 모든 장애 경로와 정책을 계산하는 데 며칠이 걸리기 때문에 이 데이터 모델이 복잡하다고 생각하신다면, 그 생각이 맞습니다.

전 세계 모든 데이터 센터의 장애 경로와 장애 복구 시나리오를 시각화하면 다음과 같습니다:

사람이 해석하기에는 다소 복잡할 수 있으므로 뉴질랜드 크라이스트처치에 대한 위의 시나리오를 좀 더 명확하게 설명하기 위해 자세히 살펴보겠습니다. 크라이스트처치에 대한 장애 조치 경로를 구체적으로 살펴보면 다음과 같습니다:

이 시나리오에서는 크라이스트처치 트래픽의 99.8%가 오클랜드로 이동하여 정전 시 크라이스트처치의 모든 트래픽을 흡수할 수 있다고 예상합니다.

트래픽 예측기를 사용하면 문제가 발생할 경우 트래픽이 어디로 이동할지 확인할 수 있을 뿐만 아니라, 트래픽 관리자 정책을 사전 구성하여 요청을 장애 조치 데이터 센터 밖으로 이동시켜, 첫 번째 데이터 센터에 문제가 발생했을 때 갑작스러운 요청의 유입으로 두 번째 데이터 센터에 장애가 발생하는, 선더링 허드 시나리오를 방지할 수 있습니다. 트래픽 예측기를 통해 트래픽 관리자는 한 데이터 센터에 장애가 발생했을 때 트래픽을 다른 데이터 센터로 이동시킬 뿐만 아니라, 다른 데이터 센터로 트래픽을 선제적으로 이동시켜 서비스를 원활하게 지속할 수 있도록 합니다.

트래픽 예측기를 통해 트래픽 관리자는 모든 데이터 센터가 모든 트래픽을 처리할 수 있도록 보장하면서 접두사를 역동적으로 광고하고 철회할 수 있습니다. 하지만 트래픽 관리 수단으로 접두사를 철회하는 것은 때때로 다소 번거로울 수 있습니다. 그 한 가지 이유는 데이터 센터에 트래픽을 추가하거나 제거할 수 있는 유일한 방법이 인터넷에 연결된 라우터의 광고 경로를 통해서만 가능했기 때문입니다. 각 경로에는 수천 개의 IP 주소가 있으므로 그중 하나만 제거해도 트래픽의 상당 부분을 차지합니다.

특히, 인터넷 앱은 최소 /24 서브넷에서 인터넷으로 연결되는 접두사를 광고하지만, 많은 경우 이보다 더 큰 접두사를 광고합니다. 이는 일반적으로 경로 유출 또는 경로 하이재킹과 같은 것을 방지하기 위한 것으로, 많은 제공업체가 실제로 /24보다 더 구체적인 경로를 필터링합니다(이에 관한 자세한 내용은 여기에서 이 블로그를확인하세요 ) . Cloudflare가 보호 속성을 IP 주소에 1:1 비율로 매핑한다고 가정하면, 각 /24 서브넷은 /24 서브넷에 있는 IP 주소 수인 256명의 고객에게 서비스를 제공할 수 있습니다. 모든 IP 주소가 초당 하나의 요청을 전송한다고 가정하면, 초당 1,000개의 요청을 이동해야 하는 경우 데이터 센터에서 4개의 /24 서브넷을 이동해야 합니다(RPS).

하지만 실제로 Cloudflare는 단일 IP 주소를 수십만 개의 보호 자산에 매핑합니다. 따라서 Cloudflare의 경우 /24는 초당 3,000개의 요청을 처리할 수 있지만, 1,000개의 RPS를 이동해야 하는 경우 /24 하나를 이동하는 것 외에는 다른 방법이 없습니다. 이는 /24 레벨로 광고한다고 가정했을 때입니다. 웹 사이트와 IP 주소가 1:1로 매핑되는 경우 각 접두사 당 초당 4,096건의 요청이 발생하고, 웹 사이트와 IP 주소가 다대일 매핑되는 경우에는 그보다 훨씬 더 많은 요청이 발생합니다.

접두사 광고를 철회하면 499 또는 500 오류가 발생했을 사용자들의 고객 경험은 개선되었지만, 문제의 영향을 받지 않았을 사용자들 중 상당수는 여전히 이동해야 할 데이터 센터에서 멀어져 속도가 조금이라도 느려졌을 수 있습니다. 필요 이상으로 많은 트래픽을 외부로 이동시키는 이 개념을 "좌초 용량"이라고 합니다. 이론적으로는 데이터 센터가 한 지역에서 더 많은 사용자에게 서비스를 제공할 수 있지만, 트래픽 관리자가 구축된 방식 때문에 그럴 수 없습니다.

문제가 발생한 데이터 센터에서 더 이상 용량을 낭비하지 않고 절대적으로 최소한의 사용자만 이동시키도록 트래픽 관리자를 개선하고자 했습니다. 그러기 위해서는 접두사의 비율을 변경해야 했기 때문에 더욱 세분화하여 꼭 이동해야 하는 항목만 이동시킬 수 있었습니다. 이 문제를 해결하기 위해 레이어 4 로드 밸런서인 Unimog의확장을 구축했으며 , 이를 Plurimog라고부릅니다.

Unimog와 레이어 4 부하 분산에 대한 간략한 설명: 모든 머신에는 해당 머신이 사용자 요청을 처리할 수 있는지 여부를 결정하는 서비스가 포함되어 있습니다. 머신이 사용자 요청을 받을 수 있는 경우, 요청을 처리한 후 사용자에게 반환하기 전에 요청을 처리하는 HTTP 스택으로 요청을 보냅니다. 머신이 요청을 처리할 수 없는 경우, 머신은 요청을 처리할 수 있는 데이터 센터의 다른 머신으로 요청을 보냅니다. 기계는 사용자 요청을 처리할 수 있는지 여부를 파악하기 위해 끊임없이 서로 대화하기 때문에 이러한 작업을 수행할 수 있습니다.

Plurimog는 동일한 작업을 수행하지만, 기계 간에 통신하는 게 아니라 데이터 센터와 PoP 간에 통신합니다. 요청이 필라델피아로 들어왔는데 필라델피아에서 요청을 처리할 수 없는 경우, Plurimog는 요청을 처리할 수 있는 다른 데이터 센터(예: 애슈번)로 요청을 전달하여 요청을 해독하고 처리합니다. Plurimog는 레이어 4에서 작동하기 때문에 개별 TCP 또는 UDP 요청을 다른 곳으로 보낼 수 있어 고도의 세분화가 가능합니다. 즉, 트래픽의 일정 비율을 다른 데이터 센터로 매우 쉽게 보낼 수 있으므로, 모든 사용자에게 최대한 빠른 서비스를 제공하기에 충분한 트래픽만 보내면 됩니다. 데이터 센터의 문제를 처리하기 위해 점점 더 많은 트래픽을 다른 곳으로 이전할 수 있는 프랑크푸르트 데이터 센터에서 어떻게 작동하는지 확인해 보세요. 이 차트는 시간 경과에 따라 프랑크푸르트에서 전송된 Free 트래픽에 대해 수행된 작업의 수를 보여줍니다:

하지만 데이터 센터 내에서도 트래픽이 데이터 센터를 벗어나지 않도록 트래픽을 라우팅할 수 있습니다. 멀티 콜로 프레즌스(MCP)라는 대규모 데이터 센터에는 데이터 센터 내에서 서로 구분되는 논리적 컴퓨팅 섹션이 포함되어 있습니다. 이러한 MCP 데이터 센터는 Duomog라는 또 다른 버전의 Unimog와 함께 사용되며, 이를 통해 컴퓨팅의 논리적 섹션 간에 트래픽을 자동으로 전환할 수 있습니다. 이를 통해 MCP 데이터 센터는 고객의 성능 저하 없이 내결함성을 확보할 수 있으며, 트래픽 관리자는 데이터 센터 내에서만이 아니라 데이터 센터 간에도 작동할 수 있습니다.

이동 요청의 일부를 평가할 때 트래픽 관리자는 다음을 수행합니다:

• 트래픽 관리자는 데이터 센터 또는 데이터 센터의 하위 섹션에서 제거해야 하는 요청의 비율을 식별하여 모든 요청을 처리할 수 있도록 합니다.

• 그런 다음 트래픽 관리자는 각 대상에 대한 집계된 공간 메트릭을 계산하여 각 장애 조치 데이터 센터가 처리할 수 있는 요청 수를 확인합니다.

• 그런 다음 트래픽 관리자는 각 요금제에서 이동해야 하는 트래픽의 양을 파악하고 충분한 트래픽을 이동할 때까지 요금제의 일부 또는 요금제 전체를 Plurimog/Duomog를 통해 이동합니다. Free 고객을 먼저 이동하고, 데이터 센터에 더 이상 Free 고객이 없는 경우 Pro를 이동한 다음 필요한 경우 Business 고객을 이동합니다.

예를 들어, MCP 중 하나인 버지니아주 애슈번을 살펴봅시다. 애슈번에는 각각 트래픽을 수용할 수 있는 9개의 서로 다른 하위 섹션이 있습니다. 8/28일, 해당 하위 섹션 중 하나인 IAD02에서 처리할 수 있는 트래픽 양을 떨어뜨리는 문제가 발생했습니다.

이 기간 동안 Duomog는 IAD02에서 애슈번 내의 다른 하위 섹션으로 더 많은 트래픽을 전송하여 애슈번이 Always Online을 유지하도록 했으며, 이 문제가 발생하는 동안 성능에 영향을 미치지 않았습니다. 그런 다음 IAD02가 다시 트래픽을 처리할 수 있게 되면 Duomog는 자동으로 트래픽을 다시 전환했습니다. 이러한 작업은 아래 시계열 그래프에서 시각화하여 확인할 수 있으며, 이 그래프는 IAD02 내의 용량 하위 섹션(녹색으로 표시됨) 간에 시간 경과에 따라 이동한 트래픽의 비율을 추적합니다:

위의 예에서는 초당 요청 수를 사용했지만 실제로 트래픽을 이동할 때 초당 요청 수를 지표로 사용하는 것은 충분히 정확하지 않습니다. 그 이유는 고객마다 서비스에 소요되는 리소스 비용이 다르기 때문입니다. WAF가 비활성화된 상태에서 캐시를 중심으로 제공되는 웹 사이트는 모든 WAF 규칙이 활성화되고 캐싱이 비활성화된 사이트보다 CPU 비용이 훨씬 저렴합니다. 따라서 각 요청이 CPU에서 소요되는 시간을 기록합니다. 그런 다음 각 요금제에서 CPU 시간을 집계하여 요금제별 CPU 시간 사용량을 찾을 수 있습니다. CPU 시간을 ms 단위로 기록하고 초당 값을 취하여 초당 밀리초 단위로 계산합니다.

CPU 시간은 대기 시간과 고객 성능에 영향을 미칠 수 있기 때문에 중요한 지표입니다. 예를 들어, 아이볼 요청이 Cloudflare 프론트 라인 서버를 완전히 통과하는 데 걸리는 시간을 생각해 보겠습니다. 이를 cfcheck 대기 시간이라고 합니다. 이 수치가 너무 높아지면 고객이 눈치채기 시작하고 나쁜 경험을 하게 될 것입니다. cfcheck 대기 시간이 길어지면, 이는 일반적으로 CPU 사용률이 높기 때문입니다. 아래 그래프는 동일한 데이터 센터에 있는 모든 머신의 CPU 사용률과 비교한 백분위수 95의 cfcheck 대기 시간을 표시한 것으로, 강력한 상관관계를 확인할 수 있습니다:

따라서 트래픽 관리자가 데이터 센터의 CPU 시간을 확인하게 하는 것은 고객에게 최상의 경험을 제공하고 문제 방지를 보장하는 매우 좋은 방법입니다.

요금제별 CPU 시간을 파악한 후에는 해당 CPU 시간 중 얼마나 많은 시간을 다른 데이터 센터로 이동해야 하는지 파악해야 합니다. 이를 위해 모든 서버의 CPU 사용률을 집계하여 데이터 센터 전체에 단일 CPU 사용률을 제공합니다. 네트워크 장치 장애, 정전 등으로 인해 데이터 센터의 일부 서버에 장애가 발생하면 해당 서버에 도달하던 요청은 Duomog에 의해 데이터 센터 내의 다른 곳으로 자동 라우팅됩니다. 서버 수가 감소하면 데이터 센터의 전체 CPU 사용률이 증가합니다. 트래픽 관리자에는 각 데이터 센터에 대해 최대 임계값, 목표 임계값, 허용 가능한 임계값의 세 가지 임계값이 있습니다:

• 최대: 트래픽 관리자가 조치를 취하게 될, 성능 저하가 시작되는 CPU 수준입니다

• 목표: 사용자에게 최적의 서비스를 복원하기 위해 트래픽 관리자가 CPU 사용률을 줄이려고 시도하는 수준입니다

• 허용 가능: 데이터 센터가 다른 데이터 센터에서 전달된 요청을 수신하거나 활성 이동을 되돌릴 수 있는 수준입니다

데이터 센터가 최대 임계값을 초과하면 트래픽 관리자는 모든 요금제에서 현재 CPU 사용률 대비 총 CPU 시간의 비율을 계산한 다음 이를 목표 CPU 사용률에 적용하여 목표 CPU 시간을 찾습니다. 이렇게 하면 각 데이터 센터의 서버 수에 관해 걱정할 필요 없이 100대의 서버가 있는 데이터 센터와 10대의 서버가 있는 데이터 센터를 비교할 수 있습니다. 이 가정은 부하가 선형적으로 증가한다고 가정하며, 이 가정이 우리의 목적에 유효할 정도로 참에 가깝습니다.

목표 비율은 현재 비율과 같습니다:

그러므로:

현재 CPU 시간에서 목표 CPU 시간을 빼면 이동에 필요한 CPU 시간을 알 수 있습니다:

예를 들어, 현재 데이터 센터의 CPU 사용률이 90%이고 목표가 85%이며 모든 요금제에서 CPU 시간이 18,000시간인 경우입니다:

이는 트래픽 관리자가 1,000 CPU 시간을 이동해야 한다는 뜻입니다:

이제 이동에 필요한 총 CPU 시간을 알았으므로 이동에 필요한 시간이 충족될 때까지 요금제를 진행할 수 있습니다.

우리가 직면한 빈번한 문제는 데이터 센터에서 트래픽 관리자가 조치를 취해야 하는 시점, 즉 어떤 메트릭을 감시해야 하며 허용 가능한 수준은 어느 정도인지 결정하는 것이었습니다.

앞서 말했듯이 서비스마다 CPU 사용률에 대한 요구 사항이 다르고, 데이터 센터의 사용 패턴이 매우 다른 경우가 많습니다.

이 문제를 해결하기 위해 머신러닝을 활용했습니다. 고객 대면 지표에 따라 각 데이터 센터의 최대 임계값을 자동으로 조정하는 서비스를 만들었습니다. 주요 서비스 수준 지표(SLI)로는 앞서 설명한 cfcheck 대기 시간 지표를 사용하기로 결정했습니다.

하지만 머신 러닝 앱이 임계값을 조정할 수 있도록 서비스 수준 목표(SLO)도 정의해야 합니다. 우리는 SLO를 20ms로 설정했습니다. SLO와 SLI를 비교하면 95번째 백분위수 cfcheck 대기 시간은 절대 20ms를 넘지 않아야 하며, 초과할 경우 무언가 조치를 취해야 합니다. 아래 그래프는 시간 경과에 따른 95번째 백분위수 참조 대기 시간을 보여 주며, 참조 대기 시간이 빨간색 영역으로 넘어가면 고객들의 불만이 커지기 시작합니다:

CPU가 너무 높아지면 고객이 좋지 않은 경험을 하는 경우, 트래픽 관리자의 최대 임계값의 목표는 고객 성능에 영향을 미치지 않도록 하고 성능이 저하되기 전에 트래픽을 다른 곳으로 리디렉션하는 것입니다. 트래픽 관리자 서비스는 예약된 간격으로 각 데이터 센터에 대한 여러 메트릭을 가져와 일련의 머신 러닝 알고리즘을 적용합니다. 이상값에 대한 데이터를 정리하고 나면 간단한 2차 곡선 맞춤을 적용하는데, 현재는 선형 회귀 알고리즘을 테스트하고 있습니다.

모델을 맞추고 나면 이를 사용하여 SLI가 SLO와 같을 경우의 CPU 사용량을 예측한 다음 이를 최대 임계값으로 사용할 수 있습니다. 아래 그래프에서 바르셀로나의 경우 곡선 적합도와 선형 회귀 적합도를 각각 비교한 결과에서 볼 수 있듯이, CPU 값을 SLI와 비교하면 이러한 방법이 데이터 센터에 적합한 이유를 명확하게 알 수 있습니다.

이 차트에서 수직선은 SLO이며, 이 선과 적합 모델의 교차점은 최대 임계값으로 사용될 값을 나타냅니다. 이 모델은 매우 정확한 것으로 입증되었으며, SLO 위반을 크게 줄일 수 있었습니다. 리스본에서 이 서비스를 언제부터 배포하기 시작했는지 살펴봅시다:

변경 전에는 cfcheck 대기 시간이 지속적으로 급증했지만 최대 임계값이 정적이었기 때문에 트래픽 관리자가 조치를 취하지 않았습니다. 하지만 7월 29일 이후에는 고객이 CPU 증가로 인해 영향을 받지 않도록 지속적으로 측정하고 있기 때문에 cfcheck 대기 시간이 SLO에 도달한 적이 없습니다.

이제 최대 임계값이 있으므로 이동해야 할 트래픽 양을 계산할 때 사용되지 않는 세 번째 CPU 사용률 임계값, 즉 허용 임계값을 찾아야 합니다. 데이터 센터가 이 임계값보다 낮으면 트래픽을 직접 전달하지 않는 한 다른 데이터 센터가 필요할 때 사용할 수 있는 미사용 용량을 보유하게 됩니다. 각 데이터 센터가 받을 수 있는 양을 계산하기 위해 위와 동일한 방법론을 사용하여 목표를 허용 가능한 것으로 대체합니다:

그러므로:

현재 CPU 시간에서 허용 가능한 CPU 시간을 빼면 데이터 센터가 수용할 수 있는 CPU 시간의 양을 알 수 있습니다:

트래픽을 전송할 위치를 찾기 위해 트래픽 관리자는 모든 데이터 센터에서 사용 가능한 CPU 시간을 찾은 다음 트래픽을 이동해야 하는 데이터 센터의 대기 시간별로 순서를 정합니다. 다음 데이터 센터로 이동하기 전에 최대 임계값에 따라 사용 가능한 모든 용량을 사용하여 각 데이터 센터를 이동합니다. 이동할 요금제를 찾을 때는 우선순위가 가장 낮은 요금제에서 가장 높은 요금제로 이동하지만, 어디로 보낼지 찾을 때는 그 반대 방향으로 이동합니다.

더 명확하게 이해할 수 있도록 예를 들어 보겠습니다:

데이터 센터 A에서 1,000개의 CPU 시간을 이동해야 하며, 요금제별 사용량은 다음과 같습니다: Free: 500ms/s, Pro: 400ms/s, Business: 200ms/s, Enterprise: 1000ms/s.

Free (500ms/s) 100%, Pro (400ms/s) 100%, Business (100ms/s) 50%, Enterprise 0%를 이동합니다.

인근 데이터 센터의 CPU 사용 가능 시간은 다음과 같습니다: B: 300ms/s, C: 300ms/s, D: 1,000ms/s.

대기 시간 포함: A-B: 100ms, A-C: 110ms, A-D: 120ms.

대기 시간이 가장 짧고 조치가 필요한 우선 순위가 가장 높은 요금제부터 시작하여, 모든 Business CPU 시간을 데이터 센터 B로 옮기고 Pro의 절반을 옮길 수 있습니다. 다음으로 데이터 센터 C로 이동하여 나머지 Pro와 20%의 Free를 옮길 수 있습니다. 그런 다음 나머지 Free를 데이터 센터 D로 전달하여 다음과 같은 작업을 수행할 수 있습니다: Business: 50% → B, Pro: 50% → B, 50% → C, Free: 20% → C, 80% → D.

트래픽 관리자가 데이터 센터가 임계값을 초과하지 않도록 지속적으로 관리하는 것과 같은 방식으로, 포워딩된 트래픽을 트래픽을 활발하게 포워딩하는 데이터 센터로 다시 가져오는 방법도 모색하고 있습니다.

위에서 트래픽 관리자가 데이터 센터가 다른 데이터 센터로부터 수신할 수 있는 트래픽의 양을 계산하는 방법을 살펴봤는데, 이를 가용 CPU 시간이라고 합니다. 활성 이동이 있는 경우 이 가용 CPU 시간을 사용하여 데이터 센터로 트래픽을 되돌리며, 항상 다른 데이터 센터의 트래픽을 수용하는 것보다 활성 이동을 되돌리기를 우선시합니다.

이 모든 것을 종합하면, 모든 데이터 센터의 시스템 및 고객 상태 메트릭을 지속적으로 측정하고 트래픽을 분산하여 현재 네트워크 상태를 고려하여 각 요청을 처리할 수 있도록 하는 시스템을 갖추게 됩니다. 이러한 데이터 센터 간의 모든 이동을 지도에 표시하면, 다음과 같이 1시간 동안의 모든 트래픽 관리자 이동을 표시한 지도를 볼 수 있습니다. 이 지도에는 전체 데이터 센터 배포가 표시되어 있지는 않지만, 이 기간 동안 이동된 트래픽을 송수신하는 데이터 센터가 표시됩니다:

빨간색 또는 노란색으로 표시된 데이터 센터는 부하가 발생하여 녹색이 될 때까지 트래픽을 다른 데이터 센터로 이동하고 있으며, 이는 모든 메트릭이 정상으로 표시됨을 의미합니다. 원의 크기는 해당 데이터 센터에서 또는 해당 데이터 센터로 이동하는 요청의 수를 나타냅니다. 트래픽이 이동하는 위치는 선이 이동하는 위치로 표시됩니다. 전 세계 규모에서는 확인하기 어려우므로 미국으로 확대하여 같은 기간 동안의 실제 상황을 확인해 보겠습니다:

여기에서 토론토, 디트로이트, 뉴욕, 캔자스시티는 하드웨어 문제로 인해 일부 요청을 처리할 수 없으므로 사용자와 데이터 센터의 균형이 회복될 때까지 해당 요청을 댈러스, 시카고, 애슈번으로 보내게 됩니다. 디트로이트와 같은 데이터 센터가 트래픽을 다른 곳으로 보낼 필요 없이 수신되는 모든 요청을 처리할 수 있게 되면, 디트로이트는 데이터 센터의 문제가 완전히 해결될 때까지 시카고로의 요청 포워딩을 점진적으로 중단할 것이며, 완결된 시점에는 더 이상 아무것도 포워딩하지 않게 됩니다. 이 모든 과정에서 최종 사용자는 온라인 상태이며 디트로이트 또는 트래픽을 전송하는 다른 위치에서 발생할 수 있는 물리적 문제의 영향을 받지 않습니다.

트래픽 관리자는 사용자 경험에 연결되어 있기 때문에 Cloudflare 네트워크의 기본 구성 요소로서 제품을 온라인 상태로 유지하고 가능한 한 빠르고 안정적으로 유지합니다. 실시간 부하 분산 장치로, 문제가 있는 데이터 센터에서 필요한 트래픽만 이동시켜 제품을 빠르게 유지하도록 도와줍니다. 트래픽 이동이 적기 때문에 제품과 서비스가 빠르게 유지됩니다.

하지만 트래픽 관리자는 제품의 안정성 문제가 발생할 수 있는 위치를 예측하고 선제적으로 제품을 다른 곳으로 옮길 수 있기 때문에 제품의 온라인 상태를 안정적으로 유지하는 데도 도움이 됩니다. 예를 들어, 브라우저 격리는 트래픽 관리자와 직접 연동하여 제품의 가동 시간을 보장합니다. 호스팅된 브라우저 인스턴스를 생성하기 위해 Cloudflare 데이터 센터에 연결하면, 브라우저 격리에서는 먼저 트래픽 관리자에게 데이터 센터에 인스턴스를 로컬에서 실행할 수 있는 충분한 용량이 있는지 묻고, 그렇다면 인스턴스가 바로 그 자리에서 만들어집니다. 사용 가능한 용량이 충분하지 않은 경우 트래픽 관리자는 브라우저 격리에게 사용 가능한 용량이 충분한 가장 가까운 데이터 센터를 알려주어 브라우저 격리가 사용자에게 최상의 경험을 제공할 수 있도록 지원합니다.

Cloudflare에서는 다양한 제품과 고객 시나리오를 모두 서비스하기 위해 이 거대한 네트워크를 운영하고 있습니다. 한 번의 장애로 인한 영향을 줄이기 위해 설계된 MCP 위치 외에도 내부 및 외부 문제에 대응하여 네트워크의 트래픽을 지속적으로 이동시키는 등 복원력을 위해 네트워크를 구축했습니다.

하지만 이는 여러분의 문제가 아니라 저희의 문제입니다.

마찬가지로 사람이 이러한 문제를 해결해야 할 때 영향을 받는 것은 고객과 최종 사용자입니다. Always Online에 접속할 수 있도록 하드웨어 장애를 감지하고 네트워크 전반의 트래픽을 선제적으로 분산하여 온라인 상태를 최대한 빠르게 유지할 수 있는 스마트 시스템을 구축했습니다. 이 시스템은 누구보다 빠르게 작동하여 네트워크 엔지니어가 밤에 잠을 자게 해줄 뿐만 아니라 모든 고객에게 더 나은 빠른 경험을 제공합니다.

마지막으로, 이러한 종류의 엔지니어링 도전이 흥미롭게 느껴진다면 Cloudflare의 채용 페이지에서트래픽 엔지니어링 팀의 공개 채용을 확인해 보세요!