Google Cloud でアプリケーションを動かす 頼兼 孝幸 Google Cloud Japan Application Modernization Specialist

1. Google Cloud でアプリケーションを動かす
頼兼 孝幸
Google Cloud Japan
Application Modernization Specialist

2. 自己紹介
Google Cloud
アプリケーション モダナイゼーション スペシャリスト
担当プロダクト エリア:
● Anthos
● GKE
● サーバーレス（App Engine、Cloud Run、Cloud Functions など）
● CI / CD
生まれも育ちも広島ですが、広島を出て 20 年以上になります…
頼兼 孝幸

3. Compute プロダクト
DB プロダクト
運用していく上での考慮点
まとめ
01
02
03
04
アジェンダ

4. Compute
プロダクト
01

5. Compute プロダクト一覧
● Google Cloud では計 5 つの Compute プロダクトを用意している
Compute Engine
Google
Kubernetes Engine
Cloud Run App Engine Cloud Functions
仮想マシン
フルマネージド
Kubernetes
サーバーレス
コンテナ実行環境
サーバーレス
アプリケーション
実行環境
サーバーレス
Functions as a Service

6. Compute プロダクト一覧
● 抽象度と柔軟性のトレードオフ
Compute Engine
Google
Kubernetes Engine
Cloud Run App Engine Cloud Functions
抽象度
柔軟性

7. Compute Engine
仮想マシン
● 柔軟なスペックの選択が可能
○ 高速な vCPU : 〜 112, メモリ: 〜 12 TB
○ ローカル SSD、GPU の利用
● 複数の OS を選択可能
○ 各種 Linux ディストリビューションから Windows Server まで

8. Compute Engine
特長
● ライブ マイグレーション
● カスタム マシンタイプ
(CPU, メモリの柔軟な選択)
● インスタンス グループ
● 秒単位での課金
インスタンス
グループ
インスタンス
グループ
インスタンス
グループ
CPU
メモリ

9. Compute Engine
ユースケース
● サードパーティ アプリケーションの実行
（Marketplace からも実行可能）
● 物理マシン、仮想マシン で稼働する
アプリケーションの移行

10. Google Kubernetes Engine（GKE）
フルマネージドなKubernetes サービス
● ユースケースに合わせた 2 つの運用モード
○ スタンダード：ノード設定の 柔軟性
○ Autopilot：完全マネージドな利用体験
● Kubernetes のエコシステムを活用

11. Kubernetes とは？
プロダクショングレードの
コンテナ オーケストレーションシステム
● コンテナ オーケストレーション
ツールのデファクト スタンダード
● オープンソース
● スケジューリング、自動ヒーリング、
自動スケーリング
● 高い拡張性
お客様構築、管理
API
Server
kubectl
User
Storage
Scheduler
Resource
Controllers
User Pod
Containers
Nodes
Control plane
Kubernetes Cluster
User Pod
Containers
User Pod
Containers
User Pod
Containers

12. Google Kubernetes Engine（GKE）
特長
● セキュリティとコンプライアンス
○ HIPAA と PCI DSS に準拠
● 自動でスケーリング、
アップグレード、ノードを修復
● ハイブリッドとマルチクラウド をサポート
kubectl
User
Nodes Google Cloud
サービス
Control plane
GKE cluster
GKE が構築、Google、お客様で管理
Google 管理
Google Cloud サービス
API
Server
Storage
Scheduler
Resource
Controllers
User Pod
Containers
User Pod
Containers
User Pod
Containers
User Pod
Containers
Vi ual
Private Cloud
Persistent
Disk
Cloud Load
Balancing
Operations

