プレイブック

マイクロサービスには、同期的なリクエスト/レスポンスと非同期的なイベント駆動型通信の両方が必要です。

→同期呼び出しにはgRPCまたはHTTPを使用します。非同期イベント処理とファンアウトにはPub/Subを使用します。

理由: Pub/Subは、信頼性と独立したスケーリングのためにサービスを完全に疎結合します。直接呼び出しは、低遅延の同期レスポンスを提供します。

リファレンス↗

ステートレスなコンピューティングサービス（Cloud Run、Cloud Functions）で一時ファイルを処理する必要があります。

→すべての一時ファイルI/OにはCloud Storageを使用します。

理由: サーバーレスプラットフォームのローカルファイルシステムは、一時的でインメモリであり、共有されません。Cloud Storageは、すべてのインスタンスからアクセス可能な耐久性のあるスケーラブルなストレージを提供します。

12-factor原則に従い、GKEワークロードの環境固有の設定とシークレットを管理します。

→機密性の低い設定にはK8s ConfigMapsを使用します。機密性の高い値にはSecret Managerを使用し、Workload Identityを介して安全にアクセスします。

理由: Secret Managerは、K8s Secretsよりも安全で管理が容易、かつ監査可能なソリューションです。Workload Identityは、サービスアカウントキーの管理と配布を不要にします。

リファレンス↗

アプリケーションには極端なトラフィックピークがあるものの、コストを最小限に抑える必要がある長いアイドル期間があります。

→`min-instances`を0に設定したCloud Runを使用します。

理由: Cloud Runはゼロまでスケールダウンでき、アイドル期間中のコンピューティングコストをすべて排除します。GKEおよびCompute Engineは、最小限の実行中のノード/インスタンスを必要とします。

アプリケーションコードを変更せずに、マイクロサービス全体でリトライ、サーキットブレーカー、およびmTLSを一貫して実装します。

→GKEにサービスメッシュ（Anthos Service Mesh）をデプロイします。

理由: サービスメッシュは、プラットフォームレベルで回復性、セキュリティ、および可観測性を注入し、アプリケーションコードをクリーンに保ち、一貫した動作を保証します。

レート制限、APIキー、および使用状況分析を備えたバックエンドサービスを外部パートナーまたはモバイルアプリに公開します。

→バックエンドサービス（例：Cloud Run、GKE）の前にAPI Gatewayを使用します。

理由: API Gatewayは、APIライフサイクルに関する懸念（セキュリティ、監視、バージョン管理）に対してフルマネージドソリューションを提供し、バックエンドサービスからそれらをオフロードします。

リファレンス↗

イベントの追記専用ログのために、耐久性があり、スケーラブルで、強力な整合性を持つストアを選択します。

→イベントストアにはCloud Spannerを使用します。

理由: Spannerは、強力なグローバル整合性を持つ水平スケーラビリティを提供し、大規模なイベントログの整合性を維持するために不可欠です。

長時間実行されるジョブのAPIは、バックグラウンドで処理が続行されている間、すぐに応答する必要があります。

→APIエンドポイントは、Pub/SubまたはCloud Tasksにタスクをキューに入れ、ジョブIDとともに202 Acceptedを返します。別のワーカー（Cloud Run、Cloud Function）がタスクを処理します。

理由: これにより、ユーザー向けの応答時間とバックエンド処理時間を分離し、UXとシステム信頼性を向上させます。ステータス更新にはCloud Storageを使用します。

共有データベースなしで、複数のマイクロサービス間でデータの一貫性を維持します。

→オーケストレーター（Cloud Workflows）またはコレオグラフィー（Pub/Subイベント）と補償トランザクションを使用してSagaパターンを実装します。

理由: 複雑でロックが発生しやすい二相コミットを回避し、分散システムにより適した結果整合性を優先します。

データが頻繁に変更されない、レート制限されたサードパーティAPIをアプリケーションが呼び出します。

→分散キャッシュとしてMemorystore for Redisを使用します。TTLを持つキャッシュアサイドパターンを実装します。キャッシュスタンプを防止するために分散ロック（例：Redis SETNX）を使用します。

理由: 分散キャッシュはすべてのアプリケーションインスタンス間でデータを共有し、外部APIへの呼び出しを劇的に削減し、レイテンシを改善し、レート制限を尊重します。

開発チームは、プライベートVPCリソースへのアクセス権を持つ、一貫性のある事前構成済みの安全な開発環境を必要としています。

→Cloud Workstationsを使用します。

理由: Cloud Workstationsは、統合されたセキュリティとVPCアクセスを備えたマネージド型のコンテナベース開発環境を提供し、「私のマシンでは動作する」問題を解決します。

リファレンス↗

SaaSアプリケーションでは、テナントが完全に分離されたデータ、暗号化キー、およびデータレジデンシーを持つ必要があります。

