HDFSのスケーラビリティの限界を突破するためのさまざまな取り組み | Hadoop / Spark Conference Japan 2019 #hcj2019

HDFSのスケーラビリティの限界を
突破するためのさまざまな取り組み
〜エクサバイト級の分散ストレージを目指して〜
ヤフー株式会社浅沼孝信
2019年3月14日

自己紹介
2 Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止
 名前
– 浅沼孝信
 業務履歴
– 2012年度新卒入社
– HadoopやNiFiを用いた社内インフラの設計・開発
– Hadoopを中心としたOSS開発
– 2018年7月よりHadoopコミッター

もくじ
 HDFSの復習
 Router-based Federation (RBF)
 Observer NameNode
 Erasure Coding

もくじ
 HDFSの復習
 Erasure Coding

HDFS: アーキテクチャー
5
NameNode
DataNode
File
metadata
Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止
Client

6
NameNode
DataNode
b1
b2
b3
128MB
128MB
metadata
Client

7
NameNode
DataNode
b1
b2
b3
128MB
128MB
metadatab1を保存したいです
d1, d3, d5に保存してください
d1 d2 d3 d4 d5 d6
Client

8
b1 b1 b1
NameNode
DataNode
b1
b2
b3
128MB
128MB
metadata
Block Report
Client

9
b1
b3
b2 b1 b1b2
b2
b3
b3
NameNode
DataNode
b1
b2
b3
128MB
128MB
metadata
Block Report
Client

HDFS: NameNodeのメタデータ
10
b1
b3
b2 b1 b1b2
b2
b3
b3
NameNode
DataNode
b1
b2
b3
128MB
128MB
metadata
NameSpace
Block Map
File -> BlockID BlockID -> DN
Client

HDFS: NameNodeのメタデータ
11
b1
b3
b2 b1 b1b2
b2
b3
b3
NameNode
DataNode
b1
b2
b3
128MB
128MB
metadata
NameSpace
Block Map
EditLog
persist
Client

HDFSのすごいところ
 強い一貫性
– 1台のマスターが全てのメタデータをメモリ上で管理しているので、
あるユーザーが行なったオペレーションが他のユーザーから見ても
瞬時に反映される
 スケーラビリティ
– 1000台ぐらい（数十PB）までならコモディティなサーバーを追加す
るだけで線形にスケールする

HDFSのスケーラビリティの限界
 数千台の大規模なクラスタやワークロードの重いク
ラスタではスケーラビリティの限界に達してさまざ
まな問題が生じる！

b1
b3
b2 b1 b1b2
b2
b3
b3
NameNode
metadata
NameSpace
Block Map
b1
b2
b3
128MB
128MB
Client
DataNode

b1
b3
b2 b1 b1b2
b2
b3
b3
NameNode
metadata
NameSpace
Block Map
b1
b2
b3
128MB
128MB
Client
①メタデータの肥大化
DataNode

b1
b3
b2 b1 b1b2
b2
b3
b3
NameNode
metadata
NameSpace
Block Map
b1
b2
b3
128MB
128MB
Client
②リクエスト量の増大
DataNode

b1
b3
b2 b1 b1b2
b2
b3
b3
NameNode
metadata
NameSpace
Block Map
b1
b2
b3
128MB
128MB
Client
③レプリケーションのストレージコストが高い
DataNode

新機能でスケーラビリティ向上！
b1
b3
b2 b1 b1b2
b2
b3
b3
NameNode
metadata
NameSpace
Block Map
b1
b2
b3
128MB
128MB
Client
→ Router-based Federation
→ Observer NameNode
③レプリケーションのストレージコストが高い → Erasure Coding
DataNode

もくじ
 HDFSの復習
 Erasure Coding

問題: メタデータの肥大化
 数千台のクラスタではメタデータがNameNodeのメモリ
サイズの限界に達する
 それ以上のデータを保存する場合は別のNameNodeが必
要なので複数のクラスタができる
 複数のクラスタはユーザーにとって扱いづらい
ユーザーから見て１つの大きなクラスタとして扱えるよう
にして欲しい

Router-based Federation（RBF）とは
Federation Layer
Cluster A
Router
DNDN DN
NN
State Store
Cluster B
Router
DNDN DN
NN
 クライアントのリクエストを
ルーティングするフェデレー
ション層を導入
– Router（プロキシサーバー）
– StateStore（マウント情報管理）
 クライアントからNameNode
が隠蔽されて複数のクラスタを
１つの大きなクラスタのように
扱うことができる
BA
/
/ad /log
/ /

RBFの処理の流れ
Federation Layer
Cluster A
Router
DNDN DN
NN
State Store
Cluster B
Router
DNDN DN
NN
(1)
(2)
(3)
(5)
hadoop fs -get /log/data/file .
(1) クライアントはRouterにリクエストを
送信
(2) RouterはStateStoreに保存されている
マウントテーブルを参照
(3) 適切なNameNodeにルーティングする
(4) NameNodeはRouterを経由しながら
クライアントにレスポンスを返信
(5) クライアントはレスポンスの情報を元
に目的のDataNodeにアクセス
(4)
BA
/
/ad /log
/ /

RBFの開発状況
 開発企業
– Microsoft, Uber, VipShop, Huawei, LinkedIn, Cloudera,
Yahoo! JAPAN...
 現在はセキュリティ機能を開発中（HDFS-13532）
