HDInsight クラスターの容量計画Capacity planning for HDInsight clusters

HDInsight クラスターをデプロイする前に、必要なパフォーマンスとスケールを決定して、必要となるクラスターの容量を計画します。Before deploying an HDInsight cluster, plan for the desired cluster capacity by determining the needed performance and scale. この計画により、使いやすさとコストの両方を最適化できます。This planning helps optimize both usability and costs. クラスターの容量に関する決定事項の中には、デプロイ後に変更できないものもあります。Some cluster capacity decisions can't be changed after deployment. パフォーマンス パラメーターが変わった場合は、保存されているデータを失うことなく、クラスターを解体して再作成できます。If the performance parameters change, a cluster can be dismantled and re-created without losing stored data.

容量計画における重要な検討事項は次のとおりです。The key questions to ask for capacity planning are:

  • クラスターをどの地理的リージョンにデプロイすればよいか。In which geographic region should you deploy your cluster?
  • どれくらいのストレージ容量が必要か。How much storage do you need?
  • どのような種類のクラスターをデプロイすればよいか。What cluster type should you deploy?
  • クラスター ノードでは、どのサイズおよび種類の仮想マシン (VM) を使用すればよいか。What size and type of virtual machine (VM) should your cluster nodes use?
  • クラスターにはワーカー ノードがいくつ必要か。How many worker nodes should your cluster have?

Azure リージョンの選択Choose an Azure region

Azure リージョンによって、クラスターを物理的にプロビジョニングする場所が決まります。The Azure region determines where your cluster is physically provisioned. 読み取りと書き込みの待機時間を最小限に抑えるには、クラスターをデータの近くに配置する必要があります。To minimize the latency of reads and writes, the cluster should be near your data.

HDInsight は多数の Azure リージョンで利用できます。HDInsight is available in many Azure regions. 最も近いリージョンを確認するには、「リージョン別の利用可能な製品」を参照してください。To find the closest region, see Products available by region.

ストレージの場所とサイズの選択Choose storage location and size

既定のストレージの場所Location of default storage

既定のストレージ (Azure ストレージ アカウントまたは Azure Data Lake Storage) は、クラスターと同じ場所に存在する必要があります。The default storage, either an Azure Storage account or Azure Data Lake Storage, must be in the same location as your cluster. Azure Storage はあらゆる場所で利用できます。Azure Storage is available at all locations. Data Lake Storage Gen1 は一部のリージョンで利用できます。Data Lake Storage の現在の提供状況を参照してください。Data Lake Storage Gen1 is available in some regions - see the current Data Lake Storage availability.

既存のデータの場所Location of existing data

データを格納しているストレージ アカウントまたは Data Lake Storage が既にあり、そのストレージをクラスターの既定のストレージとして使用する場合は、ストレージと同じ場所にクラスターをデプロイする必要があります。If you already have a storage account or Data Lake Storage containing your data and want to use this storage as your cluster's default storage, then you must deploy your cluster at that same location.

ストレージ サイズStorage size

HDInsight クラスターのデプロイ後に、追加の Azure ストレージ アカウントを接続したり、他の Data Lake Storage にアクセスしたりできます。After you have an HDInsight cluster deployed, you can attach additional Azure Storage accounts or access other Data Lake Storage. すべてのストレージ アカウントがクラスターと同じ場所に存在する必要があります。All your storage accounts must reside in the same location as your cluster. Data Lake Storage は別の場所にあっても構いませんが、その場合、データの読み取り/書き込みの待機時間が発生する可能性があります。A Data Lake Storage can be in a different location, although this may introduce some data read/write latency.

Azure Storage Gen1 には容量制限がありますが、Data Lake Storage には実質的に制限はありません。Azure Storage has some capacity limits, while Data Lake Storage Gen1 is virtually unlimited.

クラスターは、さまざまなストレージ アカウントの組み合わせにアクセスできます。A cluster can access a combination of different storage accounts. 一般的な例を次に示します。Typical examples include:

  • データ量が、1 つの Blob Storage コンテナーのストレージ容量を超える可能性がある場合。When the amount of data is likely to exceed the storage capacity of a single blob storage container.
  • BLOB コンテナーへのアクセス レートがしきい値を超え、調整が発生する可能性がある場合。When the rate of access to the blob container might exceed the threshold where throttling occurs.
  • データを作成する必要があるときに、クラスターで利用できる BLOB コンテナーに既にアップロードしている場合。When you want to make data, you've already uploaded to a blob container available to the cluster.
  • セキュリティ上の理由からストレージのさまざまな部分を分離する場合、または管理を簡素化する場合。When you want to isolate different parts of the storage for reasons of security, or to simplify administration.

