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

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

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

NGINX または NGINX Plus を使用して、大容量で可用性の高いキャッシュ クラスターを構築するにはどうすればよいですか? この投稿では、2 台以上の NGINX または NGINX Plus キャッシュ サーバーを使用して、可用性の高いキャッシュ クラスターを作成する方法について説明します。 (特に記載がない限り、ここで説明する方法は NGINX Open Source と NGINX Plus に等しく適用されますが、簡潔にするために NGINX Plus のみについて説明します。)

レビュー – シャードキャッシュソリューション

このシリーズの最初の部分では、非常に大規模なシャード キャッシュ クラスターを作成するパターンについて説明しました。

このパターンは、自由にスケールアップできる非常に大容量のキャッシュを作成する必要がある場合に効果的です。 各リソースは 1 つのサーバーにのみキャッシュされるため、完全な耐障害性はありませんが、コンシステント ハッシュ ロード バランシングにより、サーバーに障害が発生した場合でも、キャッシュされたコンテンツのその部分のみが無効になります。

高可用性キャッシュクラスタの作成

オリジン サーバーへのリクエストの数を何としても最小限に抑えることが主な目標である場合、キャッシュ シャーディング ソリューションは最適なオプションではありません。 代わりに、プライマリおよびセカンダリ NGINX Plus インスタンスを慎重に構成したソリューションで要件を満たすことができます。

プライマリ NGINX Plus インスタンスはすべてのトラフィックを受信し、リクエストをセカンダリ インスタンスに転送します。 セカンダリ インスタンスはオリジン サーバーからコンテンツを取得してキャッシュします。プライマリ インスタンスもセカンダリ サーバーからの応答をキャッシュしてクライアントに返します。

両方のデバイスのキャッシュが完全に設定されており、キャッシュは設定されたタイムアウトに従って更新されます。

プライマリ キャッシュ サーバーの構成

すべての要求をセカンダリ サーバーに転送し、応答をキャッシュするようにプライマリ キャッシュ サーバーを構成します。 アップストリーム グループのサーバーディレクティブのバックアップパラメータで示されているように、セカンダリ サーバーに障害が発生した場合、プライマリ サーバーはリクエストをオリジン サーバーに直接転送します。

