Instiq

Google Cloud Associate Cloud Engineer のナレッジマップ

Google Cloud Associate Cloud Engineer の主要概念 127 件と、そのつながり。上のマップでノードをクリックすると関連用語や前提をたどれます。下は全概念の索引で、定義と「前提・関連する概念」への内部リンクを掲載しています。

概念一覧(127)

  • マネージドサービス(管理の境界)

    AWS が運用の一部を肩代わりするサービス区分。フルマネージド(パッチ/スケール/可用性まで AWS)ほど運用負荷が下がる一方、制御は減る。アンマネージド(EC2 等)は柔軟だが自己管理。責任共有モデルの「どこまでが自分の責任か」を決める軸。

  • 性能の指標(IOPS/スループット/帯域幅/レイテンシー)

    性能を測る基本語彙。IOPS=1 秒あたりの I/O 回数(小さなランダムアクセスの指標、EBS io2 等)。スループット=単位時間のデータ量(MB/s、大きな連続転送)。帯域幅=回線容量。レイテンシー=1 操作の遅延。ワークロードに合う指標で設計・監視する。

  • Cloud Storage

    画像・動画・バックアップなど非構造化データを保存するオブジェクトストレージ。

  • Cloud Run

    コンテナをサーバーレスで実行するサービス。トラフィックがなければゼロまで縮小し、使った分だけ課金される。

  • Compute Engine

    Google Cloud の IaaS。CPU/メモリを選べる仮想マシン(VM)を提供し、OS まで自分で管理できる。既存システムのリフト&シフト先に適する。

    前提: 移行戦略(リフト&シフト/改善移行/リファクタ)

  • Eventarc

    Pub/Sub や Cloud Storage の変更など多様なイベント源からのイベントを Cloud Run / Cloud Functions へ統一的に配送する仕組み。

    前提: Cloud FunctionsCloud RunCloud StoragePub/Sub

  • BigQuery

    ペタバイト級のデータを SQL で高速に分析できる、Google Cloud のサーバーレスなデータウェアハウス。

  • Deployment Manager

    Google Cloud のネイティブな Infrastructure as Code サービス(YAML/Jinja/Python テンプレート)。非推奨化され 2026-03-31 にサポート終了予定で、Terraform ベースの Infrastructure Manager などへの移行が推奨される。

    前提: IaC ツール(Terraform / Helm)Infrastructure as Code(IaC)Infrastructure ManagerYAML

  • ファイアウォールルール(VPC firewall rules)

    VPC 内外のトラフィックを許可/拒否するステートフルな規則。方向・優先度・ターゲット(タグ/サービスアカウント)・送信元で評価する。組織レベルの階層型ファイアウォールポリシーもある。

    前提: サービスアカウント(Service account)Cloud NGFW と階層型ファイアウォール

  • サービスアカウント(Service account)

    人ではなくワークロード(VM/アプリ)が使う特別な ID。鍵の代わりにメタデータ経由の短命トークンや Workload Identity Federation で認証するのが安全。

  • Cloud Interconnect

    オンプレミスと Google Cloud を専用回線で接続するサービス(Dedicated/Partner)。高帯域・低遅延・SLA を提供し、手軽な暗号化トンネルの Cloud VPN と使い分ける。

    前提: Cloud VPN性能の指標(IOPS/スループット/帯域幅/レイテンシー)

  • Ops Agent

    Compute Engine や オンプレミス VM にインストールし、詳細なシステムメトリクス(CPU/メモリ/ディスク等)とログを Cloud Monitoring / Cloud Logging へ収集するエージェント。旧来の Monitoring エージェントと Logging エージェントを統合したもので、新規はこちらを使う。

    前提: Cloud LoggingCloud MonitoringCompute Engine

  • IaC ツール(Terraform / Helm)

    Bicep/ARM に加え、マルチクラウドの Terraform(宣言的・状態管理)や、Kubernetes 配布の Helm チャートをパイプラインから適用してインフラとアプリ構成をコード化する。

  • Cloud Build

    ソースコードの取得・ビルド・テスト・コンテナイメージ化を自動実行するサーバーレス CI サービス。cloudbuild.yaml でビルドステップを定義し、GitHub/Cloud Source Repositories への push をトリガーに実行できる。生成物は Artifact Registry へ保存するのが一般的。

    前提: YAML

    関連: Cloud DeployArtifact Registry

  • Filestore

    フルマネージドな NFS ファイルストレージ。Compute Engine VM や GKE から共有ファイルシステムとしてマウントし、低レイテンシの共有ストレージを提供する。

    前提: Compute Engineマネージドサービス(管理の境界)性能の指標(IOPS/スループット/帯域幅/レイテンシー)

  • Cloud DNS

    内部/外部の名前解決(ドメイン名から IP へ)を管理する Google Cloud のサービス。

  • Cloud NAT

    外部 IP を持たない VM から、インターネットへの外向き通信を可能にするサービス。

  • Cloud VPN

    オンプレミスや他ネットワークと Google Cloud を暗号化トンネルで接続するサービス。

  • Storage Transfer Service

    大量・継続的なデータを Cloud Storage へ転送するマネージドサービス。少量は gcloud/bq CLI が手軽。

    前提: Cloud Storageマネージドサービス(管理の境界)

  • 暗号鍵(GMEK / CMEK / CSEK)

    GMEK=Google が管理する既定の鍵、CMEK=顧客が Cloud KMS で管理する鍵(ローテーション/無効化を制御)、CSEK=顧客が鍵そのものを供給。保存時・転送時とも既定で暗号化される。

    前提: 保管時の暗号化(at rest)転送時の暗号化(in transit)

    関連: Cloud KMS

  • App Engine

    フルマネージドな Web アプリ基盤(PaaS)。サーバー管理なしにアプリを公開でき、開発に集中できる。

    前提: マネージドサービス(管理の境界)

  • Cloud Logging

    ログの収集・検索・保管を担う Google Cloud Observability の機能。原因調査や監査に使う。

    関連: 可観測性の三本柱(メトリクス・ログ・トレース)

  • Cloud Monitoring

    メトリクスの監視・ダッシュボード・アラートを担う Google Cloud Observability の機能。

    関連: 可観測性の三本柱(メトリクス・ログ・トレース)

  • Pub/Sub

    イベントをリアルタイムに取り込み、複数のサービスへ配信するメッセージングサービス。ストリーミング取り込みに使う。

  • Spanner

    世界規模で強い整合性と高可用性を両立する分散リレーショナルデータベース。グローバルな基幹系に適する。

    前提: 強整合性(strong consistency)

  • Cloud Deploy

    GKE・Cloud Run・Anthos 向けのマネージドな継続的デリバリー(CD)サービス。開発→ステージング→本番のようなデリバリーパイプラインをテンプレート化し、カナリアやブルー・グリーンなどのデプロイ戦略、承認ゲート、ロールバックを標準機能として提供する。

    前提: Cloud RunGKE Enterprise(Anthos)デプロイ戦略(カナリア/ブルー・グリーン/ロールバック)

    関連: Cloud Build

  • Cloud Trace

    分散システムのリクエストの経路(スパン)を追跡し、レイテンシのボトルネックを特定する分散トレースのサービス。メトリクス(Monitoring)やログ(Logging)とは別の観測軸。

    前提: 性能の指標(IOPS/スループット/帯域幅/レイテンシー)

    関連: 可観測性の三本柱(メトリクス・ログ・トレース)

  • Memorystore

    Redis / Memcached 互換のフルマネージドなインメモリキャッシュ。頻繁な読み取りをキャッシュしてレイテンシを下げる。永続ストアではない。

    前提: マネージドサービス(管理の境界)性能の指標(IOPS/スループット/帯域幅/レイテンシー)

  • Vertex AI AutoML

    コードをほぼ書かずに、表形式・テキスト・画像・動画データから高品質なカスタム ML モデルを自動構築する Vertex AI の機能。ニューラルアーキテクチャ探索とハイパーパラメータ調整を裏側で行い、精度と学習コストのバランスを取ったモデルを出力する。素早い SQL 分析だけなら BigQuery ML の方が手軽な場合もある。

    前提: BigQueryBigQuery MLVertex AI

    関連: Tabular Workflows

  • YAML

    インデントで階層を表す、人が読み書きしやすいテキスト形式。CloudFormation や各種 IaC ツール、CI/CD パイプラインの設定ファイルで好まれ、同じデータを JSON とも相互変換できる。

    前提: IaC ツール(Terraform / Helm)JSON

  • Config Connector

    Kubernetes の宣言的な方法で Google Cloud リソースを管理する Infrastructure as Code ツール。

    前提: Infrastructure as Code(IaC)

  • VPC ネットワークピアリング

    2 つの VPC ネットワークを直接接続して相互に通信できるようにする仕組み。

    前提: VPC(Virtual Private Cloud)

  • Amazon Managed Service for Prometheus (AMP)

    Prometheus 互換のマネージドなメトリクス収集/保存サービス。EKS/ECS などコンテナ環境のメトリクスを PromQL でクエリでき、スケールや保持を AWS に任せられる。Managed Grafana と組み合わせて可視化する構成が定番。

    前提: マネージドサービス(管理の境界)

  • Cloud Functions

    「ファイルがアップされたら実行」のようなイベント駆動の小さな処理を動かすサーバーレスの関数サービス。

  • Cloud SQL

    MySQL / PostgreSQL / SQL Server 互換のマネージド リレーショナルデータベース。一般的な業務アプリ向け。

  • Firestore

    モバイル/Web アプリのデータ向けのスケーラブルなドキュメント型 NoSQL データベース。

  • Vertex AI

    機械学習モデルの構築・学習・デプロイ・運用を一気通貫で行える統合 AI プラットフォーム。基盤モデルの利用も可能。

  • 保管時の暗号化(at rest)

    ディスクやオブジェクトストレージ上に保存されているデータを暗号化すること。クラウドの多くのマネージドストレージ(ブロック/ファイル/オブジェクト/DB)はサービス側の鍵管理(KMSなど)と統合した暗号化オプションを持つ。盗難・不正アクセスからデータ本体を守る基本対策。

    前提: Cloud Storage

  • API Gateway(Google Cloud)

    サーバーレスのバックエンド(Cloud Run/Functions/App Engine)の前段に置くフルマネージドな API ゲートウェイ。OpenAPI で定義し認証・鍵・モニタリングを担う。

    前提: App EngineCloud Runマネージドサービス(管理の境界)

  • VPC(Virtual Private Cloud)

    Google Cloud のソフトウェア定義ネットワーク。グローバルなリソースで、リージョンをまたぐサブネットを 1 つのネットワークに収容する。ルート・ファイアウォール・ピアリングで通信を制御する。

  • Infrastructure as Code(IaC)

    インフラをコード(テンプレート)で宣言的に定義し、再現可能・バージョン管理可能にする考え方。手作業のドリフトを防ぎ、レビュー・自動化・複数環境の一貫構築を可能にする。AWS では CloudFormation・CDK が代表。

  • CIDR 表記

    IP アドレス範囲を「/24」のようなプレフィックス長で表す記法。/24 は 256 個、/16 は 65,536 個のアドレスを含み、数字が小さいほど範囲が広い。VPC/VNet やサブネットの設計、ルーティングの最長一致判定、ファイアウォールルールの許可範囲指定など、あらゆるクラウドのネットワーク設計の基礎になる。

    前提: ファイアウォールルール(VPC firewall rules)

  • エフェメラルポート

    クライアントが接続の戻り通信用に一時的に使う高位のポート番号(一般に 1024–65535)。ステートレスなファイアウォールルール(例:ネットワーク ACL)では、戻り通信を許可するためにこの範囲を明示的に開ける必要があり、見落としやすい設定ミスの原因になる。

    前提: ファイアウォールルール(VPC firewall rules)ポート番号

  • デプロイ戦略(カナリア/ブルー・グリーン/ロールバック)

    カナリア=一部の利用者に先行公開、ブルー/グリーン=新旧環境を瞬時に切替、ロールバック=問題時に即座に戻す。リスクを抑えてリリースする手法。

  • VPC Service Controls

    BigQuery や Cloud Storage などのマネージドサービスへのデータ持ち出しを、サービス境界(perimeter)で防ぐ仕組み。IAM の許可とは別レイヤーの統制。

    前提: BigQueryCloud Storageマネージドサービス(管理の境界)

  • Artifact Registry

    コンテナイメージや言語パッケージを保存・管理するレジストリ。Cloud Build でビルドした成果物の保存先。

    関連: Cloud Build

  • Cloud CLI エミュレータ

    Google Cloud CLI が提供する Firestore・Pub/Sub・Spanner などのローカル模擬環境。クラウドに接続せず開発・ユニットテストを高速化する(本番の代替ではない)。

    前提: FirestorePub/SubSpanner

  • 可観測性の三本柱(メトリクス・ログ・トレース)

    メトリクス(Cloud Monitoring・数値の傾向)、ログ(Cloud Logging・出来事)、トレース(Cloud Trace・リクエストの経路)。トレース ID でログとトレースを相関させて原因を特定する。

    関連: Cloud TraceCloud LoggingCloud Monitoring

  • Cloud NGFW と階層型ファイアウォール

    VPC 内通信を制御する次世代ファイアウォール。組織/フォルダに継承する階層型ポリシー、優先度で評価される実効ポリシー、Enterprise ティアの L7 検査(IPS)を持つ。タグ/サービスアカウントでマイクロセグメンテーションを実装する。

    前提: サービスアカウント(Service account)

  • Cloud Router

    オンプレ/他ネットワークと BGP で動的に経路交換するルーター。ASN・ルート優先度/MED・認証を構成し、カスタムアドバタイズ/ラーン ルートで広告・学習する範囲を制御する。

    前提: ルート優先度

  • Cross-Cloud Interconnect

    他のパブリッククラウドと Google Cloud を、インターネットを経由せず専用の物理接続で低遅延に結ぶサービス。マルチクラウド接続で Cloud VPN より高帯域・低遅延が必要なときに使う。

    前提: Cloud VPNCloud Interconnect性能の指標(IOPS/スループット/帯域幅/レイテンシー)

  • ポート番号

    同じ IP アドレス上で動く複数のサービスを識別する 16 ビットの番号(例:HTTP は 80、HTTPS は 443、SSH は 22)。TCP・UDP のヘッダーに含まれ、ファイアウォールやセキュリティグループのルールは送信元/宛先ポートで通信を許可・拒否する。

    前提: HTTPS

    関連: UDP

  • 強整合性(strong consistency)

    書き込み完了後の読み取りは必ず最新の値を返す整合性モデル。結果整合性より遅延やコストが増えがちだが、在庫数や残高のように古い値の読み取りが許されない場面で選ぶ。整合性モデルはこのトレードオフに基づき用途ごとに使い分ける。

    前提: 性能の指標(IOPS/スループット/帯域幅/レイテンシー)

    関連: 結果整合性(eventual consistency)

  • Tabular Workflows

    表形式データ向けの AutoML パイプラインを、Vertex AI Pipelines 上のコンポーネントとして分解し、特徴量エンジニアリングやアーキテクチャ探索などの各段階を個別にカスタマイズ・再利用できるようにした機能。AutoML のブラックボックス的な自動化に対し、大規模データや特定段階への細かい制御が必要な上級ユースケース向け。

    前提: WorkflowsVertex AI

    関連: Vertex AI AutoML

  • 課金アカウントと予算

    費用を支払う単位。プロジェクトをリンクして使う(1 アカウントに複数プロジェクト可)。予算とアラートはしきい値で通知するのみで自動停止はしない。

  • マネージドインスタンスグループ(MIG)とインスタンステンプレート

    インスタンステンプレート(VM の設計図)に基づき同一構成の VM を作成し、オートスケールや自己修復を行う Compute Engine のグループ。

    前提: Compute Engine

  • 組織ポリシー(Organization Policy)

    リソース階層に沿って制約を継承・強制し、組織全体に一貫したルール(例: 特定リージョン以外の作成禁止)を適用する仕組み。IAM の許可とは別。

    前提: リソース階層

  • Cloud Storage のストレージクラス

    アクセス頻度で選ぶクラス:Standard(頻繁)/Nearline(月1)/Coldline(四半期)/Archive(長期低頻度)。低頻度ほど保存は安いが取り出しは高い。

    前提: Cloud Storage

  • Cloud KMS

    暗号鍵を作成・管理し、ローテーションや無効化を制御するマネージドな鍵管理サービス。CMEK の基盤。

    関連: 暗号鍵(GMEK / CMEK / CSEK)

  • Workflows

    サービス間の軽量なステップ連携(シンプルなワークフロー)を行うサーバーレスのオーケストレーション。重い依存は Cloud Composer。

  • エニーキャスト

    同じ IP アドレスを複数の拠点から同時に広告し、経路的に最も近いノードへ自動的に届ける通信方式。CDN や DNS、グローバル負荷分散サービスが低遅延・高可用性を実現する基盤として使う。

    前提: 性能の指標(IOPS/スループット/帯域幅/レイテンシー)

    関連: ユニキャスト

  • BigQuery ML

    BigQuery 上のデータに対し、データを移さず SQL だけで機械学習モデルを作成・予測できる機能。

    前提: BigQuery

  • Bigtable

    IoT・時系列など超大量・低遅延のワークロード向けのワイドカラム型 NoSQL データベース。

    前提: 性能の指標(IOPS/スループット/帯域幅/レイテンシー)

  • Gemini

    Google Cloud の中核となる生成 AI モデル。文章生成・要約・コード支援・画像理解などを担い、各サービスや Workspace に組み込まれる。

  • リソース階層

    組織→フォルダ→プロジェクト→リソースという Google Cloud の階層。プロジェクトが課金/権限の基本単位で、ポリシーは階層に沿って継承される。

  • Spot VM

    中断され得る代わりに大幅な割引が受けられる Compute Engine の VM。中断に強いバッチ処理などのコスト最適化に用いる。

    前提: Compute Engine

  • 転送時の暗号化(in transit)

    ネットワーク経路を通過中のデータを暗号化すること。多くの場合TLSで通信を保護する。保管時の暗号化と組み合わせて初めて、データのライフサイクル全体(保存中・移動中)を防御できるため、両方を満たすのがセキュリティの基本要件となる。

    前提: 保管時の暗号化(at rest)

  • 結果整合性(eventual consistency)

    書き込み直後は古い値が読まれる可能性があるが、時間の経過とともに全レプリカが最終的に収束する整合性モデル。高可用性・低遅延を優先する分散データストアの既定挙動になっていることが多い。強整合性が不要な読み取りに使うことでスループットを稼げる。

    前提: 性能の指標(IOPS/スループット/帯域幅/レイテンシー)

    関連: 強整合性(strong consistency)

  • Cloud Billing(課金)

    請求先アカウントをプロジェクトに紐づけ、費用の確認・予算アラート・課金データの BigQuery エクスポートを行う仕組み。

    前提: 課金アカウントと予算BigQuery

  • Gemini Cloud Assist

    Google Cloud コンソール内で、ログ・メトリクス・トレースやリソース構成を分析し、トラブルシューティングやアーキテクチャ設計の提案を自然言語で行う AI アシスタント。運用担当者がコンソールを横断して原因調査する時間を短縮する目的で使う。

    前提: Gemini

    関連: Gemini Code Assist

  • Gemini Code Assist

    IDE 上でコード補完・生成・説明・レビューを支援する AI ペアプログラミング機能。個人向け無償枠と、社内コードベースを踏まえた補完やエンタープライズ管理が可能な Enterprise 版がある。VS Code や JetBrains 系 IDE の拡張として使う。

    前提: Gemini

    関連: Gemini Cloud Assist

  • IP マスカレード(GKE)

    GKE の Pod がクラスタ外へ送信する通信の送信元 IP を、ノードの IP に変換(SNAT)する仕組み。既定の非マスカレード対象(変換しない宛先)は RFC 1918 等のプライベートアドレス範囲とリンクローカルアドレスで、ip-masq-agent の設定で対象 CIDR を追加・変更できる。この agent が DaemonSet として自動デプロイされるか、その既定設定がどうなるかは GKE のバージョンやクラスタ構成(Autopilot か Standard か、Dataplane V2 の有無等)によって異なる。

    前提: Dataplane V2CIDR 表記

  • 水平スケーリング(スケールアウト)

    インスタンスの台数を増やして負荷を分散するスケーリング方式。ステートレス設計とロードバランサ・Auto Scalingが前提になり、1台の故障がシステム全体に影響しにくいため耐障害性も高まる。クラウドネイティブな設計では基本の方向性とされる。

    前提: フォールトトレランス(耐障害性)

  • HTTPS

    HTTPをTLSの上に載せて運ぶプロトコル。通常のHTTPと違い通信内容が暗号化され、途中経路での盗聴・改ざんを防げる。ブラウザは証明書を検証してサーバーの正当性を確認し、Webサイトの標準的な通信方式になっている。

    関連: TLS

  • マイクロサービス

    アプリケーションを小さく独立したサービス群に分割するアーキテクチャスタイル。サービスごとに個別デプロイ・個別スケール・障害分離ができる一方、サービス間通信や運用の複雑さが増す。コンテナやサーバーレス基盤、API ゲートウェイと組み合わせて構築されることが多い。

  • マルチキャスト

    特定のグループに参加したホストにだけ一斉配信する通信方式。ブロードキャスト同様クラウドの仮想ネットワークでは標準サポートされないことが多く、必要な場合はトランジットゲートウェイのマルチキャスト機能のような専用サービスを使うか、設計をユニキャスト前提に置き換える。

    前提: ブロードキャストユニキャスト

  • Cloud External Key Manager(Cloud EKM)

    外部(自社/サードパーティ)の鍵管理基盤に保持した鍵で Google Cloud のデータを暗号化する仕組み。CMEK(Cloud KMS で顧客管理)よりさらに鍵主権を高める。

    前提: Cloud KMS暗号鍵(GMEK / CMEK / CSEK)

  • Infrastructure Manager

    Terraform をマネージドで実行する Google Cloud のサービス。インフラをコード化(IaC)して再現可能にし、CI/CD と PR でレビュー・監査する。

    前提: IaC ツール(Terraform / Helm)

  • Private Google Access

    外部 IP を持たない VM から Google API(Cloud Storage など)へプライベートに到達できるようにする設定。外向き一般通信の Cloud NAT とは目的が異なる。

    前提: Cloud NATCloud Storage

  • Binary Authorization

    デプロイするコンテナイメージの署名を検証し、信頼できる(出所が保証された)成果物だけを GKE / Cloud Run に許可する仕組み。サプライチェーン保護に使う。

    前提: Cloud Run

  • Cloud Run のリビジョンとトラフィック分割

    デプロイごとに作られる不変の単位がリビジョン。トラフィック分割で各リビジョンへ送る割合を制御し、カナリア公開やロールバックを行う。

    前提: Cloud Runデプロイ戦略(カナリア/ブルー・グリーン/ロールバック)

  • gRPC

    HTTP/2 上で動く低遅延・型付き(Protocol Buffers)の RPC フレームワーク。内部のサービス間通信に向く。公開 Web には REST も選ぶ。

    前提: 性能の指標(IOPS/スループット/帯域幅/レイテンシー)

  • Cloud CDN

    外部 Application LB のバックエンドで有効化し、Google のエッジでコンテンツをキャッシュする CDN。オリジンは MIG/Cloud Storage/Cloud Run/インターネット NEG。更新時はキャッシュ無効化で古い内容を破棄する。

    前提: Cloud RunCloud Storage

  • ネットワークエンドポイントグループ(NEG)

    ロードバランサのバックエンド単位。コンテナネイティブ(GKE)・サーバーレス(Cloud Run など)・インターネットのエンドポイントをまとめて登録できる。マネージドインスタンスグループ(MIG)と使い分ける。

    前提: マネージドインスタンスグループ(MIG)とインスタンステンプレートCloud Run

  • VLAN アタッチメント

    Cloud Interconnect と VPC(Cloud Router)を結ぶ論理接続。物理接続(Interconnect)を作った後、VLAN アタッチメントで実際の VPC へトラフィックを通す。

    前提: Cloud InterconnectCloud Router

  • TLS

    通信を暗号化し、証明書によってサーバー(要件次第ではクライアントも)を認証するプロトコル。ハンドシェイクで鍵交換と認証を行った後、対称鍵でデータを暗号化して送受信する。クラウドのロードバランサやCDNで終端し、証明書はマネージドサービスで発行・更新するのが一般的。

    前提: マネージドサービス(管理の境界)

    関連: HTTPS

  • UDP

    コネクションを確立せず、順序保証や再送を行わない軽量なトランスポート層プロトコル。オーバーヘッドが小さく高速なため、DNS 問い合わせや動画/音声ストリーミングなど、多少の欠落より低遅延を優先する通信に使われる。

    前提: 性能の指標(IOPS/スループット/帯域幅/レイテンシー)

    関連: ポート番号

  • ユニキャスト

    1 台の送信元から 1 台の宛先へ届ける、最も一般的な 1 対 1 の通信方式。通常のクライアント・サーバー通信やほとんどの API 呼び出しはこの方式を前提に設計される。

    関連: エニーキャスト

  • 垂直スケーリング(スケールアップ)

    1台のインスタンスのスペック(CPU・メモリ等)を増強するスケーリング方式。アプリの構成変更が少なく手軽だが、インスタンスタイプの上限があり、単一障害点になりやすく、変更時に停止を伴うことが多い。水平スケーリングと対比される選択肢。

    前提: 水平スケーリング(スケールアウト)単一障害点(SPOF)

  • GKE Autopilot

    GKE のクラスタ運用モードの一つで、ノードのプロビジョニング・スケーリング・アップグレード・セキュリティ強化まで Google がフルマネージドで行う。Pod 単位の課金で、ノードプールの構成や SSH アクセスは持てない代わりに運用負荷が最小になる。

    前提: マネージドサービス(管理の境界)

  • Transfer Appliance

    大量データを物理デバイスに格納して輸送し、Cloud Storage へ取り込むオフライン転送サービス。ネットワーク転送が現実的でない規模に向く。

    前提: Cloud Storage

  • GKE Enterprise(Anthos)

    オンプレミスや複数のクラウドにまたがって一貫した方法でコンテナを運用・管理できるプラットフォーム。ハイブリッド/マルチクラウドを実現する。

  • コネクション追跡

    ステートフルなファイアウォール(例:セキュリティグループ)が確立済みの接続を状態テーブルで記憶し、その戻り通信を自動的に許可する仕組み。ステートレスなルールと違い、戻り方向のエフェメラルポートを個別に開ける必要がない。

    前提: エフェメラルポート

  • Model Garden

    Google 製・オープン・サードパーティの多様な基盤モデルを一覧から選んで使える Vertex AI のカタログ。

    前提: Vertex AI

  • Classic VPN

    単一トンネルのゲートウェイで SLA 保証のない旧世代の IPSec VPN。ルートベース(動的)とポリシーベース(静的トラフィックセレクタ指定)の 2 方式があり、後者は特定の相手先ネットワーク機器との互換性のためだけに残っている。Google は非推奨とし、新規構築では HA VPN を案内する。

    前提: HA VPN

  • Cloud Code

    VS Code や IntelliJ 等の IDE に組み込む拡張機能。Kubernetes マニフェストや Dockerfile の作成支援、ローカルからの GKE/Cloud Run へのデプロイ、リモートクラスター上でのライブデバッグをエディタ内から行える。

    前提: Cloud Run

  • Cloud Endpoints

    OpenAPI/gRPC の API を Extensible Service Proxy 経由で管理し、認証・モニタリング・割り当てを付与する API 管理サービス。

    前提: gRPC

  • HA VPN

    冗長化された 2 本のトンネル(それぞれ別の外部 IP)を使い 99.99% の可用性 SLA を提供する、Google 推奨の IPSec VPN。オンプレミスや他クラウド・他 VPC との接続に使い、BGP による動的ルーティングを前提とする。新規構築では基本的にこちらを選ぶ。

  • Workload Identity Federation(GCP)

    AWS・Azure・オンプレミス・CI/CD(GitHub Actions 等)といった Google Cloud 外部の ID プロバイダを信頼し、その発行するトークンと引き換えに一時的な Google Cloud 認証情報を得られる仕組み。サービスアカウント鍵のダウンロード・配布を避けたい外部システム連携で使う。

    前提: サービスアカウント(Service account)

  • Dataplane V2

    eBPF ベースで実装された GKE のネットワーキングデータプレーン。Kubernetes NetworkPolicy(Pod 間の L3/L4 通信制御)をカーネルレベルで高効率に強制し、フローログによる可視化も提供する。GKE 1.20 以降の新規クラスタで既定化が進んでおり、従来の iptables ベース実装より少ないオーバーヘッドで動く。

  • イミュータブルインフラ

    稼働中のサーバーを変更せず、新しいイメージ(AMI/コンテナ)で作り直して入れ替える運用方式。構成ドリフトを排除し、ロールバックは旧バージョンへ戻すだけ。Blue/Green や Auto Scaling と相性が良い。

    前提: デプロイ戦略(カナリア/ブルー・グリーン/ロールバック)

  • JSON

    波括弧とキー・値のペアで構造化データを表す軽量なテキスト形式。API のリクエスト/レスポンスや IAM ポリシー・バケットポリシーのような権限定義など、機械可読性を重視する場面で広く使われる。

  • 最小権限の原則

    各アイデンティティ(人・アプリ・サービス)には、業務の遂行に必要な最小限の権限だけを与えるという設計原則。過剰な権限は誤操作や侵害時の被害範囲(ブラスト半径)を広げるため、IAM ロールやポリシー、権限境界を通じて継続的に絞り込む。

    前提: ブラストラディウス(影響範囲)

  • ブロードキャスト

    同一ネットワークセグメント内の全ホストへ一斉にデータを送る通信方式。多くのパブリッククラウドの仮想ネットワーク(VPC/VNet 相当)は既定でブロードキャストをサポートしないため、オンプレ前提のアプリをそのまま移行しようとすると設計の見直しが必要になる。

  • バルクヘッド(隔壁)

    リソースを区画に分離し、1 区画の過負荷や障害が他へ波及しないようにするパターン(船の防水隔壁が由来)。コネクションプールやスレッド、キュー、アカウント/セルを分けて影響を封じ込める。

    前提: コネクションプール

  • Cloud Load Balancing

    用途で選ぶロードバランサー:グローバル外部アプリケーション LB(L7・世界中の利用者を最寄りへ)、内部 LB(内部マイクロサービス)、ネットワーク LB(L4・TCP/UDP)。

    前提: マイクロサービス

  • 移行戦略(リフト&シフト/改善移行/リファクタ)

    リフト&シフト=そのまま移行(最速・変更最小)、改善して移行=少し最適化、リファクタリング=クラウドネイティブに作り替え(手間大・効果大)。要件で選ぶ。

  • アプリケーションデフォルト認証情報(ADC)

    アプリが Google Cloud へ認証する際の標準的な資格情報の解決方法。サービスアカウントや Workload Identity Federation と組み合わせ、鍵の直書きを避ける。

    前提: サービスアカウント(Service account)

  • Cloud SQL Auth Proxy

    公開 IP を露出させずに、IAM 認証と暗号化で Cloud SQL へ安全に接続するためのプロキシ。アプリからの DB 接続の推奨手段。

    前提: Cloud SQL

  • コネクションプール

    データベース接続を再利用して、接続の確立コストや接続枯渇を防ぐ仕組み。サーバーレス/高並行のアプリで特に重要。

  • Secret Manager

    API キー・パスワード・証明書などのシークレットを安全に保管・取得・ローテーションするマネージドサービス。コードへの埋め込みを避ける。

    前提: マネージドサービス(管理の境界)

  • 署名付き URL

    Cloud Storage のオブジェクトへ、期限付き・限定的なアクセスを公開せずに付与する URL。バケット全体を公開するのとは異なる。

    前提: Cloud Storage

  • Artifact Analysis

    コンテナイメージやパッケージの既知の脆弱性を検出するスキャン。Binary Authorization(署名済みのみデプロイ可)とは役割が別で、検出と強制を組み合わせて使う。

    前提: Binary Authorization

  • Private Service Connect

    インターネットを経由せず、特定のマネージドサービスや公開サービスへプライベート IP で接続する仕組み。公開 IP の露出を避けたい接続に使う。

    前提: マネージドサービス(管理の境界)

  • 合成モニタ

    エンドポイントやワークフローを能動的に定期チェックし、ユーザー視点で外形監視する仕組み。受動的な監視と併用して問題を先回りで検知する。

    前提: Workflows

  • Google Cloud Armor

    外部 Application LB の前段で適用するエッジ/バックエンドのセキュリティポリシー。WAF(SQLi/XSS/RFI)、高度な DDoS 防御と機械学習の Adaptive Protection、レート制限、bot 管理、Threat Intelligence を提供する。

    前提: レート制限

  • Cloud DNS ルーティングポリシーと分割ホライズン

    Cloud DNS の高度な解決機能。ジオロケーション(送信元地域で応答変更)とフェイルオーバー(プライマリ障害でバックアップへ)のルーティングポリシー、公開/非公開ゾーンで同名を別解決する分割ホライズン DNS を含む。

    前提: Cloud DNS

  • 動的ルーティングモード(グローバル/リージョナル)

    Cloud Router が学習した BGP 経路を伝播する範囲を決める VPC の設定。リージョナルは同一リージョンのみ、グローバルは全リージョンへ伝播する。複数リージョンへ広げるにはグローバルが必要。

    前提: Cloud Router

  • ハイブリッド DNS(転送ゾーン/インバウンドポリシー/DNS ピアリング)

    オンプレと Cloud DNS の双方向の名前解決を組む構成。転送ゾーンは Cloud からオンプレへ問い合わせ、インバウンドサーバーポリシーはオンプレから Cloud を解決、DNS ピアリングは別 VPC のゾーンを参照する。

    前提: Cloud DNS

  • Network Intelligence Center

    ネットワークの可視化・診断・最適化ツール群。Network Topology(可視化)、Connectivity Tests(経路/ファイアウォールの静的診断)、Performance Dashboard(パケットロス/レイテンシ)、Firewall Insights、Network Analyzer(自動の構成診断)、Flow Analyzer を含む。

    前提: 性能の指標(IOPS/スループット/帯域幅/レイテンシー)

  • ルート優先度

    同一宛先に複数のルートがあるときに、どれを採用するかを決める値。値が小さいほど優先される。ネットワークタグと組み合わせて適用先を絞れる。

  • Secure Web Proxy

    外向き(egress)の通信を URL や SNI に基づいて許可リスト制御するプロキシ。一般インターネット外向きの Cloud NAT とは異なり、「どこへ出てよいか」をアプリケーション層で制御する。

    前提: Cloud NAT

  • レート制限

    単位時間あたりに受け付けるリクエスト数の上限を管理し、過負荷や乱用(DoS・スクレイピング等)から後段のシステムを守る仕組み。API ゲートウェイや Web アプリケーションファイアウォールのレートベースルールとして実装されることが多い。

  • ブラストラディウス(影響範囲)

    障害や誤操作・侵害が及ぶ影響範囲。アカウント分離・複数リージョン/AZ・最小特権・セル分割で範囲を小さく保つ。範囲を限定する設計が回復力とセキュリティの基本。

  • フォールトトレランス(耐障害性)

    構成要素が壊れてもサービスを止めない設計。高可用性(早期復旧)より一段強く、障害時も中断なく稼働し続ける。冗長な並行系(アクティブ/アクティブ)・N+1 構成・複数 AZ への分散で実現する(自動復旧は中断を伴うため高可用性側の手段)。

  • 単一障害点(SPOF)

    そこが壊れるとシステム全体が止まる箇所。マルチ AZ 配置・冗長化・ロードバランサ・自動フェイルオーバーで排除する。可用性設計の出発点=SPOF を洗い出して潰す。

  • サブネットマスク

    IP アドレスのうちネットワーク部とホスト部の境界を示す値(例 255.255.255.0)。CIDR のプレフィックス長と表裏一体の表現で、オンプレのネットワーク機器や一部のクラウド設定ではこのドット区切り表記が使われる。

    前提: CIDR 表記