セキュリティメトリクスとしてのキャッシュヒット率 (CHR)
Principal Software Engineer, Fastly
CHR は、キャッシュを使用するあらゆるシステムにおいて中核となるメトリクスのひとつです。CHR が「唯一の」メトリクスであるケースも多いです。CHR は、キャッシュにコンテンツがあるかどうかの確認を観測することで測定されます。Fastly では、キャッシュヒットの数をキャッシュ確認の合計回数で割って、キャッシュヒット率を算出します。キャッシュの確認結果は「ヒット」(コンテンツが見つかった) または「ミス」(コンテンツが見つからなかった) のいずれかであるため、CHR は以下のようになります。
これまで、キャッシュヒット率 (CHR) は、パフォーマンスメトリクスとして扱われてきました。キャッシュするほどにコストを節約でき、パフォーマンスが加速するので CHR に注目する必要があります。ミスに対するヒットの割合が多いほど、以下のメリットが得られます。
オリジンで必要なハードウェア容量の削減
オリジンのアーキテクチャにおける複雑性の軽減
データ転送コストの大幅な節約
キャッシュからコンテンツを配信することでレイテンシを短縮
メリットはパフォーマンスの領域に限りません。見過ごされがちですが、CHR を向上させることで大きなセキュリティ上のメリットも得られるのです。例えば最近実施された調査では、配信を Fastly の CDN に切り替えただけでセキュリティインシデントが40%も減少したと報告した回答者もいました (調査レポートはこちら</u>)。つまり今後は、CHR をパフォーマンスメトリクスとしてだけでなく、セキュリティメトリクスとしても扱う必要があると私たちは考えています。
セキュリティメトリクスとしてのキャッシュヒット率
CHR の改善がリスク軽減につながる理由をご説明する前に、セキュリティリスクを高める要因について見てみましょう。
攻撃対象領域の拡大
使用するサーバーの数が多いほど、悪用される可能性がある場所が増え、管理の手間も増えます。水平にスケーリングして増大する容量の需要に対応でき、ベストプラクティスを通じてサーバーの安全性を確保できているはずの組織でも、設定ミスや脆弱性が発生する可能性があり、サーバーの数が多くなるにつれて悪用されるリスクも高まります。
アプリケーションの複雑化
水平にスケーリングすることができず、システムを複雑化させてスケールする必要がある場合、2つの問題が発生します。まず、システムが複雑になると悪用されるパーツが増えるので、システムの管理と保護がより困難になります。
次に、オリジンでより多くの負荷を処理する必要性が高まるにつれ、アプリケーションの複雑性も増大します。例えばトラフィックが増えると、複数のサーバーに負荷を分散させたり、プライマリデータベースの複製を導入したりする必要が生じる可能性があります。この負荷をエッジにある CDN で処理する場合、オリジンの容量とは別に総合的な容量をスケーリングできるので、オリジンのアプリケーションをよりシンプルに維持し、セキュリティを強化できます。
複雑なデプロイモデル
デプロイモデルが複雑になると、アーキテクチャにおけるリスクも高まります。これには、より多くのリージョンや可用性ゾーンの使用、マルチクラウドまたはハイブリッドクラウドのアーキテクチャのサポートなど、さまざまなデプロイ形式が含まれます。また、IAM (アイデンティティおよびアクセス管理) やデータベース、ネットワーク配信ソリューションなど大手クラウドプロバイダーが提供するサービスを使用する場合もあります。このようにリージョンやゾーンが拡大し、使用するツールが増えると、セキュリティのより多くの部分がこれらのツールやプロバイダーの手に委ねられることになります。その結果、ツール間だけでなく、ツールとオリジンシステム間の境界も増え、設定上の問題に関するリスクが高まります。
仮にこれらの各パーツで十分なセキュリティ対策が講じられていても、ロジックによりパーツ同士が連携する際にリスク要因が常に生まれます。完全になす術がないというわけではなく、リスクからシステムを保護するには、まずリスクが存在する場所とその緩和方法を理解することが重要です。
人的ミスの機会の増加
セキュリティリスクを生じさせるのはシステム内の脆弱性だけではありません。人的ミスの可能性もリスク要因となります。アーキテクチャの複雑性、管理とメンテナンスが必要なハードウェアの数、管理プロセスの追加など、種類を問わず複雑性の増加はミスが発生するリスクの増大につながります。システムについて理論的な推論が困難な場合、そのようなシステムの診断や修正、人的ミスの軽減を行うのは容易ではありません。問題を解決する際に、問題の原因をすぐに理解できないアプローチはリスクをもたらします。いくらパイプの配置を換えても水漏れする蛇口は修理できないのと同じことです。
人的ミスの可能性の拡大につながる複雑性の増大をサポートすることは、リスクを意味します。あらゆることが万全で問題がない際に存在する「リスク」は、実際にトラブルが発生してすべてが立ち行かなくなり、問題の所在も特定できないと「大きな責任問題」に発展します。
(セキュリティ問題としての) ダウンタイム
ダウンタイムは複数の意味でセキュリティ問題といえます。まず第一に、DDoS 攻撃はセキュリティ攻撃とみなされるので、DDoS 攻撃からの保護の失敗はセキュリティ障害を意味します。次に、普段のプラクティスが中断されると、セキュリティ侵害のリスクが常に高まります。それほどセキュリティが強化されていないメソッドやプロセスを代わりに使用したり、慌てて対応したりすることで、通常の状況であれば検出してブロックできるはずの攻撃に対してより脆弱になるためです。最後に、自動処理すべき進行中の DDoS 攻撃への対処に SecOps チームが貴重な時間を費やしている場合、組織の優先課題に積極的に取り組むために費やされるべき時間が失われていることを意味します。
https://www.fastly.com/jp/products/ddos-mitigation
これらのセキュリティ問題の解決に CHR がどう役立つか
CHR を向上させることで得られるメリット
必要なハードウェア容量の減少に伴う攻撃対象領域の縮小
アプリケーションやアーキテクチャの複雑性の低減
オリジンにおけるインフラの管理とメンテナンスの削減
オリジンからトラフィックをオフロードし、レジリエンスが高く、自動化機能を備えた堅牢でセキュアなエッジプラットフォームで処理
リスクの主な要因として、増大するハードウェアの管理、高まるアプリケーションやアーキテクチャ、デプロイの複雑性、理論的な推論が困難なシステムの使用、ダウンタイムなどが挙げられます。CHR の高まりは、理論的な推論がしやすいシンプルなシステムの導入による必要なハードウェアの削減、アプリケーションやアーキテクチャ、デプロイにおける複雑性の軽減を示唆すると同時に、堅牢で自動対応可能な CDN によるアップタイムと信頼性の向上を約束します。
CHR は、セキュリティレベルの直接的な指標ではありません。しかし CHR の向上は、よりセキュアなシステムの構築につながる取り組みの成果を証明しているといえます。アプリケーションのタイプによって CHR の上限が異なります。厳しい環境では80% - 90%を超えるのが困難な場合もありますが、Fastly のお客様の多くは95%以上の CHR を達成しています。これはパフォーマンスやコスト面だけでなく、セキュリティにおいても大きなメリットをもたらします。
CHR と組織のセキュリティ体制の基本的な関係を理解したところで、CHR 自体やその改善方法について詳しくみてみましょう。
キャッシュヒット率を理解する
通常ヒットとミスは正例数で示され、CHR は0から1.0の範囲になります。CHR は一般的にパーセントで表現されることが多く、その場合 CHR は0%から100%の間になります。CHR が0%の場合、すべてがキャッシュミスであることを意味し、 すべてのコンテンツがオンデマンドでオリジンから取得された、または算出されたことを示します。CHR が100%の場合、すべてがキャッシュから直接配信されたことを意味します。
キャッシュミスで実行されるプロセスはコストが高くつく傾向があるので (帯域 や CPU の使用において)、通常 CHR が高いほどシステムのパフォーマンスも高いとみなされます。各アプリケーションについて、定常状態でのキャッシュヒット率を確認できます。CHR は、コンテンツの有効期限やアクセスパターンによって左右されます。例えば、頻繁にアクセスされないコンテンツを有効期限前にパージして他のコンテンツのためのスペースを作ることはできます。しかし一般的には、CHR を可能な限り高いレベルで維持することで、望ましくない処理の遅延を排除できます。
例 : 定常状態におけるキャッシュヒット率
理解しやすいように、キャッシュヒット率が変化した場合に何が起きているのかを見てみましょう。最初の例のセットでは、完全に正常運転の日でキャッシュ動作のレート (ヒットとミスの合計) がほぼ一定し、アプリケーションが定常状態にあることを想定しています。
この定常状態で CHR が低下した場合、原因はヒットだったものの一部がミスに変わったためです。毎秒50件のヒットと50件のミスが発生しているアプリケーションを例に考えてみましょう。
この場合、キャッシュヒット率は50%になります。次に、この割合が下がった場合の影響を見てみます。ヒット数の半分がミスになると (ヒット数が25でミス数が75)、CHR は25%に下がります。
このような CHR の低下によってどのような影響があるのでしょうか。
まず、ミスが50%増加しました。つまり、コンテンツがキャッシュで見つからなかったために、オリジンに送信されたコンテンツのリクエストが50%増えたことになります。これは、オリジンで必要なハードウェアのリソースが50%増加したことを意味します。
それでは、逆方向に同じことが起こったらどうなるでしょうか。
ミスの半分がヒットになると、キャッシュヒット率は75%に上昇します。その結果、オリジンに送信されるリクエストが半減し、オリジンで必要なハードウェアのリソースも50%削減されます。これは同時にソフトウェアアーキテクチャの複雑性の低減や、オリジンで必要な可用性ゾーンの削減を意味し、アプリケーションにおける攻撃対象領域の縮小につながります。
オリジンの保護対策としてのキャッシュヒット率
キャッシュヒット率について考える際、オリジンのサーバーがどれほど効率的に保護されているかを測定する指標とみなすことができます。リクエスト数が変わらない場合、キャッシュヒット率が高いほど、インフラストラクチャに送信されるトラフィックが少なくなります。一般的にオリジンの保護について語る際、攻撃ではなくトラフィックスパイクからの保護を想定しています。しかし、セキュリティについて検討する際にも同じメリットを適用できます。
自社インフラストラクチャではなく、Fastly でリクエストを処理する場合、よりレジリエントで継続的にアップデートされ、高いセキュリティが維持されている Fastly プラットフォームに攻撃対象領域が制限されます。
キャッシュヒット率が低い場合
キャッシュヒット率が低いほど、オリジンから直接コンテンツが配信されるトラフィックが増えるので、攻撃や異常なスパイクが発生した際に、その分だけ保護が弱まります。これにより可用性の懸念が生じ、ダウンタイムはセキュリティリスクとみなされます。またキャッシュヒット率が低いと定常状態でもセキュリティに影響します。オリジンで処理するリクエストが多いと必要なインフラストラクチャが拡大し、アーキテクチャが複雑化する可能性があるためです。その結果、前述のように複雑性と人的ミスの可能性の増大によるリスクが追加されます。
キャッシュヒット率の向上による攻撃対象領域の縮小
CHR が高くなるにつれて攻撃対象領域が小さくなります。理由は、キャッシュヒットでは完全に Fastly のインフラストラクチャからコンテンツが配信され、キャッシュミスの場合にのみオリジンからコンテンツが取得されるためです。高いキャッシュヒット率は、キャッシュヒットの割合が高いことを意味します。つまり、オリジンサーバーに送信されるリクエストが非常に少ないということです。
キャッシュヒット率を向上させる方法
以下では、CHR を高めるベストプラクティスの一部をご紹介します。そのうちのいくつかは Fastly を使用する場合にのみ可能です。これは Fastly のプラットフォームが当初から従来型の CDN よりも多くのデータをキャッシュできるよう設計されているためです。今日の組織は、より多くのコンテンツを高速かつ効率的に配信してユーザーエクスペリエンスを向上させる必要があります。
TTL を拡大してコンテンツのパージを遅らせる
「TTL (Time to Live = 有効期限)」は、オブジェクトのキャッシュが可能な期間をコントロールする主なパラメーターです。TTL によって、Fastly が後続のリクエストでコンテンツを再利用できる期間が決定されます。TTL が短いと、コンテンツがキャッシュから短期間でパージされるのでキャッシュミスとなり、より多くのリクエストがオリジンからコンテンツを取得することになります。
コンテンツが非常に動的である、または頻繁に変化するという理由から長めの TTL は使用できないという考え方には、誤解が潜んでいる可能性が高いです (詳しくは Fastly にお問い合わせ</u>ください)。動的コンテンツをサポートする Fastly のツールのひとつに「Instant Purge」があります。
TTL を長めに設定し、コンテンツが変更されたら Instant Purge で消去する
Fastly の Instant Purge API を使用して、コンテンツを Fastly ネットワークからオンデマンドで瞬時にパージできます。グローバルなパージの実行に要する平均時間はわずか150ミリ秒です。簡単な操作でお客様のアプリケーションに統合し、API レスポンスやスポーツのライブスコアなど、迅速に変化するコンテンツも含め、非常に長い TTL (例えば1年ぐらい) を設定し、さまざまなメリットが得られます。一般的な印象以上に多くの種類のコンテンツをキャッシュすることが可能です。
オリジンシールドを有効にする
Fastly のオリジンシールド機能によって、特定の POP を、他の POP のオリジンとして機能するように指定できます。これにより、コンテンツがキャッシュで見つかる可能性が大幅に高まり、同時にオリジンへの負荷を軽減できます。オリジンシールドに関する詳細 →</u>
一時的に失効済みコンテンツを配信する
失効済みコンテンツが配信されるよう Fastly サービスを設定することで、オリジンがダウンしてもサービスを利用可能な状態に維持できます。
容量の大きいパワフルな少数の POP で構成される CDN を選ぶ
これは不思議に聞こえるかもしれませんが、CDN が使用する POP が少ないほど、単一の POP でコンテンツがすでにキャッシュされている確率が高まるためです。ただし言うまでもなく、より大きな統合コンテンツプールを提供するため、各 POP が通常よりもはるかに大きなストレージ容量を備えている必要があるというトレードオフがあります。これは、Fastly の CDN アーキテクチャの中核を成す原理のひとつです。先進的な POP のメリットに関する詳細 →</u>
キャッシュと緊密に統合するその他の Fastly プロダクトを検討する
Fastly のImage Optimizer</u> を有効にすることで、画像処理に関するロジックをオリジンからオフロードし、画像の変換や最適化をエッジで実行できます。また、この機能は Fastly のキャッシュと緊密に統合されているので、さまざまなデバイス固有の画像も含め、利用可能なストレージを最大限に活用できます。
さらに、Instant Purge とも統合されているので、高解像度のソース画像をパージすると、それを元に作成された画像もパージされます。変化するコンテンツでも、長めの TTL のメリットを活用できます。
キャッシュのカバレッジを拡大する方法についての詳細やアイディアについては、キャッシュ設定のベストプラクティス</u>に関するドキュメントをご覧ください。
オリジンからリクエストをオフロードするその他の方法
熱心な攻撃者はオリジンにたどり着く方法を見つけ出します。ロジックをオリジンからエッジに移行させることで、攻撃対象領域をさらに縮小することができます。できる限り CHR を高めたら、次は Fastly のエッジ・コンピューティング・プラットフォーム「Compute」で合成コンテンツを生成し、オリジンへのリクエストを削減する方法を模索することも可能です。
Computeの各リクエストはそれぞれ独立したサンドボックス環境で実行されます。同プラットフォームを通過する各リクエストごとにサンドボックスが作成され、破棄される仕組みです。これにより、コードのバグや他のユーザーによる設定ミスの影響範囲を制限し、攻撃対象範囲を縮小できます。このきわめて強力な安全機能によって、オリジンでは実現不可能なセキュア・バイ・デザインの環境に多くのロジックを安心して移行させることが可能になります。その結果、ふたつの方法でセキュリティを高められます。つまり、より多くのロジックをエッジに移行し、よりセキュアなコンピューティング環境で実行することで、オリジンの保護を強化できるのです。エッジで実践する最先端のアプリケーション開発について、詳しくはこちらのプレイブック</u>をご覧ください。
ロジックを Fastly のエッジに移行させるだけでオリジンにおける攻撃対象領域を縮小することができますが、実はそれによってパフォーマンスの改善も簡単に実現できるようになります。先日 Fastly は Compute で生成されたコンテンツの一部や合成コンテンツをキャッシュに移動させることを可能にする Core Cache API をリリースしました。この機能により、セキュリティ上のメリットに加えてコンテンツのキャッシュによるレイテンシの短縮という利点も得られます。
* Fastly の委託により、Forrester Consulting が2023年7月に実施した調査レポート「The Total Economic Impact™ Of Fastly Networks Services」のデータより。undefined
