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

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

by Yasuyuki Takeo

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

画像

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

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

以下の知識レベルの方たち、ユースケースが対象です。ご参照ください。

  • 中級レベル*
  • Liferay DXP開発に必須の知識

*レベルの定義については、こちらのブログの冒頭で紹介しています。


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

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


セッションストレージはやっかいである

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

  • その10:スティッキーセッションでは、クラスタ内の他のノードの容量が大きくても、Webアドレスからのトラフィックは同じノードへ送信されます。まだ容量に余裕があるノードに、トラフィックを転送できないため、クラスタの利点の一部が失われます。その上、ユーザーは最初にアクセスしたノードのみ使い続けることになるため、同じノード上で誰かが重い処理を始めないことを祈ることになります。
  • その9:スティッキーセッションでは、ノードに障害が発生した場合、そのノード上のユーザーは、セッションストア内のものをすべて失います。クラスターは使用可能なノードにアクセスを切り替えますが、セッションデータを復元することはできません。
  • その8:セッションレプリケーションを使用してノードの機能停止を回避しようとすると、ノード間ネットワークトラフィックが増加し、ほとんどの場合、不要なセッションデータが転送されます。ノード障害が発生した場合には必要ですが、最後にノード障害が起きたのはいつでしょうか?この「念のため」の準備のために、どれだけのネットワークとCPU容量を犠牲にしているか考えてみてください。
  • その7:スティッキーセッションデータも、セッションレプリケーションも、災害復旧の際に役に立ちません。プライマリデータセンターがネットワークから外れ、ユーザーがDRサイトに切り替えられた場合、復旧のためにバックアップとファイルをDRに同期させることがよくありますが、誰もセッションデータの同期は必要ではないはずです。
  • その6:セッションストレージはメモリに負荷を与えます。セッションデータは通常メモリ内に保持されるため、ユーザーあたり5キロバイトのセッションデータがあっても、10万人のユーザーがシステムにアクセスした場合は、500メガのデータがセッションストレージに負荷を与えます。数がもっと大きければ、、、計算すれば分かりますね。更にレプリケーションがある場合、そのデータはすべてレプリケートされ、すべてのノードに保持されます。
  • その5:スティッキーセッションでは、ノードをアップグレードするためにノードをクラスタから引き離しますが、その際、ユーザーがログアウトするのを待つ(セッションの終了)か、セッションが期限切れになるのを待つ(通常30分ですが、ノードにアクティブなユーザーがいる場合は更に長くなる)必要があります。あるいはユーザーエクスペリエンスへの影響を無視して、セッションを強制終了する手もあります。ノードをクラスタ外し、更新してからまたクラスタに戻すという、単純なプロセスであるべきです。
  • その4:セッションのために長期間にわたってノードをクラスターから外すことは、クラスタの処理能力が追いつかない、または少ないリソースで処理することになるというリスクにつながります。 2つのノードクラスタで、更新に備えて1つのノードを外している場合、2つ目のノードが停止した場合は、トラフィックを処理するために使用できるアクティブなサーバーがなくなることになります。
  • その3:大規模なクラスタでは、セッションレプリケーションは実用的ではありません。ノードが実際のトラフィックを処理するよりことも、互いのセッションを同期させるために多くの時間を費やすことになってしまうからです。
  • その2:クライアント側が望んでいるかどうかにかかわらず、セッションタイムアウトは、セッションデータを破棄します。ショッピングカートに3つの商品を入れた後、子供と遊び、戻ってきて再びログインしたときに、3つの商品がまだカート内にあるはずです。セッションにどれだけデータを詰め込んでも、ユーザーが再ログインした場合にデータがそこにまだある、と期待できます。

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


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

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

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

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

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

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

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

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

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

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

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

 


 

 

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

記事に関するご意見、ご感想などございましたら、お気軽に[email protected]までご連絡ください。

 


 

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

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

 

 

業界最高の評価

Gartner

Gartnerレポート:『リーダー』に位置づけ
ライフレイは9年連続で、Gartner社によるデジタルエクスペリエンスプラットフォーム(DXP )分野のマジック・クアドラントにおいて、リーダーに選出されました。

レポートの詳細、ダウンロード