EC2からECSへ サービスを止めずに移す
Status / 状況 完了
不動産ポータルサイトの基盤をEC2からECSへ移行しました。手作業だったOSの更新とスケーリングを自動にし、問題が起きたときに元に戻せるデプロイに変えています。
- 業界
- 不動産
- 期間
- 2024年（3か月）
- 役割
- プロジェクト管理 / インフラ設計 / 移行計画 / 実装 / 運用改善
これまで 手作業で更新するEC2 手作業で更新するEC2
からこれから 自動で入れ替わるECS
30 分
5 分
-
担当者
ソースを変更する （完了）
ビルド・テスト・デプロイが自動で進む
-
自動
ビルドとテスト （完了）
同じコンテナイメージをすべての環境で使う
-
人
承認する （完了）
本番に反映する前に必要
-
自動
デプロイする （完了）
新しいタスクの正常を確認してから古いタスクを止める
概要
これまで
EC2で動くサービスでは、担当者がOSの更新とセキュリティパッチの適用を手作業で進めていました。この作業に毎月数十時間かかっていました。運用は特定の担当者に頼っていて、その担当者がいないと対応が難しい状態でした。リリースは手作業によるファイルアップロード方式だったため、操作ミスによるサービス停止のリスクを抱えていました。
これから
CodeCiaoは基盤をECSに移し、すべての環境で同じコンテナイメージを使うようにしました。担当者がソースを変更すると、ビルド・テスト・デプロイが自動で進みます。
コンテナイメージの脆弱性と設定の誤りは、リリースの前に自動で検査します。本番に反映する前には、人の承認が必要です。
- デプロイにかかる時間は、30分から5分に短くなりました
- 運用の作業は、月に約40時間減りました
- アクセスが集中したときは、自動のスケーリングで対応します
進め方
-
サービスを止めずに入れ替える
通常の更新では、新しいタスクが起動して正常だと確認できてから、古いタスクを止めます。大きな更新では、新旧のタスクを並べて動かし、安定を確かめてから切り替えます。問題が起きた場合は、すぐに元の状態へ戻せます。
-
小さく試してから段階的に移す
CodeCiaoはまず小さな検証環境で、動作・デプロイの方式・ヘルスチェックの設定を確かめました。次に社内向けの環境で並行して動かし、設定を調整してから本番を切り替えました。
-
移行の影響を文書にする
移行で変わる点と、利用者に知らせる内容を文書にまとめました。その文書をもとに、営業部門と一緒に周知の計画を立てました。