10年以上の歩み : Instant Purge の進化

動的コンテンツ配信には、即時のキャッシュ無効化が不可欠です。ニュース速報、ライブイベントの更新、eコマースのプロモーションはすべて、古い情報を迅速にパージする能力に依存しています。

では、Instant Purge の課題を解決することが、10年以上前に取り組んだときと同じくらい今日でも難しいのはなぜでしょうか。現代のエッジネットワークは世界中に分散しています。これらすべてのキャッシュノードでほぼ同時かつ確実に無効化することは、決して簡単なことではありません。無効化イベントを数ミリ秒以内にすべてのアクティブノードに伝達する必要があるからです。さらに、信頼性、速度、スケーラビリティ、カバレッジの間で常に調整を行う必要があります。キャッシュの一貫性を損なうことなくレイテンシを最小限に抑え、同時にまさしく「瞬時」と言えるほどのパフォーマンスを実現する必要があるのですから、これはかなりの難題です。他社が追いつこうと試みるのに10年以上かかったのも不思議ではありません。

一元化か、分散化か

何年も前にこの問題に取り組んだとき、私たちはこの問題の主な解決方法は2つあることに気づきました。「一元化」または「分散化」です。一般的な解決策は、パージリクエストを中央システムに送信し、そのシステムが世界中のキャッシュからコンテンツを削除するよう調整する方法です。この方法は一見簡単に思えるかもしれませんが、単一障害点と高いレイテンシを引き起こすため、即時の成果をあげるには理想的とは言えません。

私たちは、この課題を異なる視点から見るようになりました。一元化されたコマンド構造に頼るのではなく、「パージを分散型メッセージングの問題として捉えれば、分散化する方法で解決できるのではないか」と自問したのです。そのうえで、パージリクエストを中央システムに戻すのではなく、エッジで傍受し、その場でロジックを使用して迅速に配信してはどうだろうかと考えました。

とは言え、この分散型アプローチにも課題がないわけではありません。この方法だとビルドが難しくなり、複雑さが増します。サーバー同士が一時的にアクセスできなくなる場合や、メッセージがトランジット中に紛失・遅延する可能性もあります。しかし、私たちはその解決方法を見つけました。

Instant Purge が機能する仕組み

私たちのシステムは、Bimodal Multicast と呼ばれるアルゴリズムに基づいています。このアルゴリズムは高速で理解しやすく、メッセージが最終的に配信されることが保証されています。実際の仕組みは次のようになります。キャッシュサーバーがパージリクエストを受信すると、UDP を使用して他のすべてのサーバーにメッセージを即座にブロードキャストします。配信拠点 (POP) 間の通常のパケットロス率は0.1%未満であり、パージレイテンシは多くの場合、ネットワーク遅延によってのみ制限されます。

私たちのシステムの重要な概念の1つとして、パージメッセージの確認応答を必要としないことがあります。このステップをスキップすることで、レイテンシを最大で半分に削減できます。また、ルーティングに関してもあまり巧妙に考えようとはしません。そうではなく、私たちはパージをあらゆる場所にブロードキャストします。これは非効率的に見えるかもしれませんが、実際には簡素化につながります。Fastly のすべてのノードは、同じトラフィックを均等に処理する能力があります。つまり、コンテンツの場所の複雑なマップを管理することなく、どこにでもパージリクエストを送信できるということです。これはネットワークの成長に伴ってスケーラビリティも向上する、よりシンプルで堅牢なアプローチです。

ネットワークアーキテクチャへのアプローチも Fastly に優位性をもたらします。最大限のエッジキャッシュストレージと、よりスマートなプログラムコントロールを実現するために、Fastly は配信拠点を構築しました。実行する配信拠点の数を意図的に減らしつつより高性能にすることで、ネットワークの複雑さを軽減し、パージメッセージを受信する必要があるサーバーの数を最小限に抑えています。このアーキテクチャに決定することで、Instant Purge に大きなメリットがもたらされます。さらに、Fastly のソフトウェア定義ネットワークにより、ハードウェアの制約に縛られることなく即座にパージシステムを適応させ、最適化することが可能です。

成功までの道筋

おそらく皆さんは、「このシステムはうまく拡張したのか？顧客数やトラフィックが増加しても、パフォーマンスは引き続き良好なのか？このアプローチはうまくいったのか？」と考えておられるでしょう。簡単に言えば、答えは「はい」です。当初の設計から予想していたように、処理できるトラフィックを増やし、スケーラビリティを維持するためにパージシステムを改良する必要がありましたが、時間の経過とともに、2018年には1秒あたりのパージが2～3千回だったのが、現在では1秒あたり約6万回パージしています。私たちが最初に Bimodal Multicast を実装したときは、ほとんど学術論文からそのまま抜き出しただけで、スケーリングは制限されていました。時間が経つにつれて、このシステムは Fastly 独自のものになり、もはや純粋な Bimodal Multicast ではなくなっています。

