MapR Technologies CTO の M.C. Srivas による、MapR アーキテクチャ概要。2013年11月12日に開催された MapR CTO Meetup での説明資料です。

1. 1
アーキテクチャ概要
M.
C.
Srivas,
CTO/Co-­‐founder

2. 2
バックグラウンド
§ サーチ
–
Map-­‐Reduce,
Bigtable
§ チーフアーキテクト
–
現 Netapp
§ AFS
–
AFS
チームリード
–
現

3. 3
‘09
‘11
07
06
MapReduce
論文を発表
MR
論文もとに
Hadoop
を開発
Hadoop
を
利用開始
Hadoop
を
利用開始
Hadoop
を
利用開始
NYダウが
14,300
から
6,800
に急落
MapR
設立
‘13
‘12
高信頼性Hadoopを発表
とのパートナー
数々の世界
記録を更新
MapR
の歴史
2500
ノード
の最大の
商用クラスタ
MapR
M7
世界最速NoSQL

4. 4
MapR
DistribuCon
for
Apache
Hadoop
分析
オペレーション
OLTP
Management
バッチ
インタラクティブ
リアルタイム
Data Platform
NoSQL
Hardening, Testing, Integrating,
Innovating, Contributing as part of
the
Apache Open Source Community
Web 2.0ツール 企業アプリケーション 業務アプリケーション
99.999%
高可用性
データ保護
ディザスタ
リカバリ
エンタープライ
ズ連携
スケーラビリ
ティ & 性能
マルチテナント

5. 5
§ 100%
Apache
Hadoop
§ 大幅なエンタープライズ
グレードの機能強化
§ 包括的な管理
§ 業界標準の
インターフェース
§ 高いパフォーマンス
MapR
DistribuCon
for
Apache
Hadoop

6. 6
クラウドリーダーは
MapR
を選択
Google
は
MapR
を選択し、
Google
Compute
Engine
で
Hadoop
を提供
Amazon
EMR
は売上、
クラスタ数の点で最大の
Hadoop
プロバイダ
OpenStack
環境を提供する
Canonical
および
MiranNs
とのパートナーシップ

7. 7
MapR
の信頼性が高い理由は?

8. 8
1. ストレージの信頼性を高める
– ディスクおよびノード障害からの復旧
2. サービスの信頼性を高める
– サービスは状態のチェックポイント処理を頻繁に行う必要がある
– サービスの再起動（異なるノードでの再起動もあり得る）
– 上記(1)とともにチェックポイントの状態を再起動したサービスに適用
3. 高速に行う
– 瞬時に起動
…
(1)
および
(2)
が非常に速く実行される必要がある
– メンテナンスウィンドウなしで行う
• コンパクションをなくす
(例:
Cassandra,
Apache
HBase)
• 定期的にクラスタをきれいにする「AnN-­‐entropy」処理をなくす
(例:
Cassandra)
どのようにクラスタの信頼性を高めるか

9. 9
§ NVRAM
なし
§ 特別な接続がない場合がある
– 「オンライン」用とレプリカ用に別のデータパスがあるわけではない
§ ノードあたり2つ以上のドライブがない場合がある
– RAID
構成は不可能
§ レプリケーションを使えるが…
– 他のノードが同じドライブ容量を持っているとは限らない
– 1つめのノードのドライブ容量が他のノードの容量の10倍だったら?
§ 信頼性のためにはレプリケーションをするしかない
コモディティハードウェアの信頼性

10. 10
レプリケーションは簡単ですね?
同じ内容をマスターとレプリカに送る必要がある
レプリケーションによる信頼性
クライアント
プライマリ
サーバ
レプリカ
一般的なレプリケーション
プライマリが転送
クライアント
プライマリ
サーバ
レプリカ
Cassandra型のレプリケーション

11. 11
レプリカが復旧したとき内容は古くなっている
– 最新の内容に更新しなければならない
– それまでは障害状態のまま
障害が発生…
クライアント
プライマリ
サーバ
管理者により「AnN-­‐entropy」
プロセスが起動するまでは
レプリカは古いまま
プライマリがレプリカを再同期
クライアント
プライマリ
サーバ
レプリカ
レプリカ
誰が
再同期?

12. 12
§ HDFS
は第3の方法で問題を解決
§ すべてを
Read-­‐only
に
– 静的なデータ、再同期は容易
§ 単一の Writer、書き込み中の
Read
はない
§ ファイルクローズは
Reader
がデータを見ることができるよう
にするためのトランザクション
– クローズされていないファイルは失われる
– クローズされたファイルにはそれ以上
Write
できない
HDFS
では…