13. GKE - Autopilot モード
特長
● Control plane に加え Node も Google マネージドに
● 本番ワークロードに適した
ベストプラクティスが適用済み
○ セキュリティ
○ ワークロード
○ ネットワーク設定など
● Workload（Pod）ドリブンな世界へ
○ Pod 単位での課金、Pod への SLA
Nodes Google Cloud
サービス
Control plane
Autopilot cluster
Google 管理
Google Cloud サービス
Vi ual
Private Cloud
Persistent
Disk
Cloud Load
Balancing
Operations
kubectl
User
API
Server
Storage
Scheduler
Resource
Controllers
User Pod
Containers
User Pod
Containers
User Pod
Containers
User Pod
Containers

14. Google Kubernetes Engine（GKE）
スタンダード：おすすめユースケース
● ノードの設定変更が必要なゲームバックエンド
● GPU, TPU を使う ML パイプライン
Autopilot：おすすめユースケース
● スケーラブルな負荷テストツール用環境
● 必要リソースに変動の少ない Static なシステム
GKE のユースケース
● マイクロサービス アーキテクチャにおける 大規模 Web アプリケーション
● データ処理基盤

15. Cloud Run
コンテナ + サーバーレス
● 100 ミリ秒単位での課金。最大 4 vCPU（Preview で 8 vCPU も可）、
16 GiB RAM（Preview で 32 GiB も可）の利用
● オープンソースの Knative と API 互換になっていることによる移植の容易性
● ユースケースに合わせた 2 つの選択肢
○ Cloud Run：フルマネージド
○ Cloud Run for Anthos：柔軟性、ハイブリッドクラウド
※ ここからの Cloud Run については、フルマネージド版をベースに説明を進めます

16. Cloud Run（フルマネージド）
特長
● コンテナをデプロイするだけで 外部
から到達可能な URL が発行される
● 0 〜 N へトラフィックに応じて
高速にスケーリング
● イベント駆動で処理を実行
● HTTP/2, WebSocket, gRPC への対応
● 高度なトラフィック管理 が統合
第 2 世代の実行環境Preview
● CPU, ネットワークパフォーマンス向上
● すべてのシステムコールなど Linux との完全互換性
● ネットワーク ファイルシステムのサポート
Cloud Run Jobs Preview
● HTTP リクエストに依らない実行
● 分散タスクの実行で、より長時間の実行が可能
● 明示的な並列処理や、リトライ回数を定義

17. Cloud Run（フルマネージド）
ユースケース
● ステートレスなバックエンド
● サーバーレスでマイクロサービス の構築
● 軽量なデータ変換処理
● イベント駆動処理 Cloud
Storage
データ変換
Cloud Run
BigQuery
Cloud Storage
トリガ
構造化
データ格納
gRPC API
Cloud Run
DocumentDB
Firestore
API アクセス DB 操作
CSV
ファイル

18. App Engine
アプリケーション開発に集中するための
マネージドなサーバーレスプラットフォーム
● インフラ管理の必要なし
● 2008 年にプレビュー版がリリースされから
提供を続けてきた信頼性、エコシステムの大きさ
● 用途に合わせた App Engine 環境の提供
2008 2015
2012 2017
2019

19. App Engine のランタイム
環境
スタンダード
第 1 世代
スタンダード
第 2 世代
フレキシブル
開発言語
Python 2.7
Java 8
PHP 5.5
Go 1.11
Python 3.7,3.8,3.9
Java 11
Node.js 10,12,14,16
PHP 7.2,7.3,7.4
Ruby 2.5,2.6,2.7
Go 1.12+
Node.js, Ruby,
Java, Python,
Go, PHP, .NET
カスタムコンテナ
イメージ
実行環境 サンドボックス
仮想マシン上の
Docker コンテナ
Google Cloud
機能の利用
GAE 専用 の API
Google Cloud の API
Google Cloud の API を利用 ※
サードパーティ
バイナリのインストール
不可 可
※ Python 3, Java 11, Go 1.12+ では第 1 世代からのマイグレーション手段の提供を
目的とし、 一部のGAE 専用の API が利用できるようになっています

