分散一貫性セッションの実装方法を4つ一気に説明するなんて、インタビューすごいですね〜

[[333096]]

序文

Afen 社には、Tomcat を使用して導入された Web 管理システムがあります。バックエンド管理システムであるため、すべての Web ページでは、対応する操作を実行する前にログイン認証が必要です。

当初、このシステムを使用する人は多くありませんでした。リソースを節約するために、このシステムは 1 台のマシンにのみ導入されました。その後、使用する人が増えるにつれて、1 台のマシンではワークロードを処理できなくなったため、Afen は別のマシンを導入することを決定しました。

現時点では、バックエンドシステムには 2 つのサービスがあるため、リバースプロキシとして Nginx を使用します。全体的なアーキテクチャ図は次のとおりです。

このアーキテクチャ図は誰もが知っているはずだと私は思います。現在、主流の Web システムのほとんどはこの方法で導入されています。

深夜にデバッグを行った後、Afen はシステムを本番環境に導入しました。何も問題ないと思ったので、検査員に渡して検査を始めました。

このテストには大きな問題がありました!テストを受けた女性は、ログインした後、しばらくしてから再度ログインする必要があり、これが数回発生したと報告しました。

Ah Fen は確認し、システムのアプリケーションと構成に問題がないことを確認しました。それで何が悪かったのでしょうか?

ちょうどこのとき、チームリーダーは仕事が終わるところでした。彼は私たちが問題を抱えていることに気付き、様子を見に来ました。基本的な状況を簡単に把握した後、すぐに問題の原因を見つけ、Nginx 側の設定を変更して再起動することで問題を解決しました。

分散一貫性セッション

問題を解決した後、チームリーダーは座って、Ah Fan に問題の原因を説明しました: 分散一貫性セッション。

本来であれば、ログイン後にユーザーのログイン情報をセッションに格納します。ユーザーが操作するたびに、まずセッション内にユーザー情報が存在するかどうかを確認します。存在しない場合は、ユーザーは最初にログインする必要があります。

元のアーキテクチャでは、アプリケーション システムは 1 つしかなく、すべての操作は 1 つの Tomcat で実行されていましたが、もちろん問題はありませんでした。

しかし、現在では 2 つのシステムを導入しています。 Nginx はデフォルトの負荷分散戦略 (ポーリング) を使用するため、リクエストは時系列順にバックエンド アプリケーションに 1 つずつ分散されます。

つまり、最初にTomcat1にログインすると、ユーザー情報はTomcat1のセッションに配置されます。しばらくすると、リクエストはNginxによってTomcat2に配布されます。この時、Tomcat2のセッションにはユーザー情報がないので再度ログインする必要があります。

また、当社のシステムではシングル サインオン方式を採用しているため、Tomcat2 はログイン後に Tomcat1 のログイン情報を無効にします。そのため、Nginx がトラフィックを Tomcat1 に再度分散すると、セッション内のユーザー ログイン情報が期限切れとなり、再度ログインする必要があります。

[[333098]]

問題を知っていた Ah Fen は当然解決策を知りたかったので、チーム リーダーは分散一貫性セッションの 4 つの解決策を Ah Fen に教えました。 Ah Fen は皆のためにそれらを整理しました:

以下では、Afen とチーム リーダーとの会話の形式で、分散一貫性セッション ソリューションについて説明します。

セッションレプリケーション

チームリーダー:

この時点で Tomcat1 セッションにはユーザー情報がありますが、Tomcat2 にはユーザー情報がありません。

このとき、Tomcat1 のセッションを Tomcat2 にコピーすると、Nginx はリクエストを Tomcat2 に転送します。 Tomcat2 にはセッションがあるため、再度ログインする必要はありません。

アーキテクチャ図は次のとおりです。

一貫性のあるセッション間レプリケーション

Tomcat のセッション レプリケーション構成の例はインターネット上に多数あります。ここでは投稿しません。興味のある学生は自分で検索することができます。

