スポットでとあるスタートアップで約1年間AWS上で運用されているLaravelアプリケーションのインフラをスケールできるよう改善して欲しいという依頼をされたので見てみることに。
これが中々どうして手強いのものでした。
その会社さんはエンジニアリソースが限られており、インフラに明るいエンジニアがいないのでIaCやコンテナ運用は厳しいという前提があることを頭に入れて頂いた上で読み進めて頂けると幸いです。
結構ざっくり書いてあるので所々抜けている記述があると思いますが備忘録なので許してください...
WordPressを生業としていたCTOの方がインフラを作られたという情報を念頭に置いた上でAWSのコンソール画面で見てみることに。そこにはデフォルトVPC上のパブリックサブネットにEC2がポツンと1台立たずんでいるだけでした。
Laravelアプリケーションを運用しているならS3やRDSはないのか...？
と疑問に思い、作成したご本人であるCTOに聞いてみましたがそもそもS3やRDSは知らないとのこと。では画像やMySQLのデータはどこに保存しているのですか？と聞いてみたらEBSに全て突っ込んでいるという解答を頂きました。バックアップは一切取得していないそうです。EBS消失したらどうするんだろう。
また、AWS操作のログを知りたくなったのでCloudtrailで操作ログを見てみたらルートアカウントで操作されていました。IAM...
さて、コンソールからではEC2インスタンス内に何が入っているか分からないのでSSH接続して入ってみました。するとなぜか事前に共有されていた情報とは違い
合計6つのLaravelアプリケーションが1台のEC2上に相乗りしていました
DBに至ってはEC2インスタンス内のMySQLになぜか10個くらいDBが入っていました(正確には数えていません)。
ヒアリングの結果、サービスの歴史的経緯から本体のLaravelアプリケーションの亜種が5つ相乗りしており、EC2に来たリクエストをapacheで振り分けていました。経験未熟な自分はこの現実を見てゴールが何か分からなくなりました。しかし正体不明の野良バッチなどがなかったのは不幸中の幸いと言うべきでしょうか。
混乱しても仕方がないので、状況を整理してどうして欲しいのかを話し合いました。 決まったのは、
というものでした。正直インフラ(AWS?)の基礎知識をもった人がいなかったので、誘導尋問っぽくなった感は否めませんが、自分の中ではベストな提案をできたと思っています。
まず実験できる環境が必要だと判断し、ステージング環境を作ることにしました。VPCからサブネット・セキュリティグループ・ルートテーブルなど一式作る必要があったので若干時間がかかりました。本番環境で稼働しているEC2からAMIを作成し、ステージング環境のVPC上で作成したAMIからEC2を起動して実験しました。AMIを作成するとき再起動しないにチェックをつけないとオリジナルのEC2が再起動してしまうので気をつけて下さい。
EC2上のMySQLを処してRDSへ移行するため、mysqldumpでデータをダンプできること・RDSへインポートできることを確認しました。レコード数が大したことなかったのでDMSは使いませんでした。
移行当日(深夜)はユーザに一切EC2にアクセスされて欲しくないので全段にELBを挟んでユーザにはELB側でメンテナンス画面を出し、自分達のIPアドレスからはEC2を含むターゲットグループにリクエストを流すという方法を取りました。
ドメインレジストラにはRoute53ではなく某国産ドメインレジストラを使っており、AレコードでEC2のElastic IPを指定していました。terraform applyで一発！という手段は取れない事が確定したので、温かみのある手動操作でAレコードを消してCNAMEでELBのDNSを入力して反映を待ちます。ELBのIPアドレスは可変なのでちゃんとDNSを指定しましょう！
メンテナンス画面が表示される事を確認出来たところで
.env内のDBに関する環境変数をRDSの値に書き換えという感じの流れで行いました。記憶を掘り起こして書いてるので間違ってるかもです。
本番環境を操作するのは神経をすり減らしますね。また、自分のようなインフラに明るくないエンジニアが移行作業を完遂できたのはELBあってこそだなと痛感しました。ELBマジ感謝。
お察しの通りまだアプリケーションの構成としてはELB, EC2, RDSの構成になっており、EC2のMAZ対応が出来ていないのでこの後はElastic Beanstalkへの移行というミッションが控えています。頑張ります！