Mais conteúdo relacionado Semelhante a What’s new in cloud run 2021 後期 (20) Mais de Google Cloud Platform - Japan (20) 1. 頼兼 孝幸
Google Cloud Japan
Application Modernization Specialist
What’s New in Cloud Run 2021 後期
5. 高速なデプロイ
ステートレスなコンテナ
高速に 0 to N スケール
数秒でデプロイし URL を付与
サーバーレス・ネイティブ
管理するサーバーはなし
コードに集中
言語やライブラリの制約なし
きっちり使った分だけお支払い
高いポータビリティ
どこでも同じ Developer Experience
フルマネージでも GKE のクラスタ上で
も
Knative API の一貫性
ロックインの排除
Cloud Run の主な特徴
8. Cloud Run のリソースモデル
Revision A-1
Revision A-2
Revision A-3
Revision B-1
Revision B-2
Container
Instance
Container
Instance
Container
Instance
Requests
Service A @region A
Service B @region B
Project X
Service
Cloud Run の主リソース
Service 毎に Endpoint を提供
自動で設定される a.run.app ドメイン、
もしくはカスタム ドメインが選択可能
Revision
デプロイするごとに生成される
コンテナ イメージとデプロイ時に指定される
環境変数やパラメーターから構成される
Container Instance
実際にリクエストを受けるコンテナ、
リクエスト の数に応じて自動的にスケール
9. コンテナのスペック
● CPU
○ デフォルト 1 vCPU
○ 変更可、1 vCPU、2 vCPU、4 vCPU から選択
○ 4 vCPU の場合はメモリを 2 GiB 以上選択する必要あり
● メモリ
○ デフォルト 512 MiB
○ 変更可、最小 128 MiB 〜 最大 16 GiB
● ファイルシステム
○ 読み書き可能
○ コンテナに割り当てられたメモリ上を利用、データの永続性なし（第 1 世代）
○ Filestore や Cloud Storage FUSE を利用が可能（第 2 世代）
New
New
Preview
Preview
10. Concurrency（ コンカレンシー ）
Concurrency とは同時に 1 つの Container Instance に
投げられるリクエストの最大数。
Google Cloud Functions など一般的な FaaS は
一度に 1 つのリクエストしかハンドルできない。
なので "concurrency = 1".
Cloud Run の場合、concurrency の値を 1 から 1000 まで
設定できる（default: 80） ので、1 つの Container Instance で同
時に複数のリクエストを処理することができる。
concurrency = 1
concurrency = 20
13. HTTP リクエスト処理時間に応じた CPU Allocation と課金
Instance
Billable Time
Instance Time
Request 1
Start
Request 1
End
Request 2
Start
Request 2
End
14. Cold Start に対応する
Minimum instances を指定することで Cold Start の影響を小さくすることができる
1
常時起動する Container Instance 数を
指定しておく
リクエストがスパイクした時に
Cold Start の影響を小さくできる
$ gcloud alpha run deploy servicea
--image gcr.io/cloudrun/hello
--min-instances=4
2
3
4
15. 1. HTTP リクエスト処理時間に応じたCPU Allocation と課金（これまで通り）
● Container Instance が HTTP リクエストを処理している時間にのみ課金 が行われる。
● 常に HTTP のリクエストが伴う Web や API などのホスティングに最適。
● HTTP リクエストがない場合、 CPU が Throttle されてしまいバックグラウンドタスクなどを
行うことが出来ない。
2. インスタンス時間に応じたCPU Allocation と課金（Always on CPU）
● HTTP リクエストの有無に関わらず、 常に CPU が Allocate され、Container Instance が存在してい
る時間に対して課金 が行われる。
● バックグラウンドタスクや非同期処理などを行うのに最適。
Always on CPU の登場で、非同期処理のユースケースにも対応
New
Preview
16. バックグラウンド タスクを実行する、非同期処理を行う
デフォルトでは HTTP リクエスト 処理中にのみ CPU が Allocation されるが、
常時 CPU を Allocation することで、HTTP リクエストがない状況でも
バックグラウンド タスクなどの処理が可能に。
Cloud Pub / Sub への Pull Subscribe
$ gcloud beta run deploy servicea
--no-cpu-throttling
--min-instances=3
Cloud Pub / Sub
Topic
pull
pull
pull
レスポンス後にタスクを実行する
1. リクエスト
2. レスポンス
3. レスポンス後に、
時間が掛かる処理を実行
3rd Party
Service
$ gcloud beta run deploy serviceb
--no-cpu-throttling
--min-instances=1
min-instances
オプション無しだと、
15分程度でコンテナが
削除されるので注意
Preview
17. インスタンス時間に応じた CPU Allocation と課金
Instance
Instance Time
Billable Time
Request 1
Start
Request 1
End
Request 2
Start
Request 2
End
Instance Deleted
18. 性能の高速化
● CPU パフォーマンスの高速化
● ネットワーク パフォーマンスを高速化
ユースケースの拡大
● すべてのシステムコール、名前空間、 cgroup のサポートを含む、Linux との完全な互換性
● ネットワーク ファイル システムのサポート
※ プレビューでは、第 1 世代よりもコールド スタート時間が少し長くなる点に注意
第 2 世代の実行環境の登場
New
Preview
19. ネットワーク ファイル システムのサポート
● Cloud Filestore や Cloud Storage FUSE を
利用して、複数のコンテナやサービス間のデー
タを共有可能
コンテナ
インスタンス
サービスA サービスB
コンテナ
インスタンス
コンテナ
インスタンス
起動スクリプトで
mount
VPC Access Connector 経由で
VPC 内の Filestore へアクセス
Preview
21. ● Cloud Audit Logs と Pub/Sub が、
Eventarc トリガーとして設定可能だった
が、Cloud Storage イベントも、Cloud
Audit Logs を使わずに設定することが可
能になりました
● Cloud Audit Logs を不要に有効化する必
要もなく、ネイティブ統合されることで、 起
動までの時間が短縮される などのメリット
があります
● オブジェクトの作成、削除、アーカイブ、メ
タデータの更新など
Eventarc が Cloud Storage トリガーをサポート
gcloud eventarc triggers create storage-events-trigger
--destination-run-service={CLOUD_RUN_SERVICE}
--destination-run-region={CLOUD_RUN_REGION}
--event-filters="type=google.cloud.storage.object.v1.finalized"
--event-filters="bucket={GCS_BUCKET}"
--service-account={SERVICE_ACCOUNT}
オブジェクト作成をトリガーに
Cloud Run サービスを実行する例
Preview
New
22. Cloud Run は Secret Manager をネイティブにサポート。シークレットを簡単かつ安全に扱いつ つ、
3rd party などのサービスへアクセスすることが可能。
1. シークレットをコンテナインスタンスに
マウントor 環境変数としてセット
3rd Party
Service
2. シークレットを使って、
3rd Party
Service へアクセス
Service A
Container
Instance
App / HTTP
Server
Secret Manager を使い、3rd party サービスへアクセスする
Secret
Manager
GA
27. 背景（課題）
● インフラ管理、運用を行う人員がいない 。いた場合も、 コストをかけたくない
● リリース初期は最小限にコストを抑え つつ、事業が伸びた際に は、その分
スケールする ようなバックエンド構成にしておきたい
解決手段
● アプリ基盤や DB を、Google マネージドなサーバーレス（厳密には、 Spanner はサー
バーレスではないが、インフラ管理不要）構成にする
● Cloud Run でサービスを分離させ、事業規模に応じてサービスを増やすことで、
マイクロサービスを正しい粒度で運用可能にする
Cloud Run
HTTP(S) LB
Cloud
Spanner
Frontend データベース
Backend Service A
Cloud Run Firestore
データベース
Cloud Storage
HTML, CSS, JS (static)
Backend Service B
Cloud Run Eventarc Cloud Run
Backend Service C
Cloud Storage
Event
trigger
インフラ管理不要のマイクロサービス バックエンドを構築
29. 公式ブログに示された “一つの” 方針
・“コンテキスト境界” をまたぐ制御は コレオグラフィ
・“コンテキスト境界” 内の制御には オーケストレーション
あなたの EDA に必要なのは Choreography？ Orchestration？
どちらがいいではなく
適宜使い分けるもの
※ EDA = Event Driven Architecture
32. どちらにも使えるその他 Google Cloud のマネージド サービス
EDA の部品としてご検討ください
・Cloud Scheduler: フルマネージド cron ジョブ スケジューラ
・Cloud Tasks: 後続の処理と関心を分離できない点には注意
33. ● Concurrency は最大 1,000、メモリは最大 16 GB まで設定可能に
● Always on CPU の登場により、非同期処理やバックグラウンド タスクなどにも対応
● 第 2 世代の実行環境の登場により、 Filestore を利用したファイル保持などが可能
● Eventarc で Cloud Storage イベントを、ネイティブにトリガー可能
● Secret Manager や、Binary Authorization など、セキュリティ機能の連携が GA
まとめ
