Oracle Cloud InfrastructureでのHadoopのデプロイに関する考慮事項

Hadoopを実行するカスタマの多くは、クラウドへの移行を検索するときに類似の質問を持っています。

• Hadoopをクラウドにデプロイまたは移行する方法
• クラウドのHadoopの保護方法
• クラウドでHadoop用のHAおよびDRはどのように実装しますか。
• クラウド内のHadoopデプロイメントとオンプレミスとの比較で同様のパフォーマンスを実現するにはどうすればよいですか。
• 複数の環境のデプロイ時にコストを追跡および管理するにはどうすればよいですか。

この記事では、Oracle Cloud Infrastructureからこれらの質問に対する回答を示します。

デプロイメント

Oracleのインフラストラクチャにサービス(IaaS)としてサブスクライブすると、それに関連付けられているすべての計算、記憶域およびネットワーク・サービスにアクセスできます。Oracle Cloud Infrastructure上のデプロイメントはオンプレミス・デプロイメントとまったく同じですが、これは同じバージョンおよび機能が各Hadoopディストリビューションで使用できることです。

TeraformおよびResource Manager

Oracle Cloud Infrastructureエンジニアリング・チームは各Hadoop ISVと共同で、Terraformを利用するデプロイメントを可能にしています。Terraformでは、インフラストラクチャをコード(IaC)としてデプロイでき、これには、ネットワーク(仮想クラウド・ネットワーク、サブネット、vnic)およびセキュリティ・アクセス制御リストから、Hadoopエコシステムのすべての側面が含まれ、計算およびストレージ・プロビジョニングが含まれます。Terraformは、柔軟性が高くスケーラブルで、多くのクラウド・プロバイダ間の標準に対応しています。

これらのテンプレートをOracle Cloud InfrastructureにHadoopをデプロイするためのフレームワークとして使用するか、オンプレミスで使用した既存のデプロイメント・ツールのままにしておくかを選択できます。どちらの方法も有効です。

Terraformを使用してHadoopをデプロイする場合は、Oracle Resource Managerの使用を検討してください。リソース・マネージャを使用する主な利点について考慮します。

• Terraform状態メタデータは、可用性の高い場所に保持されます。
• リソース・マネージャへのアクセスは、他のOracle Cloud Infrastructureサービスに含まれているものと同じセキュリティおよび監査ツールで管理できます。
• リソース・マネージャでは、Oracle Cloud InfrastructureにデプロイするためのTerraformの構成に関連する複雑さが排除されています。

リソース・マネージャ・インタフェースでは、スタック変数に対して予想される値が移入されたYamlベースのスキーマ・ファイルがサポートされます。これにより、スタック内の各変数に対して許可される形状、ソフトウェア・バージョンおよびその他のパラメータを定義できます。

図resource - manager-ui.pngの説明

スキーマ・ファイルの移入後、値は使いやすいUIで表示されます。スキーマ・ファイルには、これらの値を持つドロップダウン・リストと、ユーザーが入力を入力したりペーストできるカスタム入力フィールドがあります。

スキーマ・ファイルのフィールドにも依存性があるため、あるフィールドでユーザーが値を選択すると、他のフィールドもその選択に基づいて表示または非表示になります。

クラスタ・サービスのトポロジ

Hadoopをデプロイする際は、クラスタ・サービス・トポロジとノード・ロールとの次のようなマッピングを検討してください。

ノード・タイプ	Hadoopロール	Hadoopサービス
エッジ	周期性からユーザー・アクセス	クライアント・ライブラリ, Oozie
ユーティリティ	クラスタ管理	Cloudera Manager、Ambari、Metadataデータベース
マスター	コアクラスタ・サービス	Zookeeper、NameNode、JournalNode、HIVE、HBase Master、Spark History、Job History、Resource Manager、HTTPFS、SOLR
就業者	ワークロードの実行、データ・ストレージ	HDFS、NodeManager、Region Server、Kafka Broker、Spark Executor、マップ/削減

