Nginxのロードバランシングはバックエンドのセッション単一ポイント問題に対応します

クズども · 掲載地 2023/01/10 20:38:39

要件:Nginxを使ってリバースプロキシを構築し、すべてのリクエストのスケジューリングを担当します。バックエンドはMVCによって開発され、複数の異なるサーバーに展開され、バックエンド ASP.NET クラスターを形成しますセッション情報は共有できず、一部のリクエストが正しく処理されないことがあります。以下の問題が生じます。

ASP.NET ウェブサイトは以下のように言えます:

asp.net セッション共有(StateServer経由)
https://www.itsvse.com/thread-6613-1-1.html

. ネット分散アーキテクチャ:Redisに基づくセッション共有
https://www.itsvse.com/thread-5189-1-1.html

一般的に使われる解は以下の通りです:

データベースを使ってSESSIONを保存してください

各サーバーが同じセッションを使用する必要があるため、セッションを同じデータベースに保存できます。アクセスするたびにデータベースにアクセスし、このセッションが存在するか、またはこのセッションが期限切れかを確認し、複数のサーバーのセッションを同期できます。

価値：この方法は簡単で便利、そして始めやすいです。

短所：セッションを同期するためにデータベースを使うと、データベースのIOが増加し、データベースへの負担も増えます。同時に、各アクセスはリクエストを傍受しデータベースを照会する必要があり、追加のアクセス層とデータベースセッション時間の無駄が生じます。

MemcacheやRedisのようなキャッシュ機構を使ってSESSIONを保存してください

memcacheやredisのような分散キャッシュ機構を用いてセッションデータを保存することは、多くの大規模プロジェクトで負荷分散や同期セッションの人気ソリューションです。その原理は、プロジェクトがmemcacheまたはredisキャッシュを同じ場所で使用し、ユーザーがログインするとセッションがキャッシュに保存され、どのサーバーにアクセスしてもセッションキャッシュが同じ場所から取得されるため、セッション同期が容易に実現されるというものです。

価値：キャッシュを使ってセッションを同期しても、データベースへの負担が増えることはなく、セッションの存在や期限切れを手動で判断する必要もないため、一部のビジネスロジックが省けます。

短所：memcacheやredisはメモリを多くのストレージブロックの仕様に分割し、サイズを持つブロックも存在します。これにより、memcacheやredisがメモリを完全に活用できず、メモリ断片化が生じ、ストレージブロックが不足するとメモリオーバーフローも発生します。

Nginxのip_hashパターンを活用しよう

この技術はセッションキーピングとも呼ばれ、nginxにおけるip_hash技術であり、特定のIPアドレスからのリクエストは同じバックエンドアプリケーションサーバーにピン留めされますこのIPの下でクライアントとバックエンドが安定したセッションを確立できるようにしています。

(しかし、オペレーターのネットワークがより不安定で不安定であれば、エグレスIPは動的ですはい、この方法には問題が起こるでしょう。）

テスト方法はdockerを基に2つのサイトを開くことです。それぞれ /data/testsite/a と /data/testsite/b ディレクトリの下に新しいindex.htmlファイルを作成する必要があります、命令は以下の通りです:

ログインが見えます。

以下のようにブラウザを通じたアクセス:

Dockerをベースに新しいnginxコンテナを作成すれば、ip_hash技術を使わずにリクエストを異なるバックエンドサーバーに送信できます。以下の図に示されています:

ip_hash技術を用いて、以下の構成で新しい /data/testsite/nginx.conf ファイルを作成します。

ログインが見えます。

Dockerの起動コマンドは以下の通りです:

ログインが見えます。

（Stickyモジュールで参照可能なクッキーベースのセッションキーピングは省略されています）

Nginx構成:ハイパーリンクのログインが見えます。

(終わり)

Nginxのロードバランシングはバックエンドのセッション単一ポイント問題に対応します

関連記事