Google Cloud Associate Cloud Engineer試験時の学習メモ

Google Cloud Associate Cloud Engineer受験時の学習内容をまとめたもの。公式の試験概要より、指定されている範囲のサービスを触ってみた記録です。

目次

1. クラウド ソリューション環境の設定

1.1 クラウド プロジェクトとアカウントを設定する。以下のような作業を行います。

プロジェクトを作成する

プロジェクトの作成と管理

プロジェクトを作成する。

$ gcloud projects create --name=sample \
[--organization=ORGANIZATION_ID] [--folder=FOLDER_ID]    # OrganizationやFolder配下に作成する場合

gcloud projects create

プロジェクト内で事前定義された IAM ロールにユーザーを割り当てる

ユーザー(メンバー)の種類。

IDに関するコンセプト

Projectを対象に、IAM Roleをメンバーに割り当て。

$ gcloud projects add-iam-policy-binding sample-123456 --member='user:kiritan@goodbyegangster.com' --role='roles/storage.objectViewer'
$ gcloud projects add-iam-policy-binding sample-123456 --member='serviceaccount:sample@sample-123456.iam.gserviceaccount.com' --role='roles/bigquery.dataViewer'
$ gcloud projects add-iam-policy-binding sample-123456 --member='group:group@goodbyegangster.com' --role='roles/appengine.deployer''

gcloud projects add-iam-policy-binding

Cloud Identity でユーザーを管理する（手動および自動）

Cloud IdentityとはGoogleが提供するIDaaSのこと。

Cloud Identity ヘルプ - GCP 管理者向けの設定手順

Google Cloudのリソース階層。

  • Organization
    • Google WorkspaceまたはCloud Identityにて管理されるドメイン
      • Google Cloudの機能ではない
  • Folders
    • Projectを束ねるもの
      • Google Cloudの機能ではあるものの、Organizationが存在しないと作成できない
  • Projects
  • Resources

Google Cloud リソース階層の詳細

フォルダの作成。

フォルダの作成と管理

$ gcloud resource-manager folders create \
--display-name=sample \
--organization=ORAGANIZATION-ID             # 上位となるOrganization IDを指定

gcloud resource-manager folders create

各階層(Organization, Folder, Project, 一部のResource)を対象に、IAM Roleをメンバーに割り当てることができる。上位階層に割り当てられた権限は、下位の階層に継承される。

Organizationを対象に、IAM Roleをメンバーに割り当てる。

$ gcloud organization add-iam-policy-bindings ORGANIZATION-ID --member='user:zunko@goodbyegangster.com' --role='role/editor'

gcloud organization add-iam-policy-bindings

フォルダを対象に、IAM Roleをメンバーに割り当てる。

$ gcloud resource-manager folders add-iam-policy-bindings FOLDER-ID --member='user:akane@goodbyegangster.com' --role='role/editor'

gcloud resource-managers folders add-iam-policy-bindings

プロジェクトで API を有効にする

サービスの有効化と無効化

APIを有効化。

$ gcloud services enable storage.googleapis.com

gcloud services enable

Stackdriver ワークスペースをプロビジョニングする

プロジェクトの Cloud Monitoring 構成を変更する

1.2 課金構成を管理する。以下のような作業を行います。

請求先アカウントを作成する

Cloud 請求先アカウントの作成、変更、閉鎖

プロジェクトを請求先アカウントにリンクする

$ gcloud beta billing projects link sample-123456 --billing-account=012345-012345-012345

gcloud beta billing projects link

課金の予算とアラートを設定する

予算と予算アラートの設定

budgetの作成。thresholdの値が100倍して登録される。JPYだからか。

$ gcloud alpha billing budgets create \
--display-name=sample-budget \
--billing-account=123456-123456-123456  \
--budget-amount=10000JPY \
--threshold-rule=percent=50 \
--threshold-rule=percent=75,basis=forecasted-spend

gcloud alpha billing budgets create

日 / 月単位の料金見積もりを目的として請求関連のエクスポートを設定する

BigQuery への Cloud Billing のエクスポート機能を使用することで、指定した BigQuery データセットに Google Cloud の詳細な課金データ（使用量、費用予測、料金データなど）を終日、自動的にエクスポートできます。

Cloud Billing データを BigQuery にエクスポートする

1.3 コマンドライン インターフェース（CLI）、具体的には Cloud SDK をインストール、構成する（例: デフォルト プロジェクトの設定）。

googleアカウントのクレデンシャルを、WEBベースで取得する。

$ gcloud auth login

gcloud auth login

gcloud configurationを新規追加する。

$ gcloud config configurations create sample

gcloud config configurations create

作成したconfiguration(現在アクティブなconfiguration)にprojectを紐付ける。

$ gcloud config set project sample-123456

gcloud config set

作成したconfiguration(現在アクティブなconfiguration)にGoogleアカウントを紐付ける。

$ gcloud config set account zunko@goodbyegangster.com

作成したconfigurationにデフォルトリージョン・ゾーンを設定する。

$ gcloud config set compute/region asia-northeast1
$ gcloud config set compute/zone asia-northeast1-a

作成済みconfigurationの一覧を表示する。

$ gcloud config configurations list
NAME         IS_ACTIVE  ACCOUNT                     PROJECT               COMPUTE_DEFAULT_ZONE  COMPUTE_DEFAULT_REGION
sample       True       zunko@goodbyegangster.com   sample-123456         asia-northeast1-a     asia-northeast1

gcloud config configurations list

activeなconfigurationにスイッチする。

$ gcloud config configurations activate sample

gcloud config configurations activate

コマンド実行時に利用configurationを指定する方法。

$ gcloud compute instances list --configurations=sample

2. クラウド ソリューションの計画と構成

2.1 料金計算ツールを使用して GCP プロダクトの使用量を計画して見積もる

Google Cloud Pricing Calculator

2.2 コンピューティング リソースを計画、構成する。以下のような点を考察します。

ワークロードに適したコンピューティング サービス（例: Compute Engine、Google Kubernetes Engine、App Engine、Cloud Run、Cloud Functions）の選択

Googke Cloudサービス名 サービス AWSで相当するサービス
Google Compute Engine IaaS Amazon EC2
Google Kubernetes Engine Managed Kubernetes Service Amazon EKS
Google App Engine PaaS AWS Elastic Beanstalk
Google Cloud Run Managed Container Service AWS Fargate
Google Cloud Function FaaS AWS Lambda

プリエンプティブル VM とカスタム マシンタイプの適宜使用

プリエンプティブル・インスタンスとは

プリエンプティブル VM は、通常のインスタンスよりはるかに低価格で作成、実行できるインスタンスです。ただし、他のタスクがリソースへのアクセスを必要とする場合、Compute Engine がこのインスタンスを停止（プリエンプト）する可能性があります。プリエンプティブル インスタンスは Compute Engine の余剰のキャパシティを利用する機能であり、使用できるかどうかは利用状況に応じて異なります。

プリエンプティブル VM インスタンス

gcloud compute では、通常のインスタンスを作成する場合に使用するものと同じ instances create コマンドを使用しますが、--preemptible フラグを追加します。

$ gcloud compute instances create [INSTANCE_NAME] --preemptible

プリエンプティブル VM インスタンスの作成と起動

カスタム マシンタイプ

事前定義されたマシンタイプがニーズに合わない場合は、カスタムの仮想ハードウェア設定を使用して VM インスタンスを作成できます。具体的には、カスタム マシンタイプを効果的に利用して、vCPU の数とメモリ容量をカスタマイズした VM インスタンスを作成できます。カスタム マシンタイプは、汎用マシンタイプでのみ使用できます。カスタム マシンタイプを作成すると、E2、N2、N2D、または N1 マシンタイプ ファミリーからカスタム マシンタイプを効果的にデプロイできます。

$ gcloud compute instances create example-instance --custom-cpu=6 --custom-memory=3072MB --custom-vm-type=n2

カスタム マシンタイプの VM インスタンスを作成する

2.3 データ ストレージ オプションを計画、構成する。以下のような点を考察します。

プロダクト（例: Cloud SQL、BigQuery、Cloud Spanner、Cloud Bigtable）の選択

Google Cloudサービス名 サービス AWSで相当するサービス
Cloud SQL Managed Relational Database Service(MySQL, PostgreSQL, MS SQLServer) Amazon RDS
BigQuery Data Warehouse Amazon Redshift
Cloud Spanner 水平スケーリング可能な分散RDB Aurora Serverless
Cloud Bigtable Managed 分散 NoSQL, KV型, Bigdata ? Amazon Timestream

ストレージ オプション（例: Standard、Nearline、Coldline、Archive）の選択

GCSのストレージクラスについて。

Storage Class 最低保存期間(日) ストレージ料金($) クラスAオペレーション料金($) ※10000オペレーションあたり 適するデータ
Standard なし 0.023 0.05 頻繁にアクセスされるデータ
Nearline 30 0.016 0.10 月に1回程度アクセスされるデータ
Coldline 90 0.006 0.10 四半期に1回程度アクセスされるデータ
Archive 365 0.0025 0.50 1年間に1回未満しかアクセスしないデータ

ストレージ クラス

Cloud Storage の料金

2.4 ネットワーク リソースを計画、構成する。以下のようなタスクを行います。

負荷分散オプションの違いを見分ける

ロードバランサを選ぶためのフローチャート

ロードバランサー種類 トラフィックの種類 クライアントIPの保持 グローバルorリージョン 負荷分散スキーム 宛先ポート プロキシorパススルー
External HTTP(S) HTTP
HTTPS 		x グローバル(※) EXTERNAL HTTP: 80, 8080
HTTPS: 443 		プロキシ
Internal HTTP(S) HTTP
HTTPS 		x リージョン INTERNAL_MANAGED HTTP: 80, 8080
HTTPS: 443 		プロキシ
SSL プロキシ TCP
SSLオフロード 		x グローバル(※) EXTERNAL Google Cloudにより限定された複数ポート プロキシ
TCP プロキシ TCP
SSLオフロードなし 		x グローバル(※) EXTERNAL Google Cloudにより限定された複数ポート プロキシ
External TCP/UDP Network TCP
UDP 		o リージョン EXTERNAL 任意 パススルー
Internal TCP/UDP TCP
UDP 		o リージョン INTERNAL 任意 パススルー

※プレミアムティアではグローバル、スタンダードティアでは実質的にリージョン

Google Cloud ロードバランサの概要

Network Service Tiers を使用すると、インターネット上のシステムと Google Cloud インスタンス間の接続を最適化できます。プレミアム ティアは Google のプレミアム バックボーンでトラフィックを配信し、スタンダード ティアは通常の ISP ネットワークを使用します。

Network Service Tiers の概要

ロードバランサー毎の機能一覧表。

ロードバランサの機能

可用性を考慮してネットワーク内のリソースのロケーションを決定する

Compute Engine のリージョン選択に関するベスト プラクティス

Cloud DNS を構成する

Cloud DNS は、高パフォーマンスで復元力を備えたグローバル ドメインネーム システム（DNS）サービスで、費用対効果の高い方法でグローバル DNS にドメイン名を公開します。

Cloud DNS の概要

3. クラウド ソリューションのデプロイと実装

3.1 Compute Engine リソースをデプロイ、実装する。以下のようなタスクを行います。

Cloud Console と Cloud SDK（gcloud）を使用してコンピューティング インスタンスを起動する（例: ディスク、可用性ポリシー、SSH 認証鍵の割り当て）

VM インスタンスの作成と起動

VMインスタンスの作成。

