Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第5回）行ってきました

昨日参加した内容を整理します。

☆Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第5回）

トークした人：JR(システム部門)
九州電力(システム部門)

JRどこだかは不明だったですが。
かなり突っ込んだ話をされてました。

中身濃かったです。

■鉄道基幹システムの開発
現状のシステムの構成など

耐用年数:10年〜25年(長いものでは25年変わらない・・・汗) ⇒ 鉄道ポイント切替の耐用年数が25年らしい
開発基幹:1〜5年
新しいMW/HWの仕組みを導入するに当たって
2年調査
2年検証
その結果を持って開発にあたる

鉄道システムの略歴
1960年〜 : マルス・・・座席予約オンラインシステム
1972年〜 : コムトラック・・・新幹線運行管理システム
1968年〜1984年: ヤックス・・・貨物システム

信号機を使っての運転手への指示はなくなってきている。

●山手線
●京浜東北線
●新幹線

上の3つは運転席に信号がある

今後の市場分析をしっかりとしているのもあった。
□売上上がることはない
□社会インフラこれを守る事が大前提

今のシステム構成は基本的には
Active/Active
非同期処理 (i.e.)主系プリントアウトのみ
副系その他

[ここでおもろかったのがこれ！]
[知らなかったわ！]

□ □ □
|_____|_____|
|
|
比較器

2 out of 3
どこのリソースがあいているかの把握をして判断する。
この辺の機器は、1台数千万円（汗)

【運用状況】
□車両運用のモデリング
⇒ 難しさ ⇒ ・制約条件が多い(車両と駅と乗務員の関係) ⇒ 最適化をするも組み合わせ数膨大
・数式化するのが大変 ⇒ 駅にいった時に次にとりうる値が無数にある。
□乗務員運用のモデリング
⇒ 基本的には車両運用モデルと同じ ⇒ ただ、便乗もできるという式に変換できる
□最適化をするにしても・・・
◎人と車両のバランスが重要 ⇒ 結局これが難しい(最終的に部分最適にしかなっていない[発表者の意識])

[トークした人個人感想]H社が費用が高すぎる
連続稼働させるためには、保守の体制が必要になるので、それを実践してくれるのはここ。
古い体質の人がいるのと、信頼性を担保してくれるところに委託している。
それと・・・。日本であれば、ベンダーに言えば、何とかしてくれる。・・・・。
↓↓↓↓↓↓↓↓↓↓↓
これってベンダーロックイン以外の何モノでもないし何も変化しない。

まぁ、などなどの時代背景があり、ずっと課題であったバッチ処理の時間をなくしたい。
↓↓↓↓↓↓↓↓↓↓↓
そんなこんなで、Hadoopに置き換えてみ用の検証が始める。
背景としてメモリもCPUも値段が安くなってきた。

購入した機器:
□NameNode CPU:2コア
メモリ:16GB
Disk:500GB
台数:1台
□DataNode CPU:2コア
メモリ:8GB
Disk:146GB
台数:10台

構成は聞きながらメモったつもりだけど、間違ってるかも・・・。

比較検証をどのようにやったか、
・Hyper-V、VMware,KVM
上記のサーバで、それぞれHadoop環境を構築。
ゲストサーバは、100台

KVMがベストな結果を出した！

【発表者個人の感想】
・実際にやってみたけど、Asakusaが使えるかどうかはわからない。
・OSSだとベンダーが何とかしてくれるが通用しないのでないかで少々不安。
・コストが劇的に違えば当然やるべき

【その他[へぇ〜]情報】
・JR四国・北海道お金がない。
施策を打てるような状況にはない。
・JR九州結構なんでも新しい事を取り組もうと動く。
・京急全然システム化されていない。
時刻表をみても、これ本当に大丈夫か？と疑問を抱く程緻密なスケジュールになっている事もある。
ムチャなダイヤを組んでいる。
それっていつまでできるのかは大きな疑問とのこと・・・。
・東京メトロ最新的な所を取り組んでいる
・Suicaは、かなりの顧客情報を持っている
⇒ どこの駅で何が変われたかまで把握している。
⇒ なんで、この情報をつかっていかないのかがわからない。。。
・この人が抱えている現在の課題
●導入してなくなったなどの会社はあるのか？
⇒ それはない。
ただ、エクセル出力。これが問題。
2003を未だに使い続けている。 ⇒ マイクロソフトとも結構がっぷりおつらしい。
●アイログ社ソルバを使っているが、IBMに買収され、保守費用が上がるとの旨があった・・・。
なにいっとんじゃぁ〜とのこと・・・。
●保守体制耐用年数とのバランスだからなかなか変える事ができるのかどうかがある。

ただ、I/O性能に頼った時には、絶対性能でない。
オーベーヘッドが大きくなる。そこが課題になる。

