2024/05/25 serverless Meetup osaka

1. サーバレスを考える前に
アプリケーションはどこで動かすべきか？
2024//05/24
アイレット株式会社
カスタマー支援事業部
TAMグループ/グループリーダー
檜垣慶太

2. Who AM I
2
Name ：Keita Higaki (X : @keitah0322 がっきー）
Belong ：Iret,Inc
Division ：Customers Support Division
Role ：Technical Account Manager
Group Leader
Prize ：2023 Japan AWS Top Engineers
：Google Partner Top Engineer 2024
Specialty ：Serverless Architechture
Iret Technical Ambassador 2024
Momento
TiDB
Promotion

3. 3
Our Team Mission
AWS Cloud
AWS Cloud
AWS Cloud
統合的にアカウントを管理・保守
お客様
ソリューションのご提案
クラウドの進化及びサーバレス化の流れに沿い、従来型のサーバの運用保守からの移行を目指して、
アカウントの運用保守の専門チームとしてTechnical Account Management（TAM）グループを立ち上げました。
● 請求・コスト管理
● ユーザ権限管理
● プロジェクトマネジメンz
お客様の課題解決にとにかく寄り添うことがミッションとなります。
それぞれのプロジェクトのマネジメント
権限のモニタリング

4. 4
取り組み例）サードパーティの統合管理システムの導入
4
✔ IAM
：過剰な権限を持つクラウドIDの識別・管理。
✔ 使用中の権限
：アクセスパターンを分析して、使用されてない権限を特定。
アクセスポリシーを作成して、効率的な業務遂行に必要な権限だけを付与するように最適化。
✔ アクセスレビュー
：定期的にアクセスレビューを実施が可能、ユーザ権限を評価。
✔ リスクラベル
：発生したリスクラベル（多要素認証・非アクティブユーザ・管理者アクセス）について、IAM違反を自動的にマッピング。
IAMと使用ポリシーの表示 アクセスパターンの表示

5. はじめに
5

6. クラウドの進化に伴い、サービスの選択が難しい時代へ
6
● コストは抑えたいよね。
● でも安定稼働は捨てがたい。
● パフォーマンスも気になる。
● 開発のアジリティは落としたくない。
● アプリケーションをどのサービスで動かそうか？

7. Computeについて考察
7

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

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

10. 10
Compute プロダクト一覧
● CNCF WG Serverless Whitepaper v1.0 による分類とのマッピング
Compute
Engine
Google
Kubernetes
Engine
Cloud Run App Engine Cloud Functions
仮想マシン
Container as a
Service (CaaS)
サーバーレス
Platform as a
Service (PaaS)
サーバーレス
(FaaS)
https://github.com/cncf/wg-serverless/tree/master/whitepapers/serverless-
overview
● 実はそれぞれの実現モデルにあわせて、わかりやすく分かれています
サーバレスとは？という定義の部分も参考にされるといいかと。

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

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

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

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

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

16. 16
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
Virtual
Private Cloud
Persistent
Disk
Cloud Load
Balancing
Operations

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

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

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

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

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

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

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

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

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

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

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

28. 28
Day 2 Operationにおける考慮
※ Day 0 計画段階
Day 1 初期構築・開発段階
Day 2 運用段階

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

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

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

32. 32
Compute Engine
GKE
Cloud Run App Engine Cloud Functions
スタンダード Autopilot
料金を構成す
る要素
●仮想マシン
(vCPU, メモリ)
●ディスク
●イメージ
●ネットワーク転送量
●GPU
●Compute Engine
利用料
●クラスタ利用料
(1 クラスタごと)
●Pod
(vCPU, メモリ,
ディスク)
●クラスタ利用料
(1 クラスタごと)
●CPU
●メモリ
●リクエスト量
●ネットワーク転送量
●インスタンス(CPU, メモ
リ)
●ネットワーク転送量
●呼び出し回数
●コンピューティング時間
(CPU, メモリ)
●ネットワーク転送量
最小課金
単位
最低 1 分、
以降は 1 秒単位
最低 1 分、
以降は 1 秒単位
1 秒 100 ミリ秒 15 分 100 ミリ秒
ゼロスケール
可能か？
いいえ いいえ
はい
（クラスタ利用料は除
く）
はい はい はい
Excellent
Good
Average
評価表

33. 33
まとめ

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

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

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

37. 37
ご清聴ありがとうございます。