$ gcloud compute instances create VM_NAME \
    [--image=IMAGE | --image-family=IMAGE_FAMILY] \
    --image-project=IMAGE_PROJECT \
    --machine-type=MACHINE_TYPE \
    --zone=asia-northeast1-a \
    --subnet=default \
    --network-tier=PREMIUM \
    --boot-disk-size=30GB \                 # ブートディスク
    --boot-disk-type=pd-ssd \               # ブートディスク
    --boot-disk-device-name=vm-name \       # ブートディスク
    --create-disk=mode=rw,size=100,type=projects/project-name/zones/us-central1-a/diskTypes/pd-balanced,name=add-disk,device-name=add-disk \    # 追加ディスク
    --maintenance-policy=(MIGRATE or TERMINATE) \       # 可用性ポリシー：onHostMaintenance
    [--no-restart-on-failure] \                         # 可用性ポリシー：automaticRestart
    --metadata-from-file=./startup.sh       # 起動スクリプトの指定

gcloud compute instances create

メタデータに渡すことで、起動スクリプトは直接コードを記述することも可能。

$ gcloud compute instances create VM_NAME \
--metadata startup-script='#! /bin/bash
  sudo su -
  apt update
  EOF'

起動スクリプトの実行

GCEのディスクタイプ

利用可能なストレージ。

永続ディスクのディスクタイプ。

  • 標準永続ディスク(pd-standard)
    • HDD
  • バランス永続ディスク(pd-balanced)
    • SSD
    • パフォーマンスとコストのバランスが良い
  • SSD永続ディスク(pd-ssd)
  • エクストリーム永続ディスク(pd-extreme)
    • SSD
    • 高パフォーマンス
    • IOPSを指定可能

ストレージ オプション

可能性ポリシー

onHostMaintenance プロパティと automaticRestart プロパティを使ってインスタンスのメンテナンス動作と自動再起動を構成します。

インスタンス可用性ポリシーの設定

  • onHostMaintenance
    • メンテナンス・イベントが発生時の動作を指定
    • プロパティ値
      • MIGRATE(default)
      • TERMINATE
  • automaticRestart
    • インスタンス・クラッシュ時の動作を指定
    • プロパティ値
      • true(default)
      • false

インスタンス テンプレートを使用して、自動スケーリングされるマネージド インスタンス グループを作成する

マネージド・インスタンス・グループ(MIG) は、単一のエンティティとして制御する仮想マシン（VM）インスタンスのグループです。MIG は、自動修復、負荷分散、自動スケーリング、自動更新、ステートフル ワークロードなどの機能をサポートしています。

マネージド インスタンス グループの作成

マネージド・インスタンス・グループ(MIG)の種類。

  • ステートレスMIG
    • ステートレス サービスやバッチ ワークロード
      • ウェブサイトのフロントエンド、キューからの画像処理など
  • ステートフルMIG
    • ステートフル アプリケーション
      • でータベースやレガシー アプリケーションなど

VMインスタンスの分配形態。

  • リージョンMIG
    • リージョン単位で分配
  • ゾーンMIG
    • ゾーン単位で分配

ゾーン分配の、ステートレスMIGの作成。

$ gcloud compute instance-groups managed create sample-mig \
--size=2 \
--template=sample-template \
--zone=asia-northeast1-b

gcloud compute instance-groups managed create

インスタンス用のカスタム SSH 認証鍵を生成、アップロードする

メタデータ内の SSH 認証鍵の管理

SSH認証鍵の適用範囲。

プロジェクト全体SSH認証鍵の登録。

$ gcloud compute project-info add-metadata --metadata-from-file ssh-keys=[LIST_PATH]

LIST_PATHにSSH公開鍵のPATHを指定して登録する訳だが、個別でSSH公開鍵を登録できないため、コンソールからやるほうが良い。

gcloud compute project-info add-metadata

VMインスタンスでの、プロジェクト全体SSH認証鍵の利用制御。

$ gcloud compute instances add-metadata sample-instance --metadata=block-project-ssh-keys=[TRUE/FALSE]

VMインスタンス作成時にも、--metadataオプションを付与して設定できる。

gcloud compute instances add-metadata

VMインスタンス単位でのSSH認証鍵の登録。

$ gcloud compute instances add-metadata [INSTANCE_NAME] --metadata-from-file ssh-keys=[LIST_PATH]

プロジェクト全体と同じくLIST_PATHにSSH公開鍵のPATHを指定して登録する訳だが、こちらも個別でSSH公開鍵を登録できないため、コンソールからやるほうが良い。

VM で Stackdriver Monitoring と Stackdriver Logging の構成を行う

Stackdriverは、Google Cloud Operation Suiteという後継サービスになっている。Google Cloud Operation Suite内に、メトリクス管理用のCloud Monitoring、ログ管理用のCloud Logging等のサービスがある。

Google Cloud のオペレーション スイート（旧称 Stackdriver）

Cloud Monitoringの構成

Cloud Monitoring Agentを利用する。標準のOSイメージには同梱済み。インストール時の初期設定のまま、基本的なOSのメトリクスを取得できる。

Cloud Monitoring エージェントの概要

NginxやRedis等の、特定のミドルウェア向けのモニタリング・プラグインが用意されている。プラグインを有効にすることで、対象のミドルウェアのメトリクスを取得可能となる。

サードパーティ製アプリケーションのモニタリング

Cloud loggingの構成

Cloud Logging Agentを利用する。Cloud Logging Angetはfluentdを基に開発されている。そのためAgentのコンフィグ設定は、fluentdの設定方法と同じ。

Configuring the agent

syslogやNginxログ等向けのコンフィグ設定が用意されている。

デフォルトの Logging エージェントのログ

デフォルト外のログを対象としたい場合は、fluentd利用時と同じ。

  • fluentd向けに用意されているpluginを利用する
  • fluetndのルールに従いコンフィグを編集する

コンピューティングの割り当てを評価し、割り当ての引き上げをリクエストする

リソースの割り当て

モニタリングとロギング用に Stackdriver Agent をインストールする

モニタリング用

Cloud Monitoring Agentのインストール方法。

  • 候補1: OSにログインし、ダウンロードしたインストールモジュールを実行
  • 候補2: コンソールのCloud Logging Dashboard画面より、対象VMインスタンスにインストールを実行
    • 実際は、Cloud Shell上でインストールスクリプトを実行する感

単一の VM に Cloud Monitoring エージェントをインストールする

ロギング用

Cloud Logging Agentのインストール方法。

  • 候補1: OSにログインし、ダウンロードしたインストールモジュールを実行
  • 候補2: コンソールのCloud Logging Dashboard画面より、対象VMインスタンスにインストールを実行
    • 実際は、Cloud Shell上でインストールスクリプトを実行する感

Cloud Logging エージェントをインストールする

3.2 Google Kubernetes Engine リソースをデプロイ、実装する。以下のようなタスクを行います。

Google Kubernetes Engine クラスタをデプロイする

GKEクラスタの種類。

  • Autopilot
    • ワーカーノードも含めてマネージド
  • Standard
    • ワーカーノードは利用者側で、ある程度管理

Standardクラスタの可用性。

Standardクラスの種類 Controle Planeのゾーン配置 Worker Nodeのゾーン配置
シングルゾーン・クラスタ シングル シングル
マルチゾーン・クラスタ シングル マルチ
リージョン・クラスタ マルチ マルチ

クラスタのタイプ

スタンダード・リージョン・クラスタの作成。

リージョン クラスタの作成

東京リージョンのdefaultネットワークに、ワーカーノード数を指定して実行(3つのゾーンに2台づつ配置)。

$ gcloud container clusters create "cluster-sample" \
--release-channel=regular \　　　　　# リージョンクラスタを指定
--region=asia-northeast1 \
--num-nodes=2 \
--enable-autoscaling \              # 自動スケーリング・クラスタの作成(この方法のほか、ノードプール側でも指定できる)
--min-nodes=1 \
--max-nodes=3

gcloud container clusters create

Pod を使用して Google Kubernetes Engine にコンテナ アプリケーションをデプロイする

まず、ローカルにあるコンテナイメージをGCRへpush。

イメージの push と pull

GCRへ認証用のコマンドを実行。Docker Credential Helper用のコンフィグを生成してくれる。

$ gcloud auth configure-docker

gcloud auth configure-docker

コンテナイメージを、GCR用レジストリ用ネームフォーマット(HOSTNAME/PROJECT-ID/IMAGE:tag)でタギングする。

$ docker tag nginx:latest asia.gcr.io/sample-123456/nginx:latest

GCRにpushする。

$ docker push asia.gcr.io/sample-123456/nginx

ローカルのkubeconfigに、作成したGKE Clusterへの接続情報を追加する。

kubectl 用のクラスタ アクセスの構成

$ gcloud container clusters get-credentials cluster-sample --region=asia-northeast1

gcloud container clusters get-crendentials

GCRにpushしたイメージを利用して、Podを作成。

$ kubectl run sample --image=asia.gcr.io/sample-123456/nginx:latest

Google Kubernetes Engine アプリケーションのモニタリングとロギングを構成する

GKE 用 Google Cloud のオペレーション スイートの概要

  • Operation Suite内のCloud LoggingとCloud Monitoringに、GKE Cluster内のログ・メトリクスが統合されている
  • Cloud Monitoring内で、GKE用ダッシュボードが提供されている

GKE ログの管理

統合されるログ。

  • システムログ
    • GKE Clusterのログ
  • アプリケーションログ
    • コンテナ内のSTDOUTとSTDERR

3.3 App Engine リソース、Cloud Run リソース、Cloud Functions リソースをデプロイ、実装する。以下のようなタスクを行います（該当する場合）。

アプリケーションをデプロイし、スケーリング構成、バージョン、トラフィック分割を更新する

App Engine リソース

App Engine環境の種類。

  • スタンダード環境
    • マネージドなサンドボックス環境で実行される
      • 暗黙的にコンテナ化されている
  • フレキシブル環境
    • GCEのVMインスタンス上のDocker環境で実行される
    • 利用するコンテナイメージは、暗黙的に作成されるものまたは独自に作成したもののどちらも選択可能

App Engine 環境の選択

プロジェクトフォルダ内に用意されたapp.yaml構成ファイルを参照される形で、アプリケーションがデプロイされる。

App Engine アプリの設定は app.yaml ファイルで構成します。app.yaml ファイルには、ランタイムや最新バージョンの ID など、アプリコードについての情報も記載されています。

app.yaml 構成ファイル(Python3)

スタンダード環境のサービスをデプロイ。プロジェクトフォルダのルートフォルダでコマンド実行すると、Code Buildが自動実行され、サービス(アプリケーション)がデプロイされる。

$ gcloud app deploy       # コマンド実行後、デプロイ先のRegionやProjectの選択表示が出てくる

gcloud app deploy

サービスの表示(デプロイしたサービスのWEB画面を表示してくれる)。

$ gcloud app browse

gcloud app browse

gcloud app deployを再度実行することで、サービスの更新(バージョンの更新)となる。対象サービスをapp.yaml構成ファイルに定義することで、異なるプロジェクトフォルダからサービスを更新することも可能。

$ gcloud app versions list
SERVICE  VERSION.ID       TRAFFIC_SPLIT  LAST_DEPLOYED              SERVING_STATUS
default  20210601t162405  0.00           2021-06-01T16:25:20+09:00  SERVING
default  20210601t181314  1.00           2021-06-01T18:14:38+09:00  SERVING

複数バージョン作成時、トラフィックを「どのように移行するか」、「どのように分割するか」を設定できる。

新規バージョン作成時のデフォルトでは、新しいバージョンに即時トラフィックは移行されるが、app.yaml構成ファイルにinbound_services要素を追加することで、段階的なトラフィック移行が可能となる。

