NTTデータ流 Hadoop活用のすすめ～インフラ構築・運用の勘所～

2011年9月26日
Hadoop Conference Japan 2011 Fall 講演資料

NTTデータ流Hadoop活用のすヽめ
～インフラ構築・運用の勘所～

株式会社NTTデータ
基盤システム事業本部
OSSプロフェッショナルサービス
猿田浩輔
Copyright © 2011 NTT DATA CORPORATION

自己紹介
 氏名
 猿田浩輔（さるたこうすけ）

 所属
 NTTデータ基盤システム事業本部
OSSプロフェッショナルサービス

 経歴
 2009年度にNTTデータに入社
 入社以来、OSSの検証/整備、案件への適用を行う
 特に、Hadoopとその周辺技術の検証/整備や案件適用に従事
し、経済産業省からの委託業務の実証実験にも参画
http://www.meti.go.jp/policy/mono_info_service/joho/dow
nloadfiles/2010software_research/clou_dist_software.pdf
 2011年1月に「Hadoop徹底入門」を執筆
Copyright © 2011 NTT DATA CORPORATION 2

Hadoop徹底入門、おかげさまで第3刷増刷決定です！
ありがとうございます！

Hadoopについておさらい


Ｈａｄｏｏｐクラスタの全体像
集中管理型の分散システム Hadoopマスターノード
 分散処理ジョブやデータの管
理はマスタノードで実施
 スレーブノードは、分散処理の NameNode JobTracker
実行やデータの実体を保存
Hadoopクライアント
 スレーブノードのクラスタへの
参加・離脱は自動的
L2/L3スイッチ
• 各ノードはマスターノードに定
期的に通知する
Hadoopスレーブノード群
スレーブノードを増やすことで、
全体の処理性能を向上させる L2スイッチ
スケールアウトアーキテクチャ
HDFS
 マスター： NameNode
 スレーブ： DataNode
DataNode DataNode DataNode DataNode DataNode
MapReduce TaskTracker TaskTracker TaskTracker TaskTracker TaskTracker
 マスター： JobTracker
ディスクディスクディスクディスクディスク
 スレーブ： TaskTracker


分散ファイルシステムＨＤＦＳと
ＭａｐＲｅｄｕｃｅフレームワーク
低価格サーバの大量使用による故障の大規模分散処理向けフレームワーク
発生が前提の設計 Googleが検索インデックス作成のため考案
データの多重化で可用性を担保する少なくとも5000台までスケールアウトしても性能向
従来とは運用利便性の考え方が異なる上することが知られている

DFSClientモジュール
HDFS MapReduce
NameNode
ブロックに分割して
ランダムに分散配置
MAP

SW SW SW

SHUFFLE
DataNodes

REDUCE

コピーをラックの内外に Rack
多重作成して冗長化

本日お話しする内容


Hadoopクラスタのインフラ構築・運用時に
よく挙がる話題

• Hadoopクラスタの可用性向上
 マスターノードのSPOF排除の話題

• 数百台以上のサーバから構成される大規模クラスタの
効率的な運用
 初期構築
 設定変更
 増設
 障害復旧

これらの課題に対して、
一定の軸に基づいたアプローチが必要

NTTデータにおけるHadoopへの取り組み

• NTTデータでは、2008年からHadoopに取り組み、数十台～千
台規模のHadoopクラスタを構築してきた実績を有する

• 2009年には経済産業省からの委託で実施した実証実験にお
いて、Hadoopクラスタの可用性確保の仕組みや、効率的な運
用のための自動構築・環境一元管理の技術を開発

これらの経験から得た知見をもとに

Hadoopクラスタのインフラ構築・運用に関する
ベストプラクティスをご紹介します


アジェンダ

 マスターノードの可用性向上の検討
 大量サーバの運用効率化
 クラスタのリソース情報の取得
 [ネタ]：トポロジ設計
 まとめ


マスターノードの
可用性向上の検討


Hadoopには可用性向上の仕組みがいっぱい

MapReduce
• スレーブノードに障害が発生しても、当該ノードが処理していたタスク
はほかのスレーブノードが処理し、ジョブは継続する
 スレーブノードの障害が、ジョブ全体の失敗に波及することを回避

