Hadoopモデリング座談会(第5回)へ行ってきました
第5回とのことですが、自分は初めて参加しました。
そもそもHadoopとタイトルにつくイベントへ行ったのは、初めてでした。これまで遠巻きに見ていましたが、何か、色々あって参加することに。
- zusaar.com - zusaar リソースおよび情報
- 2011/06/29_Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第5回) #hadoopmodeling - Togetter
せっかくなのでノートを上げておきます。
1. 「鉄道システムへの誘い」 [twitter:@ayasehiro]さん
発表の目的は、「学生の方に鉄道システムに興味を持ってもらうこと!」とのこと。
鉄道システムの開発のお話
- システムは一度作ったら長く使う
- 耐用年数10年以上
- 開発のスパンも長い
- 長いときで5年くらい
- 製造に時間をかけられない
- 半分が開発、半分が試験
開発と開発の間が長いため、ノウハウが伝わりづらいし、人材育成がむずかしい。
新技術を採用するには、開発に入る4年くらい前から、調査研究して検証する必要がある。
採用する新技術の見極めがむずかしい。技術が登場した背景、設計思想、長く残りそうか否かを見極める。また、値段の安さよりも、保守体制を重視して決めることが多い。市販製品のトラブル時の問題切り分けは、口コミや文献だけに頼るのではきびしいため、保守契約が必須。
鉄道システムの概要
ICカード決済系は似たシステムが他業界にもあるけれども、今日のお話は、ガチの鉄道運行システム。
1960年代から始まったシステム化・・・
- マルス座席予約システム
- コムトラック運行管理システム
- ヤックス貨物システム
このうち、マルスとコムトラックは、世代を超えて進化してきた。
- 輸送計画
- 列車の運行を計画する。時刻表の元になる情報を作るシステム。
長期計画(1年〜数年)をベースに、短期計画(数日〜4半期)を重ねて、計画する。
車両運用(どの車両がいつどこを走るか)をきめたり、乗務員運用(乗務員がいつどの電車に乗るか)をきめたりする。
- 運行管理
- なるべく遅延をなくすように再スケジュールするシステム。上記の輸送計画で事前に行ったことを、臨時で起きた事象に合わせて、全部やり直す。
信号を変えたり(信号制御)、ポイント切り替えをしたり(進路制御)、追い越し地点を変えたり(運転整理)する。
信号制御と進路制御は、エラーがあると大事故につながるので、組み込み系の中でも特に厳密に作られる領域。一度作ると、耐用年数は25年に及ぶ。
- 列車の遅延検知方法は、昔は電話だったが、今は機械化されている。レール内部に絶縁体が仕込まれていて、電車の通過で電流がON/OFFされる情報を、収集している。
- 信号を線路に設置しても、走行スピードが速くて視認できないため、運転席に表示される。
どこに分散技術を適用するか
- 鉄道は、人口減も影響して、長期的には成長が鈍る産業なので、効率化が重要
- 鉄道は社会インフラなので、動かないと大混乱が起きる
- ベテラン(運行管理を手で行える、いわゆる「スジ屋」さん)が引退しつつある
鉄道システムでは、データ入出力、関連システムとの情報連携、可用性の担保、よりよい運行計画の立案支援が必要とされている。
これらのうち、分散技術は可用性に、最適化技術は計画立案支援に、それぞれ活用できる。
可用性担保への適用
- 鉄道システムに求められる可用性の要件は特殊
- 切断の許容限度は10秒以内
- 送信されてくるデータは再送されない
(現在)ハードが高い、ソフトウェアの作り込みが複雑 → (将来)汎用ハードを使い、作り込みを減らしたい …といった事情もある。
また、輸送計画は、たくさんのバッチ処理からなり、中には数時間オーダのものもある。
そのため、分散技術が合致する。
# 「壊れることを前提に設計して、安めのハードを並べて落ちないような仕組みで実行すること」と、「たくさんのデータを並列に扱う」というあたりの要請が、分散技術に合致する、という意味であると捉えました。
計画立案支援への適用
鉄道の計画問題はこれまで色々と研究されてきたが、実用化は少ない。原因は、計算に必要なコンピュータリソースの不足と、開発そのものが保守的であること。
しかし、最近はメモリが安くなり、昔の最適化理論を実装して試せるようになった。
ベテランの人がいなくなる前に技術を継承してシステム化したい、というニーズも高まっている。
たとえば、車両運用は、最適化問題のひとつ。業務要件から制約条件を設定するところは大変だが、一般的なモデルに落として、一般的な解き方が適用できる。
鉄道システムというと、複雑で高度な計算を実用化しているイメージかもしれないが、鉄道会社の多くでは実用化はまだまだこれから。いろいろな分野の技術者や学生を、鉄道業界に引き込みたい!とのこと。
開発スパンが長いので、新しい設計手法を入れるには、かなり前から検証しなければならず、大変。しかし、業務要件やシステム使用者の意識は常に変化しているので、システム屋は追随していく必要がある。
その他、興味深かった話題
- 「足りるように計算する」より、「足りない計算結果を速く出す」方針
これは、ayaseさんが研究・実用化をすすめているシステムの方針。「乗務員が足りなくならないように車両運用を計算する」のはとても大変なので、「乗務員が足りない」という計算結果を現場にいち早く渡し、運用で対応してもらうというお話でした。
運用下では、時間をかけてカンペキな計算結果を出すことが、かならずしも最適化の正解ではないんだな、と感じました。
- 最適化の対象範囲を決めるのがむずかしいという課題
運行計画を調整するときは、基本的に終電までの最適化をするけれども、これは長い目でみると部分最適。たとえば、翌日、翌年を考えた全体最適な結果を出そうと考えると、むずかしい、というお話。
- オススメ本『鉄道ダイヤ 回復の技術』
- 作者: 電気学会・鉄道における運行計画・運行管理業務高度化に関する調査専門委員会
- 出版社/メーカー: オーム社
- 発売日: 2010/08/06
- メディア: 単行本(ソフトカバー)
- 購入: 1人 クリック: 25回
- この商品を含むブログ (4件) を見る
面白そう。
ayaseさんが、「私も鉄道システムをまだ13年しかやっていない。ベテランの職人を相手にするこの世界では駆け出しです」とおっしゃっていて、凄まじい世界だと思いました。
2.「九州電力におけるHadoopの取り組みについて」株式会社キューデンインフォコム e−ビジネス部さん
# スライドを必死で見ていて、ノートをほとんど取れませんでした。残念。
# というわけで、細かい話は他の方のまとめを期待するとして、自分が受け取ったエッセンスだけ。
概要
九州電力さんは、将来に向けて次の課題を抱えていたため、対応の必要があった。
- ホスト計算機システム(バッチ)再構築
- 両現用センター構成(高可用性を実現する構成)
- スマートグリッド
また、次のような内部事情や要請もあった。
- コスト減を目指して今のベンダーを見直すための内部の技術力強化
- 商用パッケージのカスタマイズが限界(値段も高い)
- OSS製品の運用に向けて取り組みたい(脱ベンダーまかせ)
そこで、「クラウドをサーバ仮想化技術と分散処理技術の合体とみなして、それぞれをOSS製品で実現する」検証を、2009年度から始めた。
今回は、主に、現行の基幹バッチとまったく同じものをHadoopで実行した場合の効果測定検証について、商用製品との比較もまじえて、紹介してくださった。
技術的ハイライト(※私見)
- 多数のサーバから上がるアラートを1つのサーバで受けると破綻しそう → RabbitMQ利用
- ヒープメモリが規定量を超えたら、キューにメッセージを入れて、GCを動かす仕組み
- マルチハイパーバイザ対応は、libvirtのAPIを使って実装
- Hadoopに最適化したアーキテクチャ設計
- 起動したマシンから順次処理を開始し、命令を受け入れたら確実に実行させる
- 命令をキューに投げて、リソースのあるノードだけが取りに来る
- Lindaモデル(# これ? http://en.wikipedia.org/wiki/Linda_(coordination_language:title))
こうして構築されたVolante Cloudでは、仮想マシン50台を14分で起動できるようになり、
Hadoopを使ったバッチ処理も、従来19時間かかっていた計算を32分で実行できた、とのことです。
すごいですねぇ。
ベンチツール
検証で利用されたというツール。# 使ったことがないので、単純に興味があります。
ベンダーロックインについての考え方
電力会社では、発電や送電などの部門ごとに外部ベンダーがいて、それぞれの部門にがっつり入り込んでいるそうです。
トラブルのときも、ベンダーさんを呼んで解決を依頼するやり方が、主流のようです。
しかし、「ベンダーにまかせきりになることで、組織が自分で何かしようとする体質でなくなっていくのは問題だ」という意識が一部にはあり、今回のOSS製サーバ統合基盤の整備が進められたそうです。
ベンダーロックインについて、これまで自分は、ベンダーの倒産や買収、または、たとえそのようなことがなくても、サポートの縮小やライセンス料の引き上げなどがリスクとなるために、避けることが望ましいのだと思っていました。
今回のお話しであった観点を今まで持っていなかったのですが、ありそうな話ではあります。考えさせられました。