トラフィックの移行

以下コマンドを実行することで、バージョン間でトラフィックを分割できる。

トラフィックの分割

$ gcloud app services set-traffic default --splits=20210601t181314=0.5,20210601t162405=0.5 --split-by=ip --quiet

20210601t181314はバージョン名。バージョン名もapp.yaml内で指定できる。

gcloud app services set-traffic

Cloud Run リソース

コンテナ イメージのデプロイ

GCR上にあるコンテナイメージを利用して、サービス(k8sでのPod、ECSでのtaskに相当)のデプロイ。

$ gcloud run deploy sample --image=asia.gcr.io/sample-123456/nginx:latest \
--platform=managed \
--region=asia-northeast1 \
--allow-unauthenticated \
--port=80 \
--revision-suffix=v1

gcloud run deploy

スケーリング構成を変更するには、上記のgcloud run deployコマンドでスケーリング系パラメーターを付与して実行するか、下記のgcloud run services updateコマンドを実行する。新規リビジョンが作成される。

コンテナ インスタンスの最大数の設定

$ gcloud run services update sample \
--platform=managed \
--region=asia-northeast1 \
--max-instances=3 \             # ここ
--revision-suffix=v2

gcloud run services update

リビジョンの一覧。

$ gcloud run revisions list \
--service=sample \
--platform=managed \
--region=asia-northeast1
   REVISION   ACTIVE  SERVICE  DEPLOYED                 DEPLOYED BY
✔  sample-v2  yes     sample   2021-06-01 13:54:33 UTC  zunko@goodbyegangster.com
✔  sample-v1          sample   2021-06-01 13:37:52 UTC  zunko@goodbyegangster.com

スケーリング系パラメーター以外の、コンテナで利用するリソース量やコンテナ環境変数、ENTRYPOINTの指定もgcloud run services updateで同様に更新できる。

複数リビジョン間で、トラフィックの移行、段階的なトラフィックの移行、トラフィックの分割を行える。

ロールバック、段階的なロールアウト、トラフィックの移行

リビジョン間でトラフィックの分割を実行。

$ gcloud run services update-traffic sample \
--platform=managed \
--region=asia-northeast1 \
--to-revisions=sample-v1=50,sample-v2=50

gcloud run services update-traffic

Cloud Functions リソース

クイックスタート: gcloud コマンドライン ツールの使用

ローカル上にあるPythonソースコードを、Cloud Functionの関数にデプロイする。デプロイしたいコードのあるディレクトリで実行。

$ gcloud functions deploy sample_function_1 \
--runtime=python38 \
--entry-point=hello_get \
--trigger-http \
--allow-unauthenticated \
--region=asia-northeast1

gcloud functions deploy

HTTPトリガーでの、作成した関数の実行。

$ curl https://asia-northeast1-sample-123456.cloudfunctions.net/sample_function_1
Hello World!

gcloud経由にて、作成した関数の実行。

$ gcloud functions call sample_function_1 --region=asia-northeast1
executionId: p2zgio5uo7l8
result: Hello World!

gcloud functions call

Google Cloud イベント（例: Cloud Pub/Sub イベント、Cloud Storage オブジェクト変更通知イベント）を受け取るアプリケーションをデプロイする

Cloud Pub/Sub イベントを受け取るアプリケーション(Cloud Function)をデプロイ

Cloud Pub/Subのpublishイベントをトリガーとして、実行されるCloud Funtion関数の作成。

Google Cloud Pub/Sub トリガー

Cloud Pub/Sub のチュートリアル

$ gcloud functions deploy hello_pubsub \  # デプロイするコード内でイベント受け取る処理を書いてあげる
--runtime=python38 \
--trigger-topic sample-topic    # Cloud Pub/Subのtopic名を指定

gcloud functions deploy

Cloud Storage オブジェクト変更通知イベントを受け取るアプリケーション(Cloud Function)をデプロイ

Cloud Storageの通知イベントをトリガーとして、実行されるCloud Function関数の作成。

Google Cloud Storage トリガー

Cloud Storage のチュートリアル

$ gcloud functions deploy hello_gcs \   # デプロイするコード内でイベント受け取る処理を書いてあげる
--runtime=python38 \
--trigger-resource=pekomiko \                     # Cloud StorageのBucket名を指定
--trigger-event=google.storage.object.finalize    # トリガーとするイベントを指定

gcloud functions deploy

3.4 データ ソリューションをデプロイ、実装する。以下のようなタスクを行います。

プロダクト（例: Cloud SQL、Cloud Datastore、BigQuery、Cloud Spanner、Cloud Pub/Sub、Cloud Bigtable、Cloud Dataproc、Cloud Dataflow、Cloud Storage）を使用してデータシステムを初期化する

Cloud SQL

インスタンスの作成

PostgreSQLインスタンスの作成。

$ gcloud sql instances create sample-instance \
--database-version=POSTGRES_13 \
--availability-type=regional \                    # high availability構成を指定
--zone=asia-northeast1-a \
--secondary-zone=asia-northeast1-b \
--replica-type=FAILOVER \
--cpu=1 \
--memory=4096MB \
--storage-size=10GB \
--storage-type=SSD \
--storage-auto-increase \
--assign-ip \                                     # Public IPの利用
--authorized-networks=0.0.0.0/0                   # 承認済みネットワークの指定

gcloud sql instances create

cloudsqlsuperuser権限をもつDBユーザーのパスワードを設定。

Cloud SQL を使用して作成されたユーザーには、cloudsqlsuperuser 役割と関連付けられている権限（CREATEROLE、CREATEDB、LOGIN）があります。これらのユーザーによって作成されたユーザーは、データベース接続権限を持つことができます。これにより、ユーザーが削除されるのを防ぐことができます。

PostgreSQL ユーザーの作成、管理

$ gcloud sql users set-password postgres \
--instance=sample-instance \
--prompt-for-password

Postgresを作成した場合、potgresという名前のユーザーが自動的に作成されている。

gcloud sql users set-password

作成したインスタンスに接続する。Cloud SQLインスタンス作成時に、自動的にpostgresという名前のデータベースが作成されている。

$ psql -h 34.84.43.99 -p 5432 -U postgres -d postgres
Password for user postgres:
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
Type "help" for help.

postgres=> \l
                                                List of databases
     Name      |       Owner       | Encoding |  Collate   |   Ctype    |            Access privileges
---------------+-------------------+----------+------------+------------+-----------------------------------------
 cloudsqladmin | cloudsqladmin     | UTF8     | en_US.UTF8 | en_US.UTF8 |
 postgres      | cloudsqlsuperuser | UTF8     | en_US.UTF8 | en_US.UTF8 |
 template0     | cloudsqladmin     | UTF8     | en_US.UTF8 | en_US.UTF8 | =c/cloudsqladmin                       +
               |                   |          |            |            | cloudsqladmin=CTc/cloudsqladmin
 template1     | cloudsqlsuperuser | UTF8     | en_US.UTF8 | en_US.UTF8 | =c/cloudsqlsuperuser                   +
               |                   |          |            |            | cloudsqlsuperuser=CTc/cloudsqlsuperuser
(4 rows)

Cloud SQL Auth Proxyについて。

Cloud SQL Auth Proxy を使用すると、承認済みネットワークや SSL の構成を必要とせずに、安全にインスタンスへアクセスできます。
Cloud SQL Auth Proxy を使用して Cloud SQL インスタンスにアクセスする利点は次のとおりです。
・安全な接続: Cloud SQL Auth Proxy は、TLS 1.2 と 128 ビット AES 暗号を使用して、データベースとの間で送受信されるトラフィックを自動的に暗号化します。クライアントとサーバーの ID の確認には、SSL 証明書が使用されます。
・簡単な接続管理: Cloud SQL Auth Proxy が Cloud SQL との認証を処理するので、静的な IP アドレスを提供する必要がなくなります。

Cloud SQL側に用意されたProxy Server機能と、ローカルPCにインストールしたProxy Clientが通信することで、Public IPのないCloud SQLインスタンスであっても接続できるようになる。Proxy Server/Client間の認証には、サービスアカウントが利用される。

Cloud SQL Auth Proxy について

Cloud Datastore(Firestore)

Firestoreは、Datastoreの次期メジャーバージョン。ネイティブモードとDatastoreモードがある。

ネイティブ モードと Datastore モードからの選択

コンソールを利用した基本的な操作方法。

クイックスタート

データの操作は、各言語向けのライブラリまたはAPI経由で行うことになる。またSQLライクな検索を行えるGQLというクエリ言語を利用できる。

API とリファレンス

概念。

  • namespace
  • kind
    • namespaceに紐づく
    • entityのproperty(スキーマに相当)を定義したもの(と言ってもNoSQLであるため緩い)
  • entity
    • kindに紐づく
    • 実際のデータオブジェクト

BigQuery

データセット(RDBにおけるテーブルスペースに相当)の作成。

データセットの作成

$ bq --location=asia-northeast1 mk --dataset sample-123456:sample

bq mk --dataset

スキーマ(テーブル定義)を指定しつつ、テーブルの作成。

テーブルの作成と使用

$ bq mk --table \
sample-123456:sample.names_2014 \
name:string,gender:string,count:integer

bq mk --table

作成したテーブルに、ローカル上のCSVファイルをインポートする。インポートしたサンプルデータ

データのバッチ読み込み

$ bq load \
--source_format=CSV \
sample-123456:sample.names_2014 \
./names/yob2014.txt

bq load

データの検索。

インタラクティブ クエリとバッチクエリのジョブの実行

$ bq --location=asia-northeast1 query \
--use_legacy_sql=false \
'SELECT name, gender, count FROM `sample-123456.sample.names_2014` limit 3'

Waiting on bqjob_r72dc1deb8a410791_00000179d01d76f0_1 ... (0s) Current status: DONE
+--------+--------+-------+
|  name  | gender | count |
+--------+--------+-------+
| Emma   | F      | 20943 |
| Olivia | F      | 19823 |
| Sophia | F      | 18630 |
+--------+--------+-------+

bq query

Cloud Spanner

gcloud で Cloud Spanner を使ってみる

Spannerインスタンスの作成。

インスタンスの作成と管理

$ gcloud spanner instances create test-instance \
--config=regional-asia-northeast1 \
--description="Test Instance" \
--nodes=1

gcloud spanner instances create

作成したSpannerインスタンス上に、データベースの作成。

$ gcloud spanner databases create example-db --instance=test-instance

gcloud spanner databases create

テーブル(スキーマ)の作成。

$ gcloud spanner databases ddl update example-db --instance=test-instance \
--ddl='CREATE TABLE Singers ( SingerId INT64 NOT NULL, FirstName STRING(1024), LastName STRING(1024), SingerInfo BYTES(MAX) ) PRIMARY KEY (SingerId)'
$
$ gcloud spanner databases ddl update example-db --instance=test-instance \
--ddl='CREATE TABLE Albums ( SingerId INT64 NOT NULL, AlbumId INT64 NOT NULL, AlbumTitle STRING(MAX)) PRIMARY KEY (SingerId, AlbumId), INTERLEAVE IN PARENT Singers ON DELETE CASCADE'

Cloud Spannerのデータモデルと、スキーマ設計時の考慮。

スキーマとデータモデル

gcloud spanner databases ddf update

データの挿入。

