Edit

Page

Page title:

Page body:

[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]] <https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/classic/elb-sticky-sessions.html>

[1] [CITE[[[Application Load Balancer]] のターゲットグループ - Elastic Load Balancing]], [TIME[2020-09-30T02:49:27.000Z]], [TIME[2020-10-01T01:46:25.166Z]] <https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/load-balancer-target-groups.html#sticky-sessions>

[2] [CITE@ja[スティッキーセッションを使っていなければApplication Load Balancer障害に耐えれたかも??? Amazon EC2をステートレスにする為にやるべきこと | Developers.IO]], [[Yuki Suwa]], [TIME[2020-10-01T01:50:31.000Z]] <https://dev.classmethod.jp/articles/stateless_ec2/>

[4] [CITE@ja[【基礎から学ぶ】ELBのスティッキーセッションについてまとめてみた - サーバーワークスエンジニアブログ]], [TIME[2020-10-01T01:53:34.000Z]] <https://blog.serverworks.co.jp/tech/2017/01/05/elb-sticky/>

[5] [CITE@ja[ロードバランサの設定]], [TIME[2011-02-01T17:33:50.000Z]], [TIME[2020-10-01T01:55:20.638Z]] <https://docs.oracle.com/cd/E19199-01/817-4727-10/a_loadbalancer.html#wp89491>

[6] [CITE[スティッキーセッション用のロードバランサの設定 (Sun Java System Access Manager 7 2005Q4 配備計画ガイド)]], [TIME[2020-10-01T01:56:05.000Z]] <https://docs.oracle.com/cd/E19461-01/819-4121/auto51/index.html>

[7] [CITE@en[9.4. スティッキーセッション 7.4 | Red Hat Customer Portal]], [TIME[2020-10-01T01:56:54.000Z]] <https://access.redhat.com/documentation/ja-jp/red_hat_single_sign-on/7.4/html/server_installation_and_configuration_guide/sticky-sessions>

[8] [CITE['''['''ThinkIT''']''' 第1回:Tomcatによるクラスタリングの実現 (2/4)]], [TIME[2020-10-01T01:58:08.000Z]] <https://thinkit.co.jp/cert/compare/14/1/2.htm>

[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]] <https://httpd.apache.org/docs/current/en/mod/mod_proxy_balancer.html#stickyness>

Historical Legal Sensitive Parent: [Help / License]

Edit

Page

Page name(s)