<< ITシステムにおけるアーキテクチャについて | main | Javaヒープサイズのチューニングについて(世代別の場合) >>

スポンサーサイト

一定期間更新がないため広告を表示しています

| - | - | - |

セッション共有について

Web系のシステムでセッションを用いるとき、永続化するか、他のクラスターメンバーと共有するかという選択肢がある。

セッションを永続化すれば、古くなったセッションを永続化してメモリ消費量を抑えたり、再起動後も利用可能にできるようになる。また、永続化されたセッションを、他の負荷分散対象クラスターメンバーと共有できるようにすれば、処理中のメンバーで障害が発生して、他のメンバーへリクエストが割り振られても、割り振り先メンバーで、セッションを継続的に利用できるようになる(再ログインせずにサービス利用を継続できる)。

かつては、セッション永続化・セッション共有を実現するシステムが多かったが、システムの規模・複雑さが増大していく中で、トランザクショナルなデータをセッションに格納して利用することが好まれなくなり、冪等な処理をステートレスに実装することが多くなった結果、重要性は低下した。

現状でも業務システム(Systems of Record (SoR))の場合は、セッション永続化・セッション共有が求められることがあるが、業界トレンドとは別の観点として、以下のことについて気を配る必要がる。

  • セッションの永続化は、原則として非同期書き込みになるので、必ずしも全てのケースを救えるわけではない(タイミングによって、巻き戻りや、業務データ用DBなど他の永続化機構との不整合が発生する可能性がある)。
  • セッションの永続化で必要になるI/O量は、トラフィック量×サイズに依存するため、ハイトラフィックなシステムの場合、業務DBに対するI/Oよりも多くなる。
  • セッションI/O量を削減するためには、セッションサイズを最低限度に抑える必要がある(トランザクショナルに必要なデータはDB等で永続化し、トランザクションはステートレスに実装する)。
  • 大量のI/Oを処理するために、ネットワーク帯域を圧迫しないように考慮する必要がある(業務セグメントと分ける、複数ポートを束ねてイーサチャネル構成にする、など)。

セッションの永続化・共有化が必要と考えられる場合は、まず物理層で実現可能な量であるかどうかを評価する必要がある。もし、業務処理に影響を与える可能性がある場合は、セッションのサイズを減らしたり、セッション永続化・共有化に用いるネットワークのポート増設・イーサチャネル構成、セグメント分離などを検討する必要がある。

セッションのサイズを減らすということは、セッションの永続化・共有化の必要性を減らすことでもあるので、最終的には、上記の費用と得られる効果とを比較・評価した上で、セッション永続化・共有化を利用するかどうかを決定する必要がある。トランザクション量・アプリの複雑さが高まると、それだけ多くの取り組みが必要になるので、このトレードオフは不利な方へ傾いていくことになる。

| 日記 | comments(0) | trackbacks(0) |

スポンサーサイト

| - | - | - |
コメント



この記事のトラックバックURL
http://msugai.jugem.jp/trackback/1081
トラックバック
CALENDAR
Sun M T W T F Sat
  12345
6789101112
13141516171819
20212223242526
2728293031  
<< August 2017 >>
WATCH
SEARCH THIS BLOG
LATEST ENTRIES
CATEGORIES
SELECTED ENTRIES
RECENT COMMENTS
RECENT TRACKBACKS
Twitter
MY WEB SITES
PROFILE
ADMIN
MOBILE
qrcode
ARCHIVES
SPONSORED LINKS