$ gcloud spanner rows insert --table=Singers --database=example-db --instance=test-instance \
--data=SingerId=1,FirstName=Marc,LastName=Richards
$
$ gcloud spanner rows insert --table=Singers --database=example-db --instance=test-instance \
--data=SingerId=2,FirstName=Catalina,LastName=Smith
$
$ gcloud spanner rows insert --table=Albums --database=example-db --instance=test-instance \
--data=SingerId=1,AlbumId=1,AlbumTitle="Total Junk"
$
$ gcloud spanner rows insert --table=Albums --database=example-db --instance=test-instance \
--data=SingerId=2,AlbumId=1,AlbumTitle="Green"

gcloud spanner rows insert

データの検索。

$ gcloud spanner databases execute-sql example-db --instance=test-instance \
--sql='SELECT SingerId, AlbumId, AlbumTitle FROM Albums'

SingerId  AlbumId  AlbumTitle
1         1        Total Junk
2         1        Green

gcloud spanner databases execute-sql

Cloud Pub/Sub

クイックスタート: gcloud コマンドライン ツールの使用

トピックの作成。

トピックとサブスクリプションの管理

$ gcloud pubsub topics create sample-topic

gcloud pubsub topics create

サブスクリプションの作成。

$ gcloud pubsub subscriptions create sample-sub \
--topic=sample-topic \
--ack-deadline=10 \
--expiration-period=30d \
--message-retention-duration=7d

gcloud pubsub subscriptions create

gcloudコマンドラインにて、メッセージをパブリッシュ。

$ gcloud pubsub topics publish sample-topic \
--message="Hello World" \
--attribute="key=value"

gcloud pubsub topics publish

gcloudコマンドラインにて、メッセージを受信(pull)。

$ gcloud pubsub subscriptions pull sample-sub --auto-ack
┌─────────────┬──────────────────┬──────────────┬────────────┬──────────────────┐
│     DATA    │    MESSAGE_ID    │ ORDERING_KEY │ ATTRIBUTES │ DELIVERY_ATTEMPT │
├─────────────┼──────────────────┼──────────────┼────────────┼──────────────────┤
│ Hello World │ 2489941872487215 │              │ key=value  │                  │
└─────────────┴──────────────────┴──────────────┴────────────┴──────────────────┘

gcloud pubsub subscriptions pull

Cloud Bigtable

cbt ツールを使用したクイックスタート

Bigtableインスタンスの作成。

Bigtable インスタンスの作成

$ gcloud bigtable instances create sample-instance \
--display-name="sample instance" \
--cluster-config=id=sample-cluster-id-1,zone=asia-northeast1-a,nodes=1 \      # 東京と大阪リージョンでレプリケーション設定
--cluster-config=id=sample-cluster-id-2,zone=asia-northeast2-a,nodes=1 \
--cluster-storage-type=ssd

gcloud bigtable instances create

Bigtable操作用のサービスアカウントの作成。下記のcbtツールにて利用される。

Setting up authentication

cbtツールのコンフィグファイルを設定。

cbt ツールは、Cloud Bigtable でさまざまなオペレーションを行うためのコマンドライン インターフェースです。

cbt ツールの概要

$ echo project =   sample-123456 > ~/.cbtrc
$ echo instance = sample-instance >> ~/.cbtrc

テーブルの作成。

テーブルの管理

$ cbt createtable my-table

cbt createtable

テーブルに列ファミリーの追加。

$ cbt createfamily my-table cf1

cbt createfamily

下は、Bigtableのデータモデルについての説明資料。

スキーマの設計

データの書き込み。

$ cbt set my-table r1 cf1:c1=test-value1 cf1:c2=test-value2

cbt set

データの読み取り。

$ cbt read my-table
----------------------------------------
r1
  cf1:c1                                   @ 2021/06/04-16:45:23.776000
    "test-value1"
  cf1:c2                                   @ 2021/06/04-16:45:23.776000
    "test-value2"

cbt read

Cloud Dataproc

クイックスタート: gcloud コマンドライン ツールの使用

クラスタの作成。GCEのVMインスタンスが作成される。

クラスタの作成

# 実際はすごい量のパラメーターがあるが、下はdefault値で作成している例
$ gcloud dataproc clusters create sample-cluster --region=asia-northeast1

gcloud dataproc clusters create

サンプルのjarファイルを利用してジョブの送信(円周率の計算)。

ジョブの送信

$ gcloud dataproc jobs submit spark \
--cluster=sample-cluster \
--region=asia-northeast1 \
--class=org.apache.spark.examples.SparkPi \
--jars=file:///usr/lib/spark/examples/jars/spark-examples.jar \
-- 1000

gcloud dataproc jobs submit spark

Cloud Dataflow

Pythonを利用して、パイプラインの実行をする。

Python を使用したクイックスタート

Dataflowパイプライン実行用のサービスアカウントを作成する。下記のApache Beam SDKにて利用する。

Google Cloud 上のパイプラインのセキュリティと権限

Apache Beam SDKを利用して、サンプルとなるPythonコードのパイプラインをデプロイする。サンプルコード:apache_beam.examples.wordcount

$ python -m apache_beam.examples.wordcount \
--region asia-northeast1 \
--input gs://dataflow-samples/shakespeare/kinglear.txt \
--output gs://mikochi/results/outputs \
--runner DataflowRunner \
--project sample-123456 \
--temp_location gs://mikochi/tmp/

実行されたパイプライン処理の結果が、上記ouputパラメーターに指定したバケットに出力されている。

Cloud Storage

クイックスタート: gsutil ツールの使用

バケットの作成。

ストレージ バケットの作成

$ gsutil mb \
-b on \                     # バージョニングの有効化
-c Standard \
-l asia-northeast1 \
-p sample-123456 \
--retention 500d \
gs://pekomiko

gsutil mb

オブジェクトのアップロード・ダウンロード。コピー。

アップロードとダウンロード

$ gsutil cp ./kitten.png gs://pekomiko/sample/

gsutil cp

バケットレベルに対するIAM権限を用いたアクセス制御の設定。

IAM 権限の使用

$ gsutil iam ch allUsers:objectViewer gs://pekomiko         # バケットを一般公開する(https://storage.googleapis.com/pekomiko/xxx.jpg)
$ gsutil iam ch user:kiritan@goodbyegangster.com:objectCreator gs://pekomiko

顧客指定の暗号鍵を利用してアップロードする方法（コンソールでの操作不可）。

$ gsutil cp -o "GSUtil:encryption_key=YOUR_ENCRYPTION_KEY" gs://pekomiko/aaaa.jpg   # -oフラグで鍵情報を与える

この方法以外に、Boto構成ファイルに鍵情報を組み込む方法もある。

顧客指定の暗号鍵の使用

gsutil iam

データを読み込む（例: コマンドラインによるアップロード、API による転送、インポート / エクスポート、Cloud Storage からのデータの読み込み、Cloud Pub/Sub へのデータのストリーミング）

データ転送系サービス。

Google Cloud サービス 詳細 AWSで相当するもの
Transfer Service for On Premises Data GCSへデータ転送してくれるManaged Service AWS DataSync
Transfer Appliance GCSへオフラインでデータ転送してくれるアプライアンス Snowball
BigQuery Data Transfer Service SaaSやGCS, S3, Redshift, TeradataからBigQueryにデータ転送するサービス AppFlow
Clud Scheduler Managed Cron サービス Data Pipeline

Transfer Service for On Premises Data の概要 Transfer Appliance の概要 BigQuery Data Transfer Service の概要 Cloud Scheduler

3.5 ネットワーキング リソースをデプロイ、実装する。以下のようなタスクを行います。

サブネットを持つ VPC（例: カスタムモード VPC、共有 VPC）を作成する

Google Cloudにおけるネットワークリソースの範囲。

ネットワークリソース 範囲 備考
VPC グローバル
サブネット リージョン Zoneをまたいで作成される
Firewall Rule グローバル VPCにアタッチされる
Route グローバル VPCにアタッチされる

VPCの種類。

  • 自動モードVPC
    • リージョン毎に、1つのサブネットが自動に作成される
    • 事前定義されているIP範囲にて、サブネットのCIDRが設定される
  • カスタムモードVPC
    • 必要なサブネットを自由に作成できる

カスタムモードVPCの作成。

$ gcloud compute networks create custom-vpc \
--subnet-mode=custom \                          # 自動モードVPCの場合は`Auto`を指定
--enable-flow-logs \                            # VPCフローログを有効化
--bgp-routing-mode=regional

gcloud compute networks create

共有VPCとは。

共有 VPC を使用して、組織は複数のプロジェクトから共通の Virtual Private Cloud（VPC）ネットワークにリソースを接続できるため、そのネットワークの内部 IP を使用して、安全で効率的な相互通信ができます。

共有 VPC の概要

例とユースケースの図がわかりやすい。

共有VPCの作成。

共有 VPC のプロビジョニング

VPCが同一組織に属していない場合の補足。VPC ネットワーク ピアリングについて。

Google Cloud VPC ネットワーク ピアリングでは、2 つの Virtual Private Cloud（VPC）ネットワークが同じプロジェクトまたは同じ組織に属しているかにかかわらず、内部 IP アドレス接続できます。
VPC ネットワーク ピアリングを使用すると、異なる VPC ネットワーク内のワークロードが内部で通信できるように、VPC ネットワークを接続できます。トラフィックは Google のネットワーク内に留まり、公共のインターネットを経由することはありません。

VPC ネットワーク ピアリングの概要

VPCフローログについて。

VPC フローログには、VM インスタンスによって送受信されたネットワーク フローのサンプルが記録されます。これには GKE ノードとして使用されるインスタンスも含まれます。これらのログは、ネットワーク モニタリング、フォレンジック、リアルタイム セキュリティ分析、および費用の最適化に使用できます。

収集された結果はCloud Loggingにて参照できる。

VPC フローログの使用

カスタム ネットワーク構成（例: 内部専用 IP アドレス、限定公開の Google アクセス、静的外部 IP アドレスとプライベート IP アドレス、ネットワーク タグ）を持つ Compute Engine インスタンスを起動する

静的内部IPアドレスを利用するVMインスタンスの作成。

$ gcloud compute instances create instance-static-private-ip \
--subnet=sample-subnet \
--no-address \
--private-network-ip=192.168.0.10

特定の内部 IP アドレスを使用して VM インスタンスを作成する

限定公開のGoogleアクセスを利用するVMインスタンスの作成。実際は、限定公開のGoogleアクセスはサブネットを単位に有効/無効にすることができ、有効とされたサブネットに配置されたVMインスタンスが、その機能を利用できる。

デフォルトでは、Compute Engine VM がネットワーク インターフェースに割り当てられた外部 IP アドレスを持たない場合、他の内部 IP アドレスの宛先にのみパケットを送信できます。VM のネットワーク インターフェースが使用するサブネットで限定公開の Google アクセスを有効にすると、Google API とサービスで使用される一連の外部 IP アドレスに VM を接続できます。

限定公開の Google アクセスの構成

$ gcloud compute networks subnets update sample-subnet \
--region=asia-northeast1 \
--enable-private-ip-google-access

静的外部IPアドレスと静的内部IPアドレスを利用するVMインスタンスの作成。

$ gcloud compute instances create instance-both-ip \
--subnet=sample-subnet \
--address=sample-external-ip \
--private-network-ip=192.168.0.10

ネットワークタグを利用するVMインスタンスの作成。

タグは、Compute Engine 仮想マシン（VM）インスタンスやインスタンス テンプレートなどのリソースのタグフィールドに追加される文字からなる文字列です。タグは個別のリソースではないため、個別に作成することはできません。その文字列を持つすべてのリソースには、そのタグがあると考えられます。タグを使用して、特定の VM インスタンスに適用されるファイアウォール ルールやルートを作成できます。

ネットワーク タグの構成

$ gcloud compute instances create instance-with-tag \
--subnet=sample-subnet \
--tags='sample-tag'