HDFS
• ブロック（HDFS内のデータの断片）は、複数のスレーブノードに分散
してレプリカが格納される
 スレーブノードの障害によるデータの消失防止
• ラックアウェアネスという仕組みにより、レプリカはネットワークや電
源などが異なる系統のスレーブノードに格納することができる
 ネットワークや電源の障害発生時でも、データの消失を回避

マスターノードは改善の余地あり
MapReduce
• JobTrackerがMapReduceフレームワークの制御を集中管理
 ジョブ投入の受け口
 TaskTrackerが処理しているタスクの進捗状況や、タスク割り当ての
スケジューリングを集中管理
JobTrackerが停止した場合、実行中のジョブは停止。新規ジョブ投入不可

HDFS
• NameNodeがHDFSを集中管理
 HDFSのアクセス受け口
 HDFSの管理情報（ファイルシステムイメージ、更新ログ、ブロックと
DataNodeの対応表）を集中管理
NameNodeが停止した場合、HDFSにアクセスできなくなり、ファイルの参照
や新規作成ができなくなる。管理情報が消失した場合にはHDFS上のデータ
復元が不可能

いろんな取り組みがある。将来に期待！
MapReduce
• NextGeneration Apache Hadoop MapReduceでは、
ZooKeeper(分散コーディネーションサービス)でマスターノードの可
用性を向上 (#MAPREDUCE-279)

HDFS
• いくつかの方式が提案されている
 AvatarNode (#HDFS-976)
 BackupNodeのホットスタンバイへの転用 (#HDFS-2124)
 High Availability Framework for HDSF NN (#HDFS-1623)
 再起動無しでNameNodeの再設定 (#HDFS-1477)
 Etc...
近い将来にはHadoop自体の仕組みで
マスターノードの可用性向上が実現できそうだが・・・

Hadoopだけにこだわっても・・・
Hadoopクラスタから、一歩引いて視野を広げる
“Hadoopクラスタのみ”で完結するシステムは存在しない

Hadoopクラスタだけ頑張って可用性向上する必要はある・・・？

データロード処理結果の受け渡し

外接システム外接システム

過去のデータは復旧 Hadoopクラスタ
した後、さかのぼって受け渡しの期限まで
ロードすればOK に復旧すればOK

充分なレベルって？
Hadoopクラスタから、一歩引いて視野を広げる
“Hadoopクラスタのみ”で完結するシステムは存在しない

Hadoopクラスタは、全体の一部分でしかない
データロード処理結果の受け渡し

• 外接要件など、連携箇所との整合性をとる
• 一部分だけ過剰な可用性を追求しない。全体と
してのダウンタイム短縮や、SLA遵守を目指す
フロントの外接システム
外接システム
• シンプルな方式を選択する
Hadoopクラスタ
（ほかの部分と同じコンセプト/運用方法)

バランスが重要

マスターノードにダウンタイムが発生する主な理由
• ソフトウェア障害 HAなど、しくみでダウンタイムを
短縮できる領域
• ハードウェア障害 (切り替えは比較的簡単)
• メンテナンス
• オペレーションミスしくみだけではなく、
運用や設計の工夫が必要な領域
• 突発的な停電 (安全な停止手順や復旧時の切り戻し)

トラブル以外にも、停止する場合がある！
復旧手順なども考慮して
コントロールしやすい方式を選択することが大事

可用性向上の検討指針

実績のある枯れた技術を駆使

• “新しいもの”も魅力的だが、安定性も重視。その時点での”最善
の方法”を、可能な限り選択する
• “もっと良い方法”は十分検証し、使い倒して実績を積んでから
• 運用のことを考えて、コントロールしやすい方法を選ぶ

NTTデータでは、これまでオープンソースを利用したシステム構築を数多く行ってきた。
Pacemaker（Heartbeat)などのHAクラスタリングソフトウェアを用いた可用性向上方式
のノウハウを有している


枯れた技術の組み合わせでも充分いける
数百～千台規模のクラスタで実際に採用した方式

• Pacemaker(Heartbeat)などのHAクラスタリングソフトウェアと、DRBDなどのディス
クミラーリングソフトウェアを組み合わせる
• PostgreSQLなどとHeartbeatを組み合わせた運用実績に裏打ちされた、
確かな選択

• 切り替わりの契機となる監視項目とし
て、Hadoop特有の項目も考慮

相互監視 • 切り替えからサービス再開までにかか
OSS OSS
る時間も考慮(ブロックとDataNodeの
Pacemaker Pacemaker 対応表を作るために必要なブロックレ
ポートの収集に時間がかかる)
OSS OSS
データ同期 • “切り替え”だけではなく、”切戻し”の
DRBD DRBD 手順も検証し、オペレーションミスの要
因を排除

大量サーバの
運用効率化


大規模なHadoopクラスタの運用上の課題
数百台以上の規模のHadoopクラスタの運用上の課題

初期構築時/設定変更時/ 機器の台数が増えると、いずれか
増設時に１台１台対応しての機器/いずれかの部位に障害
いては、時間がかかるが発生する確率が高い

• 複数台同時かつ短時間で効率 • 予期しないときの、予期しないトラブ
的に初期構築/設定変更/増設ルに備えた対策
を行う • 確実に復旧できる方法を用意し、最
悪の復旧時間を制御する

運用設計の検討指針

オペレーションのパターンを最小限に抑える

• 統一された運用設計で、オペレーションミスを排除
• 障害発生時の”例外”対応を最小化
• 所要時間の最悪値を制御
クラスタのライフサイクルイベントの共通性に着目し、
で発生するイベント集約したオペレーションパターン
• 初期構築 • OSの自動インストール
• 設定変更  複数台のサーバに同時にOSをインス
• 増設トール
• 障害回復 • 構成管理
 複数のサーバに、一貫した設定を適用
多様な方法がある中で、統一された方法で簡素化する

OSの自動インストール/構成管理方式例

OSS

• PXEブート + Kickstartで、電源ボタン一つ
ポチっとな！
でOSインストールが完了
• Puppetにより、複数のサーバで一貫した
OSS 設定を適用可能
• 機器交換に伴うヘテロな構成も考慮

• 数ラックずつ同時にOSインストール/設定
• 100台規模のサーバ群をおよそ90分で構築。設
定変更は3分で完了

運用の簡素化のための割り切り

障害復旧において、細かい切り分けは実施しない

• OSからのリカバリに失敗する場合は、代替機をセットアップし、
交換する

• あらかじめ許容できる縮退率(レプリカの数/処理能力)を把
握し、機器交換のタイミングを計画する(1日の終わり、週末
にまとめて実施するなど）

オペレーションの簡素化のためには、割り切りも必要

クラスタの
リソース情報の取得


リソース情報の取得方式例
OSS
Gangliaによるリソース情報の可視化
スケールする方式を設計するグループの代表とのみ通信する
ので、ボトルネックになりにくい

全体

マスタープロセスが
情報集約
Web上でグラフ表示ラック単位

サーバ単位

マルチキャストグループを作り、エージェント
プロセス同士で情報を共有

[ネタ]
トポロジ設計


電源系統を考慮したトポロジ設計

エッジスイッチごとにラックアウェアネスを構成すると、異なる電
源系統のスレーブサーバにレプリカが作られるとは限らない

電源系統に障害が発生した
場合、データにアクセスできな
くなる。データをロストする


まとめ


まとめ

方式・運用設計の軸となる考え方

① 部分最適ではなく、全体最適を目指す
 割り切るところは割り切る
② 熟知し、実績のある枯れた方法を選択する
 安定性も重視した選択
 いざという時のために、使い慣れた、コントロールできる方式
③ 可能な限りシンプルに
 システムの他の箇所と同じ規約/運用方針。運用のシンプル
さを追求し、オペレーションミスの排除
④ 万が一に備え、最悪のケースを制御する
 確実な復旧手順により、障害発生時の最悪復旧時間を制御
 実際の運用シーンを想定した手順の整備で確実を期す

ご清聴ありがとうございました。


NTTデータ流 Hadoop活用のすすめ ～インフラ構築・運用の勘所～

More Related Content

What's hot

Viewers also liked

Similar to NTTデータ流 Hadoop活用のすすめ ～インフラ構築・運用の勘所～

More from NTT DATA OSS Professional Services

Recently uploaded