Cloudflareは2023年だけでも、1月に1回、3月に1回、そしてSpeed Weekでも1回、Zero Trustのパフォーマンスを深く掘り下げ、すべての記事で、当社が実施する一連のテストの概要を説明し、当社が最速であることを示してきました。これは売名行為であると考える人もいるかもしれませんが、そうではありません。私たちが考案したテストは、当社を意図的に最速に見せるように都合良く作られたものではなく、ネットワークテストの結果、当社が最速であることを示しています。
パフォーマンスが重要である理由については、以前にもブログで説明しましたが、簡単に言うと、パフォーマンスが低下することで、ユーザーが自分たちに有利なエクスペリエンスを得るために私たちが一番避けたいZero Trustの機能を停止させてしまうことに繋がり、これが脅威の要因ともなり得るということです。私たちの目標は、パフォーマンスを向上させることであり、このことがユーザーのセキュリティやお客様にとって最も重要なもののセキュリティを向上させ、ユーザーの生産性を高めることに繋がります。
Zero Trustのパフォーマンスをテストする場合、まず、ユーザーがパケットを送信してから、Zero Trustプロキシがパケットを受信、転送、検査し、宛先のWebサイトがパケットを処理し、ユーザーに戻されるまでのエンドツーエンドの遅延時間を測定します。HTTPレスポンスと呼ばれるこの数値は、CDNのパフォーマンスを測定するためのアプリケーションサービステストでよく使用されます。私たちはZero Trustのサービスの測定にもこれを使用していますが、これがパフォーマンスを測定する唯一の方法というわけではありません。プロキシ遅延と呼ばれるものでパフォーマンスを測定するZscalerや、復号化された遅延SLAでパフォーマンスを測定するNetskopeも存在します。プロバイダの中には、パフォーマンスをまったく考慮していないところもあります！
ネットワークのパフォーマンスを確認する方法には様々なものがあります。しかし、 Cloudflareでは、パフォーマンスを測定する最善の方法は、エンドツーエンドのHTTPレスポンスを測定することだと考えています。このブログでは、エンドツーエンドのパフォーマンスが注目すべき最も重要である理由、プロキシ遅延や復号化遅延SLAなどの他の方法ではパフォーマンス評価に不十分である理由、および私たちのようにZero Trustパフォーマンスを測定する方法について紹介します。
最初から始めましょう
どのようなシナリオであれ、パフォーマンスを評価する際に最も重要なことは、その測定対象を決めることです。これは当然のことのように思えるかもしれませんが、私たちの評価対象が、実際にユーザーが体験する影響を測定する対象として適していないことがよくあります。その好例が、ユーザーによるネットワーク速度テストが挙げられます。帯域幅を測定しても、インターネット接続の速さを正確に測定することはできません。
そこで、私たちは「ユーザーはどのようにZero Trust製品に接するのか？」という根本的な問いを自らに投げかける必要があります。その答えは、「ユーザーは、自分がZero Trustと接していることを知るべきではない」ということです。ユーザーが実際には接するのはインターネット上のどこかでホストされているWebサイトやアプリケーションであり、それはMicrosoft Exchangeのプライベートインスタンス、またはクラウド上のSalesforceかもしれません。どのような場合でも、その間に位置するZero Trustサービスは、ユーザーからのパケットを受信し、セキュリティとアクセス評価のためにフィルタリングを行い、パケットを宛先に送信するフォワードプロキシとして機能します。サービスが適切に機能していれば、ユーザーはその存在に気付くことはありません。
そのため、Zero Trustを検討するときには、隠れた存在からその存在を感じるようになるシナリオを検討する必要があります。つまり、Zero Trustサービスがその存在を主張するほどに高遅延、あるいはアプリケーションの障害が発生する場合です。これらのシナリオをシミュレートするためには、ユーザーが日常的にアクセスするサイトにアクセスする必要があります。Zero Trustプラットフォームを通してこれらのWebサイトへのアクセスをシミュレートすることで、リクエスト経路上にZero Trustが存在する場合の影響を確認することができます。
幸いなことに、私たちはWebサイトへのユーザーリクエストをシミュレートする方法を熟知しています。私たちには開発者プラットフォームやネットワークベンチマーク分析のためにパフォーマンスを測定した豊富な経験があります。Zero Trustのパフォーマンスを当社の他のパフォーマンス分析の取り組みと組み合わせることで、パフォーマンスを向上させることが容易になり、可能な限り多くの人々が高速化することに集中できるようになります。他のCloudflare製品の分析と同様に、このアプローチはお客様とユーザーを第一に考え、最高のパフォーマンスを得られるようにします。
オープンインターネットの課題
Zero Trustサービスの利用は、ユーザーとアクセス対象となるサービスとの間に追加のネットワークホップが自動的に追加されるため、パフォーマンスに関してその性質上不利な立場にあります。これはトラフィックをフィルタリングして保護するためのフォワードプロキシがユーザーとパブリックインターネットの間に位置するためです。これは、Zero Trustサービスは、エンドユーザのISP側との接続性と、クラウドプロバイダ側との接続性の両方を維持し、尚且つほぼすべてのパブリックインターネットトラフィックを送受信するサービスを接続するトランジットネットワークとの接続性を維持する必要があることを意味します。これは通常、ピアリングや相互接続関係を通じて行われます。これらすべての接続性を維持することに加え、サービスが実際にルールやパケット検査を処理する時間も必要です。これらすべての課題を考えると、このシナリオにおけるパフォーマンス管理は複雑です。
一部のプロバイダは、パフォーマンスを制限することでこれを回避しようとします。これは本質的にZscalerのプロキシ遅延やNetskopeの復号化による遅延と同様で、ネットワーク経路の制御が難しい部分は無視して制御可能なリクエストの側面だけに焦点を当てる試みです。具体的には、リクエストがZscalerやNetskopeの物理ハードウェア上でかかる時間だけに焦点を当てています。この利点は、これらのプロバイダが遅延に関してある程度の保証をすることができることです。このような考え方は伝統的に、リクエストをインラインで処理しない可能性のあるハードウェアファイアウォールやCASBサービスを置き換えようとすることから生まれたものです。ZscalerとNetskopeは、リクエストに対してインラインでルールとアクションを処理しても高いパフォーマンスを維持できることを証明しようとしています。
しかし、1月のブログで示したように、リクエストがZero Trustネットワークの機械の上で過ごす時間は、エンドユーザが経験するリクエスト時間のごく一部にすぎません。リクエストは、その時間の大半がマシン間の回線上で費やされます。パフォーマンスを見るときは、機体上の処理による遅延のような単一の要素ではなく、全体的に見る必要があります。つまり、パフォーマンスを機体上の処理遅延だけに限定して観察した場合、実際のパフォーマンスの全体像とは程遠いものとなります。高速であるためには、プロバイダはネットワークのあらゆる側面とその機能に目を向ける必要があります。それでは、Zero Trustサービスのパフォーマンスを向上させるために必要なすべての要素についてお話しましょう。
Zero Trustのパフォーマンスを向上させる方法は？
Zero Trustのパフォーマンスについて考える場合、高速道路を運転するようなものと考えるとよいでしょう。空腹を感じた場合、高速道路上のなるべく近場の短時間で行ける場所を目指します。1秒でハンバーガーを提供するレストランが15分もかかるところにある場合、その提供速度は問題にはならず、そのレストランまで移動するだけの価値はないと言えます。休憩所にあるマクドナルドは、他のレストランと移動時間は同じかもしれませんが、素早く提供してくれます。高速道路上の近場にある、素早く提供してくれるレストランを選びましょう。1つの要素だけに注目しても、もう一方が遅い場合、全体のタイムに影響します。
ここまでの話しから、Zero Trustのパフォーマンスを向上させる最善の方法は、処理時間が良好であることに加えて、ラストワンマイルでの良好なピアリング、重要なアプリケーションをホストするネットワークとの良好なピアリング、そしてインターネット上に万が一の場合にトラフィックを迂回させられる多様な経路を確保することです。ここからは、それぞれについてと、その重要性について説明して行きます。
ラストマイルのピアリング
パフォーマンスの向上は、ユーザーとの距離を縮めることが重要であることは以前にも説明しましたが、ここで簡単にまとめておきます。Zero Trustパケットを受信するプロバイダが物理的にユーザーの近くにあることで、デバイスとアクセス対象となるアプリケーション間を通るパケットの経路に迂回がなくなります。Zero Trustネットワークでは常に追加のホップが発生するため、そのホップが通常Webサイトへのリクエストが通る経路と同じであれば、Zero Trustネットワークで発生するオーバーヘッドは最小限になります。
上の3つの接続モデル図をご覧ください。1つはユーザーから直接Webサイトに接続するもの、1つは一般的なフォワードプロキシを経由するもの、もう1つはCloudflareを経由するものです。それぞれの線の長さは、点から点までにかかる時間を表しています。図から分かるように、フォワードプロキシを経由すると2つのセグメントの合計が直接接続よりも長くなります。この追加の移動経路を、ネットワークの世界では「ヘアピン」と呼びます。目標は、ユーザーとWebサイトの間の線を最短距離にするため、できるだけまっすぐに保つことです。
Zero Trustプロバイダとお客様の距離が近ければ近いほど、経路を短く保つことが容易になります。私たちは、ユーザーの場所に関わらず、12,000を超えるピアリングネットワークを活用し、ユーザーがどこに居ても近くに位置するための投資を絶えず行っているため、Zero Trustのこの課題に絶対的な自信を持っています。
クラウドのピアリング
しかし、ユーザーとの距離を縮めることはこの戦いの半分にすぎません。トラフィックがZero Trustネットワーク上にある場合、それを宛先に配信する必要があります。多くの場合、これらの宛先は、Azure、Amazon Web Services、Googleクラウドなどのハイパースケールクラウドプロバイダでホストされています。これらのハイパースケーラは、ユーザーがデータを保存し、サービスをホストするための何百もの場所を保有するグローバルネットワークです。Zero Trustネットワークがコンピューティング環境を提供するすべての場所のすべてのネットワークと適切にピアリングされていない場合、その直線経路は分岐し始めます。その分岐による影響はラストワンマイルよりも少ないものですが、エンドユーザが気付くには十分です。
Cloudflareは、これらの主要なクラウドプロバイダと適切にピアリングされているため、Cloudflareと各クラウド間の受け渡しを短時間かつシームレスに行うことができます。Cloudflareは世界40都市以上の主要なクラウドプロバイダとピアリングしているため、アプリケーションがどこでホストされていても、接続することができます。
その間のすべての経路には別の経路があります
Zero Trustがネットワークがラストワンマイルで良好な接続性とクラウドへの高い接続性を確保できている場合、残された課題は両者間でのトラフィックの受け渡しのみとなります。Zero Trustネットワーク内に多様なネットワーク経路を持つことは、ネットワーク上の問題を回避するためにトラフィックを迂回させて信頼性とパフォーマンスの高いZero Trustネットワーク上のプライベート接続を提供する上で、非常に重要となります。Cloudflareはこの目的のために独自のプライベートバックボーンを活用しており、このバックボーンがあらゆるシナリオタイプでより一層高いパフォーマンスを提供するのに役立っています。
重要な測定値の取得
では、私たちがどのようなシナリオを測定し、それをどのように高速化するかについて理解いただいたところで、それらをどのように測定しているのでしょうか？答えは非常にシンプルです。Zero Trustサービスを通じてHTTPコールを行い、その応答時間を測定します。ゲートウェイのテストを実施する際、Zero Trustクライアントを介して、多くの企業で一般的に使用されているWebサイトに定期的に接続するクライアントプログラムを作成し、Http-Timingを測定してHTTPレスポンスを計算します。
前述したように、レスポンスとは、ユーザーがパケットを送信してから、Zero Trustプロキシがパケットを受信、転送、検査して宛先のWebサイトにパケットを送信し、宛先のWebサイトがパケットを処理し、ユーザーにレスポンスが返されるまでの時間を指します。この測定は、Webアプリケーションがコンテンツを読み込んで描画する能力ではなく、ネットワークパフォーマンスに特に焦点を当てることができるため、価値があります。Largest Contentful Paint（最大コンテンツの描画、LCP）に関しては、宛先のソフトウェアスタック、宛先がCDNによってフロントされているかどうか、そのパフォーマンスがどうであるか、またはリクエストを行うブラウザに依存するため、私たちはこれの測定は行っていません。私たちは、Zero Trustサービスが、デバイスからWebサイトへのパケットをどれだけうまく送受信できるかを測定したいと考えています。現在の測定方法は、クライアントにレスポンスを配信する時間に重点を置いており、ブラウザの描画時間（Largest Contentful Paint）などの一部のクライアント側の処理や、UDPでの動画配信のようなアプリケーション固有のメトリックを無視したものになっています。
誰もが可能
パフォーマンスの測定は複雑に思われるかもしれませんが、Cloudflareでは簡単に行えるように努めています。ユーザーエクスペリエンスを測定するというお客様のゴールと、より高速なエクスペリエンスを提供するという当社のゴールは完全に一致しており、パフォーマンスを表示するために当社が構築したツールは、ユーザーに使用していただくだけでなく、パフォーマンス改善のために社内でも使用されています。Digital Experience Monitoring（DEM）製品は、単に問題が発生している場所を示すだけでなく、Zero Trustのパフォーマンスを監視して、お客様のユーザー体験を追跡するために開発されました。私たちはこのデータを使用して、ネットワーク上の回帰や問題を特定し、お客様が快適にご利用いただけるようにします。DEMを使用することで、私たちがテストで行っているように、関心のあるエンドポイントを測定するテストを作成して、CloudflareダッシュボードでそのHTTPレスポンスの結果を見ることができます。そして、より多くのテストを実施し、お客様のエクスペリエンスをよりよく可視化すればするほど、当社のネットワークおよび広範なインターネット全体でのエクスペリエンスをよりよく確認できるようになります。
Cloudflareの他のすべての製品と同様に、私たちのパフォーマンス測定はユーザーを考慮して設計されています。これらの数値を測定して調査すると、これらの数値を改善することで、Zero Trustユーザーのエンドツーエンドのエクスペリエンスが向上することがわかります。