VPC 用の上り（内向き）および下り（外向き）ファイアウォール ルール（例: IP サブネット、タグ、サービス アカウント）を作成する

暗黙のルール

Implied deny ingress ruleについて。

--direction="INGRESS" \
--action="DENY" \
--source-ranges="0.0.0.0/0" \
--priority="65535" \

Implied allow egress ruleについて。

--direction="EGRESS" \
--action="ALLOW" \
--destination-ranges="0.0.0.0/0" \
--priority="65535" \

ファイアウォール ルールの使用

上り（内向き）のFirewall Ruleを作成。

$ gcloud compute firewall-rules create allow-http-rule \
--network=custom-vpc \
--direction=INGRESS \
--target-tags=web-server \
--source-ranges=0.0.0.0/0 \
--action=ALLOW \
--rules=tcp:80 \
--priority=1000 \
--no-enable-logging

下り（外向き）のFirewall Ruleを作成。

$ gcloud compute firewall-rules create deny-all \
--network=custom-vpc \
--direction=EGRESS \
--destination-ranges=0.0.0.0/0 \
--action=DENY \
--rules=tcp \
--priority=1000 \
--no-enable-logging

SourceとTargetの指定にサービスアカウントを利用して作成。

$ gcloud compute firewall-rules create allow-sa-db \
--network=custom-vpc \
--direction=INGRESS \
--target-service-accounts=db-server@sample-123456.iam.gserviceaccount.com \
--source-service-accounts=app-server@sample-123456.iam.gserviceaccount.com \
--action=ALLOW \
--rules=tcp:1443 \
--priority=1000 \
--no-enable-logging

gcloud compute firewall-rules create

Cloud VPN を使用して Google VPC と外部ネットワークとの間の VPN を作成する

Cloud VPN は、IPsec VPN 接続を使用してピア ネットワークを Virtual Private Cloud（VPC）ネットワークへ安全に接続します。2 つのネットワーク間のトラフィックは、一方の VPN ゲートウェイで暗号化され、もう一方の VPN ゲートウェイで復号されます。これにより、インターネットでデータをやり取りする際もデータが保護されます。Cloud VPN の 2 つのインスタンスを相互に接続することもできます。

Cloud VPN の概要

HA(High Availability) VPNゲートウェイを設定するための一連の作業。

ピア VPN ゲートウェイへの HA VPN ゲートウェイの作成

仮想VPNルーターであるHA VPNゲートウェイの作成。

$ gcloud compute vpn-gateways create sample-vpn-gateway \
--network=custom-vpc \
--region=asia-northeast1

gcloud compute vpn-gateways create

対向VPNルーターの定義となるピアVPNゲートウェイの作成。

$ gcloud compute external-vpn-gateways create sample-peer-vpn-gateway \
--interfaces 0=219.167.191.210,1=219.167.191.211

gcloud compute external-vpn-gateways create

VPCにアタッチされる仮想ルーターであるCloud Routerの作成。

$ gcloud compute routers create sample-router \
--region=asia-northeast1 \
--network=custom-vpc \
--asn=64512

gcloud compute routers create

VPNトンネルの設定。

$ gcloud compute vpn-tunnels create sample-vpn-tunnel1 \
--peer-external-gateway=sample-peer-vpn-gateway \
--peer-external-gateway-interface=0 \
--region=asia-northeast1 \
--ike-version=2 \
--shared-secret=ILPltuJmR9FNf/D6rd1j/kd3Qju+h5m8 \
--router=sample-router \
--vpn-gateway=sample-vpn-gateway \
--interface=0
$ gcloud compute vpn-tunnels create sample-vpn-tunnel2 \
--peer-external-gateway=sample-peer-vpn-gateway \
--peer-external-gateway-interface=1 \
--region=asia-northeast1 \
--ike-version=2 \
--shared-secret=xVDESZGI8WkiSFqOMoOCVmCc96iugfj7 \
--router=sample-router \
--vpn-gateway=sample-vpn-gateway \
--interface=1

gcloud compute vpn-tunnels create

BGPセッションの設定。

$ gcloud compute routers add-interface sample-router \
--interface-name=sample-bgp-session1 \
--mask-length=30 \
--vpn-tunnel=sample-vpn-tunnel1
$
$ gcloud compute routers add-bgp-peer sample-router \
--peer-name=sample-bgp-session1 \
--peer-asn=65000 \
--interface=sample-bgp-session1 \
--region=asia-northeast1

$ gcloud compute routers add-interface sample-router \
--interface-name=sample-bgp-session2 \
--mask-length=30 \
--vpn-tunnel=sample-vpn-tunnel2
$
$ gcloud compute routers add-bgp-peer sample-router \
--peer-name=sample-bgp-session2 \
--peer-asn=65001 \
--interface=sample-bgp-session2 \
--region=asia-northeast1

gcloud compute routers add-interface

gcloud compute routers add-bgp-peer

Cloud VPN以外の拠点間ネットワーク接続方法。

Google Cloud サービス 詳細 AWSで相当するサービス
Cloud Interconnect - Dedicated Interconnect オンプレミスとGoogle Cloud間の物理的接続サービス DirectConnect 専有型
Cloud Interconnect - Partner Interconnect サービス・プロバイダ経由にてDedicated Interconnectを利用できるサービス DirectConnect 共有型

Cloud Interconnect の概要

アプリケーションへのネットワーク トラフィックを分散するロードバランサ（例: グローバル HTTP(S) ロードバランサ、グローバル SSL プロキシ ロードバランサ、グローバル TCP プロキシ ロードバランサ、リージョン ネットワーク ロードバランサ、リージョン内部ロードバランサ）を作成する

グローバル HTTP(S) ロードバランサの作成

External HTTP Load Balancerの作成手順を確認。

シンプルな外部 HTTP ロードバランサの設定

Managed Instance Group(MIG)の作成。

$ gcloud compute instance-groups managed create backend-web \
--template=sample-template \
--size=1 \
--zones=asia-northeast1-a,asia-northeast1-b

作成したMIGに名前付きポートの定義を設定。名前付きポートの定義は、Load Balancingサービスで利用するメタ情報のこと。

Named ports are key:value pairs metadata representing the service name and the port that it's running on. Named ports can be assigned to an instance group, which indicates that the service is available on all instances in the group. This information is used by the HTTP Load Balancing service.

$ gcloud compute instance-groups set-named-ports backend-web \
--named-ports=web:80 \
--region=asia-northeast1

gcloud compute instance-group set-named-ports

ファイアーウォールルールの作成。Google Cloudヘルスチェックシステム(130.211.0.0/22,35.191.0.0/16)からのトラフィック用。

$ gcloud compute firewall-rules create fw-allow-health-check \
--network=default \
--action=allow \
--direction=INGRESS \
--source-ranges=130.211.0.0/22,35.191.0.0/16 \
--rules=tcp:80

ロードバランサーにアタッチする静的外部IPアドレスの予約。

$ gcloud compute addresses create lb-ip --ip-version=IPV4 --global

ヘルスチェック定義の作成。

$ gcloud compute health-checks create http http-basic-check --port=80 --global

gcloud compute health-checks create http

バックエンドサービスの作成。作成した名前付きポートの定義とヘルスチェック定義を紐付ける。

$ gcloud compute backend-services create backend-web-service \
--protocol=HTTP \
--port-name=http \
--health-checks=http-basic-check \
--global

gcloud compute backend-service create

作成したバックエンドサービスにMIGを紐付ける。

$ gcloud compute backend-services add-backend backend-web-service \
--instance-group=backend-web \
--instance-group-region=asia-northeast1 \
--global

gcloud compute backend-services add-backend

URLマップの作成。作成したバックエンドサービスを紐付ける。

$ gcloud compute url-maps create web-map-http --default-service=backend-web-service

gcloud compute url-maps create

HTTPプロキシの作成。作成したURLマップを紐付ける。

$ gcloud compute target-http-proxies create http-proxy --url-map=web-map-http

gcloud compute target-http-proxies

グローバル転送ルールの作成。予約した静的外部IPと作成したHTTPプロキシを紐付け、待ち受けポートを宣言する。

$ gcloud compute forwarding-rules create http-rule \
--address=lb-ip \
--target-http-proxy=http-proxy \
--ports=80 \
--global

gcloud compute forwarding-rules

上で作ったロードバランサーを、HTTPS化(External HTTPS Load Balancer)する手順を確認。

Google マネージド SSL 証明書の使用

GoogleマネージドSSL証明書の作成。

$ gcloud compute ssl-certificates create sample-cert \
--domains=sample.goodbyegangster.com \
--global

gcloud compute ssl-certificates create

HTTPSプロキシの作成。URLマップのほか、利用するSSL証明書情報を付与する。

$ gcloud compute target-https-proxies create https-proxy \
--url-map=web-map-http \
--ssl-certificates=sample-cert \
--global-ssl-certificates \
--global

gcloud compute target-https-proxies create

グローバル転送ルールの作成。

$ gcloud compute forwarding-rules create https-rule \
--address=lb-ip \
--target-https-proxy=https-proxy \
--ports=443 \
--global

gcloud compute forwarding-rules create

グローバル SSL プロキシ ロードバランサの作成

SSL プロキシ負荷分散の設定

グローバルHTTPSロードバランサーと同じく、以下の設定を実施。

HTTPSプロキシの代わりに、SSLプロキシを作成。まず、SSLプロキシに紐付けるポリシーを作成する。

$ gcloud compute ssl-policies create my-ssl-policy \
--profile=MODERN \
--min-tls-version=1.0

gcloud compute ssl-policies create

SSLプロキシを作成。上記で作成したSSLポリシーのほか、SSL証明書情報を付与する。

$ gcloud compute target-ssl-proxies create my-ssl-lb-target-proxy \
--backend-service=my-ssl-lb \
--ssl-certificates=sample-cert \
--ssl-policy=my-ssl-policy \
--proxy-header=NONE

gcloud compute target-ssl-proxies create

グローバル転送ルールの作成。作成したSSLプロキシと予約済みの静的外部IPアドレスを紐付ける。

$ gcloud compute forwarding-rules create my-ssl-lb-forwarding-rule \
--target-ssl-proxy=my-ssl-lb-target-proxy \
--address=ssl-lb-static-ipv4 \
--ports=443 \
--global

グローバル TCP プロキシ ロードバランサの作成

TCP プロキシ負荷分散の設定

SSLプロキシの代わりに、TCPプロキシを作成する。

$ gcloud compute target-tcp-proxies create PROXY_NAME \
--backend-service BACKEND_NAME \
--proxy-header NONE

リージョン ネットワーク ロードバランサの作成

Google Cloud の外部 TCP / UDP ネットワーク負荷分散（以降はネットワーク負荷分散と呼びます）は、リージョンのパススルー ロードバランサです。ネットワーク ロードバランサは、同じリージョン内の仮想マシン（VM）インスタンス全体に TCP または UDP トラフィックを分散します。

・ネットワーク ロードバランサはプロキシではありません。
　・負荷分散パケットは、ソース IP が変更されていない状態でバックエンド VM で受信されます。
　・負荷分散接続はバックエンド VM によって終端されます。
　・バックエンド VM からのレスポンスは、ロードバランサを経由せず、クライアントに直接送信されます。これを業界用語で Direct Server Return といいます。

外部 TCP / UDP ネットワーク負荷分散の概要

以下のリソースより構成される。

  • インスタンスグループを持つbackendサービス
  • backendサービスと連携される転送ルール

ネットワーク負荷分散のフェイルオーバーの構成

リージョン内部ロードバランサの作成

ターゲットプロキシを配置するための、プロキシ専用サブネットを事前に作成しておく必要があり。