13. 13
§ 単一の
Writer、書き込み中の
Read
はない
§ ファイルクローズは
Reader
がデータを見ることができるよう
にするためのトランザクション
– クローズされていないファイルは失われる
– クローズしたファイルにはそれ以上書き込めない
§ リアルタイム処理は
HDFS
では不可能
– データにアクセスするためには、Write
直後にファイルをクローズする
必要がある
– HDFS
では多数のファイルを扱う場合に深刻な問題となる
(よく知られている制限)
§ このため HDFS
は
NFS
に対応できない
– NFS
には「クローズ」 がない…
どの時点でもデータ損失の可能性
HDFS
のデザインゴール

14. 14
§ 完全な Read/Write
および「Update-­‐in-­‐place」サポート
§ 課題:
レプリカ復旧時の再同期
一般アプリをサポートするには
RW
が必要
クライアント
プライマリ
サーバ
管理者により「AnN-­‐entropy」
プロセスが起動するまでは
レプリカは古いまま
プライマリがレプリカを再同期
クライアント
プライマリ
サーバ
レプリカ
レプリカ
誰が
再同期?

15. 15
§ 24
TB
/
台
–
@
1000MB/秒
=
7
時間
–
現実には、
@
200MB/秒
=
35
時間
§ オンラインで処理したい場合は?
– 再同期レートは
1/10
に絞られる
– 再同期に 350
時間
(=
15
日)
§ 平均データ損失時間
(Mean
Time
To
Data
Loss,
MTTDL)
は?
– 二重障害までの時間は?
– 三重ディスク障害は?
再同期にかかる時間は?

16. 16
問題回避のため
デュアルポートディ
スクを利用
従来のソリューション
クライアント
プライマリ
サーバ
レプリカ
デュアル
ポートディス
クアレイ
Raid-­‐6
+
スペアディスク
サーバは
NVRAM
を利用
コモディティハードウェア
ラージスケールクラスタ
大規模な購入契約、5年間の保守プラン

17. 17
パフォーマンスもあきらめてしまうのか?
SAN/NAS
data
data
data
data
data
data
daa
data
data
data
data
data
funcCon
RDBMS
従来のアーキテクチャ
data
funcCon
data
funcCon
data
funcCon
data
funcCon
data
funcCon
data
funcCon
data
funcCon
data
funcCon
data
funcCon
data
funcCon
data
funcCon
data
funcCon
Hadoop
funcCon
App
funcCon
App
funcCon
App
地理的にも分散?

18. 18
§ 各ノードのデータを数千の破片に分割
– 破片は コンテナ と呼ばれる
§ 各コンテナのレプリカをクラスタ全体に分散
MapR
のしくみ

19. 19
なぜ
MapR
でよくなるのか?

20. 20
§ 100
ノードクラスタ
§ 各ノードは全ノードの1/100ずつのデータを保持
§ サーバが停止した時、クラスタ全体が停止ノードのデータを再同
期
MapR
レプリケーションの例

21. 21
§ 99
ノードが並列で再同期
– 99
倍のドライブ数
– 99
倍の
Ethernet
ポート
§ 各ノードは
1/100
のデータを再
同期
MapR
の再同期のスピード
§ 全体的な速度は約
100
倍
– 3.5
時間
vs.
350
時間
§ MTTDL
は 100
倍改善

22. 22
§ Mean
Time
To
Data
Loss
(MTTDL)
is
far
beeer
– Improves
as
cluster
size
increases
§ Does
not
require
idle
spare
drives
– Rest
of
cluster
has
sufficient
spare
capacity
to
absorb
one
node’s
data
– On
a
100-­‐node
cluster,
1
node’s
data
==
1%
of
cluster
capacity
§ UNlizes
all
resources
–
no
wasted
“master-­‐slave”
nodes
–
no
wasted
idle
spare
drives
…
all
spindles
put
to
use
§ Beeer
reliability
with
less
resources
– on
commodity
hardware!
MapR
Reliability

23. 23
なぜこれが難しいのか?

24. 24
§ 同期 Write
– 直後に反映される
§ データは「Chain」型に
レプリケーション
– ネットワーク帯域を最大限利用
§ メタデータは「Star」型に
レプリケーション
– より良いレスポンス時間
MapR
の
Read-­‐write
レプリケーション
client1
client2
clientN
client1
client2
clientN

25. 25
コンテナのバランシング
l As
data
size
increases,
writes
spread
more
(like
dropping
a
pebble
in
a
pond)
l Larger
pebbles
spread
the
ripples
farther
l Space
balanced
by
moving
idle
containers
• Servers
keep
a
bunch
of
containers
"ready
to
go”
• Writes
get
distributed
around
the
cluster

26. 26
MapR
コンテナの再同期
§ MapR
は
100%
ランダムWrite
– 分散トランザクションを利用
§ 完全にクラッシュした時、
すべてのレプリカは互いに
分岐してしまう
§ 復旧時はどれがマスターに
なるべきか?
完全に
クラッシュ

