Amazon ECS & AWS Fargate 運用アーキテクチャ2025 / Amazon ECS and AWS Fargate Ops Architecture 2025

Transcript

1. Amazon ECS & AWS Fargate 運用アーキテクチャ 2025 Synspective Inc. 新井 雅也 (@msy78) AWS Summit Japan 2025 Community Stage – Day 1
2. 昨今はAWSサービスとの連携や機能が拡充される一方、 クラウドエンジニアとして、 アーキテクチャ設計・運用面で悩みを抱える方も多いのでは？
3. 昨今はAWSサービスとの連携や機能が拡充される一方、 クラウドエンジニアとして、 アーキテクチャ設計・運用面で悩みを抱える方も多いのでは？ 新規アーキテクチャの 検討時に選択肢が多くて 迷いが生じる 以前は最適だった アーキテクチャが 陳腐化しているかも？ 日々のアップデートを 継続的にキャッチアップ しきれない…
4. 本発表では非機能要件、特に運用の側面に焦点を合わせつつ、 最新のアップデートを交えつつもECS/Fargateを中心とした ベストなアーキテクチャとプラクティスを紹介します
5. 自己紹介
6. 新井 雅也 現在は衛星の開発・運用を手掛けるSynspectiveにて、クラウドを 中心とした技術力を活かしつつ、宇宙業界の発展に尽力している。 好きなAWSサービスは、Amazon ECS、AWS Fargate 好きなエナジードリンクは、Red Bull @msy78 Principal Cloud Architect 6
7. 7 本題
8. 本発表では非機能要件、特に運用の側面に焦点を合わせつつ、 最新のアップデートを交えつつもECS/Fargateを中心とした アーキテクチャとプラクティスを紹介します
9. 9 ところで、なぜ「運用」？
10. 10 システムは構築した後が勝負。安定運用は顧客への価値提供の前提条件。 u システムに関する運用とは、システムを安定させるために必要なことすべて u 障害発生における原因特定と早期復旧 u セキュリティの維持
11. 11 運用を「設計」として落とし込む u 日々求められるシステムの運用に対して、どれだけ事前に設計に落とせるかが重要 u 想定外を減らす努力 u 設計には通常複数の選択肢が存在する u 非機能の観点はトレードオフの世界 u 主要な設計の利点・欠点を押さえておき、自分たちの要件と照らし合わせる u 日々のクラウドの進化に並走して、運用側面でもアップデートが必要 u クラウド上でシステムを運用する者としての責務
12. 12 本発表で取り上げる運用設計観点と以前のプラクティスに関連した様々な疑問
13. 13 ロギング設計 メトリクス設計 トレース設計 デバッグ設計 普通にAmazon CloudWatch Logs使えば良くない？ 昔Amazon CloudWatch Container Insights有効化したけど、他に考慮が必要？ AWSでトレース取得するならAWS X-Rayのサイドカー構成でいいのでは？ アプリ・NWそれぞれでトラブルが発生したらどうやってデバッグする？ ※上記は運用側面で検討すべき項目の一例。CI/CD設計やその他の運用観点は時間の都合上、省略。 本発表で取り上げる運用設計観点と以前のプラクティスに関連した様々な疑問
14. ロギング設計
15. 16 普通にAmazon CloudWatch Logs使えば良くない？ ロギング設計
16. 17 確かに、小規模な（ログ出力量が少ない）システムはAmazon CloudWatch Logsで十分 ロギング設計
17. 18 ログ出力が増えると、Amazon CloudWatch Logsのログ取り込みコストが辛くなる ロギング設計 Amazon CloudWatch Logsのログ取り込み量削減は、クラウド破産防止の重要ポイント • データ取り込み料金： USD 0.76/GB （アジアパシフィック/東京） • 例) 一日のログ出力量が50GB → 1ヶ月で1140USD ※アプリのログ出力設定ミスやログバースト出力で高額請求されがち
18. 19 FireLensを構成してAmazon CloudWatch Logs・Amazon S3でコストバランスを図る ロギング設計
19. 20 ちょっとまって！FireLens用イメージ(aws-for-fluent-bit)の意外な盲点 u Fluent Bitの最新バージョンはv4.0.3 u aws-for-fluent-bit の最新イメージで内部利用されているFluent Bitはv1.9.10 u v1.9.10は2022-12-05にEOL済み、v2以降の以下恩恵は現状受けられない u Prometheusフォーマットのメトリクス提供 (v2) u OpenTelemetryプロトコルによるテレメトリの送受信 (v2) u メモリリーク等のバグ修正 (v2) u YAMLによるコンフィグ定義 (v3.2) u セキュリティ関連の改善(TLSバージョンの指定) (v4) ロギング設計
20. 21 最新バージョンのFluent Bit機能が必要なら、自前でイメージ管理が必要 ロギング設計
21. 22 ごく最近(2025年6月)にfluent-bit v4.0対応がコンテナロードマップに追加 ※containers-roadmap: https://github.com/orgs/aws/projects/244/views/1 • 2025年中のv4.0.0アップグレード を目指しているとのこと (by AWS) • 喫緊で最新バージョンの利用 ニーズがなければ、待つのもあり • アップストリームは毎年バージョン アップされるが、継続追いつきがさ れていくのか現時点で不明 ※実は私もAWS HeroのSlackチャンネルで 直接コンテナチームに要望を伝達... ロギング設計
22. 23 ・小規模なシステムならAmazon CloudWatch Logsで十分 ・ログ量が増えるとコストバランスを考慮してFirelensによるS3出力を検討 ・aws-for-fluent-bitはアップストリームとのバージョン乖離に注意 ・2025年中にFluent Bit v4.0.0にアップグレードが予定されているので要ウォッチ 普通にAmazon CloudWatch Logs使えば良くない？ ロギング設計まとめ
23. メトリクス設計
24. 25 昔Amazon CloudWatch Container Insights有効化したけど、 他に考慮が必要？ メトリクス設計
25. 26 Amazon CloudWatch Container Insights with enhanced observability(o11y)の登場 u 2024-12-01にAmazon ECSのコンテナワークロードに対応 u 一部のメトリクスがコンテナレベルまで取得可能 メトリクス設計
26. 27 Amazon CloudWatch Container Insightsのタイプにおける具体的なメトリクスの違い メトリクス設計 Amazon CloudWatch Container Insightsのメトリクス
27. 28 メトリクス設計 Amazon CloudWatch Container Insights with enhanced o11yのメトリクス Amazon CloudWatch Container Insightsのタイプにおける具体的なメトリクスの違い
28. 29 実はContainer Insights with enhanced o11yのほうがメトリクス単価が割安 メトリクス設計 ※https://aws.amazon.com/jp/cloudwatch/pricing/
29. 30 Container Insights自体が高コストなので、環境毎の使い分けを考慮する余地あり メトリクス設計
30. 31 昔Amazon CloudWatch Container Insights有効化したけど、 他に考慮が必要？ メトリクス設計まとめ ・2024年12月にAmazon CloudWatch Container Insights with enhanced o11yがECSに追加 ・Amazon ECSタスク・コンテナレベルでのメトリクスが強化 ・ Container Insights自体がコスト割高なので、環境間でバランスを考慮 メトリクス設計
31. トレース設計
32. 33 AWSでトレース取得するなら AWS X-Rayのサイドカー構成でいいのでは？ トレース設計
33. 34 AWS X-Rayを利用したい場合、以前はSDKを利用しつつサイドカー構成が有効だった トレース設計
34. 35 AWS Distro for OpenTelemetry (ADOT)の登場と利用の推奨 u AWS Distro for OpenTelemetryにより、OpenTelemetry準拠で計装が可能 u サードパーティやX-Ray含む、複数にテレメトリを送信可能 u X-Ray SDKと比較して、ADOTはサポートしているランタイムが多い(Swift, Rust, PHP…) トレース設計
35. 36 トレース設計 AWS Distro for OpenTelemetry (ADOT)の登場と利用の推奨
36. 37 Fluent Bit/ADOTは常にサイドカー構成がベストというわけではない点に留意 トレース設計
37. 38 特定のAmazon ECSサービスに集約することで、ECS関連のコストバランスを図れる トレース設計
38. 39 AWSでトレース取得するなら AWS X-Rayのサイドカー構成でいいのでは？ トレース設計まとめ ・OpenTelemetryに準拠したADOTが推奨 ・AWS X-Rayだけではなく、サードパーティのo11yツールにも情報の転送が可能 ・システム規模が拡大したら、サイドカーからの切り出し構成が有効
39. デバッグ設計
40. 48 デバッグ設計 アプリ・NWそれぞれでトラブルが発生したら どうやってデバッグする？
41. 49 備えあれば憂いなし。 障害時調査に備えて事前の段取りと環境整備を把握しておこう。 デバッグ設計
42. 50 アプリケーションコンテナ環境のデバッグユースケース デバッグ設計
43. 51 アプリケーションコンテナ環境のデバッグ：ECS Execの事前検討と考慮 デバッグ設計 u 特に、操作ログ出力に対するOSパッケージ、権限、ネットワーク設定周りの考慮が必要
44. 52 ネットワークのデバッグユースケース デバッグ設計
45. 53 ネットワークのデバッグ：Reachability Analyzerの検討と考慮 デバッグ設計 u ECSタスクにアタッチされているENIを指定する必要がある点を押さえておく
46. 54 意外と役立つデバッグ用カスタムコンテナ(ECS Execとの組み合わせ) デバッグ設計 u デバッグの柔軟性は高いが、イメージの作成とメンテナンスが必要
47. デバッグ設計(生成AI編)
48. 56 生成AI活用によるデバッグでラストワンマイルまでの時間を最小化する u AWSでは、すでに様々なMCPサーバーを提供 u Amazon ECS MCP Server(ベータ版) u AWS Documentation MCP Server デバッグ設計 (生成AI編)
49. 57 生成AI活用によるデバッグでラストワンマイルまでの時間を最小化する u LLMだけでは、「事前学習済みの知識」の回答にとどまる（陳腐化の可能性） u MCPサーバー連携により、最新の情報源の参照や関連するAPI等の実行が可能 u 「問題発生→原因調査→特定→修正」リードタイムの改善が期待 デバッグ設計 (生成AI編)
50. 58 実際の机上デモで理解を深めよう
51. 59 AIアプリ・LLM・MCPサーバーを活用したAWS環境デバッグの流れ 以下のシンプルなデバッグユースケースを想定 uAmazon ECS上のフロントエンドAppからバックエンドAppに接続できない デバッグ設計 (生成AI編)
52. 60 AIアプリ・LLM・MCPサーバーを活用したAWS環境デバッグの流れ 以下の環境を想定 u AWSはIaC (Infrastructure as Code) に従ってTerraformで構築・管理 u LLMはClaude 4 Sonnetを利用 u AIアプリ(コードエディタ)としてCursorを利用 (Claude CodeやAmazon Qでも動作) u MCPサーバーとして、以下を利用 u Amazon ECS MCP Server u Amazon Documentation MCP Server u Terraform MCP Server デバッグ設計 (生成AI編)
53. 61 AIクライアント・LLM・MCPサーバーを活用したAWS環境デバッグの流れ デバッグ設計 (生成AI編)
54. 62 AIクライアント・LLM・MCPサーバーを活用したAWS環境デバッグの流れ デバッグ設計 (生成AI編)
55. 63 AIクライアント・LLM・MCPサーバーを活用したAWS環境デバッグの流れ デバッグ設計 (生成AI編)
56. 64 AIクライアント・LLM・MCPサーバーを活用したAWS環境デバッグの流れ デバッグ設計 (生成AI編)
57. 65 AIクライアント・LLM・MCPサーバーを活用したAWS環境デバッグの流れ デバッグ設計 (生成AI編)
58. 66 AIクライアント・LLM・MCPサーバーを活用したAWS環境デバッグの流れ デバッグ設計 (生成AI編)
59. 67 デバッグケースの結果 (問題の特定) 実際のCursorにおける出力結果 発生した問題 Amazon ECS上のフロントエンドAppから バックエンドAppに接続できない デバッグ設計 (生成AI編)
60. 68 デバッグケースの結果 (問題の特定) デバッグ結果 u 調査の仮定で Amazon ECS MCPツールが利用 u セキュリティグループの許可設定で ポート番号の不一致があることを特定 実際のCursorにおける出力結果 発生した問題 Amazon ECS上のフロントエンドAppから バックエンドAppに接続できない Amazon ECS MCP Serverで用意されている トラブルシューティング用ツールを利用 デバッグ設計 (生成AI編)
61. 69 デバッグケースの結果 (問題の修正) 発生した問題 Amazon ECS上のフロントエンドAppから バックエンドAppに接続できない 実際のCursorにおける出力結果 デバッグ設計 (生成AI編)
62. 70 デバッグケースの結果 (問題の修正) デバッグ結果 u バックエンドAppに適用されているセ キュリティグループのTerraform定義を 特定 u 修正用Commitを作成 発生した問題 Amazon ECS上のフロントエンドAppから バックエンドAppに接続できない 実際のCursorにおける出力結果 問題特定から修正まで約90秒で完了 デバッグ設計 (生成AI編)
63. 71 AWSデバッグ運用時におけるAmazon ECS MCP Server利用の注意点(1/2) u現時点では開発中段階であり、開発・テスト用途での利用を想定 u プロダクション環境での利用は非推奨 u機密情報の結果出力を拒否するフラグがある u 有効にするとトラブルシューティング系のツール利用が大きく制限される u デバッグ運用活用のため、設定を有効にしつつ、開発用途の利用に限定 { "status": "error", "error": "Action fetch_network_configuration is not allowed without ALLOW_SENSITIVE_DATA=true in your environment due to potential exposure of sensitive information." } デバッグ設計 (生成AI編)
64. 72 AWSデバッグ運用時におけるAmazon ECS MCP Server利用の注意点(2/2) u IaCのコード修正は許容できるが、AIツールによるクラウド上の直接的な 変更が可能な出力設定は避けたほうが良い(コスト・セキュリティ観点) u MCP Serverの書き込み操作フラグを無効化、AIツール側ルールで指示することでリスク緩和 デバッグ設計 (生成AI編)
65. 73 アプリ・NWそれぞれでトラブルが発生したら どうやってデバッグする？ デバッグ設計まとめ ・AWSデバッグのユースケース毎に適材適所なサービスが揃っている ・デバッグ用カスタムコンテナは柔軟性が高いプラクティスとして有効 ・生成AIによるトラブルシューティングのリードタイム削減の可能性
66. まとめ
67. 77 ロギング設計 メトリクス設計 トレース設計 デバッグ設計 普通にAmazon CloudWatch Logs使えば良くない？ 昔Amazon CloudWatch Container Insights有効化したけど、他に考慮が必要？ AWSでトレース取得するならAWS X-Rayのサイドカー構成でいいのでは？ アプリ・NWそれぞれでトラブルが発生したらどうやってデバッグする？ 運用設計観点における最新アーキテクチャと考慮ポイント (Before) まとめ
68. 78 ロギング設計 メトリクス設計 トレース設計 デバッグ設計 コスト次第でFirelensの利用を検討。バージョン情報は今年ウォッチ Container Insightsの各オプション特性とコストを意識した環境毎の使い分け ADOTの活用とサービス集約アーキテクチャに対する理解 ECS Exec、 Reachability Analyzer、カスタムイメージ、AIツールの活用 運用設計観点における最新アーキテクチャと考慮ポイント (After) まとめ
69. 79 少しだけ宣伝させてください。 2025年末(予定)に拙書の改訂版が出版される予定です。 ECS/Fargate解説書の決定版として、本日発表した内容 の詳細解説をすべて含む、各種アーキテクチャやハン ズオンが大幅にアップデート予定 鋭意執筆中なので、気になる方はぜひ応援お願いしま す！
70. Thank you!