Google Cloud サービス一覧の整理

はじめに

Google Cloudに関連するサービスの特長などを整理します。
また、Google Cloudのサービス以外にも、関連するサービスや技術についても記載しています。

組織・アカウント・アクセス管理

Cloud IAM（Identity and Access Management）

• ロールベースのアクセス制御（RBAC: Role-Based Access Control）に基づいた設計
  • 「誰（Identity）」に「どのロール」を「どのリソース」に対して割り当てるか

アイデンティティ（Identity）

• アクセスする主体のことをアイデンティティ（Identity）という
• アイデンティティの例
  • ユーザーアカウント（Googleアカウント）
  • サービスアカウント
    • Google Cloud内で動作するアプリケーションやVMが使う
      • メールアドレスと秘密鍵が付与され、これらの認証情報を用いてGoogle CloudサービスのAPIを利用する
  • Googleグループ
    • チームや部門単位の制御
  • Cloud Identity / Workspace
    • 企業ドメインの管理
    • 最上位リソースであるOrganizationの管理基盤

ロール

事前定義ロール（Predefined Roles）

• 特定のリソースに対する一般的な操作をカバーするために、Google Cloudが提供しているロール

カスタムロール（Custom Roles）

• 細かい要求に対応するため、ユーザーがカスタマイズできるロール

基本ロール（Basic roles）

• プロジェクト全体に作用する広いロール
• 権限が強すぎる上にカスタマイズもできないため、現在では基本的には利用しない

IAMポリシー

• IAMのポリシー（Policy）は、主に複数のバインディングで構成される
• バインディング（bindings）とは、メンバー（ユーザーやグループ）とロールをセットにしたもの

ロギング

• IAMポリシーの変更履歴を外部にエクスポート出来る
  • エクスポート先はCloud Storage, BigQuery がサポートされている

Resource Manager

Google Cloudのリソース構造を定義し、ポリシーやIAMロールの適用範囲（スコープ）を提供するメタサービス。

Resource ManagerとIAMは連携して機能しており、リソース階層に対してIAMポリシーを適用することで、組織全体・フォルダ単位・プロジェクト単位のアクセス制御を効率的に構築できる。

リソースと階層

Google Cloudのリソースは、上から順に下記の階層構造を持つ。

• 組織（Organization）
• フォルダ（Folder）
• プロジェクト（Project）
• リソース（Resource）
  • e.g. Compute Engine, Cloud Storage など

リソース階層とロール管理

IAMの権限は、足し算（累積） が基本ルール。

• 上位のリソースに割り当てられたロールは、下位のリソースにも引き継がれる
  • Projectに割り当てたロールは、その配下のResourceにも適用される、など
• 下位の階層で新しい権限を追加することは出来るが、上位から与えられた権限を「上書き」したり「無効化」したりはできない
• 下記の方針によって「最小権限の原則」を実現するのがベストプラクティス
  • 上位階層では最小限のロール付与に留める。強い権限は与えない
  • 下位の階層（プロジェクトなど）でも、そこで必要な最小権限のみを与える

Identity Platform

• ユーザー認証や外部IDとの連携を提供するアクセス管理プラットフォーム
• シングルサインオンなどにも対応

Cloud Identity

Cloud IAMがアクセス制御を行うのに対し、Cloud Identityは、ユーザーやグループ、デバイスなどIdentityそのものの管理を行う（IDプロバイダ）。

Google Cloud Directory Sync (GCDS)

• Google アカウントのデータを、オンプレミスのMicrosoft Active Directoryと同期する
• パスワードは同期しない

実行基盤

Compute Engine

フルコントロール可能な仮想マシン（VM）を提供するIaaS型サービス。

• カスタマイズ性の高さが最大の特徴
  • OSの選定、CPU・メモリの構成、永続ディスクやGPUの追加など
• 高パフォーマンス・低レイテンシ
• そのため以下のシーンに適している
  • リフト＆シフト: オンプレミスのVM環境をそのままクラウドに移行する
  • 独自のカーネル設定やセキュリティパッチ、特殊なライブラリなど、細かいシステム要件がある

マネージドインスタンスグループ（MIG）

マネージドインスタンスグループ（MIG）を利用すれば、同じ構成のVMインスタンスを複数まとめて管理できる。

• オートスケーリング
  • CPU使用率やネットワーク負荷などに応じてインスタンス数を自動で増減
  • スケーリング条件はカスタマイズできる
• ローリングアップデート（段階的更新）
  • 新しい構成のテンプレートを適用した際、順番にVMを更新
• 自動修復
  • VMが非正常状態になると自動で再作成
  • ヘルスチェック（健全性チェック）を使って稼働状況を継続監視
• 負荷分散との統合
  • Cloud Load Balancing と組み合わせて、インスタンスグループにトラフィックを分散
  • ゾーン間・リージョン間の高可用性構成を実現

マネージドインスタンスグループを使用する際には、インスタンステンプレートの利用が推奨される。
これは既存のディスクから作成したカスタムイメージをベースイメージとする方法。

既存のディスク -> カスタムイメージ -> インスタンステンプレート

OS Patch Management

• Compute Engine VMに対してOSパッチ適用の自動化を可能にするサービス
• 定期的なパッチジョブのスケジューリングや、コンプライアンスレポートによる状態確認なども行える

SpotVM （プリエンプティブルVM）

GCPの余剰リソースを使う仕組みで、通常よりかなり安く利用できるが、その代わりに突然インスタンスを停止される可能性がある。

そのため、下記のような「途中で中断されても再開しやすい」処理や、CI/CDなどの短時間ジョブ用などに向いている

• バッチ処理
• レンダリング
• 大規模データ処理
• CI / テスト

Google Kubernetes Engine（GKE）

Google がフルマネージドで提供する Kubernetes クラスタ環境

• コンテナ化されたアプリケーションを統合的に管理できる点が最大の特徴
• マイクロサービスアーキテクチャやCI/CD、自動スケーリング、監視との統合にも優れる
• Autopilot モードを使えばインフラの運用管理も最小限に抑えることができる
  • Autopilotモードは、完全マネージドでGKEを運用するモード
  • Cloud RunやApp Engineのように、サーバー運用に関する部分をGoogle Cloudに委ねる状態

