ECSサービスで、動かし続けたいタスク数を宣言する
タスクを一度起動するだけでは、停止した瞬間にアプリは消える。サービスは「何個を正常に動かしたいか」をECSへ渡し、差分を埋め続ける仕組みだ。
TL;DR
- ECSサービスはdesired countを保つようにタスクを配置・再起動する。
- タスクが停止したとき、サービスは不足分を検知して新しいタスクを起動する。
- 学習環境の停止・起動はコストを下げる一方、稼働中サービスや依存関係への影響を確認して行う。
01サービスは「目標台数」を保つ制御役
一度起動したタスクを眺めるのではなく、望む状態との差分を見る
ECSサービスにdesired countを指定すると、ECSは実際に動いているタスク数を目標へ近づける。タスクが異常終了しても、サービス管理下なら不足分の置換を試みる。
サービスがあるからといってアプリが必ず正常とは限らない。起動できない理由とヘルスチェックの状態を確認する必要がある。
- desired countは目標の稼働数
- running countは現在の実数
- 差分が出ればECSは置換を試みる
02サービスはタスク定義の更新を展開する
新しいリビジョンを作っただけでは、稼働中のタスクは置き換わらない
新しいイメージや設定はタスク定義の新しいリビジョンに入る。サービスを更新すると、デプロイ設定に従って新しいタスクを起動し、旧タスクを段階的に入れ替える。
「新しいタスク定義がある」と「サービスが新しい版で動いている」は別の事実。稼働中リビジョンを確認する。
- 変更は新しいtask definition revisionになる
- service updateがデプロイの開始点
- 置換中はイベントとタスク状態を確認する
03停止・起動は運用手順として扱う
Cost Cutterは削減操作であり、アプリを使えなくする操作でもある
学習を終えた環境を停止すれば不要な料金を抑えられる。ただし、ECSサービスのdesired count、DBの状態、再開後の疎通を確認せずに止めると、次回の学習開始で切り分けが増える。
停止対象と停止しない対象を決め、再開手順と確認点を残してからコスト削減を行う。
- 停止前に依存するAPI・DBを確認する
- 再開後にタスク数とヘルスを確認する
- 止められないリソースの料金も別途把握する
結論
- ECSサービスはdesired countを継続して保つ。
- デプロイはタスク定義の新リビジョンをサービスへ反映する操作。
- コスト削減の停止・再開には、依存関係と復旧確認を含める。