アーファン：

はい、この方法は良いですね。 Tomcat はこのメソッドをサポートしています。 Tomcat 構成を変更するだけでよく、アプリケーション コードを変更する必要はありません。

チームリーダー:

それは本当ですが、このアプローチにはまだ多くの欠点があります。

まず、セッション複製の送信にはイントラネット帯域幅が必要です。

2 番目に、この例ではマシンが 2 台しかないため、レプリケーション パフォーマンスは許容範囲内です。しかし、N 台のマシンがあると仮定すると、各レプリケーションは N-1 台のマシンに複製される必要があります。マシンの数が多いと、ネットワーク ストームが発生し、レプリケーション パフォーマンスが急激に低下する可能性があります。

3 番目に、Tomcat はすべてのセッション データを保存する必要があります。このソリューションのセッションはメモリに保存され、マシンの合計メモリによって簡単に制限されます。マシンを追加することで水平方向に拡張することはできませんが、マシンのメモリを増やすことは可能です。しかし、マシンのメモリが大きくなるほど、価格も高くなります!!!

したがって、この解決策は推奨されません。

セッションフロントエンドストレージ

アーファン：

まあ、この計画は確かにちょっと頼りないですね〜

よし、わかった！私たちのセッションは実際にユーザーの情報を保存します。今は Tomcat セッションに保存しません。情報を取り出してブラウザの Cookie に保存します。

この方法では、各ユーザーのブラウザが独自の Cookie 情報を保存し、サーバーがそれを保存する必要がなくなるため、セッション レプリケーション ソリューションの欠陥が解決されます。

次に、ユーザーはリクエストを行うたびにこの Cookie を送信し、Cookie 内のユーザー情報を判別できるようになります。

アーキテクチャ図は次のとおりです。

一貫性のあるセッション間フロントエンドストレージ

チームリーダーは私を賞賛の眼差しで見つめた。

はい、あなたの計画は確かに実現可能です。

ただし、このソリューションを使用する場合は、まず暗号化ソリューションについて検討する必要があります。

ユーザー情報は当社の機密データであり、第三者が簡単にデータを盗んだり改ざんしたりすることは許されません。

さらに、このソリューションではリクエストごとに Cookie を送信する必要があり、外部ネットワークの帯域幅が占有されます。クッキーが大きすぎると、ネットワークのオーバーヘッドが増加します。

さらに、保存するデータのサイズは Cookie の制限の対象となります。

したがって、この方法は一般的には使用されませんが、これも考え方の 1 つです。

次の 2 つのオプションをお勧めします。

スティッキーセッション

チームリーダー:

ご覧のとおり、Nginx の設定にいくつか変更を加えただけで、問題は解決しました。

実際、これは Nginx のデフォルトの負荷分散戦略を IP ハッシュを使用するように変更したためです。

Nginx は、要求者の IP アドレスを使用してハッシュを作成し、それをマシンに配布します。これにより、同じ IP アドレスからの要求は同じ Tomcat に送信されます。

アーキテクチャ図は次のとおりです。

セッション スティッキー IP ハッシュ

上記の方法では、Nginx の 4 層負荷分散を使用します。実際、Nginx は 7 層の負荷分散も実現できます。つまり、Http プロトコルのいくつかのビジネス属性を使用してハッシュを実行します。一般的な属性としては、userId、loginId などがあります。

アーキテクチャ図は次のとおりです。

一貫性セッション - セッションの持続性 - 7 つのレイヤー

アーファン：

この解決策は単純に思えます。 Nginx 構成を変更するだけでよく、アプリケーション構成を変更する必要はありません。

リクエスト元 IP が十分にランダムである限り、2 つのアプリケーション上のトラフィックは IP HASH 後に十分にランダムになります。

さらに、後で 2 台のマシンでワークロードを処理できなくなった場合は、Nginx の設定を変更するだけで水平方向に拡張し、マシンを追加できます。