コマンド

• gcloud
  • Google Cloud全体を管理するコマンド
  • GKEでは、クラスタの作成や更新で使用する
• kubectl
  • Kubernetesクラスタを管理するための標準ツール
  • GKEでは、PodやServiceの管理で使用する
• kubemci
  • 複数クラスタにまたがるIngressを作成する（≒ HTTP(S)ロードバランサーを作成する）専用CLI

Anthos

ハイブリッド／マルチクラウド対応のKubernetes管理・運用プラットフォーム。

• 複数のKubernetesクラスタを総合的に管理する
  • ここでいう「複数のKubernetesクラスタ」は、オンプレミスやAWSなど他クラウド環境も対象
  • それらに対して、統一されたポリシー、セキュリティ、サービスメッシュ管理を提供する
    • サービスメッシュ: マイクロサービス間の通信をアプリケーションの外側で統一的に制御する仕組み

Cloud Run for Anthos

Cloud Run のサーバーレスな開発体験を保ちつつ、GKEクラスタでコンテナを実行できる環境。

Istio

Kubernetes上で動作するサービスメッシュの代表的な実装。
アプリケーションのコードを変更せずに、トラフィック制御・セキュリティ・可観測性・リトライ・タイムアウト・サーキットブレーカーなどの機能を提供。

フォールトインジェクション

• 意図的にHTTPエラーを返したり、レスポンスに遅延を発生させたりして、マイクロサービスの障害挙動をシミュレートできる機能
• 本番に近いトラフィック条件下での耐障害性テスト（カオスエンジニアリング）が可能

Ingress

外部トラフィックをKubernetesクラスタ内のサービスにルーティングする。
レイヤー7（アプリケーション層: HTTP(S)）でのルーティング制御を行う。

App Engine

App Engine Standard Environment

インフラ管理不要（サーバーレス）でアプリケーションコードをデプロイするだけで動作するPaaS。

• インスタンスの起動・停止やスケーリングは完全に自動で行われ、トラフィック量に応じたリソース割当が行われる
• バージョン管理やトラフィック分割など、アプリの運用面も機能が提供されている
• そのため、主に以下のシーンに適している
  • トラフィックに大きな波があり、インフラのスケーリングを自動で任せたい
  • バージョンごとに動作を検証したり、一部のトラフィックだけを新バージョンに流すなどの運用が必要
• memcacheが組み込まれている
  • memcacheのサービスレベル
    • 共有（shared）
      • 無料で使えるが他アプリとキャッシュが共有される
      • 開発環境や、ごく軽い用途で使用する
    • 専用（dedicated）
      • 特定のアプリ専用にメモリを確保し、確実にキャッシュを保持する
      • 基本的に本番環境ではこちらを使用する

App Engine Flexible Environment

• Docker コンテナベースの環境で、Standardに比べて、より高い自由度がある
• 任意のライブラリ・ランタイムを使用可能
• VMベースなので、Cloud Logging, Monitoring, SSH接続など Compute Engine の機能が利用可能
• アプリは Compute Engine VM 上で実行される（数秒～数十秒の起動時間）

Cloud Run

概要

コンテナイメージをリクエスト駆動で実行できるサーバーレスなプラットフォーム。
Service を入口にして、イミュータブルな Revision をトラフィック制御で切り替える。

• コンテナを扱うためCloud Functionsよりも自由度が高く、好きな言語やランタイム、バイナリを含むアプリケーションをデプロイ可能
• リクエストに応じて自動スケールし、同時実行やリクエストごとのインスタンス分離設定も可能
• ちなみに内部的にはKubernetesをベースにしている

構成要素

Cloud Runは3つの要素で構成される

Service  →  Traffic  →  Revision

Service

• ユーザーがアクセスする 唯一の安定したエンドポイント
• URL を持つのは Service
• DNS / 認証 / IAM / トラフィック分割の単位

Traffic

• Service が持つルーティング設定
• どの Revision に何％流すか、などの割合を調整できる
• --no-trafficオプションが付与されたRevisionにはトラフィックは流れない

Revision

• デプロイするたびに 必ず新しく作られる
• 不変: 実行に必要な条件を丸ごと凍結したスナップショット
• コンテナイメージ + 環境変数 + CPU/メモリ設定などを固定したもの
• KubernetesのPodに近い

デプロイ

Cloud Runにおけるデプロイは、Serviceの裏に新しい Revision を 1 つ追加すること

• 既存 Revision は消えない
• 上書きされない
• 並列に存在し続ける

環境（Revision）は残っており、再ビルドや再デプロイが不要なため、Trafficでのルーティングを変えるだけでロールバックできる。
このためロールバックが速い

Blue/Greenデプロイメントやカナリアリリースを標準的にサポートしていると言える

タグ (revision tag)

特定の Revision に対して、Service 配下に別名のURLを割り当てる仕組み

タグ付きURLでのアクセスは、Trafficでのルーティングとは別のルートを提供する。
このため、例えば--no-trafficが付与されたRevisionに対しても、タグを付けて割り当てられたURL経由ならアクセスできる。

Cloud Functions

関数単位でデプロイできる、イベント駆動型のサーバーレスなFaaS（Function as a Service）。

• 特定のイベント（Pub/Sub、Cloud Storage、Firebase など）をトリガにして自動的にコードを実行できる
• リクエストごとに必要なだけインスタンスがスケールする
• 関数は短時間で実行される軽量なユースケース向き

ネットワーク

VPC（Virtual Private Cloud）

Google Cloudのリソース間通信を制御する仮想ネットワーク。

• グローバルリソースであり、単一のVPCで複数リージョンにまたがるネットワークを構成可能
  • サブネットはリージョン単位で管理され、IP範囲はCIDRで定義
• 共有VPCにより、複数プロジェクト間で一貫したネットワーク管理が可能
  • これによりネットワーク管理とアプリケーション開発の責務を分離する

Private Google Access

• VPC内のプライベートIPアドレスを持つVMから、インターネットを介さずにGoogleのAPIやサービスへアクセスできるようにする機能
• サブネット単位で有効化できる
• 対象サービス
  • Cloud Storage, BigQuery, Cloud Pub/Sub など
