Dataproc セカンダリ ワーカー

Dataproc クラスタは、標準的な Compute Engine VM を Dataproc ワーカー（「プライマリ」ワーカーと呼びます）として使用するだけでなく、secondary ワーカーも使用できます。

次のルールは、Dataproc クラスタ内のすべてのセカンダリ ワーカーに適用されます。

  • 処理のみ - セカンダリ ワーカーはデータを保存しません。これらは、処理ノードとしてのみ機能します。そのため、セカンダリ ワーカーを使用すると、ストレージをスケールすることなく、コンピューティングをスケールできます。

  • セカンダリ ワーカーのみのクラスタはゼロ: クラスタにはプライマリ ワーカーが必要です。クラスタを作成し、プライマリ ワーカーの数を指定しない場合、Dataproc によって 2 つのプライマリ ワーカーがクラスタに追加されます。

  • マシンタイプ - セカンダリ ワーカーは、デフォルトでクラスタのプライマリ ワーカーのマシンタイプを使用します。たとえば、n1-standard-4 マシンタイプを使用するプライマリ ワーカーでクラスタを作成した場合、クラスタに追加したすべてのセカンダリ ワーカーも n1-standard-4 マシンタイプを使用します。

    セカンダリ ワーカーには、デフォルトのプライマリ ワーカー マシンタイプを使用する代わりに、セカンダリ ワーカー用に 1 つ以上のランク付けされたマシンタイプのリストを指定できます。詳細については、Dataproc フレキシブル VM をご覧ください。

  • 永続ディスクサイズ: デフォルトとして、すべてのセカンダリ ワーカーは 100GB またはプライマリ ワーカーのブートディスク サイズ未満で作成されます。このディスク容量は、データをローカルのキャッシュに保存するために使用され、HDFS では使用できません。 クラスタ作成時に gcloud dataproc clusters create --secondary-worker-boot-disk-size コマンドを使用して、デフォルトのディスクサイズをオーバーライドできます。このフラグは、クラスタの作成時にセカンダリ ワーカーが割り当てられなかった場合でも指定できます。

  • 非同期作成 - クラスタの作成またはスケーリングによってセカンダリ ワーカーを追加する場合、セカンダリ ワーカーは、作成または更新のオペレーションが完了するまでプロビジョニングされません。これは、プロビジョニングされたらすぐに Dataproc が VM を非同期に作成するマネージド インスタンス グループ（MIG）を使用してセカンダリ ワーカーを管理するためです（マネージド インスタンスのステータスの確認をご覧ください）。

プリエンプティブルと非プリエンプティブル セカンダリ ワーカー

セカンダリ ワーカーには、Spot VM、標準プリエンプティブル VM、非プリエンプティブル VM の 3 種類があります。クラスタのセカンダリ ワーカーを指定する場合は、同じタイプにする必要があります。デフォルトの Dataproc セカンダリ ワーカーのタイプは、標準プリエンプティブル VM です。

例: クラスタを作成するときに 3 つのセカンダリ ワーカーを選択した場合は、3 つすべてを Spot VM にするか、3 つすべてを（標準）プリエンプティブル VM にするか、3 つすべてを非プリエンプティブル VM にするように指定できますが、それぞれ異なるタイプを指定することはできません。

Spot VM は、Compute Engine プリエンプティブル VM の最新のタイプです。料金モデルは低コストの標準プリエンプティブル VM と共通ですが、最長存続期間が 24 時間の標準プリエンプティブル VM とは異なり、Spot VM には最長存続期間がありません。Spot VM と標準プリエンプティブル VM ワーカーは、他のタスクで Google Cloud が必要とする場合に再利用され、Dataproc クラスタから削除されます。

プリエンプティブル ワーカー

  • プリエンプティブル ワーカーの削除の可能性はジョブの安定性に影響を及ぼす可能性がありますが、プリエンプティブル インスタンスを使用して、重要性の低いデータ処理の 1 時間あたりの計算費用の削減や、非常に大規模なクラスタの低総費用での作成ができます（Google Cloud 料金計算ツールを使用して費用を見積もることができます）。

  • 最適な結果を得るには、クラスタ内のプリエンプティブル ワーカーの数を、クラスタ内のワーカー数の合計（プライマリ ワーカーとすべてのセカンダリ ワーカー）の 50% 未満にする必要があります。

  • プリエンプティブル ワーカーを使用する場合は、非プリエンプティブル ワーカーで実行されるジョブと比較して、ジョブの一時的な単一ワーカータスクの失敗が多くなります。低レベルのタスクの失敗に対するジョブの許容度を上げるには、クラスタの自動スケーリングで使用されるデフォルトのプロパティ値と同様のクラスタ プロパティ値を設定して、タスクの再試行の最大回数を増やし、ジョブの失敗を回避することが可能です。

  • コスト節減の検討事項: プリエンプティブル VM を使用しても、プリエンプションによってジョブの実行時間が長くなり、ジョブの費用が高くなる可能性があるため、必ずしもコスト削減につながるわけではありません。プリエンプティブル VM で高度な柔軟性モード（EFM）を使用すると、この影響を軽減できますが、プリエンプティブル VM の全体的なコスト削減はユースケースによって異なります。一般的に、有効期間が短いジョブの方が、ジョブ実行中のプリエンプションの可能性が低いため、プリエンプティブル VM の使用に適しています。非プリエンプティブル VM や EFM を使用するプリエンプティブル VM など、さまざまなジョブ オプションを試して、費用の見積もりを行い、最適なソリューションを見つけてください。

