「すべてのユーザーがパージを利用できます！」—すべてのお客様が、すべてのパージ方法を利用できるようになりました

Cloudflareでは毎年4月1日に、ジョークではなく本物の新製品を発表するという伝統があります。当社はこれまで、1.1.1.1やファミリー向け1.1.1.1などの実際に役立つ製品を発表してきました。そして今年もその伝統を続け、本日、すべてのキャッシュ削除（パージ）方法を、すべてのプランのユーザーに提供致します。

バースデーウィーク2024の中で私たちは、すべてのパージ方法（URL指定、ホスト名指定、タグ指定、プレフィックス指定、すべて）をすべてのCloudflareプランに導入する意向を発表しました。これまで、「URL別のパージ」と「すべてのパージ」以外の方法は、Enterpriseのお客様だけに提供していました。しかし、ここ数年、パージパイプラインの再構築をオープンに行っており（ブログシリーズのいくつかをお読みいただければ幸いです）、その結果をより広く共有できることを嬉しく思います。ここ数か月間、私たちは新しい「インスタントパージ」システムが、負荷が高い状況でも常に150ミリ秒以内で動作するように最適化を進めてきました。その結果、すべてのユーザーが安心して使える状態になりました。  

さらに、Enterpriseのお客様向けにはデフォルトのパージ実行回数（レート制限）を大幅に引き上げ、新しく開発されたインスタントパージシステムの効率性により、パージスループットをさらに向上させています。

今回の発表の背景には、2022年の終わりごろから始まった、約2年間の大規模な再設計プロジェクトがあります。2022年の終わりごろ、私たちのチームはCloudflareのパージシステムを一から作り直し始めました。目標は明確でありながら難しいもので、「全世界のネットワークでほぼ瞬時にキャッシュを無効化しつつ、スループットを大幅に向上させる」ことでした。

Cloudflareは、世界335都市以上でデータセンターを運営しています。人気のあるキャッシュデータは、世界中のデータセンターに存在する可能性があります。つまり、各パージリクエストは、そのコンテンツをキャッシングすべての場所に迅速に伝達される必要があります。パージコマンドを受け取った各データセンターは、キャッシュされたコンテンツを効率的に見つけて無効化し、古い応答が提供されないようにする必要があります。無効化する必要があるコンテンツの量は、1つのファイルから、特定のホスト名に関連付けられたすべてのキャッシュデータまで、大幅に異なる場合があります。コンテンツがパージされた後、後続のリクエストは配信元サーバーから新しいコピーを取得するトリガーとなり、応答しながらCloudflareのキャッシュに保存します。 

広大なネットワーク全体でパージリクエストを一貫して高速に伝達することは、特にデータセンターで時折発生する停電、メンテナンス、ネットワークの中断を考慮する場合に、技術的な課題が多く発生します。こうした状況でも一貫して正しく動作させるためには、堅牢な分散システムの設計と技術が求められます。

以前の記事では、新しい「インスタントパージ」システムを使って、150ミリ秒未満でパージを実行できるように設計した仕組みについてご紹介しました。しかし、この新しいアーキテクチャは、単に高速化しただけではありません。トレージの効率化やスループットの大幅な向上といった、スケーラビリティの課題も同時に解決しました。これにより、「インスタントパージ」をすべてのユーザーに提供できるようになりました。 

最初のころ、パージシステムは順調に拡張できていました。しかし、お客様が急激に増えたことで、毎日発生する数百万件のパージキーの保存により、キャッシュ領域が圧迫されるようになりました。最初の対策として、トラフィックの急増に対応するためにキューやバッチ処理を使って調整しましたが、これが逆に遅延（レイテンシ）を生み出し、使用量の増加とストレージコストが密接に結びついてしまっている問題を浮き彫りにしました。

私たちは、パージキーをより適切に保管する方法と、スペースを再利用できるよう、パージされたコンテンツをいつ削除するかについて、私たちの考え方を再検討する必要がありました。これまで、お客様がタグ、プレフィックス、またはホスト名を指定してパージする場合、Cloudflareはコンテンツを「期限切れ」としてマークし、しばらく経ってから削除する方式を採用していました。これは、レイジーパージ（lazy-purge）と呼ばれ、ディスクからは何も削除されません。レイジーパージでは削除せず残り続けるコンテンツがストレージを消費するため、高速ですが、必ずしも効率的ではありません。パージキーをグローバルまたはデータセンター単位でインデックス化する案も検討しましたが、ネットワーク規模が大きいためにシステムが複雑になりすぎ、かえって遅延が発生すると判断しました。そこで私たちは、マシンごとにインデックスを持たせ、キャッシュプロキシと直接連携する設計を選びました。これにより、ネットワークの複雑さを減らし、スケールしやすく、安定した運用が可能になりました。

分析と検証を重ねた結果、RocksDBという軽量なキーバリュー型データベースを採用しました。これは、各キャッシュプロキシとともに実行されるRustベースのサービスCacheDBの基礎を形成するものです。CacheDBは、インデックス作成と即時パージ実行（アクティブパージ）を管理し、ストレージニーズを大幅に削減し、キャッシングスペースを解放します。

