オンプレミスの Apache Hadoop クラスターの Azure HDInsight への移行

この記事では、Azure HDInsight システムのデータ ストレージのための推奨事項について説明します。 これは、オンプレミスの Apache Hadoop システムを Azure HDInsight に移行する際に役立つベスト プラクティスを紹介するシリーズの一部です。

HDInsight クラスターのための適切なストレージ システムを選択する

オンプレミスの Apache Hadoop ファイル システム (HDFS) のディレクトリ構造は、Azure Blob Storage または Azure Data Lake Storage 内に再作成できます。 計算に使用される HDInsight クラスターを安全に削除できます。このとき、ユーザー データは失われません。 どちらのサービスも、HDInsight クラスターの既定のファイル システムと追加のファイル システムの両方として使用できます。 HDInsight クラスターとストレージ アカウントは、同じリージョンに置く必要があります。

Azure Storage

HDInsight クラスターは Azure Storage 内の blob コンテナーを既定のファイル システムまたは別のファイル システムのいずれかとして使用できます。 Standard レベルのストレージ アカウントは HDInsight クラスターで使用するようにサポートされています。 Premier レベルはサポートされていません。 既定の BLOB コンテナーには、ジョブ履歴やログなどのクラスター固有の情報が格納されます。 1 つの BLOB コンテナーを複数のクラスターの既定のファイル システムとして共有することはサポートされていません。

作成プロセスで定義されたストレージ アカウントとそのそれぞれのキーは、クラスター ノードの %HADOOP_HOME%/conf/core-site.xml に格納されます。 これらは Ambari UI の HDFS の構成で「Custom core site (カスタム コア サイト)」セクションからもアクセスできます。 ストレージ アカウント キーは既定で暗号化されており、カスタムの復号スクリプトを使用してキーを復号化してから Hadoop デーモンに渡されます。 Hive、MapReduce、Hadoop ストリーミング、Pig などを含むジョブを利用して、ストレージ アカウントの説明とそのメタデータを伝達できます。

Azure Storage は、geo レプリケーションすることが可能です。 geo レプリケーションにより、災害発生時には別の拠点でデータを回復でき、データの冗長性が高まりますが、geo レプリケーションした別拠点へのフェールオーバーはパフォーマンスに大きな影響を与え、追加コストが発生する可能性もあります。 geo レプリケーションを利用するときは、追加コストがかかっても保護する価値のあるデータかどうかを十分に考慮してください。

次の形式の 1 つを使用して、Azure Storage に格納されているデータにアクセスできます。

データ アクセス形式	説明
wasb:///	暗号化されていない通信を使用して既定のストレージにアクセスします。
wasbs:///	暗号化された通信を使用して既定のストレージにアクセスします。
wasb://<container-name>@<account-name>.blob.core.windows.net/	既定以外のストレージ アカウントを使用して通信するときに使用します。

Standard ストレージ アカウントのスケーラビリティ ターゲットに関する記事には、Azure Storage アカウントの現在の制限が記載されています。 アプリケーションで必要とされるスケーラビリティが、単一ストレージ アカウントあたりのスケーラビリティ ターゲットを超えている場合、複数のストレージ アカウントを使用し、それらのストレージ アカウント間でデータが分割されるようにアプリケーションを構築できます。

Azure Storage Analytics はすべてのストレージ サービスのためのメトリックを提供し、Azure portal はメトリックを収集してグラフで視覚化するように構成できます。 ストレージ リソース メトリックのしきい値に達したときに通知するアラートを作成できます。

Azure Storage では、BLOB オブジェクトの論理的な削除が提供されており、アプリケーションまたは他のストレージ アカウント ユーザーによって誤って変更または削除された場合に、データを復旧できます。

blob スナップショットを作成することができます。 スナップショットは、ある時点で作成された読み取り専用の BLOB で、BLOB をバックアップする手段を提供します。 作成されたスナップショットは、読み取り、コピー、削除はできますが、変更はできません。

Note

「wasbs」証明書がない以前のバージョンのオンプレミスの Hadoop ディストリビューションでは、証明書を Java トラストストアにインポートする必要があります。

以下の方法を使用して、証明書を Java トラストストアにインポートできます。

Azure Blob の TLS/SSL 証明書をファイルにダウンロードします