→テナントごとにプロジェクトモデルを使用します。IaC（Terraform）を使用してプロビジョニングと構成を一元的に管理します。

理由: IAM、課金、クォータ、ネットワーク、データロケーションに対して最高レベルの分離を提供し、エンタープライズまたは規制対象の顧客にしばしば必要とされます。

公式パイプラインからの信頼できるスキャン済みのコンテナイメージのみが本番環境にデプロイされるように強制します。

→SLSAプロベナンスを生成するためにCloud Buildを、脆弱性スキャンにはArtifact Registryを、アテステーションに基づいてデプロイポリシーを強制するにはBinary Authorizationを使用します。

理由: コードからデプロイメントまで、検証可能で迂回不可能な暗号化された信頼の連鎖を作成し、侵害されたアーティファクトやスキャンされていないアーティファクトのデプロイを防ぎます。

リファレンス↗

Cloud Runサービスの新しいバージョンをデプロイし、ユーザーへの影響なしにテストし、トラフィックを即座に切り替えます。

→新しいリビジョンを`--no-traffic`でデプロイします。一意のリビジョンURLまたはリビジョンタグを使用してテストします。検証後、トラフィックの100%を新しいリビジョンに切り替えます。

理由: Cloud Runのネイティブトラフィック管理により、新しいバージョンが本番トラフィックを受信する前に検証することで、安全でダウンタイムなしのデプロイメントが可能になります。

新しいバージョンを段階的にロールアウトし、メトリクスを自動的に分析し、障害発生時にロールバックします。

→カナリアデプロイ戦略でCloud Deployを使用します。Cloud Monitoringと統合して、自動メトリクス分析とロールバックトリガーを実現します。

理由: Cloud Deployは、メトリクス分析や安全チェックを含むプログレッシブデリバリーワークフロー全体を自動化し、手作業とリスクを軽減します。

コードを重複させずに、開発、ステージング、および本番環境のKubernetesマニフェストを管理します。

→KustomizeまたはHelmを使用します。基本構成を定義し、環境固有のオーバーレイまたは値ファイルを作成して違いをパッチします。

理由: DRY原則に従い、構成管理を容易にし、環境のドリフトのリスクを低減します。

より高速なデプロイメントとより小さいアタックサーフェスのために、コンテナイメージサイズを削減します。

→マルチステージビルドを使用します。`build`ステージでは完全なSDK/JDKイメージを使用し、最終ステージではコンパイルされたアーティファクトのみを最小限の`distroless`ベースイメージにコピーします。

理由: 最終イメージには、アプリケーションとそのランタイム依存関係のみが含まれ、すべてのビルドツール、シェル、およびパッケージマネージャーが削除されます。

マージ前に検証するために、各プルリクエストに対して一時的な環境を自動的にデプロイします。

→PRイベントでCloud Buildトリガーを使用して、リビジョンタグ（例：`pr-123`）付きでCloud Runにデプロイします。PRクローズ時に別のトリガーを使用して、タグ付きリビジョンをクリーンアップします。

理由: リビジョンタグは、新しいサービスを作成するオーバーヘッドなしに、各PRに一意の一時URLを提供し、費用対効果が高く自動化も容易です。

公開ソフトウェア依存関係（例：npm、Maven Central）をキャッシュすることで、CI/CDビルド速度と信頼性を向上させます。

→パブリックリポジトリのプルスルーキャッシュとして機能するArtifact Registryのリモートリポジトリを使用します。

理由: ビルドパフォーマンスを向上させ、パブリックレジストリの停止からビルドを保護し、キャッシュされたアーティファクトの脆弱性スキャンを可能にします。

並行するCI/CDパイプライン実行のためにTerraformステートを安全に保存し、ロックします。

→TerraformステートのバックエンドとしてCloud Storageを使用し、Cloud Buildサービスアカウントに適切なIAMを設定します。

理由: Cloud Storageは、耐久性があり、バージョン管理され、ロック可能なバックエンドを提供し、並行ビルドによるステートの破損を防ぎます。

Cloud RunまたはCloud FunctionがプライベートVPCネットワーク上のリソース（例：Cloud SQL、Memorystore）にアクセスする必要があります。

→Serverless VPC Accessコネクタを構成します。

理由: コネクタはネットワークブリッジとして機能し、サーバーレス環境からのエグレス（送信）トラフィックをターゲットVPCにルーティングし、リソースを公開することなくアクセスさせます。

リファレンス↗

GKE上のステートフルアプリケーションには、安定したIDとPod/ノードの障害後も存続する永続ストレージが必要です。

→IDにはHeadless Serviceを備えたStatefulSetを使用します。ストレージにはリージョナルPersistent Diskを備えたPersistentVolumeClaim（PVC）を使用します。

