0. はじめに
前回はAI・機械学習系のサービスをまとめました。今回はその第9弾、そしてこのシリーズの最終回として、デベロッパーツール系のサービスを見ていきます。
ここまでコンピューティング・ストレージ・データベース・ネットワーク・セキュリティ・データ分析・コスト管理・AI/機械学習と見てきましたが、最後はCI/CDや日常的なクラウド操作を支えるサービスで締めくくります。
1. デベロッパーツール
| カテゴリ | AWS | Google Cloud |
|---|---|---|
| ビルド/テスト自動化 (CI) | CodeBuild | Cloud Build |
| 継続的デリバリー (CD) | CodePipeline / CodeDeploy | Cloud Deploy |
| コンテナ/パッケージレジストリ | ECR / CodeArtifact | Artifact Registry |
| マネージドGitリポジトリ | CodeCommit | Cloud Source Repositories |
| CLIツール | AWS CLI | gcloud CLI |
| コンテナ脆弱性スキャン・SBOM生成 | Amazon Inspector | Artifact Analysis |
| デプロイ時の署名検証・ポリシー適用 | - | Binary Authorization |
| モバイルアプリの実機/仮想デバイステスト | Device Farm | Firebase Test Lab |
| SaaSアプリ統合(iPaaS) | Amazon AppFlow | Application Integration |
| APIゲートウェイ・API管理 | API Gateway | Apigee |
| 事前承認済みアーキテクチャのセルフサービス提供 | AWS Service Catalog | Service Catalog |
1-1. Cloud Build
CodeBuildに相当する、ビルド、テスト、コンテナイメージ作成を実行できるサーバーレスのフルマネージドなCIプラットフォームです。
- ソースコードの変更をトリガーに、コンテナイメージの作成やArtifact Registryへの格納を自動化します。
- 速度を落とさないセキュリティの組み込み(シフトレフト): リリース速度と俊敏性を重視しつつセキュリティ上のミスの混入を減らしたい場合は、人手のピアレビューを全件必須にするのではなく、CI/CDパイプラインにソースコードのセキュリティアナライザー(コーディング段階の脆弱性検出)と脆弱性セキュリティスキャナー(ビルド成果物の既知の脆弱性検出、後述のArtifact Analysis)を自動組み込みします。
- GitHubリポジトリとの安全な連携: プルリクエストのマージを契機に自動ビルド・自動デプロイしたい場合は、Cloud Build GitHubアプリでリポジトリを接続しトリガーを作成します。認証がマネージドに処理されるため、サービスアカウントキーのソースコードへのチェックイン(認証情報漏洩の典型的な原因)やwebhookのシークレット管理が不要になります。
-
静的キー禁止と本番適用権限の分離(Terraformガバナンス): 開発者には変更提案(プルリクエスト)のみを許可し、本番プロジェクトへの直接適用権限は持たせたくない場合の構成です。プルリクエストのマージをトリガーにCloud Buildが
terraform applyを自動実行し、Cloud Build側ではサービスアカウントの権限借用を使うことで、長期有効な静的サービスアカウントキーも排除できます。 - アプリとDBスキーマのデプロイ分離による即時ロールバック: 失敗したデプロイを最後の正常な状態へ即座に戻せるようにしたい場合、データベーススキーマ移行のCI/CDパイプラインをアプリケーションデプロイから分離し、スキーマは後方互換を保って先行適用します。アプリ側はCloud Run等のリビジョン機能で段階的なトラフィック分割によるリリースを行い、問題発生時はトラフィックを旧リビジョンへ戻すだけで復旧できます。
これまでの記事でも何度か「その用途はCloud Build」と登場してきましたが、App EngineのビルドやCloud Run functionsのソースデプロイなど、裏側で他の複数サービスから利用されている点はAWSのCodeBuildと似た位置づけです。
1-2. Cloud Deploy
CodePipeline/CodeDeployに相当する、GKEやCloud Runへのアプリケーションを継続的にデリバリーするマネージドサービスです。
- dev→staging→prodのような昇格順序(プロモーションシーケンス)をYAMLで定義し、ターゲットごとに承認ゲートを設定できます。本番ターゲットの昇格にだけ承認ゲートを設ければ、CI(ビルド・テスト)は自動化しつつ本番反映だけ人手のレビューを挟む、といった構成が組めます。
- ビルドやテスト自体は担当せず(その用途はCloud Build)、Artifact Registryに格納済みのコンテナイメージをデプロイするプロセスに特化しています。
- プライベートGKEクラスタへの配信: プライベートエンドポイントのみを持つGKEクラスタへのデプロイが失敗する場合、GKEクラスタと同じVPCネットワークとピアリングされたCloud Buildプライベートプールを作成し、それをパイプラインの実行環境として指定します(Google管理のデフォルトワーカープールは対象VPCへの到達経路がありません)。
1-3. Artifact Registry
ECR/CodeArtifactに相当する、コンテナイメージや言語パッケージ(Maven, npm等)を保存・管理するためのフルマネージドなレジストリです。
- CI/CDパイプラインにおける成果物の保管場所として機能し、Cloud Run等へのデプロイに利用されます。
-
前身のContainer Registry: Artifact Registry登場前はContainer Registryというコンテナ専用レジストリ(内部的にはCloud Storageバケット)がありました。別プロジェクトのContainer Registryからイメージをプルしたい場合は、GKEノードのサービスアカウントに、イメージが保存されているプロジェクト側でStorage Object Viewer(
roles/storage.objectViewer)ロールを付与します。
1-4. Cloud Source Repositories
AWS CodeCommitに相当する、Google Cloud上でホストされるプライベートGitリポジトリです。
- IaCテンプレートなどをGitでバージョン管理し、差分レビューや共同作業を行えます。
- 注意: 2024年6月17日付でCloud Source Repositoriesは新規顧客への提供を終了しており、それ以前に利用実績のない組織や、組織に未接続の新規プロジェクトではAPIを有効化できません。これから新規にGitホスティングを選定する場合は、Cloud Buildと連携可能な外部のGitホスティング(GitHub、GitLab等)や、後継のSecure Source Managerを検討するのが現実的です。
1-5. gcloud CLI の基本操作
AWS CLIに相当する、Google Cloudリソースをコマンドラインで操作するためのCLIツールです。各サービスの操作で共通して使う場面が多いため、シリーズの締めくくりとしてここでまとめて扱います。
-
gcloud auth loginでブラウザ経由のOAuth 2.0フローによりログイン認証を行います。サービスアカウントキーで認証する場合はgcloud auth activate-service-account --key-file=<パス>を使います。 -
gcloud config set project $my_projectでデフォルトプロジェクトを設定すると、以降のコマンドで--projectフラグの指定が不要になります。 -
複数プロジェクトの切り替え:
gcloud config configurations createで、プロジェクト・認証アカウント・リージョン等をまとめた名前付き「構成」を作成できます。切り替えはgcloud config configurations activate <構成名>だけで完了します。 -
GKEクラスタのデフォルト化:
gcloud config set container/cluster <クラスタ名>で、以降のgcloud container系コマンドのデフォルト対象を設定できます。 - 新しいサービスを初めて使う際は、対応するAPI(例: Compute Engineなら
compute.googleapis.com)をまず有効化する必要があります。 -
プロジェクト名からのAPI一覧取得: プロジェクト名(表示名)しかわかっていない場合、
gcloud services list --project <プロジェクトID>はID指定が必要なので、まずgcloud projects listでIDを確認してから実行します。
1-6. Artifact Analysis と Binary Authorization
ソフトウェアサプライチェーンを保護するための2サービスで、役割を「調べる」役と「通さない」役で分担します。Artifact AnalysisがAmazon Inspectorに相当し、Binary Authorizationには直接対応するAWSサービスがありません。
- Artifact Analysis(調べる役): Artifact Registryへのイメージpushを契機に、OS・言語パッケージの脆弱性スキャン、検証可能な**ビルド来歴(プロベナンス)の記録、依存関係のSBOM(ソフトウェア部品表)**生成までを一体で自動提供します。
- Binary Authorization(通さない役): 署名・証明された(attestationを持つ)イメージ以外のデプロイを拒否する、デプロイ時の適用ポリシーです。スキャンや来歴・SBOM生成の機能は持ちません。
- 上流と水際の二段構え: 脆弱性を本番へ到達させない包括的な戦略には、ビルド前の脆弱性スキャンとGoogleが保守するベースイメージの採用(上流で混入を防ぐ)、Artifact Analysisのスキャン結果をもとにBinary Authorizationで重大な脆弱性を持つイメージのデプロイを拒否する構成(水際で機械的に遮断)を組み合わせます。
- 構成証明(attestation)によるデプロイ検証の仕組み: ビルド・テスト・脆弱性スキャンなど各段階の合格時に、署名者(signer)(CIシステム等)がCloud KMS等の秘密鍵でイメージダイジェストに署名し、構成証明(attestation)を作成します。Artifact Analysisのノートに紐づく**アテスター(attestor)**は対応する公開鍵を保持するリソースで、デプロイ時にBinary Authorizationがこの公開鍵でattestationを検証し、未署名または改ざんされたイメージの実行を自動的にブロックします。この強制はGKE/Cloud Runのデプロイ時ポリシーとして適用されるため、CI/CDパイプラインの設定を迂回した未承認デプロイも阻止できます。
- ビルド来歴(プロベナンス)の標準規格(SLSA): ソフトウェアサプライチェーンの完全性を段階的に保証する業界標準フレームワークがSLSAです。Cloud BuildはSLSAレベル3のビルド来歴を自動生成し、Google Cloud ConsoleのSecurity insightsサイドパネルで確認できます。
- Cloud Runでの信頼イメージ強制: Cloud Runは各サービスでもBinary Authorizationを有効化でき、署名・証跡(attestation)を満たすイメージのみデプロイを許可できます。
-
組織全体での強制: サービス単位の設定漏れを防ぎたい場合は、組織ポリシー制約
constraints/run.allowedBinaryAuthorizationPoliciesで許可するBinary Authorizationポリシー名を指定し、全Cloud Runサービスへの適用を強制します(Compute Engine向けのconstraints/compute.trustedImageProjectsはCloud Run/GKEのコンテナイメージには適用されない別の制約で、詳細はコンピューティング編を参照してください)。 -
GKEでのイメージ出所制限: GKEでも同様に、承認済みレジストリパス以外からのイメージデプロイを拒否したい場合は、Binary Authorizationのポリシーで
admissionWhitelistPatterns(許可するレジストリパスのパターン)を設定し、defaultAdmissionRuleをALWAYS_DENYにします。「承認済みレジストリかつ署名済み」まで要求するには、前述のアテスター(attestor)による署名検証もあわせて設定する必要があります。
1-7. Application Integration
Amazon AppFlowに相当する、Salesforce・ServiceNow等のSaaSアプリケーションとCloud SQL等のシステム間で、データの接続・マッピング・変換をシームレスに行うためのマネージドiPaaS(Integration Platform as a Service)です。
- 事前構築済みのSaaSコネクタと、ノーコードのビジュアルエディタによるデータマッピング・変換機能を備えます。WorkflowsはGoogle CloudサービスやHTTP APIを順序立てて呼び出す軽量オーケストレーションが主目的で、SaaS向けの豊富なコネクタは持たない点が違いです。
1-8. Apigee
AWS API Gatewayに相当する、API管理(APIゲートウェイ、トラフィック制御、分析、収益化)を行うフルマネージドサービスです。
- バックエンド変更をクライアントから隠すAPIファサード: モノリシックなバックエンドAPIを将来マイクロサービスへ段階的に置き換える予定があり、依存する他アプリへの影響を最小化したい場合は、ApigeeでAPIファサードを実装しクライアントには安定したAPIコントラクトを見せ続けます。ルーティングや形式変換をファサード層で吸収できるため、裏側のバックエンド構造が変わってもクライアント側の改修が不要になります。
- 呼び出し総数の制御(Quota)と瞬間的な急増対策(Spike Arrest): 過剰利用・悪用を防ぎコストを管理したい場合は、1日/1か月などの期間ごとに開発者・アプリ単位で呼び出し回数の上限を設定するQuotaポリシーを使います。瞬間的なトラフィックの急増からバックエンドを守りたい場合は別機能のSpike Arrestポリシーを使います。
1-9. Service Catalog
AWS Service Catalogに相当する、事前承認済みのソリューション(Terraform構成等を含む)をポートフォリオとして公開できるセルフサービスプラットフォームです。
- クラウドネイティブパターンの専門知識が浅い開発チームに、デプロイごとの手動承認というボトルネックなしで、安全で一貫性のあるアーキテクチャパターンを選ばせたい場合に使います。承認はカタログへの登録時に完了しているため、開発速度とガバナンスを両立できます。
1-10. Firebase Test Lab
AWS Device Farmに相当する、Googleがホストするデバイスのクラウドテスト基盤です。
- Android/iOSの多様なデバイスモデル・OSバージョン・画面の向き・言語などの構成マトリックスに対して、モバイルアプリのテストを並列実行できます(仮想デバイスはAndroidのみで、iOSは実機での提供です)。
- 自前でデバイス群を購入・維持する必要がなく、効率的かつコスト効率よくモバイルアプリをテストしたい場合の定番です。バックエンドサーバーの負荷テスト用途には使えない点に注意してください。
2. まとめ
これで「AWSエンジニアのためのGoogle Cloudサービスまとめ」は完結です。全9回、コンピューティングからデベロッパーツールまで、AWSとの対応関係を軸に整理してきました。
改めて振り返ると、EC2・Lambda・S3・RDSのようにほぼ1対1で対応するサービスがある一方、Cloud SpannerやVPC Service Controlsのように単純な対応先がないサービスや、GKE Enterpriseのように統合・再編が進んでいるサービスもあり、対応表の暗記だけでなく現在の提供状況を都度公式ドキュメントで確認する必要があるカテゴリが多いという印象です。
Google Cloudの学習を始めたばかりの方にとって、この対応表が少しでも頭の整理の助けになれば幸いです。
参考