概要

WordPress のデータベースを Amazon RDS から Amazon Aurora Serverless に移行が完了しました。
そして、移行から約 1 年ぐらいが経過するので、過去の対応や知らなかったことをまとめました。

なお、過去に他環境でも Aurora Serverless を採用した話がありますので、比較しながらご覧いただくと面白いかもしれません。

Aurora Serverless に移行した背景

まずはじめに、移行した背景について軽く記述します。

システム概要

一般的な、WordPress をホストする AWS 環境です。

今回は、データベースのみ変更したため、アーキテクチャとしてはあまり変わっていません。

• 移行前:RDS for MySQL 8.0
• 移行後:Aurora Serverless v2

本サービスの特徴

• 月末月初に負荷が集中する
  • 通常時とアクセス集中時を比べるとアクセス数は約 10 倍ぐらいの差
• 急激なアクセス増加も発生する
  • 月末月初以外にも突発的にアクセスが集中するときもある
• 深夜・早朝は比較的アクセスが落ち着く

課題

RDS 運用の課題について、大きくまとめると以下の 2 つです。

• アクセス集中の負荷に耐えられない
• 手動スペックアップの運用負荷

それぞれ詳細に記述します。

アクセス集中の負荷に耐えられない

サービスの成長に伴って、データベースのパフォーマンス部分の課題が発覚しました。

2023 年後半ごろから、人気記事が投稿された場合アクセス集中によりデータベースで処理がつまりサイトがダウンする事象が何度か発生いたしました。
通常の日は、特にパフォーマンスに問題はありませんが、月に 2~3 度負荷が集中する日があり、データベースのパフォーマンスがボトルネックになってました。

調査する限り、現在のパフォーマンスの限界のように見受けられたため、スケールアップを行う方法を選択しました。
そのため、暫定の対応として「事前の手動スケールアップ」の運用が開始しました。

手動スケールアップの運用負荷

「アクセス集中の負荷に耐えられない」に伴って発生した新しい運用でも課題が生まれました。

手動スケールアップの問題としては、事前予測として以下が必要になります。

• どのタイミングでアクセスが発生するか
  • スケールアップするタイミングを図るため
• どのぐらいアクセスが発生するか
  • インスタンスサイズをどれぐらい上げるかを考えるため

本サイトの特性上、「どのぐらいアクセスが発生するか」が全く読めませんでした。

そのため、毎回これぐらいなら耐えられるといった予測を立てて、インスタンスサイズを決定しスケールアップしていました。
ただ、その予測を上回って追加でスケールアップが必要になったことも多々ありました。

なお、この運用はタイミングを事前に予測できたとしても、都度都度発生する作業のため運用コストとしては高くなります。

振り返り

上述した課題を解決するために、Aurora Serverless を選択しました。
そして、無事に Aurora Serverless に移行して運用できているので、その結果を振り返ってみます。

ちなみに、トータル的には良かったことが多いですが、すごく苦労はしました。

良かった点

良かった点は大きく 2 つあります。

• アクセス集中に耐えられている点(一番大事)
• 事前のプロビジョニングが不要になった

それぞれ詳細に記述します。

アクセス集中に耐えられている点

根本的な課題としては、アクセス集中に耐えられていないという内容でしたが、Aurora Serverless に移行したことにより、オートスケールで対応できるようになりました。

この結果、障害回数は 2~3 ヶ月に一回のペースに減りました。
ただし、完全に障害はなくすことができませんでしたが、これは別の問題が起因していることが発覚しました。

ACU と CPU 使用率のメトリクスです。

安定した日の状態

負荷が集中するタイミングがあった日の状態

意外に細かくスケールしているので、スケール速度が遅いといった問題は今のところ発生していません。

事前のプロビジョニングが不要になった

運用者側としては、これはかなり嬉しいです。
事前のやり取りや作業が減ったのはもちろんですが、当日も負荷に耐えられているかを確認する作業もなくなりました。

最大 ACU は、移行前のインスタンスサイズの 2.5 倍ぐらいのメモリ数になるぐらいに設定します。

ただし、定期的(半年・1 年)に最大 ACU と最小 ACU が、パフォーマンス的に問題ないかはチェックしたほうが良いです。

あまり良くない点

Aurora Serverless に移行して、良いことばかりではありませんでした。
決して悪いわけではないですが、あまり良くなかった点をまとめました。

• コストがプロビジョニングに比べて高い
• 常にスケールするためパフォーマンス分析しづらい
• Aurora Serverless の技術・仕様理解が難しい

それぞれ詳細に記述します。

コストがプロビジョニングに比べて高い

シンプルにコストが高いです。
RDS から比較すると約 2 ~ 3 倍になりました。

