Successfully reported this slideshow.
Your SlideShare is downloading. ×

What’s new in cloud run 2021 後期

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad

Check these out next

1 of 33 Ad
Advertisement

More Related Content

Slideshows for you (20)

Similar to What’s new in cloud run 2021 後期 (20)

Advertisement

More from Google Cloud Platform - Japan (20)

Recently uploaded (20)

Advertisement

What’s new in cloud run 2021 後期

  1. 1. 頼兼 孝幸 Google Cloud Japan Application Modernization Specialist What’s New in Cloud Run 2021 後期
  2. 2. Cloud Run の概要
  3. 3. Cloud Run Google Cloud Next '19 で発表 Knative API 互換のサーバーレスコンテナ サーバーレスのアジリティを コンテナ化したアプリケーションに
  4. 4. Google Cloud のサーバーレス App Engine Cloud Functions Cloud Run アプリケーション 実行環境 関数 Function as a Service コンテナ 実行環境
  5. 5. 高速なデプロイ ステートレスなコンテナ 高速に 0 to N スケール 数秒でデプロイし URL を付与 サーバーレス・ネイティブ 管理するサーバーはなし コードに集中 言語やライブラリの制約なし きっちり使った分だけお支払い 高いポータビリティ どこでも同じ Developer Experience フルマネージでも GKE のクラスタ上で も Knative API の一貫性 ロックインの排除 Cloud Run の主な特徴
  6. 6. Cloud Run 完全にサーバーレス 管理するクラスタ無し 使った分だけお支払い Cloud Run for Anthos GKE のクラスタ上でサーバーレス体験 Anthos ライセンス + GKE の費用 本資料は こちらを説明 2 つの Cloud Run
  7. 7. Cloud Run の機能紹介 (新しい機能にフォーカス) New
  8. 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. 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. 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. 11. ユースケースの拡張
  12. 12. オートスケーリング Service A 繁忙期 Service A リクエストがない時間帯 Container Instance のデフォルト最大数は 1000 Cloud Run ではリクエスト数に応じて 特に明示的に設定をしていなくてもオートスケーリングを行う リクエストがしばらくない場合、 Container Instance が 0 になる
  13. 13. HTTP リクエスト処理時間に応じた CPU Allocation と課金 Instance Billable Time Instance Time Request 1 Start Request 1 End Request 2 Start Request 2 End
  14. 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. 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. 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. 17. インスタンス時間に応じた CPU Allocation と課金 Instance Instance Time Billable Time Request 1 Start Request 1 End Request 2 Start Request 2 End Instance Deleted
  18. 18. 性能の高速化 ● CPU パフォーマンスの高速化 ● ネットワーク パフォーマンスを高速化 ユースケースの拡大 ● すべてのシステムコール、名前空間、 cgroup のサポートを含む、Linux との完全な互換性 ● ネットワーク ファイル システムのサポート ※ プレビューでは、第 1 世代よりもコールド スタート時間が少し長くなる点に注意 第 2 世代の実行環境の登場 New Preview
  19. 19. ネットワーク ファイル システムのサポート ● Cloud Filestore や Cloud Storage FUSE を 利用して、複数のコンテナやサービス間のデー タを共有可能 コンテナ インスタンス サービスA サービスB コンテナ インスタンス コンテナ インスタンス 起動スクリプトで mount VPC Access Connector 経由で VPC 内の Filestore へアクセス Preview
  20. 20. 開発がより便利に、よりセキュアに
  21. 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. 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. 23. Binary Authorization を有効化し、承認されたコンテナだけをデプロイ GA 脆弱性スキャン Cloud Run Artifact Registry CI / CD Pipeline Build Test Scan Analysis QA イメージの署名を行い、 証明書を作成 deploy ポリシーに適合した イメージでない場合、デ プロイされない    Binary    Authorization
  24. 24. ネットワークや認証まわり
  25. 25. 前期にリリースがまとまっていたので割愛 Google Cloud Day: Digital ‘21 のセッションをご覧ください https://cloudonair.withgoogle.com/events/google-cloud-day-digital-21
  26. 26. Cloud Run を使ったアーキテクチャ
  27. 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. 28. “Google Cloud でのサービスオーケストレーション| Google Cloud Blog” https://cloud.google.com/blog/ja/topics/developers-practitioners/service-orchestration-google-cloud
  29. 29. 公式ブログに示された “一つの” 方針 ・“コンテキスト境界” をまたぐ制御は コレオグラフィ ・“コンテキスト境界” 内の制御には オーケストレーション あなたの EDA に必要なのは Choreography? Orchestration? どちらがいいではなく 適宜使い分けるもの ※ EDA = Event Driven Architecture
  30. 30. イベント駆動アーキテクチャのメリットがさまざま享受できる王道パターン ・Pub/Sub を使ったパターン(右)をまずは検討 ・Eventarc を挟む(左)かどうかは要件次第 Choreography アプローチ: Google Cloud での構成例
  31. 31. Orchestration アプローチ: Google Cloud での構成例 状態とその遷移を管理するコンポーネントが存在するパターン ・Workflows を使ったオーケストレーション ・もしくは自前実装(EDA の意識が不要、一般的によくある構成)
  32. 32. どちらにも使えるその他 Google Cloud のマネージド サービス EDA の部品としてご検討ください ・Cloud Scheduler: フルマネージド cron ジョブ スケジューラ ・Cloud Tasks: 後続の処理と関心を分離できない点には注意
  33. 33. ● Concurrency は最大 1,000、メモリは最大 16 GB まで設定可能に ● Always on CPU の登場により、非同期処理やバックグラウンド タスクなどにも対応 ● 第 2 世代の実行環境の登場により、 Filestore を利用したファイル保持などが可能 ● Eventarc で Cloud Storage イベントを、ネイティブにトリガー可能 ● Secret Manager や、Binary Authorization など、セキュリティ機能の連携が GA まとめ

×