非プリエンプティブル ワーカー

  • 非プリエンプティブルのセカンダリ ワーカーを持つクラスタを作成すると、ジョブの安定性を損なうことなくコンピューティングをスケールできます。これを行うには、セカンダリ ワーカーのタイプとして「非プリエンプティブル」を指定します。

セカンダリ ワーカーを使用する

Google Cloud Console、gcloud CLI、または Dataproc API を使用してクラスタを作成するときに、セカンダリ ワーカーの数とタイプを指定できます。

  • セカンダリ ワーカーは同じタイプでなければなりません。
  • 作成後にクラスタを更新して、クラスタ内のセカンダリ ワーカーの数を変更できますが、セカンダリ ワーカーのタイプは変更できません。
  • ラベルの更新は、24 時間以内にすべてのプリエンプティブル セカンダリ ワーカーに反映されます。ラベルの更新はプリエンプティブルでない既存のセカンダリ ワーカーには反映されません。ラベルの更新は、ラベル更新の後にクラスタに追加されたすべてのワーカーに伝搬されます。たとえば、クラスタをスケールアップすると、すべての新しいプライマリ ワーカーとセカンダリ ワーカーに新しいラベルが付けられます。

Console

Google Cloud コンソールから Dataproc クラスタを作成する際に、セカンダリ ワーカーの数を指定できます。クラスタを作成したら、Google Cloud コンソールからクラスタ構成を編集して、セカンダリ ワーカーの追加や削除を行います。

セカンダリ ワーカーを持つクラスタを作成する

Google Cloud コンソールの Dataproc [クラスタの作成] ページの [セカンダリ ワーカーノード] セクションから、新しいクラスタに適用するセカンダリ ワーカーの数とタイプを設定します。[セカンダリ ワーカー ノード] と [プリエンプティブル] フィールドに、セカンダリ ワーカーの数とタイプをそれぞれ指定します。

セカンダリ インスタンスでのクラスタの更新

クラスタ内のセカンダリ ワーカー数を更新するには、Google Cloud コンソールの [クラスタ] ページでクラスタ名をクリックします。[クラスタの詳細] ページで、[構成] タブをクリックし、[編集] をクリックして [セカンダリ ワーカーノード] フィールドの番号を更新します。

クラスタからすべてのプリエンプティブル インスタンスを削除する

クラスタからすべてのセカンダリ ワーカーを削除するには、[セカンダリ ワーカーノード] フィールドに 0 を指定して、先ほどの説明のとおりにクラスタ構成を更新します。

gcloud コマンド

gcloud dataproc clusters create コマンドを使用して、クラスタの作成時にセカンダリ ワーカーをクラスタに追加します。クラスタの作成後に、gcloud dataproc clusters update コマンド（更新できるセカンダリ ワーカーのタイプではなく、数値）を使用して、セカンダリ ワーカーをクラスタから追加または削除できます。

セカンダリ ワーカーを持つクラスタを作成する

セカンダリ ワーカーを持つクラスタを作成するには、--num-secondary-workers 引数を持つ gcloud dataproc clusters create コマンドを使用します。セカンダリ ワーカーは、デフォルトでは標準プリエンプティブル VM です。クラスタの作成時に --secondary-worker-type=non-preemptible を設定すると、非プリエンプティブル セカンダリ ワーカーを指定できます（セカンダリ ワーカーのタイプを指定する際に、dataproc:secondary-workers.is-preemptible.override プロパティを使用することはなくなりました）。

例 1

次のコマンドは、2 つの標準プリエンプティブル（デフォルト タイプ）セカンダリ ワーカーを持つ「cluster1」を作成します。

gcloud dataproc clusters create cluster1 \
    --num-secondary-workers=2 \
    --region=us-central1
例 2

次のコマンドは、secondary-worker-type フラグを使用して 2 つの Spot（プリエンプティブル）セカンダリ ワーカーを持つ「cluster2」を作成します。

gcloud dataproc clusters create cluster2 \
    --num-secondary-workers=2 \
    --secondary-worker-type=spot \
    --region=us-central1

例 3

次のコマンドは、secondary-worker-type フラグを使用して 2 つの非プリエンプティブルセカンダリ ワーカーを持つ「cluster3」を作成します。

gcloud dataproc clusters create cluster3 \
    --num-secondary-workers=2 \
    --secondary-worker-type=non-preemptible \
    --region=us-central1

セカンダリ ワーカーを持つクラスタの更新

