14日で消える_ECS_Managed_Instancesのストレージ戦略

Transcript

1. 2025/11/07   JAWS-UG コンテナ⽀部 ×ストレージ⽀部コラボ会 クラスメソッド株式会社 浅野 晴輝 14⽇で消える！ECS Managed Instancesのストレージ戦略
2. ⾃⼰紹介 2 • 最近やっていること ◦ CDK ◦ ガイドライン設定⽀援 ◦ AWS環境構築⽀援など • 好き‧興味のある技術 ◦ コンテナ ◦ サーバーレス ◦ アプリ開発(Python, TypeScript) • 技術ブログ記載してます！ • 名前（ニックネーム） ◦ 浅野 晴輝 • 所属 ◦ クラスメソッド株式会社 ◦ クラウド事業本部コンサルティング部 • 趣味 ◦ 旅⾏ ◦ ⾳楽活動(ドラム) ◦ 映画鑑賞など
3. ECS Managed Instancesとは？
4. ECS Managed Instancesとは？ 4 2025年9⽉30⽇に⼀般提供開始 🎉 • on Fargate, on EC2に続く新しいECS コンピューティングオプション • Bottlerocket OSベース(AWS管理)のEC2インスタンス ◦ SSH/SSM等を⽤いてのアクセス不可 (ECS Exec 可) ◦ AMI選択不可 ◦ ユーザーデータ設定不可(起動テンプレートの編集不可) • セキュリティパッチ等適⽤のため最⼤14⽇間のサイクルでManaged Instance Drainingによってインスタンス&タスクが交換される ◦ EC2 イベントウィンドウにてスケジュール調整可 • スポットインスタンス未対応、RI/SPは対応 • Service Connect未対応 • コストに関して「ECS on EC2 の料⾦体系 + AWS側の管理費⽤」 「コンピューティング条件柔軟に決めたいけどインスタンス管理⾯倒だなぁ」 と思っているあなたにオススメ！
5. 最⼤14⽇間のライフサイクルについて • ECS Managed Instance Draining(2024/01リリース)の機能にてグレースフルシャットダウンでタスクとインスタンスを切り替え • EventBridge でDrainingのタイミングでイベント検知可能 ECS Managed Instancesとは？ 5 公式ドキュメント引用 21 日目までにドレインが完了しない場合、Amazon ECS はDeregisterContainerInstanceAPI を実行してマネージドコンテナ インスタンスと残りのワークロードを停止し、コンプライアンスを維持し、マネージドインスタンスに最新のソフトウェアを適用します。 アタッチされている ストレージ関係ってどうなるの？
6. イベントウィンドウで曜⽇や時間帯を指定可能 AWS側が紐づいているイベントウィンドウに対して設定を考慮して Drainを開始します(最⼤14⽇間)。 ECS Managed Instancesとは？ 6
7. インスタンスタイプについて 「ECSクラスター」作成時にキャパシティプロバイダーによって起動インスタンスタイプの選択が柔軟に可能です！ ECS Managed Instancesとは？ 7 条件に⼀致したインスタンスタイプ⼀覧が表⽰ この中からタスク定義に記載した容量とコスト最適化を考慮 して⾃動でインスタンスタイプが選定されます
8. 【起動したインスタンス】 ‧インスタンスタイプ: 「c7i-flex.large」 ‧vCPU: 2コア ‧メモリ: 4GiB ECS Managed Instancesとは？ ECS Managed Instanceを⽤いて以下の条件でタスクを起動してみると‧‧‧ 8 【キャパシティプロバイダー】 ‧インスタンス選択を⾃動で⾏わせる ように指定 【タスク定義でのスペック指定】 ‧CPU: 0.25コア ‧メモリ: 512MB タスク定義で設定したCPUとメモリの⽐率に合わせて、でき るだけ多くのタスクを格納でき、かつコスト効率が良いイン スタンスタイプが選定されていそうでした
9. ストレージについて 1インスタンス、1タスク起動でなんとEBSが３つもアタッチされていました。なんだこれは‧‧‧ ECS Managed Instancesとは？ 9
10. 3つのEBSについて
11. 3つのEBSについて 11 ①インスタンスストレージ キャパシティプロバイダーで容量(GiB)を指定できるインスタンス内のタスク全体共有ストレージ • インスタンス上の全タスクでシステムファイル(/etc/hosts, /etc/hostname等)に⾃動マウントされる • Pullしてきたコンテナイメージの保存領域でもある → タスク2回⽬以降の起動速度UP • 最⼤14⽇間のサイクルでデータ消失 → deleteOnTermination : true 固定 • EBSのボリュームタイプ(gp3), IOPS, スループットは⾃動設定 項目 値 最小サイズ 30GiB 最大サイズ 16,384GiB デフォルト 80GiB
12. 3つのEBSについて 12 CDK L2コンストラクトclass ManagedInstancesCapacityProvider を⽤いた実装例
13. 3つのEBSについて 13 ②タスク専⽤ストレージ サービス作成/更新時 or スタンドアロンタスク起動時ににストレージ設定を⾏い、タスク定義内でバイン ドマウントを指定することで使⽤可能になるタスク毎のボリュームストレージ • マウントは任意で必須ではない • インフラストラクチャロールに適切なポリシーが必要 ◦ マネージドポリシー「AmazonECSInfrastructureRolePolicyForVolumes」 • ECSの起動形式 によって揮発性が変わる ◦ スタンドアロンタスク → deleteOnTermination : true or false 設定可能 ◦ サービス内タスク  → deleteOnTermination : true 固定 • ストレージ設定時にスナップショットからのデータ復元可能 • EBSのボリュームタイプ(gp3),サイズ, IOPS, スループット, 暗号化は柔軟に設定可能 • タスク定義とサービス定義でのボリューム名称を合わせることに注意
14. 3つのEBSについて 14 CDK L2コンストラクトを⽤いた実装例 • class ServiceManagedVolume
15. 3つのEBSについて 15 • class Ec2TaskDefinition
16. 3つのEBSについて 16 • class Ec2Service
17. 3つのEBSについて 17 ③OS⽤ルートボリューム Bottlerocket⽤OSボリューム(AWS管理) • ECS on EC2の場合は①インスタンスボリュームと③OS⽤ルートボリュームが同⼀のEBSで管理されていた • 14⽇間のライフサイクルにおけるOSレベルセキュリティパッチ等の運⽤を考慮してマネージドインスタンスでは 分離されている • EBSのボリュームタイプ(gp3),サイズ, IOPS, スループット, 暗号化等は⾃動設定 • スナップショットが⾃動で作成(AWS管理) • マネージドインスタンスタスク内から読み取り専⽤(イミュータブル)としてマウントされている
18. 3つのEBSについて 18 それぞれのストレージがECSタスク内でどのように確認できるか # df -h Filesystem Size Used Avail Use% Mounted on overlay 30G 754M 28G 3% / tmpfs 64M 4.0K 64M 1% /dev shm 1.9G 0 1.9G 0% /dev/shm /dev/nvme3n1 20G 24K 20G 1% /ebs /dev/nvme1n1 30G 754M 28G 3% /etc/hosts /dev/root 984M 984M 0 100% /managed-agents/execute-command/amazon-ssm-agent /dev/nvme0n1p8 2.9G 288M 2.6G 10% /managed-agents/execute-command/certs tmpfs 1.9G 0 1.9G 0% /proc/acpi tmpfs 1.9G 0 1.9G 0% /sys/firmware tmpfs 1.9G 0 1.9G 0% /proc/scsi # # # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS nvme0n1 259:0 0 8G 0 disk ├─nvme0n1p1 259:3 0 4M 0 part ├─nvme0n1p2 259:4 0 10M 0 part ├─nvme0n1p3 259:5 0 200M 0 part ├─nvme0n1p4 259:6 0 4.5G 0 part ├─nvme0n1p5 259:7 0 50M 0 part ├─nvme0n1p6 259:8 0 140M 0 part ├─nvme0n1p7 259:9 0 113M 0 part └─nvme0n1p8 259:10 0 3G 0 part /managed-agents/execute-command/configuration /managed-agents/execute-command/certs nvme2n1 259:1 0 46.6G 0 disk nvme1n1 259:2 0 30G 0 disk /etc/hostname /etc/resolv.conf /etc/hosts nvme3n1 259:11 0 20G 0 disk /ebs ルートボリューム デバイスとマウントの関係表⽰ インスタンスストレージ タスク専⽤ストレージ マウントされているファイルシステムの使⽤量確認
19. EFSについて
20. EFSについて 20 以下両⽅の形式で使⽤可能でした。 • 直接マウント⽅式 • アクセスポイント経由でのマウント⽅式 (推奨) 公式ドキュメントもEFS全体へのアクセスを防ぎ、最⼩権限かつ特定 ディレクトリのみできめ細かな制御ができることから 「アクセスポイント」経由でのマウントが推奨されています。
21. EFSについて 21 それぞれの設定がECSタスク内でどのように確認できるか # df -h Filesystem Size Used Avail Use% Mounted on overlay 30G 714M 28G 3% / tmpfs 64M 0 64M 0% /dev shm 1.9G 0 1.9G 0% /dev/shm /dev/nvme3n1 20G 24K 20G 1% /ebs 127.0.0.1:/ 8.0E 0 8.0E 0% /mnt/efs-direct 127.0.0.1:/ 8.0E 0 8.0E 0% /mnt/efs-ap /dev/nvme1n1 30G 714M 28G 3% /etc/hosts /dev/root 984M 984M 0 100% /managed-agents/execute-command/amazon-ssm-agent /dev/nvme0n1p8 2.9G 349M 2.6G 12% /managed-agents/execute-command/certs tmpfs 1.9G 0 1.9G 0% /proc/acpi tmpfs 1.9G 0 1.9G 0% /sys/firmware tmpfs 1.9G 0 1.9G 0% /proc/scsi
22. インスタンスストアは使⽤可能か？
23. インスタンスストアは使⽤可能か？ 23 キャパシティープロバイダーでインスタンスタイプを※1「c5d.large」に固定してデプロイしてみた‧‧ コンテナ内部に⼊ってマウント状況を確認すると 
 ※1 : 50GB NVMe SSD 搭載インスタンスタイプ 
 # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS nvme1n1 259:0 0 10G 0 disk /etc/hostname /etc/resolv.conf /etc/hosts nvme0n1 259:1 0 8G 0 disk ├─nvme0n1p1 259:2 0 4M 0 part . . .   //省略 nvme2n1 259:10 0 46.6G 0 disk nvme3n1 259:11 0 20G 0 disk /ebs # df -h Filesystem Size Used Avail Use% Mounted on overlay 9.8G 709M 8.6G 8% / /dev/nvme3n1 20G 24K 20G 1% /ebs /dev/nvme1n1 9.8G 709M 8.6G 8% /etc/hosts インスタンスストアは存在する マウントはされていない