– UberやMicrosoftが中心
– ケルベロス認証のベースの実装が完了
– デリゲーショントークンに対応
– Hadoop-3.3.0に入りそう

もくじ
 HDFSの復習
– Consistent Reads from Standby Node
 Erasure Coding

NameNode HAのアーキテクチャ
Active NN Standby NN
Journal nodes
① Read/Write
metadata metadata
EditLog
② Write EditLog ③ Read EditLog

metadatametadatametadata
複数NameNodeの機能（HDFS-6440）
Active NN
Standby NNs
Journal nodes
① Read/Write
metadata
EditLog
② Write EditLog
③ Read EditLog

問題: Active NameNodeの責任が重い
Active NN
Standby NNs
Journal nodes
① Read/Write
metadata
EditLog
② Write EditLog
③ Read EditLog

Observer NameNodeの登場
Active NN
Standby
Journal nodes
① Read/Write
metadata
EditLog
② Write EditLog
③ Read EditLog
ObserverObserver
Read
Read処理はObserver
NameNodeから可能！！
Read

READリクエストの分散
 READリクエストの分散は効果的である
– 一般的なユースケースではREAD/WRITEのリクエストのうち
約9割がREADリクエスト
 ObserverからのREADを優先する機能
– Hadoopクライアントの機能（ObserverReadProxyProvider）
– ObserverからREADできなかったらActiveからREADする

Observer NameNodeの状態遷移
Active Standby
Observer
Active-Observer間は直接遷移できない

Stale Read 問題
Journal nodes
① write x
② Write EditLog
metadata metadata
EditLog
③ read x
-> doesn’t exist!
stale!
Active NN Observer NN

Stale Read 問題の解決: state IDの導入
Journal nodes
metadata metadata
EditLog

Journal nodes
metadata metadata
EditLog

Journal nodes
metadata metadata
EditLog
transaction ID
② Write EditLog

Journal nodes
metadata metadata
EditLog
transaction ID
② Write EditLog
state ID
transaction ID
④transaction IDからstate IDを作成

Journal nodes
metadata metadata
EditLog
transaction ID
② Write EditLog
state ID
transaction ID

Journal nodes
metadata metadata
EditLog
transaction ID
② Write EditLog
state ID
transaction ID
⑥state IDに含まれたtransaction IDの
EditLogを読み込んでから処理を行う
transaction ID

transaction ID
Journal nodes
metadata metadata
EditLog
state ID
transaction ID
⑥state IDに含まれたtransaction IDの
EditLogを読み込んでから処理を行う
② Write EditLog transaction ID
シングルクライアントに関しては
Read-After-Write一貫性を保つ！

開発状況
 開発企業: LinkedIn, Uber, PayPal, Cloudera...
 マスターブランチにマージ完了！(2018/12/24)
– Hadoop-3.3.0でリリースされる
– Hadoop2系にもバックポートされそう（HDFS-14204）

もくじ
 HDFSの復習
 Erasure Coding

問題: ストレージコストが高い
 通常の3レプリケーションでは冗長性を保つために
元データの3倍のストレージコストがかかる
b1
b3
b2 b1 b1b2
b2
b3
b3
DataNode

 ６個のデータブロックから３個のパリティブロックを生成
 ９個のブロックうち任意の６個ブロックから元データを復元可能
 レプリケーションの半分のストレージコストで同等の冗長性を実現！
Erasure Coding（EC）とは
b1 b3 b4 b6 b7 b8b2 b5 b9
Replication Erasure Coding (6, 3)
損失の許容できるブロック数 2 3
元データに対するストレージコスト 3倍 1.5倍
encode

データ量が多いほど顕著な差が出る
レプリケーション EC 元データ
ストレージコスト
データ量

ECブロックの実装の詳細
1MB
1MB
b1 b2 b3 b4 b5 b6 b7 b8 b9

ECブロックの実装の詳細
b1 b2 b3 b4 b5 b6 b7 b8 b9

開発状況など
 開発自体はだいぶ前に完了
– 新機能の開発はしばらく無し
– 細かい改善・バグ修正が行われている
 利用できるのはHadoop3系から
– ユーザーが増えるのはこれから
 解説記事（拙著）
– HDFS Erasure Codingの紹介とYahoo! JAPANにおける運用事例
https://techblog.yahoo.co.jp/infrastructure/hdfs_erasure_coding

番外編: Ozone
 Hadoopのオブジェクトストア
 HDFSのアーキテクチャを刷新
 マスターのメタデータ肥大化問題を根本的に解決

HDFSの新機能のリリースプラン
Router-based
Federation
Erasure Coding
RBF with Security
Observer NameNode
Ozone
trunk
~ 3.2.0 (2019/01) 3.3.0

HDFSのスケーラビリティの限界を突破するためのさまざまな取り組み | Hadoop / Spark Conference Japan 2019 #hcj2019

More Related Content

What's hot

Similar to HDFSのスケーラビリティの限界を突破するためのさまざまな取り組み | Hadoop / Spark Conference Japan 2019 #hcj2019

More from Yahoo!デベロッパーネットワーク

HDFSのスケーラビリティの限界を突破するためのさまざまな取り組み | Hadoop / Spark Conference Japan 2019 #hcj2019