1. Oracle Cloud InfrastructureへのHadoopのデプロイについて学ぶ
  2. パフォーマンスとシェイプの考慮事項

パフォーマンスとシェイプの考慮事項

Oracle Cloud InfrastructureでHadoopを実行する場合、重要な価格とパフォーマンスに関する考慮事項があります。また、要件がデプロイメントの形状に与える影響についても考慮する必要があります。

比較分析

Oracle Cloud Infrastructureには、Oracle CloudでHadoopクラスタを実行する場合のエンタープライズのパフォーマンスとコストの両方の点があります。

TeraSortは、Hadoopの一般的なベンチマークです。これは、クラスタのすべての要素(計算、メモリー、記憶域、ネットワーク)を活用して、ランダム化されたデータセットを生成、マップ/削減および検証するためです。

1つの比較分析によって、300 OCPUでOracle Cloud Infrastructureクラスタが正規化され、HDFSストレージ用のブロック・ボリュームが使用されます。この特定の分析では、競合相手のクラウド上のデプロイ可能数よりも、Oracle Cloud Infrastructureの実行時間が3倍高速で、80%未満のコストであることが判明しました。

次のグラフは、正規化されたクラスタ・サイズでこの10 Tb TeraSortを実行している場合の様々なOracle Cloud Infrastructure形状の全体的なパフォーマンスを示しています。


Comparison-terasort-phase-cpu.pngの説明が続きます
図comparison-terasort-phase-cpu.pngの説明

Oracle Cloud Infrastructureでは、IntelおよびAMDのcpuを含む標準のベア・メタル計算インスタンスのみでなく、特殊なHPCオプションも用意されています。グラフに表示されているように、専用のHPCクラスタは、これらのインスタンスのコア数が下がっても、IntelおよびAMDの対応する方より高速に実行されました。この結果は主に、このクラスタが同じ正規化されたOCPUカウントを達成するためにより多くのノードを使用しており、これは全体的なHDFS集計スループットに直接影響し、パフォーマンスを向上させます。

また、HPCシェイプでは、100 - GBネットワーク機能を利用できるため、クラスタ内データの転送が高速になります。

次の図は、VMベースの就業者のパフォーマンスとブロック・ボリューム、ベア・メタルNVMeのパフォーマンスを比較し、Clouderaを実行してクラスタ内の10個の就業者ノードに正規化しています。


Comparison-terasort - vm-bm-performance.pngの説明が続きます
図comparison - terasort - vm-bm-performance.pngの説明

就業者のVMサイズを8から16コアまで2倍にすることはパフォーマンスの向上であり、VMのネットワーク・スループットは基礎となる物理NICの部分共有であるため、逆効果が大きくなります。ローカルのNVMeとベア・メタルのメリットも明らかです。クラスタは、25 Gbpsのネットワーク・インタフェースと組み合わされたローカルNVMe記憶域の高速の利点を活用します。

Hadoopクラスタの計算に使用する形状の決定は、Hadoop isvとの間で一貫性があります。

コンピュート・インスタンスの選択

この項では、各ノード・ロールに対して形状を選択する際のベスト・プラクティスを示します。

マスター・ノード

マスター・ノードはCloudera、HortonworksおよびApache Hadoopディストリビューションにのみ適用できます。デフォルトでは、MapRは就業者ノードからクラスタ・サービスを分離しません。実際には、Oracleでは、クラスタおよびサービス管理のオーバーヘッドをサポートするために、マスター・ノードで優れたメモリー密度を使用することをお薦めします。マスター・ノードでは、Zookeeper、NameNode、JournalNode、Resource Manager、HBase、Sparkおよびcluster management (Cloudera ManagerおよびAmbari)の各サービスが実行されます。

  • 最小シェイプ: VM.Standard2.8
  • 推奨される形式: VM.standard2.24

就業者ノード

