Amazon ECSとCloud Runの相互理解で広げる クラウドネイティブの景色 / Mutually understanding Amazon ECS and Cloud Run

CloudNative Days Winter 2024の登壇資料です。
https://event.cloudnativedays.jp/cndw2024/talks/2438

Transcript

1. Amazon ECSとCloud Runの相互理解で広げる クラウドネイティブの景色 新井 雅也 (@msy78)
2. 新井 雅也 現在は衛星の開発・運用を手掛けるスタートアップ企業にて、 クラウドを中心とした技術力を活かしつつ、宇宙業界の発展に尽力 している。 好きなサービス: Amazon ECS、AWS Fargate、GKE、Cloud Run 好きなエナジードリンク: Red Bull AWS Container Hero AWS Ambassador 2022-2023 Google Cloud Champion Innovator Google Cloud Partner Top Engineer 2023/2025 @msy78 Synspective Inc. - Principal Cloud Architect
3. 本発表の目的 ECSもしくはCloud Runのいずれかの事前知識を活用することで、 他方のサービスと照らし合わせながら相互理解が進むことに気づいてもらう
4. ⚠ 前提 ⚠ • 各クラウドサービスの優劣比較を目的とはしていません。 あくまで、「他方の領域に学びを広げる観点」で捉えましょう。 ・Amazon ECSのデータプレーンとして、AWS Fargateを前提に解説します。 ・本発表で扱うアーキテクチャは一般的な例です。 ビジネス要件によっては、他の構成が最適となる可能性があります。 ・便宜上、解説はECS→Cloud Runの順番で行います。
5. Q: なぜAmazon ECS とCloud Run？
6. Q: なぜAmazon ECS とCloud Run？ A: クラウド上でコンテナを活用した システムを構築する際に最も受け入れら れているサービスだから
7. • 世界中のECSタスク起動数は3億個/日 • AWSでコンテナ新規利用ユーザの65%がECSを選択 • 多数のECS/Fargateアーキテクチャ事例が公開 • 利用実績に関する定量的な数値は公開されていないものの、 2019~2024年の5年間でPreviewを除く機能追加発表は151件 • Cloud Run functionsの統合など、主要サービスとしてリブランディング
8. アジェンダ 1. 基本的な特徴 2. アーキテクチャ デザインの違い 3. 非機能デザイン からの理解 以下の3つの観点から相互理解を目指す
9. アジェンダ 1. 基本的な特徴 2. アーキテクチャ デザインの違い 3. 非機能デザイン からの理解 以下の3つの観点から相互理解を目指す
10. • コンポーネントとワークロード • VPC内外 • アクセス制御 • コンテナ実行環境 各サービスの基本的な特徴 2 4 3 1
11. • コンポーネントとワークロード • VPC内外 • アクセス制御 • コンテナ実行環境 各サービスの基本的な特徴 2 4 3 1
12. ECSは主に5つのコンポーネントで構成 基本的な各サービスの特徴 - コンポーネントとワークロード
13. ECSは主に5つのコンポーネントで構成 &$4Ϋϥελʔ &$4αʔϏε &$4λεΫ ίϯςφ 基本的な各サービスの特徴 - コンポーネントとワークロード ɾෳ਺ͷ&$4αʔϏεɾ&$4λεΫ͔ΒͳΔ ࿦ཧతͳάϧʔϓ ɾࢦఆͨ͠&$4λεΫͷىಈ਺Λҡ࣋ ɾͭҎ্ͷίϯςφΛଋͶΔ&$4ͷ࠷খ࣮ߦ୯Ґ ɾΞϓϦέʔγϣϯΛύοέʔδԽ࣮ͨ͠ߦओମ &$4λεΫఆٛ ɾ&$4λεΫΛੜ੒͢ΔͨΊͷςϯϓϨʔτ ɾϦϏδϣϯ͝ͱʹ؅ཧ
14. ECSの各コンポーネントとワークロードの関連性 基本的な各サービスの特徴 - コンポーネントとワークロード
15. ECSの各コンポーネントとワークロードの関連性 基本的な各サービスの特徴 - コンポーネントとワークロード マネージドな データプレーン
16. ECSの各コンポーネントとワークロードの関連性 基本的な各サービスの特徴 - コンポーネントとワークロード マネージドな データプレーン Webサービス用途 ジョブ用途
17. Cloud Run services は4つのコンポーネントで構成 基本的な各サービスの特徴 - コンポーネント αʔϏε ϦϏδϣϯ Πϯελϯε ίϯςφ ɾϦϏδϣϯΛଋͶͯ)5514ΤϯυϙΠϯτΛఏڙ ɾσϓϩΠຖʹ࡞੒͞ΕΔઃఆͷ୯Ґ ɾϦϦʔε࣌ɺϦϏδϣϯ͝ͱʹτϥϑΟοΫΛ੍ޚͰ͖Δ ɾͭҎ্ͷίϯςφΛଋͶΔ$MPVE 3VOͷ࠷খ࣮ߦ୯Ґ ɾϦϏδϣϯʹඥͮ͘ Ref. https://cloud.google.com/run/docs/resource-model ɾΞϓϦέʔγϣϯΛύοέʔδԽ࣮ͨ͠ߦओମ
18. Cloud Run jobs は4つのコンポーネントで構成 基本的な各サービスの特徴 - コンポーネント δϣϒ λεΫ Πϯελϯε ίϯςφ ɾෳ਺ͷλεΫΛଋͶ࣮ͯߦ ɾฒྻ࣮ߦͷ୯ҐɻΠϯελϯεΛ࣮ͭߦ ɾͭҎ্ͷίϯςφΛଋͶΔ$MPVE 3VOͷ࠷খ࣮ߦ୯Ґ ɾϦϏδϣϯʹඥͮ͘ Ref. https://cloud.google.com/run/docs/resource-model ɾΞϓϦέʔγϣϯΛύοέʔδԽ࣮ͨ͠ߦओମ Services と同じ Services と同じ
19. Cloud Runの各コンポーネントとワークロードの関連性 基本的な各サービスの特徴 - コンポーネントとワークロード Amazon ECSと異なり、クラスターの概念がない
20. Cloud Runの各コンポーネントとワークロードの関連性 基本的な各サービスの特徴 - コンポーネントとワークロード Webサービス用途 ジョブ用途
21. • コンポーネントとワークロード • VPC内外 • アクセス制御 • コンテナ実行環境 各サービスの基本的な特徴 2 4 3 1
22. 前提として、AWSとGoogle CloudではVPCのスコープが異なる
23. おさらい）AWSにおけるVPCのスコープ リージョン アベイラビリティゾーン アベイラビリティゾーン アベイラビリティゾーン 基本的な各サービスの特徴 - VPC内外
24. リージョン アベイラビリティゾーン アベイラビリティゾーン アベイラビリティゾーン VPC サブネット サブネット サブネット AWSの場合、 VPCはリージョンに閉じる おさらい）AWSにおけるVPCのスコープ 基本的な各サービスの特徴 - VPC内外
25. ECSタスクはVPC内サブネット上にデプロイされるリソース リージョン アベイラビリティゾーン アベイラビリティゾーン アベイラビリティゾーン VPC サブネット サブネット サブネット ECSタスク ECSタスク ECSタスク 可用性を担保するために、 マルチAZ考慮が必要 基本的な各サービスの特徴 - VPC内外
26. おさらい）Google CloudにおけるVPCのスコープ リージョン ゾーン ゾーン ゾーン リージョン ゾーン ゾーン ゾーン 基本的な各サービスの特徴 - VPC内外
27. リージョン ゾーン ゾーン ゾーン サブネット リージョン ゾーン ゾーン ゾーン サブネット VPC Google Cloudの場合、 VPCはリージョンを またがる おさらい）Google CloudにおけるVPCのスコープ 基本的な各サービスの特徴 - VPC内外
28. Cloud RunはVPC外にデプロイされるリソース リージョン ゾーン ゾーン ゾーン サブネット リージョン ゾーン ゾーン ゾーン サブネット VPC Cloud Run 透過的にゾーン毎に リソースがデプロイされる ためマルチAZ考慮は不要 別サービスと連携することで、 内部的にVPC内に通信可能 基本的な各サービスの特徴 - VPC内外
29. • コンポーネントとワークロード • VPC内外 • アクセス制御 • コンテナ実行環境 各サービスの基本的な特徴 2 4 3 1
30. ECSのHTTP(S)リクエストはセキュリティグループにて制御 VPC ECSタスク サブネット Security group サブネット単位や セキュリティグループIDなどにより TCPレベルでアクセス制御 基本的な各サービスの特徴 - アクセス制御
31. Cloud RunのHTTPSリクエストはIngress制御+IAM認証で制御 リージョン Cloud Run Ingress制御 IAM認証 Internet VPC 基本的な各サービスの特徴 - アクセス制御
32. リージョン Cloud Run Ingress制御：すべて IAM認証： 不要 VPC Internet IAM認証あり IAM認証なし 実行認証あり 実行認証なし 基本的な各サービスの特徴 - アクセス制御 Cloud RunのHTTPSリクエストはIngress制御+IAM認証で制御
33. リージョン Cloud Run Ingress制御：すべて IAM認証： 要 VPC Internet 実行権限あり 実行権限なし 実行認証あり 実行認証なし 基本的な各サービスの特徴 - アクセス制御 Cloud RunのHTTPSリクエストはIngress制御+IAM認証で制御
34. リージョン Cloud Run Ingress制御：内部 IAM認証： 不要 VPC Internet 実行権限あり 実行権限なし 実行認証あり 実行認証なし 基本的な各サービスの特徴 - アクセス制御 Cloud RunのHTTPSリクエストはIngress制御+IAM認証で制御
35. リージョン Cloud Run Ingress制御：内部 IAM認証： 要 VPC Internet 実行権限あり 実行権限なし 実行認証あり 実行認証なし 基本的な各サービスの特徴 - アクセス制御 Cloud RunのHTTPSリクエストはIngress制御+IAM認証で制御
36. • コンポーネントとワークロード • VPC内外 • アクセス制御 • コンテナ実行環境 各サービスの基本的な特徴 2 4 3 1
37. ECS/FargateはFirecrackerというmicroVMで起動 各サービスの基本的な特徴 - コンテナ実行環境
38. ECS/FargateはFirecrackerというmicroVMで起動 • KVMベースの仮想化 ※同一マシン上で別VMとして分離 各サービスの基本的な特徴 - コンテナ実行環境
39. ECS/FargateはFirecrackerというmicroVMで起動 • KVMベースの仮想化 ※同一マシン上で別VMとして分離 • GoogleのChromium OSで使われるcrosvmをフォークして再利用(※) ※seccomp-bpfやキャッシュによるデータ転送面で利点 (※)https://firecracker-microvm.github.io/ 各サービスの基本的な特徴 - コンテナ実行環境
40. ECS/FargateはFirecrackerというmicroVMで起動 • KVMベースの仮想化 ※同一マシン上で別VMとして分離 • GoogleのChromium OSで使われるcrosvmをフォークして再利用(※) ※seccomp-bpfやキャッシュによるデータ転送面で利点 • LambdaやApp Runner等でも利用 (※)https://firecracker-microvm.github.io/ 各サービスの基本的な特徴 - コンテナ実行環境
41. ECS/FargateはFirecrackerというmicroVMで起動 ホストカーネル VMM (ハイパーバイザー) ハードウェア システムコール 仮想ハードウェア ゲストカーネル システムコール コンテナ Firecracker コンテナランタイム microVM 各サービスの基本的な特徴 - コンテナ実行環境
42. Cloud Runは世代により実行環境が異なる 各サービスの基本的な特徴 - コンテナ実行環境
43. Cloud Runは世代により実行環境が異なる • 第１世代はgVisorベース • コールドスタートが早い • 一部のLinuxシステムコールと非互換(※1) (※1)https://gvisor.dev/docs/user_guide/compatibility/linux/amd64/ 各サービスの基本的な特徴 - コンテナ実行環境
44. Cloud Runは世代により実行環境が異なる • 第１世代はgVisorベース • コールドスタートが早い • 一部のLinuxシステムコールと非互換(※1) • 第２世代はmicroVMベース(※2) • CPUやネットワークのパフォーマンスが改善 • 第２世代はLinuxシステムコールと完全互換 (※1)https://gvisor.dev/docs/user_guide/compatibility/linux/amd64/ (※2)Cloud Run jobsは第２世代の実行環境のみ 各サービスの基本的な特徴 - コンテナ実行環境
45. Cloud Runは世代により実行環境が異なる • 第１世代はgVisorベース • コールドスタートが早い • 一部のLinuxシステムコールと非互換(※1) • 第２世代はmicroVMベース(※2) • CPUやネットワークのパフォーマンスが改善 • 第２世代はLinuxシステムコールと完全互換 • いずれの世代もBorg基盤上のKnative互換Appとして稼働 ※Knativeそのものではなく、Knative互換のAPIを提供 (※1)https://gvisor.dev/docs/user_guide/compatibility/linux/amd64/ (※2)Cloud Run jobsは第２世代の実行環境のみ 各サービスの基本的な特徴 - コンテナ実行環境
46. 世代毎のCloud Runコンテナ実行環境の違い 第１世代 第２世代 ホストカーネル gVisor ハードウェア システムコール(限定) システムコール ホストカーネル VMM (ハイパーバイザー) ハードウェア システムコール 仮想ハードウェア ゲストカーネル システムコール コンテナ コンテナランタイム microVM コンテナ コンテナランタイム ユーザー空間 上で動作 各サービスの基本的な特徴 - コンテナ実行環境
47. • コンポーネントとワークロード • VPC内外 • アクセス制御 • コンテナ実行環境 ここまでのまとめ 2 4 3 1 各サービスの基本的な特徴
48. • コンポーネントとワークロード • VPC内外 • アクセス制御 • コンテナ実行環境 2 4 3 1 コンテナ、タスク、 サービス、クラスター コンテナ、インスタンス、 リビジョン、サービス VPC内 VPC外 セキュリティグループ Ingress制御 + IAM認証 microVM (Firecracker) gVisor / microVM ここまでのまとめ 各サービスの基本的な特徴
49. アジェンダ 1. 基本的な特徴 2. アーキテクチャ デザインの違い 3. 非機能デザイン からの理解 以下の3つの観点から相互理解を目指す ✔
50. アーキテクチャデザインの違い
51. アーキテクチャデザインの違い 一般的なWebアプリケーション構成を例に 内容を追っていく
52. クラウド 一般的なWebアプリケーション構成例 LB Backend App (BFF) Backend App Backend App DB DB Job Scheduler Job Workflow WAF … … 外部 サービス Client Internet Internet
53. クラウド 一般的なWebアプリケーション構成例 LB Backend App (BFF) Backend App Backend App DB DB Job Scheduler Job Workflow WAF … … 外部 サービス Client Internet or or or or Internet
54. クラウド 一般的なWebアプリケーション構成例 LB Backend App (BFF) Backend App Backend App DB DB Job Scheduler Job Workflow WAF … … 外部 サービス Client Internet or or or or Internet
55. アーキテクチャデザインの違い – インターネットアクセス セキュリティや可用性観点からWAFやロードバランサを配置する構成は共通
56. アーキテクチャデザインの違い – インターネットアクセス セキュリティや可用性観点からWAFやロードバランサを配置する構成は共通
57. アーキテクチャデザインの違い – インターネットアクセス セキュリティや可用性観点からWAFやロードバランサを配置する構成は共通
58. セキュリティや可用性観点からWAFやロードバランサを配置する構成は共通 アーキテクチャデザインの違い – インターネットアクセス
59. (※)2024年11月28日時点ではプレビューだが、Cloud Runに直接IAPの紐づけも可能 アーキテクチャデザインの違い – インターネットアクセス セキュリティや可用性観点からWAFやロードバランサを配置する構成は共通
60. まとめ Amazon ECS Cloud Run • ロードバランサとしてALB、WAF としてAWS WAFを配置 • フェデレーティッドIDからのアク セスのみ許容する場合はAmazon Verified Accessと連携 • ロードバランサとしてExternal ALB、WAFとしてCloud Armorを 配置 • 特定Googleアカウントからのリ クエストのみを許容する場合は IAP(Identity-aware Proxy)と連携 アーキテクチャデザインの違い – インターネットアクセス
61. クラウド 一般的なWebアプリケーション構成例 LB Backend App (BFF) Backend App Backend App DB DB Job Scheduler Job Workflow WAF … … 外部 サービス Client Internet or or or or Internet
62. ECSとCloud Runで通信方法とアクセス制御方法が大きく異なる アーキテクチャデザインの違い – サービス間内部通信
63. アーキテクチャデザインの違い – サービス間内部通信 ECSとCloud Runで通信方法とアクセス制御方法が大きく異なる
64. アーキテクチャデザインの違い – サービス間内部通信 ECSとCloud Runで通信方法とアクセス制御方法が大きく異なる
65. アーキテクチャデザインの違い – サービス間内部通信 ECSとCloud Runで通信方法とアクセス制御方法が大きく異なる
66. アーキテクチャデザインの違い – サービス間内部通信 ECSとCloud Runで通信方法とアクセス制御方法が大きく異なる
67. アーキテクチャデザインの違い – サービス間内部通信 ECSとCloud Runで通信方法とアクセス制御方法が大きく異なる
68. アーキテクチャデザインの違い – サービス間内部通信 ECSとCloud Runで通信方法とアクセス制御方法が大きく異なる
69. アーキテクチャデザインの違い – サービス間内部通信 ECSとCloud Runで通信方法とアクセス制御方法が大きく異なる
70. まとめ Amazon ECS Cloud Run • 複数の接続パターンあり • ELB • ECS Service Discovery • ECS Service Connect • App Mesh(廃止予定) • Ingress制御+IAM認証の組み合わ せによるアクセス許可 • 内部通信からのみ許容する場 合、VPCのバイパスが必要 アーキテクチャデザインの違い – サービス間内部通信
71. クラウド 一般的なWebアプリケーション構成例 LB Backend App (BFF) Backend App Backend App DB DB Job Scheduler Job Workflow WAF … … 外部 サービス Client Internet or or or or Internet
72. 外部サービスへのアクセスはVPC要否により構成が異なる アーキテクチャデザインの違い – インターネットへの外部通信
73. 外部サービスへのアクセスはVPC要否により構成が異なる アーキテクチャデザインの違い – インターネットへの外部通信
74. 外部サービスへのアクセスはVPC要否により構成が異なる アーキテクチャデザインの違い – インターネットへの外部通信
75. 外部サービスへのアクセスはVPC要否により構成が異なる アーキテクチャデザインの違い – インターネットへの外部通信
76. まとめ Amazon ECS Cloud Run • VPC内から外部に通信する際は NAT Gatewayを経由 • リージョンサービスなので、グ ローバルIPアドレスで直接外部 サービスに通信可能 • 外部サービス側要件として、IPア ドレス制限が必要な場合はVPC経 由でCloud NATを通過 アーキテクチャデザインの違い – インターネットへの外部通信
77. クラウド 一般的なWebアプリケーション構成例 LB Backend App (BFF) Backend App Backend App DB DB Job Scheduler Job Workflow WAF … … 外部 サービス Client Internet or or or or Internet アーキテクチャデザインの違い – インターネットへの外部通信
78. ジョブ実行は各クラウドのワークフローサービスを利用 アーキテクチャデザインの違い – ジョブワークフロー
79. ジョブ実行は各クラウドのワークフローサービスを利用 アーキテクチャデザインの違い – ジョブワークフロー
80. ジョブ実行は各クラウドのワークフローサービスを利用 アーキテクチャデザインの違い – ジョブワークフロー
81. まとめ Amazon ECS Cloud Run • Step Functionsにより、ECSタス クをコール • 定期実行する場合はEventBridge でStep Functionsを呼び出し • Cloud Workflowsにより、Cloud Run jobsをコール • 定期実行する場合は、Cloud SchedulerでCloud Workflowsを 呼び出し アーキテクチャデザインの違い – ジョブワークフロー
82. アジェンダ 1. 基本的な特徴 2. アーキテクチャ デザインの違い 3. 非機能デザイン からの理解 以下の3つの観点から相互理解を目指す ✔ ✔
83. 非機能観点におけるアーキテクチャベストプラクティスが提供
84. Well-Architected Framework Architecture Framework 非機能観点におけるアーキテクチャベストプラクティスが提供
85. Well-Architected Framework Architecture Framework 共通軸による設計観点をいくつかピックアップ
86. 共通軸による設計観点をいくつかピックアップ Well-Architected Framework Architecture Framework 運用デザイン セキュリティ 信頼性 コスト最適化 パフォーマンス CI/CD設計、ログ運用 クレデンシャル管理 スケールアウト設計 シグナルハンドリング 課金モデル
87. 運用デザイン – CI/CD設計
88. 大きな違いとしては、AWSは専用のワークフローサービスがある点や Google Cloudでは デプロイサービスに承認プロセスがある 非機能デザインからの理解 – CI/CD設計
89. GitHub Actionsによる CIアーキテクチャ例 or 大きな違いとしては、AWSは専用のワークフローサービスがある点や Google Cloudでは デプロイサービスに承認プロセスがある 非機能デザインからの理解 – CI/CD設計
90. 大きな違いとしては、AWSは専用のワークフローサービスがある点や Google Cloudでは デプロイサービスに承認プロセスがある 非機能デザインからの理解 – CI/CD設計
91. 大きな違いとしては、AWSは専用のワークフローサービスがある点や Google Cloudでは デプロイサービスに承認プロセスがある 非機能デザインからの理解 – CI/CD設計
92. Amazon ECS Cloud Run • CI/CDワークフロー： CodePipeline or CodeBuild • ビルド：CodeBuild • デプロイ：CodeBuild or CodeDeploy • 承認プロセス： CodePipeline • CI/CDワークフロー：Cloud Build • ビルド：Cloud Build • デプロイ：Cloud Build or Cloud Deploy • 承認プロセス： CodeBuild or CodeDeploy まとめ 非機能デザインからの理解 – CI/CD設計
93. 運用デザイン –ログ運用
94. ECSはFluentbitをサイドカー構成とすることで、 出力先を柔軟に変更できる一方、Cloud RunはCloud Logging出力がマスト 非機能デザインからの理解 – ログ運用
95. 非機能デザインからの理解 – ログ運用 ECSはFluentbitをサイドカー構成とすることで、 出力先を柔軟に変更できる一方、Cloud RunはCloud Logging出力がマスト
96. 非機能デザインからの理解 – ログ運用 ECSはFluentbitをサイドカー構成とすることで、 出力先を柔軟に変更できる一方、Cloud RunはCloud Logging出力がマスト
97. 非機能デザインからの理解 – ログ運用 ECSはFluentbitをサイドカー構成とすることで、 出力先を柔軟に変更できる一方、Cloud RunはCloud Logging出力がマスト ECSのログ長期保管と分析のために、 出力先を変えたい場合はどうする？
98. 非機能デザインからの理解 – ログ運用 ECSはFluentbitをサイドカー構成とすることで、 出力先を柔軟に変更できる一方、Cloud RunはCloud Logging出力がマスト
99. 非機能デザインからの理解 – ログ運用 ECSはFluentbitをサイドカー構成とすることで、 出力先を柔軟に変更できる一方、Cloud RunはCloud Logging出力がマスト
100. 非機能デザインからの理解 – ログ運用 ECSはFluentbitをサイドカー構成とすることで、 出力先を柔軟に変更できる一方、Cloud RunはCloud Logging出力がマスト Cloud Runのログ長期保管と分析のために、 出力先を変えたい場合はどうする？
101. Cloud Runでログを振り分ける場合、 Log sinkを作成して別途転送するように構成する 非機能デザインからの理解 – ログ運用
102. 非機能デザインからの理解 – ログ運用 Cloud Runでログを振り分ける場合、 Log sinkを作成して別途転送するように構成する
103. Amazon ECS Cloud Run • ログの基本出力はCloudWatch Logs • ログ出力を振り分ける場合、 fluentbitをサイドカー構成 • ログの基本出力はCloud Logging • ログ出力を振り分ける場合、Log Routerにより別のLog sinkを作成 まとめ 非機能デザインからの理解 – ログ運用
104. セキュリティ – クレデンシャル管理
105. クレデンシャル管理サービスを活用し、 アプリケーション起動時に環境変数として埋め込むことで安全に利用 非機能デザインからの理解 – セキュリティ/クレデンシャル管理
106. クレデンシャル管理サービスを活用し、 アプリケーション起動時に環境変数として埋め込むことで安全に利用 非機能デザインからの理解 – セキュリティ/クレデンシャル管理
107. Amazon ECSではタスク定義にSecrets Managerや SSM Parameter Storeの参照先を定義し、起動時に環境変数として埋め込み 非機能デザインからの理解 – セキュリティ/クレデンシャル管理
108. Cloud RunではSecret Managerを参照先として定義し、 起動時に環境変数として埋め込み 非機能デザインからの理解 – セキュリティ/クレデンシャル管理
109. まとめ Amazon ECS Cloud Run • ECSタスク定義にSecrets ManagerやSSM Parameter Store 参照先を定義し、コンテナ起動時 に環境変数として埋め込み • Cloud Run定義にSecret Manager の参照先を定義し、コンテナ起動 時に環境変数として埋め込み 非機能デザインからの理解 – セキュリティ/クレデンシャル管理
110. パフォーマンス – スケールアウト設計
111. Amazon ECSとCloud Runではスケールアウト挙動の バリエーションが大きく異なる 非機能デザインからの理解 – パフォーマンス/スケールアウト設計
112. Amazon ECSでは、3種類のスケーリングポリシーと スケールトリガ条件となるメトリクスを選択することで挙動を定義 非機能デザインからの理解 – パフォーマンス/スケールアウト設計
113. Amazon ECSでは、3種類のスケーリングポリシーと スケールトリガ条件となるメトリクスを選択することで挙動を定義 非機能デザインからの理解 – パフォーマンス/スケールアウト設計
114. Amazon ECSでは、3種類のスケーリングポリシーと スケールトリガ条件となるメトリクスを選択することで挙動を定義 非機能デザインからの理解 – パフォーマンス/スケールアウト設計
115. Amazon ECSでは、3種類のスケーリングポリシーと スケールトリガ条件となるメトリクスを選択することで挙動を定義 非機能デザインからの理解 – パフォーマンス/スケールアウト設計
116. Cloud Runの場合、スケールアウトロジックは内部仕様として単一であり、 最大リクエスト数・インスタンス数・CPU使用率により動作が決まる 非機能デザインからの理解 – パフォーマンス/スケールアウト設計
117. 非機能デザインからの理解 – パフォーマンス/スケールアウト設計 Cloud Runの場合、スケールアウトロジックは内部仕様として単一であり、 最大リクエスト数・インスタンス数・CPU使用率により動作が決まる
118. 非機能デザインからの理解 – パフォーマンス/スケールアウト設計 Cloud Runの場合、スケールアウトロジックは内部仕様として単一であり、 最大リクエスト数・インスタンス数・CPU使用率により動作が決まる
119. 非機能デザインからの理解 – パフォーマンス/スケールアウト設計 Cloud Runの場合、スケールアウトロジックは内部仕様として単一であり、 最大リクエスト数・インスタンス数・CPU使用率により動作が決まる
120. まとめ Amazon ECS Cloud Run • ステップスケーリングポリシー or ターゲット追跡スケーリング ポリシーに従ってスケールアウト • 最大リクエスト、インスタンス数、 CPU使用率を基に、Google Cloudの内部仕様に従ってスケー ルアウト 非機能デザインからの理解 – パフォーマンス/スケールアウト設計
121. 信頼性 – シグナルハンドリング
122. メンテナンスやスケールダウン時において アプリケーションを安全に停止するためにはシグナルハンドリングが重要 非機能デザインからの理解 – 信頼性/シグナルハンドリング
123. Amazon ECSでは停止指示としてSIGTERMが発行される 参考）https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task-lifecycle-explanation.html 非機能デザインからの理解 – 信頼性/シグナルハンドリング
124. Amazon ECSでは停止指示としてSIGTERMが発行される 参考）https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task-lifecycle-explanation.html 非機能デザインからの理解 – 信頼性/シグナルハンドリング 一定時間以内にアプリケーションが 終了しなかったらどうなる？
125. タイムアウト値以内にアプリケーションが停止しない場合、 SIGKILLにより強制終了される 参考）https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task-lifecycle-explanation.html 非機能デザインからの理解 – 信頼性/シグナルハンドリング
126. Cloud Runにおいても同様に、停止指示としてSIGTERMが発行される 参考）https://cloud.google.com/run/docs/samples/cloudrun-sigterm-handler?hl=ja 非機能デザインからの理解 – 信頼性/シグナルハンドリング
127. SIGKILLによる強制終了はECSと同じ。ただしシグナル発行までの 猶予時間に関してはCloud Runの世代によって挙動が変わる 参考）https://cloud.google.com/run/docs/samples/cloudrun-sigterm-handler?hl=ja 非機能デザインからの理解 – 信頼性/シグナルハンドリング
128. 参考）Cloud Run jobsに関しては、メンテナンスイベント時に 一時停止用のシグナルが発行される 参考）https://cloud.google.com/run/docs/configuring/task-timeout?hl=ja#observing_and_handling_maintenance_events 非機能デザインからの理解 – 信頼性/シグナルハンドリング
129. まとめ Amazon ECS Cloud Run • 停止指示としてSIGTERMが発行 • 強制停止指示としてSIGKILLが発 行 • 停止指示としてSIGTERMが発行 • 強制停止指示としてSIGKILLが発 行 • Cloud Run jobsに関してはメンテ ナンスイベント時にSIGTSTPと SIGCONTが発行 非機能デザインからの理解 – 信頼性/シグナルハンドリング
130. コスト最適化 – 課金モデル
131. コスト観点比較の特徴はARM、Spot、リクエスト時CPU割り当て 非機能デザインからの理解 – コスト最適化/課金モデル
132. コスト観点比較の特徴はARM、Spot、リクエスト時CPU割り当て 割り込みにより停止の可能性がある Fargate起動タイプ 独自のCPUプロセッサ (Gravitonプロセッサ) 非機能デザインからの理解 – コスト最適化/課金モデル
133. Amazon ECS Cloud Run • ECS自体は無料。Fargateに割り 当てるCPU/メモリ/ストレージで 料金が発生 • ARMプロセッサ採用により、 CPU/メモリのコストを約20%減 • Fargate Spot採用により、CPU/ メモリのコストを約70%減 • Cloud Runに割り当てるCPU/メ モリで料金が発生 • リクエスト時CPU割り当てにする ことでCPU/メモリの料金を削減 可能(100msec切り上げ、リクエ スト数課金あり) コスト観点比較の特徴はARM、Spot、リクエスト時CPU割り当て 非機能デザインからの理解 – コスト最適化/課金モデル
134. 本発表のまとめ
135. まとめ 1. 基本的な特徴 2. アーキテクチャ デザインの違い 3. 非機能デザイン からの理解 以下の3つの観点から相互理解を目指す ✔ ✔ ✔ • コンポーネントとワークロード • VPC内外 • アクセス制御 • コンテナ実行環境 • インターネットアクセス • サービス間内部通信 • インターネットへの外部通信 • ジョブワークフロー • 運用デザイン • セキュリティ • パフォーマンス • 信頼性 • コスト最適化
136. ご清聴ありがとうございました。