このページでは、Google Kubernetes Engine（GKE）でバッチ処理プラットフォームを構築して最適化する際のベスト プラクティスについて説明します。次のようなベスト プラクティスについて説明します。
- アーキテクチャ
- ジョブ管理
- マルチテナンシー
- セキュリティ
- キュー
- ストレージ
- パフォーマンス
- 費用対効果
- モニタリング
GKE は、データ処理、ML モデルのトレーニング、科学シミュレーションの実行、その他のハイ パフォーマンス コンピューティング ワークロードなど、バッチ ワークロードのオーケストレーションを行うための優れたフレームワークを提供します。
ここで説明するベスト プラクティスは、GKE にバッチ ワークロードをデプロイするプラットフォーム管理者、クラウド アーキテクト、運用担当者を対象としています。GKE 上のバッチ処理プラットフォームのリファレンス アーキテクチャでは、このガイドで説明したベスト プラクティスの多くを紹介しています。このアーキテクチャは、独自の Google Cloud プロジェクトにデプロイできます。
バッチ ワークロードの仕組み
バッチ ワークロードは、ユーザーの介入なしに完了するまで実行されるタスクのグループです。タスクを定義するには、Kubernetes の Job リソースを使用します。バッチ プラットフォームは Job を受信し、受信した順にキューに入れます。バッチ プラットフォームのキューは、優先度、割り当て、割り当て可能なリソースなどの処理ロジックを適用します。Kubernetes では、バッチ処理パラメータのキューイングとカスタマイズを行うことで、使用可能なリソースの使用を最適化し、スケジュールされた Job のアイドル時間を最小限に抑え、コスト削減を最大化できます。次の図は、バッチ プラットフォームを構成する GKE コンポーネントを示しています。
バッチ プラットフォーム管理
従来、バッチ プラットフォームには、デベロッパーとプラットフォーム管理者という 2 つの主要なユーザー ペルソナがあります。
- デベロッパーが、プログラム、処理するデータ、Job の要件を指定して Job を送信します。次に、デベロッパーは Job 送信の確認と固有識別子を受け取ります。Job が完了すると、Job の出力または結果とともに、デベロッパーに通知が送信されます。
- プラットフォーム管理者は、効率的で信頼性の高いバッチ処理プラットフォームを管理し、デベロッパーに提供します。
バッチ処理プラットフォームは、次の要件を満たす必要があります。
- プラットフォーム リソースが適切にプロビジョニングされており、ユーザーの介入をほとんど、またはまったく必要とせずに Job を実行できること。
- プラットフォーム リソースが組織のセキュリティとオブザーバビリティのベスト プラクティスに沿って構成されていること。
- プラットフォーム リソースは可能な限り効率的に使用されます。リソース競合が発生した場合、最も重要な処理が最初に行われます。
GKE のバッチ プラットフォーム アーキテクチャを準備する
GKE 環境はノードで構成されます。ノードは Compute Engine 仮想マシン（VM）であり、グループ化されてクラスタを形成します。
次の表に、バッチ プラットフォーム アーキテクチャの計画と設計における主な推奨事項を示します。
| 推奨事項 | リソース | |
|---|---|---|
| GKE の運用モードを選択する |
GKE では、次の運用モードを使用できます。
Autopilot と Standard モードの概要の比較をご覧ください。 |
|
| ノードのマシンタイプを選択する |
GKE は、次の Compute Engine VM シリーズをサポートしています。
各マシンシリーズは、Intel や AMD の Arm プロセッサや x86 プロセッサなど、1 つ以上の CPU プラットフォームに関連付けられています。 |
|
| ハードウェア アクセラレータをノードで使用する |
GKE では、グラフィック プロセッシング ユニット（GPU）や Tensor Processing Unit（TPU）などのハードウェア アクセラレータを使用することもできます。GPU 時間共有戦略を検討してください。これにより、複数のコンテナが同じ物理 GPU で時間を共有できます。 このアプローチは、リクエストが少ないバースト可能な同種 GPU ワークロードに役立ちます。マルチインスタンス GPU を使用して GPU をパーティショニングし、1 つの GPU リソースを複数のコンテナで同時に共有します。
|
|
| Standard クラスタでクラスタ オートスケーラーを有効にする | GKE は、ワークロードの需要に基づいて、特定のノードプール内のノード数を自動的に変更します。ノードを手動で追加または削除する必要はありません。また、ノードプールを過剰にプロビジョニングする必要もありません。代わりに、ノードプールの最小サイズと最大サイズのみを指定します。 クラスタ オートスケーラーは、次の構成で設定することをおすすめします。
Autopilot クラスタを使用すると、ノードプールがノード自動プロビジョニングによって自動的にプロビジョニングされ、またワークロードの要件に合わせて自動的にスケーリングされるため、ノードのプロビジョニングやノードプールの管理について心配する必要はありません。 |
|
| クラスタをリリース チャンネルに登録する | GKE は、クラスタのバージョンとアップグレードを自動的に管理できます。リリース適応モデルに基づいて、クラスタを GKE の使用可能なチャネルに登録できます。
詳細については、クラスタに最適なリリース チャンネルを選択する方法をご覧ください。 | |
| クラスタから除外するメンテナンスのスコープを定義する | アップグレード スコープの除外ウィンドウが定義されている場合、GKE は、長時間実行されるバッチ ワークロードが完了するまで、メンテナンスによって中断されません。
詳細については、除外するメンテナンスの範囲をご覧ください。 |
Job のライフサイクルを管理する
Kubernetes では、一連の Pod でワークロードを実行します。Pod は、共有ストレージとネットワーク リソースをもつ単一または複数のコンテナのグループです。Pod は Kubernetes 仕様によって定義されます。
Job は 1 つ以上の Pod を作成し、指定された数の Pod が正常に終了するまでそれらの実行を再試行し続けます。Pod が完了すると、Job は正常に完了した数を追跡します。指定した回数が正常に完了すると、Job は完了します。
次の表に、Job を設計および管理する際の主な推奨事項を示します。
| 推奨事項 | リソース |
|---|---|
| Job 完了モードを選択する | [完了モード] を Indexed として指定します。この構成は、Pod のインデックスに基づいて処理するデータのパーティションを割り当てる場合に便利です。Job の Pod は、関連付けられた完了インデックスを取得します。Job を削除すると、Job で作成された Pod がクリーンアップされます。Job を一時停止すると、Job が再開されるまで、その Job のアクティブな Pod が削除されます。 |
| 定期的にスケジュールされるアクションに対して CronJob を設定する | GKE 用の CronJob を使用して、バックアップ、レポート生成、ML モデルのスケジュールされたトレーニングなど、スケジュール設定された定期的なアクションを実行します。 |
| Job の失敗を管理する | Job 内の再試行可能と再試行不可能な障害を処理する Kubernetes Pod の障害ポリシーと Pod バックオフの障害上限を定義します。この定義により、Pod の不要な再試行と Pod の中断による Job の失敗を回避することで、クラスタ リソースの消費を改善できます。たとえば、プリエンプション、API が開始したエビクション、または taint ベースのエビクション（ |
| 複数の Job を 1 つのユニットとして管理する | JobSet API を使用して、複数の Job を 1 つの単位として管理し、1 つのドライバ（またはコーディネーター）や複数のワーカー（MPIJob など）などのワークロード パターンに対処します。その一方で、ユースケースに基づいて一般的なパターンに沿った Job のデフォルトを設定します。たとえば、デフォルトでインデックス登録された Job を作成し、Pod 用に予測可能な完全修飾ドメイン名（FQDN）用のヘッドレス サービスを作成して、関連する Pod 障害ポリシーを設定できます。 |
| 再起動を許容しない Pod の実行時間を延長する | Pod 仕様で Kubernetes cluster-autoscaler.kubernetes.io/safe-to-evict アノテーションを false に設定します。クラスタ オートスケーラーは、Pod に設定されているエビクション ルールを考慮します。この制限により、cluster-autoscaler.kubernetes.io/safe-to-evict アノテーションが付いた Pod が含まれている場合に、オートスケーラーによってノードが削除されるのを防ぐことができます。詳細については、Pod のスケジューリングと停止の考慮をご覧ください。 |
マルチテナンシーの管理
GKE のクラスタ マルチテナンシーは、1 つの組織で、テナントと呼ばれるさまざまなユーザーまたはワークロードで GKE リソースを管理する、代わりの手段です。GKE リソースの管理は、テナントの分離、割り当てと上限の範囲、費用の割り当てなどの条件に従う場合があります。
次の表に、マルチテナンシーを管理する際の主な推奨事項を示します。
| 推奨事項 | リソース |
|---|---|
| Namespace を使用してテナント分離を管理する | 各テナントとその Kubernetes リソースをそれぞれ独自の Namespace に分離できます。 |
| ポリシーを使用してテナント分離を適用する | ポリシーを定義して、API アクセスを限定し、割り当てを設定し、リソース使用量に上限を設け、コンテナで許可される操作を制限します。これらのポリシーは Namespace でスコープされます。 |
| GKE の費用割り当てを設定する | GKE の費用割り当てを使用して、Namespace ごとに各テナントのクラスタ リソース リクエストに関する分析情報を取得します。 |
バッチ プラットフォームへのアクセスを制御する
GKE を使用すると、クラスタ上で実行されるワークロードのアクセス権限を微調整できます。
次の表は、アクセスとセキュリティを管理する際の主な推奨事項を示しています。
| 推奨事項 | リソース |
|---|---|
| Workload Identity Federation for GKE を設定する | GKE により、GKE クラスタ内のワークロードは、Identity and Access Management（IAM）サービス アカウントの権限を借用して Google Cloud サービスにアクセスできます。GKE 用 Workload Identity 連携を使用すると、ワークロードは GKE の外部に保存されている Secret に安全にアクセスできます。 詳細については、GKE 用 Workload Identity 連携と保存されている Secret にアクセスするをご覧ください。 |
| クラスタ ネットワーク分離を設定する | コントロール プレーン エンドポイントとワーカーノードの両方が内部 IP アドレスを持つことができるように、クラスタのネットワーク分離を構成します。 詳細については、ネットワーク分離のカスタマイズについてをご覧ください。 |
| Shielded GKE Nodes を使用する | シールドされた GKE ノードを構成して、強固で検証可能なノード ID と整合性を提供し、GKE ノードのセキュリティを強化します。 |
| 物理的な分離 | セキュリティ上の理由から、ワークロードの分離を強化する必要がある場合があります。ノード taints でスケジューリングを制御し、ノード taints とワークロードの toleration を使用して、ノードプール内のテナントを物理的に分離します。これにより、適切なワークロードのみがそれらのノードプールにスケジュールされるようになります。 |
キューと公平な共有
リソースの使用量を制御するには、テナントごとにリソース割り当て上限を割り当て、受信 Job をキューに入れて、Job を受信順に処理します。
次の表に、バッチ ワークロード間のキューと公平な共有を管理する際の主な推奨事項を示します。
| 推奨事項 | リソース |
|---|---|
| Kueue を使用する | Kueue は、Kubernetes クラスタ内のバッチ、ハイ パフォーマンス コンピューティング、ML、および同様のアプリケーションのための Kubernetes ネイティブの Job のキューイング システムです。テナント間でクラスタ リソースを公平に共有できるように、Kueue は割り当てと Job による使用方法を管理します。Kueue は次の決定を行います。
Job のキューイング システムの実装方法については、GKE の Namespace 間で割り当てを共有するジョブ キューイング システムを実装するをご覧ください。 Kueue の詳細については、Kueue のコンセプトをご覧ください。 |
ストレージ、パフォーマンス、費用対効果
GKE のコンピューティング リソースとストレージ リソースを効率的に使用することで、費用を削減できます。 1 つの戦略は、パフォーマンスを犠牲にすることなく、バッチ処理のニーズに応じてコンピューティング インスタンスのサイズと構成を適正化することです。
次の表に、ストレージの設計と管理、およびパフォーマンスの最適化に関する主な推奨事項を示します。
| 推奨事項 | リソース |
|---|---|
| Compute Engine Persistent Disk を使用する | 次の Compute Engine Persistent Disk 構成を使用することをおすすめします。
|
| ネットワーク接続ストレージを使用する | 最適なストレージ パフォーマンスを得るには、Persistent Disk とともに次のネットワーク接続ストレージを使用します。
|
| Pub/Sub を定義する | バッチ ワークロードでは、データの読み取りと書き込みを行うこともできます。たとえば、Pub/Sub を使用して BigQuery などのデータ ウェアハウスに結果を書き込み、そこからレポートとダッシュボードを更新できます。 次のストレージ ソリューションを使用することをおすすめします。
|
| ワークロードの調整パラメータを指定する | 次の構成を使用することをおすすめします。
|
| ワークロードのネットワークとレイテンシを最適化する | GKE はノードプールのコンパクト プレースメント ポリシーをサポートしています。このポリシーでは、ゾーン内でこれらのノード（つまり、それらのワークロード上で実行されているワークロード）をお互い物理的に近接した場所に配置するように指定します。これは、密結合で高パフォーマンスのワークロードに特に役立ちます。この場合、ワークロードを構成する異なるプロセス間の低レイテンシが大きな懸念事項となります。詳しくは、コンパクト プレースメントをご覧ください。 |
| Spot VM を使用する | Spot VM は標準的な Compute Engine VM より料金が低く、可用性が保証されない Compute Engine 仮想マシン（VM）インスタンスです。 次のソリューションを使用することをおすすめします。
|
| イメージ ストリーミングを使用する | イメージ ストリーミングを使用してコンテナ イメージを pull します。GKE は対象のイメージからデータをストリーミングします。これにより、イメージ全体のダウンロードを待たずにワークロードを初期化できるため、初期化時間が大幅に短縮され、費用対効果が向上します。 |
モニタリング
GKE には、クラスタの信頼性と効率性のモニタリングに役立つ、オブザーバビリティ ツールとロギングツールが統合されています。次の表に、GKE オブザーバビリティ ツールを有効にして使用する際の主な推奨事項を示します。
| 推奨事項 | リソース |
|---|---|
| Prometheus を使用する | GKE は Google Cloud Observability と統合されています。GKE が Cloud Logging と Cloud Monitoring に送信する指標をカスタマイズします Google Cloud Managed Service for Prometheus は、GKE クラスタではデフォルトで有効になっています。マネージド コレクションを使用して、Prometheus サーバーのセットアップやメンテナンスの複雑さを解消することをおすすめします。 詳細については、Managed Service for Prometheus をご覧ください。 |
| Cloud Monitoring ダッシュボードを使用する | GKE 用 Monitoring ダッシュボードを使用すると、クラスタとリソースの使用状況の概要を確認し、さまざまな指標と項目にドリルダウンしてフィルタリングできます。 詳細については、GKE クラスタの観察をご覧ください。 |