RDS MySQLから Auroraへ：スパイク + デプロイ負荷に耐えるデータベース基盤

背景

大規模なコンシューマ向けサービスを運用する上では、以下のような負荷要因に対応できるインフラ設計が求められます。

• 日々のアクセス変動
• イベント発生時のトラフィック急増
• デプロイ時に発生する一時的な負荷上昇

特にバックエンドのデータベースはシステムの中心となるため、以下の観点がサービスの継続に直結します。

• スケール性の確保
• 高負荷時でも安定して処理できること
• 可用性を維持し続けること

私たちが担当するサービスでも、以下のような課題が顕在化していました。

• ユーザー数の増加により、データベース接続数が逼迫
• アクセスが集中するタイミングでレスポンスが低下
• 機能拡張に伴い、既存構成ではスケールが難しくなってきた

これらを踏まえ、以下の目的でデータベース基盤の見直しが必要になりました。

• 柔軟にスケールアウトできる基盤への刷新
• メンテナンス性の向上と運用負荷の軽減

本記事では、

• どのように課題へアプローチしたか
• どの観点でAmazon Auroraを選定したか
• 実際の移行によってどのような成果が得られたか

について紹介します。

ツール導入前の課題

以下のような複数の負荷要因により、データベースに大きな負荷がかかる状況が発生していました。

• ユーザー増加に伴う通常トラフィックの増加
• 週に一度の全ユーザー向けPush通知による短時間のアクセス急増
• Push通知時に大量のリクエストが集中し、データベース接続数が跳ね上がる傾向
• ECSデプロイ時、タスク数が一時的に倍増し、その分だけデータベース接続数も増加
• デプロイ負荷が原因で Blue/Green デプロイが正常に完了しないケース

どのような状態を目指していたか

複数の要因が重なったことで、以下のような改善が必要であることが明確になりました。

• 中長期的なユーザー増による負荷に柔軟にスケールアウトを行える構成
• 短時間の高負荷イベントにも耐えられる構成
• デプロイ時でも余裕を持って接続を捌ける構成

Push通知、デプロイ時の一時的なタスク増加、日常的なアクセス負荷など、複数の要素が同時に作用する環境では、既存のRDS MySQLでは以下のような課題がありました。

• 柔軟にスケールアウトしにくく、アクセス急増に即時対応できない
• 高負荷イベント時に接続数が逼迫しやすく、安定性を確保しにくい
• Push通知やデプロイ時の接続急増に十分な耐性を持てていなかった
• 読み取りスケールに強くない構造で、Read Replicaの追加にも時間がかかる
• ストレージがクラスタ構造ではないため、拡張性に限界がある

これらの課題を踏まえ、より柔軟にスケールし、高負荷時にも安定性を維持できるAurora移行を検討しました。

Aurora MySQLを選んだ理由は以下です。

• Read Replicaを高速に追加でき、アクセス増加に即時対応できる
• クラスタ構造により、ストレージが自動でスケールし運用コストが低い
• RDS MySQLより高いスループットと安定性を持ち、高負荷耐性が高い
• マイナーバージョンアップがダウンタイムなしで実施できる

Aurora MySQLへの移行により、以下のような成果が得られました。

• Read Replicaを必要に応じて高速に追加できるようになり、短時間のアクセス急増にも柔軟に対応可能になった
• マイナーバージョンアップをダウンタイムなしで実施できるようになり、メンテナンス性が大きく向上した

工夫したポイント

今回の移行において、いくつか工夫した点があります。

1. 手動作業を無くすためスクリプトの用意

Terraformでリソース自体は管理しているものの、実際のメンテナンス作業は一時的に手動で実施せざるを得ない場面がありました。 例えばECS / Lambda / Glue等のデータベース接続先の切り替えや環境変数の変更などです。これらを都度手入力で行うのはヒューマンエラーのリスクが高いため、Bashスクリプトを作成し、定型的な操作を自動化しました。これにより、作業のスピードと正確性が大きく向上しました。

2. Terraform importをスムーズに実施

移行作業後は、メンテナンス後のリソースをTerraform importでIaC管理下にする必要がありました。 この際、特に役立ったのは、Terraformコードがあらかじめモジュール化されていたことです（前任者に感謝）。 リソースごとに散在していないためimportの対象が明確で、作業手順をシンプルにできました。 もちろん変更点が多かったため多少の調整は必要でしたが、モジュール化されていたおかげで「どのファイルにどのリソースを定義するか」を迷うことなく進められ、結果的にdiffの最小化につなげることができました。