これらのロールに使用するコンピュート・シェイプを選択する際は、このソリューションで後述します。また、次の基準も考慮してください。

• クラスタを使用する同時ユーザー数はどのくらいですか。

  エッジ・ノードは、同時ユーザー数に基づいて数量とOCPUの両方でスケール変更する必要があります。OCPUごとに2つの同時ユーザーには優れたガイドラインがあり、ユーザーごとに1つのスレッドを実現できます。また、障害ドメイン間で追加のエッジ・ノードでも冗長性が提供されます。

• 具体的なSparkまたはHBaseリージョン・サーバー・メモリー要件はありますか。

  このような要件は、就業者ノードの数量と構成に直接影響を与えます。HBaseのサイズを変更するには、基礎となるアプリケーションの理解が必要で、そのサイズも異なります。ほとんどのお客様は、HBaseデプロイメントの要件、つまりサーバーごとに割り当てられたリージョン・サーバー数およびメモリー数をすでに認識しています。Sparkのワークロードも同様に集計メモリー・ターゲットを持ち、ワーカー・ノードの数とワーカー当たりの使用可能メモリーを掛けて算出します。

• 特定のHDFS容量要件はありますか。

  ほとんどの顧客にこの要件があります。ただし、多数のベア・メタルDenseIO就業者ノードに幅広くなる前に、このソリューションの後半で説明するように、NVMeでバックアップされたHDFSをブロック・ボリュームで拡張して必要なHDFS密度を実現できることを検討してください。Oracleでは、HDFS要件を理解することをお薦めしますが、コストを最小限に抑えながら両方のターゲットにヒットするようにクラスタを適切なサイズにするために、ワークロード要件を考慮に入れます。

移行

Hadoopを実行しているカスタマがOracle Cloud Infrastructureへのデプロイを決定した場合、通常は大量のデータが移行されます。このデータの大部分はHDFSに存在し、これをサポートするクラスタ・メタデータがデータベースに存在します。

HDFSデータをインターネットに直接コピーすると、いくつかの理由でチャレンジされます。

• データ量が大きすぎるか、使用可能な帯域幅が制約されすぎて、有意義な時間枠でデータ・コピーを伝送できません。
• データは機密性が高く、インターネット上でコピーすると、ガバナンスや規制の要件によって許可されない場合があります。
• オンプレミス・クラスタ・リソースは制約され、データ・コピーは進行中のワークロードに影響を与えます。

データ移行にはいくつかのアプローチがサポートされています。これらは、移行されるデータのタイプによって定義されます。

HDFSデータの移行

HDFSデータをOracle Cloud Infrastructureにコピーするには、次の3つの共通の方法があります。

• インターネットまたはFastConnectとのVPNを使用して、オンプレミスのクラスタからOracle Cloud Infrastructureリージョンのオブジェクト・ストレージにデータを直接コピーします。このプロセスが完了すると、オブジェクト・ストレージからのデータでOracle Cloud Infrastructureクラスタをリハイドレーションできます。
• データをインターネット経由で、またはFastConnectを使用して、オンプレミス・クラスタからOracle Cloud Infrastructureクラスタに直接コピーします。
• データをデータ転送アプライアンスにコピーします。これは顧客データ・センターにデプロイされ、データが入力された後、Oracleに送信されてオブジェクト・ストレージにアップロードされます。その後、このデータを使用してOracle Cloud Infrastructureクラスタをリハイドレーションできます。

これらの各メソッドに関する技術的な詳細については、このソリューションで後述します。

Metadataの移行

クラスタ・メタデータは、通常はHDFSデータよりも大幅に小さく、オンプレミス・クラスタのデータベースに存在します。

クラスタ・メタデータの移行は、ソース・クラスタ内のHadoopディストリビューションと、メタデータの格納に使用されるデータベースの2つの要素によって決まります。このデータの転送は簡単であり、Hadoopの各ディストリビューションに固有です。

