MapR アーキテクチャ概要 - MapR CTO Meetup 2013/11/12

1

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

2

バックグラウンド

§ サーチ –  Map-‐Reduce, Bigtable

§ チーフアーキテクト –  現 Netapp

§ AFS –  AFS チームリード –  現

3

‘09 ‘11 07 06

MapReduce 論文を発表

MR 論文もとに Hadoop を開発

Hadoop を利用開始



NYダウが14,300 から 6,800 に急落

MapR 設立

‘13 ‘12

高信頼性Hadoopを発表

とのパートナー

数々の世界記録を更新

MapR の歴史

2500 ノードの大の商用クラスタ

MapR M7 世界速NoSQL

4

MapR DistribuCon for Apache Hadoop

分析オペレーション OLTP

Man

agem

ent

バッチインタラクティブリアルタイム

Data Platform NoSQL

Hardening, Testing, Integrating, Innovating, Contributing as part of

the Apache Open Source Community

Web 2.0 ツール企業アプリケーション業務アプリケーション

99.999% 高可用性データ保護ディザスタ

リカバリエンタープライ

ズ連携スケーラビリティ & 性能マルチテナント

5

§  100% Apache Hadoop

§  大幅なエンタープライズグレードの機能強化

§  包括的な管理

§  業界標準のインターフェース

§  高いパフォーマンス

MapR DistribuCon for Apache Hadoop

6

クラウドリーダーは MapR を選択

Google は MapR を選択し、 Google Compute Engine で

Hadoop を提供

Amazon EMR は売上、クラスタ数の点で大の

Hadoop プロバイダ

OpenStack 環境を提供する Canonical および MiranNs とのパートナーシップ

7

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

8

1.  ストレージの信頼性を高める – ディスクおよびノード障害からの復旧

2.  サービスの信頼性を高める – サービスは状態のチェックポイント処理を頻繁に行う必要がある – サービスの再起動（異なるノードでの再起動もあり得る） – 上記(1)とともにチェックポイントの状態を再起動したサービスに適用

3.  高速に行う – 瞬時に起動 … (1) および (2) が非常に速く実行される必要がある – メンテナンスウィンドウなしで行う

•  コンパクションをなくす (例: Cassandra, Apache HBase) •  定期的にクラスタをきれいにする「AnN-‐entropy」処理をなくす (例: Cassandra)

どのようにクラスタの信頼性を高めるか

9

§  NVRAM なし §  特別な接続がない場合がある

–  「オンライン」用とレプリカ用に別のデータパスがあるわけではない

§  ノードあたり2つ以上のドライブがない場合がある –  RAID 構成は不可能

§  レプリケーションを使えるが… – 他のノードが同じドライブ容量を持っているとは限らない –  1つめのノードのドライブ容量が他のノードの容量の10倍だったら?

§  信頼性のためにはレプリケーションをするしかない

コモディティハードウェアの信頼性

10

レプリケーションは簡単ですね? 同じ内容をマスターとレプリカに送る必要がある

レプリケーションによる信頼性

クライアント

プライマリサーバレプリカ

一般的なレプリケーションプライマリが転送

クライアント


Cassandra型のレプリケーション

11

レプリカが復旧したとき内容は古くなっている –  新の内容に更新しなければならない – それまでは障害状態のまま

障害が発生…

クライアント

プライマリサーバ

管理者により「AnN-‐entropy」プロセスが起動するまでは

レプリカは古いまま

プライマリがレプリカを再同期

クライアント

プライマリサーバレプリカレプリカ

誰が再同期?

12

§  HDFS は第3の方法で問題を解決 §  すべてを Read-‐only に

– 静的なデータ、再同期は容易

§  単一の Writer、書き込み中の Read はない §  ファイルクローズは Reader がデータを見ることができるよう

にするためのトランザクション – クローズされていないファイルは失われる – クローズされたファイルにはそれ以上 Write できない

HDFS では…

13

§  単一の Writer、書き込み中の Read はない §  ファイルクローズは Reader がデータを見ることができるよう

にするためのトランザクション – クローズされていないファイルは失われる – クローズしたファイルにはそれ以上書き込めない

§  リアルタイム処理は HDFS では不可能 – データにアクセスするためには、Write 直後にファイルをクローズする

必要がある –  HDFS では多数のファイルを扱う場合に深刻な問題となる (よく知られている制限)

§  このため HDFS は NFS に対応できない –  NFS には「クローズ」がない… どの時点でもデータ損失の可能性

HDFS のデザインゴール

14

§  完全な Read/Write および「Update-‐in-‐place」サポート §  課題: レプリカ復旧時の再同期

一般アプリをサポートするには RW が必要

クライアント

プライマリサーバ

管理者により「AnN-‐entropy」プロセスが起動するまでは

レプリカは古いまま

プライマリがレプリカを再同期

クライアント

プライマリサーバレプリカレプリカ

誰が再同期?

15

§  24 TB / 台 –  @ 1000MB/秒 = 7 時間 –  現実には、 @ 200MB/秒 = 35 時間

§  オンラインで処理したい場合は? – 再同期レートは 1/10 に絞られる

– 再同期に 350 時間 (= 15 日)

§  平均データ損失時間 (Mean Time To Data Loss, MTTDL) は? – 二重障害までの時間は? – 三重ディスク障害は?

再同期にかかる時間は?

16

問題回避のためデュアルポートディスクを利用

従来のソリューション

クライアント


デュアルポートディス

クアレイ Raid-‐6 + スペアディスク

サーバは NVRAM を利用

コモディティハードウェアラージスケールクラスタ

大規模な購入契約、5年間の保守プラン

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

