スティッキーセッションの長所と短所/セッションアフィニティの負荷分散戦略？
高いスケーラビリティへの1つのアプローチは、ネットワーク負荷分散を使用して、処理負荷を複数のサーバー間で分割することです。
このアプローチが提示する1つの課題は、サーバーが状態を認識する場所であり、ユーザーの状態を「セッション」に保存します。
この問題の1つの解決策は、「スティッキーセッション」（別名「セッションアフィニティ」）です。この場合、各ユーザーは単一のサーバーに割り当てられ、ユーザーの状態データはセッションの期間中そのサーバーに排他的に含まれます。
「スティッキーセッション」アプローチの長所と短所は何ですか？あなたはそれを使用していますか、使用している場合は満足していますか？
長所：
- 簡単です。アプリを変更する必要はありません。
- ローカルRAMキャッシュをよりよく利用します（たとえば、ユーザープロファイルを一度検索してキャッシュし、同じユーザーからの以降のアクセスで再利用できます）
短所：
- サーバーがダウンすると、セッションは失われます。 （これは、セッション情報をローカルでWebサーバーに格納することの短所であり、スティッキーセッション自体の短所ではないことに注意してください）。セッションの内容がユーザー（メールの下書きなど）またはサイト（ショッピングカートなど）にとって本当に重要である場合、サーバーの1つを失うことは非常に苦痛になる可能性があります。
- ロードバランサーの「スティッキー」実装によっては、一部のサーバーと他のサーバーに不均等な負荷がかかる場合があります
- 新しいサーバーをオンラインにしても、すぐに新しいサーバーに大きな負荷がかかるわけではありません。スパイクに対処するための動的負荷分散システムがある場合、スティッキによってスパイクへの迅速な対応能力が低下する可能性があります。とはいえ、これはややまれなケースであり、実際には非常に大規模で洗練されたサイトにのみ適用されます。
- ユーザーが比較的少ないが、1人のユーザーのトラフィックが1つのサーバーを圧倒する可能性がある場合（SSL、AJAX、動的に生成された画像、動的圧縮などの複雑なページなど）、stickineはエンドユーザーの応答時間を損なう可能性があります1人のユーザーの負荷をサーバー間で均等に分散します。多数の同時ユーザーがいる場合、すべてのサーバーが氾濫するため、これは問題にはなりません！
ただし、サーバーローカルセッション状態を使用する必要がある場合は、スティッキーセッションを使用することをお勧めします。また、サーバーローカルセッション状態を使用しない場合でも、キャッシュ使用率に関しては、スティッキ性に利点があります（上記を参照）。 IPアドレスは単一のセッション中に変化する可能性があるため（たとえば、有線ネットワークとワイヤレスネットワーク間でのラップトップのドッキングなど）、ロードバランサーはHTTP Cookie（IPアドレスだけでなく）を調べてスティッキ性を判断できる必要があります。
さらに良いことに、Webサーバーでセッション状態を使用しないでください！セッション状態が失われるのが非常に困難な場合（ショッピングカートなど）、それを中央データベースに保存し、古いセッションを定期的に消去します。セッション状態が重要ではない場合（ユーザー名やアバターのURLなど）、Cookieに貼り付けます。Cookieに過剰なデータを入れていないことを確認してください。
Railsの最新バージョンでは、上記の理由により、デフォルトでセッション変数がCookieに保存されます。他のWebフレームワークには、「cookieに保存」オプションや「DBに保存」オプションがある場合があります。