レバテック、オウンドメディア「レバテックLAB」のWordPressをEC2/AuroraからECS/TiDBへ。段階的検証で約2時間のメンテナンス内に移行し、CPU・メモリは約半分に

レバテックLABはレバテックのオウンドメディアで、EC2上のWordPressとAurora 2系（MySQL 5.7互換）という構成で運用されていた。この環境にはいくつかの課題があった。まずメモリ逼迫が常態化しており、手動でのスケールや復旧作業が必要だった。記事がバズった際にはPVが急増するが、その変動に対応するのが難しかった。さらにライブラリなどのシステムメンテナンスコストがかかっていたうえ、MySQL 5.7互換のAuroraはサポートコストの増加も避けられない状況だった。これらを解決するため、Fargate上でNginxとphp-fpmのコンテナを動かすECS、データベースにTiDB Cloud Serverless、ファイル共有にEFSを使う構成への移行を決めた。ECSとTiDBはどちらも自動でスケールするため、手動運用とPV急増の両方の課題に対応できる。

移行は、変更点を一度に混ぜない段階的な検証を軸に進められた。

• 1段階目: EC2→ECSへの移行（ソースコード・DBは変更なし）
• 2段階目: Aurora→TiDBへの移行
• 3段階目: PHPのバージョンアップ（6系→8系）
• 4段階目: プラグインの最新化
• 各段階で運用チームの受け入れテストを実施。検証環境と本番環境の差異が見つかったため、テスト用のサブドメインを新規作成して本番同等の環境で確認した

本番移行はメンテナンス時間を設けて実施した。

• 13:00 メンテナンスモード開始、13:03〜13:10 SRE作業、13:12 切り替え
• 14:35 運用側の動作確認完了、14:55 メンテナンス終了
• 100分経過時点で問題があれば切り戻す計画を用意

WordPress管理画面のタイムゾーンがAsia/Tokyo、TiDBがUTCで9時間ずれる問題は、PHPサーバーのタイムゾーンをAsia/Tokyoに設定して解消した。

本番同等の環境を用意した段階的な検証が功を奏し、移行はトラブルなく完了した。

• CPU・メモリは元の状態から半分くらい減少した値で落ち着いた
• ECSもTiDBも自動でスケールするため、運用コストが下がった
• EFS利用によるI/O遅延でページのパフォーマンスが低下したが、OPCacheの導入で画面操作が12〜15秒から2〜4秒に改善した

一方、SFTPでのファイル転送が手動、OPCacheのクリアが自動化されていないなど、ECSのCDには改善余地が残っている。今後はCI/CDのさらなる整備と、同様の構成を持つレバテックLAB以外のWordPressシステムの統合管理化を予定している。