内部 HTTP(S) 負荷分散の設定

プロキシ専用サブネットは、内部 HTTP(S) 負荷分散プロキシ専用として予約されています。他の目的には使用できません。各 VPC ネットワークのリージョンごとに、1 つのプロキシ専用サブネットだけをアクティブにできます。

内部 HTTP(S) ロードバランサの転送ルールを作成する前に、プロキシ専用サブネットを作成しておく必要があります。内部 HTTP(S) ロードバランサを使用する仮想プライベート ネットワーク（VPC）の各リージョンに、プロキシ専用サブネットを作成する必要があります。

内部 HTTP(S) ロードバランサのプロキシ専用サブネット

プロキシ専用サブネット作成。

$ gcloud compute networks subnets create proxy-subnet \
--purpose=INTERNAL_HTTPS_LOAD_BALANCER \
--role=ACTIVE \
--region=asia-northeast1 \
--network=custom-vpc \
--range=172.168.0.0/23

gcloud compute networks subnets create proxy-subnet

3.6 Cloud Marketplace を使用してソリューションをデプロイする。以下のようなタスクを行います。

Cloud Marketplace カタログを閲覧し、ソリューションの詳細を見る

Google Cloud Marketplace を使用すると、Google Cloud で動作する機能的なソフトウェア パッケージをすばやくデプロイできます。Compute Engine、Cloud Storage などのサービスに慣れていない場合でも、なじみのあるソフトウェア パッケージを簡単に使い始めることができます。ソフトウェア、仮想マシン インスタンス、ストレージ、ネットワークの構成を手動で行う必要はありません。今すぐソフトウェア パッケージをデプロイして、アプリケーションで追加の容量が必要になったら後から拡張できます。

Google Cloud Marketplace とは

カタログの確認。

Marketplaceページ

Cloud Marketplace ソリューションをデプロイする

デプロイの管理

Deployment Managerにてデプロイされる事になるので、Deployment Managerで管理することができる。

3.7 Cloud Deployment Manager を使用してアプリケーション インフラストラクチャをデプロイする。以下のようなタスクを行います。

Deployment Manager テンプレートを開発する

Deployment Manager の基礎知識

リソースの作成にあたっては、構成(Configuration)のファイルを作成する必要がある。

Configurationは以下の要素よりなる。

  • resource
    • 作成するリソース毎のリスト
    • 下記3つの要素を含む
    • name
      • リソースを特定するためのユーザー定義の文字列
    • type
    • propaties
      • デプロイされるリソースで設定するパラメーター

Configurationのサンプル。

resources:
- name: sample-vm
  type: compute.v1.instance
  properties:
    zone: asia-northeast1-a
    machineType: https://www.googleapis.com/compute/v1/projects/sample-123456/zones/asia-northeast1-a/machineTypes/e2-micro
    disks:
    - deviceName: boot
      type: PERSISTENT
      boot: true
      autoDelete: true
      initializeParams:
        sourceImage: https://www.googleapis.com/compute/v1/projects/debian-cloud/global/images/debian-7-wheezy-v20150526
    networkInterfaces:
    - network: https://www.googleapis.com/compute/v1/projects/sample-123456/global/networks/default
      accessConfigs:
      - name: External NAT
        type: ONE_TO_ONE_NAT

Configurationで利用できる機能たち。

Deployment Manager テンプレートを起動する

Configuration(構成)をデプロイする。

gcloud または API を使用してデプロイを作成する

$ gcloud deployment-manager deployments create sample-deployment --config ./sample-configuration.yaml

gcloud deployment-manager deployment create

Configuration(構成)を更新するために、プレビューする。

デプロイを更新する

$ gcloud deployment-manager deployments update sample-deployment --config ./sample-configuration-update.yaml --preview

gcloud deployment-manager deployments update

Configuration(構成)を更新する。

$ gcloud deployment-manager deployments update sample-deployment

4. クラウド ソリューションの正常なオペレーションの確保

4.1 Compute Engine リソースを管理する。以下のようなタスクを行います。

単一の VM インスタンス（例: 起動、停止、構成の編集、インスタンスの削除）を管理する

起動

$ gcloud compute instances start sample1

gcloud compute instances start

停止

$ gcloud compute instances stop sample1

gcloud compute instances stop

構成の編集

インスタンスのプロパティの更新

現在の設定情報をエクスポートして、編集する。

$ gcloud compute instances export sample1 --destination=./export.yaml

gcloud compute instances export

編集したファイルを用いてアップデートのテスト。--most-disruptive-allowed-action NO_EFFECTオプションを付与すると、変更内容の確認と更新時の再起動必要有無が分かる。

$ gcloud compute instances update-from-file sample1 --source=./export.yaml --most-disruptive-allowed-action NO_EFFECT
ERROR: (gcloud.compute.instances.update-from-file) Could not fetch resource:
 - Invalid value for field 'mostDisruptiveAllowedAction': 'NO_EFFECT'. 'machineType' changed. Insufficient allowed action to perform the update. Required action: RESTART.

アップデート。

$ gcloud compute instances update-from-file sample1 \
--source=./export.yaml \
--most-disruptive-allowed-action RESTART

gcloud compute instances update-from-file

インスタンスのゾーン間の移動

インスタンスをゾーン間で移動する。

ゾーン間のインスタンスの移動

$ gcloud compute instances move sample1 -zone=asia-northeast1-a --destination-zone=asia-northeast-b

gcloud compute instances move

インスタンスの削除

インスタンスを削除する。

$ gcloud compute instances delete sample1 --delete-disks=all --quiet

gcloud compute instances delete

インスタンスに SSH / RDP で接続する

Linux VMインスタンスへのSSH接続

メタデータ・マネージドSSH接続の方法(Project、もしくはVM InstanceにSSH公開鍵を登録した場合の方法)。

Linux VM への接続

$ gcloud compute ssh sample-instance --project=sample-123456 --zone=asia-northeast1-a

gcloud compute ssh

Windows VMインスタンスへのRDP接続

Window VMインスタンスの、ログイン用アカウントにパスワードを設定する。尚、パスワード・リセットも同コマンドで可能。

Windows VM のパスワードの作成

$ gcloud compute reset-windows-password sample-instance --user=foo        # ランダムなパスワードが生成される

gcloud compute reset-windows-password

RDP接続する。

Windows VM への接続

利用可能なRDPクライアント。

  • Native RDP Client
  • Chrome RDP plugin
    • Google Cloudコンソール画面から、RDPボタンを押して接続する時に利用されている
  • Chrome Remote Desktop
    • ブラウザベースでRDP接続可能
    • VMインスタンス側に、Chrome Remote Desktop Serviceを動かしておく必要あり
  • IAP Desktop

GPU を新しいインスタンスに接続し、CUDA ライブラリをインストールする

1 つ以上の GPU を使用してインスタンスを作成する場合、ホスト メンテナンス時にインスタンスが停止するように設定する必要があります。GPU を使用するインスタンスは、特定のハードウェア デバイスに割り当てられているため、ライブ マイグレーションができません。

GPU の追加または削除

VMインスタンスの作成。

$ gcloud compute instances create sample-gpu \
--image=ubuntu-2004-focal-v20210510 \
--image-project=ubuntu-os-cloud \
--machine-type=n1-standard-4 \                  # アクセラレータ最適化マシンタイプを指定
--accelerator=type=nvidia-tesla-t4,count=1 \    # 利用するGPUとGPU数を指定
--maintenance-policy=TERMINATE \                # LiveMigrationできない
--restart-on-failure

CUDAライブラリ(NVIDIA CUDA Toolkit)をインストールする。

GPU ドライバのインストール

現在実行されている VM のインベントリ（インスタンス ID、詳細）を見る

gcloud compute 使用上のヒント

詳細の確認。

$ gcloud compute instances describe sample1 --format="table(name,status, id)"
NAME     STATUS   ID
sample1  RUNNING  808218861529190553

スナップショットを操作する（例: VM からのスナップショットの作成、スナップショットの表示、スナップショットの削除）

永続ディスクのスナップショットの操作

スナップショットの作成。

$ gcloud compute disks snapshot DISK_NAME --snapshot-names=snapshot-test

gcloud compute disks shanpshot

スナップショットの表示。

$ gcloud compute snapshots list
NAME          DISK_SIZE_GB  SRC_DISK                         STATUS
tzqx0wjoz2ej  10            asia-northeast1-a/disks/sample1  READY

gcloud compute snapshots list

スナップショットの削除。

$ gcloud compute snapshots delete tzqx0wjoz2ej --quiet

gcloud compute snapshots delete

イメージを操作する（例: VM またはスナップショットからのイメージの作成、イメージの表示、イメージの削除）

ソースディスク、イメージ、スナップショット、Cloud Storage に保存されているイメージからカスタム イメージを作成し、それらのイメージを使用して仮想マシン（VM）インスタンスを作成できます。これは、永続ブートディスクまたは特定のイメージを作成して特定の状態に変更し、その状態を保存してインスタンスを作成する場合に理想的です。

カスタム イメージの作成、削除、廃止

スナップショットから、カスタムイメージの作成。

$ gcloud compute images create sample-image --source-disk=sample1 --family=sample

gcloud compute images create

カスタムイメージの表示。

$ gcloud compute images list --project=sample-123456 --no-standard-images
NAME          PROJECT       FAMILY  DEPRECATED  STATUS
sample-image  sample-123456 sample              READY

gcloud compute images list

カスタムイメージの削除。

$ gcloud compute images delete sample-image --quiet

gcloud compute images delete

VMインスタンスから、マシンイメージの作成。

マシンイメージを使用すると、Compute Engine で実行される VM インスタンス用に、すべての構成、メタデータ、権限、データを 1 つ以上のディスクから格納できます。マシンイメージを作成するために使用する VM インスタンスは、ソース インスタンスと呼ばれます。

マシンイメージの作成

$ gcloud beta compute machine-images create sample-image --source-instance sample1

gcloud beta compute machine-images create

インスタンス グループを操作する（例: 自動スケーリング パラメータの設定、インスタンス テンプレートの割り当てや作成、インスタンス グループの削除）

自動スケーリング パラメータの設定

マネージド インスタンス グループ（MIG）には、負荷の増減に基づいて、MIG から仮想マシン（VM）インスタンスを自動的に追加または削除できる自動スケーリング機能が備わっています。自動スケーリングによって、トラフィックの増加をアプリで適切に処理できると同時に、リソースの必要性が低下した場合は費用を削減できます。自動スケーリング ポリシーを定義すると、測定された負荷と構成したオプションに基づいてオートスケーラーが自動スケーリングを実行します。

利用可能な目標使用率。

  • 平均CPU使用率
  • 1秒あたりのリクエスト数、または使用率に基づいたHTTP負荷分散処理能力
  • Cloud Monitoringの指標

インスタンスのグループの自動スケーリング

作成済みのMIGに自動スケーリングを設定。

$ gcloud compute instance-groups managed set-autoscaling sample-mig \
--max-num-replicas=3 \
--min-num-replicas=1 \
--mode=on \
--target-cpu-utilization=0.60 \         # 平均CPU使用率を指標に利用
--cool-down-period=60 \
--zone=asia-northeast1-b

gcloud compute instance-groups managed set-autoscaling

インスタンス テンプレートの割当や作成

インスタンス・テンプレートを作成する。

インスタンス テンプレートの作成

$ gcloud compute instance-templates create sample-template \
--machine-type=n1-standard-2 \
--image-project=sample-123456 \
--image=sample-image \
--boot-disk-size=30GB

gcloud compute instance-templates create

インスタンス グループの削除