20. App Engine（スタンダード環境 第 2 世代）
特長
● トラフィック分割
● アプリケーション バージョニング
● トラフィックに合わせた
高速なスケーリング
Version 1 Version 2
80 % 20 %

21. App Engine（スタンダード環境 第 2 世代）
ユースケース
● スパイク特性のある Web アプリケーション
● 静的、動的コンテンツ を利用する
Web アプリケーション
● モバイル バックエンド データ格納
Firestore
API
アクセス
DB
操作
静的コンテンツ +
API
AppEngine
Cloud Load
Balancing
Cloud CDN

22. Cloud Functions
サーバーレスFunctions as a Service
● 様々な Google Cloud のイベントとの連携
● 100 ミリ秒単位の課金
Cloud Logging
Cloud Storage
Pub/Sub
Firebase
Firestore
HTTP Request
イベント

23. Cloud Functions
特長
● オープンソースの FaaS フレームワークを
利用し、ロックインを回避
● Cloud Trace、Cloud デバッガといった
Google Cloud の開発ツールと
ネイティブに連携 Functions Framework
ローカル環境
アプリケーション コード
Cloud Functions 第 2 世代
● リクエスト処理時間が最長 60 分に
● 最大 16 GiB メモリ、4 vCPU に
（Preview で 32 GiB メモリ、8 vCPU も可）
● 最小インスタンス設定、トラフィック分割が可能に

24. Cloud Functions
ユースケース
● サードパーティ サービス、API との統合
● リアルタイム ファイル処理
Cloud
Storage
Cloud
Storage
Vision API 呼び出し
Cloud Functions
不適切画像検出
Vision API
画像ブラー処理
Cloud Functions
トリガー
開始
処理済み
画像を格納

25. ユースケースの整理
Compute
Engine GKE Cloud Run
App
Engine
Cloud
Functions
サード パーティアプリ ◎ ○ △
物理、仮想マシン移行 ◎ ○ △
Web、モバイル バックエンド
ステートレス △ ○ ◎ ◎ ○
ステートフル ○ ◎ ○
内部 API
ステートレス △ ◎ ◎ ○ △
ステートフル ○ ◎ ○
注：マークが無いところが実現不可能というわけでありません
運用負荷なども勘案し、あくまで まず◎から検討してみる という基準とお考えください

26. ユースケースの整理
● GKE か、サーバーレスプロダクトを選ぶかが大きな分岐点となる
Compute
Engine GKE Cloud Run
App
Engine
Cloud
Functions
バッチ
処理時間長、またはリソースが必要 ◎ ◎ ○ ○
軽い △ ◎ ◎ ○
ワークフロー △ ○ ◎
Google Cloud のイベントをソースに起動 △ ○ ◎

27. DB プロダクト
02

28. アプリあるところに DB あり
データベース
データ
クライアント
アプリケーション
システムで使うデータベースは何を使えば
いいのだろうか？
使いたい機能を持ったデータベースを選ぶ？
機能以外ではどんな基準で考えれば
いいのだろうか？

29. Google Cloud におけるマネージド データベースの選択肢
Cloud Bigtable
Cloud Spanner
PostgreSQL
SQL 方言のみ互換
Cloud SQL
for PostgreSQL
for MySQL
for SQL Server
BigQuery
Firestore
ネイティブモード
Datastore モード
Memorystore
for Redis
for Memcached
OSS 及び商用のマネージド DB クラウド ネイティブ DB
Datastream
Database Migration Service
データベース移行サービス サーバーレスCDC サービス
キャッシュ リレーショナルデータベース（SQL データベース） DWH
NoSQL データベース
KVS / ワイドカラム ドキュメント DB
クラウド環境用に設計された
Google Cloud 独自の DB のこと
ユーザー数や経験者も非常に多い OSS の DB や商用 DB を
マネージド サービス化
DB と一緒に使う周辺サービス
New!
AlloyDB
for PostgreSQL
（完全互換）
Preview
サーバーレス

