こんにちは。
日本ライフレイ、サポータビリティエンジニアの竹生（たけお）です。

今回は、セッションレプリケーションの利用に関する記事をご紹介します。

---

※本記事はLiferay Community Blogに投稿されている”Today's Top Ten: Ten Reasons to Avoid Sessions”を翻訳したものです。配信元または著者の許可を得て配信しています。
※オリジナルの英記事著者:David H Nebinger サウスカロライナ州のサマーヴィルに住むLiferay, Inc.のSoftware Architect/リードコンサルタント。Liferay Communityサイトにて、多くの技術情報を投稿するなど精力的に活動しています。

セッションストレージを避けるべき10の理由

---

セッションレプリケーションはやっかいである

サウスカロライナ州チャールストン郊外の本社で働く私が、セッションレプリケーションを回避すべき10の理由を説明します。

• その１０：スティッキーセッションでは、クラスタ内の他のノードの容量が大きくても、Webアドレスからのトラフィックは同じノードへ送信されます。まだ容量に余裕があるノードに、トラフィックを転送できないため、クラスタの利点の一部が失われます。その上、ユーザーは最初にアクセスしたノードのみ使い続けることになるため、同じノード上で誰かが重い処理を始めないことを祈ることになります。

• その９：スティッキーセッションでは、ノードに障害が発生した場合、そのノード上のユーザーは、セッションストア内のものをすべて失います。クラスターは使用可能なノードにアクセスを切り替えますが、セッションデータを復元することはできません。

• その８：セッションレプリケーションを使用してノードの機能停止を回避しようとすると、ノード間ネットワークトラフィックが増加し、ほとんどの場合、不要なセッションデータが転送されます。ノード障害が発生した場合には必要ですが、最後にノード障害が起きたのはいつでしょうか？この「念のため」の準備のために、どれだけのネットワークとCPU容量を犠牲にしているか考えてみてください。

• その７：スティッキーセッションデータも、セッションレプリケーションも、災害復旧の際に役に立ちません。プライマリデータセンターがネットワークから外れ、ユーザーがDRサイトに切り替えられた場合、復旧のためにバックアップとファイルをDRに同期させることがよくありますが、誰もセッションデータの同期は必要ではないはずです。

• その６：セッションストレージはメモリに負荷を与えます。セッションデータは通常メモリ内に保持されるため、ユーザーあたり5キロバイトのセッションデータがあっても、10万人のユーザーがシステムにアクセスした場合は、500メガのデータがセッションストレージに負荷を与えます。数がもっと大きければ、、、計算すれば分かりますね。更にレプリケーションがある場合、そのデータはすべてレプリケートされ、すべてのノードに保持されます。

• その５：スティッキーセッションでは、ノードをアップグレードするためにノードをクラスタから引き離しますが、その際、ユーザーがログアウトするのを待つ（セッションの終了）か、セッションが期限切れになるのを待つ（通常30分ですが、ノードにアクティブなユーザーがいる場合は更に長くなる）必要があります。あるいはユーザーエクスペリエンスへの影響を無視して、セッションを強制終了する手もあります。ノードをクラスタ外し、更新してからまたクラスタに戻すという、単純なプロセスであるべきです。

• その４：セッションのために長期間にわたってノードをクラスターから外すことは、クラスタの処理能力が追いつかない、または少ないリソースで処理することになるというリスクにつながります。 2つのノードクラスタで、更新に備えて1つのノードを外している場合、2つ目のノードが停止した場合は、トラフィックを処理するために使用できるアクティブなサーバーがなくなることになります。

• その３：大規模なクラスタでは、セッションレプリケーションは実用的ではありません。ノードが実際のトラフィックを処理するよりことも、互いのセッションを同期させるために多くの時間を費やすことになってしまうからです。

• その２：クライアント側が望んでいるかどうかにかかわらず、セッションタイムアウトは、セッションデータを破棄します。ショッピングカートに3つの商品を入れた後、子供と遊び、戻ってきて再びログインしたときに、3つの商品がまだカート内にあるはずです。セッションにどれだけデータを詰め込んでも、ユーザーが再ログインした場合にデータがそこにまだある、と期待できます。

セッションを回避すべき最大の理由は、、、

---

• その 1 - 彼らはやっかいなのです！

少しふざけたように聞こえるかもしれませんが、、、しかし、実際これは正確で重要なのです。

上記の問題はすべて、Liferay、ポートレット、または実際にはあらゆるWebアプリケーションのデプロイ時に直面することです。セッションストレージを避けてれば、すべての問題も回避できます。

しかし、開発者にとって、セッションストレージは魅力的で簡単であることも理解しています。どこに格納すべきかわからないが、将来必要かもしれない・・・セッションストレージへ保持しよう！となりますよね。

しかし、実際には、セッションストレージは麻薬のようなものなのです。使い始めてしまうと、抜けられなくなるでしょう。気づかぬうちに、セッションを悪用してしまうこととなり、結果としてアプリケーションにも悪影響を及ぼすでしょう。本当に避けた方が良いのです。

ショッピングカートは、自身をセッションに保存しないのには理由があります：あまりにも問題があったからです。あなたのデータは、おそらく私がカートにどのような歯磨き粉を入れているかということよりもずっと重要なものなので、データの永続性に問題なければ、それで十分なはずです。

そして何より、もっと良い選択肢がたくさんあります！

複数ページにまたがるフォームで、1回の送信に結果をまとめたい？であれば前のページフォーム要素からの値を持つ隠しフィールドを、このデータ用にクライアントストレージとして使用します。

Cookieは、ストレージをブラウザにプッシュし、サーバーから遠ざけ、サーバー側のコードをステートレスにする、もう1つの方法です。

MongoのようなNoSQLデータベース内のデータストレージは非常に人気があり、クラスタ全体で共有でき（レプリケーションなし）、スキーマがないため、不完全なデータを簡単に永続化できます。リレーショナルデータベースでもこれは可能です。

というわけで、心から、セッションストレージを避けることをおすすめします。

---

本記事は以上です。
いかがでしたでしょうか？

記事に関するご意見、ご感想などございましたら、お気軽にyasuyuki.takeo@liferay.comまでご連絡ください。

---

■ これまで発信してきた日本語による技術コンテンツを、Qiitaでお読みいただけます。よろしければそちらの記事も合わせてご役立てください。
→https://qiita.com/yasuflatland-lf

■ Doorkeeperのライフレイコミュニティメンバー大歓迎！
コーポレートブログの技術コンテンツ更新情報など定期的におとどけしています。
→ https://liferay.doorkeeper.jp/