Instiq

Google Cloud Digital Leader のナレッジマップ

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

概念一覧(124)

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

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

    前提: 責任共有モデル

  • Cloud Storage

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

  • サーバーレス(FaaS)

    サーバー管理が不要で、イベント時だけコードを実行し実行分だけ課金する形態(例:AWS Lambda)。

  • Cloud Run

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

  • 暗号化

    データを鍵で変換し許可された者だけが復号できるようにする技術。対称鍵/非対称鍵、保管時/転送時がある。

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

  • Compute Engine

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

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

  • CIA(機密性・完全性・可用性)

    情報セキュリティの3要素:機密性(Confidentiality)・完全性(Integrity)・可用性(Availability)。

  • 暗号鍵(GMEK / CMEK / CSEK)

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

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

    関連: Cloud KMS

  • BigQuery

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

    前提: サーバーレス(FaaS)

  • Spanner

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

    前提: CIA(機密性・完全性・可用性)高可用性(HA)強整合性(strong consistency)

  • Vertex AI

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

    前提: 機械学習(ML)

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

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

    前提: Cloud Storage

    関連: 暗号化

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

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

  • Cloud VPN

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

    前提: 暗号化

  • App Engine

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

    前提: マネージドサービス(管理の境界)PaaS(Platform as a Service)

  • BigQuery ML

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

    前提: BigQuery機械学習(ML)

  • Gemini

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

    前提: 生成 AI

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

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

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

    関連: 暗号化

  • 機械学習(ML)

    データから規則(パターン)を学び、新しいデータに対して予測を行う技術。AIの土台。

  • Cloud Interconnect

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

    前提: Cloud VPN暗号化

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

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

    関連: Cloud TraceCloud LoggingCloud Monitoring

  • スケーラビリティ

    需要に応じて能力を増減できること。スケールアップ=垂直(1台を大きく)、スケールアウト=水平(台数を増やす)。

  • エラーバジェット

    SLOから逆算される許容可能な失敗量(1−SLO)。バジェットが残っていればリスクを取った変更を進め、使い切れば新機能より安定化を優先する、というリリース判断の共通言語として使う。ポストモーテム(非難なき事後検証)でバジェット消費の原因を学び、再発防止に活かす。

    関連: SLI(サービスレベル指標)

  • Eventarc

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

    前提: Cloud FunctionsCloud RunCloud StoragePub/Sub

  • Cloud Functions

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

    前提: サーバーレス(FaaS)

  • Cloud Logging

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

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

  • Cloud Monitoring

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

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

  • Pub/Sub

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

  • サイト信頼性エンジニアリング(SRE)

    ソフトウェアの考え方で運用を行い、信頼性を SLO(サービスレベル目標)やエラーバジェットといった測定可能な目標で管理する Google 発の手法。

    前提: エラーバジェット

  • 消費ベースの課金(従量課金)

    確保した容量ではなく実際に使った分だけ支払う料金体系。初期投資が不要で無駄が少ない。

  • API Gateway(Google Cloud)

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

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

  • Cloud Deploy

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

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

    関連: Cloud Build

  • SLI(サービスレベル指標)

    SRE(Site Reliability Engineering)で信頼性を定量化するための実測指標。成功率・レイテンシ・可用性など、ユーザー体験に直結する値を継続的に測定する。SLOの目標値と対比させて達成度を評価する土台となる。

    前提: サイト信頼性エンジニアリング(SRE)CIA(機密性・完全性・可用性)

    関連: エラーバジェットSLO(サービスレベル目標)

  • Vertex AI AutoML

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

    前提: BigQueryBigQuery MLVertex AI

    関連: Tabular Workflows

  • 課金アカウントと予算

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

  • Ops Agent

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

    前提: Cloud LoggingCloud MonitoringCompute Engine

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

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

    前提: Cloud Storage

  • Cloud KMS

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

    前提: 暗号化

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

  • Workflows

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

    前提: サーバーレス(FaaS)

  • CapEx(資本的支出)

    設備や機器を前払いで購入・所有する支出。オンプレのデータセンター構築のように、大きな初期投資が発生し、資産として長期にわたり減価償却する。クラウド以前の伝統的なIT投資モデルの中心だった。

  • BeyondCorp

    ネットワークの場所ではなくユーザーとデバイスの検証に基づいてアクセスを許可する、Google のゼロトラスト実装。

    前提: ゼロトラスト

  • Cloud SQL

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

  • Firestore

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

  • GKE Enterprise(Anthos)

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

  • リソース階層

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

  • Spot VM

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

    前提: Compute Engine

  • 結果整合性(eventual consistency)

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

    前提: CIA(機密性・完全性・可用性)高可用性(HA)

    関連: 強整合性(strong consistency)

  • Cloud Build

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

    前提: サーバーレス(FaaS)

    関連: Cloud DeployArtifact Registry

  • 高可用性(HA)

    障害があってもサービスを動かし続けられるように設計すること(冗長化・可用性ゾーンなど)。

    前提: CIA(機密性・完全性・可用性)

  • IaaS(Infrastructure as a Service)

    仮想マシンなどのインフラを借りるモデル。OSから上は利用者が管理し、最も自由度が高い(例:Azure Virtual Machines)。

  • OpEx(運用支出)

    使った分だけ継続的に支払う支出。クラウドの従量課金はこのモデルで、初期投資を抑え需要に応じて費用を伸縮できる。CapExからOpExへの転換はクラウド移行の主要な財務メリットとして語られる。

    前提: CapEx(資本的支出)消費ベースの課金(従量課金)

  • PaaS(Platform as a Service)

    アプリの実行基盤を借りるモデル。OS・ランタイムは事業者が管理し、利用者はアプリとデータに集中(例:App Service)。

  • Cloud External Key Manager(Cloud EKM)

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

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

  • VPC Service Controls

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

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

  • Cloud CLI エミュレータ

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

    前提: FirestorePub/SubSpanner

  • Google Cloud Armor

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

    前提: 機械学習(ML)

  • Cloud CDN

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

    前提: Cloud RunCloud Storage

  • Cloud Router

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

    前提: ルート優先度

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

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

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

  • SLO(サービスレベル目標)

    SLIに対して組織が設定する目標値(例:可用性99.9%)。契約上の約束であるSLA(サービスレベル合意)より内部的・保守的に設定されることが多く、SLOを下回りそうな兆候はエラーバジェットの消費で把握する。

    前提: CIA(機密性・完全性・可用性)エラーバジェット

    関連: SLI(サービスレベル指標)

  • Tabular Workflows

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

    前提: WorkflowsVertex AI

    関連: Vertex AI AutoML

  • Cloud DNS

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

  • Cloud NAT

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

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

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

    前提: Compute Engine

  • Storage Transfer Service

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

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

  • 弾力性(Elasticity)

    負荷に応じて自動で能力を増減すること(オートスケール)。スケーラビリティを自動化したもの。

    前提: スケーラビリティ

  • Cloud Billing(課金)

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

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

  • Deployment Manager

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

    前提: Infrastructure as Code(IaC)Infrastructure Manager

  • Filestore

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

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

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

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

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

  • HA VPN

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

    前提: CIA(機密性・完全性・可用性)

  • Gemini Cloud Assist

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

    前提: Gemini

    関連: Gemini Code Assist

  • Gemini Code Assist

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

    前提: Gemini

    関連: Gemini Cloud Assist

  • 生成 AI

    学習データをもとに文章・画像・コードなど新しいコンテンツを生成するAI。分類/回帰とは別用途。

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

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

    前提: スケーラビリティ

  • Infrastructure as Code(IaC)

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

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

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

  • 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デプロイ戦略(カナリア/ブルー・グリーン/ロールバック)

  • Cloud SQL Auth Proxy

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

    前提: Cloud SQL暗号化

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

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

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

  • Cross-Cloud Interconnect

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

    前提: Cloud VPNCloud Interconnect

  • VLAN アタッチメント

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

    前提: Cloud InterconnectCloud Router

  • 責任共有モデル

    セキュリティと運用の責任をプロバイダーと利用者で分担する考え方。境界はサービスモデルで動き、データ・ID・デバイスは常に利用者。

  • 強整合性(strong consistency)

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

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

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

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

    前提: 水平スケーリング(スケールアウト)スケーラビリティ

  • ゼロトラスト

    「決して信頼せず、常に検証する」という指針。内側でも毎回ID・デバイス・状況を検証する。

  • Config Connector

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

    前提: Infrastructure as Code(IaC)

  • GKE Autopilot

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

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

  • 組織ポリシー(Organization Policy)

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

    前提: リソース階層

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

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

    前提: VPC(Virtual Private Cloud)

  • Transfer Appliance

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

    前提: Cloud Storage

  • Amazon Managed Service for Prometheus (AMP)

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

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

  • コンテナ化

    アプリと依存関係を 1 つのイメージにまとめ、どこでも同じように動かす技術。VM より軽量・高速起動で、密度とポータビリティが高い。AWS では ECR(保管)+ECS/EKS(実行)+Fargate(サーバーレス実行)で運用する。

    前提: サーバーレス(FaaS)

  • 規模の経済(クラウドの価値)

    AWS が多数の顧客の需要を束ねることで単価が下がり、その分が値下げとして還元される考え方。使った分だけ支払う従量課金、初期投資不要、グローバル展開の容易さと並ぶクラウドの基本価値。

    前提: 消費ベースの課金(従量課金)

  • 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

  • VPC(Virtual Private Cloud)

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

  • 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 ベース実装より少ないオーバーヘッドで動く。

  • IP マスカレード(GKE)

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

    前提: Dataplane V2

  • Cloud Trace

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

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

  • Infrastructure Manager

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

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

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

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

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

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

  • Artifact Registry

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

    関連: Cloud Build

  • コネクションプール

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

    前提: サーバーレス(FaaS)

  • gRPC

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

  • Identity-Aware Proxy(IAP)

    ユーザーの ID に基づいてアプリやリソースへのアクセスを保護する仕組み。VPN なしで安全に公開でき、ゼロトラスト的なアクセス制御を実現する。

    前提: ゼロトラスト

  • Memorystore

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

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

  • Secret Manager

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

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

  • 署名付き URL

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

    前提: Cloud Storage

  • Artifact Analysis

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

    前提: Binary Authorization

  • Private Service Connect

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

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

  • 合成モニタ

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

    前提: Workflows

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

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

    前提: Cloud DNS

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

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

    前提: Cloud Router

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

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

    前提: Cloud DNS

  • ルート優先度

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

  • Secure Web Proxy

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

    前提: Cloud NAT

  • プロビジョンド vs サーバーレス

    容量モデルの対比。プロビジョンド=事前に容量を確保(予測可能な負荷・常時稼働で割安なことも)。サーバーレス=需要に自動追従し使った分だけ課金・容量管理不要(断続的/予測困難な負荷向け)。Aurora・DynamoDB・Lambda 等で選択肢になる。

    前提: サーバーレス(FaaS)