各Hadoopディストリビューションに関する詳細は、このソリューションの後の部分で説明します。

セキュリティ

クラウドのセキュリティは特にHadoopで重要であり、Oracle Cloud Infrastructureにデプロイしても安全であることを保証する方法は多数あります。

まず、Oracle Cloud Infrastructure固有の一部のセキュリティ制御を考えてみます。

• Identity and Access Management (IAM)を利用して、クラウド・リソースへのアクセス権を持つユーザー、ユーザーのグループが持つアクセス・タイプおよび特定のリソースへのアクセス権を制御します。このアーキテクチャにより、次のような結果が得られます。
  • 組織構造に基づいてクラウド・リソースを安全に分離
  • ブラウザ・インタフェース、REST API、SDKまたはCLIを介してクラウド・サービスにアクセスするユーザーを認証します
  • ユーザーのグループの認可による適切なクラウド・リソースへのアクションの実行
  • 既存のアイデンティティ・プロバイダとフェデレーション
  • 管理対象のサービス・プロバイダ(MSP)またはシステム・インテグレータ(SI)によるインフラストラクチャ・アセットの管理を可能にしながら、オペレータがリソースにアクセスできるようにします
  • クラウド・サービスに対してAPIコールを実行するためのアプリケーション・インスタンスの認可
• 仮想クラウド・ネットワーク(VCN)内のすべてのネットワークの監査セキュリティ・リスト。これらのルールは可能に応じて制限し、信頼性のあるトラフィックのみをインターネットに接続するサブネットに許可します。
• インターネットに接続するホストでホストのファイアウォールを有効にし、必要なトラフィックのみを許可します。
• セキュリティ監査は定期的に使用することを検討してください。

また、暗号化は、残りのデータとモーションのデータの両方に適したオプションです。次のリソースについて考えてみます。

• Cloudera暗号化メカニズム
• Hortonworks
  • HDFS暗号化(残り)
  • ワイヤ暗号化
• MapR暗号化

Hadoop固有のその他のセキュリティに関する考慮事項には、次のものがあります。

• プライベートIPアドレスを持つサブネット上にクラスタをデプロイすると、必要なapiまたはuiのみが内部向けサブネットに公開されます。
• クラスタ・セキュリティを使用してHadoopを実行します。
• エッジ・ノードを使用して、SSHトンネリングによりクラスタ・サービスにアクセスします。これはMacまたはLinux上でも簡単です。
• Apache Knoxを活用してAPIエンドポイントを保護します。
• クラスタ・データおよびメタデータに対するロールベースのアクセスのために、Apache SentryまたはCloudera Navigatorを利用します。

ネットワーク・セキュリティ

Hadoopおよびセキュリティに関する考慮事項はオープンな性質を持つため、ほとんどのお客様は、プライベート・サブネット内にHadoopクラスタをデプロイすることをお薦めします。クラスタ・サービスへのアクセスは、エッジ・ノードを使用するか、Ui、apiおよびサービス・ダッシュボードへのロード・バランシング・アクセスを使用するか、エッジ・プロキシを介したFastConnect VPNまたはSSHトンネリングを介したアクセスのみが可能になります。

パブリック・サブネットは、内部向けサービス(Cloudera ManagerやAmbariなど)を実行するエッジ・ノードおよびユーティリティ・ノードのクラスタ・デプロイメントを拡張します。これは完全にオプションです。FastConnect VPNを活用し、オンプレミス・ネットワーク・トポロジの拡張としてデプロイメント全体を実行するように選択できます。そのため、VCNレベルで関連付けられ、Oracle Cloud Infrastructureの適切なサブネットに分割される、ユーザーがルーティング可能なプライベートIPセグメントのみが必要です。アクセスは、サブネット・レベルで適用されるセキュリティ・リストを使用して制御されます。ベスト・プラクティスは、同様のアクセス要件を持つリソースを同じサブネットにグループ化することです。

