レバテックLAB インフラ大改造！EC2/Aurora⇨ECS/TiDB に移行した話

この記事は「レバテック開発部 Advent Calendar 2024」の 22 日目の記事です！
昨日の記事は、うちさんの「CIのボトルネックを特定してJestの実行時間をチョット速くした話」でした。

はじめに

レバテック開発部でオウンドメディアおよびデザインシステムの開発を担当している本名です。

12月12日にレバテックLABのメンテナンスがありました。
https://x.com/levtech_lab/status/1867011488595968165

レバテックLABは、AWS EC2上でWordPressを稼働させてAurora2系をDBとして利用してきましたが、運用まわりで以下の対応に課題が出てきていました。

• 手動でのスケール・復旧作業
  • 冗長構成になっておらず、メモリ逼迫が常態化していました
  • 外形監視でアラートが発砲され、気づいたらサービスが落ちていたなんてことがあったり…
    • サービスの特性上、不測のタイミングで記事がバズってPV数が跳ねてこの状態になったします
• ライブラリなどシステムのメンテナンスコスト
• MySQL 5.7 互換 Aurora のサポートコスト増加^[1]

これらの課題を避けるため、ECSへの移行、およびレバテックで導入が進んでいるTiDBへの移行を実施することにしました。

移行後のインフラ構成

今回の移行後のインフラ構成は、ECS（Fargate上でNginx、php-fpmコンテナ稼働）とTiDB Cloud Serverlessを組み合わせた構成になりました。

• EC2 ⇨ ECS 移行について
  • コンテナ化によるデプロイ容易性向上のため
  • オートスケーリングによる運用コスト削減のため
• Aurora ⇨ TiDB Serverless 移行について
  • MySQL 5.7 互換 Aurora のサポートコスト増から移行する判断になった
  • TiDBを移行先としたのはレバテックで導入が進んでいるため
• EFS 導入
  • コンテナ環境でのデータ共有や障害時の復旧、バックアップ管理が容易になるため
    • これまではEC2ファイルサーバーに直接入り、ファイルアップ作業を行ったりしていた
  • 運用上のファイル変更時は、SFTPによるアップロードを想定

移行の検証

本番移行に向けては、変更による影響範囲を明確にするため、EC2 ⇨ ECS の移行、Aurora ⇨ TiDBへの移行、PHP,WPプラグインのバージョンアップ適用と段階的な検証を行いました。
ここではシステム側の動作だけでなく、運用チームが行う管理作業や運用の確認も含め、密なコミュニケーションを図りながら進めていきました。

具体的にやった段階的な移行検証

• EC2 ⇨ ECS 移行
  • まずはEC２からECSにソースやDB変更を加えずに移行して問題ないか確認を行った。
  • 受け入れテスト（開発・運用チームにて確認）
    • 公開ページ内でエラーが発生していないか
    • 管理画面にて運用上の想定操作が可能かテスト
      • 通常投稿できるか
      • 予約投稿できるか
      • 投稿記事が編集できるか
      • 記事の装飾できなくなっているものがないか
• Aurora ⇨ TiDB 移行
  • 次にAuroraからTiDBにDBの向き先を変更し、アプリケーションの動作確認を行った。
  • 受け入れテスト（前記内容と同様）
    • Wordpressアプリ側設定がAsia/TokyoでTiDBのデフォルトのタイムゾーンがUTCなので、移行データに９時間ずれが生じた。
      • TiDBのデフォルトのタイムゾーンを変更するのは既存データへの影響を考えて変更しないよう判断した。
      • これによってWP管理画面の予約投稿時間設定などサイト上の時間がUTCで表示されてしまう現状になってしまったが、PHPサーバーのタイムゾーンをAsia/Tokyoにして9時間ずれを解消させた。
• PHPバージョンアップ(6系 ⇨ 8系)
  • 受け入れテスト（前記内容と同様）
• プラグイン最新化
  • 検証・本番で差異があったため、本番に合わせるように対応しました。
  • 受け入れテスト（前記内容と同様）

以上が段階的な移行検証の全容になります。

運用チームが行う管理作業や運用の確認も含め、密なコミュニケーション

この章の冒頭で書いてましたが、段階的な移行検証の各フローそれぞれで運用チームの方々に「受け入れテスト」を実施いただいていました。
検証移行に入る事前のすり合わせでどのタイミングでどんな内容の検証確認をしてもらうようにすり合わせを行い、確認時には対面でコミュニケーションをしつつ、認識齟齬を防ぎながらスムーズに確認作業を進めていただきました。