30. アプリの裏で利用する Google Cloud のデータベース サービス
Google Cloud では、アプリの要件に合わせて使える
6 種類のマネージドDB を用意。
Cloud Bigtable
Cloud Spanner
Cloud SQL
for MySQL
for PostgreSQL
for SQL Server
Firestore
ネイティブモード
Datastore モード
Memorystore
for Redis
for Memcached
BigQuery は
データ分析系の
サービスなので
別枠です
AlloyDB
for PostgreSQL
（完全互換）
Preview
New!

31. まずは 2 種類に大分類
Cloud SQL
for MySQL
for PostgreSQL
for SQL Server
AlloyDB
for PostgreSQL
Preview
OSS / 商用のマネージド DB クラウド ネイティブ DB
Memorystore
for Redis
for Memcached
Cloud Bigtable
Cloud Spanner
Firestore
ネイティブモード
Datastore モード

32. OSS / 商用 DB をマネージド サービスとして提供
ユーザー数や経験者も非常に多い OSS や商用 DB を、
運用が簡単なマネージドサービスとして提供。
Memorystore
インメモリ データストアである Redis と Memcached を
マネージド サービスとして提供。
Cloud SQL
RDBMS である MySQL、PostgreSQL、SQL Server をマネージ
ド サービスとして提供。リードレプリカや HA 構成の構築や自動管
理、ストレージ容量の無停止自動拡張、自動バックアップなど、運
用を容易にする様々な機能を提供。
AlloyDB
RDBMS である PostgreSQL を、ストレージ層などを強化し、マ
ネージド サービスとして提供。Cloud SQL が持つ運用容易性に加
え、書き込み性能向上、低遅延のレプリケーション、可用性の向上
など、様々な強化が行われている。現在
プレビュー版として提供。
Cloud SQL
for MySQL
for PostgreSQL
for SQL Server
Memorystore
for Redis
for Memcached
キャッシュ
リレーショナルDB
AlloyDB
for PostgreSQL
Preview
Preview
リレーショナルDB
OS MySQL
VM
ロギング
監視
その他サービス
Cloud SQL for MySQL のインスタンス
マネージド サービスになってい
るだけで、中身は普通に OS の
上で動く RDBMS が動作してい
る。

33. クラウド環境に合わせて設計開発されたマネージド DB
クラウド ネイティブ DB は、クラウド上の複数ゾーンやリージョン
を活用した高可用性と、クラウドの柔軟な
リソースを活用したスケーラビリティを備えている。
アップグレードやメンテナンスも完全無停止で行われる。
Cloud Spanner
高可用性、スケーラビリティ、運用容易性、SQL のサポートなどを
備えた、フルマネージド RDBMS 。
Cloud Bigtable
NoSQL の一種であるワイド カラムストアを提供。高スループット
と低レイテンシな読み書きが可能。 Apache HBase との互換性も
あり。
Firestore
(ネイティブモード / Datastore モード)
NoSQL の一種であるドキュメント ストアをサーバーレス DB とし
て提供。Firebase との親和性が高く、モバイルアプリから直接接
続が可能であり、サーバーサイド要らずで開発を高速化。
KVS / ワイドカラム
ドキュメントDB
リレーショナルDB
Cloud
Bigtable
Cloud Spanner Firestore
ネイティブモード
Datastore モード
サーバーレス
AlloyDB は、PostgreSQL をクラウドネイティブDB として
提供した、両方の特性を持つデータベース。

34. Web / API サービスの開発において、まず検討する DB
Cloud Spanner
Cloud SQL
for PostgreSQL
for MySQL
for SQL Server
Firestore
ネイティブモード
Datastore モード
OSS のマネージド DB クラウド ネイティブ DB
リレーショナルデータベース（SQL データベース） NoSQL
ドキュメント DB
New!
AlloyDB
for PostgreSQL
（完全互換）
Preview
サーバーレス
注意）
AlloyDB は 2022 年 8 月現在はまだプレビュー期間中であり、サポート対象ではないため
AlloyDB GA 後の状況で選ぶ選択肢として今回は紹介。

