ACE対策ノート
サービス説明
★設計思想
WSC
「The Datacenter as a Computer」という論文がベース
初版が2009年で、2018年に第３版が発表
論文中で「WSC: Warehouse-Scale Computer」という思想が紹介
WSCの３つのポイント
インフラ設計の標準化
インフラを１つのコンピュータのように扱う
大規模分散処理の実現
ゼロトラストネットワーク
ゼロトラストネットワークは、信頼できるもの同士をピンポイントで接続する
対比は境界型ネットワーク
境界型ネットワークは、VPNでアクセスすることを前提とし、内部ネットワークを検証しない
Google自社内ではBeyondCorpというゼロトラストネットワークを導入
これはCloud IdentityやCloud IAP(Identity-Aware Proxy)に導入されている
またBeyondCorp Enterpriseと呼ばれるサービスも提供
オープンクラウド
Google Cloudで使用される多くの技術をOSSとして公開
クラウドベンダとしては珍しいマルチクラウドも対応
オープンな技術によりベンダーロックインからの解放
★アカウント
◆アカウント
Googleアカウント
プロジェクト作成や課金情報の設定が可能
プロジェクト自体の管理者権限にあたる「owner」のロールが付与されるため、非常に強い権限を持つ
サービスアカウント
Google Cloud内で稼働するリソースやGoogle Cloud外のアプリケーションが、Google CloudのAPIにアクセスする際に使用するアカウント
各サービスを利用するための権限を付与可能
サービスアカウントは、アカウントキー（キーペア）を作成可能
Compute EngineやApp Engineなどの一部のサービスは、サービスアカウントが自動で生成される
プロジェクト
サービス、API、課金情報などの利用環境を分割するもので、リソース階層の一つ。
プロジェクト名は変更可能だが、プロジェクトIDは変更不可
プロジェクトの分割単位は、アプリケーションごと、環境（本番・開発など）ごと、とするケースが多い
プロジェクトは、一度に1つの課金アカウントにしか紐付けられない。
1つの課金アカウントは、複数のプロジェクトの課金を処理することができます。
◆Google Cloud コンソール
Webブラウザでリソースを操作するツール
可能な操作
アカウントや権限の管理
サーバーやDBなどリソース管理
課金管理
仮想マシンへのSSH接続
モバイルアプリを利用した管理・通知
Cloud Shellを利用したCLIベースのオペレーション
Operations suiteによる横断的な監視・診断
作業の際はプロジェクト指定が必要
◆gcloud CLI
初回設定時は、gcloud initで認証し、以降はgcloud auth loginで認証
複数の切り替えを設定する場合は以下
gcloud config configurations create
◆リソース階層
以下の階層構造をもつ
組織：Organization
企業単位、ドメイン単位
組織を作成する場合は個人利用のGoogleアカウントではなく、Google WorkspaceやCloud Identityで管理されたアカウントが必要
組織には組織全体に適用可能な組織ポリシーという機能がある
組織ポリシーは、組織全体に対して機能の「制限を」かけるものである
一方、IAMポリシーは個々のユーザーに対して権限を「設定」するもの
フォルダ：Folder
部門単位（開発チーム、分析チーム）
なお、フォルダの中にフォルダを分けるような階層を構成することも可能
プロジェクト
階層の最も下の単位
前述のとおり、アプリケーションや環境単位で作成
リソース
実際に使用されるリソース（Compute EngineやGKEなど）
フォルダ単位で管理ポリシーを設定することで、アクセス制限や権限設定を適切に実施可能
◆IAM
IAMの構成
誰が
Googleアカウント、Googleグループ、サービスアカウント
何に対して
各リソース
どのアクションを実行できるか
ロールの付与で行う
ロールに許可するアクションをまとめて設定する（アクションをIAMで指定することはできない）
オプションとして接続元IPアドレスや有効期間などを指定することも可能
ロール
ロールは権限(パーミッション)をまとめたもの
Computeインスタンス管理者
compute.instances.list, compute.instances.delete, compute.neworks.get, compute.disks.resize, …
BigQueryデータ閲覧者
bigquery.datasets.get, bigquery.datasets.getIamPolicy, bigquery.tables.export, bigquery.tables.list, ..
ロールには３種類ある
基本ロール
IAM導入前から存在していたロール
roles/owner, roles/editor, roles/viewerの３種類が存在
roles/owner：すべての権限を変更可能な権限。課金情報も設定可能
roles/editor：リソースのアクセス権を変更可能。ほとんどのリソースの作成・変更・削除が可能
roles/viewer：読み取り専用の権限
基本ロールには何千もの権限が含まれるため、特に必要ない場合は利用非推奨
事前定義ロール
使いやすくまとめられたロール
多くのリソースで、「管理者・編集者・読み取り」という役割毎にロールが用意
例
roles/storage.admin：オブジェクトとバケットのすべてを管理する権限
roles/storage.objectAdmin：オブジェクトのすべてを管理する権限
roles/storage.objectCreator：オブジェクトの作成や閲覧のみ
roles/storage.objectViewer：オブジェクトやメタデータ(ACL以外)の閲覧のみ
カスタムロール
ユーザー側で権限を自由にまとめられるもの
アップデート等でリソースに新しい権限が追加された場合、自身でメンテナンスが必要な点は要注意
IAMポリシー
バインディング
１つ以上のGoogleグループ、Googleアカウント、サービスアカウント、ドメインを１つ以上のロールに関連付けたもの
ポリシーは必ず１つ以上のバインディングを持つ
プロジェクトにアタッチすればそのプロジェクト内で権限が有効となる
複数のプロジェクトにアタッチしたり、フォルダにアタッチすることも可能
監査構成
ログに記載する内容を制御することが可能
メタデータ
ポリシーを記述するスキーマのバージョンなどのシステム管理情報
IAM Conditions
IAMポリシーに条件を追加する機能
ポリシーに期限を設けたい、一部のIPアドレスに制限したい、特定のバケットにのみIAMポリシーをアタッチしたい
プロジェクトのアクセス制御をするためには以下の権限が必要
resourcemanager.projects.getresourcemanager.projects.getIamPolicyresourcemanager.projects.setIamPolicy
Cloud Billing
料金確認が可能なサービスで、Google Cloudコンソールで使用
予算とアラートなどもこちらで設定可能
特定のプロジェクトなどの条件を絞った確認が可能
リソースの使用料金を調査するには、リソースにラベルを貼付する
タグは、ポリシーを詳細に制御するためのもので、ラベルと区別する。
プロジェクトで使用するリソースの割り当てを設定することで、リソース利用量が指定限度を超えることを防ぐことができる
★リージョン
リージョン
27のリージョンと82のゾーンで構成（2021年7月時点）
リージョンはデータセンターの集合体
リージョン選択時は、レイテンシや利用可能なサービス、料金を確認する
ゾーン
ゾーンは、サービスが稼働するエリアで、特定のデータセンターの建物単位とは限らない
ゾーンは、電源やネットワークを共有した単一障害ドメインと見なせる
各リージョンには３つ以上のゾーンが存在
冗長構成
マルチゾーン、マルチリージョンを構成可能
マルチリージョンには、以下のようなおもにストレージ系のサービスなどが対応
Firestore
Cloud Storage
BigQuery
Cloud Spanner
Cloud Bigtable
グローバルプロダクト
一部のサービスはリージョンに依存せず利用可能
Cloud CDN
Cloud DNS
Cloud Armor
Cloud Logging
Cloud Build
★サービス一覧
https://cloud.google.com/products?hl=ja
◆コンピューティング
Compute Engine
仮想マシンを使って構築するタイプのコンピューティングリソース
OSの選択と構成を完全にコントロールすることができます。
サーバーやOSのレベルで管理を行う場合に選択する
従来のアプリを素早く移行するための素晴らしい選択肢となり、既存のコードを変更することなく、クラウド上にソリューションを実装することができます。
ライブマイグレーション
仮想マシンを稼働したまま、別の物理サーバー上へ移動する仕組み
物理サーバーをメンテナンスしたい場合でも稼働の継続が可能
ハードウェア障害が発生した場合でも、ライブマイグレーション機能自体に影響がない障害であれば、ライブマイグレーションが実行される
ユーザ側は設定を意識する必要がない
必ず行われるわけではないため、完全に故障した場合などはホストエラーとなり、再起動される
また以下のインスタンスは対象外
GPUが割り当てられたインスタンス
スポット（前身：プリエンプティブル）属性を持ったインスタンス
ホストエラー
仮想マシンの停止が発生すること。この場合、再起動が行われるため一定期間利用不可となる
ホストエラーはまれではあるものの、システム構築の際に考慮が必要
インスタンスへのアクセス
Cloud Shell、gcloud、SSH、RDPなどを使用して行うことが可能
インスタンスの作成
プロジェクト内で一意の名前を持つ必要がある
マシンタイプファミリーは、汎用・メモリ最適・コンピューティング最適・GPUから選択
変更できない要素
名前・リージョン・ゾーン・ブートディスク
変更可能な要素
サービスアカウント・ディスク容量・マシンタイプ・プリエンプティブル
マシンタイプの変更時には、インスタンスの停止が必要
追加ディスク
ブートディスクとは別のディスクを追加可能
ネットワーク
VPCとサブネットを選択（初期設定のままであればdefaultとなる）
プライマリ内部IP
エフェメラル（自動）・エフェメラル（カスタム）・IPアドレスの作成から選択
初期設定は、エフェメラル（自動）
外部IP
なし・エフェメラル・IPアドレスの作成から選択
初期設定は、エフェメラル
ネットワークサービス階層
スタンダード・プレミアムを選択
初期設定はプレミアム
IP転送
パケットのルーティング（初期設定はオフ）
パブリックDNS PTRレコード
パブリックの逆引きDNS名を入力し、外部アドレスに関連付け（初期設定はオフ）
使用可能なOSイメージ
公開イメージ（無料）
Debian・Ubuntu・CentOS・Fedra CoreOS(軽量)・Container Optimized OS(Dockerに最適化)
プレミアムイメージ
RHEL(Red Hat)・SLES(SUSE)・Windows Server
オンデマンドライセンスとBYOSの２種類ある
BYOSは、既存のサブスクリプションをGoogleのイメージに適用可能
その他、Google Cloud MarketplaceでFreeBSDなどのイメージも調達可能
使用料金
インスタンスの利用料
OSの利用料
ディスクの利用料
ネットワークの利用料
オプション（外部IPなど）
利用料金の割引
継続利用割引(SUD: Sustained use discounts)
１か月の利用期間が25%を超えた場合、最大で30%割引を受けられる
割引率はインスタンスタイプによって異なる
確約利用割引(CUD: Committed use discounts)
１年間または３年間分の支払いを確約する代わりに割引購入ができる仕組み
多くは最大57%で、メモリ最適化の場合は最大70%の割引となる
一度購入するとキャンセルは不可
インスタンスの推奨サイズの提案
Cloud Monitoringにより、過去８日間の稼働実績に合わせて推奨サイズを提案
インスタンスにMonitoringエージェントをインストールすれば、更に正確な提案がされる
マシンタイプ
種類
汎用：N1、N2、N2D、E2など
コンピューティング最適：C1など
メモリ最適：M1、M2など
アクセラレータ：A2など
マシンタイプの変更時には、インスタンスの停止が必要
その他
共有コアマシンタイプ
CPUバースト機能をもったマシンタイプ
コスト効率がよい
スポット（前身：プリエンプティブル）
Compute Engineの余剰リソースを利用するオプション
稼働中は停止する可能性があり、起動は最大２４時間、ライブマイグレーションなしなどの制約がある
その分通常のインスタンスに比べて安価に利用できるため、バッチジョブなどのユースケースに使用
カスタムマシンタイプ
vCPUやメモリサイズをユーザー自身で定義可能
ただしvCPU数は２の倍数で、vCPU毎にメモリ上限がある
インスタンス削除防止機能
コンソールで誤って削除されるのを防止するオプション
ストレージ
永続ディスク
ブートディスクは必ずこの種類
インスタンスを停止・削除してもデータは削除されない
インスタンスと独立しているため、他のインスタンスに再度接続することも可能
永続ディスクに３つの種類がある
標準：標準HDDによりバックアップされる構成
SSD：SSDによりバックアップされる構成
バランス：SSDによりバックアップされる構成だが値段が抑えめ
リージョン永続
各タイプでリージョン永続を選択可能
リージョン内の複数ゾーンで自動的にレプリケーションを実施
ローカルSSD
永続ディスクよりも高速にアクセス可能
インスタンスを停止・削除するとデータが削除される
ローカルSSDをアタッチしたVMは停止できなくなる
また内部でシャットダウンを実行された場合、VMへ接続不可となる
そのため基本は常時稼働、あるいはプリエンプティブルVM・スポットVMでのステートレスな利用をする
ネットワーク
原則として下りの通信に対してデータ量に応じた課金
プレミアムティアとスタンダードティアがある
VM間の通信にも課金が発生する場合があり、それぞれが異なるゾーン（あるいはリージョン）にある場合は料金が発生
接続方法
Cloud ShellからのSSH接続
gcloud CLI（外部IPが必要）
ローカルPCからのSSH接続（外部IPが必要）
Cloud IAPの利用
リバースプロキシサービスで踏み台サーバーなしでもセキュアな接続を可能
IAPを利用できるのは、Cloud IAMで適切なロールがあるアカウントのみ
スナップショット
ある時点の永続ディスクから増分的にデータをバックアップしたもの
自動的に圧縮されるため、ディスクの完全なコピーをバックアップとして作成するよりも高速、かつ低コストでバックアップを実現可能
毎時や毎週などスケジューリングを設定可能
バックアップには、ストレージ料金とネットワーク料金（Cloud Storageへの通信費用）が必要
同じゾーン、同じリージョン、同じdisktypeである必要がある。（サイズは複製先の方が大きければOK）
マシンイメージ
インスタンス全体をバックアップ可能で2022年1月にGAされた
個々のディスクではなく、接続された複数のディスクをまとめてバックアップ可能
ファイアウォール設定などもそのまま引き継ぎ可能
スケジューリングは設定できないため、Cloud Functionsなどとの連携が必要
カスタムイメージ
既存のインスタンスやスナップショットを元に作成が可能なイメージ
プロジェクト間で共有が可能で、開発環境のイメージを本番環境に展開するなどが可能
また冗長構成を構築する場合に、環境を複製する場合にも使用可能
マネージド インスタンス グループ（MIG）
インスタンス テンプレートとオプションのステートフル構成で指定した構成に基づいて MIG の各マネージド インスタンスを維持
リージョン MIGにより複数のゾーンに分散が可能
異種混合のクラスタを使う場合は、アンマネージドなインスタンスグループを使用する必要がある
単一テナントノード
単一テナントノードを使用するとノードに独占的にアクセスできます。
他のプロジェクトからVMを物理的に分離できる。
コマンド例
スナップショット一覧取得
gcloud compute snapshots describe
プロジェクトIDを調べる
gcloud compute project-info desribe --project {PROJECT-ID}
Windows Serverのイメージリストを取得
gcloud compute images list --project windows-cloud --no-standard-images
ロール例
インスタンスにフルアクセスし、サービスアカウントをインスタンスに割り当てる
roles/compute.instanceAdmin.v1roles/iam.serviceAccountUser
Google Kubernetes Engine（GKE）
マネージドなKubernetesサービス
自動スケーリングが可能でコンテナを動かすクラスタをすぐに作成可能
自動修復や自動アップグレードなど運用負荷を軽減する仕組みが準備
サーバーやOSのレベルで管理はサービス側に任せる場合に使用
コンテナのオーケストレーションと可用性を完全に制御することが可能
Kubernetesとは
コンテナオーケストレーションツール
コンテナのライフサイクル、ネットワーク設定などを統合的に管理可能
設定はYAML形式に記述
代表的な機能は、ヘルスチェック、オートスケール、スケジューリング、ロールアウト・ロールバック、サービスディスカバリなど
GKEの特徴
大量のクラスタ作成からネットワーク設定をワンライナーで実行可能
クラスタ名、ロケーションの指定、マスターバージョン（マスターノード）の指定という３つを設定すれば作成可能
GKEのモード
標準モード：クラスタとマスターモードを自動で管理するモード
作業者があらかじめワーカーノードの設定を定義する
Autopilotモード：標準に加えてワーカーノードも自動で管理するモード
ワーカーノードが必要分自動的にオートスケーリングで確保される
料金
標準の場合、「クラスタの管理料金」と「ノードの管理料金の合計」
Autopilotの場合、「vCPUの料金」と「ポッドメモリの料金」と「エフェメラルストレージの料金」の合計
階層構造
クラスタ
後述のノード群をまとめたもの
ノード
マスターノード
クラスタ全体を監視するノード
クラスタに対する操作はマスターを経由して実行
普段意識することは少ない
ワーカーノード
アプリケーションが実際にデプロイされるノード
実際どのワーカーノードにデプロイされるかは作業者は指定せず、おおまかなルールに沿ってマスターノードが開いているワーカーノードに自動的にデプロイする
ポッド
デプロイする際の最小単位
ポッドはアプリケーションが消費するリソース情報を設定ファイルでテンプレート化する
関連する機能をもつコンテナを複数詰め込むこともある（例：サイドカーコンテナ）
サービス
複数デプロイされた同じタイプのポッドを１つのリソースにグループ化したもの
グループ化されたポッドへのアクセスを提供
以下の５つのタイプがある
ClusterIP：一番基本となるサービス。クラスタ内部でポッドにアクセスを振り分け。クラスタ内でのみ疎通できる仮想IP。
NodePort：外部から直接アクセスできるサービス。あらかじめ指定したポートでアクセスする。振り分け先はClusterIPサービスとなる。
LoadBalancer：GKE内でのTCPロードバランサの仕組み。ワーカーノードのNodePortを宛先としてバランシングする
ExternalName：外部ドメインへアクセスできる仕組み。
Headless：ポッドのIPアドレスを返却する仕組み
Ingressを使った外部ロードバランサとの連携
GKEでは、外部HTTP(S)負荷分散との連携が可能
デプロイ
レプリカセット
期待するポッド数を定義するリソース
デプロイメント
デプロイメントリソースを設定すると、ポット情報が変更された場合に、自動的に新しいレプリカセットとポッドが作成され、ローリングアップデートが行われる。
これはロールバックの際も同様に行うことができる。
ヘルスチェック機能
さまざまな要因でコンテナに異常が発生したとき、ポッドの設定情報をもとにして、新しいコンテナを一から起動し直します。
マルチゾーンクラスタとリージョンクラスタ
ソーンクラスタ：マスター、ワーカーともにシングルゾーン
マルチゾーンクラスタ：マスターはシングルゾーン、ワーカーはマルチゾーン
リージョナルクラスタ：マスター、ワーカーともにマルチゾーン
オートスケール
GKEには２種類ある
ワーカーノードを増減するオートスケール
Node Poolを定義したうえで、「自動スケーリングを有効化」設定する
中身は、Compute Engineのオートスケールと同じ
稼働するポッドを増減するオートスケール
Horizontal Pod Autoscaler(HPA)を定義する
コストの整理
namespacesとLabelsを使用する
Cloud Operations for GKE
create時に「--enable-stackdriver-kubernetes」を指定することで有効化
ログ
STDOUT, STDERRがログとしてcollectsされる
コマンド例
オートスケールの設定
kubectl autoscale rc my-app-rc --min=2 --max=6 --cpu-percent=80
マニフェストファイルからクラスターをデプロイ
kubectl apply -f my-app.yaml
クラスタ作成
gcloud container clusters create with --enable-autoscaling X --min-nodes X --max-nodes X
App Engine
アプリとバックエンド向けのサーバーレスアプリケーションプラットフォーム
設定ファイル（YAML形式）を書き、コマンドを1つ実行するだけでデプロイ
デプロイはBlue-Green デプロイメントにもとづいて行われる
自動でスケールするWebアプリケーションを簡単に構築可能
２種類の環境
スタンダード環境
低コスト運用を目的とした環境。制限は多いが、最小インスタンス数を0にすることも可能
対応言語は、Python、Java、Node.js、PHP、Ruby、Goのみ
SSH接続不可
フレキシブル環境
任意の言語を使用可能で、SSH接続も可能。
複数のyamlから構成する
app.yaml
アプリケーション全体の仕様が記載
cron.yaml
スケジュールされたジョブを実行するための仕様が記述
dispatch.yaml
ルーティング・ルールを上書きするためのもの
index.yaml
複数の属性を参照する複雑なクエリ用のインデックスを記載
Cloud Run
コンテナ化アプリを実行するためのフルマネージド環境
GKEと比較
上位のレイヤまで運用管理が不要で、１つのDockerfileで構築できるアプリケーションがユースケース
GKEはより柔軟にストレージやネットワーク構成が可能で、コンテナ同士の通信が必要な場合はGKEが良い
App Engineとの違いは、コンテナかどうかという点
デプロイ方法
イメージのURLを指定
Cloud Runからアクセス可能なストレージにビルド済みイメージを格納してURLを指定
ソースリポジトリを指定
Dockerfileを用意してCloud Buildを使用してデプロイ
ソースレポジトリには、GitHub、Bitbucket、Cloud Source Repositoriesが指定可能
料金
実行時に使用したCPUやメモリ、下りネットワークの使用量
リクエスト数に応じた料金
リクエストがないときは、自動でインスタンス数を0に下げることが可能で無課金できる
Cloud Functions
小さなコードのスニペットを開発し、実行することを基本とするサーバーレスサービス
HTTPリクエストやGoogle Cloud の各種サービスのイベントをトリガーに、関数を実行するサーバーレスサービス
Cloud Storageなどにファイルのアップロード等あらかじめ登録した操作が行われた際に自動起動可能
あくまで小規模な機能を実行するサービスという位置づけ
2022-08-22に2nd genがGAとなり、Cloud Runベースとなった
使用可能なリクエスト処理時間やインスタンス規模がパワーアップ
デプロイ方法
gcloudコマンド、コンソールからデプロイ
GitHub、Bitbucketからのデプロイ
料金
関数の実行時間、実行回数、ネットワーク（下り）でそれぞれ課金
Shielded VM
セキュリティが強化された仮想マシン
Secure Boot、Virtual Trusted Platform Module enabled Measured Boot、およびIntegrity Monitoringを使用
◆データベース
Cloud SQL
MySQLやPostgreSQL、SQL Serverをフルマネージド環境として提供するサービス
バックアップやレプリケーション、暗号化、容量増加を簡単に実施可能
MySQL、PostgreSQL、SQL Serverからの移行が可能
柔軟なスケーリング、すばやいプロビジョニング
ああ
セキュリティの仕組み
暗号化、プライベート接続、ユーザー認証
テーブルごとのアクセス制御も可能
マシンタイプ
共有コア、軽量、標準、ハイメモリの４種に加えてカスタムがある
SQL Serverでは共有コアが使用できない
各タイプで、複数のスペック（vCPU・メモリ）が選択可能
料金
マシンタイプ、ストレージ、ネットワーク単位で課金
共有コアの場合は、マシンタイプではなく、インスタンス料金となる
SQL Serverの場合は、上記に加えてライセンス料金が必要
ロケーション
リージョン、ゾーンを選択する
リージョンは作成後変更不可、ゾーンは変更可能
接続方法
パブリックIPの場合
接続元のIPの登録が必要
複数の接続元がある場合は、Cloud SQL Auth Proxyを使用
プライベートIPの場合
同じVPCや共有VPC、Cloud VPNやCloud Interconnectで接続したオンプレから接続可能
Cloud Spanner
グローバル分散機能を備えたクラウドネイティブなRDB
無制限なスケーリングが可能
世界規模でトランザクションの一貫性を確保可能
マルチリージョナルの構成で99.999%（ファイブナイン）の可用性
負荷やデータサイズにもとづいて自動的にシャーディング（水平分割）を実施
シャーディングとは、データを複数のノードに分散して保存し、スルー プットを上げる手法
制約
自動採番機能が実装されていない。
単調に増加するシーケンシャルな値を主キーとして使用することは推奨されておらず、ランダムなUUIDが推奨
主キーの値に応じてデータを分散保存するため、シーケンシャルな主キーではデータの偏りが発生
テーブルごとのアクセス制御は不可
IAMによるデータベースレベルでのアクセス制御のみをサポート
Firestore
ネイティブモードとDatastoreモードがある
クラウドネイティブなドキュメント型のNoSQLデータベース
クライアントからの直接アクセスが可でWebやモバイルアプリ、IoTアプリに使用
コレクションやドキュメントという概念でデータを保存し、柔軟なデータ検索が可能
ドキュメントの読み書きに対してトランザクションを実行するので、データ整合性を保持可能
リアルタイム同期
複数のデバイスによるリアルタイム同期が可能
オフライン時には、ローカルストレージに永続化し、オンライン復帰時に同期
Datastoreモード
一般的なキーバリューストアと違いエンティティグループ仕組みでデータ同士を紐付け可能
すべてのクエリで強整合性を保証し、更新直後から最新であることが保証
以前のDatastore単体のサービス時はクエリ種類により結果整合性となっていた
以下の場合はDatastoreを選択可能
クライアントライブラリが不要
リアルタイム機能が不要
大規模なバイナリファイルを効率的に処理するのには向かない
コマンド例
バックアップをバックグラウンド実行
gcloud datastore export gs://my-datastore-backup --async
Firebase Realtime Database
クラウドネイティブなドキュメント型のNoSQLデータベース
データはJSONとして保存され、接続されているクライアントとリアルタイムで同期可能
Forestoreと同様、オフライン時にはSDKを使用してローカルに永続化する
データ同期はHTTPリクエストではなくWebSocketを利用し、ミリ秒単位で更新
クライアントからの直接アクセスが可能
スケーリング
Blazeプランの仕様で、複数のデータベースインスタンスにデータ分割し、大規模データに対応可能
Cloud Bigtable
列指向でキーバリューストア型のNoSQLデータベース
Cloud Bigtableは、ペタバイト規模のNoSQLで、特定のクエリに最適化された行キーを持つカラムファミリー・データベースです。歴史的、時間的なデータの保存に用いられ、この要件に応えるものです。
低レイテンシ、高スループットが特徴で、BigQUeryよりも低レイテンシが特徴
IoT で求められる高速の読み書きなどに対応
バイナリファイルの保存には制限があるため適さない
Google検索やYoutube、Googleマップなどのサービス基盤にも使用
HBase API規格をサポートし、HBaseからの移行が可能
Hadoopなどを利用している場合は、移行に関わる変更が少なくて済む
ノード追加により再起動なしでスケールが可能
Memorystore
キーバリューストア型のNoSQLデータベース
マネージドなRedisとmemcachedのインメモリデータベース
基本は揮発性のデータだが、ハードディスクに永続化することも可能
セッション情報の保存やリアルタイム分析、ゲームのランキング情報の取得など、高速なア クセスが必要なデータを取り扱うケースに対応
RedisとMemcachedが存在
Memorystore for Redis
フルマネージドなサービスで障害検出やフェイルオーバーなどに対応
標準階層と基本階層の２種類がある
標準階層
複数ゾーンでレプリケーション
障害検出時は自動でフェイルオーバー
基本階層
レプリケーションなし
容量スケーリング
最大300GBまでスケール可能
Memorystore for Memcached
インスタンスのサイジングを手動で指定して作成
スケーリング
ノード数の増減で水平スケーリングが可能
垂直スケーリングは、インスタンスを再作成が必要
接続先
Compute Engine、GKE、Cloud Functions、App Engine
Cloud Runからの接続が未サポート
Bare Metal Solution
RDBを稼働させるためのハードウェア
特殊ワークロードで利用する。低レイテンシでGoogle Cloudのサービスと統合しアクセ ス可能。
Oracle Databaseなどを導入可能なベアメタルサーバーを提供
◆ネットワーキング
VPC
VPC配下に複数リージョンを持たせることが可能
リージョンはデータセンターの単位
リージョンにはゾーンと呼ばれる複数のエリアが存在
内部IP
仮想マシンやコンテナを起動すると、VPCのサブネットからIPが自動的に割り当てられる
また内部IPは固定的な割り当ても可能
同じVPC内のリソースは、異なるサブネット間でもルーティング設定なしに通信可能
異なるVPC間では、VPCのピアリングやCloud VPNを使用
デフォルトVPC
プロジェクトを作成すると自動的にdefaultという名前でVPCが作成
これはあらかじめ各リージョンにサブネットが用意される
あくまで一時的にリソースを試す用途で、本番環境では手動でVPCを作成することを推奨
自動でIP割り当てが変わるなどの意図しない挙動があるため
サブネット
リージョンリソースであり、必ず１つだけのリージョンに所属
サブネットは複数のゾーンにまたがることが可能
VPC作成時のモード
自動モード
各リージョンのサブネットが自動で作成される
この場合、各サブネットには
10.128.0.0/9のCIDRブロック内に収まるIP範囲が割り当てられる
カスタムモード
ユーザーがサブネットの範囲を決定する
オンプレやVPC間を接続する場合はアドレス重複がないようカスタムが良い
本番ではこちらが推奨
一度カスタムとすると、自動には変更不可
ファイアウォール
ユーザが定義したファイアウォールルールを利用
プロトコルや送信元を設定してアクセスを制御
またGoogle Cloudでは、外部IPのポート25(SMTP)を宛先とする通信は許可できない
セキュリティ上不正使用のリスクがあるため
ルールにはソースタグやサービスアカウントなどを送信先に設定したものを作成可能
ルールには優先度が設定可能
許可ルールと拒否ルールがあり、拒否の優先度が低い場合は許可されるなど
ルールは上り下りどちらかを指定が必要
ターゲットタグを指定すれば、特定のネットワークタグを持つ仮想マシンにそのルールを紐づけ可能
app向けのファイアウォール、db向けのファイアウォールなど
firewall-rules-logging
ルールごとに有効化可能。接続が記録され、Cloud Loggingで確認が可能。
デフォルトファイアウォール
デフォルトVPCに存在するファイアウォールルール
TCP22などが広く許可されるルール（優先度低）が設定されているため注意
VPCピアリング
２つのVPCを内部IPで接続する方式
片方のVPCで設定しても動作しないため、もう一方もピアリング設定が必要
加えて、お互いの内部IPからのアクセスをファイアウォールで許可する必要あり
共有VPC
ホストプロジェクトとサービスプロジェクトから構成される形式
ホストプロジェクトに共有VPCを設置し、そのVPCにサービスプロジェクトを参加させる
複数のプロジェクトで共通のVPCを共有するために使用
あくまでプロジェクト間で、組織間などの場合はVPCピアリングなどが必要
ルーティング
相手先にデータを届けるための宛先情報を経路情報と呼ぶ
Google Cloudでは静的ルーティングを使用しない限り、直接設定はしないことが多い
VPCとサブネットを作成すると以下のルートが自動で登録される
デフォルトルート：VPCからインターネットへ接続するインタネットゲートウェイへの経路情報
サブネットルート：サブネット同士で通信するための経路情報
動的ルーティング
Cloud VPNやCloud Interconnectでオンプレミスと接続した際、経路情報を動的に交換する
VPCに構成のお変更があった場合も自動的に交換される
静的ルーティング
変更の多くないネットワークで利用
Cloud NAT
外部IPを持たせないプライベートなネットワークを、ソフトウェア更新などのために外向きの接続だけ許可したい場合に使用
NATとは、プライベートIPをパブリックIPに変換する技術
SLAは99.9%の可用性を持ち、利用状況に応じて自動でスケーリング可能
Cloud Load Balancing
世界規模の負荷分散を行えるサービス
地理的に近いリージョンへリクエストを分散
Compute EngineやGKEで稼働するアプリケーションの全面で負荷分散を実施
Cloud Storageのバケットについても負荷分散が可能
複数のリージョン、ゾーンにまたがった負荷分散に対応
プレウォーミングが不要で、ゼロからフル稼働状態まで数秒でスケーリングが可能
ロードバランサの種類
内部：Google Cloud内での負荷分散。内部の場合グローバル分散しない。
HTTP(S)ロードバランサ
内部IPを使用して特定のリージョン内でアクセスが可能なレイヤ７のバランサ
TCP UDPロードバランサ
内部IPを使用してTCPまたはUDPを負荷分散するバランサ。ストリーミングやネイティブアプリで、低レイヤのプロトコルが必要な場合に使用。
外部：インターネットからのトラフィックを負荷分散
HTTP(S)ロードバランサ
外部IPを使用して、複数のリージョンに負荷分散するバランサ。クライアントから近いリージョンにアクセスを振り分ける。プロキシ機能がある。
SSLプロキシロードバランサまたはTCPプロキシロードバランサ
トラフィックをバランサで終端し、複数リージョンをまたいだトラフィック分散をするバランサ
プレミアムの場合、グローバル分散が可能
TCP/UDPロードバランサ
外部IPを使用してTCPまたはUDPを負荷分散するバランサ。同じリージョン内での負荷分散を実施し、グローバル分散しない。
プロキシ機能がないため、クライアントからのリクエストがそのまま背後に送信されるパススルー。
HTTPによるアクセスも可能だが、SSL証明書の認証などの機能は提供されないため注意
HTTP(S)ロードバランサ（リージョン内）
スタンダードティアの場合はグローバル分散が使用できず、こちらとなる。
URL maps
ユーザーによって指定されたURLに応じて、リクエストは異なるバックエンドサービスにルーティングする際に設定する
Cloud CDN
画像やHTMLなどの静的コンテンツをキャッシュするためのサービス
外部HTTP(S)負荷分散のバランサを設定しオリジンを構成すればすぐに使用可能
オリジンには以下などが使用可能
インスタンスグループ？
Cloud Storage
ネットワークエンドポイントグループ？
アクセス解析をしたい場合は、ロードバランサ側のログを参照する必要がある
ロードバランサ側にはCloud CDNへのアクセスも含む
キャッシュモード
「静的コンテンツをキャッシュする」
デフォルトの設定
private やno-store、no-cacheといったディレクティブで明示的にキャッシュを拒否するコンテンツをのぞき、すべてをキャッシュする。
TTLの設定のみで使用可能で、送信元の対応は不要
「Cache-Control ヘッダーに基づいて送信元の設定を使用する」
オリジンサーバーで設定した、Cache-Controlヘッダーに基づいてキャッシュする
送信元でヘッダの設定が必要
「すべてのコンテンツを強制的にキャッシュする」
ディレクティブを無視してすべてキャッシュする
Cloud DNS
IPアドレスとドメイン（URL）を紐づける仕組み
Cloud DNSの権威ネームサーバーは100%の可用性を保証
Cloud DNSは数百万のレコードを登録可能
大量のクエリ処理を行うために、自動でスケーリング
説明が簡単なので補足した方がいいかも
Cloud Armor
アプリケーションとWebサイトを保護するサービス
◆ハイブリッド・マルチクラウド
Cloud Interconnect
オンプレとGoogle Cloudを接続するサービス
2つの提供形態がある
Dedicated Interconnect
自社のデータセンターとGoogle Cloudを直接接続
高速にデータ転送を行いたい場合に利用
Partner Interconnect
自社のデータセンターとGoogle Cloudをパートナーのネットワーク経由で接続
Cloud VPN
IPsec-VPNによるサイト間接続が可能なサービス
IPsecの設定のみで暗号化された通信路でGoogle Cloudをオンプレやその他のクラウドと接続可能
Anthos
オンプレミスや他のパブリッククラウドにGKEという統一されたプラットフォームを構築可能なサービス
ハイブリッドクラウドやマルチクラウドを実現を容易化
以下のようなサービスに分岐する
オンプレミス：Anthos clusters on VMware
Google Cloud：GKE
AWS：Anthos clusters on AWS
◆セキュリティ
Cloud IAP（Cloud Identity-Aware Proxy）
Google Cloudが提供するフルマネージドのリバースプロキシ
IAPを経由してVPCにある各種リソース（Compute Engineなど）にアクセス可能
参考
踏み台サーバはもういらない。IAP(Identity-Aware Proxy)の便利な使い方
VPC Service Controls（VPC-SC）
セキュリティ境界を設置することで、プロジェクト内サービスへのアクセスや、インターネットを含むプロジェクト外とのやり取りを制限するサービス
ファイアウォールルールによる保護では、パスワードの認証情報漏洩などによる機密データのアクセスなどに対応できない
認証情報に加えて、アクセス元の情報を使用することでさらにセキュアな環境とすることが可能
Cloud Identity
ユーザーがシングル サインオンでアプリに簡単にアクセスできるようにする
多要素認証でユーザーと企業データを保護する
エンドポイント管理による個人や会社のデバイスへのポリシーの適用
ドメインをCloud Idnetityで使用する場合、そのドメインの所有権を証明する必要がある
手順としてはCloud Identity から提供される確認レコードをドメインの DNS 設定に追加する
◆ストレージ
Cloud Storage
保存容量に制限のないストレージサービス
99.999999999%（イレブンナイン）の耐久性、99.0～99.5%の可用性
静的ファイルホスティングやログの長期保存など様々な用途で使用可能
データ暗号化
データはすべて永続化される前に暗号化される（何かの設定は必要ない）
顧客が管理する暗号化鍵を設定することは可能
TLS暗号化
アップロード、ダウンロードの際にネットワーク経路がTLSで暗号化
低レイテンシ
ストレージクラスによってレスポンスが急激に低下するなどは発生しない
アクセス方法
Googole Cloudコンソール、REST API、gsutilコマンド
各言語に対応したクライアントライブラリ
ストレージクラスが異なっても同じ方法でアクセス可能
料金
ストレージ料金：格納されるデータ量で決定される料金
オペレーション料金：オブジェクトのダウンロード回数などで決定。無料の操作もある。
ネットワーク料金：読み取ったデータ量、バケット間で移動したデータ量で決定（外部からGoogle Storageへの送信は無料
gsutilコマンド
多くのサービスはgcloudコマンドを使用するのに対して、Cloud Storageはgsutilを使用するため要注意
コマンド例
ストレージクラスを変更する
gsutil rewrite -s nearline gs://free-photos-gcp
オブジェクトを公開する
gsutil iam ch allUsers:objectViewer gs://free-photos-on-gcp
オブジェクトの作成時間やコンテンツタイプなどのメタデータを取得する
gsutil stat gs://BUCKET_NAME/OBJECT_NAME
ストレージクラス
種類
Standard：高可用性が求められるデータ
Nearline：最小保持期間が30日のため、30日以上保持が必要で、月に１回程度のアクセス用途
Coldline：最小保持期間が90日のため、90日以上保持が必要で、数か月に１回程度のアクセス用途
Archive：法令規制に関するアーカイブなど、少なくとも365日間保存する必要があるデータ用途。オペレーション料金は他のクラスと比較して高価
Standard以外は、最小保持期間が存在（その前に削除しても最小保持期間分の課金）
オブジェクトのストレージクラスの変更はコンソール上では不可だが、gsutilなどでは可能
ストレージクラスはバケットで指定されたものがオブジェクトに適用されるが、オブジェクトのストレージクラスを後から変更可能
冗長化
リージョナル：
例えばデータを分析するようなユースケースには、パフォーマンス上の理由から、ストレージ資産は処理が行われる場所の近くに置きたいので、Regionalが理にかなっています。
マルチリージョン：
決められた地域内のデータセンターのうちいくつかに配置
例：ASIA、EU、US
デュアルリージョン：
特定の２つのリージョンで冗長化
配置するリージョンを把握することが可能
例：asia1(asia-northeast1とasia-northeast2)、eur4(europe-north1とeurope-west5)、nam4(us-central1とus-east1)
バケットとオブジェクト
バケットが格納する入れ物で格納されたデータをオブジェクトと呼ぶ
１つのオブジェクトの最大サイズは5TB
保存できるオブジェクト数には上限なし
バケット名は小文字、数字、ダッシュ、アンダースコア、ドット
先頭と末尾は記号使用不可
長さな3～63文字
先頭にgoogは使用できず、googleやそれに類似する表記が不可
バケットロック
データを保護機能としてオブジェクトの変更を制限可能
アクセス管理
IAMを使用して柔軟なアクセス管理が可能
IAMとACL(Access Control Lists)による「きめ細かい管理」を使用すると、個々のバケットやオブジェクトに対してアクセス制御が可能
ACLはAmazon S3とお互いにやり取りできることを目的に設計
均一なアクセス制御の方が管理や設定ミスが低くなるため推奨
Cloud Storage のアクセス制御のために事前定義されたIAMのロールがある
アップロード、ダウンロード
アップロード操作
単一リクエストのアップロード：通常のアップロード
マルチパートアップロード：Amazon S3と互換性のあるアップロード。REST APIのみで可能
再開可能なアップロード：信頼性の高い転送方法で、ファイルサイズが大きい場合に使用
並列複合アップロード：１ファイルを最大３２チャンクに分割し、これらを並列してアップロード。gsutilのみで使用可能
ストリーミングアップロード：圧縮転送する場合など、アップロード開始時に最終的なサイズがわからない場合に使用
ダウンロード操作
シンプルダウンロード：通常のダウンロード
ストリーミングダウンロード：プロセスにダウンロードする
スライス化されたダウンロード：チャンクに分割し、平行でダウンロード。gsutilのみで可能
認証によるWebブラウザでのダウンロード：Googleアカウントで認証してダウンロードする。コンソールのみで可能。
gsutilを使用すると複数のオブジェクトをアップロードまたはダウンロードする際に、並列処理で転送が可能
バージョニング
履歴を保持する機能でバケットに対して設定可能（オブジェクトで個別設定できない）
バージョニングすると、各世代分の料金が必要
ライフサイクル管理
バケットに対するアクションを定期実行や日付指定で実行する機能で、バケットに対して設定可能（オブジェクトで個別設定できない）
ユースケース
アップロードから90日以上経過したプロジェクトをColdline Storageに変更
特定の日付より前のオブジェクトを削除
バージョニングが有効な場合、３世代分のみを保持する
アクションはDeleteとSetStorageClassの２つ
指定したすべての条件を満たしたときにアクションが実行される
SetStorageClassは、より保存期間の長い方向にしか変更できない
Filestore
Filestore は、アプリケーションに低レイテンシのストレージ オペレーションを提供
ハイ パフォーマンス コンピューティング、データ分析、その他のメタデータ量の多いアプリケーションなど、レイテンシの影響を受けやすいワークロードに対して、Filestore は最大 100 TB の容量と、25 GB/秒、920K IOPS のスループットをサポート
Filestore で GKE ワークロードをサポートする
バックアップとスナップショット
ファイル共有のデータとメタデータをバックアップしたり、定期的なバックアップ スケジュールを設定したり、必要なときにいつでもインスタンスのスナップショットを作成
データを復元する場合は、10 分以内に以前のスナップショット リカバリ ポイントからデータの一部またはすべてを復元
◆API管理
Apigee API Platform
APIの管理や開発、セキュリティのためのプラットフォーム
APIGWと比較し、マネタイズ（課金の仕組み）やユーザの階層（ゴールドユーザ、ノーマルユーザ）なども提供するフル機能なサービス
API Gateway
フルマネージドなAPIゲートウェイ
Autho0認証などを使用することも可能
【初心者向け】Google Cloud API Gatewayを使って、認証付きWeb APIを作成してみた
Cloud Endpoints
APIデプロイと開発管理のためのサービス
◆開発ツール
Artifact Registry
コンテナイメージや言語パッケージの保存管理が可能
Container Registryの後継サービス
コマンド例
コンテナイメージのメタデータ一覧を見る
gcloud container images list
Cloud Build
CI/CDのためのビルド環境
コンテナのビルドも可能
ほかのGoogle Cloud サービスを利用する際に、自動的にCloud Build が使わ れるケースもある
たとえば、App Engine にデプロイする際は、自動でCloud Build が起動
このように自動的に使われるケースでも、コンソールから実行状況を確認
ソースリポジトリが必要でGitHubやBitbucket、Cloud Source Repositorieと連携可能
ソースリポジトリにpush すると、自動的にCI/CD の処理が行われるといっ た自動化も可能
トリガーの例
指定したソースリポジトリのブランチへpush する
指定したソースリポジトリに新しいタグをpush する
指定したソースリポジトリにpull リクエストを作成する
手動実行
マシンタイプを指定可能で、料金がそれに応じて変わる
Google Cloudコンソール
Google Cloudを操作するためのWebコンソール画面
Cloud Shell
Webブラウザ上で動作するシェル環境
Cloud Shellは、コマンドの実行とスクリプトによる自動化を可能にするコンテナ化されたコマンドラインインターフェイスを提供します。
Cloud Shellは、クラウドベースのCLI環境を提供します
組み込み済みのSQLクライアントでアクセスするコマンド
gcloud sql connect {INSTANCE-ID} --user=root
Cloud SDK
Cloud SDKは、ローカルCLI環境を提供します。
◆運用（Operations suite）
Cloud Logging
アプリケーションのログなどを収集し、監査などを可能にするプラットフォーム
ログを集約し、リアルタイムでのログの管理や分析を実施可能
ログ集約には以下の方法がある
マネージドサービス（GKE など）から自動的に送信
仮想マシンやサーバーにLogging エージェントを導入
アプリケーションにLogging 用のSDK を導入
エージェントについて
google-fluentdというfluentdが元になったエージェントが使用
ログエクスプローラ
集約されたログに対してクエリ（フィルタ）を実行可能
ログベースの指標
集約されたログをもとに指標を集計・通知を行うための指標を管理する機能
例
特定の文字列を含むエラーログの出現頻度
レスポンスタイムのヒートマップを作成
ログルーター
Cloud Logging API に送信されたログに対し、保存や破棄、宛先の指定といったルールが設定可能
宛先として設定できる宛先
Cloud Loggingバケット
削除できないバケットで、_Requiredは400日、_Defaultは30日保存期間がある
BigQueryデータセット
Cloud Storageバケット
Cloud Pub/Subトピック
たとえば後続にDataflow→BigQueryとすることで前処理されたログを分析など
Splunk
別のGoogle Cloudプロジェクト
Cloud Audit Logs
以下４つのログを保持
管理者アクティビティログ
データアクセスログ
システムイベントログ
ポリシー拒否監査ログ
Error Reporting
Cloud Loggingで集約されたログをもとに、エラー発生件数の確認、対応状況の管理などが行える機能
Cloud Monitoring
豊富なメトリクスでインフラの監視を行うサービス
予算アラートを受信する電子メール受信者を定義するために、最大5つのCloud Monitoringチャネルを設定することができます。
アラートの通知先
メールやチャットツールをはじめとする複数のサービス選択可能
また、通知先にwebhookも指定可能
マネージドではないサーバーにエージェントを導入することで、指標をCloud Monitoringに集約可能
たとえば、Compute Engineインスタンスの場合、Monitoring API経由である程度の指標を収集できるが、エージェントをインストールすると、より詳細な情報を収集
エージェント無し
CPU使用率、ネットワーク送受信量、ディスクIO
エージェントあり
上記に加え、ロードアベレージ、TCP接続数、ディスク使用率、メモリ使用率
collectdをベースとしたstackdriver-agentが使用
Cloud Monitoring Dashboards
Cloud Monitoring Service Monitoring API
Cloud Trace
分散システムにおけるパフォーマンスを把握するために使用
リクエストごとに詳細なレイテンシ情報を分析する、またはアプリケーション全体のレイテンシを確認することができます。
Cloud Run、Cloud Functions、App Engineは自動的に測定され、それ以外はライブラリを用いて最小限の設定を行います。
Cloud Profiler
統計を目的として本番環境アプリケーションから CPU 使用率とメモリ割り当てに関する情報を継続的に収集する、オーバーヘッドの少ないプロファイラ
Cloud Debugger
実行中のアプリを停止したり遅らせたりすることなく、任意のコードの場所でアプリケーションの状態を検査できる
テスト、開発、本番など、アプリケーションのあらゆるデプロイで使用できます。
2023年6月以降に非推奨となる予定
◆マイグレーション
Database Migration Service
オンプレのMySQLなどからCloud SQLに移行するためのサービス
Cloud Foundation Toolkit
Deployment Manager 用と Terraform 用の参照テンプレートが用意され、これらを使用してGoogle Cloud で繰り返し使用できるエンタープライズ向けの基盤を迅速に構築可能
Transfer Appliance
データセンターや現場から Google Cloud にペタバイト規模のデータを転送するサービス
業界固有の規制（ISO、SOC、PCI、HIPAA）を遵守可能
◆データ分析
BigQuery
サーバー管理が不要なスケーラビリティと費用対効果に優れたDWH
ペタバイト規模のデータに対して高速なクエリを実行可能
BigQueryは、Google Cloudによる最新のデータウェアハウスの実装である。過去のデータを分析し、SQLクエリエンジンを使用する。
BigQueryは、時間ベースの履歴データのクエリに最適化されたデータウェアハウス製品です。BigQueryは、独自のカラムベースのストア内のデータに対してクエリを実行したり、他のデータサービスやファイルストアからのデータに対して連携クエリを実行したりすることができます。
スケーラビリティ
ストレージ容量が無制限かつ自動でスケールアウト可能
可用性
SLAで1カ月あたり99.99%の稼働時間が保証
セキュリティ
インフラとして必要なセキュリティ対策が実施
アクセス制御を含む、ユーザーがデータ保護を実現するために必要な機能が提供
クエリ構文の種類
標準SQL とレガシーSQL という2 種類のSQLが存在
レガシーSQLは標準SQLがサポートされる前に使用され、独自の構文
料金
ストレージ料金と、オペレーション料金の合計
BigQueryの用語
プロジェクト
Google Cloudプロジェクトのこと。データセット、テーブル、ジョブはプロジェクトに紐づく
データセット
テーブルやビューの集合
テーブル
データを格納した行と列の集合。各列のスキーマ情報を持つ
ジョブ
クエリやインポート、エクスポート、データのコピーといった処理単位
アクセス方法
Google Cloudコンソール、bqコマンド（BigQuery専用のCLI）、クライアントライブラリからアクセス可能
一般公開データセット
Google Cloud Marketplaceに多数のカテゴリやジャンルのデータセットが一般公開されている
BigQueryのコスト抑制方法
パーティション指定
ある特定のパーティション対象の列があれば、その列をWHERE句に指定することで、一部のテーブルのみを参照する形でコストを抑制できる
パーティションの指定を必須にする
require_partitioning_filter の使用で、パーティション指定のないクエリを実行しないように制約することが可能
カラム指定を必要最低限とする
列指向であるため、カラムを指定した分だけデータを参照するので、最低限の指定にとどめる
キャッシュを有効化
キャッシュにより同じクエリであれば料金が発生しなくなる。
ただし、キャッシュから２４時間経過している、テーブルに更新がある場合などはキャッシュは削除される
ドライランでのチェック
ドライランを実行すると、クエリを実行した場合の課金バイト数やクエリのパフォーマンスを確認可能
実際にコマンドには
--dry-runを付与する
Dataproc
SparkやHadoopクラスタを実行するためのサービス
クラスタが常時稼働するため、費用対効果の高いサービスの場合は選択しない
どちらかというとバッチ処理のためのサービス
Cloud Data Fusion
データパイプラインの構築と管理を行うための統合環境
ETL処理はDataprocにより実施
Dataflow
ストリーム・バッチ処理を行うためデータパイプライン実行のためのマネージドサービス
入力データをフィルタ、加工して、指定のサービスに出力可能
ストリーム処理は、Cloud Pub/Subと組み合わせて実現（Pub/Subからデータを取得）
Amazon S3に配置されたログデータなども収集可能
Cloud Dataprep
データクレンジングのサービスでETLツールの一種
GUI操作でデータの探索や変換、異常値の検出が可能
Trifacta のGUI ツールとDataflow を組み合わせたもので、裏ではDataflowが稼働
アナリティクスや機械学習用のデータを準備するために使用
Cloud Pub/Sub
イベント取り込みと配信を行うための非同期なメッセージングサービス
ストリーミング分析パイプラインを構築する際のデータの受け口として利用
送信側は受信側を意識することなく処理を行えるため、受信側のシステム変更や障害に強い
そのため、マイクロサービスのアプリケーション同士の連携にも使用可能
Publisher、Subscriberには、Google Cloudサービス以外にIoT機器やオンプレシステムも使用可能
複数サーバーに大量のタスクを効率的に、スケーラブルに割り当てるアーキテクチャにも使用
ack-deadline
subscriberのackが無い場合、そのsubscriberには再度配信する。その待ち時間の設定値
Data Catalog
データの探索と管理を行うためのメタデータソリューション
Dataplexに現在は吸収されている
Cloud Composer
Apache Airflowで構築されたワークフローのマネージドサービス
Pythonでコードを記述することで、バッチのジョブを管理
Data Studio（Googleデータポータル）
ダッシュボード作成のためのサービス
リソースは不要で無料で使用可能
Google Workspaceをグループウェアとしている場合、レポートの共有も可能
データソースとの接続
データコネクタを選択してデータソースを作成
データソースではフィルタリング、クレンジング、クエリ抽出を担当
その後、レポートとデータソースを接続
データ
BigQueryやCloud Storage、Cloud Spanner、Cloud SQL、Google Analytics、Google スプレッドシートなどが利用可能
他のパブリッククラウドやオンプレのデータも扱うことが可能
複数のデータソースも統合可能
BigQuery BI Engine
レポートで参照しているBigQUeryが更新されると自動でキャッシュを生成する
Looker
データ分析からデータ活用までをつなげる高機能なデータモデリングのサービス
BI ツールとしての用途だけでなく、可読性の高いモデリング言語であるLookMLを使用
接続するデータソースによって異なるSQL仕様を吸収
LookMLのコードをGitHubで管理すれば、組織・部門で異なっていた指標を一元管理可能
◆AI・機械学習
Vertex AI
データサイエンスと機械学習に必要なサービスが備わったマネージドプラットフォーム
統一されたAPI、クライアント、ライブラリ、UIにAutoMLとAI Platformを統合
デプロイだけでなく前処理やモデル構築などのワークフローを作成可能
Vertex AI Workbench
Jupyter Labのマネージドサービス
AutoML
モデルの開発とトレーニングを自動化したサービス
AutoML Tables
構造化データを対象としたサービス
Vision AI
画像分類や認識のサービス
Video AI
動画の分類や認識のサービス
Cloud Natural Language API
非構造化テキストデータの分析サービス
Cloud Translation API
翻訳サービス
Text-to-Speech
音声合成サービス
Speech-to-Text
音声認識サービス
Dialogflow
会話アプリケーション開発のためのサービス群
Cloud Inference API
Recommendations AI
レコメンデーションのサービス
Cloud GPUs
機械学習向けのGPUインフラサービス
Cloud TPU
機械学習向けのTPUインフラサービス
Last updated