このドキュメントでは、AI ハイパーコンピュータ ワークロード用に安全で復元性に優れたネットワーキング環境を作成するためのベスト プラクティスについて説明します。これらの推奨事項は、AI Hypercomputer で AI と ML のワークロードを構成してデプロイするネットワーク アーキテクト、ネットワーク エンジニア、デベロッパーを対象としています。
明確で制限された IAM ロールを確立する
IAM を正しく構成すると、AI Hypercomputer のデプロイのセキュリティと成功率を高めることができます。本番環境では、権限が不十分または誤って構成されていると、デプロイが失敗する可能性があります。AI Hypercomputer のデプロイ、特に Cluster Toolkit を使用するデプロイは、デフォルトの Compute Engine サービス アカウントに幅広い Editor ロールが付与されていないセキュリティ強化された環境で失敗することがよくあります。
権限の問題が原因で発生する可能性のあるデプロイの問題を軽減するには、このセクションに記載されているベスト プラクティスに従ってください。
専用のサービス アカウントを使用する
セキュリティと制御を強化するため、デフォルトの Compute Engine サービス アカウントは使用しないでください。代わりに、AI Hypercomputer デプロイ専用のサービス アカウントを作成します。
必要な IAM ロールを付与する
作成した専用のサービス アカウントに次の IAM ロールを付与します。
- Compute 管理者（
roles/compute.admin）: Compute Engine リソースを完全に制御できます。 - サービス アカウント ユーザー（
roles/iam.serviceAccountUser）: サービス アカウントを他のリソースに接続できます。これは、カスタム イメージのビルド時に Packer などのツールで重要になります。 - ストレージ管理者（
roles/storage.admin）: Packer イメージやその他のアーティファクトの保存など、Cloud Storage バケットへのアクセスと管理が必要です。 - Logging 管理者（
roles/logging.admin）: サービス アカウントがロギングを構成してログを表示できるようにします。これはデバッグに不可欠です。
デプロイ前に権限を確認する
デプロイを開始する前に、サービス アカウントに必要な権限が付与されていることを確認します。gcloud projects get-iam-policy コマンドを実行します。
gcloud projects get-iam-policy PROJECT_ID \
--flatten="bindings[].members" \ format='table(bindings.role)' \
--filter="bindings.members:serviceAccount:SERVICE_ACCOUNT_EMAIL"
次のように置き換えます。
PROJECT_ID: 実際の Google Cloud プロジェクト ID。SERVICE_ACCOUNT_EMAIL: 検証するサービス アカウントのメールアドレス。
このコマンドは、指定されたプロジェクトのサービス アカウントに付与されているすべてのロールを一覧表示します。必要な IAM ロールを付与するに記載されているロールが出力に表示されていることを確認します。
公共ネットワークのアクセスを制限し、ファイアウォールの構成を強化する
公共ネットワークのアクセスを制限し、ファイアウォール構成を強化してセキュリティを強化します。この基本的なセキュリティ対策により、制限が緩すぎるデフォルトのファイアウォール ルールのリスクを軽減できます。
本番環境では、内部テストでは存在しない制限の厳しいファイアウォール構成が原因で、仮想マシン（VM）の設定エラーが発生することがあります。特定のファイアウォール ルールに関する知識がないと、エンジニアはこれらの障害の診断に苦労する可能性があります。
ファイアウォール ルールを確認して更新し、インターネットに直接公開するリソースを最小限に抑えます。VPC ファイアウォール ルールの詳細については、VPC ファイアウォール ルールをご覧ください。
内部ネットワーキングのデフォルトを標準化する
内部ネットワークのデフォルトを標準化して、リスクと構成の課題を軽減します。デフォルトのネットワーキング動作は、複雑な環境やセキュリティ強化された環境でリスクや構成上の課題を生み出す可能性があります。Google では、次の構成をおすすめします。
- ゾーン DNS を使用する: 新しいプロジェクトの場合、内部ドメイン ネーム システム（DNS）をゾーン DNS のみに設定します。このアプローチにより、グローバル DNS の停止による影響を軽減できます。ゾーン DNS の使用の詳細については、ゾーン DNS の使用の概要をご覧ください。
- 外部 IP アドレスを無効にする: 可能な場合は、外部 IP アドレスを無効にします。IP アドレスを無効にする前に、ステージング環境で慎重に計画してテストする必要があります。これは、マネージド インスタンス グループ（MIG）やパブリック ノードを含む GKE クラスタなど、一部のサービスが IP アドレスに依存しているためです。パブリック IP アドレスの制限の詳細については、Google Cloud でのパブリック IP アドレスの制限をご覧ください。
ベスト プラクティスの概要
次の表に、このドキュメントで推奨するベスト プラクティスをまとめます。
| トピック | タスク |
|---|---|
| IAM | 明確で制限された IAM ロールを確立する |
| ファイアウォール | 公共ネットワークのアクセスを制限し、ファイアウォール構成を強化する |
| ネットワークのデフォルト | 内部ネットワーキングのデフォルトを標準化する |
次のステップ
- サービス アカウントの使用に関するベスト プラクティスについて学習する。
- VPC ファイアウォール ルールの詳細を確認する。
- AI Hypercomputer ネットワーク アーキテクチャの詳細を確認する。