理由: これはステートフルワークロードのための規範的なKubernetesパターンであり、データの永続性、高可用性、および予測可能なPodの命名/ネットワークを保証します。

GKE上のPodが、静的なサービスアカウントキーを管理せずにGCP APIに安全にアクセスする必要があります。

→Workload Identityを構成して使用します。

理由: Workload Identityは、KubernetesサービスアカウントをGoogleサービスアカウントにバインドし、Podがメタデータサーバーから取得した短期間のGCP認証情報を使用できるようにします。

完了に数時間かかるバッチジョブ（例：大規模ファイルの処理、夜間データ集計）を実行します。

→EventarcまたはCloud SchedulerによってトリガーされるCloud Runジョブを使用します。

理由: Cloud Runジョブは、長時間実行（最大24時間）タスク向けに設計されており、ゼロにスケールダウンでき、バッチワークロードのために専用のGKEクラスタやVMを使用するよりも費用対効果が高く、シンプルです。

Cloud Runで、メインコンテナがロギング、メトリクス、またはプロキシとしてサイドカーを必要とするマルチコンテナアプリケーションをデプロイします。

→Cloud Runサービスを、メインコンテナとして1つ、サイドカーとして他の複数のコンテナイメージを指定してデプロイします。

理由: Cloud Runのネイティブマルチコンテナサポートにより、GKEの複雑さなしにサーバーレスワークロード向けのサイドカーパターンが可能になります。

新しいCloud Runリビジョンがトラフィックを受信する前に、データベース移行が完了している必要があります。

→コンテナ起動中に移行を実行し、移行が成功した後にのみパスするCloud Runスタートアッププローブを使用します。

理由: スタートアッププローブは、コンテナが完全に準備できるまでトラフィックルーティングを遅延させ、リクエストが処理される前にデータベーススキーマが正しいことを保証します。

GKEアプリケーションが、CPU/メモリだけでなく、Pub/Subからのキューの深さのようなカスタムメトリックに基づいてスケールする必要があります。

→Cloud Monitoringからカスタムメトリックを読み取るように構成されたHorizontal Pod Autoscaler (HPA)を使用します。

理由: これにより、ビジネスロジックやアプリケーション固有の負荷インジケータによってオートスケーリングを駆動でき、一般的なリソースメトリックよりも正確なスケーリングが提供されます。

メッセージ駆動型サービスは、再試行や重複配信の可能性にもかかわらず、各メッセージを正確に一度だけ処理する必要があります。

→Pub/Sub（少なくとも一度、または厳密に一度の配信）を冪等なコンシューマと組み合わせます。コンシューマは、処理されたメッセージIDを永続ストア（例：Firestore、Memorystore）で追跡します。

理由: Pub/Subは配信を保証しますが、アプリケーションレベルの再試行を処理し、真の厳密に一度の処理を実現するためには、コンシューマが冪等性を担う必要があります。

同じエンティティ（例：特定のユーザー）に関連するイベントは、生成された順序で処理される必要があります。

→`orderingKey`を付けてPub/Subにメッセージを公開します。サブスクリプションでメッセージの順序付けを有効にします。

理由: Pub/Subは、同じ順序キーを持つメッセージが順序通りに配信されることを保証し、異なるキーを持つメッセージはスケーラビリティのために並行して処理できます。

リファレンス↗

複数のトリガーイベントが到着した場合でも、タスク（例：日次ユーザーレポートの生成）が一度だけ実行されるようにします。

→Cloud Tasksを使用します。明示的な名前（例：`report-userX-2024-10-26`）でタスクを作成します。Cloud Tasksは、既存の名前を持つタスクを作成するリクエストを重複排除します。

理由: これにより、重複排除ロジックをキューイングサービスにオフロードし、アプリケーションコードを簡素化し、冗長な作業を防ぎます。

Pub/Subメッセージが複数回の再試行後も処理に失敗し続け、キューをブロックしています。

→Pub/Subサブスクリプションにデッドレタートピック（DLQ）を構成し、最大配信試行回数を設定します。

理由: Pub/Subは「ポイズン」メッセージを自動的にDLQに移動させ、他のメッセージが処理されるのを可能にし、失敗したメッセージを分析のために保持します。

ビジネスプロセスに、条件ロジック、エラー処理、および長時間待機を伴う一連のサービス呼び出しが含まれます。

→オーケストレーションロジックを定義および実行するためにCloud Workflowsを使用します。

理由: Cloud Workflowsは、状態、再試行、および長時間待機を管理するサーバーレスオーケストレーターであり、手動で連鎖させた関数よりも優れた信頼性と可視性を提供します。

リファレンス↗

Cloud FunctionまたはCloud Runサービスは、特定のクラウドイベント（例：Cloud Storage内の特定のファイルタイプ）によってのみトリガーされるべきです。

