WR blog

PofEAA 5th

PofEAA第五回読書会に参加してきた。

発表に関連した議論の内容を中心に、箇条書きでメモ。

セッションステート

レコードデータとサーバセッション
- セッションステートをRDBに書き出したレコードはレコードデータではない。
- publicかつpersistentなデータがレコードデータであると理解した。
文中の「データベースとサーバセッションの中間の位置」とは何か？
- 中間の位置ではなく、中間の特性（？）ということみたい。
- 「位置」なる訳は、かなりグレー。
セッションの特性に応じて、セッションアフィニティ(=スティッキー)にすべきか？セッションマイグレーション（セッションレプリケーション）すべきか？が変わってくると思われる。
- 具体的には・・・セッションに格納するデータ量の大小、セッションの維持時間
- セッションに格納するデータ量が多い場合→ アフィニティ?
- セッションの維持時間短い場合→ アフィニティ?
（セッションアフィニティに関連して）ロードバランシングについて・・・
- 書籍では「クライアントIPアドレスによってロードバランシングする」なる記載があるが、SSLのキーでロードバランシングできるものもある。暗号化の影響を受けず、かつ、決め細やかなロードバランシングが実現できる。
- 書籍では、「クライアントIPアドレスによるロードバラシンシングが機能しにくい」例として、Proxyサーバを介したアクセスとなるAOLが上げられている。が、日本の場合、Docomoが問題となりやすい。
  - DOCOMO携帯からのアクセスの場合、リクエストのたびにIPアドレスが変化するので、IPアドレスでロードバランシングすることは問題。サブネット単位で行う必要が有るようだ。
Session Stateとパフォーマンス
- ステートの格納先をServerとするか？DBとするか？の選択基準としては、パフォーマンスよりリソースの観点が重要なのでは？
- ちなみに、「パフォーマンス」のファウラー流定義は、邦訳 P6あたりにある。
PHPにはセッション情報をインメモリに持つ手段が無い。
- スクリプト起動のモデルがCGI的である故
- デフォルトで、セッション情報はファイルに格納する
- RDBMSのテーブル(永続化ストレージ or インメモリ）に格納することもできる。
Rails
- セッションID?セッションステート?の保存先としてメモリ、DB、ファイルが選択可能
- フレームワークレベルでのクラスタリングの考慮は特に無い。
用語「MySQLセッションステート」
- PHPな人はステート情報でもなんでもMySQLに格納するに格納する様をさした言葉みたい。データの特性に応じてインメモリテーブル、ディスク上のテーブルなどを使い分ける。
- 上記に関連して・・・、はてなのMySQL使用方法
  - 検索用DBサーバ、INSERT用DBサーバが別
  - DBフォレスト前段にキャッシュサーバが大量に・・・
最近は、サーバアフィニティで設計するケースが多いかも。
- サーバはめったに壊れないし。
AJAXならば、サーバ側で状態を保持しなくてもOK(らしい。WR：よく理解できず・・・)
- ただし、システム全体をAJAXだけで構築することは一般的でないため、結局、サーバ側でもログイン情報を持つことになる。
  - 典型的な事例：ファイルのダウンロード（サーブレットなどを用いて実装するのが一般的）

分散ストラテジー

パフォーマンス比較
- 別プロセス vs 別ノードで、あまり差異が無いのでは？
- （ある参加者が昔測定した結果）同一プロセス：別プロセス：別ノード＝１：？（ききそびれ・・・）：数千、数万倍オーダー
- CORBAにおける、別プロセス：別ノードの比較 → 別プロセス：別ノード＝１：１０程度
  - 考察：OSがループバック通信の最適化がしている可能性がある。
  - UNIXドメインを使うともっと速い（Solaris2.4 では、共有メモリで実装している。速いことが期待できる）
  - また、Windowsの場合、同一ノード内別プロセス通信 → Local RPC で通信 ⇒速い！
EJB1.4とWebサービス
- コーディングレスでWebサービス化可能
  - 発刊時点ではEJB1.4は存在しない。
CORBAにも類似の仕組み(IIOP over HTTP)が存在するが、Webサービスというわけではない。over HTTPなだけ。
XML Webサービスのパフォーマンス
- RPCに比べると2,3桁違う
- Apache XML-RPCと比較してもWebサービスは1,2桁遅い
- やっぱりRMIは圧倒的に速い
  - 理由のひとつ：ソケットのキープアライブをする。これだけでも5倍ぐらい差が出るはず。
DTO:ローカルとリモートの2つあることに注意！
- ファウラーは、リモートDTOのみをDTOと読んでいるかも。（狭義の/J2EEパターンの文脈におけるDTO？）

オンライン型バッチ処理

書籍所有者は2名だけ。orz. ま、しょうがないか。
30分弱で10スライド進んだ。
- あと33スライド(笑)
APPサーバ～DBサーバ間NWラウンドトリップ回数削減のtips
- SQLステートメントのセミコロンつなぎ
- JDBC batchUpdate
- (ひがさんのコメントの内容を忘れた・・・）
一旦リストアしてリラン pattern
- いったんリストアしてリランなんて、60’sのテクニックだぜ！
- 単にリランしても無駄なケースが多いのでは？
  - バッチ失敗の原因はデータ不備。よって、投入データorマスタデータの修正後にリランするのが常套手段と思われる。
    - とすると、夜間張り付いている人が必要だよね？
      - バッチリランのため、外部からログイン可能/状態チェック可能な経路/手段を設けておいたケースあり
ミニバッチ pattern
- 読み取り一貫性問題：みんなあまりピンと来てないみたいなので、次回もうすこしブレークダウンして・・・
- ミニバッチの並列実行：並列実行を想定して物理設計しないと（Oracleパーティション&ディスク構成とか？）。無闇に並列化してもNG
そもそも、オンライン型バッチの必要性って？
- システムの全サービスをインサービス状態のままでバッチを実行するのではなく、バッチ実行が影響する特定のサービスをアウトオブサービス状態とするのが一般的では？
  - システム要件的に許されるならば、それが（コスト的に）一番かも。
「エンタープライズシステムはバッチでしょう！」ということなので、次回も地味に頑張ります。