セカンダリ ワーカーを追加または削除するクラスタを更新するには、--num-secondary-workers 引数を持つ gcloud dataproc clusters update コマンドを使用します。

例

次のコマンドは、4 つのセカンダリ ワーカー（デフォルト タイプまたはクラスタ作成時に指定したタイプ）を使用するように「example-cluster」を更新します。

gcloud dataproc clusters update example-cluster \
    --num-secondary-workers=4 \
    --region=us-central1

クラスタからすべてのセカンダリ ワーカーを削除する

クラスタからすべてのセカンダリ ワーカーを削除するには、--num-secondary-workers を 0 に設定して gcloud dataproc clusters update コマンドを使用します。

例

次のコマンドは、「example-cluster」からすべてのセカンダリ ワーカーを削除します。

gcloud dataproc clusters update example-cluster \
    --num-secondary-workers=0 \
    --region=us-central1

REST API

セカンダリ ワーカーを持つクラスタを作成する

Dataproc clusters.create API を使用して、クラスタの作成時にセカンダリ ワーカーをクラスタに追加します。セカンダリ ワーカーは、デフォルトでは標準プリエンプティブル VM です。

例 1

次の POST リクエストは、2 つの標準プリエンプティブル（デフォルト タイプ）VM ワーカーを持つ「cluster1」を作成します。


POST https://dataproc.googleapis.com/v1/projects/project-id/regions/region/clusters

{
  "clusterName": "cluster1",
  "config": {
    "secondaryWorkerConfig": {
      "numInstances": 2
    }
  }
}
例 2

次の POST リクエストは、2 つの Spot（プリエンプティブル）VM ワーカーを持つ「cluster2」を作成します。


POST https://dataproc.googleapis.com/v1/projects/project-id/regions/region/clusters

{
  "clusterName": "cluster2",
  "config": {
    "secondaryWorkerConfig": {
      "numInstances": 2,
      "preemptibility": "SPOT"
    }
  }
}

例 3

次の POST リクエストは、2 つの非プリエンプティブル セカンダリ ワーカーを持つ「cluster3」を作成します。


POST https://dataproc.googleapis.com/v1/projects/project-id/regions/region/clusters

{
  "clusterName": "cluster3",
  "config": {
    "secondaryWorkerConfig": {
      "numInstances": 2,
      "preemptibility": "NON_PREEMPTIBLE"
    }
  }
}

セカンダリ ワーカーを持つクラスタの更新

Dataproc clusters.patch API を使用して、セカンダリ ワーカーを追加および削除します。

例

次の PATCH リクエストは、4 つのセカンダリ ワーカー（デフォルト タイプまたはクラスタ作成時に指定したタイプ）を持つようにクラスタを更新します。


PATCH /v1/projects/project-id/regions/region/clusters/cluster-name?updateMask=config.secondary_worker_config.num_instances
{
  "config": {
    "secondaryWorkerConfig": {
      "numInstances": 4
    }
  }
}

セカンダリ ワーカーのトラブルシューティング

サービス アカウントの権限に関する問題: セカンダリ ワーカーはマネージド インスタンス グループを介して作成され、Compute Engine はプロジェクトの Google API サービス エージェントのサービス アカウントを使用してマネージド インスタンス グループのオペレーションを実行します。このサービス アカウント名は project-id@cloudservices.gserviceaccount.com の形式です。

このサービス アカウントに権限の問題がある場合は、Dataproc ログはセカンダリ ワーカーの作成失敗を報告しませんが、失敗したワーカーが Google Cloud Console 内の [クラスタの詳細] ページの [VM インスタンス] タブに緑のチェックマークなしで一覧表示されます（Dataproc の [クラスタ] ページを開いてから、クラスタ名をクリックして [クラスタの詳細] ページを開きます）。

  • マネージド インスタンス グループの権限の問題: マネージド インスタンス グループの権限に問題があるかどうかを確認するには、「Google Compute Engine Instance Group」リソースタイプのために、Google Compute Engine のログ エクスプローラでログを表示し、対応するインスタンス グループ ID でフィルタリングします。インスタンス グループ ID フィルタには、dataproc-CLUSTER NAME-sw の形式でインスタンス グループ名が表示され、インスタンス グループ ID がロギングクエリに自動的に入力されます。プルダウン フィルタを使用する代わりに、resource.type="gce_instance_group" と resource.labels.instance_group_name="dataproc-CLUSTER NAME-sw" のためにロギング フィルタを適用することもできます。

  • カスタム イメージの権限の問題: Dataproc クラスタ VM が、別のプロジェクトから取得されるカスタム イメージで作成される場合には、Compute Image User ロールはプロジェクトの project-id@cloudservices.gserviceaccount.com サービス アカウントに割り当てる必要があります（マネージド インスタンス グループにイメージへのアクセス権限を付与するをご覧ください）。 正しいロールが割り当てられていない場合は、ログに Required 'compute.images.useReadOnly' permission for 'projects/[IMAGE PROJECT]/global/images/[IMAGE NAME] のエラー メッセージが表示されます。