echo -n | openssl s_client -connect <storage-account>.blob.core.windows.net:443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > Azure_Storage.cer

上記のファイルをすべてのノードの Java トラストストアにインポートします

keytool -import -trustcacerts -keystore /path/to/jre/lib/security/cacerts -storepass changeit -noprompt -alias blobtrust -file Azure_Storage.cer

追加された証明書がトラストストアにあることを確認します

keytool -list -v -keystore /path/to/jre/lib/security/cacerts

詳細については、次の記事を参照してください。

• Azure HDInsight クラスターで Azure Storage を使用する
• Standard ストレージ アカウントのスケーラビリティ ターゲット
• Blob ストレージのスケーラビリティおよびパフォーマンス ターゲット
• Microsoft Azure Storage のパフォーマンスとスケーラビリティに対するチェック リスト
• Microsoft Azure Storage の監視、診断、およびトラブルシューティング
• Azure Portal でのストレージ アカウントの監視

Azure Data Lake Storage Gen2

Azure Data Lake Storage Gen2 は、最新のストレージ製品です。 これによって、Azure Blob Storage に直接統合された Hadoop 互換ファイル システム エンドポイントに、Azure Data Lake Storage Gen1 の第 1 世代からのコア機能が統合されます。 この機能強化は、通常はオンプレミスのファイル システムにのみ関連付けされている信頼性とパフォーマンスに、オブジェクト ストレージのスケールとコスト上のメリットを結合したものです。

Azure Data Lake Storage Gen 2 は、Azure Blob Storage に基づいて構築され、ファイル システムとオブジェクト ストレージの両方のパラダイムを使用して、データと連携させることができます。 ファイル システム セマンティクス、ファイル レベルのセキュリティおよびスケールなど、Azure Data Lake Storage Gen1 に由来する機能は、Azure Blob ストレージの低コストの階層型記憶域、高可用性/ディザスター リカバリー機能、および SDK/ツール エコシステムと組み合わされています。 Data Lake Storage Gen2 では、すべてのオブジェクト ストレージの品質を備えたまま、分析ワークロード用に最適化されたファイル システム インターフェイスの利点が追加されています。

Data Lake Storage Gen2 の基本的な機能は、パフォーマンスの高いデータ アクセスのために、オブジェクト/ファイルをディレクトリの階層に編成した Blob ストレージ サービスに、階層構造の名前空間を追加することです。 階層構造により、ディレクトリの名前変更や削除などの操作は、ディレクトリ名のプレフィックスを共有するすべてのオブジェクトを列挙して処理するのではなく、ディレクトリ上の単一のアトミック メタデータの操作になります。

以前は、パフォーマンス、管理、およびセキュリティの領域では、クラウドベース分析は妥協する必要がありました。 Azure Data Lake Storage (ADLS) Gen2 の主要機能は次のとおりです。

• Hadoop と互換性のあるアクセス:Azure Data Lake Storage Gen2 では、Hadoop 分散ファイル システム (HDFS) を利用する場合と同様に、データの管理およびアクセスを可能にします。 新しい ABFS ドライバーは、Azure HDInsight 内に含まれているすべての Apache Hadoop 環境内で使用できます。 このドライバーにより、Data Lake Storage Gen2 に格納されているデータにアクセスできます。

• POSIX アクセス許可のスーパーセット:Data Lake Gen2 のセキュリティ モデルは、ACL および POSIX のアクセス許可に加え、Data Lake Storage Gen2 固有の追加設定を完全サポートしています。 設定は、管理ツールを通じて構成することもできますし、Hive や Spark などのフレームワークを通じて構成することもできます。

• コスト効率:Data Lake Storage Gen2 は、低コストのストレージ容量とトランザクションを備えています。 ライフサイクル全体を通してデータが移行されるにつれて、Azure Blob ストレージ ライフサイクルなどの組み込み機能を使用してコストを最小限に抑えるために課金レートが変化します。

• BLOB ストレージ ツール、フレームワーク、およびアプリの操作:Data Lake Storage Gen2 では、BLOB ストレージ用に今日存在するさまざまなツール、フレームワーク、およびアプリケーションを継続的に利用できます。

• 最適化されたドライバー:Azure Blob ファイル システム ドライバー (ABFS) は、ビッグ データ分析用に特別に最適化されています。 対応する REST API は、dfs エンドポイントである dfs.core.windows.net を通して公開されます。