■■■■■■■■■■■
■■九州電力 ■■■■
■■■■■■■■■■■
■会社規模東京電力の3分の1
世帯数:800万世帯
日本の1割の電源供給
※原子力発電所1機あたりの発電量=170万KW

■将来に対する課題
・メインフレーム(バッチの事があり、やめられないんじゃないか)
・両現用センター構成への対応(DR)・・・現状やっていない東京電力はデュアル構成を完全に組んでいる。
・スマートグリッドへの対応

年間コスト：数百億円
・商用パッケージのカスタマイズの限界
作りこみの費用が
パッケージ＜カスタマイズの状態・・・。

・各部門が各ベンダーと契約をしているので、それをやめたい
ベンダーロックイン、システムのサイロ化

■評価したきたもの

- - 平成21年---

・ユーカリピタス
・MapReduce 耐障害性 ②
・lmbenchで検証 ①
・unixbenchで検証 ①
VMwareとKVMと比較
・信頼性の検証 ③

①Hyper-V、VMware、KVM
KVMが一番良かった

②10台の物理サーバ 110台の仮想サーバ
Rubyで環境構築
作りこむのに、全然Hadoopを知らないSEが2カ月死亡。

③信頼性の検証
・MapReduceの最中に、LAN引っこ抜いたり、OS止めたり、
問題になる事はなかった。。。[いまいち説得力に欠けた・・・]

■管理
・クラウド管理方法これが課題になるだろう。
利用は、RabbitMQ
↓↓↓
参考URL:http://sourceforge.jp/magazine/10/08/26/0241237
・Java Heapメモリ 8MB超えたらキューにためる[いまいち意味がわかってない]
それでガベコレを稼働させる

- - 平成22年---

1.サーバの仮想化＆管理
2.分散処理の課題（オープン系で動かせるか)
3.監視ソフトを使えるか

[条件]全て本番のデータをコピーして検証
1.サーバ統合基盤(Monkey Magic)-----→ Amazon EC2との互換性あり
⇒!!!分散バッチ処理に最適化された統合基盤を作るのが目的!!!
⇒□柔軟さ⇒自社開発した ◎libvirtを利用
↓↓↓
http://www.atmarkit.co.jp/flinux/rensai/linuxkvm03/03a.html

・Lindaモデル
・Volante Cloud
これを利用することで、50台のサーバを14分で起動！

・複数拠点(DR)は先送り

2.運用管理基盤
判断と制御に柔軟性を
DSLで全て定義
◎メッセージキューイング
Hitachi JP1 と Mokey Magicを比較

□RDP CPU:2コア
メモリ:16GB
Disk:500GB
台数:1台
□サーバ CPU:2コア
メモリ:16GB
Disk:72GB
台数:10台

i.e. 電柱の管理方法は九州だけでも104万本

実行したバッチ(本番のバッチと同じ状態にした)
[現状]DB3台 Oracle 7多重（何がかわからない）
処理時間：15時間程度 1本当たり 365ms
処理方法：不明(PL/SQLか？？？)

[今回]mysql ⇒ MapReduce ⇒ mysql
処理時間：32分 1本当たり 2ms
処理方法：java

これで上に報告しても信用してもらえなかった。
なんでこんなに早くなるのかが理解できないと・・。
※アクセスの回数が激減そのために、分散ファイルシステムを利用！
これを組み込むのにSEが2ヵ月・・・。めっちゃ大変だった模様。死亡とまで言われてた。

3.Monkey Magic これが活用できる
誕生ストーリー
↓↓↓
参考URL:http://www.ec-one.com/product/product_cloud/monkeymagic_birth.html

OSS化を今年の8月に実現するらしい(EC-oneさん)
ちょっと使えるかどうかを確認したいなぁ。
比較内容の細かいところは全然わかりませんが、JP1と比較をしていて、圧倒的にMokey Magicがよろしいとのことでした。

- - 平成23年---

・リソース固定 or 動的をどうするのか？
・データボリューム
24時間 * 2(30分毎) * 30日 * 800万世帯 = 115億レコード/月
※発表者の方曰く
TVAとClouderaのOpenPDCがHadoopど真ん中とのことでした・・・。

その他現在評価中って感じでした。

- - - - -

◎まず将来目指すべき理想像を掲げる
◎新しい技術は段階を踏んで検証してから導入する ⇒ 今回やって思った事は、ロジカルな結果をしっかりと残す事が非常に有益。
◎コミュニケーションは非常に大切

仮想化のオーバーヘッド(I/O)これがネックになったら、最後。
⇒ こちらは物理(IA)サーバと仮想化とのバランスは、お金とのバランスも絡んでくる！
どういう構成が一番適正かは、検証を繰り返すのみ。

NetApp,EMC ⇒ I/Oがネックになったら、最後