インスタンス・グループを削除する。

$ gcloud compute instance-groups managed delete sample-mig --zone=asia-northeast1-b --quiet

gcloud compute instance-groups managed delete

管理インターフェース（例: Cloud Console、Cloud Shell、GCloud SDK）を操作する

省略。

4.2 Google Kubernetes Engine リソースを管理する。以下のようなタスクを行います。

現在実行されているクラスタのインベントリ（ノード、Pod、サービス）を見る

ノードの表示。

$ kubectl get node
NAME                                            STATUS   ROLES    AGE     VERSION
gke-cluster-sample-default-pool-3a65b553-kmmg   Ready    <none>   6h27m   v1.19.9-gke.1400
gke-cluster-sample-default-pool-43fbf440-8ms5   Ready    <none>   6h27m   v1.19.9-gke.1400
gke-cluster-sample-default-pool-8d39884a-thgq   Ready    <none>   6h27m   v1.19.9-gke.1400

Podの表示。

$ kubectl get pod
NAME     READY   STATUS    RESTARTS   AGE
sample   1/1     Running   0          115m

サービスの表示。

$ kubectl get svc
NAME         TYPE           CLUSTER-IP   EXTERNAL-IP    PORT(S)        AGE
kubernetes   ClusterIP      10.7.240.1   <none>         443/TCP        6h28m
svc-sample   LoadBalancer   10.7.252.5   34.85.117.72   80:32650/TCP   17m

コンテナ イメージ リポジトリを閲覧し、コンテナ イメージの詳細を見る

GCRのイメージリポジトリの一覧を表示。

$ gcloud container images list --repository=asia.gcr.io/sample-123456
NAME
asia.gcr.io/sample-123456/nginx

gcloud container images list

コンテナイメージの詳細を表示。

$ gcloud container images describe asia.gcr.io/sample-123456/nginx:latest
image_summary:
  digest: sha256:61191087790c31e43eb37caa10de1135b002f10c09fdda7fa8a5989db74033aa
  fully_qualified_digest: asia.gcr.io/sample-123456/nginx@sha256:61191087790c31e43eb37caa10de1135b002f10c09fdda7fa8a5989db74033aa
  registry: asia.gcr.io
  repository: sample-123456/nginx

gcloud container images describe

ノードプールを操作する（例: ノードプールの追加、編集、削除）

ノードプールの追加と管理

ノードプールの追加。

$ gcloud container node-pools create addtional-pool \
--cluster=cluster-sample \
--region=asia-northeast1 \
--num-nodes=1 \
--node-locations=asia-northeast1-a \
--enable-autoscaling --min-nodes=1 --max-nodes=4        # クラスタ・オートスケラーの有効化

gcloud container node-pools create

ワーカーノードが追加されている。

$ kubectl get node
NAME                                              STATUS   ROLES    AGE   VERSION
gke-cluster-sample-addtional-pool-d7ffa347-gd5c   Ready    <none>   35s   v1.19.9-gke.1400
gke-cluster-sample-default-pool-3a65b553-kmmg     Ready    <none>   17h   v1.19.9-gke.1400
gke-cluster-sample-default-pool-43fbf440-8ms5     Ready    <none>   17h   v1.19.9-gke.1400
gke-cluster-sample-default-pool-8d39884a-thgq     Ready    <none>   17h   v1.19.9-gke.1400

ノードプールの編集。ノード数を2にする。

$ gcloud container clusters resize cluster-sample \
--region=asia-northeast1 \
--node-pool=addtional-pool \
--num-nodes=2

gcloud container clusters resize

ノードプールの削除。

$ gcloud container node-pools delete addtional-pool --quiet \
--cluster=cluster-sample \
--region=asia-northeast1

gcloud container node-pools delete

Pod を操作する（例: Pod の追加、編集、削除）

Pod

Podの作成。

$ kubectl run sample --image=nginx

Podの編集。

$ kubectl edit pod sample

Podの削除。

$ kubectl delete pod sample

サービスを操作する（例: サービスの追加、編集、削除）

Service

LoadBalancerタイプのサービスを作成すると、External TCP Network LoadBalancerが作成される。

$ kubectl expose pod sample --name=svc-sample --type=LoadBalancer --port=80 --target-port=80

サービスの削除。

$ kubectl delete service svc-sample

ステートフル アプリケーション（例: 永続ボリューム、ステートフル セット）を操作する

永続ボリュームの操作

リージョン永続ディスクのプロビジョニング

GCEのリージョン永続ディスクを、GKE ClusterのPersistent Volumeとして利用できる。以下はリージョン永続ディスクを指定したStorageClass作成用のマニフェスト・サンプル。

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: regionalpd-storageclass
provisioner: pd.csi.storage.gke.io
parameters:
  type: pd-standard
  replication-type: regional-pd
volumeBindingMode: WaitForFirstConsumer
allowedTopologies:
- matchLabelExpressions:
  - key: topology.gke.io/zone
    values:
    - europe-west1-b
    - europe-west1-c

ステートフルセットの操作

StatefulSet

管理インターフェース（例: Cloud Console、Cloud Shell、Cloud SDK）を操作する

省略。

4.3 App Engine リソースと Cloud Run リソースをデプロイする。以下のようなタスクを行います。

アプリケーションのトラフィック分割パラメータを調整する

省略。

自動スケーリング インスタンスのスケーリング パラメータを設定する

App Engineの自動スケーリング

app.yaml構成ファイルに、スケーリング関連のパラメーター定義をすることで設定できる。

利用可能なスケーリングタイプ。

  • 自動スケーリング
    • リクエスト率、レスポンスのレイテンシなどのアプリケーションの指標に基づきスケーリング
    • 常時稼働する最小数のインスタンスを指定可能
  • 基本スケーリング
    • アプリケーションがリクエストを受信したときに、インスタンスを作成(アイドル状態になるとシャットダウン)
    • 断続的な処理やユーザーのアクティビティに応じて動作する処理に適す
  • 手動スケーリング

インスタンスの管理方法

app.yamlの例。

automatic_scaling:
  target_cpu_utilization: 0.65
  min_instances: 5
  max_instances: 100
  min_pending_latency: 30ms             # リクエストを保留キューで待機させる最短時間
  max_pending_latency: automatic        # リクエストが保留キューで待機できる最長時間(これを超過するとスケールアップされる)
  max_concurrent_requests: 50

app.yaml - スケーリングの要素

管理インターフェース（例: Cloud Console、Cloud Shell、Cloud SDK）を操作する

省略。

4.4 ストレージとデータベースのソリューションを管理する。以下のようなタスクを行います。

Cloud Storage バケット間でオブジェクトを移動する

gsutil cp

ストレージ クラス間で Cloud Storage バケットを変換する

バケットにデータが含まれている場合は、新しい名前、ロケーション、プロジェクトを指定して新しいバケットを作成し、データを古い方のバケットから新しいバケットにコピーしたうえで、古いバケットとその内容を削除します。

バケットの移動と名前変更

Cloud Storage バケットのオブジェクト ライフサイクル管理ポリシーを設定する

オブジェクトのバージョニングを有効にする。

オブジェクトのバージョニングの使用

$ gsutil versioning set on gs://pekomiko

gsutil versioning

非現行バージョンのオブジェクトの表示。

非現行バージョンのオブジェクトの一覧表示

$ gsutil ls -a gs://pekomiko

オブジェクトのライフサイクル管理ルールを設定する。

オブジェクトのライフサイクルの管理

ライフサイクル管理ルールを定義したファイルを利用して更新。

$ gsutil lifecycle set ./lifecycle-rule.json gs://pekomiko

gsutil lifecycle

ライフサイクル管理ルールのサンプル。

{
"lifecycle": {
  "rule": [
  {
    "action": {"type": "Delete"},
    "condition": {
      "numNewerVersions": 3
    }
  },
  {
    "action": {
      "type": "SetStorageClass",
      "storageClass": "NEARLINE"
    },
    "condition": {
      "age": 100,
      "matchesStorageClass": ["STANDARD"]
    }
  },
  {
    "action": {"type": "Delete"},
    "condition": {
      "age": 300,
      "matchesStorageClass": ["NEARLINE"]
    }
  }
]
}
}

IAM Roleではなく、ACLにてバケット・オブジェクトのアクセス管理をする方法。(コンソールでの操作不可)

アクセス制御リスト（ACL）の作成と管理

$ gsutil acl ch -u zunda@goodbyegangster.com:O gs://zunpero/example-bucket

指定するパーミッションはLinuxと同じく、R(Read), W(Write),O(Owner)となる。

gsutil acl ch

データ インスタンス（例: Cloud SQL、BigQuery、Cloud Spanner、Cloud Datastore、Cloud Bigtable）からデータを取得するクエリを実行する

省略。

BigQuery クエリのコストを見積もる

ストレージとクエリの費用の見積もり

--dry_runフラグをつけてクエリを実行すると、読み取るデータ量(バイト数)を見積もることができる。

$ bq --location=asia-northeast1 query \
--use_legacy_sql=false \
--dry_run \
'SELECT name, gender, count FROM `sample-123456.sample.names_2014` limit 3'

Query successfully validated. Assuming the tables are not modified, running this query will process 637986 bytes of data.

MB単位で課金され端数は四捨五入、最小は10MBから。

クエリのドライランの実行

データ インスタンス（例: Cloud SQL、Cloud Datastore）のバックアップと復元を行う

Cloud SQLのバックアップと復元

バックアップを取得する。

オンデマンド バックアップと自動バックアップを作成、管理する

$ gcloud sql backups create --async --instance=sample-intance

gcloud sql backups create

バックアップから復元する。

インスタンスの復元

バックアップ元のインスタンスに復元(上書きリストア)する場合。

$ gcloud sql backups list -i sample-instance
ID             WINDOW_START_TIME              ERROR  STATUS
1622678175712  2021-06-02T23:56:15.712+00:00  -      SUCCESSFUL
$
$ gcloud sql backups restore 1622678175712 --restore-instance=sample-instance

gcloud sql backups restore

Cloud Datastoreのバックアップと復元を行う

Cloud Datastoreのバックアップは、エンティティのエクスポートとインポートを行う事で実現できる。

エンティティのエクスポートとインポート

特定の名前空間にある、特定の種類(kind)のエンティティをエクスポートする。

$ gcloud datastore export gs://zunpero --async \
--namespaces="(default)" \
--kinds=test

gcloud datastore export

上記でエクスポートしたエンティティをインポートする。

$ gcloud datastore import gs://zunpero/2021-06-03T02:29:59_71784/2021-06-03T02:29:59_71784.overall_export_metadata --async \
--namespaces="(default)" \
--kinds=test

gcloud datastore import

Bigtableのバックアップとリストア

バックアップを取得する。

バックアップの管理

$ gcloud bigtable backups create backup-20210607 \
--instance=sample-instance \
--cluster=sample-cluster-id-1 \
--table=my-table \
--retention-period=1d \
--async

gcloud bigtable backups create

取得したバックアップをリストアする。

$ gcloud bigtable instances tables restore \
--source-instance=sample-instance \
--source-cluster=sample-cluster-id-1 \
--source=backup-20210607 \
--destination-instance=sample-instance \
--destination=restore-table \
--async

gcloud bigtable instances tables restore

Cloud Dataproc、Cloud Dataflow、BigQuery のジョブ ステータスを確認する

Dataprocのジョブステータスを確認する

実行されたSparkのジョブを確認する。

$ gcloud dataproc jobs list --cluster=sample-cluster --region=asia-northeast1
JOB_ID                            TYPE   STATUS
400da74c05c74274b83389e69c31f2c1  spark  DONE

