HDInsight クラスターの容量計画

HDInsight クラスターをデプロイする前に、必要なパフォーマンスとスケールを判定することによって目的のクラスター容量を計画します。 この計画により、使いやすさとコストの両方を最適化できます。 クラスターの容量に関する決定事項の中には、デプロイ後に変更できないものもあります。 パフォーマンス パラメーターが変わった場合は、保存されているデータを失うことなく、クラスターを解体して再作成できます。

容量計画における重要な検討事項は次のとおりです。

• クラスターをどの地理的リージョンにデプロイすればよいか。
• どれくらいのストレージ容量が必要か。
• どのような種類のクラスターをデプロイすればよいか。
• クラスター ノードでは、どのサイズおよび種類の仮想マシン (VM) を使用すればよいか。
• クラスターにはワーカー ノードがいくつ必要か。

Azure リージョンの選択

Azure リージョンによって、クラスターを物理的にプロビジョニングする場所が決まります。 読み取りと書き込みの待機時間を最小限に抑えるには、クラスターをデータの近くに配置する必要があります。

HDInsight は多数の Azure リージョンで利用できます。 最も近いリージョンを確認するには、「リージョン別の利用可能な製品」を参照してください。

ストレージの場所とサイズの選択

既定のストレージの場所

既定のストレージ (Azure ストレージ アカウントまたは Azure Data Lake Storage) は、クラスターと同じ場所に存在する必要があります。 Azure Storage はあらゆる場所で利用できます。 Data Lake Storage は一部のリージョンで利用できます。Data Lake Storage の現在の提供状況を参照してください。

既存のデータの場所

既存のストレージ アカウントまたは Data Lake Storage をクラスターの既定のストレージとして使用する場合は、その同じ場所にクラスターをデプロイする必要があります。

ストレージ サイズ

デプロイされたクラスターで、別の Azure Storage アカウントを接続したり、他の Data Lake Storage にアクセスしたりできます。 すべてのストレージ アカウントがクラスターと同じ場所に存在する必要があります。 Data Lake Storage は別の場所にあってもかまいませんが、その距離が長いと、ある程度の待ち時間が発生する可能性があります。

Azure Storage には何らかの容量制限がありますが、Data Lake Storage はほぼ無制限です。 クラスターは、さまざまなストレージ アカウントの組み合わせにアクセスできます。 一般的な例を次に示します。

• データ量が、1 つの Blob Storage コンテナーのストレージ容量を超える可能性がある場合。
• BLOB コンテナーへのアクセス レートがしきい値を超え、調整が発生する可能性がある場合。
• データを作成する必要があるときに、クラスターで利用できる BLOB コンテナーに既にアップロードしている場合。
• セキュリティ上の理由からストレージのさまざまな部分を分離する場合、または管理を簡素化する場合。

パフォーマンスを向上させるために、ストレージ アカウントごとにコンテナーを 1 つだけ使用します。

クラスターの種類の選択

クラスターの種類によって、HDInsight クラスターが実行するように構成されるワークロードが決定されます。 タイプには、Apache Hadoop 、Apache Kafka 、または Apache Spark が含まれます。 使用できるクラスターの種類の詳細については、Azure HDInsight の概要に関するページを参照してください。 クラスターの種類ごとに、サイズとノード数の要件を含む特定のデプロイ トポロジがあります。

VM のサイズと種類の選択

各クラスターの種類には一連のノード タイプがあり、各ノード タイプには VM のサイズと種類の固有のオプションがあります。

アプリケーションに最適なクラスター サイズを決定するために、クラスターの容量のベンチマークを実行し、その結果に従ってサイズを増やすことができます。 たとえば、シミュレートされたワークロードや "カナリア クエリ" をご利用いただけます。 シミュレートされたワークロードをさまざまなサイズのクラスターで実行します。 目的のパフォーマンスに到達するまで、サイズを徐々に増やします。 他の実稼働クエリの間にカナリア クエリを定期的に挿入することで、クラスターに十分なリソースがあるかどうかを示すことができます。

ワークロードのための適切な VM ファミリを選択する方法の詳細については、クラスターの適切な VM サイズの選択に関するページを参照してください。

クラスターのスケールの選択

クラスターのスケールは、VM ノードの数によって決まります。 どのクラスターの種類にも、特定のスケールのノード タイプと、スケールアウトをサポートするノード タイプがあります。たとえば、クラスターで 3 つの Apache ZooKeeper ノードまたは 2 つのヘッド ノードが必要な場合があります。 分散方式でデータ処理を実行するワーカー ノードは、別のワーカー ノードのメリットが得られます。

クラスターの種類によっては、ワーカー ノードの数を増やすと、コンピューティング容量が増えます (コア数の増加など)。 ノードの数が増加すると、処理されるデータのインメモリ ストレージをサポートするためにクラスター全体に必要なメモリの合計が増えます。 VM のサイズと種類の選択と同様に、クラスターの適切なスケールの選択も、通常は経験的に実現されます。 シミュレートされたワークロードまたはカナリア クエリを使用します。

ピーク時の負荷要求を満たすようにクラスターをスケールアウトできます。 その後、これらの追加のノードが必要なくなったら、再びスケールダウンします。 自動スケーリング機能を使用すると、事前に定義されたメトリックとタイミングに基づいて、クラスターを自動的にスケーリングできます。 クラスターの手動スケーリングについて詳しくは、「HDInsight クラスターのスケーリング」をご覧ください。

クラスターのライフサイクル

ユーザーは、クラスターの有効期間に対して課金されます。 特定の時間だけクラスターが必要な場合は、Azure Data Factory を使用してオンデマンド クラスターを作成します。 また、クラスターのプロビジョニングと削除を実行する PowerShell スクリプトを作成し、Azure Automation を使用してそれらのスクリプトのスケジュールを設定することもできます。

クラスターのジョブ エラーの分離

マルチノード クラスターでの複数の map および reduce コンポーネントの並列実行のためにエラーが発生する場合があります。 この問題を分離しやすくするために、分散テストを試してください。 1 つのワーカー ノード クラスターで複数の同時実行ジョブを実行します。 次に、このアプローチを拡張して、複数のノードを含むクラスターで複数のジョブを同時に実行します。 Azure で単一ノードの HDInsight クラスターを作成するには、Custom(size, settings, apps) オプションを使用し、ポータルで新しいクラスターをプロビジョニングするときに [クラスター サイズ] セクションの [ワーカー ノードの数] に 1 の値を使用します。

HDInsight のクォータ管理を表示する

VM でのクォータの詳細なレベルと分類をファミリ レベルで表示します。 現在のクォータと、リージョンの残りのクォータを VM ファミリ レベルで表示します。

1. 現在のクォータを表示します。

   現在のクォータと、リージョンの残りのクォータを VM ファミリ レベルで表示します。

   1. Azure portal の上部の検索バーで [クォータ] を検索して選択します。

   2. [クォータ] ページで、[Azure HDInsight] を選択します

      

   3. ドロップダウン ボックスから、サブスクリプションとリージョンを選択します

      

      

2. VM ファミリとリージョンごとに新しいクォータを要求する

   1. クォータの詳細を表示する行をクリックします。

   

Quotas (クォータ)

サブスクリプション クォータの管理の詳細については、クォータの増加要求に関するページを参照してください。

次のステップ

• Apache Hadoop、Spark、Kafka などを使用して HDInsight でクラスターをセットアップする: HDInsight でクラスターをセットアップして構成する方法について説明します。
• クラスター パフォーマンスを監視する: クラスターの容量に影響を及ぼす可能性のある HDInsight クラスターを監視するための主なシナリオについて説明します。