24. ⾊々調査した結果‧‧‧コンテナにマウントすることは不可能です！ 正しいマウントの流れ 現状、Bottlerocketは⾃動的にインスタンスストアのファイルシステムを構成してくれません。 よってユーザーデータやインスタンス内で直接コマンドを叩いてファイルシステムを設定し、それをコンテナ側でマ ウントする必要があります(ECS on EC2ならそれが可能) → しかし、ECS Managed Instances はユーザーデータを含めSSH等でのインスタンスへの直接アクセスが禁⽌されて いる 結論 : インスタンスストアは現状使⽤出来なさそう インスタンスストアは使⽤可能か？ 24 1. ホスト側でデバイスをマウント $ mount /dev/nvme2n1 /host-mount-point 2. Dockerコンテナ起動時にbind mount $ docker run -v /host-mount-point:/container-path 3. コンテナからアクセス可能 $ ls /container-path ← ここがManaged Instancesの場合出来ない
25. まとめ 25 ECS Managed Instancesにおけるストレージについてまとめ ストレージ 用途 ライフサイクル 備考 インスタンスストレージ (EBS) コンテナイメージ保存 複数タスク間の一時共有データ システムファイル インスタンスと同じ 最大14日で消失 タスク専用ストレージ (EBS) 一時的なタスク固有処理データ タスクと同じ 任意で使用可能 タスク終了で即削除 ルートボリューム(EBS) Bottlerocket OS用（ユーザー利用不可） インスタンス更新時に自 動更新 read-only EFS 複数タスク間の永続的な共有データ 独立・永続的 アクセスポイント推奨 インスタンスストア 利用不可 インスタンスと同じ 仕様を理解して適切なストレージ戦略を選択しましょう！