2011/07/13

2011/06/29 Hadoop勉強会メモ(電力編)

Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第5回)のメモ。
九州電力におけるHadoopの取り組みについて

■Hadoopを採用するに至った経緯
情報システム部が抱える問題
 各部門が個別最適なシステムを導入
 各部門ごとに異なるベンダー

システムのサイロ化、ベンダーロックイン

■将来に対する課題
 ・ホスト計算機システム再構築への対応
  →ネックはバッチ処理
 ・両現用センター構成への対応
  →事業(サービス)継続のため
 ・スマートグリッドへの対応

■そのなかで...
 ・コスト削減要求
 ・技術革新に対する対応
 ・商用パッケージ、カスタマイズの限界
  →パッケージ代<カスタマイズ代...となることも
 ・脱ベンダーロックイン

→オープンソース適用に向けての取り組み

■H21研究概要
クラウドの要素技術はサーバ仮想化技術(KVM)と分散処理技術(Eucalyptus)である
オープンソースと商用(VMWear)の性能・機能コスト比較
Hadoopの性能検証
 →台数増やすとどうなるかの実証とか
  →サーバも構築した(b10台、仮想100台以上)
  →結果:台数↑、性能↑(リニアに向上していくみたい)
Hadoopの信頼性
 →実行中にノードを抜いたりして、うまく動くか検証したりした
クラウド環境下における管理手法
 ・リソースの状況とアプリケーションの情報の一括管理
  →管理システムが複雑に
  →RabbitMQ を使った検証

障害時の切り離しとか、複雑多岐になる
→データセンター全体の管理も重要になる

■H22研究概要
分散処理に特化した研究
昨年度からの課題
 ・サーバの仮想化・管理に関する課題
 ・分散処理に関する課題
 ・分散処理環境の運用監視に関する課題

目的
Hadoopを使って、九州電力の典型的業務システムを動かす(運用はしてないけどね)

1.サーバ統合基盤
monkey magic

仮想サーバリソースの有効活用
仮想サーバの自動制御
迅速なサーバ機動
複数の仮想化ソフトウェア(KVMでも、VMWearでもなんでも)に対しても、その差異を気にせず利用可能
ネットワーク的に違う拠点でも制御可能

Eucalyptusは使わず、自社開発

libvertを使った。

Eucalyptus
10台以上リクエストタイムアウトが発生したり...

 ・要求台数に満たなくても、起動したものからサービス提供
  →Lindaモデル

monkey magicとの連携→amazon EC2との連携が可能

Volante Cloud
と連携APIで接続
 →ハイブリッドクラウドを実現

50台起動→15分ほど。既存の7分の1くらいで実現可能に

2.運用監視基盤
 →既存の監視に加え、判断、制御を行う
  ※monkey magicのDSLで定義可能

3.分散バッチ処理
hadoopサーバ(仮想10台。実際は物理2台ですんだ)
処理対象の電柱データ104万本

抽出してHDFSに

処理性能が676倍に

コストも物理サーバ2台といい感じ。

プログラム処理の効率化
 →プログラムに前後関係が無いことが前提

障害発生
 ・レプリケーション
 ・復元可能

■H23研究概要

課題
・仮想サーバの動的・固定割当
・分散バッチに関する課題
 →開発標準の策定
 →分散バッチ開発フレームワークの整備
  →Asakusa

将来へ向けて
 ・スマートグリッドの時代に
  →メーターの取替えが必要なので、実際10年はかかるw
  →10年後のシステムに商用ソフトがいいのか...
   →Hadoopみたいなのがいいのでは?
  →24h×2×800万世帯...
   →1日に膨大なデータが増えていく

テネシー州の電力公社の事例

まず、将来目指すべき理想像を掲げる
新しい技術の導入は、段階を踏んで
コミュニケーションは大切

diskIOを分散するのが分散化のポイント
→ストレージを共有するタイプなら、Hadoopは向かない...

仮想化で何がマズイか)ディスクIOが共有するので<共有ストレージとか使う場合 これだと分散の意味がいない・・。IOを分散するような仮想化じゃないとストレージがボトルネックになる
仮想化上のHadoopで気をつけなければいけないのは、ディスクを共有しないこと

Asakusa、monkey magic の連携は必然的にそうなった。
monkey magic
 →8月にオープンソース化
 →Asakusaのコードリーディングの会あり

0 件のコメント:

コメントを投稿