CacheDB内のローカルキューは、パージ処理を一時的にバッファして、スループットを安定させ、遅延の急増を防ぎ、キャッシュプロキシはCacheDBに問い合わせることで、迅速かつ確実にキャッシュを削除できます。さらに、新しくなった配信パイプラインでは、パージ情報が各マシンのCacheDBインスタンスに直接配信されるようになり、処理速度とパージのスピードが大幅に向上しました。

CacheDBを使用することで、レイジーパージの問題であるストレージの蓄積を解消し、ストレージ要件を10分の1に削減し、貴重なディスクスペースを即座に解放することができました。ストレージを解放することで、キャッシュの保持力が向上し、キャッシュヒット率が上がり、オリジンのエグレス料金を最小限に抑えることができます。以上のストレージの節約とスループットの向上により、より多くのお客様にインスタントパージを提供できるまでの拡張が可能になりました。

新しいインスタントパージシステムの設計に関する詳細については、パージシリーズのブログ記事の以前の記事を参照してください。 

新しいパージ方法を実際に使用する際の重要な考慮点として、無効化したい内容に応じた適切な方法を使用することが重要です。過度にパージを行うと、配信元サーバーに不要なリクエストが集中し、エグレスコストの上昇や、ダウンタイムの発生に繋がります。逆に、パージが不十分だと、訪問者に古いコンテンツが提供されてしまいます。精度と速度のバランスを取ることが重要です。

Cloudflare、お客様がこのバランスをとれるよう支援するために、複数の標的パージ方法をサポートしています。

• すべてをパージ： Webサイトに関連するすべてのキャッシュされたコンテンツを削除します。

• プリフィックス別パージ：共通のプレフィックスを持つURLを対象にします。

• ホスト名別パージ：特定のホスト名に関連するコンテンツを無効化します。

• URL別パージ（個別ファイルパージ） : 個々のURLを対象に正確にパージします。

• タグ別パージ：Cache-Tagヘッダーを使用してグループ化されたアセットを無効にし、複雑なキャッシュ管理シナリオに柔軟に対応します。

本日より、これらの方法はすべて、Cloudflareのすべてのお客様にご利用いただけます。    

ユーザーは、設定セクションの「キャッシュ」タブにあるCloudflareダッシュボードで直接、またはCloudflare APIを介してパージ方法を選択することができます。各パージリクエストには、選択したパージタイプに関連する、対象URL、ホスト名、プレフィックス、またはキャッシュタグ（パージキー）を明確に指定する必要があります。たとえば、プレフィックスパージリクエストは、「example.com/foo/bar」のようなディレクトリを指定します。効率とスループットを最大化するために、それぞれ単一のキーで個別のパージリクエストを送信するよりも、複数のパージキーを単一のリクエストにまとめることをお勧めします。

Cloudflareのタグ、プレフィックス、ホスト名、すべてのパージに対する新しいレート制限は、プランの種類によって異なります。Cloudflareではトークンバケット方式のレート制限を使用しており、各アカウントにはプランの種類に応じた最大サイズのトークンバケットがあります。パージリクエストを受け取ると、まずアカウントの前回のパージリクエストからの経過時間そのプランのリフィルレートで割った分だけ、トークンがバケットに追加されます（リフィルレートはトークンの一部であることもあります）。その後、バケットに少なくとも1つの完全なトークンがあるか確認し、あればそれを取り除いてパージリクエストを処理します。トークンが足りない場合、パージリクエストはレート制限されます。このレート制限について簡単に考えるには、リフィルレートはユーザーが一定期間に送信できるリクエストの一貫したレートを表し、バケットサイズは利用可能なリクエストの最大バースト（突発的なリクエスト量）を表していると考えるとよいでしょう。

例えば、無料ユーザーの場合、バケットサイズは25リクエスト、リフィルレートは1分あたり5リクエスト（12秒に1回のリクエスト）です。もしユーザーが26リクエストを一度に送信した場合、最初の25リクエストは処理されますが、最後の1つのリクエストはレート制限されます。その場合、12秒待ってから再度リクエストを送信することで、最後のリクエストが成功します。 

現在の上限は、アカウントごとに適用されます： 

すべてのパージレート制限に関するより詳細な文書は、ドキュメントをご覧ください。

当社ではパージプラットフォームの最適化に多くの時間を費やしてきました。しかし、これで終わりではありません。今後は、Cloudflareの個別ファイルパージのパフォーマンスをさらに向上させていく予定です。現在のP50パフォーマンスは約250ミリ秒であり、これをさらに最適化して200ミリ秒未満にすることができると考えています。また、すべてのシステムで、より高いパージスループットを実現できるように取り組み続け、スケーラビリティを維持するためにフィルタリング技術を導入し、お客様が望むものを望むタイミングでパージできるようにする方法を模索し続けます。 

すぐにでも訪問者にシームレスな体験を提供するために、新しいパージシステムを今すぐお試しください。