→イベント属性にCEL (Common Expression Language) フィルタリングを使用するEventarcトリガーを使用します。

理由: サービスが呼び出される前にフィルタリングが行われるため、関連性のないイベントを処理しないことでコストとコンピューティングサイクルを節約します。

Cloud Runのような水平スケーリングされたサービスからサードパーティAPIへの送信呼び出しをレート制限します。

→`rateLimits`を構成した（例：1秒あたりの最大ディスパッチ数）Cloud TasksキューにAPI呼び出しをタスクとしてキューイングします。

理由: Cloud Tasksは、複雑な分散カウンタを必要とせずに、すべてのスケールされたインスタンスで機能する集中型のサーバーレスレート制限を提供します。

2つのCloud Run（またはCloud Functions）サービス間の呼び出しを安全に認証します。

→呼び出し元サービスのサービスアカウントに、呼び出し先サービスに対する`roles/run.invoker` IAMロールを付与します。呼び出し元は、Googleが署名したIDトークンをリクエストとともに送信します。

理由: これは、GoogleのIDインフラストラクチャを活用した、サービス間認証のためのネイティブで安全、かつキーレスな方法です。

イベント駆動型サービスが、Cloud SQLデータベースの行レベルの変更にほぼリアルタイムで反応する必要があります。

→Datastream (CDC) を使用してデータベースの変更をPub/Subにストリームします。Eventarcを使用して、Pub/SubトピックからCloud Runサービスをトリガーします。

理由: これは、データベースのポーリングを回避し、データベースに書き込むアプリケーションを変更する必要がない、疎結合で信頼性の高いパターンです。

長時間実行されるビジネスプロセスが、メールの承認リンクをクリックするなどの外部イベントを待機するために一時停止する必要があります。

→コールバックエンドポイントを持つCloud Workflowsを使用します。ワークフローは、一意のコールバックURLでHTTPリクエストを受信するまで（最長1年間）一時停止します。

理由: コールバックにより、ワークフローはコンピューティングリソースを消費することなく外部イベントを待機できるため、長時間実行されるヒューマンインザループプロセスに最適です。

レイテンシに敏感なサーバーレスアプリケーションが、アイドル期間後に初期応答が遅くなる現象を経験します。

→`min-instances`を1以上に構成します。避けられないコールドスタートの場合、`startup-cpu-boost`を使用します。また、アプリケーションを最適化します（より小さいイメージ、より高速な初期化）。

理由: `min-instances`はコールドスタートを排除する最も効果的な方法ですが、コストがかかります。`startup-cpu-boost`は起動プロセス自体を高速化します。

リファレンス↗

複数のマイクロサービス間でリクエストが遅延または失敗しており、ログや個々のサービスメトリクスからはボトルネックが明らかではありません。

→コンテキスト伝播を備えたCloud Traceを使用します。アプリケーションを計測してトレースヘッダー（例：W3C Trace Context）を転送します。

理由: Cloud Traceは、すべてのサービスにわたるリクエストライフサイクル全体のウォーターフォール視覚化を提供し、レイテンシやエラーの発生源を特定します。

リファレンス↗

本番環境でアプリケーションの実行が遅く、問題がCPUバウンド、メモリリーク、またはI/Oのいずれであるかが不明です。

→Cloud Profilerを使用して、本番環境でのCPUおよびヒープ使用量を継続的に分析します。

理由: Cloud Profilerは、テスト環境で問題を再現することなく、非常に低いオーバーヘッドでコードレベルのパフォーマンスボトルネック（ホットパス、メモリリーク）を特定します。

単純な閾値アラート（例：「レイテンシ > 500ms」）から、サービスレベル目標（SLO）に基づいたより意味のあるアラートに移行します。

→Cloud MonitoringでSLIとSLOを定義します。エラーバジェットの「バーンレート」に基づいてアラートポリシーを作成します。

理由: バーンレートアラートは、単純な閾値アラートよりも重要な変更に敏感で、ノイズが少なく、SLOを達成できない軌道に乗っていることを通知します。

複数のサービスからのアプリケーション例外を集約して頻度を追跡し、スタックトレースを確認し、新しいエラータイプが通知されるようにします。

→Cloud Error Reportingを使用します。

理由: Error Reportingは、構造化ログからの例外を自動的に取り込み、グループ化し、分析し、アプリケーションエラーを管理するための一元化されたダッシュボードを提供します。

カスタムビジネスメトリック（例：1分あたりの注文数、ユーザー登録数）を監視、可視化、およびアラートします。

→OpenTelemetry SDKを使用してアプリケーションコードを計測します。エクスポーターを構成して、メトリックをCloud Monitoringに送信します。

理由: これは、カスタム計測のための現代的でベンダーニュートラルな標準です。これにより、あらゆるメトリックを追跡し、Cloud Monitoringのすべての機能を活用できます。