RDSの負荷増大に立ち向かったAurora移行プロジェクトの裏側

ツール導入前の課題

RDS for MySQL を利用していましたが、顧客数やデータ量の増加に伴い、いくつかの課題が顕在化してきました。まず、スロークエリの発生数が増え、特にデータ量の多いテナントでパフォーマンス低下が目立つようになりました。これにより、画面表示の遅延や処理速度の低下など、日々プロダクトを利用する顧客のユーザー体験に影響を与えていた可能性があります。

もちろんクエリ修正による改善も進めていましたが、対応コストが高く、新機能の追加と比較するとスロークエリ改善の優先度が下がってしまうことが多くありました。短期的には、機能追加をスピーディに進めることでプロダクトの売上向上に寄与していた側面もありますが、中長期的に見ると、顧客が求める快適な操作性や安定したサービス提供を継続する上での課題となり、プロダクトの価値提供を阻害しかねない問題でもありました。

さらに、Qast はエンタープライズ企業向けの提供が中心であるため、データの冗長性をマルチAZで確保する必要性もありました。

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

目指していたのは、クエリ修正に多くの作業時間を奪われることなく、スロークエリの発生数が削減されている状態です。これにより、開発チームが本来注力すべき新機能開発や価値向上につながる改善にリソースを割けるようにし、プロダクト全体の進化を止めないことを意図していました。

• Aurora (Aurora Provisioned)
• Aurora Serverless v2

• ランニングコスト
• 初期構築・メンテナンスコスト

まず、ランニングコストの面で Aurora Provisioned の方が安くなると判断したことが大きな理由でした。既存の RDS におけるCPU・メモリ使用率、コネクション数などの実績値をもとに、Aurora Serverless を利用した場合の想定最小および最大ACUを試算し、その結果から算出したコストを比較したところ、Aurora Provisioned の方がより低コストで運用できる見込みが立ちました。

また、初期構築コストが低い点も選定の決め手となりました。Aurora Provisioned は既存RDSの設定値をそのまま流用しやすく、構築にかかる手間を抑えられると考えました。一方で、Aurora Serverless を採用した場合は、運用開始直後にある程度のチューニング作業が必要になることが予想されていましたが、社内でその作業に割くリソースを十分に確保できる見通しが立たなかったため、この点からも Aurora Provisioned を選ぶ方が適切だと判断しました。

改善したかった課題はどれくらい解決されたか

導入前に抱えていた課題のうち、スロークエリの削減については一定の効果が見られ、件数が約2割ほど減少しました。期待していたほど大きな改善には至らなかったものの、明確な改善傾向は確認できました。

また Aurora Provisioned ではデータは3つのAZにまたがるクラスターボリュームに保存され、高い耐障害性を確保することができるため、データベースレイヤで高可用性を実現することができました。

どのような成果が得られたか

今回の移行によりスロークエリ改善にかかる対応コストが減少し、開発チームの負担を軽減できました。また耐障害性についても、自動フェイルオーバーによる復旧時間の短縮などにより、障害発生時の影響を最小限に抑えられることが見込まれています。

導入にあたって特に苦労したのは、ダウンタイムを最小限に抑えるための移行方針の検討でした。ダウンタイムを完全にゼロにすべきか、ある程度は許容するのかという判断に悩み、さらにダウンタイムを許容する場合でも、どの方法であれば短時間で移行を完了できるかを慎重に検討する必要がありました。

最終的には、無理にゼロダウンタイムを目指して準備やトラブルリスクを増やすよりも、最小限のダウンタイムを設けて低リスクで移行する方針にしました。DNSレコードによる RDS と Aurora Provisioned の切り替えや、万が一の切り戻し手順の整備など事前準備を入念に行い、約3時間のメンテナンス時間を設けましたが、実際の作業は1時間ほどで完了しました。