次の形式の 1 つを使用して、ADLS Gen2 に格納されているデータにアクセスできます。

• abfs:///:クラスターの既定の Data Lake Storage にアクセスします。
• abfs://file_system@account_name.dfs.core.windows.net:既定以外の Data Lake Storage と通信するときに使用します。

注意

Azure Data Lake Storage Gen2 機能を備えた実行中のクラスターのプライマリまたはセカンダリ ストレージ アカウントのアップグレードはサポートされていません。 既存の HDInsight クラスターのストレージの種類を Data Lake Storage Gen2 に変更するには、クラスターを再作成し、階層型名前空間が有効なストレージ アカウントを選択する必要があります。

詳細については、次の記事を参照してください。

• Azure Data Lake Storage Gen2 の概要
• Azure BLOB ファイル システム ドライバー (ABFS.md)
• Azure HDInsight クラスターで Azure Data Lake Storage Gen2 を使用する

オンプレミスの Hadoop クラスター構成内の Azure Storage キーをセキュリティ保護する

Hadoop 構成ファイルに追加された Azure Storage キーは、オンプレミスの HDFS と Azure Blob Storage 間に接続を確立します。 これらのキーは、Hadoop の資格情報プロバイダー フレームワークを使用して暗号化することで保護できます。 暗号化されると、それらを安全に格納してアクセスできます。

資格情報をプロビジョニングするには:

hadoop credential create fs.azure.account.key.account.blob.core.windows.net -value <storage key> -provider jceks://hdfs@headnode.xx.internal.cloudapp.net/path/to/jceks/file

上記のプロバイダー パスを core-site.xml またはカスタムのコアサイトの下の Ambari 構成に追加するには:

<property>
    <name>hadoop.security.credential.provider.path</name>
        <value>
        jceks://hdfs@headnode.xx.internal.cloudapp.net/path/to/jceks
        </value>
    <description>Path to interrogate for protected credentials.</description>
</property>

Note

プロバイダー パス プロパティは、core-site.xml のクラスター レベルでキーを格納する代わりに、次のように distcp コマンド ラインに追加することもできます。

hadoop distcp -D hadoop.security.credential.provider.path=jceks://hdfs@headnode.xx.internal.cloudapp.net/path/to/jceks /user/user1/ wasb:<//yourcontainer@youraccount.blob.core.windows.net/>user1

SAS を使用して Azure Storage データ アクセスを制限する

HDInsight には、既定の状態で、クラスターに関連付けられた Azure Storage アカウントのデータへのフル アクセス権があります。 blob コンテナーの Shared Access Signatures (SAS) を使用して、データへの読み取り専用アクセスをユーザーに提供するなど、データへのアクセスを制限できます。

Python で作成された SAS トークンを使用する

1. SASToken.py ファイルを開き、次の値を変更します。

   トークンのプロパティ	説明
   policy_name	作成する保存済みのポリシーに使用する名前。
   storage_account_name	ご利用のストレージ アカウントの名前。
   storage_account_key	ストレージ アカウントのキー。
   storage_container_name	アクセスを制限するストレージ アカウントのコンテナー。
   example_file_path	コンテナーにアップロードされるファイルのパス。

2. SASToken.py ファイルには、ContainerPermissions.READ + ContainerPermissions.LIST のアクセス許可が付いており、ユース ケースに基づいて調整できます。

3. スクリプトを次のように実行します: python SASToken.py

4. スクリプトが完了すると、次のテキストのような SAS トークンが表示されます。sr=c&si=policyname&sig=dOAi8CXuz5Fm15EjRUu5dHlOzYNtcK3Afp1xqxniEps%3D&sv=2014-02-14

5. Shared Access Signature によるコンテナーへのアクセスを制限するために、Ambari HDFS Configs Advanced Custom core-site Add プロパティの下のクラスターのコアサイト構成にカスタム エントリを追加します。

6. [キー] と [値] フィールドに、次の値を使用します。

   [キー]: fs.azure.sas.YOURCONTAINER.YOURACCOUNT.blob.core.windows.net[値]: 上記の手順 4 で Python アプリケーションから返された SAS キー。

