hatakoya memo

GCP: Best Practice

GCP でシステム構築する上でのベストプラクティス。
Google Cloud Platform を使用する方法の内容をまとめたもの。

エンタープライズ企業

Ref:
エンタープライズ企業のベスト プラクティス

組織の設定

  • リソース階層を定義する

    • 組織の運用体制を GCP にマッピングし、関連リソースのグループに対するアクセスを制御できる。

  • 組織ノードを作成する

  • プロジェクト構造を指定する

    • 理想的なプロジェクト構成は要件によって異なる
    • 次の点について決める必要がある
      • リソースごとに請求を行う必要があるか
      • どの程度の分離が必要か
      • リソースとアプリを管理するチームをどのように構成するか

  • プロジェクトの作成を自動化する

    • 一貫した処理が可能になり、再現性を高め、テストが容易になる
    • ソフトウェアの成果物と一緒に構成のバージョニングやライフサイクル管理ができる
    • リソースに一貫した命名規則やラベル付けを適用するなど、ベストプラクティスを実現できる
    • 要件が変化してもプロジェクトのリファクタリングを簡単に行える
    • 構成管理ツールにはDeployment Managerを使用する
      • 再利用可能な構成要素として、パラメータ化されたテンプレートを定義可能
      • Cloud IAM を使用してアクセス制御権限を設定可能
    • すでに慣れているツールがある場合は Terraform などのツールも使用できる

ID とアクセスの管理

  • Google ID を管理する

    • GCP は認証とアクセス管理に Google アカウントを使用する
    • Cloud Identity を使用して、会社のドメインにフルマネージドの Google アカウントを関連付けることが推奨されている
      • 開発者が会社のメールアドレスを使用して GCP にアクセスできるようになる
      • 管理者は管理コンソールにアカウントを表示し、管理できるようになる
      • ドメインの組織ノードが作成され、リソース階層を使用して会社の組織体制を GCP リソースにマッピングし、管理できる
      • Cloud Identity に G Suite のライセンスは不要

  • ID プロバイダを GCP と連携させる

    • オンプレミスまたはサードパーティの ID とプロバイダを使用している場合は、ユーザーディレクトリを Cloud Identity と同期し、会社の認証情報を使用して GCP にアクセスできるようにする
      • ID プラットフォームを使用しながら、Cloud Identity で従業員による Google サービスへのアクセスを制御できる

  • 管理対象外のアカウントを移行する

    • 会社のメールアドレスを使用して個人の Google アカウントを作成している場合（YouTube などのサービスに登録した場合など）、これらのアカウントを移行し、Cloud Idnentity で管理できるようにすることを検討する
    • これらのアカウントが別のメールアドレスを使用するように強制的に変更することもできる

  • リソースへのアクセスを制御する

    • IAM を使用して、特定の GCP リソースに対するアクセス権を設定し、リソースへの不要なアクセスを防ぐ
    • 権限を直接割り当てるのではなく、役割を割り当てる
      • IAM の役割は権限のコレクション
        • ex) BigQuery データ閲覧者は、テーブルの一覧表示、読み取り、クエリの実行権限が含まれているが、テーブル作成やデータ変更権限は含まれていない
      • IAM には、一般的なユースケースに利用できる多くの役割が事前定義されている

  • グループとサービスアカウントを使用して業務を委任する

    • 同じ業務に携わるユーザーをグループにまとめ、IAM を個々のユーザーではなくグループに割り当てる
      • 新しいメンバーがチームに参加しっときは、グループに追加するだけで定義済みの権限を継承できる
    • サーバー間の通信にはサービスアカウントを使用する

企業の場合、次の 6 グループの作成がおすすめされている

グループ 説明
gcp-organization-admins 組織の管理者は、組織で使用するリソースの構造の編成を担当します。
gcp-network-admins ネットワーク管理者は、ネットワーク、サブネット、ファイアウォール ルール、およびクラウドルーター、クラウド VPN、クラウド ロードバランサなどのネットワーク デバイスの作成を担当します。
gcp-security-admins セキュリティ管理者は、アクセス管理や組織の制約ポリシーなどの組織全体のセキュリティ ポリシーの確立と管理を担当します。
gcp-billing-admins 請求管理者は、請求先アカウントの設定とその使用状況の監視を担当します。
gcp-devops DevOps 従事者は、継続的インテグレーション、継続的デリバリー、モニタリング、システム プロビジョニングをサポートするエンドツーエンドのパイプラインを作成または管理します。
gcp-developers デベロッパーはアプリケーションの設計、コーディング、テストを担当します。
  • 組織ポリシーを定義する
    • 特定のリソースに制限を設定し、どのような構成と使用方法が可能であるかを決定する
      • ex) 仮想マシンインスタンスに外部 IP アドレスが割り当てられないように制限する
    • ポリシーはすべての子孫に継承される
      • 継承されたポリシーを上書きする場合は子ノードにカスタム組織ポリシーを設定する

Ref: エンタープライズのお客様向けのポリシー設計

ネットワーキングとセキュリティ

  • VPC を使用してネットワークを定義する
    • インターネットを経由することなく、単一の VPC で複数リージョンにまたがる通信を実現できる
    • VPC はグローバルリソース
    • VPC サブネットはリージョンリソース
    • 1 つのサブネットは 1 つのリージョンに明示的に関連付けられている

