NGINX Plus キャッシュ クラスターによる共有キャッシュ、パート 1

編集者 – これは、高容量および高可用性キャッシュに関するシリーズの最初の部分です。

• NGINX Plus キャッシュ クラスターによる共有キャッシュ、パート 1 (この投稿)
• NGINX Plus キャッシュ クラスターによる共有キャッシュ、パート 2

この投稿は、ここで最初に説明した個別の拡張ステータス モジュールを置き換えて非推奨にする NGINX Plus API を参照するように更新されました。

NGINX または NGINX Plus を使用して、大容量で可用性の高いキャッシュ クラスターを構築するにはどうすればよいですか? これは、この目標を達成するための代替アプローチを紹介する 2 部構成のシリーズの第 1 部です。 パート2には上のリンクからアクセスできます。 (特に記載がない限り、このアプローチは NGINX Open Source と NGINX Plus に等しく適用されますが、簡潔にするために NGINX Plus のみを参照します。)

NGINX Plus キャッシュの概要

NGINX Plus は、オリジン サーバーとリモート クライアントの間に位置するプロキシ キャッシュ サーバーとして動作できます。 NGINX Plus は、オリジン サーバーへのトラフィックを管理し、共通の不変のリソースをキャッシュ (保存) します。 これにより、NGINX Plus はこれらのリソースが要求されたときにクライアントに直接応答できるようになり、オリジン サーバーの負荷が軽減されます。 NGINX Plus のプロキシ キャッシュは、オリジン サーバーの隣のデータ センターに展開されるのが最も一般的ですが、グローバルに分散された PoP に CDN のような形式で展開される場合もあります。

コンテンツ キャッシュは驚くほど複雑なトピックです。 この記事を読み進める前に、いくつかの基本的なキャッシュ手法について理解しておくことをお勧めします。

• NGINX Plus キャッシュの仕組み- コア構成とキャッシュローダーおよびキャッシュマネージャープロセスの役割
• キャッシュ時間の微調整– マイクロキャッシュなどの手法を実装して、コンテンツのキャッシュ方法と有効期限切れ時の更新方法を制御する

NGINX Plus がキャッシュに共有ディスクを使用しないのはなぜですか?

各 NGINX Plus サーバーは独立した Web キャッシュ サーバーとして機能します。 複数の NGINX Plus サーバー間でディスクベースのキャッシュを共有する技術的な手段はありません。これは意図的な設計上の決定です。

レイテンシが高く、信頼性が低い可能性のある共有ファイルシステムにキャッシュを保存することは、設計上適切な選択ではありません。 NGINX Plus はディスクのレイテンシに敏感であり、スレッド プール機能によってメイン スレッドからread()およびwrite()操作がオフロードされるとしても、ファイルシステムが遅く、キャッシュ I/O が高い場合、NGINX Plus は大量のスレッドによって圧倒される可能性があります。 NGINX Plus インスタンス間で一貫性のある共有キャッシュを維持するには、フィル、読み取り、削除などの重複するキャッシュ操作を同期するためにクラスター全体のロックも必要になります。 最後に、共有ファイルシステムは、信頼性と一貫したパフォーマンスが最も重要であるキャッシュに、信頼性の低さと予測不可能なパフォーマンスの原因をもたらします。

複数の NGINX Plus サーバー間でキャッシュを共有する理由

ファイルシステムを共有することはキャッシュに適した方法ではありませんが、それぞれに対応するテクニックを持つ複数の NGINX Plus サーバーにコンテンツをキャッシュすることには十分な理由があります。

• 主な目的が非常に大容量のキャッシュを作成することである場合は、キャッシュを複数のサーバーに分割 (パーティション化) します。 この投稿ではこのテクニックについて説明します。
• 主な目標が、オリジン サーバーの負荷を最小限に抑えながら高可用性を実現することである場合は、高可用性の共有キャッシュを使用します。 このテクニックについては、関連記事（近日公開予定）を参照してください。

キャッシュを分割する

キャッシュのシャーディングは、キャッシュ エントリを複数の Web キャッシュ サーバーに分散するプロセスです。 NGINX Plus キャッシュ シャーディングでは、一貫性のあるハッシュ アルゴリズムを使用して、キャッシュ エントリごとに 1 つのキャッシュ サーバーを選択します。 これらの図は、1 台のサーバーがダウンした場合 (中央の図)、または別のサーバーが追加された場合 (右の図)、3 台のサーバーに分割されたキャッシュに何が起こるかを示しています (左の図)。

総キャッシュ容量は、各サーバーのキャッシュ容量の合計です。 各リソースをキャッシュしようとするサーバーは 1 つだけなので (同じリソースの独立したコピーが複数あるわけではありません)、オリジン サーバーへのトリップが最小限に抑えられます。