7. [追加] ボタンをクリックしてこのキーと値を保存し、 [保存] ボタンをクリックして構成の変更を保存します。 プロンプトが表示されたら、変更の説明 (「SAS ストレージ アクセスの追加」など) を追加し、 [保存] をクリックします。

8. Ambari Web UI で、左側の一覧から [HDFS] を選択して、右側の [サービス アクション] ドロップダウン リストから [すべて再起動] を選択します。 メッセージが表示されたら、 [Confirm Restart All](すべての再起動の確認) を選択します。

9. この手順を MapReduce2 と YARN に対して繰り返します。

Azure での SAS トークンの使用に関して、3 つの重要なことを覚えておく必要があります。

1. 「READ + LIST」アクセス許可を持つ SAS トークンが作成されると、その SAS トークンを使用して Blob コンテナーにアクセスするユーザーは、データを「書き込みおよび削除」できません。 その SAS トークンを使用して Blob コンテナーにアクセスし、書き込みまたは削除の操作を試行すると、"This request is not authorized to perform this operation" のようなメッセージが表示されます。

2. SAS トークンが、READ + LIST + WRITE のアクセス許可で生成された場合 (DELETE のみ制限する)、hadoop fs -put のようなコマンドは、最初に \_COPYING\_ ファイルに記述し、後でファイルの名前を変更しようとします。 この HDFS 操作は、WASB の copy+delete にマップします。 DELETE アクセス許可が提供されなかったため、「プット」は失敗します。 \_COPYING\_ 操作は、いくつかの同時実行制御を提供する Hadoop です。 現在、「書き込み」操作に影響を与えずに、「削除」操作だけを制限する方法はありません。

3. 残念ながら、Hadoop の資格情報プロバイダーおよび復号化キー プロバイダー (ShellDecryptionKeyProvider) は現在、SAS トークンと一緒に動作しないため、現時点では可視性から保護できません。

「Azure Storage の Shared Access Signature を使用して HDInsight でのデータへのアクセスを制限する」をご覧ください。

データの暗号化およびレプリケーションを使用する

Azure Storage に書き込まれるすべてのデータは、Storage Service Encryption (SSE) を使用して自動的に暗号化されます。 Azure Storage アカウント内のデータは、高可用性のため常にレプリケートされます。 ストレージ アカウントを作成するときは、次のレプリケーション オプションのいずれかを選択できます。

• ローカル冗長ストレージ (LRS)
• ゾーン冗長ストレージ (ZRS)
• geo 冗長ストレージ (GRS)
• 読み取りアクセス geo 冗長ストレージ (RA-GRS)

Azure Storage によってローカル冗長ストレージ (LRS) が提供されますが、ディザスター リカバリー プランのニーズに合った頻度で、別のリージョン内の別の Azure Storage アカウントに重要なデータをコピーする必要もあります。 ADLCopy、DistCp、Azure PowerShell、Azure Data Factory など、データをコピーするさまざまな方法があります。 また、誤って削除されないように、Azure Storage アカウントのアクセス ポリシーを適用することもお勧めします。

詳細については、次の記事を参照してください。

• Azure Storage のレプリケーション
• Azure Data Lake Storage Gen1 (ADLS) 向けのディザスター ガイダンス

クラスターに Azure Storage アカウントを追加する

HDInsight の作成プロセス時に、既定のファイル システムとして Azure Storage アカウント、Azure Data Lake Storage Gen1、または Azure Data Lake Storage Gen2 が選択されます。 クラスター作成プロセス時またはクラスターが作成された後に、この既定のストレージ アカウントに加えて、同じ Azure サブスクリプションか、別の Azure サブスクリプションからストレージ アカウントをさらに追加することもできます。

次のいずれかの方法でストレージ アカウントを追加できます。

• Ambari HDFS Config Advanced Custom core-site Add the storage Account Name を指定し、サービスの再起動を指定します
• ストレージ アカウントの名前とキーを渡してスクリプト アクションを使用する

Note

有効なユース ケースでは、Azure サポートへの要求を使用して Azure ストレージの制限を増やすことができます。

詳細については、「HDInsight にストレージ アカウントを追加する」を参照してください。

次のステップ

このシリーズの次の記事をお読みください。オンプレミスから Azure HDInsight Hadoop への移行のためのデータ移行のベスト プラクティス。