Ref:
Virtual Private Cloud（VPC）ネットワークの概要

  • ファイアウォールルールでトラフィックを管理する 　- GKE を利用している場合は別の注意事項がある 　- Ref: GKE ネットワーキングのコンセプト

  • 外部アクセスを制御する

    • ファイアウォールルールで拒否されない限り、VPC 内のリソースは内部 IP アドレスで通信できる
    • インターネットと通信するには次の方法を利用する
      • リソースに外部 IP を割り当てる
      • Cloud NAT を使用する
    • VPN で接続していない限り、同じ VPC にないリソースへ接続するには外部 IP が必要
    • インターネットへのアクセスは、必要なリソースにのみ許可する

  • ネットワーク制御を一元管理する

    • 共有 VPC を使用すると内部 IP を使用してプロジェクト間の安全な通信ができる
    • 共有 VPC と IAM を使用して、ネットワーク管理とプロジェクト管理を切り分ける

  • 企業ネットワークを接続する

    • 帯域幅、レイテンシ、SLA 要件を検討して最適な接続方法を選択する
    • インターネットを経由せずに低レイテンシで高可用性のエンタープライズレベルの接続が必要な場合は Cloud Interconnect を使用する
      • Dedicated Interconnect は、物理的にオンプレミスネットワークと Google ネットワークを接続する
      • Partner Interconnect は、サポート対象のサービスプロバイダを介してオンプレミスネットワークと GCP VPC ネットワークを接続する
    • Cloud Interconnect の低レイテンシと高可用性を必要としない場合や、クラウドへの移行を始めたばかりの場合は、Cloud VPN を使用してオンプレミスネットワークと VPC 間に暗号化された IPsec VPN トンネルを設定する

  • アプリとデータを保護する

    • ファイアウォールルールと VPC の分離に加えて、次のツールを使用する
      • VPC Service Controls
        • VPC 内のデータを制限してデータ引き出しのリスクを軽減する
      • HTTP(S)ロードバランサ
        • インターネットに接続するサービスの高可用性とスケーリング
      • Cloud Armor
        • HTTP(S)ロードバランサと統合して、DDos 対策と、ネットワークエッジで IP アドレスをブラックリストおよびホワイトリストに登録する
      • Cloud Identity-Aware Proxy(Cloud IAP)
        • アプリへのアクセスを制御する

ロギング、モニタリング、オペレーション

  • ロギングとモニタリングを一元管理する

    • StackDriver で一元管理する
    • Logging エージェントとインストールすれば StackDriver にログを転送できる

  • 監査証跡を設定する

    • 開発者がどのように GCP リソースを使用しているか追跡し、トレース情報を維持する
    • Cloud Audit Logging を使用して「誰が、何を、どこで、いつ行ったか」の情報を残す
    • IAM を使用して監査ログの表示権限を持つユーザを制限する

Ref:
Cloud Audit Logging
監査ログ付きの Google サービス

  • ログをエクスポートする
    • 法令遵守のために長期保存する場合は Cloud Storage を使用する
    • ログの分析には BigQuery を使用する
    • フィルタを使用して、不要なログを除外する
    • ログは Cloud Storage、BigQuery、Cloud Pub/Sub にエクスポートできる

Ref:
Stackdriver Logging のエクスポートのための設計パターン

  • DevOps とサイト信頼性エンジニアリングを採用する

Ref:
DevOps ソリューション

クラウドアーキテクチャ

  • 移行を計画する

  • マネージドサービスを使用する

    • TCO（総所有コスト）を抑える

  • 高可用性を設計する

    • HTTP(S)ロードバランサで異なるリージョン間で負荷分散する
      • ゾーンまたはリージョンが使用不能になっても他のゾーンにトラフィックを転送できる
    • 特定のゾーンの障害から保護するため、VM や GKE クラスタなどをリージョン内のゾーン全体に分散する

  • 障害復旧戦略を計画する

Ref:
障害復旧計画ガイド

請求と管理

  • リソースの課金方法を理解する

Ref:
GCP の料金

  • 請求管理を設定する

    • 請求先アカウントを使用して、一連のプロジェクトのリソース使用量の支払い者を定義する

  • 請求書を分析してエクスポートする

    • CSV または JSON ファイルにエクスポートして Cloud Storage に保存する
    • BigQuery へのエクスポートを構成する（推奨）
      • SQL でデータを分析できる
    • リソースに適用されているラベルもエクスポートされる

  • 容量要件を計画する

    • 割り当てを設定して、予期しない使用量の急増を防ぐ
      • あるプロジェクトが特定のリージョンやゾーンの CPU コアを専有しないように制限できる

  • 費用管理を行う

    • 予算を定義して、特定のしきい値に達したときにメールでアラートを送信する
    • プログラムで通知する場合は、Pub/Sub メッセージを生成できる
    • 割り当てを使用して特定のリソースの使用量を制限する
      • ex) BigQuery API に、「1 日あたりのクエリ使用量」を設定

  • サポートパッケージを購入する

  • エキスパートのヘルプを利用する

  • センターオブエクセレンスを構築する

VPC 設計

VPC 設計のためのおすすめの方法とリファレンスアーキテクチャ

← GCP: Big Query →