このパターンは、 N 台のキャッシュ サーバーがあり、そのうち 1 台に障害が発生した場合に、キャッシュの 1/ Nのみが失われるという意味で、フォールト トレラントです。 この「失われた部分」は、一貫性のあるハッシュによって残りのN –1 台のサーバーに均等に分散されます。 より単純なハッシュ方法では、代わりにキャッシュ全体を残りのサーバーに再配布しますが、再配布中にキャッシュのほとんどすべてが失われます。

コンシステントハッシュ ロード バランシングを実行する場合は、キャッシュ キー(またはキーの構築に使用されるフィールドのサブセット) をコンシステントハッシュのキーとして使用します。

アップストリームの cache_servers { ハッシュ $scheme$proxy_host$request_uri 一貫性あり;

サーバー red.cache.example.com;
サーバー green.cache.example.com;
サーバー blue.cache.example.com;
}

NGINX Plus のアクティブ/パッシブ高可用性ソリューション、ラウンドロビン DNS、またはkeepalivedなどの高可用性ソリューションを使用して、着信トラフィックをロードバランサー (LB) 層全体に分散できます。

シャードキャッシュ構成の最適化

キャッシュ シャーディング構成に対して 2 つの最適化のいずれかを選択できます。

ロードバランサとキャッシュ層の組み合わせ

LB 層とキャッシュ層を組み合わせることができます。 この構成では、各 NGINX Plus インスタンスで 2 つの仮想サーバーが実行されます。 負荷分散仮想サーバー (図の「LB VS」) は、外部クライアントからのリクエストを受け入れ、一貫性のあるハッシュを使用して、内部ネットワークで接続されているクラスター内のすべての NGINX Plus インスタンスにリクエストを分散します。 各 NGINX Plus インスタンス上のキャッシュ仮想サーバー (「Cache VS」) は、内部 IP アドレスでリクエストのシェアをリッスンし、リクエストをオリジン サーバーに転送して、応答をキャッシュします。 これにより、すべての NGINX Plus インスタンスがキャッシュ サーバーとして機能するようになり、キャッシュ容量が最大化されます。

第一レベルの「ホット」キャッシュの構成

あるいは、大規模な共有キャッシュを第 2 レベル キャッシュとして使用して、非常にホットなコンテンツ用にフロントエンド LB 層に第 1 レベル キャッシュを構成することもできます。 これにより、第 1 層のキャッシュ コンテンツが徐々に期限切れになるときにのみコンテンツを更新する必要があるため、第 2 層のキャッシュ レイヤーに障害が発生した場合のパフォーマンスが向上し、オリジン サーバーへの影響が軽減されます。

キャッシュ クラスターが非常に大量のホット コンテンツを処理している場合、小さい第 1 レベル キャッシュの変更率が非常に高くなることがあります。 つまり、キャッシュ内の限られたスペースに対する需要が非常に高いため、コンテンツは、後続の 1 つの要求を満たすために使用される前に、キャッシュから削除されます (最近要求されたコンテンツのためのスペースを確保するため)。

この状況を示す指標の 1 つは、提供されたコンテンツと書かれたコンテンツの比率が低いことです。これらは、NGINX Plus APIモジュールによって報告される拡張統計に含まれる 2 つの指標です。 これらは、組み込みのライブ アクティビティ監視ダッシュボードの[キャッシュ]タブの [提供済み] フィールドと[書き込み済み]フィールドに表示されます。 ( NGINX Plus APIモジュールとライブ アクティビティ監視ダッシュボードは、NGINX Open Source では利用できないことに注意してください。)

このスクリーンショットは、NGINX Plus がキャッシュから提供するよりも多くのコンテンツをキャッシュに書き込んでいる状況を示しています。

この場合、最も頻繁に要求されるコンテンツのみを保存するようにキャッシュを微調整できます。 proxy_cache_min_usesディレクティブは、このコンテンツを識別するのに役立ちます。

まとめ

複数の NGINX または NGINX Plus Web キャッシュ サーバーにまたがってキャッシュをシャーディングすることは、非常に大容量でスケーラブルなキャッシュを作成する効果的な方法です。 一貫性のあるハッシュは、高い可用性を提供し、キャッシュに障害が発生した場合でも、キャッシュされたコンテンツの一部のみが無効になることを保証します。

この投稿の後半では、 NGINX または NGINX Plus キャッシュ サーバーのペアでキャッシュを複製する代替の共有キャッシュ パターンについて説明します。 総容量は個々のサーバーの容量に制限されますが、構成は完全にフォールト トレラントであり、キャッシュ サーバーが使用できなくなってもキャッシュされたコンテンツは失われません。

独自のサーバーでキャッシュ シャーディングをお試しください。今すぐ30 日間の無料トライアルを開始するか、弊社にお問い合わせの上、ユースケースについてご相談ください。