はじめに
ALB配下のサーバで特定のドメインだけはスティッキーセッションあり、その他はなしにしたいというケースが有ったので、実装方法を記載します。
1.そもそもやりたい構成
かんたんに説明すると、上記のように複数のドメインへのリクエストを前段のALB１つで処理し、Webサーバでリクエストに基づいて、後続のAPサーバに振り分けます。ただし、www2のリクエストに関しては後続のAPサーバのアプリの都合上スティッキーを有効化したいというケースです。
2.実装方法
まずターゲットグループを２つ作成します。
１つは、スティッキーセッションあり（www2）、もう１つはスティッキーセッションなし（www1）のターゲットグループです。
次に、リスナールールをALBに作成します。
ホストヘッダーの条件に、www1.xxx(FQDNを記載)を指定し、ターゲットに前段で作成した、スティッキーセッションなしのターゲットグループを指定します。
次にもう一つのリスナールールを作成します。
ホストヘッダーの条件に、www2.xxx(FQDNを記載)を指定し、ターゲットに前段で作成した、スティッキーセッションありのターゲットグループを指定します。
最後にAutoScalingグループにて、上記２つのターゲットグループを指定すれば完了です。
※AutoScalingグループでは２つのターゲットグループへの同時所属が可能です。そのため、同じEC2が２つのターゲットグループに所属することができ、２つのリクエスト（www１、www２）を受理できます。
３.そもそもなぜスティッキーセッションを限定したいか？
結論から言うと、ステートレスにしたいからです。ステートを特定のEC2でもってしまうと、その部分が単一障害点となってしまいます。また、セッションの維持期間中は元のリクエストを受け付けたサーバにリクエストが行ってしまうため、負荷分散を均等に行うことができなくなってしまいます。基本的には、スティッキーは原則利用しない、セッションは外部に管理すると言うことを必ずお勧めしています。今回の構成はどうしてもセッションを維持しないとと言うことで苦肉の策で考えた構成です。
4.まとめ
今回はスティッキーセッションの特殊な事例をご紹介しました。
原則ステートレストすべきと言う考えから、スティッキーセッションは最小限の利用にとどめたいものですね。