• RDS: 10 万円
• Aurora Serverless: 20 ~ 30 万円

一応、事前に負荷試験を行いどれぐらいの ACU が妥当かを計測し、ある程度料金を試算してましたが、それ以上に高い結果となりました。

しばらくして、2024/11 に ACU 単価が 0.2 → 0.15 に 1 ACU/h 下がりました。
調査した限りでは、東京と大阪リージョンの Aurora Serverless ACU 単価が 25%削減されたようです。

この効果によりある程度のコストは下がりましたが、以前よりコストが高い状況には変わりありません。

コスト問題が大きかったので、「ステージング環境の自動起動・停止でコスト削減」を追加で対応しました。
もともと、ステージング環境はあまり利用がなかったので、大幅なコスト削減にはなりませんでした。

また、Aurora Serverless に移行して、データベースのロックが問題になるケースがちらほらありました。
それとコスト問題を解決するために、ElastiCache を導入しました。

データベースキャッシュとしてElastiCacheを導入することにより、Aurora Serverlessへの負荷を削減できるため、データベースのパフォーマンスが上がると推測しました。

また、ElastiCache を導入したことによるコスト増より、Aurora Serverless の負担を下げたことによるコスト減のほうがトータル的にコストが安いと判断しました。

ElastiCache を導入した結果としては、平均の ACU が 5.5 → 3.5 ぐらいに下がりました。
2 インスタンスあるので、合計で 4 ACU ぐらい下がったのでかなりのコスト削減になってます。

4 ACU * 0.15/h * 720h(月) = 432 USD(約 6.5 万円)

常にスケールするためパフォーマンス分析しづらい

個人的に辛かった部分です。
秒単位でスケールするので、「ACU がいくつで vCPU がいくつなので、その時の負荷としては…」みたいな事をずっと考えてました。

以下は、5 分間隔で表示した ACU のメトリクスです。

期間を 1 秒単位したらこんな感じです。

Performance Insights でまとめてみることは可能ですが、問題やボトルネックを探すときは少し苦労しました。

Aurora Serverless の技術・仕様理解が難しい

結構、プロビジョニングと Serverless では違う部分が多いので、仕様について理解するまでに時間と労力がかなりかかりました。

詳細についてはあまり触れませんが、Aurora Serverless を理解するうえで必要になるのは基本の「ACU」についてです。

Aurora Serverless v2 の単位は Aurora 容量単位 (ACU).です。

各 ACU では、約 2 ギビバイト (GiB) のメモリと、対応する CPU、ネットワークが組み合わせられています。
Aurora Serverless v2 の仕組み – Amazon Aurora

また、ACU の値に応じて vCPU も変動するので、ACU に関連するパラメータの理解も必要になります。

他に運用していくうえで発見したことは後述でまとめています。

Aurora Serverless を運用中に発見したこと

次に運用中に発見したことをまとめます。

• max_connections が静的
• メトリクスの投稿は 1 秒間隔
• RDS Proxy の最低利用料金が 8ACU
• Performance Insights の一部機能が使えない
• 使っていなくてもリーダーインスタンスはオートスケールする
• ACU が大きいほうがスケールは早い

max_connections が静的

プロビジョニングや RDS の場合は、max_connectionsパラメータ値で同時接続数を動的に変更することが可能です。

しかし、Aurora Serverless になると、max_connectionsパラメータ値は「動的」ではなく「静的」に内部的に挙動が変わります。
そのため、max_connectionsを変更した場合はインスタンスの再起動が必要なります。

Aurora Serverless v2 DB クラスターの最大容量を変更する場合、Aurora Serverless v2 DB インスタンスを再起動して max_connections 値を更新する必要があります。これは、Aurora Serverless v2 の場合、max_connections が静的パラメータであるためです。
Aurora Serverless v2 でのパフォーマンスとスケーリング – Amazon Aurora

ACU を更新する際は、インスタンスの再起動なしで実施可能なので、その場合はmax_connectionsとの整合性が合わなくなる場合があるためご注意ください。

メトリクスの投稿は 1 秒間隔

基本的な AWS サービスでは、CloudWatch に投稿されるメトリクスは 1 分間隔ですが、Aurora Serverless の場合は 1 秒間隔になってます。

以下の CloudWatch インスタンスレベルのメトリクスは、Aurora Serverless v2 DB インスタンスはスケールアップとスケールダウンを理解するうえで重要なモニタリングです。これらすべてのメトリクスは 1 秒ごとに計算されます。
Aurora Serverless v2 でのパフォーマンスとスケーリング – Amazon Aurora