就業者ノードは、すべてのHadoop isvとApache間で一貫性があります。ワークロード要件を満たすために、就業者ノードの形状を適切にスケール変更します。これは計算要件とメモリー要件の両方に適用されます。これは、多くの顧客がSparkベースのワークロードで使用する集計メモリーを検索しているためです。従来のマップ/削減ワークロードの利点として、就業者ノードのメモリー・フットプリントが増加します。

  • 最小シェイプ: VM.Standard2.8
  • 推奨形状: BM.DenseIO2.52

サポート・ノード

サポート・インフラストラクチャには、補助的なクラスタ・サービスまたはカスタム・アプリケーション・コードを実行している可能性があるエッジ・ノードまたはその他のノードが含まれます。これらのノードの要件は、スケールおよびユースケースに応じて異なります。エッジ・ノードの場合、最小サイズのVM.Standard2.2をお薦めします。エッジ・ノード当たりのユーザー数に応じてこれをスケール・アップします。障害ドメイン間HA用と、ユーザーがクラスタと対話するための複数の方法を作成するために、複数のエッジ・ノードを推奨します。

ネットワークに関する考慮点

Hadoopは、クラスタ内トラフィックのネットワークに大きく依存します。そのため、クラスタ・トポロジの各ロールに対してデプロイするように選択した形状は、クラスタ内接続に直接影響を及ぼします。

ベア・メタル形状を使用する場合、計算ホストではフル25 GB仮想ネットワーク・インタフェース・カード(vnic)を使用できます。VM形状は計算サイズに対して相対的にスケールされます。

HDFS容量にブロック・ボリュームを使用する場合は、ブロック・ボリュームに対するI/Oトラフィックが、アプリケーション・トラフィックと同じVNICを共有する(デフォルト)ことに注意してください。ベア・メタル形状を使用する場合にこれを最適化する方法の1つとして、クラスタ接続に使用するセカンダリVNICを、2番目の物理インタフェースで作成する方法があります。これはブロック・ボリュームのトラフィックのみのためにプライマリVNICを予約するため、ネットワーク使用率を最適化します。

次の図に、この概念を示します。


Architecture-vnic.pngの説明が続きます
図architecture-vnic.pngの説明

ブロック・ボリュームを使用する場合は、各ワーカーのノードに関連付けられているブロック・ボリュームの量およびサイズにHDFS I/Oを直接集約することも検討してください。必要なHDFS容量を実現するために、Oracleは、少数の大きなボリュームではなく、就業者ごとの多数のボリュームのスケーリングをお薦めします。

ストレージの考慮事項

Hadoopデプロイメントの場合、ローカルNVMeを持つDenseIO形状およびブロック・ボリュームという2つのタイプのストレージをHDFS容量に使用できます。MapRデプロイメントの場合、データ層のライセンスを持っていないかぎり、単一のストレージ・タイプを就業者ノード(同種)に対して選択する必要があります。その他のHadoop isvでは、追加のライセンス・コストなしで、異種ストレージ(DenseIO NVMeとブロック・ボリュームを組み合せて)をサポートしています。

ベンダーがサポートするストレージ構成

ClouderaおよびHortonworksは、Hadoopで使用するために、Oracle Cloud Infrastructure上のあらゆる形式のストレージをサポートしています。

  • DenseIO形状上のローカルNVMe
  • ブロック・ボリューム
  • オブジェクト・ストレージ(S3互換性の使用)

Clouderaはデータ階層化(異種ストレージ)をサポートしており、ローカルNVMeとHDFS用のブロック・ボリュームで構成されるデプロイメントです。

MapRデプロイメントでは、DenseIO図形にローカルNVMeを活用することも、デプロイメント用にボリュームをブロックすることもできます。

  • オブジェクト・ストレージ: MapR XDオブジェクト階層化を参照してください。
  • MapRでは、追加ライセンスなしで異種ストレージをサポートしていません。