• インスタンスが該当サブネットに属し、デフォルトルートでインターネットに向かう経路を持っている必要がある
• 外部インターネットアクセスやパブリックIPを持たない環境で、Google Cloudのサービスへアクセスする際に活用される

Cloud VPN

オンプレミスや他クラウドとのセキュアな（暗号化された）IPsecトンネルを通じた接続。

• Classic VPN
  • 単一トンネル。静的ルートのみ対応
• HA VPN
  • 高可用性を提供するVPN
  • 複数トンネル、自動フェイルオーバー、動的ルーティングに対応
    • BGPを使うためCloud Routerが必須
• GCP内のVPC間接続にも使えるが、インターネット経由のため、Interconnectと比べるとパフォーマンスは劣る
  • ただし構築は簡便

Dedicated Interconnect

オンプレミスとGoogleのネットワーク間を専用線で接続するサービス。

• Google Cloudとオンプレミスを物理的に直接接続することで、高帯域・安定性・セキュリティを実現
  • Dedicated Interconnect：Googleとの直結（エンタープライズ向け）
  • Partner Interconnect：通信事業者を介した接続（中小規模向け）
• Cloud Routerと連携して動的ルーティングを構成可能

VPCルーティング

Google Cloud内のパケット転送経路を制御する仕組み。自動ルートとカスタムルートが存在する。

• リージョンをまたいだ内部通信もサポート（グローバルVPC）
• VPNやInterconnect使用時は、Cloud RouterによるBGP動的ルーティングが推奨

Cloud Router

オンプレミスや他クラウドと接続する際の動的ルーティング（BGP: Border Gateway Protocol）を提供するフルマネージドサービス。

• Interconnect や VPN を使ったハイブリッド接続時に、経路情報を動的にやりとりする役割を持つ
  • オンプレミスとGoogle Cloud間のネットワーク構成変更があっても、自動で経路が更新される
• Cloud RouterがBGPにより学習・生成したルートは、VPCルーティングにも自動的に反映される
• 高可用性
  • Cloud Router 自体はゾーン障害に強く、リージョン内で自動的に復旧

VPC Firewall

インスタンス間の通信許可・拒否を制御するステートフルなファイヤーウォール。
ステートフルとは、片方向（ingressまたはegress）のルールを記述するだけで、対応する逆方向の返答通信が自動で許可されることを意味する。

• 許可ルール中心の構成
  • 明示的な拒否も可能だが補助的なもの
    • すべてのIngress通信は暗黙のルールで拒否されているため
• インスタンス単位ではなく、ネットワークタグやサービスアカウントに基づいて制御
• 優先度によってルールを適用する
  • より優先度の若いものが優先される。0が最優先
  • 最も低い優先度である65535に下記の設定がある
    • 暗黙の許可（Egress: 任意の宛先）
    • 暗黙の拒否（Ingress: すべてのインスタンス）
  • つまり、特に制限しない限り外に出ていく通信は許可されるし、明示的に許可しない限り外部からの通信は拒否されるということ
    • これらの暗黙的なルールをベースとして、明示的な許可ルールと明示的な拒否ルールを加えて制御する
    • 「暗黙のルールを追加する」という操作はない

Cloud Load Balancing

グローバルスケールでトラフィック分散を提供するフルマネージド型ロードバランサ。

• 種類によって適用範囲が異なる
  • HTTP(S) LB
    • グローバル対応、CDNやCloud Armorと連携可
    • レイヤー7（アプリケーション層）で動作する
      • URLパスやHTTPヘッダーなどで負荷分散を行う
  • Internal LB
    • マイクロサービス間などプライベート通信向け
  • TCP/SSL/UDP LB
    • 低レイヤー（レイヤー4: トランスポート層）の通信向けであり、L7と比べて処理が高速
      • IPアドレスとポート番号を基準に判断し、アプリケーションの内容は解析しない
• オートスケーリング、ヘルスチェック、SSL終端処理に対応

Cloud CDN

静的コンテンツのキャッシュ配信を行うことで、応答速度を高速化し、バックエンド負荷を軽減。

• Googleのエッジネットワークを活用する
• HTTP(S) Load Balancerと組み合わせて使用
• レイテンシ削減、帯域使用量削減、トラフィックのスパイク吸収に有効

Cloud DNS

Google Cloud上のスケーラブルなDNSサービス。

• パブリックDNS／プライベートDNSの両方に対応
• インフラ構成のコード化と合わせて、Managed Zoneで自動化が可能

Apigee

APIのライフサイクル全体（API公開、制御、分析、セキュリティ保護）を管理するプラットフォーム。

• レート制限、アクセス制御、分析、バージョン管理、モニタリングなどを統合
• 内部／外部向け問わず、APIの統一的な公開基盤を提供
• 企業のAPIファースト戦略を支える中核コンポーネントとして重要

ストレージ・データ転送・コード管理

Cloud Storage

Google Cloudが提供するオブジェクトストレージサービス。

• データは「バケット」単位で管理される
  • バケットはグローバルに一意な名前を持つ
• 容量無制限、高耐久、高可用性
• コマンドでの操作はgsutilで行う

ストレージクラス

• Standard / Nearline / Coldline / Archive
• 後者のものほど保存料金は安くなるが取り出し料金は高くなる
• ライフサイクル管理: データのアクセス頻度に応じて自動的にストレージクラスを移動したり、削除したり出来る
  • e.g. 90日間アクセスがないオブジェクトをColdlineに移行する、など

リージョン

• マルチリージョンストレージ（Multi-region）
  • 複数の大陸内の複数のリージョンにまたがって自動的にレプリケーションされる
  • リージョン単位の障害が発生しても、データの可用性と冗長性を維持できる
  • 世界中にユーザーが居る場合、エンドユーザーへのアクセス高速化にも寄与する
  • 単一のMulti-Regionalバケットは一つの大陸しかカバーしないため、グローバルアクセスするサービスは、複数のMulti-Regionalバケットへの配置が推奨される
• デュアルリージョンストレージクラス（Dual-region）
  • データは2つの特定のリージョン間でレプリケーションされる
  • マルチリージョンストレージと同等の可用性を保ちつつ、リージョンを詳細に指定したい場合に有用