ServerlessDatabaseCapacity メトリクスを 1 秒間隔で表示

もし、投稿されたメトリクスをすべて拾う仕組み等があれば、取得回数がかなり増えてコスト増につながるためご注意ください。

RDS Proxy の最低利用料金が 8ACU

RDS の機能として、マネージドなプロキシ機能を提供する RDS Proxy があります。
Aurora Serverless でも使用することは可能ですが、プロビジョニングに比べて費用が高くなるケースがあるためご注意ください。

ACU が 8ACU 未満であれば、RDS Proxy の費用が 8ACU 分として加算されるため費用が高くなります。

高可用性データベースプロキシ – Amazon RDS Proxy の料金 – Amazon Web Services

RDS Performance Insights の一部機能が使えない

RDS の機能として、データベースのパフォーマンスを分析できる Performance Insights があります。
Performance Insights の有料利用枠を使うと様々な追加機能を利用することができます。

しかし、Aurora Serverless では、この一部機能が利用できません。

利用に制限がある機能

• 一定期間のデータベースパフォーマンスの分析
• Performance Insights のプロアクティブ推奨事項の表示

詳細は以下をご覧ください。
Amazon Aurora DB エンジンとインスタンスクラスでサポートされている Performance Insights – Amazon Aurora

なお、Performance Insights を利用する際の最小 ACU は 2 ACU が推奨とされています。

Aurora Serverless v2 は、すべての MySQL 互換バージョンと PostgreSQL 互換バージョンの Performance Insights をサポートします。最小キャパシティは少なくとも 2 Aurora キャパシティユニット (ACU) に設定することをお勧めします。
Performance Insights でサポートされているリージョンと Aurora DB エンジン – Amazon Aurora

使っていなくてもリーダーインスタンスはオートスケールする

言われてみれば、至極当然のことでしたが、冗長化のために起動しているリーダーインスタンスでも、ライターインスタンスと同様に負荷に合わせてオートスケールを行います。

Aurora Serverless を運用する前は、「リーダーインスタンスを使わないから ACU は上がらないだろう」と考えてました。
しかし、ライターインスタンスと同期を取るための処理などで、リーダーインスタンスを使っていなくても裏側で動いている影響で、オートスケールしていると推測しています。

ライターインスタンスとリーダーインスタンスで比較すると、リーダーインスタンスのほうが過度な増減はしてないですが、平均で比較するとある程度同じぐらいの値になります。

1 秒間のライターインスタンスの ServerlessDatabaseCapacity

1 秒間のリーダーインスタンスの ServerlessDatabaseCapacity

1 分間のライター・リーダーインスタンスの ServerlessDatabaseCapacity

ACU の費用をある程度求める場合は、使っていないリーダーインスタンスがあればそのインスタンスの ACU を見るとわかりやすいです。

ACU が大きいほうがスケールは早い

ACU の仕様に関する話です。

現在の容量が大きいほど、スケーリングの増分が大きくなり、そのため、スケーリングがより高速になります。
Aurora Serverless v2 の仕組み – Amazon Aurora

例えば、コストを重視して ACU を下げすぎると、スケールが間に合わないケースが発生するかもしれません。
そのため、最大 ACU だけでなく最小 ACU もパフォーマンスによって調整が必要になります。

Aurora Serverless を検討する場合

様々な構築・運用してみた経験則からまとめた内容です。
もし、Aurora Serverless を検討する場合は参考にしてみてください。

• コストよりもパフォーマンス効率・信頼性を優先したい場合は Aurora Serverless が有用
  • コストを重視するならプロビジョニングで RI 購入のほうがコストが安いかもしれません
• 初期はサーバーレスで走り始めて安定稼働後に、プロビジョニングに変更することもできる
  • バージョンが同じなら簡単に変更可能(ダウンタイムあり)
• ピーク時の負荷と通常時の負荷を比較した際に、スペック差が約 2.5 ~ 3 倍ぐらいなら Serverless でもコストメリットがでる
  • r6g.large を利用中の場合は r6g.xlarge ~ 2xlarge 相当のリソースが必要になる状況が存在する場合に Aurora Serverless が有用
• プロビジョニングからサーバーレスを検討する際に、事前に ACU を測定したいときは、リードレプリカで Aurora Serverless を導入してみると大まかな目安がわかる
  • リーダーインスタンスでもある程度スケールするため事前に ACU の測定が可能
• スケール速度がシステム要件に合うか注意
  • 事前に負荷試験を実施するとおおよその ACU が評価できます

まとめ

課題にマッチするソリューションとして Aurora Serverless を採用しましたが、様々な壁があり運用は大変でした。
もし、要件に合う場合は検討してみると良いかもしれません