27. 27
MapR
コンテナの再同期
§ MapR
はレプリカがどこで分岐し
たかを正確に検出可能
– 2000
MB/s
の更新レートであっても
§ 再同期で行われること
– 分岐ポイントへのロールバック
– 選択したマスターに合わせロール
フォワード
§ オンラインの状態で行われる
–
通常処理に与える影響は非常に小
さい
クラッシュ後
の新マスター

28. 28
§ Re-­‐sync
traffic
is
“secondary”
§ Each
node
conNnuously
measures
RTT
to
all
its
peers
§ More
throele
to
slower
peers
– Idle
system
runs
at
full
speed
§ All
automaNcally
MapR
Does
AutomaCc
Re-­‐sync
ThroSling

29. 29
コンテナはどこに適合するのか?

30. 30
l 各コンテナは次を含む
l ディレクトリ&ファイル
l データブロック
l サーバ間でレプリケー
ション
l 自動で管理される
MapR
コンテナ
ファイル/ディレクトリは分割されコンテナに格
納される
コンテナは16-­‐32
GB
のディスクを割
り当てられノードに
置かれる

31. 31
MapR
アーキテクチャのパラメータ
§ I/O
の単位
– 4K/8K
(MapR
では 8K)
§ チャンク
(Map-­‐reduce
の split)
の単位
– 10-­‐数100
MB
§ 再同期（レプリカ）の単位
– 10-­‐数100
GB
– MapR
ではコンテナ
– 自動で管理
KB
I/O
10^3
Map-­‐red
10^6
再同期
10^9
管理
HDFS
「ブロック」
§ 管理の単位
(スナップショット、
ミラー、クォータ、バックアップ)
– 1
GB-­‐
数1000
TB
– MapR
ではボリューム
– あるブロックが失われた時に影響
するデータは?

32. 32
MapR
はどこでどのようにこの
独自の優位点を活用しているか?

33. 33
E
F
E
F
E
F
NameNode
NameNode
NameNode
MapRのNo
NameNode
HATM
アーキテクチャ
HDFS
FederaNon
MapR
(分散メタデータ)
•
複数の単一障害点
•
5,000万-­‐2億ファイルが上限
•
性能ボトルネック
•
商用
NAS
が必要
•
自動フォールオーバーによる HA
•
迅速なクラスタ再起動
•
1兆ファイル以上に対応
(5,000倍以上)
•
10-­‐20倍の性能
•
100%コモディティハードウェア
NAS
appliance
NameNode
NameNode
NameNode
A
B
C
D
E
F
DataNode
DataNode
DataNode
DataNode
DataNode
DataNode
A
F
C
D
E
D
B
C
E
B
C
F
B
F
A
B
A
D
E

34. 34
性能およびスケーラビリティの比較
0
2000
4000
6000
8000
10000
12000
14000
16000
18000
0
1000
2000
3000
4000
5000
6000
ファイル生成回数/秒
ファイル数
(百万)
0
100
200
400
600
800
1000
MapR
他ディストリビューション
ベンチマーク:
100バイトのファイル
ハードウェア:
10
ノード
2
x
4
コア
24
GB
RAM
12
x
1
TB
7200
RPM
1
GigE
NIC
0
50
100
150
200
250
300
350
400
0
0.5
1
1.5
ファイル生成回数/秒
ファイル数
(百万)
他ディストリビューション
MapR
その他
性能比
レート(回数/秒)
1.4-­‐1.6万
335-­‐360
40倍
規模(File数)
60億
130万
4615倍

35. 35
MapR
はどこでどのようにこの
独自の優位点を活用しているか?

36. 36
MapR
の
NFS
による直接の書き込み
コネクタは不要
既存アプリケーションとスムーズに連携
ランダムRead/Write
圧縮
分散HA
Web
サーバ
…
Database
サーバ
Application
サーバ

37. 37
MapR
はどこでどのようにこの
独自の優位点を活用しているか?

38. 38
MapR
ボリューム
&
スナップショット
100K
volumes
are
OK,
create
as
many
as
desired!
ボリュームによりデータ管理が大幅に
シンプルに
• レプリケーションのコントロール
• ミラーリング
• スナップショット
• データ配置のコントロール
• 強力なセキュリティ
• 認証/暗号化
(heps
のような)
• Kerberos
v5
10万のボリュームも
問題なし。作りたい
だけ作ることが可能
/projects
/tahoe
/yosemite
/user
/msmith
/bjohnson

39. 39
MapR
はどこでどのようにこの
独自の優位点を活用しているか?