• リージョナルストレージクラス
  • データは単一のリージョン内の複数のゾーンにレプリケーションされる
  • 特定のリージョン内でのゾーン障害に対する高可用性が提供される

セキュリティ

暗号化

• 転送中の暗号化
  • クライアントとCloud Storage間の転送はSSL/TLSを用いて暗号化される
• 保存中の暗号化
  • 暗号化キーのオプション
    • Google管理キー（GMEK: Google-managed encryption keys）
      • 何も設定しなくても、自動的にGoogleが管理する暗号鍵（GMEK）が使われる
      • デフォルトはこの管理方法であり、通常のユースケースはこれで十分
    • カスタマー管理キー（CMEK: Customer-managed encryption keys）
      • Cloud KMSを使用して暗号化キーを作成・管理する
        • Cloud KMSを通じた鍵のローテーションや無効化などの管理が可能
      • 鍵のライフサイクル制御、アクセス制御、監査ログ記録が可能
      • セキュリティや監査の要件が厳しい場合に有効
      • バケット単位の暗号化、またはオブジェクト単位でアップロード時の指定も可能
    • カスタマー提供キー（CSEK: Customer-supplied encryption key）
      • カスタマー自身が用意した暗号化キーを用いる。Cloud Storageには保存されない
      • 鍵の管理などをすべて自分で行うことになるので、Google Cloudの推奨する管理方法ではない
        • 主にレガシーなセキュリティ要件がある場合に利用される
      • 鍵の設定はboto設定ファイルなどで保持する

データ保護

• バージョニング
  • 上書き保存しても以前のバージョンのオブジェクトを取り出せる
  • バケット単位でバージョニングを有効にできる
• バケットロック
  • オブジェクトを一定期間、削除や変更不可の状態にする
• 署名付きURL
  • 特定の操作に対して、特定の期間、アクセスを許可するURLを発行できる
  • Googleアカウントなどの認証情報を持たないユーザーでもリソースに対する操作を行える

アクセス制御

• 「均一な管理」と「きめ細かい管理」

Cloud Filestore

POSIX互換のマネージド型NFSファイルストレージ。

• 高いIOPS
• 低レイテンシ
• 高スケーラビリティ

Transfer Appliance

• ネットワーク転送が困難な場合に大量のデータを物理的にGoogle Cloudへ送るための物理ハードウェア
• リクエストしてからデータがアップされるまでに1週間から10日程度かかる
  • 金額も安価ではない
  • ただネットワーク経由のアップロードはデータ破損のリスクもあるため、Google推奨の方法はこちら
• 数十テラバイトからペタバイト規模のデータ転送で使用される
  • データ規模によっては、ネットワーク経由のほうが速いこともある
    • コストや転送時間を最小限に抑えたいのであれば、ネットワーク経由
    • gsutilコマンドを使用して転送する
    • マルチスレッドで処理すれば処理時間の短縮も期待できる
• 物理ハードウェアに保存されたデータは暗号化され、暗号化されたままアップロードされる
  • Transfer Appliance RehydratorというCLIツールを使い、ユーザーのみが保持する鍵で復元する
  • この仕組みにより、Googleも中身を見ることができない

Storage Transfer Service

大規模データの転送や同期を行うためのマネージド型データ転送サービス。

• 下記の目的に使用される
  • AWS S3など、サードパーティのオブジェクトストレージからCloud Storageへの移行
  • オンプレミスのファイルシステムからCloud Storageへの移行
    • Storage Transfer Agentというツールを使用
  • Cloud Storage同士で、リージョンをまたいだデータ再配置や複製
• 下記の機能が提供される
  • スケジュール実行
  • 差分転送
  • 失敗時のリトライやログ取得
  • IAMによるアクセス制御

Cloud Source Repositories

• Gitベースのコードリポジトリサービス
  • GitHubのように、バージョン管理されたソースコードをホスティングするためのもの
• gsutilではなく gcloud や git などのコマンドでアクセスする

Cloud Source Repositories は 2024/06/17 以降、新規利用不可（新規顧客に提供されない）。

データベース・キャッシュ

Cloud SQL

• 汎用的なフルマネージドのRDBMS
  • リレーショナルで構造化されたデータを保持する
  • パッチ適用、バックアップ、障害復旧などが自動的に行われる
• MySQL, PostgreSQL, SQL Serverを利用できる
• 標準のSQLをサポート
• バックアップ機能
  • 自動バックアップ / 手動バックアップ
  • 増分バックアップ
  • ポイントインタイムリカバリ
• パフォーマンス
  • 読み書き両方ができるプライマリインスタンス（Primary Instance）
  • 読み込み専用のリードレプリカ（Read-Replica）
    • クロスリージョンのリードレプリカや、外部（オンプレミスなど）のレプリカも作成可能
  • 読み書きのワークロードを分離することで負荷を分散
  • 高可用性（HA）構成
    • リージョン内の異なるゾーンに、フェイルオーバーレプリカを作成することで高可用性（HA）構成を実現できる
    • Cloud SQLはリージョナルサービスのため、リージョンをまたいでフェイルオーバーレプリカを作成することはできない
    • 複数リージョンにわたる設計はディザスタリカバリ構成として行う必要がある

シャーディング

• データベースの負荷分散の手法
• データベース全体を複数の「シャード」（＝データのサブセット）に分割し、複数のサーバに分散配置することで水平方向にスケールする（スケールアウトする）手法
• レプリケーションの負荷を軽減し、レイテンシの低減に寄与する
• Cloud SQLはあくまで既存RDBMSのマネージド版であり、RDBMS自体にはシャーディング機能がないので、自動的にはシャーディングされない。ユーザーが手動で設計・管理する必要がある
  • Cloud SpannerなどのクラウドネイティブなDBは自動でシャーディングが行われる

Cloud Spanner

• グローバルスケールのRDB
  • リレーショナルで構造化されたデータを保持
  • 地理的に分散されたデータセンター間でデータを自動的にレプリケート
  • 大量のデータを処理し、高いトランザクションを実現
• 水平スケーリングと強力なトランザクション整合性を両立
  • 通常、動的スケーリングが保証される場合はトランザクション整合性を保つのは難しいが、Cloud Spannerは強力なトランザクション整合性を持つ