チームリーダー:

あなたの言ったことはまさにその通りです！

しかし、考えたことはありますか、弊社のような状況では、全員のエクスポート IP は同じです。そうすると、当社からのすべてのリクエストは 1 台のマシンにのみ送信され、状況は再び単一ポイントになります。

さらに、Tomcat を再起動すると、セッションはメモリに配置されるため、セッションのこの部分は失われ、これらのユーザーは再度ログインすることになります。

最後に、一時的に別のマシンを追加し、Nginx の設定を変更して再起動すると、Nginx はハッシュ分散要求を再計算します。

この状況では、一部のユーザーは新しいマシンにリダイレクトされ、セッションがないため、再度ログインする必要があります。

ただし、Tomcat が再起動されたり、新しいマシンが頻繁に追加されることはないため、この問題は大きな問題ではありませんが、ユーザー エクスペリエンスは若干悪くなります。

今日はこれをこの問題の解決策として使います。

しかし、後に以下の方法に変更しました。

バックエンド集中ストレージ

チームリーダー:

上記の方法では、セッションをアプリケーション メモリに保存します。アプリケーション マシンが再起動されると、セッションは失われます。

この問題を解決するには、セッションを Redis または MySQL に個別に保存します。

ただし、セッションは期限切れになる必要があり、永続化する必要がないため、Redis を使用して保存することをお勧めします。

この構造は次のようになります。

一貫性のあるセッション間バックエンドストレージ

私たちはセッション損失のリスクなしにこのソリューションを使用しますが、もちろん、Redis がダウンしないことが前提です。

また、後段で直接横展開できるアプリケーションであれば。

後続のアプリケーションからのリクエスト数が非常に多く、1 つの Redis では処理できない場合は、実際にクラスターを拡張し、キャッシュ キーに基づいてルーティングを実行することができます。

アーファン：

はい、これは良い方法です〜

チームリーダー:

すぐに満足しないでください。このソリューションを使用するには、一定の代償を支払う必要があります。

まず、リクエストごとに Redis を 1 回呼び出す必要があるため、ネットワークのオーバーヘッドが増加します。

さらに、Redis の導入により、対応するコードを変更する必要があり、複雑さが増します。

したがって、このソリューションには利点と欠点の両方があります。もちろん、私たちのシナリオでは、利点が欠点を上回ります。

アーファン：

そうですね、そうみたいです。

チームリーダー:

さて、もう遅いし、問題は解決したので、串焼きを食べに行きましょう。私がご馳走します！

アーファン：

ボス、？？！

チームリーダーはアーフェンの頭を撫でた。

私の食事は無駄ではなかった。来週は、現在の方法を集中型セッションストレージに変更する必要があります。

ヒント: spring-session を使用できます。

アーファン：

さて、来週勉強します。

要約する

最後にまとめさせていただきます。バックエンド Web アプリケーションを複数のマシンに拡張すると、分散一貫性セッションの問題が発生してしまいます。主流の解決策は 4 つあります。

セッションレプリケーション: Tomcat やその他の Web コンテナを使用した同期レプリケーション

セッションフロントエンドストレージ: ユーザーのブラウザのCookieを使用してセッション情報を保存します

セッションスティッキーソリューション: Nginx の 4 層または 7 層のハッシュ機能を使用して、すべてのユーザーリクエストが同じマシンで処理されるようにします。

セッション バックエンド集中ストレージ ソリューション: Redis を使用してセッションを集中的に保存することで、Web アプリケーションが再起動または拡張されたときにセッションが失われることはありません。

上記の 4 つのオプションのうち、4 番目のオプションが推奨されます。

もちろん、4 番目のオプションには、ある程度の開発作業が必要です。変革の初期段階では、移行として 3 番目のオプションを選択できます。

さて、このプロジェクトを変換するには、セッション バックエンド ストレージ ソリューションを使用します。春のセッションについては後ほどシェアします。