過去数年にわたり、パージの方法に最適化と変更を加えた時期が3回ありました。パージ機能を最初に導入してから数年後、ネットワークを拡大し、常に変動するインターネットの接続状況に対処する中で、スケーラビリティと信頼性の問題が発生し始めました。当初はすべてのノードを配信拠点で階層のないピアリングとして設定し、すべてのノードがすべてのパージリクエストを受け取って他のすべてのノードにパケットを配信する役目を担っていました。その後、ノード数が増加するにつれてスケーラビリティを最適化し、インターネットの接続状況によるパケット損失の信頼性を向上させるために、配信拠点内のすべてのノードにパージメッセージを送信する代わりに、1つのノードに送信して配信拠点内の他のノードに再送信させてはどうかと考えました。

これにより、スケーラビリティが大幅に向上し、全体的なオペレーション数が削減されました。パージリクエストは UDP パケットにカプセル化され、クラスターの各配信拠点で少なくとも2つの正常なノードに配信されます。その後、パケットはローカルネットワーク上の隣接ノードに再ブロードキャストされます。この「ダブル配信」メカニズムは、信頼性を確保するための最初のレイヤーであり、インターネットの接続状況によってリクエストがトランジット中に失われる可能性を大幅に低下させます。

最後に、昨年私たちはスケーラビリティに多大な影響を与えるバッチパージに取り組みました (この結果、夜中にアラートに起こされることがなくなりました)。私たちの API を使うことで、常にお客様は一連のサロゲートキーを使用したバッチパージが可能でしたが、これは本当の「バッチパージ」ではありませんでした。システムがバッチを個別のパージに分割すると大量のパージによりシステムのフラッディングが発生し、パフォーマンスの低下を回避するためにレート制限を強制するようアラートが発動します。これは、お客様にとっても私たちにとっても理想的ではありません。そこで私たちはシステムを改良し、実際にバッチパージを真に処理できるようにし、スケーラビリティを向上させ、アラートと手動のレート制限を排除しました。現在、私たちは1秒あたり数十万件のデータパージを実行できると確信できるようになりました。

Instant Purge の今後

将来を見据えて、私たちはパージシステムのパフォーマンスとスケーラビリティをさらに向上させ、必要な時に必要なだけパージできる方法を模索しています。そして常に現在必要な容量の10倍、需要を先取りしたいと考えています。私たちの目標は、1秒あたり数十万件のリクエストから1秒あたり数百万件のリクエストに処理能力を高めることです。そして、すでに実装しているグループ化に関する最適化と手法をさらに展開することで、次のレベルのパフォーマンスとスケーラビリティを達成できると信じています。増え続ける需要に先んじるためには、継続的なイノベーションのプロセスが必要です。

最終的には、ニーズの進化に応じて適応できる、スケーラビリティを備えたアーキテクチャを構築する必要があります。問題へのアプローチを変え、分散化を採用することで、私たちはまさに即時のパージを実現するシステムの配信を実現しました。


この記事には、Fastly の考えや仮定、およびこの記事の公開日において Fastly が入手している情報に基づいた「将来の見通し」に関する記述が含まれています。将来の見通しに関する記述には、既知および未知のリスク、不確実性、ならびにその他の要因が影響する可能性があり、これらの要因によって実際の結果、パフォーマンス、または成果が、将来の見通しに関する記述において明示的または暗示的に示されたものと大きく異なる可能性があります。これらの記述には、将来のプロダクトパフォーマンス、および将来のオペレーションに関するビジョンと目標に関する記述が含まれますが、これらに限定されません。法律で義務付けられている場合を除き、Fastly は、これらの将来の見通しに関する記述を公に更新する義務、または実際の結果が将来の見通しに関する記述で予想されるものと大きく異なる可能性のある理由を更新する義務を負いません。これは、将来新しい情報が入手可能になった場合でも同様です。Fastly の実際の結果を大きく異なるものにする可能性のある重要な要因は、Fastly が米国証券取引委員会 (SEC) に提出するレポート (2024年12月31日に終了した事業年度の Form 10-K による年次報告書、および Form 10-Q による四半期報告書を含む) に随時詳述されています。SEC に提出されたレポートのコピーは Fastly の Web サイトに掲載されており、また Fastly から無料で入手していただけます。