• 標準のSQLをサポート
• OLTP（Online Transaction Processing）など高いトランザクションレートを持つシステムに適している
• 3つの構成オプションが選択できる
  • リージョン構成 / デュアルリージョン構成 / マルチリージョン構成
  • リージョン構成でも同一リージョンの複数ゾーンにデータが分散配置され高い可用性を提供するが、マルチリージョナル構成では地理的に分散した複数のリージョンにデータがレプリケートされ、より高い可用性を提供する

Bigtable

• 大規模な分散をサポートする、マネージドなNoSQLデータベース
• リアルタイムのアプリケーションや大量のデータを処理するバッチジョブ、分析ワークロードに適する
• 数TBから数PBまでスケーリングする
• スキーマ設計
  • 単一の主キーと任意の数の列。列は列ファミリにグループ化される
• Hadoopエコシステムとの互換
  • HBase API規格のサポート

Firestore

フルマネージドなNoSQLドキュメントデータベース。
2つのモードが提供されている。

Firestoreネイティブモード

FirebaseにもGoogle Cloudにも統合されているドキュメント指向NoSQLデータベース。
現在はこちらが推奨されている。

• ドキュメント / コレクション モデルに基づいており、柔軟な入れ子構造が可能
  • ドキュメントはコレクションとしてグループ化される
  • ドキュメントはフィールドを持ち、サブコレクションを持つ
  • コレクションとドキュメントを効率的に検索、フィルタリングできる
• 高スケーラビリティ、高可用性、ACIDトランザクション対応
  • 複数のドキュメントやコレクションにまたがるトランザクションも可能
• リアルタイムの同期が可能で、クライアント側のSDK（Firebase SDK）を使えば、データの変更を即時にアプリへ反映できる
  • オフライン対応もサポートされており、オフライン時の変更はオンライン復帰時に自動で同期される
• モバイルアプリやWebアプリにおけるリアルタイム性が求められるユースケースに最適

Firestore Datastoreモード（旧 Cloud Datastore）

Datastoreモードは、従来のCloud Datastoreとの互換性を維持するために提供されているレガシー互換モード。

• データ構造はエンティティ / Kind / プロパティモデルに基づく
  • RDBで言うテーブルやレコードに近い
• スケーラブルでトランザクションにも対応するが、トランザクションは単一のエンティティグループ内に制限される
• リアルタイム同期やオフライン対応はサポートされていない
  • クライアント側の更新検知にはポーリングなど自前の実装が必要
• App Engineとの親和性が高く、旧来のアプリケーションにおけるデータストアとして引き続き利用可能

Cloud Memorystore

• フルマネージドなインメモリデータストアサービス
• RedisとMemcachedをサポート
• キャッシュ、セッション管理、リアルタイムアプリケーションのデータストアとして利用
• 高いパフォーマンスと低レイテンシを実現
• Redisクラスタ構成による高可用性とスケーラビリティもサポート

データ分析・データエンジニアリング

BigQuery

• フルマネージドのデータウェアハウスサービス
• 大量のデータをリアルタイムで高速に分析
  • ペタバイト規模のデータを扱える
• SQLを使ってMapReduceの技術を扱えることが特徴
• 自然言語インターフェースによるデータ探索に対応
• BigQuery ML: 機械学習モデルの作成と予測にも対応
• Connected Sheet: スプレッドシートとの連携も可能

Looker Studio（旧 Data Studio）

データを可視化して共有するための BI / レポーティングツール。

• BigQuery との連携が定番で、BigQuery への接続を作ると Looker Studio 側で集計・計算などに使いやすい形でフィールドが補助される
• 「分析基盤は BigQuery、可視化と共有は Looker Studio」という組み合わせで語られることが多い

Dataproc

• マネージドなHadoop/Sparkサービス
• ストレージ（Cloud Storage）とコンピュート（Dataproc）を分離し、それぞれでスケーリングが可能
• エフェメラルクラスタ（ジョブ単位の一時利用クラスタ）としての使用
  • 高速に起動できるので、常時起動せず、使う時だけ起動する使い方が可能。これにより無駄なコストを省く

Pub/Sub

• メッセージキューイングサービス
• パブリッシャー（発信者）が送信したメッセージをキューイング（待ち行列に入れ）し、サブスクライバー（受信者）と非同期に連携する
• メッセージ
  • Pull型: サブスクライバーが任意のタイミングでキューからメッセージを取得する方式
  • Push型: 指定されたエンドポイントに対してPub/Sub側からメッセージを配信する方式
• メッセージ送信の確実性を担保するため、下記の機能がある
  • 一定時間、Ack通信（受信確認）がなければメッセージを再送する
  • At-least-once
    • 最低一回の配信を保証する
    • デフォルトでは重複を排除しないため、2回以上配信されることもある
    • Dataflowの重複排除（Deduplication）と組み合わせてExactly-Onceを実現できる
  • メッセージ複製
    • Pub/Subにキューされたメッセージは複数のディスクに複製され、メッセージがAckされるまで永続化される
• バッチ処理
  • 複数のメッセージをまとめて送受信することでスループットを向上させる仕組み
  • ある程度の数のメッセージが貯まるか、一定時間が経過したらまとめて送信する
  • ただし、条件を満たすまでメッセージの送信が行われないため、個々のメッセージで見ると遅延（レイテンシー）も発生する
  • レイテンシーを最小にするためには、バッチ処理をオフにする必要がある

Dataflow

• 大規模データに対する「バッチ処理」「ストリーミング処理」の両方を同一のプログラミングモデルで記述できる
  • Apache Beamのプログラミングモデルに則って実装
  • Java, Pythonが使用可能
• データを分散処理するフルマネージドサービス
  • 自動スケーリングや自己修復機能を備え、インフラ管理の手間を最小限に抑えられる
• コードベースでの記述が前提であるため、エンジニア主導のデータパイプライン構築に適している
  • 特に複雑なデータ変換や高頻度のストリーム処理が必要なユースケースで強みを発揮する

Data Fusion

