Kohei Yasan

# プロジェクトの目的 私が担当するサービスはElasticBeanstalk(以下EB)でホストされていましたが、当時いくつか問題がありました。 - EBで管理するEC2にAmazon Linux2を入れることが相当大変であった - 当時あと3ヶ月でAmazon LinuxがEoLになると言われていたが、EBがRubyプラットフォームでAmazon Linux2に対応する気配がなかった。 - コードベースの肥大化に伴い、EBによるデプロイにとても時間がかかるようになった - Rubyのバージョンを上げるコストが高い これらの問題を解決するために、インフラ構成を見直すのが当プロジェクトの目的でした。 # 行ったこと まず、EBから切り替えるサービスを何にするか決定しました。 結果、上記の課題を解決するため、また個人的な技術的興味からAmazon ECS Fargate(以下Fargate)を使うことにしました。 Fargateを採用した理由は以下のとおりです。 - 社内のいくつかの事業部で採用実績があり、ノウハウを獲得しやすいと判断したから - 以下の点からサーバのプロビジョニングがしやすいと判断したから - 仮想サーバを管理する必要がない - Docker Imageで簡単にプロビジョニングができる - 個人的にコンテナ技術に興味があったから 次にFargateに切り替えていくためのロードマップ策定、Fargateを使ったときの構成図作成、デプロイフローの策定などを行い、実装を開始しました。 実装する中で当初の設計では解決できない点などがあったので、都度設計を修正しながら進めました。 # 得られた成果 得られた成果は以下のとおりです。 - デプロイ速度の向上 - 切り替え前は23分ほど掛かっていましたが、Fargateに切り替えてチューニングした結果、5分30秒ほどで終わるようになりました - Rubyのバージョンアップのコスト削減 - 切り替え前はRubyのバージョンアップデートに1週間ぐらい掛かるのではないかと言われていましたが、切り替え後は1日もあれば切り替え作業が終わるようになりました - インフラリソースの管理をチームでできるようにした - 今までインフラリソースはAWSのコンソール画面から手動で管理されていましたが、これを機にTerraformを導入し、誰もがTerraformファイルを見ればどのリソースを使っているのか、いつリソースに変更が加えられたのか分かるようにしました - これにより管理されないAWSリソースを減らし、安全な運用ができる土壌を作れたと思っています # その他 - プロジェクトは私と元先輩社員のアルバイトと行いました。先輩に設計や実装のアドバイスを貰いながら進めていきました。