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
* そもそも、オンライン型バッチの必要性って？
* システムの全サービスをインサービス状態のままでバッチを実行するのではなく、バッチ実行が影響する特定のサービスをアウトオブサービス状態とするのが一般的では？
* システム要件的に許されるならば、それが（コスト的に）一番かも。
* 「エンタープライズシステムはバッチでしょう！」ということなので、次回も地味に頑張ります。

### その他
* この人数になってしまうと、さすがにハンドル名と顔を一致させるのはムリ。
* 名札の導入に期待！
* 懇親会は1hほどで退散 ⇒ 友人のLive@三宿へ。