サブネット・トポロジ

VCNは、任意の単一の連続したIPv4 CIDRブロックをカバーします。VCN内で、クラスタ・ホストに個別のIPv4サブネットをデプロイできます。各サブネットへのアクセスは、セキュリティ・リストによって制御されます。追加のセキュリティは、ファイアウォールによってホスト・レベルで制御されます。

ベスト・プラクティスは、Hadoopクラスタのリソースを、インターネットから直接アクセスできないプライベート・サブネットに分離することです。クラスタへのアクセスは、パブリック・ネットワーク・セグメントとプライベート・ネットワーク・セグメント間のトラフィックを制御する適切なセキュリティ・リスト・ルールを使用して、パブリック・クラスタの追加ホストを介して制御する必要があります。このモデルは、Hadoopクラスタに最適なセキュリティを提供します。

• パブリック・サブネットは、エッジ・ノード(ユーザー・アクセス)および外部アクセス用のUIまたはAPI (Cloudera ManagerやAmbariなど)を公開する必要があるすべてのサービスに使用できます。
• プライベート・サブネットはクラスタ・ホスト(マスター、ワーカー)に使用する必要があり、インターネットから直接アクセスすることはできません。かわりに、これらには、アクセス用のパブリック・サブネット、ロード・バランサ、あるいはVPN、FastConnectまたはSSHプロキシによる直接アクセスが必要です。

セキュリティ・リスト

セキュリティ・リストは、サブネット・レベルでエグレストラフィックおよびエグレス・トラフィックを制御します。Hadoopの場合、TCPとUDPの両方のトラフィックに対して、クラスタ・ホストを持つサブネット間で、無制限の完全な双方向アクセスを持つのが最適です。パブリック・サブネットは、信頼できるポート(およびソースIPアドレス)のみがapiおよびuiにアクセスできるように、より制限の高いセキュリティ・リストを持つ必要があります。

高可用性

Hadoopには高可用性(HA)の組込みメソッドがありますが、それらはここでは説明しません。HAを実現するためにOracle Cloud Infrastructure for Hadoopを活用する上でのベスト・プラクティスについて次に説明します。

リージョン選択

Oracle Cloud Infrastructureの各リージョンは、1から3つの可用性ドメインで構成されます。各可用性ドメインは3つのフォルト・ドメインでも構成されています。自分に近い地域とビジネス・リソース(データ・センターなど)を選択します。選択したリージョンの構成によって、単一可用性ドメイン・デプロイメントか複数可用性ドメインのデプロイメントかが決定されます。

単一可用性ドメインのデプロイメント

Oracleでは、Oracle Cloud InfrastructureでHadoopデプロイメントを行う、単一可用性ドメインのデプロイメントをお薦めします。MapRデプロイメントの場合、このアーキテクチャはサポートされているアーキテクチャは1つのみです。クラスタ内トラフィックは、待機時間が短く、高いスループットを維持するローカル・ネットワーク・セグメントに含まれるため、このデプロイメント・モデルは、ネットワークの観点から最もパフォーマンスが高いことです。可用性ドメイン内のリソースは、物理インフラストラクチャのHAを実現するために、フォルト・ドメイン間でストライプ化されます。

フォルト・ドメインは、可用性ドメイン内のハードウェアおよびインフラストラクチャをグループ化したものです。各可用性ドメインには3つのフォルト・ドメインがあります。フォルト・ドメインを使用すると、インスタンスを1つの可用性ドメイン内の同じ物理ハードウェア上に配置しないようにインスタンスを分散できます。あるフォルト・ドメインに影響するハードウェア障害またはハードウェアの計算のメンテナンスは、他のフォルト・ドメインのインスタンスには影響しません。

複数の使用可能なドメインのデプロイメント