Oracle Cloud Infrastructureのすべてのストレージ・フォームは、HDFSコネクタを利用するオブジェクト・ストレージを含め、Apache Hadoopで使用できます。

DenseIO NVMe

DenseIO NVMeは、Oracle Cloud InfrastructureのHadoopで最もパフォーマンスが高いストレージ・オプションです。HDFSで使用するための高速ローカルNVMeドライブは、ベア・メタルと仮想マシンの両方の形状で使用できます。

ローカルのNVMeを使用する場合、Oracleでは、データの冗長性を保証するために3つのレプリカにDFSレプリケーションを設定することをお薦めします。

または、Clouderaクラスタについては、必ず消去コーディングを使用して特定タイプのデータに対するストレージの効率を高めることを検討してください。

ブロック・ボリューム

Oracle Cloud Infrastructure上のブロック・ボリュームは優れたパフォーマンス・オプションで、HDFS容量の柔軟な構成を提供します。ブロック・ボリュームはネットワーク接続ストレージであるため、I/O用のVNIC帯域幅を使用します。ブロック・ボリュームも、構成されたサイズ(GB当たり)に基づいてIOPSおよびMB/秒単位でスケール変更されます。個別のブロック・ボリュームのスループットは、700Gb以上のボリュームについて320 MB/秒です。

次の表に、700Gbボリュームを使用した1つの就業者ノードのスループットのスケーリングを示します。

ブロック・ボリューム 集計スループット(GB/秒)
3 0.94
4 1.25
5 1.56
6 1.88
7 2.19
8 2.50
9 2.81
10 3.13
11 3.44

Oracleでは11ブロック・ボリューム後に追加のブロック・ボリュームを追加すると、スループットの向上が解消されます。

Vmを就業者として使用する場合、ブロック・ボリューム・トラフィックがHadoop (アプリケーション)トラフィックと同じVNICを共有することに注意してください。次の表に、推奨される最大ブロック・ボリュームと、選択したOracle Cloud Infrastructure形状のVNIC帯域幅を測定し、ディスクI/Oの上部でアプリケーション・トラフィックをサポートするために十分な追加帯域幅を許可します。

Oracle Cloud Infrastructure形状 VNIC帯域幅 HDFSで推奨される最大ブロック・ボリューム
BM.DenseIO2.52 25Gbps 11
BM.Standard2.52 25Gbps 11
VM.Standard2.24 24.6Gbps 6
VM.Standard2.16 16.4Gbps 4
VM.Standard2.8 8.2Gbps 3

HDFS容量にブロック・ボリュームを使用する場合、HDFSターゲット容量を達成するために、就業者ごとに少数の大規模ブロック・ボリュームではなく、多数の小さなブロック・ボリュームを使用することをお薦めします。

HDFS用の700gbブロック・ボリューム・サイズの例として、最低3つの就業者ノードを使用します。


Block - volumes - apacity-chart.pngの説明が続きます
図block - volumeds - apacity-chart.pngの説明

就業者ごとに3つのブロック・ボリュームが最小要件であることに注意してください。Oracleでは、必要なHDFS容量を最適化するためにブロック・ボリュームの量とサイズをスケーリングすることをお薦めします。これは、就業者ごとのブロック・ボリュームが増加するほど、使用可能な全体のHDFS帯域幅が増えていることを知るためです。これは特に、クラスタ内でより多くの集計I/Oを必要とする、大規模で高スループットのワークロードで重要になります。

また、永続クラスタは、増大またはリファクタのために追加のオーバーヘッドを残すことも重要です。

ロギングおよびアプリケーション・データ