48 ノードのクラスターの場合、4 から 8 個のストレージ アカウントを使用することをお勧めします。For a 48-node cluster, we recommend 4 to 8 storage accounts. 既に十分な数のストレージが存在する場合もありますが、各ストレージ アカウントはコンピューティング ノードに追加のネットワーク帯域幅を提供します。Although there may already be sufficient total storage, each storage account provides additional networking bandwidth for the compute nodes. 複数のストレージ アカウントがある場合は、各ストレージ アカウントにプレフィックスなしのランダムな名前を使用します。When you have multiple storage accounts, use a random name for each storage account, without a prefix. ランダムな名前付けの目的は、すべてのアカウント間でストレージのボトルネック (調整) や共通モード エラーが発生する可能性を低減することです。The purpose of random naming is reducing the chance of storage bottlenecks (throttling) or common-mode failures across all accounts. パフォーマンスを向上させるために、ストレージ アカウントごとにコンテナーを 1 つだけ使用します。For better performance, use only one container per storage account.

クラスターの種類の選択Choose a cluster type

クラスターの種類によって、実行されるワークロード (Apache HadoopApache StormApache KafkaApache Spark など) が決まります。HDInsight クラスターは、そのワークロードを実行するように構成されます。The cluster type determines the workload your HDInsight cluster is configured to run, such as Apache Hadoop, Apache Storm, Apache Kafka, or Apache Spark. 使用できるクラスターの種類の詳細については、Azure HDInsight の概要に関するページを参照してください。For a detailed description of the available cluster types, see Introduction to Azure HDInsight. クラスターの種類ごとに、サイズとノード数の要件を含む特定のデプロイ トポロジがあります。Each cluster type has a specific deployment topology that includes requirements for the size and number of nodes.

VM のサイズと種類の選択Choose the VM size and type

各クラスターの種類には一連のノード タイプがあり、各ノード タイプには VM のサイズと種類の固有のオプションがあります。Each cluster type has a set of node types, and each node type has specific options for their VM size and type.

アプリケーションに最適なクラスター サイズを決定するために、クラスターの容量のベンチマークを実行し、その結果に従ってサイズを増やすことができます。To determine the optimal cluster size for your application, you can benchmark cluster capacity and increase the size as indicated. たとえば、シミュレートされたワークロードや "カナリア クエリ" をご利用いただけます。For example, you can use a simulated workload, or a canary query. シミュレートされたワークロードを使用して、さまざまなサイズのクラスターで予想されるワークロードを実行し、必要なパフォーマンスに到達するまでサイズを徐々に増やしていきます。With a simulated workload, you run your expected workloads on different size clusters, gradually increasing the size until the desired performance is reached. 他の実稼働クエリの間にカナリア クエリを定期的に挿入することで、クラスターに十分なリソースがあるかどうかを示すことができます。A canary query can be inserted periodically among the other production queries to show whether the cluster has enough resources.

ワークロードのための適切な VM ファミリを選択する方法の詳細については、クラスターの適切な VM サイズの選択に関するページを参照してください。For more information on how to choose the right VM family for your workload, see Selecting the right VM size for your cluster.

クラスターのスケールの選択Choose the cluster scale

クラスターのスケールは、VM ノードの数によって決まります。A cluster's scale is determined by the quantity of its VM nodes. どのクラスターの種類にも、特定のスケールのノード タイプと、スケールアウトをサポートするノード タイプがあります。たとえば、クラスターで 3 つの Apache ZooKeeper ノードまたは 2 つのヘッド ノードが必要な場合があります。For all cluster types, there are node types that have a specific scale, and node types that support scale-out. For example, a cluster may require exactly three Apache ZooKeeper nodes or two Head nodes. 分散方式でデータ処理を実行するワーカー ノードは、ワーカー ノードを追加することで、スケールアウトのメリットが得られます。Worker nodes that do data processing in a distributed fashion can benefit from scaling out, by adding additional worker nodes.

クラスターの種類によっては、ワーカー ノードの数を増やすことでコンピューティング能力が高まりますが (コア数の増加など)、処理するデータのインメモリ ストレージをクラスター全体でサポートするために必要なメモリの総容量も増加する可能性があります。Depending on your cluster type, increasing the number of worker nodes adds additional computational capacity (such as more cores), but may also add to the total amount of memory required for the entire cluster to support in-memory storage of data being processed. VM のサイズと種類を選択する場合と同様に、通常、クラスタの適切なスケールの選択は、シミュレートされたワークロードやカナリア クエリを使用して経験的に行われます。As with the choice of VM size and type, selecting the right cluster scale is typically reached empirically, using simulated workloads or canary queries.

ピーク時の負荷要求に合わせてクラスターをスケールアウトし、それらの追加ノードが不要になったらスケールインすることができます。You can scale out your cluster to meet peak load demands, then scale it back down when those extra nodes are no longer needed. 自動スケーリング機能を使用すると、あらかじめ決められているメトリックとタイミングに基づいて、クラスターを自動的にスケーリングできます。The Autoscale feature allows you automatically scale your cluster based upon predetermined metrics and timings. クラスターの手動スケーリングについて詳しくは、「HDInsight クラスターのスケーリング」をご覧ください。For more information on scaling your clusters manually, see Scale HDInsight clusters.

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