複数使用可能なドメインのデプロイメント(可用性ドメイン・スパン)はClouderaとHortonworksによってのみサポートされますが、Apache Hadoopを使用することもできます。

ただし、ドメインの可用性範囲に関する次の注意事項を検討してください。

• クラスタ内接続は、WANセグメントを横断する必要があり、待機時間が増加し、最適なスループットが低下します。これは、パフォーマンス、特にベアメタル就業者ノードに測定可能な影響を与えます。より小さなVM就業者ノードの場合、パフォーマンスへの影響は顕著になります。
• すべてのOracle Cloud Infrastructureリージョンがこのモデルをサポートするわけではありません。

次の図は、単一の可用性ドメインで10 TBのTeraSortを使用している場合に、5就業者ノードと3つのマスター・ノードで構成されるクラスタの可用性ドメインとでは、パフォーマンスに与える影響を測定したものです。

図comparisoison-ability-domain - spanning.pngの説明

可用性ドメインの範囲は、クラスタ・サービスの追加の冗長性を1つのリージョンに提供します。クラスタ・リソースは、各可用性ドメインで追加の論理的なラックのトポロジとして機能することもできます。ラックの認識のために、各フォルト・ドメインは「ラック」と見なされます。これらの利点について、次の図で説明します。

図アーキテクト例例例例:マルチパート- available - domain s.pngの説明

障害時リカバリ

Oracle Cloud Infrastructureの障害回復(DR)は、リカバリ・ポイント目標(RPO)およびリカバリ時間目標(RTO)の要件に直接依存しています。

RPOまたはRTOのいずれかがリアルタイムに近い場合、Hadoopの唯一のオプションは、別の可用性ドメインまたはリージョンにDRクラスタを作成してから、本番クラスタとDRクラスタの間でデータをレプリケートすることです。RPOおよびRTO要件の方が柔軟性が高い場合は、オブジェクト・ストレージをHDFSおよびクラスタ・メタデータのバックアップ・ターゲットとして利用することをお薦めします。DistCp (分散コピー)などのツールを使用して、RPOターゲットを満たすのに必要な頻度でコピー・プロセスをスケジュールし、データをオブジェクト・ストレージにプッシュします。データベース(Oracle、MySQL)をオブジェクト・ストレージ・バケットにバックアップしたり、他の可用性ドメインまたはリージョンにある追加のデータベース・インスタンスにレプリケートすることもできます。

1つのリージョンで提供できないデータに対してDR要件で地理的冗長性が指定されている場合は、領域間のオブジェクト・ストレージにデータをコピーすることもできます。障害が発生した場合は、Terraformを使用して、別の可用性ドメイン(同じリージョンまたは異なるリージョン内)でリソースを迅速にプロビジョニングし、Object StorageのデータからDRクラスタをリハイドレートすることを検討します。

Cost Management

このソリューションの残りの部分を詳しく説明するとともに、インフラストラクチャのコストを削減するために計算と記憶域の要件を右サイズにする方法がいくつかあります。Oracle Cloud Infrastructureには、Hadoopデプロイメントに関連するコストの管理に役立つ追加のツールがあります。

• デプロイメントに対するタグ付けを利用すると、消費をより簡単に追跡できます。
• 区分レベルで割当て制限を設定し、異なるラインのビジネスによる消費を制限できます。本番、QAおよび開発環境を管理するために複数の区分の使用を検討し、適切に割当て制限します。

クラウドの動的な性質を活用することは、永続的である必要がない環境にも大きな特徴です。データのバックアップ(またはデータ・レイク)としてObject Storageを使用している場合、Terraformを使用したリハイドレートHDFSをObject Storageからのデータで使用して環境を容易に作成し、不要になった場合は環境を破棄します。

ブロック・ボリュームのあるVM環境は、コンピュート請求を停止するためにも一時停止でき、ストレージ使用量にのみチャージされます。