• GUIベースでデータパイプライン（ETL）を設計・運用できるサービス
• CDAP（Cask Data Application Platform）をベースとする
• GUI上でのドラッグ&ドロップでパイプラインを構築できるため、エンジニアでなくともデータ統合や変換処理を迅速に実現できる
• 数百種類のコネクタやトランスフォーマを活用できるのが特徴
  • オンプレミスやSaaS、各種クラウドサービス（postgreSQL, Salesforce, GCS, BigQuery など）を1つのパイプライン内で容易に統合できる
  • バックエンドではDataflowを実行エンジンとして使用するため、スケーラブルに処理が行える
  • バッチ処理だけでなく、ストリーミング処理にも対応（Spark Streamingを使用）
• 異種データソースの統合が求められるユースケースや、開発者と被技術者が連携するチームにおいて有効

Dataprep

• データの分析の前に行う「前処理」や「データクレンジング」などを行うフルマネージド型サービス
  • データの不整合や欠損値を自動的に検出し、それらを補完したり除去したりする
  • スプレッドシートのような感覚でデータ処理を実施できる
• 実行エンジンとしてはDataflowを使用するため、データ量が多くなってもスケーラブルに処理される
• ノーコードで、ビジュアライズされた変換機能を提供する。非エンジニアでも簡単にデータ変換を実行できる

セキュリティ

Secret Manager

Google Cloud上の機密情報（シークレット）を集中管理するサービス。

• Cloud Audit Logsと統合されているため、シークレットへのアクセスや変更などの監査トレイルを容易に実行できる
• Cloud Functionsと併用して、シークレットに有効期限を設けたり、定期的なローテーション（更新）を強制したりできる

Cloud Data Loss Prevention (DLP)

機密情報を含むデータを発見、保護する機能を提供する。

• データの中の機密情報に対しマスキングやトークン化などの不可逆な変換処理を行い、匿名化する
• 機密情報の代表例
  • PII (Personally Identifiable Information): 個人を特定可能な情報
  • クレジットカード情報
    • PCI DSS (Payment Card Industry Data Security Standard) に準拠した対応が必要
    • トークン化やマスキングはその要件を満たすもの
• BigQuery, Cloud Storage, Datastore などのGoogle Cloudのストレージとは統合されている
• APIを通じて、Google Cloud外のデータに対して検査や変換を行うこともできる

VPC Service Controls

境界ベースのセキュリティモデルにより、Google Cloudへの不正アクセスやデータ漏洩を防ぐための機能。

• セキュリティ境界（Service Perimeter）を定義し、プロジェクトやサービスアカウント、組織フォルダなどを「境界内」に含める
  • この境界の外から内側のリソースへのAPIアクセスは制限される
• 対象サービス
  • Cloud Storage, BigQuery, Cloud Pub/Sub など、多くのマネージドサービスに対応
• 注意点として、対象はあくまで「API経由のアクセス」
• インターネットアクセスをブロックするわけではないため、VPC FirewallやPrivate Google Accessと併用して保護する必要がある

Cloud Armor

DDoS防御およびWebアプリケーションファイアウォール（WAF）サービス。

• WebアプリケーションやAPIのセキュリティを強化するために設計されたグローバルな防御レイヤー
• HTTP(S) Load Balancerに対してのセキュリティ対策を行う
• Google のエッジネットワークでグローバルに動作する

システム監視・可観測性

Cloud Operations (Operations Suite)

Google Cloudのリソースを監視し、リアルタイム・または直近の状況を素早く把握するためのツール群。旧称Stackdriver。

リアルタイムや直近の状況把握が主目的のため、データの保存期間は数週間から数ヶ月程度。それ以上の長期保管や分析が必要であれば、Cloud StorageやBigQueryなどの別サービスへ連携が必要。

Cloud Logging

ログの収集・ルーティング・保存・検索・可視化を行うログ管理基盤

ログの収集

Google Cloudのサービスに関するログは基本的に自動で収集される。
VMの内部ログやミドルウェアのログなどは自動収集されないので、Ops Agentをインストールして収集する必要がある。
Ops AgentはLoggingとMonitoring両方に対応している

ログのルーティング: Logs Router

Cloud Loggingに取り込まれたすべてのログは、Cloud Logging内部の機能であるLogs Routerを通り、どこに送られるか判断される

どのログをどこに送るか（どこで保存するか）というルーティングルールがLog Sink（ログシンク）

ログの保存・転送

Logs Routerの宛先として、以下が使用できる

• Log Bucket（Cloud Logging 内部）
• Pub/Sub
• BigQuery
• Cloud Storage

用途に応じて使い分ける。

• 分析が必要なら BigQuery
• 長期保存・監査用途なら Log Bucket や Cloud Storage
• 外部システム連携やリアルタイム配信なら Pub/Sub

ログの検索・可視化

Log Bucket に保存されたログは、Logs Explorer を使ってリアルタイムに検索・フィルタ・可視化できる。
また、ログベースメトリクスを定義することで、特定ログの出現数などを Cloud Monitoring に送信し、アラートとして活用することも可能。

Cloud Audit Logs（監査ログ）

Google Cloud の各種サービスに対する操作を記録するログ機能。
プロジェクト / フォルダ / 組織 単位で自動的に収集され、構造化されたJSON形式で一貫したスキーマが提供される。

主に以下の種類がある。

• Admin Activity Logs（管理アクティビティ監査ログ）
  • リソースの作成・変更・削除など「管理操作」に関するログ
  • デフォルトで有効になっている
• Data Access Logs（データアクセス監査ログ）
  • データの読み取りや書き込みなど、実データへのアクセス操作に関するログ
  • 明示的に有効化が必要な場合あり
• System Event Logs（システムイベント監査ログ）
  • Google Cloud のシステムによる内部イベント（ユーザーアクションなしで実行される操作）に関するログ
  • Compute Engine等で使用
    • VMの自動移行などを追跡するのに役立つ
• Policy Denied Logs（ポリシー拒否監査ログ）
  • IAM ポリシーによって拒否されたリクエスト（拒否イベント）を記録
  • セキュリティ監査向け
    • セキュリティとコンプライアンスの観点から、どのリクエストが拒否されたのか、なぜ拒否されたのかを把握できる

Cloud Monitoring

Google Cloudやアプリケーションのメトリクスを可視化・監視し、アラートも設定できる。

• インフラ／アプリの状態をリアルタイムで可視化
• カスタムダッシュボード
  • ユーザーが重要と考える指標を、ひと目で分かるように視覚化する