クラスターの有効期間に課金が発生します。You are charged for a cluster's lifetime. 特定の時間にのみクラスターを起動して実行する必要がある場合は、Azure Data Factory を使用してオンデマンド クラスターを作成できます。If there are only specific times that you need your cluster up and running, you can create on-demand clusters using Azure Data Factory. また、クラスターのプロビジョニングと削除を実行する PowerShell スクリプトを作成し、Azure Automation を使用してそれらのスクリプトのスケジュールを設定することもできます。You can also create PowerShell scripts that provision and delete your cluster, and then schedule those scripts using Azure Automation.

注意

クラスターが削除されると、既定の Hive metastore も削除されます。When a cluster is deleted, its default Hive metastore is also deleted. クラスターを次回再作成するために metastore を保持するには、Azure Database や Apache Oozie などの外部メタデータ ストアを使用します。To persist the metastore for the next cluster re-creation, use an external metadata store such as Azure Database or Apache Oozie.

クラスターのジョブ エラーの分離Isolate cluster job errors

マルチノード クラスターで、複数の map および reduce コンポーネントの同時実行が原因でエラーが発生する場合があります。Sometimes errors can occur due to the parallel execution of multiple maps and reduce components on a multi-node cluster. この問題を分離するために、単一ワーカー ノード クラスターで複数の同時実行ジョブを実行して分散テストを試してみます。その後、この手法を拡大して、複数のノードを含むクラスターで複数のジョブを同時に実行します。To help isolate the issue, try distributed testing by running concurrent multiple jobs on a single worker node cluster, then expand this approach to run multiple jobs concurrently on clusters containing more than one node. Azure で単一ノードの HDInsight クラスターを作成するには、 [カスタム (サイズ、設定、アプリ )] オプションを使用して、ポータルで新しいクラスターをプロビジョニングするときに [クラスター サイズ] セクションの [Number of Worker nodes](ワーカー ノードの数) に 1 の値を使用します。To create a single-node HDInsight cluster in Azure, use the Custom(size,settings,apps) option and use a value of 1 for Number of Worker nodes in the Cluster size section when provisioning a new cluster in the portal.

Quotas (クォータ)Quotas

ターゲット クラスターの VM サイズ、スケール、種類を決定したら、サブスクリプションの現在のクォータの容量制限を確認します。After determining your target cluster VM size, scale, and type, check the current quota capacity limits of your subscription. クォータの上限に達すると、新しいクラスターをデプロイしたり、ワーカー ノードを追加して既存のクラスターをスケールアウトしたりといったことができなくなる可能性があります。When you reach a quota limit, you may not be able to deploy new clusters, or scale out existing clusters by adding more worker nodes. 唯一のクォータ制限は CPU コア クォータに関するものであり、サブスクリプションごとにリージョン レベルで存在します。The only quota limit is the CPU Cores quota that exists at the region level for each subscription. たとえば、ご利用のサブスクリプションは、米国東部リージョンにおいてコア数が 30 に制限されます。For example, your subscription may have 30 core limit in the East US region. クォータの増加を要求する必要がある場合は、次の手順を行います。If you need to request a quota increase, do the following steps:

  1. Azure Portal にサインインします。Sign in to the Azure portal.

  2. ページの左下にある [ヘルプとサポート] を選択します。Select Help + support on the bottom-left side of the page.

  3. [新しいサポート リクエスト] を選択します。Select New support request.

  4. [新しいサポート要求] ページの [基本] タブで、次のオプションを選択します。On the New support request page, under Basics tab, select the following options:

    • 問題の種類: サービスとサブスクリプションの制限 (クォータ)Issue type: Service and subscription limits (quotas)

    • サブスクリプション: 使用するサブスクリプションSubscription: the subscription you want to modify

    • クォータの種類: HDInsightQuota type: HDInsight

      HDInsight コア クォータを増やすためのサポート要求を作成します。

  5. [次へ:ソリューション >>] を選択します。Select Next: Solutions >>.

  6. [詳細] ページで、問題に関する説明を入力し、問題の重大度、希望する連絡方法、およびその他の必須フィールドを選択します。On the Details page, enter a description of the issue, select the severity of the issue, your preferred contact method, and other required fields.

  7. [次へ:確認と作成 >>] を選択します。Select Next: Review + create >>.

  8. [確認および作成] タブで、 [作成] を選択します。On the Review + create tab, select Create.

注意

プライベート リージョンで HDInsight コア クォータを増やす必要がある場合は、ホワイト リストの要求を送信してください。If you need to increase the HDInsight core quota in a private region, submit a whitelist request.

サポートに連絡してクォータの引き上げを要求できます。You can contact support to request a quota increase.

ただし、固定のクォータ制限もいくつかあります。たとえば、1 つの Azure サブスクリプションで使用できるコア数は最大 10,000 コアです。However, there are some fixed quota limits, for example a single Azure subscription can have at most 10,000 cores. これらの制限の詳細については、「Azure サブスクリプションとサービスの制限、クォータ、制約」をご覧ください。For details on these limits, see Azure subscription and service limits, quotas, and constraints.

次の手順Next steps