Instiq

Google Cloud Associate Data Practitioner のナレッジマップ

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

概念一覧(128)

  • BigQuery

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

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

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

  • Cloud Storage

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

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

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

  • Cloud Run

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

  • Eventarc

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

    前提: Cloud FunctionsCloud RunCloud StoragePub/Sub

  • Workflows

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

    前提: Cloud Composer

  • Compute Engine

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

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

  • Storage Transfer Service

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

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

  • Cloud Composer

    Apache Airflow ベースのマネージドなオーケストレーション。依存のある複数ステップのパイプラインをスケジュール・実行する。

  • Cloud KMS

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

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

  • Dataproc

    既存の Spark / Hadoop ワークロードをマネージドで実行するサービス。Dataflow(Beam)とは用途が異なる。

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

  • 暗号鍵(GMEK / CMEK / CSEK)

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

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

    関連: Cloud KMS

  • スケジュールされたクエリ

    BigQuery で定期的に同じクエリ(集計など)を自動実行する手軽な機能。複雑な依存は Cloud Composer。

    前提: Cloud ComposerBigQuery

  • Cloud Logging

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

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

  • Cloud Monitoring

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

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

  • Cloud SQL

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

  • Spanner

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

    前提: 強整合性(strong consistency)

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

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

    前提: Cloud Storage

  • Cloud Deploy

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

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

    関連: Cloud Build

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

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

  • Cloud Interconnect

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

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

  • Vertex AI AutoML

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

    前提: BigQueryBigQuery MLVertex AI

    関連: Tabular Workflows

  • Tabular Workflows

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

    前提: WorkflowsVertex AI特徴量エンジニアリングと埋め込み/RAG

    関連: Vertex AI AutoML

  • AlloyDB

    高性能な PostgreSQL 互換のマネージドデータベース。

  • Ops Agent

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

    前提: Cloud LoggingCloud MonitoringCompute Engine

  • Cloud Data Fusion

    コードをあまり書かずにビジュアルで ETL/ELT パイプラインを構築できるマネージドサービス。

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

  • ライフサイクルルール

    Cloud Storage で「作成から N 日後に削除」「N 日後に安いクラスへ移行」を自動化し、コストを最適化するルール。BigQuery では有効期限が同様の役割。

    前提: BigQueryCloud Storage

  • Transfer Appliance

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

    前提: Cloud Storage

  • Bigtable

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

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

  • Cloud Functions

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

  • Dataflow

    バッチとストリーミングの両方に対応するデータ処理パイプラインのサービス。

  • Firestore

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

  • Vertex AI

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

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

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

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

  • ETL(抽出・変換・格納)

    データ統合パターンの一つ。ソースからデータを抽出し、格納先に入れる前に変換(クレンジング・整形・集計)を行う。変換用の別コンピュート(サーバーやマネージドサービス)を要するが、格納先には整った形のデータだけが入る。

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

  • API Gateway(Google Cloud)

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

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

  • 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/スループット/帯域幅/レイテンシー)

  • JSON

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

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

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

  • VPC Service Controls

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

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

  • Cloud CLI エミュレータ

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

    前提: FirestorePub/SubSpanner

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

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

    関連: Cloud TraceCloud LoggingCloud Monitoring

  • Database Migration Service(Google Cloud DMS)

    MySQL/PostgreSQL などを Cloud SQL や AlloyDB へ継続的レプリケーション付きで移行する Google のマネージドサービス。最小ダウンタイムのカットオーバーを支援する。

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

  • Cloud Router

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

    前提: ルート優先度

  • Cross-Cloud Interconnect

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

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

  • BigQuery Data Transfer Service

    SaaS や他のデータウェアハウスから BigQuery へデータを定期的に取り込むマネージドサービス。DB の移行は Database Migration Service と用途が異なる。

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

  • 強整合性(strong consistency)

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

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

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

  • YAML

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

    前提: JSON

  • Cloud DNS

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

  • Cloud NAT

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

  • Cloud VPN

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

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

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

    前提: Compute Engine

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

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

    前提: Cloud Storage

  • Analytics Hub

    BigQuery のデータセットを、コピーを作らずに社内外の他組織と安全に共有・受領できるサービス。

    前提: BigQuery

  • Dataform

    BigQuery 内の SQL ベースの変換(ELT)を、依存関係やバージョン管理とともに開発・運用できるサービス。

    前提: BigQuery

  • Looker Studio

    手軽にレポートやダッシュボードを作成・共有できる可視化(BI)ツール。

    前提: Looker

  • LookML

    Looker でデータのメトリクスやディメンションを定義するモデリング言語。指標の一貫性を保つ。

    前提: Looker

  • 均一バケットレベルアクセス

    Cloud Storage で、オブジェクトごとの ACL を使わずバケット単位で IAM により権限を一元管理する推奨設定。簡潔で安全。

    前提: Cloud Storage

  • App Engine

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

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

  • BigQuery ML

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

    前提: BigQuery

  • Gemini

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

  • Looker

    分析結果をダッシュボードで可視化し、ビジネスでの活用を支えるビジネスインテリジェンス(BI)。

  • Pub/Sub

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

  • 結果整合性(eventual consistency)

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

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

    関連: 強整合性(strong consistency)

  • Cloud Billing(課金)

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

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

  • Deployment Manager

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

    前提: Infrastructure ManagerYAML

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

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

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

  • Gemini Cloud Assist

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

    前提: Gemini

    関連: Gemini Code Assist

  • Gemini Code Assist

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

    前提: Gemini

    関連: Gemini Cloud Assist

  • Cloud External Key Manager(Cloud EKM)

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

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

  • Cloud Trace

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

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

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

  • 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/スループット/帯域幅/レイテンシー)

  • Memorystore

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

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

  • Cloud CDN

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

    前提: Cloud RunCloud Storage

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

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

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

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

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

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

  • VLAN アタッチメント

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

    前提: Cloud InterconnectCloud Router

  • BigLake

    Cloud Storage などのデータを移動せずに BigQuery から統一的に扱えるようにするストレージエンジン。レイクとウェアハウスを橋渡しする。

    前提: BigQueryCloud Storage

  • 課金アカウントと予算

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

  • GKE Autopilot

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

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

  • 組織ポリシー(Organization Policy)

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

    前提: リソース階層

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

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

    前提: VPC(Virtual Private Cloud)

  • Amazon Managed Service for Prometheus (AMP)

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

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

  • GKE Enterprise(Anthos)

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

  • リソース階層

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

  • Sensitive Data Protection(Cloud DLP)

    保存データから個人情報などの機微データを自動で発見・分類し、マスキングできるサービス。

    関連: 機密データ保護(PII / マスキング)

  • Spot VM

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

    前提: Compute Engine

  • 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 による動的ルーティングを前提とする。新規構築では基本的にこちらを選ぶ。

  • 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

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

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

  • Infrastructure Manager

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

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

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

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

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

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

  • Artifact Registry

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

    関連: Cloud Build

  • Cloud SQL Auth Proxy

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

    前提: Cloud SQL

  • Secret Manager

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

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

  • 署名付き URL

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

    前提: Cloud Storage

  • メンテナンスウィンドウ

    マネージドデータベースの計画的なメンテナンス(パッチ/マイナーバージョン更新等)を実施する時間帯。可用性要件に合わせ、業務影響の小さい時間帯に設定して計画停止を制御する。

    前提: ウィンドウと遅延データ(ストリーミング)

  • リバースレプリケーション

    移行のカットオーバー後に新環境から旧環境へ書き戻す仕組み。問題発生時に旧環境へ安全に切り戻すためのロールバック保険になる。

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

  • 同期/非同期レプリケーション

    同期レプリケーションは RPO≈0 だが書き込み遅延が増える。非同期は遅延が小さいが障害時にデータ損失の可能性がある。RPO 要件で選ぶ。

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

  • 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

  • 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

  • BI Engine とマテリアライズドビュー

    BI Engine は BigQuery のインメモリ分析を高速化する。マテリアライズドビューはよく使う集計を事前計算しておく。ダッシュボードの応答を速くする別々の手段(併用可)。

    前提: BigQuery

  • BigQuery Editions と予約(reservations)

    安定利用のコンピュート容量を予測可能なコストで確保する仕組み。少量・不定期はオンデマンドが向く。

    前提: BigQuery

  • 特徴量エンジニアリングと埋め込み/RAG

    特徴量エンジニアリングは学習・サービング向けにデータを整える作業。生成 AI では非構造化データを埋め込み(embeddings)にし、検索拡張生成(RAG)で関連情報を取り出して回答に使う。

  • パーティションとクラスタリング(BigQuery)

    パーティションはテーブルを日付などで分割し、クラスタリングはよく絞る列で行を整列する。どちらもスキャン量を減らし BigQuery のコスト/性能を最適化する。

    前提: BigQuery

  • ウィンドウと遅延データ(ストリーミング)

    ストリーミングでは、時間で区切って集計するウィンドウと、遅れて到着するデータ(late data)をウォーターマークと許容遅延で扱う設計が要る。バッチは溜めてまとめて処理。

  • 機密データ保護(PII / マスキング)

    PII(個人を特定できる情報)や PHI などの機密データを守る運用。Macie で検出・分類し、暗号化・アクセス制御・最小化で保護。マスキング/トークン化で値を秘匿し、データ分類に応じて扱いを変える。ログへの機密混入も防ぐ。

    関連: Sensitive Data Protection(Cloud DLP)

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

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

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