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

9,872 views

Published on

『Hadoop Conference Japan 2011 Fall』での講演資料。

NTTデータ
基盤システム事業本部 OSSプロフェッショナルサービス
猿田 浩輔

Published in: Technology
0 Comments
24 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
9,872
On SlideShare
0
From Embeds
0
Number of Embeds
1,224
Actions
Shares
0
Downloads
0
Comments
0
Likes
24
Embeds 0
No embeds

No notes for slide

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

  1. 1. 2011年9月26日 Hadoop Conference Japan 2011 Fall 講演資料 NTTデータ流Hadoop活用のすヽめ ~インフラ構築・運用の勘所~ 株式会社NTTデータ 基盤システム事業本部 OSSプロフェッショナルサービス 猿田 浩輔Copyright © 2011 NTT DATA CORPORATION
  2. 2. 自己紹介 氏名  猿田 浩輔 (さるた こうすけ) 所属  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
  3. 3. Hadoop徹底入門、おかげさまで第3刷増刷決定です! ありがとうございます!Copyright © 2011 NTT DATA CORPORATION 3
  4. 4. HadoopについておさらいCopyright © 2011 NTT DATA CORPORATION 4
  5. 5. Hadoop クラスタの全体像集中管理型の分散システム Hadoopマスターノード  分散処理ジョブやデータの管 理はマスタノードで実施  スレーブノードは、分散処理の NameNode JobTracker 実行やデータの実体を保存 Hadoopクライアント  スレーブノードのクラスタへの 参加・離脱は自動的 L2/L3スイッチ • 各ノードはマスターノードに定 期的に通知する Hadoopスレーブノード群スレーブノードを増やすことで、 全体の処理性能を向上させる L2スイッチ スケールアウトアーキテクチャHDFS  マスター: NameNode  スレーブ: DataNode DataNode DataNode DataNode DataNode DataNodeMapReduce TaskTracker TaskTracker TaskTracker TaskTracker TaskTracker  マスター: JobTracker ディスク ディスク ディスク ディスク ディスク  スレーブ: TaskTracker Copyright © 2011 NTT DATA CORPORATION 5
  6. 6. 分散ファイルシステムHDFS と MapReduceフレームワーク 低価格サーバの大量使用による故障の 大規模分散処理向けフレームワーク 発生が前提の設計 Googleが検索インデックス作成のため考案 データの多重化で可用性を担保する 少なくとも5000台までスケールアウトしても性能向 従来とは運用利便性の考え方が異なる 上することが知られている DFSClientモジュール HDFS MapReduce NameNodeブロックに分割してランダムに分散配置 MAP SW SW SW SHUFFLE DataNodes REDUCE コピーをラックの内外に Rack 多重作成して冗長化 Copyright © 2011 NTT DATA CORPORATION 6
  7. 7. 本日お話しする内容Copyright © 2011 NTT DATA CORPORATION 7
  8. 8. Hadoopクラスタのインフラ構築・運用時に よく挙がる話題 • Hadoopクラスタの可用性向上  マスターノードのSPOF排除の話題 • 数百台以上のサーバから構成される大規模クラスタの 効率的な運用  初期構築  設定変更  増設  障害復旧 これらの課題に対して、 一定の軸に基づいたアプローチが必要Copyright © 2011 NTT DATA CORPORATION 8
  9. 9. NTTデータにおけるHadoopへの取り組み • NTTデータでは、2008年からHadoopに取り組み、数十台~千 台規模のHadoopクラスタを構築してきた実績を有する • 2009年には経済産業省からの委託で実施した実証実験にお いて、Hadoopクラスタの可用性確保の仕組みや、効率的な運 用のための自動構築・環境一元管理の技術を開発 これらの経験から得た知見をもとに Hadoopクラスタのインフラ構築・運用に関する ベストプラクティスをご紹介しますCopyright © 2011 NTT DATA CORPORATION 9
  10. 10. アジェンダ マスターノードの可用性向上の検討 大量サーバの運用効率化 クラスタのリソース情報の取得 [ネタ]:トポロジ設計 まとめCopyright © 2011 NTT DATA CORPORATION 10
  11. 11. マスターノードの 可用性向上の検討Copyright © 2011 NTT DATA CORPORATION 11
  12. 12. Hadoopには可用性向上の仕組みがいっぱい MapReduce• スレーブノードに障害が発生しても、当該ノードが処理していたタスク はほかのスレーブノードが処理し、ジョブは継続する  スレーブノードの障害が、ジョブ全体の失敗に波及することを回避 HDFS• ブロック(HDFS内のデータの断片)は、複数のスレーブノードに分散 してレプリカが格納される  スレーブノードの障害によるデータの消失防止• ラックアウェアネスという仕組みにより、レプリカはネットワークや電 源などが異なる系統のスレーブノードに格納することができる  ネットワークや電源の障害発生時でも、データの消失を回避 Copyright © 2011 NTT DATA CORPORATION 12
  13. 13. マスターノードは改善の余地あり MapReduce• JobTrackerがMapReduceフレームワークの制御を集中管理  ジョブ投入の受け口  TaskTrackerが処理しているタスクの進捗状況や、タスク割り当ての スケジューリングを集中管理JobTrackerが停止した場合、実行中のジョブは停止。新規ジョブ投入不可 HDFS• NameNodeがHDFSを集中管理  HDFSのアクセス受け口  HDFSの管理情報(ファイルシステムイメージ、更新ログ、ブロックと DataNodeの対応表)を集中管理NameNodeが停止した場合、HDFSにアクセスできなくなり、ファイルの参照や新規作成ができなくなる。管理情報が消失した場合にはHDFS上のデータ復元が不可能Copyright © 2011 NTT DATA CORPORATION 13
  14. 14. いろんな取り組みがある。将来に期待! 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自体の仕組みで マスターノードの可用性向上が実現できそうだが・・・ Copyright © 2011 NTT DATA CORPORATION 14
  15. 15. Hadoopだけに こだわっても・・・ Hadoopクラスタから、一歩引いて視野を広げる “Hadoopクラスタのみ”で完結するシステムは存在しない Hadoopクラスタだけ頑張って可用性向上する必要はある・・・? データロード 処理結果の受け渡し外接システム 外接システム 過去のデータは復旧 Hadoopクラスタ した後、さかのぼって 受け渡しの期限まで ロードすればOK に復旧すればOKCopyright © 2011 NTT DATA CORPORATION 15
  16. 16. 充分なレベルって? Hadoopクラスタから、一歩引いて視野を広げる “Hadoopクラスタのみ”で完結するシステムは存在しない Hadoopクラスタは、全体の一部分でしかない データロード 処理結果の受け渡し• 外接要件など、連携箇所との整合性をとる• 一部分だけ過剰な可用性を追求しない。全体と してのダウンタイム短縮や、SLA遵守を目指す フロントの外接システム外接システム• シンプルな方式を選択する Hadoopクラスタ (ほかの部分と同じコンセプト/運用方法)Copyright © 2011 NTT DATA CORPORATION 16
  17. 17. バランスが重要 マスターノードにダウンタイムが発生する主な理由• ソフトウェア障害 HAなど、しくみでダウンタイムを 短縮できる領域• ハードウェア障害 (切り替えは比較的簡単)• メンテナンス• オペレーションミス しくみだけではなく、 運用や設計の工夫が必要な領域• 突発的な停電 (安全な停止手順や復旧時の切り戻し) トラブル以外にも、停止する場合がある! 復旧手順なども考慮して コントロールしやすい方式を選択することが大事 Copyright © 2011 NTT DATA CORPORATION 17
  18. 18. 可用性向上の検討指針 実績のある枯れた技術を駆使• “新しいもの”も魅力的だが、安定性も重視。その時点での”最善 の方法”を、可能な限り選択する• “もっと良い方法”は十分検証し、使い倒して実績を積んでから• 運用のことを考えて、コントロールしやすい方法を選ぶNTTデータでは、これまでオープンソースを利用したシステム構築を数多く行ってきた。Pacemaker(Heartbeat)などのHAクラスタリングソフトウェアを用いた可用性向上方式のノウハウを有している Copyright © 2011 NTT DATA CORPORATION 18
  19. 19. 枯れた技術の組み合わせでも充分いける 数百~千台規模のクラスタで実際に採用した方式• Pacemaker(Heartbeat)などのHAクラスタリングソフトウェアと、DRBDなどのディス クミラーリングソフトウェアを組み合わせる• PostgreSQLなどとHeartbeatを組み合わせた運用実績に裏打ちされた、 確かな選択 • 切り替わりの契機となる監視項目とし て、Hadoop特有の項目も考慮 相互監視 • 切り替えからサービス再開までにかか OSS OSS る時間も考慮(ブロックとDataNodeの Pacemaker Pacemaker 対応表を作るために必要なブロックレ ポートの収集に時間がかかる) OSS OSS データ同期 • “切り替え”だけではなく、”切戻し”の DRBD DRBD 手順も検証し、オペレーションミスの要 因を排除 Copyright © 2011 NTT DATA CORPORATION 19
  20. 20. 大量サーバの 運用効率化Copyright © 2011 NTT DATA CORPORATION 20
  21. 21. 大規模なHadoopクラスタの運用上の課題 数百台以上の規模のHadoopクラスタの運用上の課題 初期構築時/設定変更時/ 機器の台数が増えると、いずれか 増設時に1台1台対応して の機器/いずれかの部位に障害 いては、時間がかかる が発生する確率が高い • 複数台同時かつ短時間で効率 • 予期しないときの、予期しないトラブ 的に初期構築/設定変更/増設 ルに備えた対策 を行う • 確実に復旧できる方法を用意し、最 悪の復旧時間を制御するCopyright © 2011 NTT DATA CORPORATION 21
  22. 22. 運用設計の検討指針 オペレーションのパターンを最小限に抑える • 統一された運用設計で、オペレーションミスを排除 • 障害発生時の”例外”対応を最小化 • 所要時間の最悪値を制御クラスタのライフサイクル イベントの共通性に着目し、で発生するイベント 集約したオペレーションパターン• 初期構築 • OSの自動インストール• 設定変更  複数台のサーバに同時にOSをインス• 増設 トール• 障害回復 • 構成管理  複数のサーバに、一貫した設定を適用 多様な方法がある中で、統一された方法で簡素化する Copyright © 2011 NTT DATA CORPORATION 22
  23. 23. OSの自動インストール/構成管理方式例 OSS • PXEブート + Kickstartで、電源ボタン一つポチっとな! でOSインストールが完了 • Puppetにより、複数のサーバで一貫した OSS 設定を適用可能 • 機器交換に伴うヘテロな構成も考慮 • 数ラックずつ同時にOSインストール/設定 • 100台規模のサーバ群をおよそ90分で構築。設 定変更は3分で完了Copyright © 2011 NTT DATA CORPORATION 23
  24. 24. 運用の簡素化のための割り切り 障害復旧において、細かい切り分けは実施しない • OSからのリカバリに失敗する場合は、代替機をセットアップし、 交換する • あらかじめ許容できる縮退率(レプリカの数/処理能力)を把 握し、機器交換のタイミングを計画する(1日の終わり、週末 にまとめて実施するなど) オペレーションの簡素化のためには、割り切りも必要Copyright © 2011 NTT DATA CORPORATION 24
  25. 25. クラスタの リソース情報の取得Copyright © 2011 NTT DATA CORPORATION 25
  26. 26. リソース情報の取得方式例 OSS Gangliaによるリソース情報の可視化スケールする方式を設計する グループの代表とのみ通信する ので、ボトルネックになりにくい 全体マスタープロセスが情報集約Web上でグラフ表示 ラック単位 サーバ単位 マルチキャストグループを作り、エージェント プロセス同士で情報を共有 Copyright © 2011 NTT DATA CORPORATION 26
  27. 27. [ネタ] トポロジ設計Copyright © 2011 NTT DATA CORPORATION 27
  28. 28. 電源系統を考慮したトポロジ設計 エッジスイッチごとにラックアウェアネスを構成すると、異なる電 源系統のスレーブサーバにレプリカが作られるとは限らない 電源系統に障害が発生した 場合、データにアクセスできな くなる。データをロストするCopyright © 2011 NTT DATA CORPORATION 28
  29. 29. まとめCopyright © 2011 NTT DATA CORPORATION 29
  30. 30. まとめ 方式・運用設計の軸となる考え方 ① 部分最適ではなく、全体最適を目指す  割り切るところは割り切る ② 熟知し、実績のある枯れた方法を選択する  安定性も重視した選択  いざという時のために、使い慣れた、コントロールできる方式 ③ 可能な限りシンプルに  システムの他の箇所と同じ規約/運用方針。運用のシンプル さを追求し、オペレーションミスの排除 ④ 万が一に備え、最悪のケースを制御する  確実な復旧手順により、障害発生時の最悪復旧時間を制御  実際の運用シーンを想定した手順の整備で確実を期すCopyright © 2011 NTT DATA CORPORATION 30
  31. 31. ご清聴ありがとうございました。Copyright © 2011 NTT DATA CORPORATION 31

×