株式会社LITALICOでWebエンジニア（Rails/React/ECSなど）を担当しています、@koheiyamaguchi0203です。
この記事は『LITALICO Engineers Advent Calendar 2020』1日目の記事です。
初めに
今年の7月~10月に私達が運営するサービスのインフラ部分をAWS Elastic Beanstalk(以下EB)からAWS ECS(以下ECS)へ移行しました。
移行する決断を下してから実際に移行しきるまでの道のりを書いていこうと思います。
目次
| タイトル |
|---|
| どうして切り替える必要があったのか |
| ECSを採用した理由 |
| 切り替えるためにやったこと |
| 移行を終えてみて |
どうして切り替える必要があったのか
主な理由は以下のとおりです。
- EBのデプロイが遅すぎる。しかも、改善のしようがない。
- Rubyなどのバージョンアップデートができない。
- OS周りの管理を減らしたい。
１つ目の「EBのデプロイが遅すぎる。しかも、改善のしようがない。」について。
EBでは eb deploy というコマンドを使ってデプロイをしていました。
このコマンド１つでEBのデプロイは終わります。
しかし、このコマンドに掛かる時間が年々増えていき、リリース当初1は11分ほどだったものが、切り替える前には22分になりました。
私たちのチームは毎日10回ぐらいデプロイしているので、デプロイ時間は短いほど助かります。
次に２つ目の「Rubyなどのバージョンアップデートができない。」について。
私たちのチーム状況/EB特有のやりづらさによってRubyのバージョンアップデートがリリース当初からできていませんでした(もちろん、EBを使っていてもバージョンアップデートはできます)。
このことから、Rubyを始めとするソフトウェアをもっと手軽に管理できないだろうか？と考えていました。
最後に3つ目の「OSレイヤーの管理を減らしたい。」について。
EBはEC2を使ってアプリケーションを提供します。
そうなると、仮想サーバのメンテナンスタスクが定期的に発生します。
それをこなしていくのはチームにとって負担が大きかったです。
なので、できる限り仮想サーバを意識しない設計にしたいと考えていました。
ECSを採用した理由
理由は以下のとおりです。
- デプロイを早くできる。
- ソフトウェアの管理コストを下げられる。
- 仮想サーバを意識しない。
- 隣の事業部で採用事例があった。
- 私が使ってみたかった。
上３つはEBを使うことで辛かった点を克服するという観点です。
ここでは、下２つについてを説明します。
まず、１つ目の「隣の事業部で採用事例があった。」について。
当時4つあるサービスのうち2つでECSを採用していました。
であれば、そこの人たちにわからないことを質問できるだろうと思っていました。
あと、社内でできる限り同じ技術が使われている方が後々良いことがあるだろうとも思っています。
２つ目の「私が使ってみたかった。」について。
とても重要です。使ってみたい技術をプロダクションで試せる、素晴らしいことだと思います。
もちろん、それだけで採用するなんてことはありませんが、事業部のためにメリットがある。
その上で自分が使ってみたい技術を導入できるのは素晴らしいことだと思います。
移行を終えてみて
移行を終えて、以下の成果を出すことができました。
他にも細かいことはあるのですが、割愛します。
- デプロイ時間75%削減
- Rubyのバージョンアップデートをこの2ヶ月弱で4回行うことができた
他にもいくつか事業部、開発チームにとって嬉しい成果を上げることができました。
その中でも上２つの成果は開発チームの生産性を大きく向上するものです。
私のスキルも相当向上しました。
このプロジェクトをやる前からインフラの学習を続けたり、コンテナ技術とは何なのか？を調べたり。
その学習でも補えなかったことを周りの社員に聞きながら、プロジェクトを進めました。
その中で学べたことも多かったので、次のセクションではそれらについて書いていきます。
やったこと/学んだこと
やったことは以下です。
- Web部分をECSに切り替える
- Worker部分をECSに切り替える
- 監視/オートスケールなどを導入する
やったことを詳しく書いてもたいして面白くないので、学んだことを主に書きます。
プロジェクトを進めるために必要なこと
色々ありますが、中でも重要なのは3つです。
- 責任感
- 設定力
- 分解力
１つ目の責任感について。
当然のことなんですけど、プロジェクト推進者が責任を持ってプロジェクトを進めるために行動あるいは思考しなければプロジェクトは着地しません。
当然ですけど、そんなことも分かってなかったです。
2つ目の設定力について。
これも当然のことなんですけど、プロジェクトの目的、マイルストーン、TODOを設定しないと何も進みません。
プロジェクトの規模が大きければ大きいほど進みません。
それを設定できれば、あとは進めながら修正するだけです。
それが難しいのですが、、、。
最後に３つ目の分解力について。
これも当然のことなんですけど、プロジェクトの目的を設定したあとのマイルストーン、TODO設定では上から下へ論理的に分解して力が必要です。
これは分かっていたつもりでしたが、そんなことなかったです。
精進します。
当然のことしか書いてませんが、当然のことができないことがわかり、プロジェクトを進める中で学べたことは良かったです。
コンテナ技術の基本のキ
コンテナとは一体何なのかを完全に理解しました。
これからも何年かはコンテナ技術の躍進は続くと思うので、これを機にキャッチアップできてよかったです。
やはり実戦配備にまさる勉強方法はないと思いました。
インフラ構築経験
0からインフラ構築したわけではありません。
ですが、0からでも構築できるぐらいにはなったんじゃないか？と思っています。
0からインフラ構築ができれば、とりあえずサービスを世に出せる(もちろん他にもやらないといけないことはたくさんありますが)ので、とても良い経験をしたと思っています。
最後に
この記事はここで終わりです。これからも精進します。
明日は @i-k さんのCodePipelineでCI/CDパイプラインを組もうとして苦労した話です。
注釈
-
サービスリリースは2018年3月です。 ↩