ネットワーキングのベスト プラクティス

このドキュメントでは、AI Hypercomputer ワークロードの安全で復元性に優れたネットワーキング環境を作成するためのベスト プラクティスについて説明します。これらの推奨事項は、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 command コマンドを実行します。

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 アドレスの制限をご覧ください。

ベスト プラクティスの概要

次の表に、このドキュメントで推奨するベスト プラクティスをまとめます。

次のステップ

• サービス アカウントの使用に関する ベスト プラクティス の詳細を確認する。
• VPC ファイアウォール ルールの詳細を確認する。
• AI Hypercomputer ネットワーク アーキテクチャの詳細を確認する。