Sticky sessionの自体は、わりと一般的な機能だと思いますが、あまり知識がなかったころにえいやっ!で設定して理解が浅かったので、あらためて動作検証してみました。

ELBのStickiness(維持設定)について

ELBがリクエストを振り分ける際、ユーザーのセッションごとに振り分け先のインスタンスを固定するSticky sessionを提供する機能です。
一度接続が確立すると、Cookieの有効期間を超過するか、接続先インスタンスのヘルスチェックに失敗するまで、同一インスタンスにリクエストを振り分け続けます。

メリット

以下のように冗長化されたWeb/AP構成で動作を検証してみました。
Web_App.png

1セッションごとに発生するRDS, Appサーバのコネクション数は、Sticky sessionを有効にした場合とそうでない場合とで異なります。

検証過程は冗長なので省きますが、以下のような結果になります。

  • ELB->Web, Web->AppでそれぞれSticky sessionを有効にしなかった場合
    • RDSのコネクション数(最大):4
    • Appのコネクション数(最大):2 * 2台
  • ELB->Web, Web->AppでそれぞれSticky sessionを有効にした場合
    • RDSのコネクション数(最大):1
    • Appのコネクション数(最大):1

DBやアプリケーションに最大同時接続数の制約があるにもかかわらず、前者はサーバ台数が増えれば増えるほど、サーバ間のコネクションが増大し、余分なリソースを消費するようになるため、サービス全体の同時接続数を増やすことが難しくなります。

一方、後者は1セッションあたり常に1コネクションとなるので、適切なリソース消費が行えるようになります。

デメリット

今回の検証の中では見つけられませんでした。
サーバ側の障害でエラーを返すようになったとして、ヘルスチェックで切り離されるまで、あるユーザーにはエラーが返るようになりますが、Sticky sessionを無効にした場合も数回に1回エラーが返る状況は変わらないはず。
デメリットをご存知の方に教えていただけると嬉しいです。

Sign up for free and join this conversation.
Sign Up
If you already have a Qiita account log in.