AWSコンテナ本出版から3年経った今、もし改めて執筆し直すなら / If I revise our container book

Transcript

1. AWSコンテナ本出版から3 年経った今、もし改めて執 筆し直すなら… 新井 雅也 (@msy78)
2. 全体方針・設計 パート 構築・ハンズオン パート
3. 全体方針・設計 パート 構築・ハンズオン パート こちらのパートから 20分間お話します！ 馬勝さんパートと内容が重複する点があるかもしれませんが、ご容赦ください
4. 新井 雅也 現在は衛星の開発・運用を手掛けるSynspectiveにて、クラウドを 中心とした技術力を活かしつつ、宇宙業界の発展に尽力している。 好きなAWSサービスは、Amazon ECS、AWS Fargate。 好きなエナジードリンクはRed Bull。 AWS Container Hero AWS Ambassador 2022-2023 Google Cloud Champion Innovator Google Cloud Partner Top Engineer 2023 @msy78 Principal Cloud Architect
5. 本発表の目的 • 書籍出版から3年間の内容を踏まえ、ECS/Fargateを前提としたアーキテク チャ設計の最適解を探る • 本書を読んだことがある方に対して、更に最適な設計・構築ができるような ヒントを提供する
6. おはなしの前提 AWS上におけるECS/Fargateに関連した 技術・サービスの話にとどめます Kubernetesやその他コンテナ系サービス(App Runner等)に関する トピックは今回の発表では対象外
7. 時間軸 2021年 10月
8. 時間軸 2021年 10月 2021年出版当時のコンテナ本内ECS/Fargateアーキテクチャ
9. 時間軸 2024年 10月 2021年 10月 ちょうど 3年が経過
10. 時間軸 2024年 10月 ??? 2021年 10月
11. 時間軸 本日お話すること 2024年 10月 どのような AWSアーキテクチャを主軸にしながら 改めて読者のみなさまに価値を届けるか？ 2021年 10月
12. 時間軸 本日お話すること（３つの観点から考察） 2024年 10月 2021年 10月 ECS/Fargateをとりまく アーキテクチャデザイン Well-Architected Framework再考 サービス新規利用停止と 終了を踏まえて
13. ECS/Fargateを取り巻くアーキテクチャデザイン
14. 初版では、あえてECS/Fargateと他のAWSサービスのつなぎ方を 個別に切り出して執筆しなかった
15. • 刊行当初でさえAWSサービス数は200を超え、サービス連携の仕方は無数に存在 初版では、あえてECS/Fargateと他のAWSサービスのつなぎ方を 個別に切り出して執筆しなかった
16. • 刊行当初でさえAWSサービス数は200を超え、サービス連携の仕方は無数に存在 • サービス連携の判断は自分たちのビジネス要件次第 • ニーズに合わせて最終的には意思決定される • ECS/Fargateのサービス興隆期でもあり、見極めが難しい • 自分たちが紹介するアーキテクチャを”ベストプラクティス”と謳うには時期尚早 初版では、あえてECS/Fargateと他のAWSサービスのつなぎ方を 個別に切り出して執筆しなかった
17. • 刊行当初でさえAWSサービス数は200を超え、サービス連携の仕方は無数に存在 • サービス連携の判断は自分たちのビジネス要件次第 • ニーズに合わせて最終的には意思決定される • ECS/Fargateのサービス興隆期でもあり、見極めが難しい • 自分たちが紹介するアーキテクチャを”ベストプラクティス”と謳うには時期尚早 • ECS/Fargateベースのシステムを本番運用することを想定し、価値提供の先として 読者のみなさまが自力で設計・構築できる状態を目指した 初版では、あえてECS/Fargateと他のAWSサービスのつなぎ方を 個別に切り出して執筆しなかった
18. あれから3年、AWS上におけるコンテナ活用が広がり、 要件に合わせた最適な組み合わせ方が確立されてきている
19. • 1日における世界中のECSタスクの起動数は3億個/日 あれから3年、AWS上におけるコンテナ活用が広がり、 要件に合わせた最適な組み合わせ方が確立されてきている
20. • 1日における世界中のECSタスクの起動数は3億個/日 • AWS上でコンテナを利用しようとしている新規ユーザーの65%がECSを選択 あれから3年、AWS上におけるコンテナ活用が広がり、 要件に合わせた最適な組み合わせ方が確立されてきている
21. • 1日における世界中のECSタスクの起動数は3億個/日 • AWS上でコンテナを利用しようとしている新規ユーザーの65%がECSを選択 • ECS/Fargateを活用したアーキテクチャ事例も多数公開されている • 事例は生きた（ビジネスとして価値を生み出す or 生み出さない）アーキテクチャの証拠 • 「外さない(無難な)」アーキテクチャデザインが見えるようになってきた • よく採用されるアーキテクチャパターンはそれなりの理由がある あれから3年、AWS上におけるコンテナ活用が広がり、 要件に合わせた最適な組み合わせ方が確立されてきている
22. つまりお伝えしたいことは... 「ECS/Fargateに関する要件に合わせた最適な アーキテクチャパターンを紹介できるフェーズになった」 ということ
23. ここで、いくつかのアーキテクチャパターンを 一緒に考えてみましょう
24. 例１）インターネット上にWebアプリケーションを公開する場合
25. 例１）インターネット上にWebアプリケーションを公開する場合
26. 要件のユースケース 1 • なるべくシンプルかつスモール 構成でアプリケーションを公開 したい • 一般的なWebアプリケーション セキュリティ対策を施したい • アクセス増に対するアプリケー ションの可用性を高めたい 例１）インターネット上にWebアプリケーションを公開する場合
27. 要件のユースケース 1 • なるべくシンプルかつスモール 構成でアプリケーションを公開 したい • 一般的なWebアプリケーション セキュリティ対策を施したい • アクセス増に対するアプリケー ションの可用性を高めたい 例１）インターネット上にWebアプリケーションを公開する場合
28. 要件のユースケース 2 • 一般的なWebアプリケーション セキュリティ対策を施したい • アクセス増に対するアプリケー ションの可用性を高めたい • グローバルからのアクセスのレ スポンスを最適化したい 例１）インターネット上にWebアプリケーションを公開する場合
29. 要件のユースケース 2 • 一般的なWebアプリケーション セキュリティ対策を施したい • アクセス増に対するアプリケー ションの可用性を高めたい • グローバルからのアクセスのレ スポンスを最適化したい 例１）インターネット上にWebアプリケーションを公開する場合
30. 要件のユースケース 3 • 一般的なWebアプリケーション セキュリティ対策を施したい • アクセス増に対するアプリケー ションの可用性を高めたい。ま た、一定数のアクセスに流量制 御を設けたい • グローバルからのアクセスのレ スポンスを最適化したい • 個別の認証・認可を実装したい 例１）インターネット上にWebアプリケーションを公開する場合
31. 要件のユースケース 3 • 一般的なWebアプリケーション セキュリティ対策を施したい • アクセス増に対するアプリケー ションの可用性を高めたい。ま た、一定数のアクセスに流量制 御を設けたい • グローバルからのアクセスのレ スポンスを最適化したい • 個別の認証・認可を実装したい 例１）インターネット上にWebアプリケーションを公開する場合
32. 例２）定期実行ジョブを構成したい場合
33. 例２）定期実行ジョブを構成したい場合
34. 例２）定期実行ジョブを構成したい場合 要件のユースケース 1 • 単発の処理を実行したい • 開発コストをかけず、 シンプルに運用したい
35. 例２）定期実行ジョブを構成したい場合 要件のユースケース 1 • 単発の処理を実行したい • 開発コストをかけず、 シンプルに運用したい
36. 例２）定期実行ジョブを構成したい場合 要件のユースケース 2 • 複数の処理を実行したい • 処理結果によって、分岐処理を 設けたい • 他のAWSサービスと連動した ジョブ処理を構成したい • リトライ処理を容易に実装した い
37. 例２）定期実行ジョブを構成したい場合 要件のユースケース 2 • 複数の処理を実行したい • 処理結果によって、分岐処理を 設けたい • 他のAWSサービスと連動した ジョブ処理を構成したい • リトライ処理を容易に実装した い
38. 例２）定期実行ジョブを構成したい場合 要件のユースケース 3 • 複数の処理を実行したい • マイクロサービスで構成された API処理を組み合わせて処理を 実行したい • リトライ処理を容易に実装した い
39. 例２）定期実行ジョブを構成したい場合 要件のユースケース 3 • 複数の処理を実行したい • マイクロサービスで構成された API処理を組み合わせて処理を 実行したい • リトライ処理を容易に実装した い
40. より良い設計を模索するために、 確立された設計パターンとその採用理由を学ぶことは価値がある
41. • 愚者は経験から学び、賢者は歴史（他者の成功と失敗）から学ぶ より良い設計を模索するために、 確立された設計パターンとその採用理由を学ぶことは価値がある
42. • 愚者は経験から学び、賢者は歴史（他者の成功と失敗）から学ぶ • アーキテクチャの設計理由をビジネス観点から言語化するのは 設計者自身の責務 より良い設計を模索するために、 確立された設計パターンとその採用理由を学ぶことは価値がある
43. Well Architected Framework再考
44. Well Architected Framework おさらい
45. クラウド上のシステム設計時における、 AWSが提供する非機能観点のアーキテクチャベストプラクティス Well Architected Framework おさらい
46. Well Architected Framework おさらい クラウド上のシステム設計時における、 AWSが提供する非機能観点のアーキテクチャベストプラクティス
47. 刊行当初における Well Architected Framework に沿った設計観点
48.  ログ・メトリクス設計  トレース設計  CI/CD設計  イメージメンテナンス運用  Bastion設計  イメージセキュリティ  レジストリセキュリティ  オーケストレータセキュリティ  コンテナセキュリティ  スケールアップ戦略  スケールアウト戦略  マルチAZ構成の考慮  障害時切り離しと復旧  システムメンテナンスの考慮  サービスクォータ  ECSタスク数とリソースサイジング  Compute Savings Plans  ECSコンテナイメージのメンテナンス  タスク稼働時間帯の調整  Fargateスポットの調整  コンテナイメージサイズの削減 刊行当初における Well Architected Framework に沿った設計観点
49. 刊行当初におけるWell Architect Frameworkに沿った設計観点  ログ・メトリクス設計  トレース設計  CI/CD設計  イメージメンテナンス運用  Bastion設計  イメージセキュリティ  レジストリセキュリティ  オーケストレータセキュリティ  コンテナセキュリティ  スケールアップ戦略  スケールアウト戦略  マルチAZ構成の考慮  障害時切り離しと復旧  システムメンテナンスの考慮  サービスクォータ  ECSタスク数とリソースサイジング  Compute Savings Plans  ECSコンテナイメージのメンテナンス  タスク稼働時間帯の調整  Fargateスポットの調整  コンテナイメージサイズの削減 刊行から3年、ECS/Fargateや関連サービスは どのように進化したのか？
50. 50 書籍刊行〜現在までのECS/Fargate主要アップデートを追ってみる
51. 時間軸 書籍刊行〜現在までのECS/Fargate主要アップデートを追ってみる
52. 時間軸 書籍刊行〜現在までのECS/Fargate主要アップデートを追ってみる 2022-11-23 : Graviton2サポート アプリケーションをarm64向けにビルドできれば、 vCPUとメモリのコストを25%程度安く利用できる
53. 時間軸 書籍刊行〜現在までのECS/Fargate主要アップデートを追ってみる 2022-11-23 : Graviton2サポート 2022-03-01 : FISがECSタスクをサポー ト FISにより、ECSクラスター、ECSタスク、 Auroraクラスターレベルでの障害注入が可能となり、 信頼性の検証がしやすくなった。
54. 時間軸 書籍刊行〜現在までのECS/Fargate主要アップデートを追ってみる 2022-11-23 : Graviton2サポート 2022-04-13 : タスクスケーリング改善 2022-11-10 : タスクのスケールイン保護 2022-03-01 : FISがECSタスクをサポー ト ECSタスクの起動が16倍高速になった。 また、ミッションクリティカルなタスクが意図せず終 了しないように制御できるようになった。
55. 時間軸 書籍刊行〜現在までのECS/Fargate主要アップデートを追ってみる 2022-11-23 : Graviton2サポート 2022-04-13 : タスクスケーリング改善 2022-11-10 : タスクのスケールイン保護 2022-11-27 : ECS Service Connectの発表 2022-03-01 : FISがECSタスクをサポー ト サービスの検出やトラフィック観測に対応した ECS間の接続構成が可能なった。
56. 時間軸 書籍刊行〜現在までのECS/Fargate主要アップデートを追ってみる 2022-11-23 : Graviton2サポート 2022-04-13 : タスクスケーリング改善 2022-11-10 : タスクのスケールイン保護 2022-11-27 : ECS Service Connectの発表 2023-11-26 : Fargateにおける 2022-03-01 : FISがECSタスクをサポー ト GuardDuty ECS runtime monitoring GuardDutyによる脅威検知がECSにも対応。 サイドカーによるセキュリティエージェント により、潜在的な問題を検出可能 （コストバランスは要検討）
57. 時間軸 書籍刊行〜現在までのECS/Fargate主要アップデートを追ってみる 2022-11-23 : Graviton2サポート 2022-04-13 : タスクスケーリング改善 2022-11-10 : タスクのスケールイン保護 2022-11-27 : ECS Service Connectの発 表 2024-07-12 : 停止タスクの 2023-11-26 : Fargateにおける 2022-03-01 : FISがECSタスクをサポー ト GuardDuty ECS runtime monitoring エラーメッセージ内容強化 タスク停止時のエラーメッセージがより具体的に なった。さらにSlack等と連携することで、トラブ ルシューティングがしやすくなる。
58. 時間軸 書籍刊行〜現在までのECS/Fargate主要アップデートを追ってみる 2022-11-23 : Graviton2サポート 2022-04-13 : タスクスケーリング改善 2022-11-10 : タスクのスケールイン保護 2022-11-27 : ECS Service Connectの発表 2024-07-12 : 停止タスクの 2024-09-07 : GravitonベースのSpot利用 2023-11-26 : Fargateにおける 2022-03-01 : FISがECSタスクをサポー ト GuardDuty ECS runtime monitoring エラーメッセージ内容強化 可用性とのバランスで折り合いがつけば、 Fargate料金を最大70%割引可能
59.  ログ・メトリクス設計  トレース設計  CI/CD設計  イメージメンテナンス運用  Bastion設計  イメージセキュリティ  レジストリセキュリティ  オーケストレータセキュリティ  コンテナセキュリティ  スケールアップ戦略  スケールアウト戦略  マルチAZ構成の考慮  障害時切り離しと復旧  システムメンテナンスの考慮  サービスクォータ  ECSタスク数とリソースサイジング  Compute Savings Plans  ECSコンテナイメージのメンテナンス  タスク稼働時間帯の調整  Fargateスポットの調整  コンテナイメージサイズの削減  Gravitonの考慮  Gravitonの考慮 刊行当初における Well Architected Framework に沿った設計観点
60. 現在におけるWell Architected Frameworkに沿った設計観点  ログ・メトリクス設計  トレース設計  CI/CD設計  イメージメンテナンス運用  Bastion設計  (追加)トラブルシューティング  イメージセキュリティ  レジストリセキュリティ  オーケストレータセキュリティ  コンテナセキュリティ  (追加) ランタイムセキュリティ  スケールアップ戦略  スケールアウト戦略  マルチAZ構成の考慮  障害時切り離しと復旧  システムメンテナンスの考慮  サービスクォータ  (追加) FISによる耐障害性の検証  ECSタスク数とリソースサイジング  Compute Savings Plans  ECSコンテナイメージのメンテナンス  タスク稼働時間帯の調整  Fargateスポットの調整  コンテナイメージサイズの削減  Gravitonの考慮  (追加)Gravitonの利用検討 ECS Execの活用 タスクのエラーメッセージ
61. 昨今のサービス新規利用停止・終了を踏まえて
62. AWSはユーザニーズに基づく価値発散から収束のフェーズに
63. 昨今では一部AWSサービスの新規利用停止と終了がアナウンス(2025/10/31時点)
64. AWS App Mesh 2026/09/30終了予定 AWS App Cost Profiler 2024/09/30終了 AWS Cloud9 2024/07/25新規受付停止 Amazon Cloud Search 2024/07/25新規受付停止 AWS CodeCommit 2024/07/25新規受付停止 AWS CodeStar 2024/07/31終了 AWS Data Pipeline 2024/07/25新規受付停止 AWS DeepComposer 2025/09/17終了予定 AWS DeepLens 2024/01/31終了 AWS DeepRacer 2025/12終了予定 Amazon Forecast 2024/07/29新規受付停止 Amazon FSx File Gateway 2024/10/28新規受付停止 Amazon Honeycode 2024/02/29終了 AWS IoT 1-Click 2024/12/16終了予定 AWS Lex V1 2025/09/30終了予定 ※V2に以降 Lookout for Equipment 2024/10/17新規受付停止 AWS OpsWorks 2024/05/26終了 Amazon QLDB 2025/07/31終了予定 AWS RoboMaker 2025/09/10終了予定 Amazon S3 Select 2024/07/25新規受付停止 Amazon SimpleDB 2024/07/25新規受付停止 AWS WAF Classic 2025/09/30終了 ※V2に以降 NICE EnginFrame 2025/09/25終了予定 AWS Snowmobile 2024/03終了 Amazon IoT Analytics 2024/07/25新規受付停止 AWS IoT Device Management Fleet Hub 2025/10/18終了予定 AWS Kinesis Data Analytics for SQL 2028/01/27終了予定 Amazon CloudWatch Evidently 2025/10/17終了予定 昨今では一部AWSサービスの新規利用停止と終了がアナウンス(2025/10/31時点)
65. AWS App Cost Profiler 2024/09/30終了 Amazon Cloud Search 2024/07/25新規受付停止 AWS CodeStar 2024/07/31終了 AWS Data Pipeline 2024/07/25新規受付停止 AWS DeepComposer 2025/09/17終了予定 AWS DeepLens 2024/01/31終了 AWS DeepRacer 2025/12終了予定 Amazon Forecast 2024/07/29新規受付停止 Amazon FSx File Gateway 2024/10/28新規受付停止 Amazon Honeycode 2024/02/29終了 AWS IoT 1-Click 2024/12/16終了予定 AWS Lex V1 2025/09/30終了予定 ※V2に以降 Lookout for Equipment 2024/10/17新規受付停止 AWS OpsWorks 2024/05/26終了 Amazon QLDB 2025/07/31終了予定 AWS RoboMaker 2025/09/10終了予定 Amazon S3 Select 2024/07/25新規受付停止 Amazon SimpleDB 2024/07/25新規受付停止 AWS WAF Classic 2025/09/30終了 ※V2に以降 NICE EnginFrame 2025/09/25終了予定 AWS Snowmobile 2024/03終了 Amazon IoT Analytics 2024/07/25新規受付停止 AWS IoT Device Management Fleet Hub 2025/10/18終了予定 AWS Kinesis Data Analytics for SQL 2028/01/27終了予定 Amazon CloudWatch Evidently 2025/10/17終了予定 AWSコンテナ本含め、ECS/Fargate関連システムで影響があるサービス AWS App Mesh 2026/09/30終了予定 AWS Cloud9 2024/07/25新規受付停止 AWS CodeCommit 2024/07/25新規受付停止
66. もともと、ECS間のサービス接続方式は4種類存在
67. ALBによる接続 ECS Service Discoveryによる接続 AWS App Meshによる接続 ECS Service Connectによる接続 もともと、ECS間のサービス接続方式は4種類存在 ・B/Gデプロイや追加メトリクスの取得 ・追加のALBコストとリソース管理 ・シンプルな構成 ・トラフィックのメトリクスなし ・トラフィック制御、mTLS通信 ・構成管理が複雑になりがち ・シンプルかつ追加メトリクスの取得 ・サイドカー注入による追加コスト
68. ALBによる接続 ECS Service Discoveryによる接続 AWS App Meshによる接続 ECS Service Connectによる接続 ・B/Gデプロイや追加メトリクスの取得 ・追加のALBコストとリソース管理 ・シンプルな構成 ・トラフィックのメトリクスなし ・トラフィック制御、mTLS通信 ・構成管理が複雑になりがち ・シンプルかつ追加メトリクスの取得 ・サイドカー注入による追加コスト 2026年9月30日にサービス終了予定 AWS App Mesh終了により、ECSタスク間の接続方法は今後3種類となる
69. AWS Cloud9の新規受付停止により、諸々の開発作業環境の移行が必要に
70. AWS Cloud9の新規受付停止により、諸々の開発作業環境の移行が必要に ここ
71. 一部のユーザーにおいては、書籍内のハンズオンが手順どおり実行できなくなってしまう AWS Cloud9の新規受付停止により、諸々の開発作業環境の移行が必要に
72. 代替としてのCloudShellは有力候補だが、各種制約に気をつける必要あり
73. • 永続ストレージの容量が1GBしかない • 120日利用がないと削除される • サイズの引き上げが不可 • VPC環境で起動すると、そもそも永続ストレージがない • 毎月の使用量クォーター(200時間/月)が存在する • 場合によってはクォーター引き上げが必要 • 20-30分操作しないとシェルセッションが終了する 代替としてのCloudShellは有力候補だが、各種制約に気をつける必要あり
74. 新規ユーザーはCodeCommitが利用できない
75. 新規ユーザーはCodeCommitが利用できない
76. 2024年７月25日 新規利用の受付停止 新規ユーザーはCodeCommitが利用できない
77. 代替として、まずはGitHubをリポジトリとしてCI/CDパイプラインを検討
78. 代替として、まずはGitHubをリポジトリとしてCI/CDパイプラインを検討
79. まとめ
80. 時間軸 まとめ 2024年 10月 どのような AWSアーキテクチャを主軸にしながら 改めて読者のみなさまに価値を届けるか？ 2021年 10月
81. 時間軸 まとめ（３つの観点から考察） 2024年 10月 ECS/Fargateをとりまく アーキテクチャデザイン Well-Architected Framework再考 サービス新規利用停止と 終了を踏まえて 2021年 10月 先人が築いた良質な設計を理解す ることで、設計の最適解を模索 日々のアップデートとW-A軸を 照らし合わせることで、 より網羅的な設計を探索 潮流にあわせて、自分たちの アーキテクチャを持続可能なもの にしていく必要
82. 時間軸 まとめ（出版当初のアーキテクチャ） 2024年 10月 2021年 10月
83. 時間軸 まとめ（現在のアーキテクチャ） 2024年 10月 2021年 10月
84. さいごに
85. AWSコンテナ本出版から3 年経った今、もし改めて執 筆し直すなら…
86. AWSコンテナ本出版から3 年経った今、もし改めて執 筆し直すなら…します！ 出版社さま(SB Creativeさま)側の企画は承認済み。 2025年度の出版を目標に、皆さまに新たな価値を 届けるべく、鋭意改訂版を執筆中です！ Stay tuned! ほぼ全刷新
87. ご清聴ありがとうございました。