こんにちは！最近自作キーボードの沼に足を滑らせました、Cake.jp CTOの @ar_tamaです。

というわけで、ビフォーアフターをご紹介します！

移行前の環境

私が入社したタイミングでは、まだClassic EC2に"Classic"が付く前の時代にEC2＋Beanstalkで立ち上げた環境をなだめすかして動かしている状況でした。つまりVPCの外で動いていたのです。
（ちなみに相談先からは「えっVPCがなかった時代とかあるんですか」とか言われました。これもインターネット老人会事案だったか…）
既にClassic環境は2022年8月に廃止されることがアナウンスされていたので、いっちょ本気出して移行するか〜となったわけです。

移行後の環境

Beanstalk環境をVPC内で新しく立ち上げるには、諸般の事情で芋づる式に対応すべき事柄が増える見込みだったこと、コンテナ化できたほうがコストも下がることがわかっていたので、ECS Fargateを移行先に決めました。
RDSもこのタイミングで新しく作り直し、ついでにバージョンアップもしつつ、dump, importして移行することにしました。盛りだくさんですね。

移行手順

フルタイムではない業務委託メンバーの力を借りながらの進行だったため、下準備に1ヶ月、本構築・移行に1ヶ月、というスケジュールで進めることにしました。

既存開発環境のコンテナ化≒環境変数の整理

開発環境のコンテナ化自体は既に済んでいたのですが、微妙にローカルに依存している部分などもあったので、まずは環境変数さえ入れ替えればどの環境としても動くように足回りのリファクタを行いました。

PHPのconfig fileにいろいろ定義されていたのをメリメリと剥がし環境変数化（ローカルでは.env fileに定義）していくのですが、既存のコードが様々な手法で環境依存のコードを埋め込んでいたので、それを洗い出し外に出していく過程が一番地味かつ大変でしたね……。
とはいえ、これがコードベースのリファクタにもなり、開発者生産性の向上にも一歩繋がりました。

このタイミングで一旦リリースをし、手戻りがない状態でコンテナ化へと歩を進めます。

ネットワーク、コンテナ、デプロイパイプラインの構築

既存のVPC環境に使い回せるものがなかったので、新規にルール決めから行いました。CFnでテンプレート化して、いつでも新しい環境セットを生やせるようにしています。

前のステップで整理した環境変数は、デプロイ先での定義場所をSecrets Managerに移し、各環境用のタスク定義に対応キーを設定した上で、Dockerfileで取得・注入するようにしました。

CDはCodePipeline + CodeBuild + CodeDeployを用いて

• メインブランチへのマージをきっかけにビルド開始、ステージング環境にデプロイ

• Approvalを待って本番環境にB/Gデプロイ

が行われるようにしました。モダンですね！

コンテナ／DBの構築・動作テスト

開発環境相当の環境変数を注入したコンテナを立ち上げ、旧開発環境と挙動に差分がないことを確認します。

メンテナンス入れ・各所の切り替え

今回はRDSとアプリケーションの移行を同時に行ったため、こんなステップを踏みました。

• アプリケーションをメンテナンスモードにし、DB書き込みを停止

• 旧DBのDumpを取り、停止し、予め用意していた新しい箱にimport

• 新アプリケーションをデプロイし、DNSを旧→新に切り替え

• DBに依存している他アプリケーションの向き先を変更

• 動作確認が完了したらメンテナンスモードを終了

これを何度か繰り返し、めでたく全環境のモダナイズ＋コスト削減が叶ったのでした🥳🎊

おわりに

すったもんだありましたが、なんとかモダンかつ実用的な作りへの軌道修正が行えました。またKotlinへの移行も粛々と進んでおり、更に楽しく安全に開発できる環境が整いつつあると感じています。
オッちゃんとしてるやんけ、面白そうやんけと思っていただけたそこのアナタ！Meetyしませんか〜〜！

また、現在Classic環境を使っていて移行にお困りの方がいたら、それなりにご相談にも乗れると思います。お気軽にお声かけください👋