HDFSに対してブロック・ボリュームを使用する場合、Hadoopのログおよびアプリケーション・データ(Cloudera Parcels、NameNodeおよびJournalのメタデータ)で使用するためにいくつかのブロック・ボリュームを予約する必要があります。OSボリュームを拡張してこのデータに対応することもできますが、この目的で専用のブロック・ボリュームを使用することをお薦めします。マスター・ノードのインスタンス・タイプを変更する場合はブロック・ボリュームにより移植性が向上し、特定のデータ場所に対してI/Oのパフォーマンスを向上させる場合は柔軟性が向上します。インスタンスへのブロック・ボリュームの追加、RAID配列の作成、および使用するスペア・ボリュームのアタッチメントがある場合は、既存のデータの移行が簡単になります。

HDFSでも同じことが当てはまります。ブロック・ボリュームをさらに追加するオーバーヘッドは、就業者の廃止、大規模なディスクによる再構築、クラスタへの追加、およびHDFSのリバランスより簡単です。どちらの方法も有効です。クラスタ・ワークロードでは、データ・スループットをサポートするためにブロック・ボリュームを完全に補完する必要があるかどうかに問題があります。その場合は、高速なNVMeストレージを使用し、データ階層を使用した異種ストレージ・モデルを使用して、就業者をベア・メタルの稠密なIO形状に切り替えることを検討してください。

オブジェクト・ストレージ

オブジェクト・ストレージの統合は、Apache Hadoopを含むすべてのHadoop isvで可能です。Oracle Cloud Infrastructureには、Apache Hadoopと互換性があるネイティブHDFS Connectorがあります。Hadoop ISV (Cloudera、HortonworksおよびMapR)は、Object Storage統合のために許可された外部エンドポイントをリストし、Object Storageとの統合を正しく動作させるためにS3互換性を使用する必要があります。

注意事項として、S3の互換性はテナンシのホーム・リージョンでのみ機能します。つまり、オブジェクト記憶域との統合では、Hadoopクラスタも同じ(ホーム)リージョンにデプロイする必要があります。

別の注意点として、オブジェクト・ストレージを使用してクラスタに対してデータをプッシュまたは除外する場合、HDFSはキャッシュ・レイヤーとして使用されません。実際、OSファイル・システムは、オブジェクト・ストレージとHDFS間のデータを転送するためにデータがキャッシュされる場所です。大量のデータがクラスタHDFSとオブジェクト・ストレージ間を移動する場合は、このデータ移動をサポートするOSでブロック・ボリューム・キャッシュ・レイヤーを作成することをお薦めします。

次の図は、就業者ノードのデータ層とともにS3データの移動をサポートする典型的なパーティション・ダイアグラムを示しています。


Object - storage - partitioning-throughput.pngの説明が続きます
図object - storae-partitioning-throughput.pngの説明

データ階層化

Apache Hadoop、ClouderaまたはHortonworksを使用して強力なデータ層(heterogenous)ストレージ・モデルを作成する場合は、前述のすべての記憶域オプションを結合できます。データ・ライフサイクル管理を使用して、あるストレージ層から別のストレージ層にデータをプッシュし、HDFSストレージ・コストを最適化することもできます。


Data - lifecycle-tiering.pngの説明が続きます
図data - lifecycle-tiering.pngの説明

コーディングの消去

Hadoop 3.0では、erasureコーディング(EC)がHDFSデプロイメントでサポートされています。ECは、単一のコピーでパリティーセルによって拡張されたデータを格納することによって、ローカルHDFSデータのストレージ要件を削減します。HDFSトポロジは、タグ付けした場所に格納されているすべてのデータに対してこの機能を有効にするECとしてタグ付けできます。これにより、Ec関連のHDFSデータのraw記憶域要件が効率的に削減され、記憶域の効率が向上します。

ECに関する注意事項がいくつかあります。

  • ECを有効にするには、就業者ノードの最小数が必要です。
  • ECタグ付けされたデータの地域が失われました。
  • ECは、頻繁にアクセスされない中規模ファイルに適しています。小さいファイル、および頻繁にアクセスされるファイルでは非効率的です。
  • ECは、従来の(3 x)レプリケーションと同様のデータと比較して、Name Node Metadataに存在するブロック・オブジェクトの数を増やします。
  • ECデータのリカバリには、クラスタからの計算(パリティー再構築)が必要です。このリカバリ時間は、従来の(3 x)レプリケートされたデータよりも長くなります。

