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 件のコメント:
コメントを投稿