NGINX クックブック第3版

第2章 高性能ロードバランサ

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

2.0 はじめに

今日のインターネット・ユーザ体験は、パフォーマンス（ ）とアップタイムを要求している。これを実現するために、同じシステムの複数のコピーが実行され、負荷が分散される。負荷が増加すると、システムの別のコピーをオンラインにすることができる。このアーキテクチャテクニック（ ）は、水平スケーリングと呼ばれている。ソフトウェアベースのインフラは、その柔軟性から人気が高まっており、可能性の広大な世界が広がっている。ユースケースが高可用性のための2つのシステムコピーのセットという小規模なものであれ、世界中に数千あるという大規模なものであれ、インフラと同じくらいダイナミックなロードバランサソリューションが必要とされている。NGINXは、HTTP、伝送制御プロトコル（TCP）、ユーザデータグラムプロトコル（UDP）のロードバランサなど、多くの方法でこのニーズを満たす。

ロードバランサを行う場合、クライアントのエクスペリエンスに与える影響が完全にポジティブなものであることが重要だ。最近のウェブアーキテクチャの多くは、ステートレスの アプリケーション層を採用し、共有メモリやデータベースに状態を保存している。しかし、これはすべての人にとっての現実ではない。セッション状態 は非常に価値があり、インタラクティブなアプリケーションで広く使われている。例えば、作業するデータが非常に大きく、ネットワークのオーバーヘッドがパフォーマンスにおいて高すぎるアプリケーションでは、この状態は、多くの理由でアプリケーションサーバーにローカルにストアされるかもしれない。アプリケーション状態がアプリケーションサーバーにローカルに保存される場合、その後のリクエストが同じサーバーに配信され続けることは、ユーザ体験にとって極めて重要である。この状況のもう一つの側面は、セッションが終了するまでサーバを解放すべきではないということである。ステートフルなアプリケーションを大規模に扱うには、インテリジェントなロードバランサが必要である。NGINXは、クッキーやルーティングを追跡することで、この問題を解決する複数の方法を提供する。この章では、NGINXによるロードバランサに関連するセッションの永続性について説明する。

NGINXがサービスを提供しているアプリケーションが、健全であることを確認することが重要である。アップストリームのリクエストは、さまざまな理由で失敗し始める可能性がある。ネットワーク接続、サーバの障害、アプリケーションの障害など、いくつか例を挙げればきりがない。プロキシやロードバランサは、上流のサーバ（ロードバランサやプロキシの背後にあるサーバ）の障害を検出し、それらへのトラフィックの受け渡しを停止するのに十分賢くなければならない。

サーバに障害が発生したときのサービス低下を軽減する方法は、プロキシにアップストリームサーバの正常性を確認させることである。NGINXは、NGINXオープンソースで利用可能なパッシブ型と、NGINX Plus でのみ利用可能なアクティブ型の2種類の正常性確認を提供している。アクティブヘルスチェック 定期的に上流サーバに接続またはリクエストを行い、レスポンスが正しいことを確認できる。パッシブヘルスチェック は、クライアントがリクエストまたは接続を行うと、上流サーバの接続またはレスポンスを監視する。パッシブな正常性確認を使用してアップストリームサーバの負荷を軽減したり、アクティブな正常性確認を使用してクライアントに障害が発生する前にアップストリームサーバの障害を判定したりすることができる。この章の最後では、ロードバランサを行うアップストリーム・アプリケーション・サーバの健全性の監視について説明する。 ...