Cloudflare에서는 2023년에만 1월에 한 번, 3월에 한 번, Speed Week에 한 번 등 Zero Trust 성능에 대해 여러 차례 심층 분석을 수행했습니다. 각 테스트에서 저희는 수행하는 일련의 테스트를 개략적으로 설명하고 저희가 가장 빠르다는 것을 보여줍니다. 일부에서는 이것이 마케팅 전략이라고 생각할 수도 있지만, 그렇지 않습니다. 저희가 고안한 테스트가 반드시 저희를 최고로 보이게 하기 위해 만들어진 것은 아니며, 테스트를 실행할 때 저희 네트워크가 저희를 최고로 보이게 해주는 것입니다.
이전 블로그에서 성능이 중요한 이유를 설명한 적이 있지만, 간단히 요약하면 성능 저하는 위협 요인이며, 귀사의 사용자가 이용 가능한 경험을 얻기 위해 Zero Trust를 꺼버리는 것이 가장 바람직하지 않습니다. 저희 목표는 성능을 향상하는 것입니다. 그래야만 귀사 사용자의 보안과 귀사에 가장 중요한 사항의 보안을 개선하고 귀사 사용자의 생산성을 높이는 데 도움이 되기 때문입니다.
Zero Trust 성능 테스트를 실행할 때는 사용자가 패킷을 보내는 시점부터 Zero Trust 프록시에서 패킷을 수신, 전달, 검사하는 시점, 대상 웹 사이트에서 패킷을 처리한 후 사용자에게 돌아갈 때까지의 엔드투엔드 대기 시간을 측정하는 것으로 시작합니다. HTTP 응답이라고 불리는 이 수치는 앱 서비스 테스트에서 CDN의 성능을 측정하는 데 자주 사용됩니다. 저희는 Zero Trust 서비스를 측정하는 데도 이 방법을 사용하지만, 이것이 성과를 측정하는 유일한 방법은 아닙니다. Zscaler는 프록시 대기 시간이라는 것을 통해 성능을 측정하는 반면, Netskope는 복호화된 대기 시간 SLA를 통해 성능을 측정합니다. 일부 공급자는 성능에 대해 전혀 고려하지 않습니다!
네트워크 성능을 확인하는 방법에는 여러 가지가 있습니다. 그러나 Cloudflare에서는 성능을 측정하는 가장 좋은 방법은 엔드투엔드 HTTP 응답 측정을 사용하는 것이라고 믿습니다. 이 블로그에서는 엔드투엔드 성능을 가장 중요하게 봐야 하는 이유, 프록시 대기 시간 및 해독된 대기 시간 SLA 등의 다른 방법이 성능 평가에 불충분한 이유, 저희처럼 Zero Trust 성능을 측정하는 방법에 관해 이야기해 보겠습니다.
맨 처음부터 시작하기로 하죠
모든 시나리오의 성과를 평가할 때 가장 중요하게 고려해야 할 것은 정확히 무엇을 측정해야 하는가 하는 것입니다. 이는 당연해 보일 수 있지만, 종종 우리가 평가하는 항목이 실제로 사용자가 느끼는 영향을 제대로 측정하지 못하는 경우가 많습니다. 예를 들어 사용자가 네트워크 속도 테스트를 볼 때 대역폭을 측정하는 것으로는 인터넷 연결 속도를 정확하게 측정하지 못합니다.
따라서 우리는 스스로 근본적인 질문을 해봐야 합니다. 사용자가 Zero Trust 제품과 어떻게 상호 작용할까? 정답은 사용자가 상호작용하지 않아야 하거나 Zero Trust와 상호작용하고 있는 것을 몰라야 한다는 것입니다. 사용자는 실제로 인터넷 어딘가에서 호스팅되는 웹 사이트 및 앱과 상호 작용합니다. Microsoft Exchange의 비공개 인스턴스와 상호 작용하거나 클라우드의 Salesforce에 액세스하고 있을 수도 있습니다. 어떤 경우든 그 사이에 있는 Zero Trust 서비스는 사용자로부터 패킷을 수신하고 보안 및 액세스 평가를 위해 필터링한 다음 패킷을 목적지로 전송하는 포워드 프록시 역할을 합니다. 서비스가 제대로 작동하면 사용자는 서비스의 존재를 전혀 알아차리지 못합니다.
따라서 Zero Trust 서비스를 볼 때 우리는 투명성이 불투명해지는 시나리오를 살펴봐야 합니다. 이 경우는 Zero Trust 서비스가 스스로를 드러내어 대기 시간이 길어지거나 앱 장애가 발생하는 때입니다. 이러한 시나리오를 시뮬레이션하려면 사용자가 정기적으로 액세스하는 사이트에 액세스해야 합니다. Zero Trust 플랫폼을 통해 해당 웹 사이트에 액세스하는 시뮬레이션을 해보면 요청 경로에 Zero Trust가 있을 때 어떤 일이 발생하는지 살펴볼 수 있습니다.
다행히도 저희는 웹 사이트를 방문하는 사용자 요청을 시뮬레이션하는 방법을 정확히 알고 있습니다. 개발자 플랫폼과 네트워크 벤치마킹 분석을 위한 성능 측정에 많은 경험이 있습니다. 다른 성능 분석 이니셔티브의 맥락에서 Zero Trust 성능의 틀을 잡으면 성능을 개선하고 최대한 많은 사람이 최대한 빨리 이용할 수 있도록 하는 데 모든 노력을 집중할 수 있습니다. 다른 Cloudflare 제품에 대한 분석과 마찬가지로, 이 접근 방식은 고객과 사용자를 최우선으로 생각하며 최상의 성능을 보장합니다.
개방형 인터넷의 도전 과제
Zero Trust 서비스는 사용자와 액세스하려는 서비스 사이에 자동으로 네트워크 홉을 추가하므로 성능 측면에서 당연히 불리한 점이 있습니다. 그 이유는 포워드 프록시가 사용자와 공용 인터넷 사이에 위치하여 트래픽을 필터링하고 보호하기 때문입니다. 이는 Zero Trust 서비스가 최종 사용자 인터넷 서비스 공급자와의 연결을 유지하고, 클라우드 공급자와의 연결을 유지하며, 대부분의 공용 인터넷 트래픽을 송수신하는 서비스를 연결하는 네트워크를 경유해야 한다는 것을 의미합니다. 이는 일반적으로 피어링 및 상호 연결 관계를 통해 이루어집니다. 이러한 모든 연결성을 유지하는 것 외에도 서비스가 실제로 규칙과 패킷 검사를 처리하는 데 걸리는 시간도 있습니다. 이러한 모든 문제를 고려할 때 이 시나리오의 성능 관리는 복잡합니다.
일부 공급자는 성능 범위를 축소하여 이를 우회하려고 시도합니다. 이는 본질적으로 제어하기 어려운 네트워크 경로의 일부를 제거하고 제어할 수 있는 요청의 측면에만 집중하려는 시도로, Zscaler의 프록시 대기 시간과 Netskope의 해독된 대기 시간이 이에 해당합니다. 좀 더 구체적으로 설명하자면, 이러한 대기 시간은 요청이 Zscaler 또는 Netskope의 물리적 하드웨어에서 보내는 시간에만 초점을 맞춥니다. 이 방법의 장점은 이러한 공급자가 대기 시간에 대해 어느 정도 보장할 수 있다는 것입니다. 이러한 사고 방식은 전통적으로 요청을 인라인으로 처리하지 못하는하드웨어 방화벽과CASB 서비스를 대체하려는 시도에서 비롯되었습니다. Zscaler와 Netskope는 요청과 함께 규칙과 작업을 인라인으로 처리하면서도 성능을 유지할 수 있다는 것을 입증하려고 노력하고 있습니다.
하지만 지난 1월 블로그에서 살펴본 바와 같이 Zero Trust 네트워크의 컴퓨터에서 소요되는 시간은 최종 사용자가 경험하는 요청 시간의 일부에 불과합니다. 요청 시간의 대부분은 컴퓨터와 컴퓨터 사이를 연결하는 데 소요됩니다. 성능을 살펴볼 때는 온박스 처리 대기 시간과 같은 단일 요소가 아닌 전체적 관점에서 살펴봐야 합니다. 따라서 성능을 온박스 처리 대기 시간으로만 범위를 좁히면 실제로는 성능의 전모를 볼 수 없습니다. 속도를 높이려면 공급자는 네트워크의 모든 측면과 네트워크가 작동하는 방식을 살펴봐야 합니다. 이제 Zero Trust 서비스 성능을 개선하는 데 필요한 모든 요소에 대해 이야기해 보겠습니다.
Zero Trust 성능을 개선하려면 어떻게 해야 할까요?
Zero Trust 성능은 고속도로에서 운전하는 것과 같다고 생각하면 됩니다. 배가 고파서 음식을 먹어야 한다면 고속도로에서 가까운 곳에 빨리 가고 싶을 것입니다. 1초 안에 버거를 제공하는 레스토랑이 고속도로에서 15분 벗어난 곳에 있다면, 버거를 얼마나 빨리 제공하는지는 중요하지 않습니다. 해당 레스토랑에 도착하는 데 걸리는 시간 때문에 거기까지 갈 가치가 없습니다. 휴게소에 있는 맥도날드는 그 레스토랑과 동일한 시간이 소요될 수 있지만, 전체적으로는 더 빠릅니다. 선택해야 하는 레스토랑은 고속도로에서 가깝고 음식을 빠르게 제공해야 합니다. 두 측면 중 하나만 보면, 다른 측면이 느린 경우, 전체 시간에 영향이 미칩니다.
이 비유에 따르면, Zero Trust 성능을 개선하는 가장 좋은 방법은, 처리 시간도 짧아야 하지만, 라스트 마일에서 잘 피어링되고, 중요한 앱을 호스팅하는 네트워크와 잘 피어링되며, 문제가 발생할 경우 트래픽을 우회할 수 있는 인터넷의 다양한 경로를 확보하는 것입니다. 이들 각 요소와 그 중요성에 대해 살펴보겠습니다.
라스트 마일 피어링
이전에 성능 향상을 위해 사용자에게 더 가까이 다가가는 것이 얼마나 중요한지에 대해 설명한 적이 있지만, 간단히 요약해 보겠습니다. 패킷을 물리적으로 가까운 곳에서 수신하는 Zero Trust 공급자가 있으면 장치와 액세스하려는 앱 간에 패킷이 이동하는 경로가 직선화됩니다. Zero Trust 네트워킹은 항상 추가 홉이 발생하므로 해당 홉이 웹 사이트에 대한 요청이 일반적으로 이동하는 경로와 인라인이면 Zero Trust 네트워크에서 발생하는 오버헤드가 최소화됩니다.
위의 다이어그램에서는 사용자가 직접 웹 사이트로 연결되는 모델, 일반 포워드 프록시를 거치는 모델, Cloudflare를 경유하는 모델 등 세 가지 연결 모델을 볼 수 있습니다. 각 선의 길이는 지점 간 대기 시간을 나타냅니다. 이를 바탕으로 두 세그먼트가 합산되어 길기 때문에 직접 연결보다 포워드 프록시 경로가 더 길다는 것을 알 수 있습니다. 이 추가 이동 경로를 네트워킹 세계에서는 헤어핀이라고 부릅니다. 사용자와 웹 사이트 사이의 선을 최대한 직선으로 유지하는 것이 목표인데, 그 이유는 사용자와 웹 사이트 사이의 거리가 가장 짧기 때문입니다.
Zero Trust 공급자가 사용자와 가까울수록 경로를 짧게 유지하는 것이 더 쉬워집니다. 이러한 도전은 저희가 정말 잘 할 수 있는 일입니다. Cloudflare에서는 12,000개 이상의 피어링 네트워크를 활용하여 사용자가 어디에 있든 사용자에게 더 가까이 다가가기 위해 항상 투자하고 있기 때문입니다.
클라우드 피어링
하지만 사용자에게 다가가는 것은 전투의 절반에 불과합니다. 트래픽이 Zero Trust 네트워크에 도달하면 목적지로 전달해야 합니다. 이러한 대상은 대부분 Azure, Amazon Web Services, Google Cloud 등의 하이퍼스케일 클라우드 공급자가 호스팅합니다. 이러한 하이퍼스케일러는 사용자가 데이터를 저장하고 서비스를 호스팅할 수 있는 위치가 수백 개 있는 전역 네트워크입니다. Zero Trust 네트워크가 컴퓨팅을 제공하는 모든 곳에서 이러한 모든 네트워크와 잘 피어링되지 않는다면, 그 직선 경로는 라스트 마일보다는 못하지만, 최종 사용자가 알아차릴 수 있을 만큼 충분히 분산되기 시작합니다.
Cloudflare에서는 이러한 주요 클라우드 공급자가 있는 곳에서 피어링되어 Cloudflare와 각 클라우드 간의 핸드오프가 짧고 원활하게 이루어질 수 있도록 지원합니다. Cloudflare에서는 전 세계 40여 개의 대도시에서 주요 클라우드 공급자와 피어링하므로, 앱이 호스팅되는 곳이면 어디에서든 Cloudflare를 통해 연결할 수 있습니다.
사이에 있는 모든 것을 위한 대체 경로
Zero Trust 네트워크의 라스트 마일 연결이 양호하고 클라우드 연결이 양호하면 남은 문제는 두 네트워크 간에 트래픽을 전달할 수 있는 능력뿐입니다. Zero Trust 네트워크 내에서 다양한 네트워크 경로를 갖추고 있는 것은 네트워킹 문제를 중심으로 트래픽을 전환하고 Zero Trust 네트워크에서 안정적이고 성능이 우수한 사설 연결을 제공할 수 있다는 점에서 매우 유용합니다. Cloudflare에서는 이러한 목적으로 자체 사설 백본을 활용하며, 이러한 백본은 모든 시나리오 유형에 대해 한 차원 높은 성능을 제공하는 데 도움이 됩니다.
중요한 측정 값 얻기
이제 어떤 시나리오를 측정하고 어떻게 하면 더 빠르게 측정할 수 있는지 알았으니 어떻게 측정해야 할까요? 그 답은 간단합니다. Zero Trust 서비스를 통해 HTTP 호출을 하고 응답 시간을 측정하는 것입니다. 게이트웨이 테스트를 수행할 때는 Zero Trust 클라이언트를 통해 기업에서 일반적으로 사용하는 여러 웹 사이트에 주기적으로 접속하는 클라이언트 프로그램을 구성하고 HTTP 타이밍을 측정하여 HTTP 응답을 계산합니다.
앞서 설명한 것처럼 응답이란 사용자가 Zero Trust 프록시로 패킷을 보내면 이 프록시가 패킷을 수신, 전달, 검사한 다음 대상 웹 사이트로 패킷을 전송하여 패킷을 처리하고 사용자에게 응답을 반환하는 데 걸리는 시간입니다. 이 측정은 반드시 웹 앱의 콘텐츠 로드 및 렌더링 능력이 아니라 네트워크 성능에 집중할 수 있다는 점에서 가치가 있습니다. 최대 콘텐츠풀 페인트와 같은 항목은 대상의 소프트웨어 스택, 대상에 CDN이 있는지 여부와 그 성능, 심지어 요청을 하는 브라우저에 따라 종속성이 있으므로 저희는 측정하지 않습니다. 저희는 Zero Trust 서비스가 장치에서 웹 사이트로 패킷을 얼마나 잘 전달할 수 있는지 측정하기를 원합니다. 저희 현재 측정 방법은 클라이언트에 응답을 전달하는 시간에 초점을 맞추고 있으며 브라우저 렌더링 시간(최대 큰 콘텐츠풀 페인트)과 같은 일부 클라이언트 측 처리 및 UDP 동영상 전송과 같은 앱별 지표는 무시합니다.
여러분도 할 수 있습니다
성능 측정은 복잡해 보일 수 있지만, Cloudflare에서는 이를 쉽게 만들기 위해 노력하고 있습니다. 사용자 경험을 측정하려는 사용자의 목표와 더 빠른 경험을 제공하려는 Cloudflare의 목표는 완벽하게 일치하며, 성능을 보기 위해 구축한 도구는 사용자 대면뿐만 아니라 내부적으로도 성능 개선을 위해 사용됩니다. 저희가 목적에 맞추어 구축한 Digital Experience Monitoring 제품은 단순히 어디에서 문제가 발생하고 있는지 보여줄 뿐만 아니라 Zero Trust 성능을 모니터링하여 사용자 경험을 추적할 수 있도록 하기 위한 것입니다. Digital Experience Monitoring을 사용하면 고객도 저희 테스트에서와 마찬가지로 관심 있는 엔드포인트를 측정하는 테스트를 만들 수 있으며, Cloudflare 대시보드에서 HTTP 응답에 대한 결과를 확인할 수 있습니다. 더 많은 테스트를 수행하고 사용자 경험에 대한 가시성을 확보할수록, 네트워크와 더 넓은 인터넷에서 Zero Trust 경험을 더 잘 파악하는 데 도움이 됩니다.
Cloudflare의 다른 모든 기능과 마찬가지로 성능 측정도 사용자를 염두에 두고 설계되었습니다. 저희는 이러한 수치를 측정하고 조사할 때, 이러한 수치를 개선함으로써 Zero Trust 사용자의 엔드투엔드 경험을 개선할 수 있다는 것을 알게 됩니다.