§  各ノードのデータを数千の破片に分割 – 破片はコンテナと呼ばれる

§  各コンテナのレプリカをクラスタ全体に分散

MapR のしくみ

19

なぜ MapR でよくなるのか?

20

§  100 ノードクラスタ §  各ノードは全ノードの1/100ずつのデータを保持 §  サーバが停止した時、クラスタ全体が停止ノードのデータを再同

期

MapR レプリケーションの例

21

§  99 ノードが並列で再同期 –  99 倍のドライブ数 –  99 倍の Ethernet ポート

§  各ノードは 1/100 のデータを再同期

MapR の再同期のスピード §  全体的な速度は約 100 倍

–  3.5 時間 vs. 350 時間

§  MTTDL は 100 倍改善

23

なぜこれが難しいのか?

24

§  同期 Write – 直後に反映される

§  データは「Chain」型にレプリケーション – ネットワーク帯域を大限利用

§  メタデータは「Star」型にレプリケーション – より良いレスポンス時間

MapR の Read-‐write レプリケーション

client1 client2

clientN

client1 client2

clientN

26

MapR コンテナの再同期

§ MapR は 100% ランダムWrite – 分散トランザクションを利用

§  完全にクラッシュした時、すべてのレプリカは互いに分岐してしまう

§  復旧時はどれがマスターになるべきか?

完全にクラッシュ

27

MapR コンテナの再同期

§  MapR はレプリカがどこで分岐したかを正確に検出可能 – 2000 MB/s の更新レートであっても

§  再同期で行われること – 分岐ポイントへのロールバック – 選択したマスターに合わせロール

フォワード

§  オンラインの状態で行われる –  通常処理に与える影響は非常に小

さい

クラッシュ後の新マスター

29

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

30

l  各コンテナは次を含む l  ディレクトリ&ファイル l  データブロック

l  サーバ間でレプリケーション

l  自動で管理される

MapR コンテナファイル/ディレクトリは分割されコンテナに格納される

コンテナは16-‐32 GB のディスクを割り当てられノードに

置かれる

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

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

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

性能およびスケーラビリティの比較

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


36

MapR の NFS による直接の書き込みコネクタは不要

既存アプリケーションとスムーズに連携

ランダムRead/Write

圧縮

分散HA

Web サーバ

…

Database サーバ

Application サーバ

37


38

MapR ボリューム & スナップショット

100K volumes are OK, create as many as

desired!

ボリュームによりデータ管理が大幅にシンプルに •  レプリケーションのコントロール •  ミラーリング •  スナップショット •  データ配置のコントロール •  強力なセキュリティ

•  認証/暗号化 (hhps のような) •  Kerberos v5

10万のボリュームも問題なし。作りたいだけ作ることが可能

/projects

/tahoe

/yosemite

/user

/msmith

/bjohnson

39


40

MapR M7 Table

§  Apache HBase とバイナリ互換 – M7 Table へのアクセスには再コンパイルは必要なし –  CLASSPATH を設定するだけ

§ M7 Table はパス名でアクセス –  openTable( “hello”) … HBase を使用 –  openTable( “/hello”) … M7 を使用 –  openTable( “/user/srivas/hello”) … M7 を使用

41

§ M7 Table はストレージに統合されている – 全ノードでいつでも利用可能

§  Table 数は無制限 §  コンパクションなし

– データは随時更新

§  瞬時に起動 – 復旧時間はゼロ

§  5-‐10 倍の性能 §  一貫した低レイテンシ

–  95% および 99%

M7 Table

MapR M7

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

YCSB 50-‐50 mix (レイテンシ)

Other latency (usec) M7 Latency (usec)

45


46

§  すべての Hadoop コンポーネントは高可用性を持つ –  e.g. YARN

§  ApplicaNonMaster (旧 JT) および TaskTracker は状態を MapR に記録

§  ノード障害時、AM は MapR から状態を回復 – クラスタ全体が再起動した時でも機能する

§  すべてのジョブは停止したところから再開可能 – MapR のみがサポート

§  プリエンプションを可能に – MapR はジョブの進捗を失うことなくプリエンプション（切り替え）が可能 – MapR の ExpressLane 機能がプリエンプションを活用

MapR は Hadoop を真の HA に

47

MapR は（高速に） MapReduce を実行

TeraSort 記録 1 TB を 54 秒

1003 ノード

MinuteSort 記録 1.5 TB を 59 秒

2103 ノード

48

MapR は（より高速に） MapReduce を実行

TeraSort 記録 1 TB を 54 秒

1003 ノード

MinuteSort 記録 1.5 TB を 59 秒

2103 ノード 1.65

300

49

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

50

MapR の独自の優位点を活用するには §  すべてのユーザーコードは簡単にScale-‐out HAに

– MapR にサービス状態を保存 – MapR データを保存

§  サービス障害の通知には Zookeeper を利用 §  どこからでも再開、データ＋状態は自動的に移動 § MapR の実装は実際に上記を行っている

§ MapR のみが HA をサポート: HA for Impala, Hive, Oozie, Storm, MySQL, SOLR/Lucene, HCatalog, Kaoa, …

51

MapR: アンリミテッド Hadoop

高信頼処理高信頼ストレージ

クラスタを1台ずつ構築 l  価格性能比の高いコモディティハードウェアを利用 l  エンタープライズクラスの信頼性: 迅速な再起動、ス

ナップショット、ミラーリング、単一障害点の除去、… l  NFS, ODBC, Hadoop およびその他の標準プロトコル経

由でアクセスを提供

52

どうもありがとうございます!

[email protected] www.mapr.com

Technology

MapR アーキテクチャ概要 - MapR CTO Meetup 2013/11/12