• 異常検知やアラート通知
• AWSやオンプレミスなど、外部サービスの監視もサポートしている
  • 監視対象にエージェント（Monitoring Agent）をインストールする必要がある
  • エージェントをインストールせずとも、API経由で取得できるメトリクスもある
    • 1つ1つの環境にエージェントを導入する手間が省ける
    • ただし取得できる指標が限定される場合もある

Google Cloud Managed Service for Prometheus（マネージド Prometheus）

Prometheus / OpenTelemetry のメトリクスを、Google Cloud 側でフルマネージドに収集・保管・クエリできる仕組み。

Cloud Monitoring と同じバックエンド/API 上に載っているため、Cloud Monitoring のメトリクスと同様に扱える。PromQL や Grafana、Prometheus API を読むツールからクエリできる。

Grafana（ダッシュボード/可視化）

Grafana は OSS の可視化ツールで、Cloud Monitoring をデータソースとして利用できる。

• Grafana には Google Cloud Monitoring data source が標準で用意されており、Cloud Monitoring の指標を Grafana のダッシュボードで可視化できる
• Managed Service for Prometheus を使っている場合も、Grafana 側は（多くのケースで）Prometheus データソースや既存ダッシュボード資産を流用しやすい

Cloud Trace

アプリケーションのレイテンシ（遅延）やパフォーマンスのボトルネックを可視化・分析する分散トレーシングサービス。

• 各リクエストのライフサイクル（どこで時間がかかったか）を視覚的に表示
  • WebアプリやAPIで特に有効
  • マイクロサービス間の通信（gRPC / HTTP）でのボトルネック分析に活躍
  • サービスの遅延原因がDBなのかAPIなのか通信なのかを特定したい場合に有効
• Stackdriver Trace SDK や OpenTelemetry に対応
  • Cloud Run / App Engine / GKE / Compute Engine 上のアプリケーションから利用可能

Cloud Debugger

本番環境で動作しているアプリケーションの状態をリアルタイムで観察できるデバッガ。

• コードに「スナップショットポイント」を設定することで、その時点の変数値やスタックトレースを取得可能
• アプリケーションの動作には影響を与えない（ノンブロッキング）
• バグ再現が困難なケースや、本番でのみ発生する問題の調査に向いている
• App Engine / Cloud Run / GKE / Compute Engine など、Google Cloud上の一般的な実行環境で使用可能

Cloud Profiler

本番環境でのアプリケーションのCPU / メモリ使用状況を継続的に可視化・最適化するツール。

• サンプリングベースのプロファイリング（オーバーヘッドは非常に低い）
• 高頻度で呼び出されている関数やメモリ消費の多い箇所を特定できる
• レイテンシではなくリソース使用量のボトルネックを解消する用途に向く
• スケーラビリティやコスト最適化のために、プロファイリングによる不要なリソース消費の削減が推奨される
• パフォーマンス改善を継続的に行う文化を支えるツールとして活用されることが望ましい

Cloud Error Reporting

アプリケーションの実行時エラー（例外）を自動的に検出・集計・通知するサービス。

• 同じスタックトレースを持つエラーを自動でグルーピング
• 発生回数や発生時間、影響度をUIで確認可能
• 新規エラー発生時には通知が届くため、潜在的な問題の早期発見が可能
• サービス品質指標（SLO / SLA）を満たすために、エラーのトラッキングと通知は必須
• 特にサーバーレス環境では、Error Reporting を通じて運用状況を把握するのが推奨される

デプロイ・IaC

Cloud Deploy

GKEやCloud Runへの継続的デリバリー（CD）を管理するマネージドサービス

• GKE / Cloud Run へのリリース
• 多環境プロモーション（dev → staging → prod）
• カナリア/ブルーグリーン
• ロールバック
• リリース履歴管理

Cloud Foundation Toolkit（CFT）

• Terraformをベースとした、IaCツール用のテンプレート/モジュール集
  • 現在はこちらがベストプラクティス構成
• 下記のコンポーネントで構成される
  • CFTコマンドラインツール
    • CFTが独自にCLIツールを持っている訳ではなく、Terraform や Pulumi などの既存のIaCツールのCLIを使う
  • CFTテンプレート
    • HCL (Terraform) / YAML / TS (Pulumi)
    • Gitなど、Google Cloud外のサービスで管理できる
  • CFTライブラリ
• Terraformベースなのでマルチクラウド構成も可能

Cloud Deployment Manager（CDM）

• Google Cloudに特化したIaCツール
  • gcloudコマンドを使って操作するよう設計されている
• テンプレートは YAML または Jinja2 / Python で記述
  • Google Cloudのコンソールで作成および管理される
• シンプルな要件に対応
• 最近は、新しい機能の追加が止まっている or 遅い
  • 将来的にはDeprecatedの方向性

Deployment Manager は 2026/03/31 にサポート終了。移行先として Infrastructure Manager が案内されています。

AI / ML

Vertex AI

• 機械学習モデルの構築からデプロイ、運用までを包括的にサポートするマネージドサービス
• トレーニング用データの管理、モデルのトレーニング、モデルのデプロイというパイプラインの管理を行う
• コードなしでモデルを構築するAutoMLと、ユーザー自身で定義したカスタムモデルの両方に対応
• 高度なカスタマイズを行えることが、後述のAPI群よりも有利な点
  • 逆に簡単な組込みAIであれば、API群が向いている

モデル作成: AutoML

• コードなしでモデルを構築できる機能群
  • 画像分類、自然言語処理など
  • 内部ではTensorFlowベース
• データソースとしてCloud StorageやBigQueryを使用可能
  • Cloud Storageは、主に画像・動画・音声・非構造データの保存用
  • BigQueryは、構造化データの教師データを保持し、Vertex AIにわたす前の前処理を行うこともある

Vertex AI Studio（旧称: Generative AI Studio）

• Geminiなどの大規模言語モデル（LLM）を使ったアプリ開発を支援するUIツール
• プロンプトのチューニングや評価などが可能
• デプロイしたモデルは、Cloud RunやCloud FunctionsなどにAPIとして組み込める

機械学習のトレーニング: 旧称 Google Cloud Machine Learning（Cloud ML Engine）

