Hadoopモデリング座談会（第5回）へ行ってきました

Cloud Event

第5回とのことですが、自分は初めて参加しました。

そもそもHadoopとタイトルにつくイベントへ行ったのは、初めてでした。これまで遠巻きに見ていましたが、何か、色々あって参加することに。

せっかくなのでノートを上げておきます。

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に最適化したアーキテクチャ設計

こうして構築されたVolante Cloudでは、仮想マシン50台を14分で起動できるようになり、

Hadoopを使ったバッチ処理も、従来19時間かかっていた計算を32分で実行できた、とのことです。

すごいですねぇ。

ベンチツール

検証で利用されたというツール。# 使ったことがないので、単純に興味があります。

ベンダーロックインについての考え方

電力会社では、発電や送電などの部門ごとに外部ベンダーがいて、それぞれの部門にがっつり入り込んでいるそうです。

トラブルのときも、ベンダーさんを呼んで解決を依頼するやり方が、主流のようです。

しかし、「ベンダーにまかせきりになることで、組織が自分で何かしようとする体質でなくなっていくのは問題だ」という意識が一部にはあり、今回のOSS製サーバ統合基盤の整備が進められたそうです。

ベンダーロックインについて、これまで自分は、ベンダーの倒産や買収、または、たとえそのようなことがなくても、サポートの縮小やライセンス料の引き上げなどがリスクとなるために、避けることが望ましいのだと思っていました。

今回のお話しであった観点を今まで持っていなかったのですが、ありそうな話ではあります。考えさせられました。

というわけで

とても面白かったです。発表されたお二方、主催の[twitter:@okachimachiorz1]さん、ありがとうございました。

お土産に頂いたmonkeyな付箋も、使わせてもらいます。