trippieceでは2014年末頃からレガシーなEC2からOpsWorksに移行しています。
前提条件としてインフラ専属エンジニアが現時点で社内に存在せず、兼任であるため管理サーバーなどの監視、運用工数がほとんど、もしくは全くかからないで、管理サーバーなどを自前で立てないで済む選択肢に限っています。
かっちりとした構成管理、リソースに依存した設定を入れなくて済むのでスケールアップが自由自在、githubにプッシュするだけのお手軽デプロイオートメーションなど今までの面倒な手順や操作ミスから解放されるという、非常に当時は画期的な導入効果がありましたが約2年の運用期間を経てDocker運用のノウハウが一般的に十分蓄積され成熟してきたことと、OpsWorksやChefに関連する以下の問題が顕著になり移行を計画し始めました。
- 新規インスタンスの追加に相当時間がかかる (構成によっては20分以上) ためトラフィック急増に対応できない。
- 起動できなくなるケースが少なからずある。(Chefバージョンの過渡期で、依存しているCookbookがさらにその中で依存しているCookbookの対応バージョンが変更になってしまったり、依存しているパッケージファイルが削除されたり、一時的な障害でダウンロードに失敗するなど) また、失敗した場合に対応できるエンジニアが非常に限られる。
- 各インスタンスの実行時間に差が出てしまうのでデプロイ時の細かい制御(オーケストレーション)を入れるのに向いていない。
- 長時間実行非同期タスク(Celery Task)が走っている最中にデプロイを流してしまうとデプロイがブロックされてしまうのと、タスク終了後にCeleryプロセスがダウンしてしまう。
上記とは別に、運用上の問題としてChefレシピを弄って簡単に構成拡張ができるが故に一つのスタックに時間と共に色々詰め込んでいってしまい、結果としてモノリシックなシステムとなってしまっていました。これにより複数インスタンス間の同期処理を自前で書かなければいけなかったり、一度実行すればよいものが複数回実行しデプロイ時にパフォーマンスダウンする事象も起きていました。
作り込み次第でこれら問題が軽減できることがありますが、ここで頑張ってOpsWorksに拘るよりも上記のような問題を根本的に解決できる一つの方法であるECSへと段階的に移行することにしました。
まずは定期実行タスクのトリガーとその実行処理をモノリシックなOpsWorksから切り離し、ECSとRunDeckに置き換えます。その後のフェーズでWebやAPIその他をECSに移行する計画です。
以下は定期タスクをECSに載せ替えた場合のメリットです。
- 起動が劇的に速い
- docker imageをECR(EC2 Container Registry)にアップロードしておけば起動しなくなることはまずない
- docker imageが更新されても実行中の定期(長時間実行)タスクを終了する必要はほとんどなく、既存タスクはそのままで、新しく起動するタスクは新しいコードで動くというシームレスなデプロイが可能
- 1タスク1コンテナなのでタスクの独立性が高い
- ハードウェアリソースの管理も自動で行ってくれるためリソース利用効率が高い
その他、弊社特有のメリットとして実行スケジュールをコードではなくWebUIでいつでも変更、逐次実行ができるようになり柔軟性が格段にあがりました。
次回は具体的な定期タスクのECS移行について投稿する予定です。
投稿しました
--
trippieceではエンジニアを募集しています。
https://www.wantedly.com/projects/38518