GCP設計指針

Google Cloud でアーキテクチャを設計する際のポイントなど をまとめる。 の気になる点を列挙する

セキュリティ

基本的にはこのガイドラインに従えば良さそう。

• Google Cloud 側のコンプライアンス対応状況
  • Cloud コンプライアンスと規制に関するリソース  |  Google Cloud

用語

• ゼロトラスト
  • 複雑で相互接続されたシステムの単一コンポーネントに対する盲目的な信頼は、重大なセキュリティ リスクをまねく可能性があるという考え
    • 認証機能の強化(MFAなど)、最小限のアクセス権、複数のセキュリティ施策などで実現する
• BeyondCorp
  • Googleが考えた、VPNの代わりにアクセスプロクシによる安全な通信、デバイスインベントリーシステムによる端末の管理、アクセスコントロールによるゼロトラスト運用
• BeyondProd
  • BeyondCorpの考えを本番環境にも適用し、ユーザーが安全にサービスを利用できるようにする仕組み

参照

• Cloud セキュリティ ベスト プラクティス センター  |  Google Cloud

ぼやき

BeyondCorpとBeyondProdが結局よくわからんな🤔

リソース階層

• ガイドラインに沿ってリソース階層を設計する。
  • GCPで組織の設定をしようとすると「基盤の設定」というウィザードが表示されるのでウィザード通りに操作するとガイドラインに沿ったリソース階層になる
  • これによってGoogle Cloud 設定のチェックリスト  |  ドキュメントも網羅できている
• Workspaceの特権管理者はWorkspaceのリソース（カレンダー・グループなど）にはフルアクセスできるが、GCPのリソースと直接の関係はない

ネットワーク

• VMに外部IPを持たせずCloudNATで外部にアクセスする

ログ

• ログ用プロジェクトとLogging Bucketを作り、各プロジェクトのログルーターのシンクを作成したバケットに向ける
  • 各プロジェクトのログルーターではなく組織・フォルダのログルーターのシンクを使って一括で設定しても良いかも
• Logging Agentを利用して標準出力を含む全ログをCloud Loggingに集約する
• GKEのログをCloud Loggingに送る場合はクラスタレベルでログ出力を有効にする（DaemonSetsにfluentdがデプロイされる）

監査ログ

• 監査ログが必要なGCPのサービス（例えばMySQLのデータ読み書きは監査ログとして記録する場合）は監査ログの設定で「管理読み込み・書き込み」「データ読み込み・書き込み」に任意のチェックを入れる。これによりCloud Loggingに監査ログが記録される。
• 監査ログの種類と記録タイミング (*は常に有効400日保持・課金対象外、**はデフォルト有効)
  • Admin Activity audit logs*: リソースの管理・メタ情報の呼び出し・変更
  • Data Access audit logs: 上記に加えてデータのCRUDなど
  • System Event audit logs*: Googleがリソースを操作する
  • Policy Denied audit logs**: ポリシー違反によってアクセスを拒否
• 全てのサービスで全ての監査ログが記録されるわけではない → 監査ログ付きの Google サービス  |  Cloud Logging  |  Google Cloud

ぼやき

• システムイベントとポリシー拒否のログほとんど記録されないじゃん

モニタリング

• モニタリング用プロジェクトにダッシュボードを作り、各プロジェクトのメトリクスを表示する

分散トレーシング、プロファイリング

• Cloud Trace を使うとパフォーマンスにあまり影響を与えず（本番環境で使っても問題ない）にリクエスト全体のトレースができる
• Cloud Profiler を使うとパフォーマンスにあまり影響を与えず（本番環境で使っても問題ない）にパフォーマンスのボトルネック調査ができる

バグ調査

• Error Reporting を使うと、Sentry他のエラーレポートツールを使わずにエラーログ収集ができる。フロントエンドのエラーログ収集はできない（Experimentalで数年前から止まってる）
• Cloud Debugger を使うと、本番で動いているコードにブレークポイントのような形でその行実行時点の変数スナップショットを取れる。本番で動作しているコードの任意の行にログ出力を足すこともできる。

Compute Engine

• サービスアカウントを作成して割り当てる

バックアップ

• ゾーン/リージョン永続ディスクのスナップショットを定期的に作成（差分更新）する
  • スナップショットはグローバルリソース
  • スナップショットを元に別のプロジェクトにディスクを作成できる
  • スナップショットからディスクを作ることも、スナップショットからインスタンスを作ることもできる
• スナップショット前にできれば fstrim コマンドを実行して容量削減・スナップショット速度向上を図る

障害対応

• システムやハードウェア障害: 永続ディスクとスタートアップスクリプト
• ゾーンやリージョン障害: マネージメントインスタンスグループのマルチゾーン展開、ロードバランサによるマルチリージョン負荷分散
• インフラのパッチ当て: ライブマイグレーション

App Engine

Kubernetes Engine

Cloud Run

• 負荷分散を細かく制御する場合はサーバーレス ネットワーク エンドポイント グループを使ってHTTP(S)ロードバランサに接続する。

コストと請求

• プロジェクト作成時に予算アラートを設定する
• 組織の請求アカウントは一つに集約する
  • Cloud Billing リソースの組織化とアクセス管理  |  Google Cloud
• 請求アカウント作成時にすぐにBigQueryエクスポートを有効にする（過去に遡って課金情報を出力できないため）