[10] [DFN[sticky session]] は、 複数の[[アプリケーションサーバー]]で構成される [[Webサービス]]の[[逆プロキシサーバー]]において、 特定の[[クライアント]]からの[[要求]]を常に特定の[[アプリケーションサーバー]]に[[転送]]するための技法です。 [11] [[Webアプリケーション]]の設計技法として、 [[クライアント]]に直接相対する[[逆プロキシ]]の背後に多数の[[アプリケーションサーバー]]を配置し、 適宜分散させて処理させる手法が極めて一般的です。 この「適宜分散」が、候補となる[[アプリケーションサーバー]]からの無作為の選択だとすると、 同じ[[クライアント]]からの連続した[[要求]]が、 同じ[[アプリケーションサーバー]]に[[転送]]されることは保証されません。 そのため、 前回の[[要求]]の結果が次回の[[要求]]の結果に影響するような処理に不都合が生じます。 そこで各[[アプリケーションサーバー]]から共通してアクセスする[[データベースサーバー]]を他に設けて、 後から参照するデータはそこに保存します。 これがいわゆる[[三層構造]]アーキテクチャーです。 [12] 通常は3層アーキテクチャーで構わないのですが、 性能向上や単純化、 古いシステムとの互換性などの理由で、 個々の[[アプリケーションサーバー]]内またはそれに近しい場所に後から参照するデータを置きたいこともあります。 その場合、 [[逆プロキシ]]は同じ[[クライアント]]からの[[要求]]を毎回同じ[[アプリケーションサーバー]]に[[転送]]しなければなりません。 そのための技法が [[sticky session]] です。 こうした設計は [[HTTP]] の想定外の利用であって標準的な手段が提供されていないため、 やや強引な方法が編み出されています。 [13] 素朴な手法として、 [[クライアント]]の [[IPアドレス]]のような[[下位層プロトコル]]から提供される識別情報を使ってアクセス元[[クライアント]]を区別し、 前回記録しておいた[[アプリケーションサーバー]]へと[[転送]]する方法が考えられます。 ただこの方法は同じ [[IPアドレス]]を持つ[[クライアント]]は相互に区別できないため複数[[アプリケーションサーバー]]間の分散に難があることや、 [[クライアント]]の[[IPアドレス]]の変化に耐えられないという問題があります。 [SRC[>>9]] そのため現在ではあまり使わないか、 他の方法が利用できないときの[[フォールバック]]として扱われています。 [14] [[アプリケーションサーバー]]が保存するデータ (状態) を識別する[[セッションID]] を[[クライアント]]ごとに発行する場合、 [[逆プロキシ]]もこのIDで[[クライアント]]を識別し、 適切な[[アプリケーションサーバー]]へと振り分けることができます。 [[セッションID]]の転送方法として[[クッキー]]を使う方法と、 [[URL]] の [[path][URL path]] や [[query][URL query]] を使う方法があります。 [15] [[逆プロキシ]]が独自に[[クッキー]]を発行し[[クライアント]]を区別する方法もあります。 この方法は[[アプリケーションサーバー]]の設計に依存せず[[逆プロキシ]]だけで完結できるため、 柔軟に利用できます。そのため現在ではこの方法が主流となっているようです。 [16] [[URL]] を使う方法は、 [[URLが汚くなり][汚いURL]]、 特定の[[クライアント]]の専用で他の人に[[共有]]できなくなるため、 嫌われています。 [[平成時代]]にはそうしたシステムもよくみられました。 [17] [[クッキー]]を使う方法は、 [[クッキー]]に対応していない[[クライアント]]には通用しないという欠点があります。 通常の [[Webブラウザー]]を使う一般の[[利用者]]には影響はほとんどありませんが、 [[プログラム]]からのアクセスの場合は対応した[[ライブラリー]]を使うなど配慮が必要になります。 [[クッキー]]は[[利用者]]の[[追跡]]につながるため[[プライバシー]]の観点から風当たりが強く、 利用の許諾を得るなど[[法令]]に基づく措置が必要となる場合があるのも難点です。 [3] [CITE[Classic Load Balancer のスティッキーセッションの設定 - Elastic Load Balancing]], [TIME[2020-09-26T04:07:28.000Z]], [TIME[2020-10-01T01:51:33.789Z]] [1] [CITE[[[Application Load Balancer]] のターゲットグループ - Elastic Load Balancing]], [TIME[2020-09-30T02:49:27.000Z]], [TIME[2020-10-01T01:46:25.166Z]] [2] [CITE@ja[スティッキーセッションを使っていなければApplication Load Balancer障害に耐えれたかも??? Amazon EC2をステートレスにする為にやるべきこと | Developers.IO]], [[Yuki Suwa]], [TIME[2020-10-01T01:50:31.000Z]] [4] [CITE@ja[【基礎から学ぶ】ELBのスティッキーセッションについてまとめてみた - サーバーワークスエンジニアブログ]], [TIME[2020-10-01T01:53:34.000Z]] [5] [CITE@ja[ロードバランサの設定]], [TIME[2011-02-01T17:33:50.000Z]], [TIME[2020-10-01T01:55:20.638Z]] [6] [CITE[スティッキーセッション用のロードバランサの設定 (Sun Java System Access Manager 7 2005Q4 配備計画ガイド)]], [TIME[2020-10-01T01:56:05.000Z]] [7] [CITE@en[9.4. スティッキーセッション 7.4 | Red Hat Customer Portal]], [TIME[2020-10-01T01:56:54.000Z]] [8] [CITE['''['''ThinkIT''']''' 第1回:Tomcatによるクラスタリングの実現 (2/4)]], [TIME[2020-10-01T01:58:08.000Z]] [9] [CITE@en[mod_proxy_balancer - Apache HTTP Server Version 2.4]], [TIME[2020-07-28T12:39:54.000Z]], [TIME[2020-10-01T02:03:03.310Z]]