• 機械学習モデルのトレーニングに特化
  • モデルの監視・バージョン管理・再学習まで一元化している
• TensorFlow や PyTorch などのフレームワークに対応
  • TensorFlowはGoogleが開発したフレームワーク

Google Cloudが提供するAI関連のAPI群

Vertex AIほど高度にカスタマイズするのではなく、簡単な組込みAIが欲しい場合にはAPI群が利用できる。
これらはプリビルト（事前学習済み）なサービス。

Cloud Vision API

• 画像認識を行い、ラベル検出やOCR、顔検出などを行うためのAPI
• Cloud Storageの画像と連携し、Cloud Functionsでトリガー処理を自動化できる
• リアルタイムの処理が可能
  • 動画（を分割した画像）に対してのOCRなどを行いたい場合、現状ではVision APIのみが対応している
    • Cloud Video Intelligence APIはリアルタイム処理に対応していないため

Speech-To-Text / Text-To-Speech API

• 音声を認識してテキスト情報にしたり、テキストから音声合成を行ったりするAPI
• 音声データはCloud Storageから取得する
• ストリーミング処理ではPub/SubやCloud Functionsと組み合わせる

Cloud Natural Language API

• 自然言語処理（NLP）のためのAPI
  • テキストの構文解析、感情分析、エンティティ抽出などを行う
• REST APIベースでどこからも呼び出し可能
• Cloud Functionsなどから利用しやすい

Cloud Translation API

• テキストの翻訳及び言語検出を行うAPI
  • 数十の言語をサポート
• WebアプリやCloud Runのマイクロサービスとの連携に適している

Cloud Video Intelligence API

• 動画ファイルを分析して、ラベル検出やショット分割、顔や人物の検出、文字起こし（Speech-To-Text との連携）などを提供する
• 動画内のコンテンツを構造化する目的で利用される
• あくまで動画ファイルに対するバッチ処理（事後処理）を提供するものなので、ストリーミング動画やリアルタイム処理には非対応
• Cloud Storage上の動画ファイルに対応
• 解析結果の構造化データはBigQueryに保存し、検索できる

API管理公開基盤

Apigee

APIのライフサイクル全体（API公開、制御、分析、セキュリティ保護）を管理するプラットフォーム。

• レート制限、アクセス制御、分析、バージョン管理、モニタリングなどを統合
• 内部／外部向け問わず、APIの統一的な公開基盤を提供
• 企業のAPIファースト戦略を支える中核コンポーネントとして重要

Firebase（周辺プロダクト）

Firebase Test Lab

• モバイルアプリ（Android/iOS）の自動テストを実行できるテストツール
• ビルド済みのアプリをアップロードし、そのアプリに対するテストを実機やエミュレータ上で実行し、結果をレポートとして提供する
• 様々なOSバージョン、画面サイズ、設定の端末上でテストを実行できる

Firebase Hosting

• 静的コンテンツ（HTML, CSS, JSなど）を高速に配信できるホスティングサービス
• GoogleのグローバルCDNを活用して、エッジロケーション（なるべくユーザーに近い拠点）から配信される

可用性・災害対策（DR）

システム障害や自然災害などが発生した場合でも、サービスを継続させ、データの保全性を確保することにより、システム全体の耐障害性・高可用性を実現する。

指標

• RPO（Recovery Point Objective: 復旧時点目標）
  • データをどの時点まで復旧するか（≒ どの時点のデータまでなら失ってもよいか）
  • e.g. 直近1時間まで失ってもよいのであれば、RPOは1時間
• RTO（Recovery Time Objective: 復旧時間目標）
  • サービスをどれくらいの時間内に復旧するか

一般的に、RPOとRTOを短くすると、それだけコストは高くなる。

DR戦略

Google CloudにおけるDR戦略のパターンは下記の通り。

• バックアップ&リストア
  • 普段から定期的にデータをバックアップしておき、災害が発生したらリストアする
  • 復旧までに時間がかかり、失われるデータも多いが、コストは最も低い
• パイロットライト（コールドスタンバイ）
  • 本番環境と同じアーキテクチャだが必要最低限のリソース（= 構成のスケルトン）だけを持つ スタンバイ環境 を常時稼働しておく
    • スタンバイ環境は別のリージョンに構築する
    • ここでいう必要最低限のリソースは、主に永続化層に留まるケースが多い
  • 災害が発生したら、本番環境と切り替えてスケールアウト/スケールアップさせる
• ウォームスタンバイ
  • パイロットライトに加えて、アプリケーション層を含む主要なサービスを縮小構成でスタンバイ環境に構築しておく
• アクティブ-アクティブ構成（ホットスタンバイ / マルチサイト）
  • 本番環境と同じスペックをスタンバイ環境でも常に同時稼働させておく
  • 災害が発生しても即時にサービス復旧できるがコストも最も高い

下にいけばいくほどコストは高くなるが、RTO/RPOを短くすることが出来る。

アーキテクチャ戦略

マルチゾーン / マルチリージョン構成

• Compute Engine, GKE（Google Kubernetes Engine）などはリージョン単位の管理が基本
• 高可用性（HA）を担保するためには、複数ゾーンに分散配置し、ゾーン障害に強くする
• より広範な障害（地震など）に備えるには、複数リージョンにまたがって冗長化する

ストレージとデータ保全

• Cloud Storage：マルチリージョン、リージョン、デュアルリージョンのクラス選択が可能。DR目的にはマルチリージョンやデュアルリージョンが推奨される
• Cloud SQL / Spanner / Bigtable：リージョン内レプリケーションやマルチリージョン構成に対応。Spannerはグローバル分散型DBとして特にDRに強い
• バックアップとリストア：Cloud SQLなど多くのマネージドサービスは自動バックアップとスナップショット機能を提供

ネットワークとアクセス

• Global Load Balancing：トラフィックをヘルスチェックに基づき健全なリージョンへ振り分け。自動フェイルオーバーを実現
• Cloud DNS：「通常はプライマリの環境に接続し、障害時には自動でセカンダリ環境へ切り替える（フェイルオーバーする）」という仕組みをDNSレベルで実現できる
• CDNのキャッシュにより一時的にサービスを継続することも可能