gcloud dataproc jobs list

Dataflowのジョブステータスを確認する

実行されたDataflowのジョブを確認する。

Dataflow コマンドライン インターフェースの使用

$ gcloud dataflow jobs list --region asia-northeast1
JOB_ID                                   NAME                              TYPE   CREATION_TIME        STATE  REGION
2021-06-05_05_27_09-3727785196286762344  beamapp-zunda-0605122649-706841  Batch  2021-06-05 12:27:12  Done   asia-northeast1

gcloud dataflow jobs list

BigQueryのジョブステータスを確認する

BigQuryジョブとは、データの読み込み、データのエクスポート、データのクエリ、データのコピーなど、BigQuery がユーザーに代わって実行するアクションのことです。

BigQuery ジョブの概要

ジョブ実行履歴を確認する。

ジョブの管理

$ bq ls --jobs --all -n 5 sample-123456
                         jobId                           Job Type    State      Start Time         Duration
 ------------------------------------------------------ ---------- --------- ----------------- ----------------
  scheduled_query_60b7267f-0000-2e38-86bd-30fd38166cc8   query      SUCCESS   03 Jun 13:46:13   0:00:01.215000
  bquxjob_66343773_179d030c84a                           query      SUCCESS   03 Jun 13:45:28   0:00:00.028000
  bqjob_r72dc1deb8a410791_00000179d01d76f0_1             query      SUCCESS   03 Jun 13:24:23   0:00:00.221000
  bquxjob_49377bf4_179d01cf5a8                           query      SUCCESS   03 Jun 13:23:49   0:00:00.261000
  bqjob_r1d01ec8414166ac5_00000179d011f5c4_1             load       SUCCESS   03 Jun 13:11:49   0:00:01.307000

bq ls --jobs

実行されたジョブの詳細を確認する。

$ bq show --format=prettyjson --job sample-123456:bquxjob_66343773_179d030c84a

bq show

管理インターフェース（例: Cloud Console、Cloud Shell、Cloud SDK）を操作する

省略。

4.5 ネットワーキング リソースを管理する。以下のようなタスクを行います。

既存の VPC にサブネットを追加する

サブネットを追加する。

$ gcloud compute networks subnets create sample-subnet \
--network=custom-vpc \
--range=192.168.0.0/24 \
--region=asia-northeast1

gcloud compute networks subnets create

サブネットを拡張して IP アドレスを増やす

サブネットのCIDRを拡張する。

$ gcloud compute networks subnets expand-ip-range sample-subnet \
--region=asia-northeast1 \
--prefix-length=16

gcloud compute networks subnets expand-ip-range

静的外部または内部 IP アドレスを予約する

IPアドレスの種類。

静的外部IPアドレスを予約する。--addressesフラグで既存のエフェメラルIPアドレスを指定すると、静的IPアドレスに昇格される。

静的外部 IP アドレスの予約

$ gcloud compute addresses create sample-external-ip \
--region=asia-northeast1

gcloud compute addresses create

静的内部IPアドレスを予約する。

静的内部IPアドレスの予約

$ gcloud compute addresses create sample-internal-ip \
--region=asia-northeast1 \
--subnet=sample-subnet \
--addresses=192.168.0.10

gcloud compute addresses create

管理インターフェース（例: Cloud Console、Cloud Shell、Cloud SDK）を操作する

--filterオプションを利用して検索。

$ gcloud compute networks subnets list --filter="region:asia-northeast1 OR region:asia-northeast2"
NAME           REGION           NETWORK     RANGE
default        asia-northeast1  default     10.146.0.0/20
default        asia-northeast2  default     10.174.0.0/20
$
$ gcloud compute networks subnets list --filter="REGION:(asia-northeast1 asia-northeast2)"
NAME           REGION           NETWORK     RANGE
default        asia-northeast1  default     10.146.0.0/20
default        asia-northeast2  default     10.174.0.0/20

--formatオプションを利用して表示。

$ gcloud compute networks subnets list \
--format="table[box,title=Subnets](REGION,RANGE)" \
--filter="region:asia-northeast1 OR region:asia-northeast2"
┌──────────────────────────────────┐
│             Subnets              │
├─────────────────┬────────────────┤
│      REGION     │     RANGE      │
├─────────────────┼────────────────┤
│ asia-northeast1 │ 10.146.0.0/20  │
│ asia-northeast2 │ 10.174.0.0/20  │
└─────────────────┴────────────────┘

gcloud による出力情報のフィルタと整形

4.6 モニタリングとロギングを行う。以下のようなタスクを行います。

リソース指標に基づいて Stackdriver アラートを作成する

Cloud Monitringのアラート機能を利用する。

API によるアラート ポリシーの管理

作成したポリシーファイルを登録する。

$ gcloud alpha monitoring policies create --policy-from-file="rising-cpu-usage.json"

ポリシーファイルのサンプル。

サンプル ポリシー

Stackdriver カスタム指標を作成する

カスタム指標の作成

ログが外部システム（例: オンプレミスまたは BigQuery）にエクスポートされるようにログシンクを構成する

Google Cloud Console でのログのエクスポート

Stackdriver のログを表示、フィルタリングする

ログ エクスプローラの使用

コマンドラインで表示。

$ gcloud logging read "resource.type=gce_instance AND logName=projects/sample-123456/logs/syslog" --limit 1 --format json

Reading log entries

フィルタリングのための言語。

Logging のクエリ言語

Stackdriver のログメッセージの詳細を見る

省略。

Cloud Diagnostics を使用してアプリケーションの問題を調査する（例: Cloud Trace データの確認、Cloud Debug を使用したアプリケーションのポイントインタイムの確認）

Cloud Error Reportingについて。

Error Reporting では、Google Cloud プロジェクト内のすべてのアプリとサービスおよび Amazon Elastic Compute Cloud（EC2）アプリケーションからのエラー条件を一元的にモニタリングできます。

Error Reporting のクイックスタート

Cloud Traceについて。

Cloud Trace では、アプリケーションの分散トレースデータを提供します。アプリケーションをインストルメント化すると、Cloud Trace コンソールで、1 つのリクエストのレイテンシ データを分析して、アプリケーション全体の集約したレイテンシを確認できます。

概要

ソースコード内に、指定のライブラリ(OpenTelemetry クライアント ライブラリ等)を組み込む事で、トレース情報をCloud上へ連携してあげる。

Cloud Debuggerについて。

Google Cloud上で動作するコードのスナップショット(ローカル変数のキャプチャ等)を利用して調査できるもの。

Python 用 Cloud デバッガの設定

ソースコード内に、指定のライブラリ(google-python-cloud-debugger等)を組み込む事で、ソースコードをCloud上に連携している。

Google Cloud Platform のステータスを見る

Google Cloud Status Dashboard

管理インターフェース（例: Cloud Console、Cloud Shell、Cloud SDK）を操作する

省略。

5. アクセスとセキュリティの構成

5.1 Identity and Access Management（IAM）を管理する。以下のようなタスクを行います。

IAM ロールの割り当てを見る

割り当てを確認する。

現在のポリシーの取得

$ gcloud projects get-iam-policy sample-123456 --format=yaml

gcloud projects get-iam-policy

出力されるポリシーファイルのサンプル。

bindings:
- members:
  - user:mike@example.com
  - group:admins@example.com
  - domain:google.com
  - serviceAccount:my-project-id@appspot.gserviceaccount.com
  role: roles/resourcemanager.organizationAdmin
- members:
  - user:eve@example.com
  role: roles/resourcemanager.organizationViewer
  condition:
    title: expirable access
    description: Does not grant access after Sep 2020
    expression: request.time < timestamp('2020-10-01T00:00:00.000Z')
- etag: BwWWja0YfJA=
- version: 3

Policy

IAM ロールをアカウントまたは Google グループに割り当てる

上記コマンドget-iam-policyで取得したpolicyファイルを編集して、そのファイルを適用する。

$ gcloud projects set-iam-policy sample-123456 ./iam-policy.yaml

gcloud projects set-iam-policy

カスタム IAM ロールを定義する

カスタムIAMロールを作成するには、マニフェストファイルを作成して適用するか、gcloudコマンドのパラメーターで指定する。

カスタムロールの作成と管理

カスタムIAMロールの作成。

$ gcloud iam roles create sampleCustomRole \
--project=sample-123456 \
[--organization=ORGANIZATION-ID] \                         # projectのほか、Organizationに対してもカスタムIAMロールを作成できる
--title="Sample Custome Role" \
--description="sample" \
--permissions=storage.buckets.list,storage.objects.list \   # 付与する権限を指定
--stage=GA

gcloud iam roles create

カスタムIAMロールに付与できる権限の一覧。

カスタムロールでの権限のサポートレベル

IAMロールを、Organizationや別プロジェクトにコピーする。

$ gcloud iam roles copy \
--source-project=sample-123456 \
--source=sampleCustomRole \
--dest-project=copy-123456 \    # Organizationをコピー先として指定もできる
--destination=copyRole

gcloud iam roles copy

5.2 サービス アカウントを管理する。以下のようなタスクを行います。

特権が制限されているサービス アカウントを管理する

サービス アカウントは、ユーザーではなく、アプリケーションや仮想マシン（VM）インスタンスで使用される特別なアカウントです。アプリケーションはサービス アカウントを使用して、承認された API 呼び出しを行います。これは、サービス アカウント自体として承認されるか、ドメイン全体の委任により Google Workspace または Cloud Identity ユーザーとして承認されます。

サービス アカウント

サービスアカウントの作成。

$ gcloud iam service-accounts create sample-sa \
--display-name="Sample Service Account"

gcloud iam service-accounts create

サービスアカウントにIAMロールを付与する。

$ gcloud projects add-iam-policy-binding sample-123456 \
--member="serviceAccount:sample-sa@sample-123456.iam.gserviceaccount.com" \
--role="roles/editor"

gcloud projects add-iam-policy-binding

サービス アカウントを VM インスタンスに割り当てる

VMインスタンス作成時に、サービスアカウントを割り当てる。

インスタンスのサービス アカウントの作成と有効化

$ gcloud compute instances create sample-with-sa \
--service-account=sample-sa@sample-123456.iam.gserviceaccount.com \
--scopes=cloud-platform

scopesのAlias

別のプロジェクトのサービス アカウントにアクセス権を付与する

サービスアカウントsample-sa@sample-123456.iam.gserviceaccount.comに、プロジェクトaaaaaa-123456のIAM Roleroles/editorを付与する。

$ gcloud projects add-iam-policy-binding aaaaaa-123456 \
--member="serviceAccount:sample-sa@sample-123456.iam.gserviceaccount.com" \
--role="roles/editor"

5.3 プロジェクトとマネージド サービスの監査ログを見る。

Cloud Audit Logsの概要

Cloud Audit Logsは、組織・フォルダ・プロジェクト毎に、以下の監査ログを収集している。

  • 管理アクティビティ監査ログ
    • リソース構成を変更するAPIの呼び出し履歴
    • 管理アクションの履歴
  • データアクセス監査ログ
    • リソース構成を参照するAPIの呼び出し履歴
    • ユーザー定義データ(GCS上のオブジェクト等)のアクセス履歴
    • BigQueryを除いて、デフォルトで無効になっている
  • システム イベント監査ログ
    • リソース構成を変更するGoogle Cloud側アクションの履歴
  • ポリシー拒否監査ログ

gcloud logging readにて、表示するグループ毎に、表示したいログを指定する。

$ gcloud logging read "logName : projects/sample-123456/logs/cloudaudit.googleapis.com%2Factivity" --project=sample-123456 --limit=1

表示する監査ログの指定方法