1. 背景
1.1. 様々なデータの集中・蓄積。どう使うか
1.2. クラウドの発展。分散基盤
1.2.1. ヘテロな環境
1.2.1.1. メンテナンスによる交換
1.2.1.2. 搬入時期の違いによる
2. 商用への期待
2.1. 業務への適用性
2.1.1. スケールアウトする中で、求めるべき問題が解けるのか
2.1.1.1. 処理時間を台数でコントロールできるか
2.2. 信頼性
2.2.1. 一部は冗長構成を持たない
2.2.1.1. 冗長化させる
2.2.2. 信頼性確保のための方針
2.3. 運用性
2.3.1. 監視
2.3.1.1. スケーラブルであること
2.3.2. 自動設定
2.3.2.1. サーバの種類に応じた設定
3. 評価・検証
3.1. アプリ実装評価
3.1.1. 利用者が求める処理時間・処理精度の要件を満たせるか
3.1.1.1. 決められた時間内で処理を完了
3.1.1.1.1. 処理時間と精度のバランス
3.1.1.1.2. 情報の粒度のコントロール
3.1.2. 渋滞解析
3.1.2.1. データの種類
3.1.2.1.1. 様々な場所から集められる
3.1.2.1.2. 計測ポイントの連続性
3.1.2.2. 解析
3.1.2.2.1. 短期間の情報から現状を分析し表現する
3.1.2.2.2. 長期間の情報から統計
3.2. 基盤評価
3.2.1. 運用スケーラビリティ
3.2.1.1. 100台までのスケールを検証
3.2.1.2. 障害発生からの増設、その際の運用負荷を作業時間を軸に検証
3.2.1.2.1. 自動化、Web画面集約で作業者人数、時間を削減
3.3. シナリオ実験
3.3.1. 運用しながらどう戦えばいいか
3.3.2. 処理時間・精度
3.3.2.1. 3段階のレベルアップを想定
3.3.2.1.1. 小規模⇒中規模⇒大規模
3.3.2.1.2. 中規模と大規模の違いは情報精度
3.3.3. データ量
3.3.3.1. ディスク容量不足に注意
3.3.3.1.1. HDFS領域以外にMapの結果を格納する領域を用意する
3.3.3.2. アプリケーションデータ
3.3.3.2.1. TaskTracker起動時に同期しておくなど
3.3.4. 時間の見積もり
3.3.4.1. 少量データによるパラメータの決定（精度）
3.3.4.2. 大規模データによる処理時間の見積もり
3.3.5. 障害テスト
3.3.5.1. タスクの障害は、別のスレーブサーバで担保される
3.3.5.2. スレーブサーバの障害
3.3.5.2.1. 別スレーブサーバでのジョブ実行
3.3.5.2.2. 障害のスレーブサーバが保持していたデータのレプリカ
3.3.5.3. ラック障害
3.3.5.3.1. ラック内スレーブの保持するジョブ、データが別ラックに移される
3.3.5.4. 増設
3.3.5.4.1. 増設したスレーブサーバはすぐに処理可能なスレーブサーバとして利用（CPU負荷軽減）
3.4. 今後の課題
3.4.1. データセンター間をまたぐ場合も考えられる
3.4.2. リモートからの運用作業を想定
3.4.3. データの収集（センサー）からクラウドへ格納するところまでにフォーカス
3.4.4. 複数アプリケーションの実行
3.4.4.1. ジョブのスケジューリング
4. MapReduce
4.1. Map
4.1.1. Mapでデータを分割、分散させて処理
4.1.2. 依存のない処理を実行
4.1.3. リソース消費
4.1.3.1. HDFS上データの読み出し
4.1.3.2. Map処理
4.1.3.3. Map処理結果をローカルディスクへ書き出し
4.2. Shuffle
4.2.1. Mapの結果を定義した条件で振り分ける
4.2.2. 振り分けたデータをKeyでソートする
4.2.3. リソース消費
4.2.3.1. Map処理結果の中間ファイルを取得
4.2.3.2. 中間ファイルの結合
4.2.3.3. 結合後Keyでソート
4.3. Reduce
4.3.1. Mapの処理結果から同じキーを持つデータを同じサーバにて集計
4.3.2. 依存関係が生まれるところ
4.3.3. Keyで配置するため、データに偏りが出る可能性
4.3.4. リソース消費
4.3.4.1. Reduce処理
4.3.4.2. Reduce処理結果をHDFSへ書き出し
4.4. 入力データの決定
4.4.1. Key-Value
4.4.2. 中間データ(MapとReduce処理の間)
4.4.2.1. Reducdeでまとめる単位をKeyに
4.4.2.2. 大事
4.5. 設計技法
4.5.1. 処理のフローを分割
4.5.1.1. データフローを考える
4.5.1.1.1. どの処理で、どの情報が欲しいか
4.5.1.1.2. Map, Reduce, 中間データ
4.5.2. アプリケーションボトルネックの把握
4.5.2.1. 最も時間のかかる処理を見つける
4.5.2.1.1. 逐次処理によるシミュレーション
4.5.2.1.2. 時間のかかる処理(Map or Reduce)を分割
4.5.2.2. シミュレーション・エミュレーション
4.5.2.2.1. 少量データを対象として見積もる
4.5.2.2.2. シミュ/エミュレータ
4.6. 不得意な処理
4.6.1. MapReduce処理が再帰的に繰り返される
4.6.2. 前後の処理に依存するKeyを使う処理
5. 分散ファイルシステム
5.1. HDFS
5.1.1. NameNode
5.1.1.1. ファイルのメタデータを管理
5.1.2. DataNode
5.1.2.1. データブロックを管理
5.1.2.2. 複数のノードでレプリカを保持
5.1.2.2.1. Rack Awareness
6. 基盤
6.1. 環境制約
6.1.1. 実メモリ容量制約
6.1.1.1. ジョブ毎にヒープメモリ容量を決定可能
6.1.1.1.1. 統一された容量。混在環境は考慮されない
6.1.1.1.2. メモリ容量越えはスワップの原因に繋がる
6.1.2. ディスク容量制約
6.1.2.1. 不足は失敗につながる
6.1.2.2. RAID-0で対応
6.2. 考慮点
6.2.1. ネットワークコスト
6.2.1.1. 特にShuffle、ReduceのHDFS書き込み処理に負荷増大（特にShuffle）
6.2.2. Map Reduce同時処理数
6.2.3. ディスクI/Oの分散
6.3. 可用性
6.3.1. ファイルシステムに分散されたデータ
6.3.1.1. 複数のデータレプリカ
6.3.1.1.1. レプリカ数の調整
6.3.1.2. 単一のメタデータ
6.3.1.2.1. 複数のファイルシステムに保管
6.3.1.2.2. SecoundaryNameNode
6.3.1.2.3. 障害は処理継続不可能を意味する
6.3.1.2.4. 冗長構成による保護
6.3.1.2.5. 同期処理による保護
6.3.1.3. StandbyNodeの評価
6.3.1.3.1. 記載なし。（紹介まで）
6.3.2. MapReduceで分散された処理
6.3.2.1. JobTrackerが管理
6.3.2.1.1. 冗長化による保護
6.3.2.1.2. 同期処理による保護
6.3.2.2. TaskTrackerが処理
6.3.2.2.1. 故障時の別Trackerによるフォロー
6.3.2.3. ジョブを複数回失敗するとブラックリスト入り
6.3.3. スレーブサーバの可用性はコストバランス比較で
6.3.4. ネットワーク
6.3.4.1. ラック間スイッチの障害
6.3.4.1.1. ラック下のすべてのスレーブサーバを失う
6.3.4.2. マスタサーバ、スレーブサーバ間のスイッチ障害
6.3.4.2.1. 困る
6.3.4.2.2. 冗長化必須
6.4. 運用
6.4.1. 特徴
6.4.1.1. 対象ノードが多い
6.4.1.2. クラスタの構成が動的に変更されることを前提に設計されている
6.4.2. 注目点
6.4.2.1. 異なる機器が混在することを考慮
6.4.2.2. スケーラビリティ
6.4.2.2.1. 運用コスト
6.4.2.2.2. システム規模・構成に依存しない
6.4.2.3. 構成の動的な変更を受け入れられる運用
6.4.3. 方式
6.4.3.1. 構築
6.4.3.1.1. 完全自動化
6.4.3.2. 監視・障害検知
6.4.3.2.1. Web画面による監視
6.4.3.2.2. ジョブの実行状態の可視化
6.4.3.3. 設定管理
6.4.3.3.1. Puppet
6.4.3.4. 回復・増設
6.4.3.4.1. HDFSリバランス