MapR アーキテクチャ概要 - MapR CTO Meetup 2013/11/12
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

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

  • 4,081 views
Uploaded on

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

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

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
4,081
On Slideshare
3,979
From Embeds
102
Number of Embeds
2

Actions

Shares
Downloads
77
Comments
1
Likes
22

Embeds 102

https://twitter.com 101
http://s.deeeki.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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