40. 40
MapR
M7
Table
§ Apache
HBase
とバイナリ互換
– M7
Table
へのアクセスには再コンパイルは必要なし
– CLASSPATH
を設定するだけ
§ M7
Table
はパス名でアクセス
– openTable(
“hello”)
…
HBase
を使用
– openTable(
“/hello”)
…
M7
を使用
– openTable(
“/user/srivas/hello”)
…
M7
を使用

41. 41
§ M7
Table
はストレージに統合されている
– 全ノードでいつでも利用可能
§ Table
数は無制限
§ コンパクションなし
– データは随時更新
§ 瞬時に起動
– 復旧時間はゼロ
§ 5-­‐10
倍の性能
§ 一貫した低レイテンシ
– 95%
および
99%
M7
Table
MapR
M7

42. 42
YCSB
50-­‐50
Mix
(スループット)
M7
(ops/sec)
Other
HBase
0.94.9
(ops/sec)
Other
HBase
0.94.9
latency
(usec)
M7
Latency
(usec)

43. 43
YCSB
50-­‐50
mix
(レイテンシ)
Other
latency
(usec)
M7
Latency
(usec)

44. 44
MapR
M7によるHBaseアプリケーションの高速化
ベンチマーク
MapR
3.0.1
(M7)
CDH
4.3.0
(HBase)
MapR
性能比
50%
read,
50%
update
8000
1695
5.5倍
95%
read,
5%
update
3716
602
6倍
Reads
5520
764
7.2倍
スキャン
(50
行)
1080
156
6.9倍
CPU:
2
x
Intel
Xeon
CPU
E5645
2.40GHz
12
コア
RAM:
48GB
ディスク:
12
x
3TB
(7200
RPM)
レコードサイズ:
1KB
データサイズ:
2TB
OS:
CentOS
Release
6.2
(Final)
メンチマーク
MapR
3.0.1
(M7)
CDH
4.3.0
(HBase)
MapR
性能比
50%
read,
50%
update
21328
2547
8.4倍
95%
read,
5%
update
13455
2660
5倍
Reads
18206
1605
11.3倍
スキャン
(50
行)
1298
116
11.2倍
CPU:
2
x
Intel
Xeon
CPU
E5620
2.40GHz
8
コア
RAM:
24GB
ディスク:
1
x
1.2TB
Fusion
I/O
ioDrive2
レコードサイズ:
1KB
データサイズ:
600GB
OS:
CentOS
Release
6.3
(Final)
HDD
使用時の MapR
の性能:
5-­‐7
倍
SSD
使用時の MapR
の性能:
5-­‐11.3
倍

45. 45
MapR
はどこでどのようにこの
独自の優位点を活用しているか?

46. 46
§ すべての Hadoop
コンポーネントは高可用性を持つ
– e.g.
YARN
§ ApplicaNonMaster
(旧
JT)
および TaskTracker
は状態を
MapR
に記録
§ ノード障害時、AM
は
MapR
から状態を回復
– クラスタ全体が再起動した時でも機能する
§ すべてのジョブは停止したところから再開可能
– MapR
のみがサポート
§ プリエンプションを可能に
– MapR
はジョブの進捗を失うことなくプリエンプション（切り替え）が可能
– MapR
の ExpressLane
機能がプリエンプションを活用
MapR
は
Hadoop
を真の
HA
に

47. 47
MapR
は（高速に） MapReduce
を実行
TeraSort
記録
1
TB
を 54
秒
1003
ノード
MinuteSort
記録
1.5
TB
を
59
秒
2103
ノード

48. 48
MapR
は（より高速に） MapReduce
を実行
TeraSort
記録
1
TB
を 54
秒
1003
ノード
MinuteSort
記録
1.5
TB
を
59
秒
2103
ノード
1.65
300

49. 49
ユーザーはどこでどのようにこの
独自の優位点を活用できるか?

50. 50
MapR
の独自の優位点を活用するには
§ すべてのユーザーコードは簡単にScale-­‐out
HAに
– MapR
にサービス状態を保存
– MapR
データを保存
§ サービス障害の通知には Zookeeper
を利用
§ どこからでも再開、データ＋状態は自動的に移動
§ MapR
の実装は実際に上記を行っている
§ MapR
のみが
HA
をサポート:
HA
for
Impala,
Hive,
Oozie,
Storm,
MySQL,
SOLR/Lucene,
HCatalog,
Kava,
…

51. 51
MapR:
アンリミテッド Hadoop
高信頼処理
高信頼ストレージ
クラスタを1台ずつ構築
l 価格性能比の高いコモディティハードウェアを利用
l エンタープライズクラスの信頼性:
迅速な再起動、ス
ナップショット、ミラーリング、単一障害点の除去、…
l NFS,
ODBC,
Hadoop
およびその他の標準プロトコル経
由でアクセスを提供

52. 52
どうもありがとうございます!
srivas@maprtech.com
www.mapr.com