パフォーマンスの監視

Oracle Cloud Infrastructure Monitoringサービスでは、メトリックおよびアラーム機能を使用してクラウド・リソースを積極的にモニターできます。パフォーマンスしきい値や容量のしきい値に達した場合に通知するアラームの設定は、Oracle Cloud Infrastructureネイティブ・ツールを使用してインフラストラクチャを管理するための優れた方法です。

参照アーキテクチャ

このトピックでは、各Hadoop ISVの参照資料を提供します。次の参照アーキテクチャおよび部品構成表は、Oracle Cloud Infrastructure上でベンダーがサポートするHadoopのデプロイメントに必要最低限必要なフットプリントを反映します。

オープンソースのプロジェクトとして、Apache Hadoopデプロイメントには、ベンダーが提供する最低限必要なフットプリントがありません。Oracleでは、最小限のApacheデプロイメントの妥当なガイドとしてここに示されている占有デプロイメントを使用することをお薦めします。

Cloudera


Architecture oudera.pngの説明が続きます
図architecture-cloudera.pngの説明

Clouderaを使用したHadoopのデプロイメントの最低要件は次のとおりです。

ロール 数量 推奨されるコンピュート・シェイプ
エッジ 1 VM.Standard2.4
Cloudera Manager 1 VM.Standard2.16
マスター・ノード 2 VM.Standard2.16
就業者ノード 3 BM.DenselO2.52

この最小限のデプロイメントでは、Cloudera Managerノードもマスター・サービスを実行します。

Oracle Cloud InfrastructureにClouderaをデプロイするには独自のライセンスを取得する必要があります。すべてのソフトウェアのサポートはClouderaを介して行われます。

Hortonworks


Architecture-hortonworks.pngの説明が続きます
図architecturehoc - rtonworks.pngの説明

Hortonworksを使用してHadoopをデプロイメントするための最小要件は次のとおりです。

ロール 数量 推奨されるコンピュート・シェイプ
エッジ 1 VM.Standard2.4
オレンジ色 1 VM.Standard2.16
マスター・ノード 2 VM.Standard2.16
就業者ノード 3 BM.DenselO2.52

この最小デプロイメントでは、オレンジ色ノードもマスター・サービスを実行します。

HortonworksをOracle Cloud Infrastructureにデプロイするには、自分のライセンスを所有している必要があります。すべてのソフトウェアサポートはHortonworksを介して行われます。

MapR


Architect - -mapr.pngの説明が続きます
図Architect - -mapr.pngの説明

MapRを使用したHadoopのデプロイメントの最低要件は次のとおりです。

ロール 数量 推奨されるコンピュート・シェイプ
エッジ 1 VM.Standard2.4
データ・ノード 3 BM.DenselO2.52

Oracle Cloud InfrastructureにMapRをデプロイするには、自分のライセンスを取得する必要があります。すべてのソフトウェア・サポートはMapRを使用します。

Terraformのデプロイメント

このソリューションの「コードのダウンロード」セクションに、Hadoop ISVごとにTerraformテンプレートがあります。

ClouderaおよびHortonworksリポジトリには、Oracle Resource Managerに準拠したテンプレートがあります。これらはリソース・マネージャに固有です。ベース(マスター)ブランチには、スタンドアロンのTerraformテンプレートが含まれています。ClouderaおよびHortonworksのリソース・マネージャ・テンプレートにも、各テンプレートのTerraform変数を簡単に移入できるYAMLスキーマが含まれています。これによって、変数に対するドロップダウンUIの選択が提供されます。このUIでは、ユースケースをカスタマイズし、基本的に各テンプレートに許容形状オプションとセキュリティ/構成設定を移入できます。