35. ユースケースの整理
Cloud SQL AlloyDB Cloud Spanner Firestore
既存アプリケーションの移行（ OSS 互換性） ◎ ◎ △
リレーショナル データベースとしての利用 ◎ ◎ ◎
モバイル バックエンド、リアルタイム同期 ◎
書き込みスループットのスケーラビリティが必要 △ ○ ◎ ○
運用負荷の低減 ○ ○ ◎ ◎
注：マークが無いところが実現不可能というわけでありません
運用負荷なども勘案し、あくまで まず◎から検討してみる という基準とお考えください

36. アプリとデータベースの接続方式の違い
Cloud Spanner
Cloud Bigtable
Firestore
ユーザーアプリ
MySQL 用の
ドライバ
MySQL の通信プロトコル（ TCP/IP）
Private IP
Public IP
サービスごとに API エンドポイントがあり、アプリからは、Google
Cloud が提供している各プロダクト用のドライバを利用して、共通
の API エンドポイントに接続する。
インスタンスごとに IP アドレスが割り振られており、アプリからは、データ
ベースごとのドライバを利用して IP アドレスとポート指定で接続。OSS とし
て使う MySQL や PostgreSQL と同じ接続方式。
例）spanner.googleapis.com
Cloud Spanner の通信（gRPC ベース）
API の
エンドポイント
例）10.35.32.38 : 3306
ユーザーアプリ
Cloud Spanner 用の
ドライバ
Cloud SQL / Memorystore / AlloyDB
Cloud Spanner / Cloud Bigtable / Firestore
project id / instance id / database name
+ IAM による認証情報 🔑
接続先 IP + DB の認証情報 🔑
Private IP
Private IP
OSS / 商用のマネージド DB
クラウド ネイティブ DB
Cloud SQL
for MySQL
AlloyDB
for PostgreSQL
Memorystore
for Redis

37. アプリとデータベースの接続俯瞰図
プロジェクト
ユーザーのVPC
Compute
Engine
サーバーレス
VPC アクセス
コネクタ
Cloud Run
Memorystore の VPC AlloyDB の VPC
Cloud SQL の VPC
Memorystore AlloyDB
Cloud SQL
アプリ
アプリ
Private IP
Private IP
Private IP
Public IP
(Auth Proxy 経由)
*) PSC = Private Service Connect
クラウド ネイティブ DB
リージョンやインスタンス問わず、
API エンドポイント
から自動的にルーティングされる。
Cloud Spanner、Firestore、Cloud Bigtable は、共通のAPI エンドポイントに接続するだけなので、ア
プリケーションが稼働するサービスを意識すること無く利用しやすい。一方、既存
DB との互換性を維持
しているCloud SQL、AlloyDB、Memorystore は、IP アドレスに接続に行くため、アプリケーション側
の
ネットワークを意識して接続方式を考える必要がある。
Kubernetes
Engine
アプリ
Cloud Bigtable
Cloud Spanner
Firestore
Public
Cloud APIs の
エンドポイント
Private (PSC*)

38. 運用していく上での
考慮点
03

39. チーム構成
CCoE のような、サービスを
横断で管理するチームがいる場合
● そのチームに GKE の管理を任せることで
○ マルチテナント構成でリソースの有効利用
○ 知見の集約、他チームへの展開
○ 何より Kubernetes のエコシステムの活用
GKE cluster 1
CCoE
Service A Service B
Service C
GKE cluster 2
Service D
Service E

40. プロダクトの統一を考える
各ユースケースで最適なプロダクト選択に
固執するのではなく、それぞれのワークロードの
特性をカバーできる1 プロダクトに統一する
● クラウドでは普通にシステムを構築すると
複数のプロダクト（Compute 以外）を組み合わせることとなる
● 複数のプロダクトを利用する ＝ それぞれの Day 2 operations にも責任を持つ
○ それぞれのプロダクトは 独自にアップデートされていく