proxy_cache_path /tmp/mycache keys_zone=mycache:10m; server { status_zone mycache; # NGINX Plus 拡張ステータス用 listen 80; proxy_cache mycache; proxy_cache_valid 200 15s; location / { proxy_pass http://secondary; } } アップストリームセカンダリ { zone secondary 128k; # NGINX Plus 拡張ステータス用 server 192.168.56.11; # セカンダリサーバー 192.168.56.12 backup ; # origin }

セカンダリ キャッシュ サーバーの構成

セカンダリ キャッシュ サーバーを構成して、要求をオリジン サーバーに転送し、応答をキャッシュします。

proxy_cache_path /tmp/mycache keys_zone=mycache:10m;
server {
status_zone mycache; # NGINX Plus 拡張ステータス用

listen 80;

proxy_cache mycache;
proxy_cache_valid 200 15s;

location / {
proxy_pass http://origin;
}
}

upstream origin {
zone origin 128k; # NGINX Plus 拡張ステータス用

server 192.168.56.12; # origin
}

高可用性の構成

最後に、プライマリ サーバーに障害が発生した場合にセカンダリ サーバーが着信トラフィックを取得し、その後プライマリ サーバーが回復したときにトラフィックを再び取得するように、高可用性 (HA) を構成する必要があります。

この例では、 NGINX Plus のアクティブ/パッシブ HA ソリューションを使用します。 外部にアドバタイズされる仮想 IP アドレスは 192.168.56.20 であり、プライマリ キャッシュ サーバーはクラスター内の HA のプライマリ ノードとして機能します。 NGINX Open Source を使用している場合は、 keepalivedまたは別の HA ソリューションを手動でインストールして構成できます。

フェイルオーバーのシナリオ

キャッシュ サーバーに障害が発生しても動作を継続する、可用性の高いキャッシュ クラスターを作成する必要があることを思い出してください。 キャッシュ サーバーに障害が発生した場合、またはキャッシュ サーバーが回復して古いコンテンツを更新する必要がある場合でも、オリジン サーバーの負荷が増加しないようにする必要があります。

プライマリに障害が発生し、 NGINX Plus HA ソリューションが外部 IP アドレスをセカンダリに転送するとします。

セカンダリのキャッシュは満杯で、通常どおり動作を続けます。 オリジンサーバーに追加の負荷はかかりません。

プライマリ キャッシュ サーバーが回復し、クライアント トラフィックの受信を開始すると、そのキャッシュは古くなり、多くのエントリが期限切れになります。 プライマリは、セカンダリ キャッシュ サーバーからローカル キャッシュを更新します。セカンダリ サーバーのキャッシュはすでに最新であるため、オリジン サーバーへのトラフィックは増加しません。

ここで、セカンダリが故障したと仮定します。 プライマリはこれを検出し (HA ソリューションの一部として構成されたヘルス チェックを使用)、トラフィックをバックアップ サーバー (元のサーバー) に直接転送します。

プライマリ サーバーのキャッシュは満杯で、通常どおり動作を続けます。 繰り返しになりますが、オリジン サーバーに追加の負荷は発生しません。

セカンダリが回復すると、そのキャッシュは古くなります。 ただし、プライマリのキャッシュの有効期限が切れたときにのみプライマリからのリクエストを受信し、その時点でセカンダリのコピーも有効期限が切れます。 セカンダリがオリジン サーバーからのコンテンツをリクエストする必要があるにもかかわらず、オリジンへのリクエストの頻度は増加しません。 オリジンサーバーに悪影響はありません。

フェイルオーバー動作のテスト

HA ソリューションをテストするために、リクエストをログに記録し、リクエストごとに現在の時刻を返すようにオリジン サーバーを構成します。 つまり、オリジン サーバーの応答は毎秒変化します。

access_log /var/log/nginx/access.log;
location / {
return 200 "現在時刻は $time_localn です";
}

プライマリおよびセカンダリキャッシュサーバーは、ステータスコード付きの応答をキャッシュするようにすでに設定されています。200 15秒間。 これにより、通常は 15 秒または 16 秒ごとにキャッシュが更新されます。

proxy_cache_valid 200 15秒;

キャッシュの動作の検証

1 秒に 1 回、キャッシュ クラスターの高可用性仮想 IP アドレスに HTTP リクエストを送信します。 プライマリ サーバーとセカンダリ サーバーのキャッシュが期限切れになり、オリジン サーバーから応答が更新されるまで、応答は変更されません。 これは 15 秒または 16 秒ごとに発生します。

$ while sleep 1 ; do curl http://192.168.56.20/ ; done現在は 9/Feb/2017:06:35:03 -0800 です 現在は 9/Feb/2017:06:35:03 -0800 です 現在は 9/Feb/2017:06:35:03 -0800 です 現在は 9/Feb/2017:06:35:19 -0800です ^C

また、オリジン サーバーのログを調べて、リクエストが 15 秒または 16 秒ごとにのみ受信されていることを確認することもできます。

フェイルオーバーの検証

たとえば、 nginxプロセスを停止するなどして、プライマリ サーバーまたはセカンダリ サーバーのいずれかを停止することで、フェイルオーバーが正しく機能していることを確認できます。 一定負荷テストは継続して実行され、応答は一貫してキャッシュされます。

オリジン サーバーのアクセス ログを調べると、どのキャッシュ サーバーが障害を起こしても、または回復しても、15 ～ 16 秒ごとにリクエストを受信するだけであることが確認できます。

キャッシュ更新のタイミング

安定した状況では、キャッシュされたコンテンツは通常 15 ～ 16 秒ごとに更新されます。 コンテンツは 15 秒後に期限切れになり、次のリクエストを受信するまでに最大 1 秒の遅延が発生し、キャッシュが更新されます。

場合によっては、キャッシュの更新が遅くなることがあります (コンテンツの変更間隔は最大 30 秒)。 これは、プライマリ キャッシュ サーバーのコンテンツの有効期限が切れ、プライマリがセカンダリからほぼ有効期限が切れたキャッシュ コンテンツを取得した場合に発生します。 これが問題となる場合は、セカンダリ サーバーでキャッシュ タイムアウトを短く設定できます。

まとめ

ここで説明したように、2 台以上の NGINX キャッシュ サーバー間でキャッシュを階層化することは、オリジン サーバーの負荷を最小限に抑え、キャッシュ サーバーの 1 つに障害が発生したり回復したりしたときにトラフィックの急増からオリジン サーバーを保護する、可用性の高いキャッシュ クラスターを作成する効果的な方法です。

キャッシュの合計容量は、単一のキャッシュ サーバーの容量に制限されます。 このシリーズの最初の部分では、キャッシュ サーバーのクラスター間でキャッシュを分割する代替のシャード キャッシュ パターンについて説明します。 その場合、合計容量はすべてのキャッシュ サーバーの合計になりますが、キャッシュ サーバーに障害が発生した場合に元のサーバーへのトラフィックの急増から保護するためにコンテンツは複製されません。

独自のサーバーで高可用性キャッシュをお試しください。今すぐ30 日間の無料トライアルを開始するか、弊社にお問い合わせの上、使用事例についてご相談ください。