また、検証環境と本番環境で、データベースやWordPressソースに差異が見つかりました。このため、もともとあった検証用リソースだけでのテストでは十分な確認ができませんでした。そこで、テスト用のサブドメインを新たに作成し、既存のALBを複製して、本番環境と同じ状態を再現しました。これにより、本番と同じ条件で動作を確認し、最終的なメンテナンス作業に向けた準備を整えました。

本番移行の手順

以下のように本番移行を進めました。

	作業内容	作業者
	メンテナンス対応開始
13:00~	メンテナンス対応開始連絡	開発
13:00~	メンテナンスモードを入れる 　WAFにてレバテックLABページのみ社内IP制限をかけ、外部アクセスはメンテナンスページを表示させた状態	開発
13:03~	レバテックLAB ページが全てメンテナンス状態になる
	SRE作業開始 　作業分は基本的にスクリプトを事前に準備しておく
13:03~	データ差分チェック開始	SRE
13:07~	DBのレプリケーション停止 作業開始 　一週間前からレプリケーション開始していました	SRE
13:08~	AutoIncrementリセット作業開始	SRE
13:09~	テーブル定義修正	SRE
13:10~	SRE作業終了	SRE
13:12~	ECS + TiDB環境へ切り替え 　新環境用のTGを既存ALBに紐づけ	開発
13:30~	運用側動作確認	LAB運用担当
14:35~	メンテナンス解除対応 　WAFのIP制限&メンテナンスページ表示ルールを削除	開発
14:38	メンテナンス終了報告	開発
	メンテナンス終了
切り戻し作業	※メンテ開始から100分(14:40)経過時点で切り戻しを始める	今回は実施なし
14:40~	TGの切り戻し 　EC2+Aurora環境へ	開発
14:50~	メンテナンス解除対応	開発
14:55~	終了報告	開発

今回は行いませんでしたが、移行後の万が一の場合はメンテナンス開始から100分後を目安に切り戻しの実施を予定してました（この時間はメンテ想定作業時間にバッファを考慮した長さ）
先ほど説明した検証を十分に行えていたので本番メンテナンスでの大きな問題は発生せず、オンスケでメンテナンスを無事完了させることができました🎉

インフラ移行後

ECS/TiDBへ移行することで、スケールアウトや保守性の面で想定どおりの改善が見られました。

• オートスケーリング
  • ECSもTiDBも自動でスケールするので運用コストが下がりました。高トラフィック時でも安定性が向上しましたと思います。
    • サービスの特性上、記事がバズった時など急激なPV向上も耐えられるようになったと思います。（前まではすぐ落ちてたから嬉しい…
• 柔軟なリソースの割り当て
  • 元の構成に比べると細やかな調整が可能となったため、リソースの最適化ができたと思います。

一方で、新たなインフラ構成による課題が出てきたり、ECS運用となった結果の改善余地も出てきたりしました。

• EFS利用によるページパフォーマンス低下
  • WordPressやPHPが参照するファイルをEFS上に配置したため、ローカルディスクに比べI/O遅延が発生しやすくなり、一部ページで読み込み速度が低下する問題が発生しました。
• ECSに対するCDの改善余地
  • 現状最低限のCDしか用意できていないため、運用上発生する作業をCDに組み込めれば、より運用コストを下げられそうだと感じています。
    • SFTPでファイル転送が手動であったり、OPCacheのキャッシュクリアをアップタイミングで自動化出てきていないので、ファイル適応まで数分かかることも…

前者の対策として、I/Oの頻度を下げることを目的にOPCacheを導入しました。ある程度はEFS由来の遅延影響を緩和できていると思っています。

変更前後のECSメトリクス：CPU・メモリに関しては元々の状態から半分くらい減少した値で落ち着きました。

気になるページ改善速度ですが、計測が思うように取得できず体感ベースですが………

🎉画面操作で　12~15秒 ⇨ 2~4秒 でした！！！🎉

まとめ

レバテックLABのインフラ移行についてまとめました。本番同等の環境を用意しての段階的な検証が功を奏して、トラブルもなく終えることができました。
また、ECS+TiDBとリッチな環境に移行できた上、当初の狙いは概ね達成できました。

今後は、CI/CDのさらなる整備やレバテックLAB以外にもほぼ同様の構成のWordpressシステムがあり、それらのシステムの統合管理化を進めて、よりよい運用を目指していく予定です。

脚注

1. https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/Aurora.MySQL57.EOL.html