41. コストの考え方
● コストは利用料金だけではなく、潜在的なコストも含めて考える
利用料金
● プロダクトごとに異なる、コストが
かかるポイント
● リソースの考え方
● 価格付けから読み取れる適切な使い方
潜在的なコスト
● Day 2 operations で発生するコスト
● プロダクトの学習コスト
● 将来、他のテクノロジーに移行するコスト
● エキスパートを採用するコスト

42. まとめ
04

43. 再掲：Compute プロダクトのユースケースの整理
Compute
Engine GKE Cloud Run
App
Engine
Cloud
Functions
サード パーティアプリ ◎ ○ △
物理、仮想マシン移行 ◎ ○ △
Web、モバイル バックエンド
ステートレス △ ○ ◎ ◎ ○
ステートフル ○ ◎ ○
内部 API
ステートレス △ ◎ ◎ ○ △
ステートフル ○ ◎ ○
注：マークが無いところが実現不可能というわけでありません
運用負荷なども勘案し、あくまで まず◎から検討してみる という基準とお考えください

44. 再掲：Compute プロダクトのユースケース
Compute
Engine GKE Cloud Run
App
Engine
Cloud
Functions
バッチ
処理時間長、またはリソースが必要 ◎ ◎ ○ ○
軽い △ ◎ ○ ○
ワークフロー △ ○ ◎
Google Cloud のイベントをソースに起動 △ ○ ◎

45. AlloyDB
for PostgreSQL
Preview
4 種の DB から検討し、必要に応じて特化型の DB を利用
Cloud Bigtable
Cloud Spanner
PostgreSQL
SQL 方言のみ互換
Cloud SQL
for PostgreSQL
for MySQL
for SQL Server
BigQuery
Firestore
ネイティブモード
Datastore モード
Memorystore
for Redis
for Memcached
OSS 及び商用のマネージド DB クラウド ネイティブ DB（可用性 99.99% 以上を実現可）
キャッシュ リレーショナルデータベース（SQL データベース） DWH
NoSQL データベース
KVS / ワイドカラム ドキュメント DB
（GA 後に選択肢に）
サーバーレス
特定用途に特化
まずはこれらのDB で要件を満たせるかを検討する。
内製化向き
特定用途に特化
特定用途に特化
内製化向き
Cloud Run + Firestore
(Datastore モード) は、
サーバーレスの恩恵を最
大限活用できる、運用いら
ずの組み合わせ。
分析 DB、分析プラットフォー
ムとして使うなら、間違いなく
これ。
機械学習モデルの学習基盤
などにも最適。
Firebase 連携するなら、
Firestore ネイティブモード
高スループットと
低レイテンシが、同時に
必要な場合の選択肢。
大量の IoT センサーデータ
の処理や、機械学習での
レコメンデーションに利用す
る大量データなどを、
リアルタイムに読み書きする
といったユースケースなどに
適している。
99.95%
別途メンテナンスあり
99.99%
メンテナンス含む SLA
99.99 ~ 99.999%
メンテナンスによる
停止時間などは一切なし
書き込み含めた自在なスケーラビリティが必要なら Cloud Spanner。
提供されているインスタンス サイズで足りる性能でよければ、 Cloud SQL ま
たは AlloyDB (GA 後)を選択するのがよい。
可用性
性能と拡張性
フロントにキャッシュが必要
なときには検討

46. まとめ
プロダクトの
向き不向き
コ
ス
ト
チ
ー
ム
体
制
● それぞれのプロダクトは実現モデルが
わかりやすく分かれています
● チーム体制もあわせて
どのプロダクトを選ぶか検討しましょう
● 使い分けも大事ですが、 あえて 1 つのプロダクトに
寄せようとしてみるのも良いかもしれません

47. Thank you.