What’s new in cloud run 2021 後期
- 1. 頼兼 孝幸 Google Cloud Japan Application Modernization Specialist What’s New in Cloud Run 2021 後期
- 3. Cloud Run Google Cloud Next '19 で発表 Knative API 互換のサーバーレスコンテナ サーバーレスのアジリティを コンテナ化したアプリケーションに
- 4. Google Cloud のサーバーレス App Engine Cloud Functions Cloud Run アプリケーション 実行環境 関数 Function as a Service コンテナ 実行環境
- 5. 高速なデプロイ ステートレスなコンテナ 高速に 0 to N スケール 数秒でデプロイし URL を付与 サーバーレス・ネイティブ 管理するサーバーはなし コードに集中 言語やライブラリの制約なし きっちり使った分だけお支払い 高いポータビリティ どこでも同じ Developer Experience フルマネージでも GKE のクラスタ上で も Knative API の一貫性 ロックインの排除 Cloud Run の主な特徴
- 6. Cloud Run 完全にサーバーレス 管理するクラスタ無し 使った分だけお支払い Cloud Run for Anthos GKE のクラスタ上でサーバーレス体験 Anthos ライセンス + GKE の費用 本資料は こちらを説明 2 つの 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
- 11. ユースケースの拡張
- 12. オートスケーリング Service A 繁忙期 Service A リクエストがない時間帯 Container Instance のデフォルト最大数は 1000 Cloud Run ではリクエスト数に応じて 特に明示的に設定をしていなくてもオートスケーリングを行う リクエストがしばらくない場合、 Container Instance が 0 になる
- 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
- 20. 開発がより便利に、よりセキュアに
- 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
- 23. Binary Authorization を有効化し、承認されたコンテナだけをデプロイ GA 脆弱性スキャン Cloud Run Artifact Registry CI / CD Pipeline Build Test Scan Analysis QA イメージの署名を行い、 証明書を作成 deploy ポリシーに適合した イメージでない場合、デ プロイされない Binary Authorization
- 24. ネットワークや認証まわり
- 25. 前期にリリースがまとまっていたので割愛 Google Cloud Day: Digital ‘21 のセッションをご覧ください https://cloudonair.withgoogle.com/events/google-cloud-day-digital-21
- 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 インフラ管理不要のマイクロサービス バックエンドを構築
- 28. “Google Cloud でのサービスオーケストレーション| Google Cloud Blog” https://cloud.google.com/blog/ja/topics/developers-practitioners/service-orchestration-google-cloud
- 29. 公式ブログに示された “一つの” 方針 ・“コンテキスト境界” をまたぐ制御は コレオグラフィ ・“コンテキスト境界” 内の制御には オーケストレーション あなたの EDA に必要なのは Choreography？ Orchestration？ どちらがいいではなく 適宜使い分けるもの ※ EDA = Event Driven Architecture
- 30. イベント駆動アーキテクチャのメリットがさまざま享受できる王道パターン ・Pub/Sub を使ったパターン（右）をまずは検討 ・Eventarc を挟む（左）かどうかは要件次第 Choreography アプローチ: Google Cloud での構成例
- 31. Orchestration アプローチ: Google Cloud での構成例 状態とその遷移を管理するコンポーネントが存在するパターン ・Workflows を使ったオーケストレーション ・もしくは自前実装（EDA の意識が不要、一般的によくある構成）
- 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 まとめ