目次
「Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第5回）」に参加しました。300名入るイベントルームでしたが、後ろの方まで人が埋まっていました。
ということで、主に自分用ですが、メモを取ったので。
※二次会行きたかった。。。
1.「鉄道システムへの誘い」
@ayasehiro（本名無理w）
Hadoopの話はありません。
○鉄道系基幹システムの開発
実態：
耐用年数：１０年以上
開発期間：数年～５年程度
開発規模：～10Mステップ、10k人月～
ほとんどテスト、しかも異常系が主体。
夜間に実際に鉄道を走らせて試験したり。
開発サイクルが長い
人材育成が難しい、ノウハウがたまらない。
開発自体はほとんど時間がなく、設計・製造・試験など新規技術の採用が難しい。
開発４年前の調査・検証自体が２年程度。
Hadoopも調査中。
○鉄道システム３大システム
マルス（予約オンラインシステム）（1960～）
コムトラック（運行管理システム）（1972～）
ヤックス（ヤード自動化システム）（1968～1984）
○鉄道輸送システムとは
用語：
運行を計画する=>輸送計画
列車を運行する=>運行管理
需要想定＋営業施策＋その他（お召し列車など）＝列車ダイヤ作成
基本計画（長期）＋短期計画（数日～四半期程度）＝列車ダイヤ（重ねあわせてできあがり）
ダイヤの計画（発車時刻など）と車両運用（車両自体の走る組み合わせ（仮の車両））の作成
＋乗務員運用（乗務員の運用計画）
運行管理：
なにも起きなければすることなし。（車両故障、天候、人身事故などによる整合性を取る作業）
＝事前に計画した輸送計画をすべて見直し
遅延の検知は？
昔：人による伝令
今：システムによる検知（レールに電流流して検知）
運転整理（実際に遅れた）：
部分運休、折り返し駅の変更などにより対応
元の計画になるべく近づく形で修正していく。
新幹線、山手線、京浜東北線などは速度信号という信号が表示される。
線路上に信号はないらしい。
○鉄道システムを取り巻く情勢
少子高齢化・人口減少のため凋落産業となっている。
社会インフラの責務＝動くのが当たり前
2007年問題（ベテランの引退）＝スジ屋さんは最近いないらしい。
高度な判断支援をするシステムが必要
連続稼動＝分散技術を適用できない？
関係各所との情報共有
計画立案のための情報支援＝最適化技術を適用できない？
○分散処理技術の適用
個人的な感想
可用性（連続稼動）のための仕組み
バッチ処理
○分散技術の適用
・連続稼動
active-active構成がメイン
主系の出力だけを行う。問題が出れば副系の出力。
3系統の出力を比較器にて出力もある
magiシステム
問題点：
ハードが高い（H社）
ソフトウェアの作り込みが複雑＝テストが前パターンできない
解決案：
汎用的なハードが使いたい。
作り込みも減らしたい
・バッチ処理：
Asakusa使えないかなーw
○最適化技術の採用
コンピュータ技術の発展
2007年問題
職人に言わせれば最適化はいらない、俺の言うことを聞けｗ
・車両運用のモデリング
車両数大=>組み合わせ大
制約条件が多い
車両運用の場合、走行累積キロの条件もある
->有向グラフにモデル化される。（ただし、グラフ化するまでが大変）
・乗務員運用のモデリング
車両と違い、乗務員は1回で2人とか運べる（運転士＋移動する人とか）
・車両割当のモデリング
やはり、グラフ化が可能
・乗務員交番のモデリング。。。など
結構一般的なモデルに落とし込める。ただし、落し込みが大変。
机上研究だったものが、コンピュータの発展により実証研究になりつつある。
○まとめ
鉄道システムはまだまだ未到の領域が残っている。
開発サイクルが長いため、保守的な開発になる（35年前の設計思想からあまり変わってなかったりする）
しかし業務要件やシステム利用者の意識は変化している
興味を持たれた方は、ぜひ、我社に！（社名は2次会でｗ）
○Q&A
Q：鉄道システムのカルチャーってイケイケ？保守的？（@okachimachiorgさん）
A：最新技術も知らないとだめじゃないかという人が出てきている。
コア部分（安全第一なところ）＋周辺領域（ある程度融通が効きそうな部分）と考えることができるんじゃないかって人も出てきている。
JR九○＝先進的
JR四○、北○道＝お金ない
JR○海＝超保守（企業的に超保守）
JR東、西＝うーむ？
東京メト○（運行計画）、阪○＝先進的
京○急行＝基本人間で進路制御w
基本的には新しいものには興味をもつ人たちでは。
Q：Su○caとかで分散処理は利用出来るんでは？
A：匿名なので外側から見ていると分散処理はいろいろ使えるんでは？
ログデータからいろいろできるんじゃないの？活かすべきでないの？
使いどころはいっぱいある。
Q：鉄道システムでどうしようもなくなったことはあるか？
A：保守体制が一番気になる。
OSSとかならまだ調べられる。ミドルウェアなどの保守契約が必要。
保守体制が確立されてればある程度の保守費用は飲み込む。
どうしようもないことはないが、今すごく困ってることは
Excelで帳票を出したいとかいわれること。（ちょっと前に作ったシステムでExcel2003。バージョンあげると速度が遅くなったりするｗ）
ilog社のものを使ってたが、IBMに買収されて保守費用があがってこまってるｗ
保守が10年と長いため、サポートなどの折衝が必要。
Q：最適化の適用範囲は？
A：走行順序（どこで追い抜くか）の算出に活用。ほぼ完成でユーザ教育中。
1列車の波及がかなり影響が出る。ダイヤだけ見ると列車だけだが、乗務員も関係しており、大変。
ある時点から終電までを最適化の対象としたりして割り切っている。
また、不足分について算出が出来れば、そこで打ち切ったりもする。
2.「九州電力におけるHadoopの取り組みについて」
株式会社キューデンインフォコム e－ビジネス部 @hisashi_yano
概要：2年間関係したOSSをメインにしたシステムの話。
○九州電力の概要
現在風当たりが強い業界。
東電の1/10くらい
部門ごとに大手ベンダーが関わってる。
○Hadoop採用の経緯
部門ごとに個別最適なシステムを導入していてベンダーロックインされてる。
・ホストのリプレース
・両現用センター構成への対応
・スマートグリッドへの対応
問題点
・コスト削減
・技術革新への中の人の対応（内部でも問題を理解できるように）
・商用パッケージのカスタマイズの限界
・脱ベンダーロックイン（実は楽なんだけど。。。）
○過去2年間の研究内容
・H21年度の結果
テーマ：クラウドの要素技術の研究
KVM、Eucalyptus、wakame、hadoop
性能比較：VMWareとKVM->ベンチマーク比較
結論：性能的にあまり問題なし。
MapReduceの耐障害性など
ダミーデータにより台数増加による影響を検証
結論：台数大->性能向上
ストリーミングは性能劣化する
スループットはリニアに向上
信頼性は？
実行中にノードを抜いたりして検証。
結論：問題なし。
クラウド環境におけるシステム管理手法
複数ハードで1アプリという構成になる。
監視対象が膨大になる。
障害発生時の切り離しや監視対象も膨大。
データセンター自体を監視する仕組みが必要では？というところで終了。
・H22年度の結果
分散に特化した研究
前年度の課題
サーバの仮想化・管理に関する課題
分散処理に関する課題
分散処理環境の運用監視に関する課題
目的：
Hadoopを本番への適用（実際にはダミーデータ＋本番の仕組み）
柔軟なサーバ統合基盤（サーバを起動->バッチを起動->回す仕組み）＝MonkeyMagic
libvirtを使ってる
50台の仮想サーバの起動が10数分で完了。
運用監視基盤（monkey magic）
仮想、実サーバ混在の監視
監視状況（サーバの状況）から判断して制御する仕組みを構築
DSLにてルール（判断＋制御）を指定
・ジョブの監視
・ジョブの実行管理
・構成管理の省力化
volanteと連携が可能＝AmazonWebServiceとも連携可能
・サーバリソース＋アプリケーションの一括監視が可能
分散バッチ処理の概要
RDBからKV形式にして抽出し、MRで回してRDBに戻すという研究
対象：
配電部門（電柱の設備情報の目視検査）のデータの月間バッチ処理
現状：
19時間程度かかってる。
テスト環境：
実サーバ2台（仮想10台）
MySQL、Javaで実装
処理内容
電柱104万本
巨大バッチを分割して実装
結果
MySQL1台では15日以上かかる処理（現行システムで19時間）
処理が32分で終了！他でも効果でるよね。
バッチ短縮の理由は？
1.データアクセスが分散された
2.処理の並列化（多重化出来る部分がうまくできた）
分散処理を書くのに2名死亡。。。
適用基準の策定、開発ガイドライン、フレームワーク整備などが必要。
・H23年度は？
Asakusaの適用など。
・さらに今後は？
スマートグリッドへの適用
->メーターの交換が必要だが、10年くらいかかる
->スパンが長い（10年）ので商用製品だときつい？
データ量も半端ない。
テネシー州とClouderaでOpenPDCってのやってるらしい。
電力と気温の関係は密接な関係あり。
エアコンが割合を占めてるから。
過去実績と予想気温データから分析するのにHadoop使える！
・2年間やってきて思うこと
将来目指すべき理想像を掲げるのが重要
新技術導入は段階を踏むことが必要
コミュニケーション大切！
○Q&A
Q：仮想化環境のオーバヘッドは？（I/O）
A：台数を増やしたときにどうなるか？というのを検証したかった。
アプリ配布も考えていたので、物理サーバに縛られたくなかった。
Q：仮想化に関して気をつけたM/RのPGで気をつけたことありますか？
A：まったくないです。
Q：日本でスマートグリッドははやるの？
A：電力会社的にはやりたくない。費用対効果があまりない。
Q：今後のスケジュールは？
A：文書管理システムの組織名変更などの処理時間が540時間とかでてくるらしい。
これをHadoopで対応してみようかと思ってる。
Q：Asakusaをどう評価していくのか？
A：開発効率性があがるか？は検証する予定。1/3くらい楽になるんじゃないかなぁ？byのぐちさん
バッチの種類などにもよると思うが、標準化も指標にする予定。
結果はまたこの場で報告する予定。
Q：Asakusa＋MonkeyMagicの連携はどんなこと考えてる？
A：MonkeyMagicを運用基盤として行く予定。合意が取れればだけど。
※MonkeyMagicもOSSにするよー
まとめ
Hadoopから少しずつ離れつつありますが、やはり興味があるので、非常に楽しく話を聞けました。
また、今回はインフラ分野のシステムということで、システムに要求されるレベルや
運用周りにも気を配っている話が聞けたのが収穫でした。保守期間が長いため、テストが長い＝
運用もしっかりと考慮を入れた設計、実装が必要になるというのは最もだと思います。
ただ、少しずつ修正が入るアジャイルなども同様かと。
MonkeyMagicが出来上がってきた背景の話を聞いて、さらに興味が湧いてきたところです。
今後もかかわりが少ないかもしれないですが、ウォッチしていきたいと思いました。
ただ、興味あるモノが多すぎるので、優先度をつけつつこなして行かないと。。。
少しずつでも身につけていきたいと思う今日このごろです。
※追記：Twitterでコメントを頂いたので、忘れないように追記。
コメントを貰えるだけでもうれしい。やはり、アウトプットしたらフィードバック貰いたいし。
ありがとうございます！
Twitter / @cocoatomo: あの質問をまとめるとこうなるのかぁ…… 最適化そのも …
Twitter / @cocoatomo: @johtani すみません, コメントはコメント欄 …
Twitter / @cocoatomo: @johtani そこらへんの理論って最後には計算量 …
Twitter / @cocoatomo: @johtani あの話し振りだとどうもまだ本格的に …
あと、まとめも出来ていたので、ついでに。
Togetter - 「2011/06/29_Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第5回） #hadoopmodeling」
関連するブログも見つけたので。
第5回Hadoop座談会の感想 - ひしだまの変更履歴
Hadoopモデリング座談会（第5回）へ行ってきました - 虎塚
comments powered by Disqus
See Also by Hugo
- JVM Operation Casual Talksに参加しました #jvmcasual
- Riak Meetup #3 #riakjp に参加しました。
- Hadoop Conference Japan 2011 Fallに参加してきました。(Jugemより移植)
- 第1回 データ構造と情報検索と言語処理勉強会に参加しました。(Jugemより移植)