リクルートが『スタディサプリ』で Amazon Aurora Serverless v2 を採用。コストを最適化しつつ Aurora の管理工数を大幅削減

株式会社リクルートは、日本国内のHR・販促事業及びグローバル斡旋・販促事業をおこなう事業会社です。リクルートでは、『スタディサプリ』というスマートフォンアプリ、パソコンで利用可能なオンライン学習サービスのデータベースとして Amazon Aurora PostgreSQL を採用しています。 2023 年 5 月にこの Aurora PostgreSQL を Aurora Serverless v2 に変更しました。採用検討から 1.5 ヶ月と短期間で導入を決定しましたが、入念な検証の結果 Aurora の運用負荷を大幅に削減し、サービスの安定運用も実現しています。本ブログは、『スタディサプリ』の Aurora PostgreSQL を Aurora Serverless v2 に変更した時の検討から移行後の効果や課題についてご紹介します。

アーキテクチャ

以下は、Aurora Serverless v2 採用前のアーキテクチャです。データベースとしては、Aurora PostgreSQL をご利用されています。システムは下記右側の図に示すようなマイクロサービスアーキテクチャ (2023/03 時点) で構成されており、本番・開発環境含めて 26 の Aurora クラスタを利用しておられました。また、各クラスタは冗長化のためマルチ AZ 構成を採用していました。

Aurora Serverless v2 採用前の課題

『スタディサプリ』では、中学・高校の授業が始まる前の朝 8 時ごろにアクセスが集中する傾向にありました。このアクセス増による負荷は、この時間帯のみの一時的なものであり、その他の時間帯はこの時間帯と比較して約 1/3 程度とリソースとして余裕がある状況でした。そして、この負荷の高い時間帯を基準としながら、受験シーズンなど季節的な要因や今後のユーザー数の増加、機能追加などによる処理量を考慮してデータベースをサイジングする必要があったため、インスタンスサイズを大きめにサイジングする必要があり、これが結果的にコスト増になっていました。そしてさらに、コロナ禍によるユーザー数の増加でデータベースへの処理量も増加しました。これによるサービスへの影響なども懸念されたため、アクセスが集中する 8 時台の状況を注視する状況が続いていました。

この状況を改善するため、Aurora に Reader インスタンスを追加して負荷を分散させる案も検討されましたが、アプリケーションの特性として Write 処理が支配的であった為、Reader インスタンスの追加や Auto Scaling などでは負荷分散が限定的になってしまうことがわかりました。

Aurora Serverless v2 の導入

このような状況から、Aurora Serverless v2 の検討が進められました。Aurora Serverless v2 は負荷に応じてシームレスにスケールアップ・ダウンすることができる Aurora の機能の一つです。Aurora Serverless v2 は Writer インスタンスにも適用できるため、今回の『スタディサプリ』というアプリケーションの特性に合った機能でした。

Aurora Serverless v2 採用に向けた検討のポイントとしては大きく 3 つありました。 1 つ目はコスト、 2 つ目は性能影響、 3 つ目は移行性です。

コスト
検討ポイントの 1 つ目はコストです。今回のように特定の時間帯だけ負荷が増大するようなケースだと、通常の Provisioned インスタンスの場合ではピークに合わせたサイジングが必要となり、ピーク時間帯以外は過剰なインスタンスサイズとなってしまいます。また、ピークは最も処理量が多いケースでもリソースが不足しないようサイジングするため、実際にピークで使用されるリソース以上のインスタンスサイズが必要となります。さらに、障害を考慮してマルチ AZ 配置を採用する場合、 Reader インスタンスも Writer インスタンスと同じインスタンスサイズで構成する必要があります。一方、Aurora Serverless v2 の場合、アプリケーションのワークロードに合わせてインスタンスのリソースが動的に変更されます。この為、今回のような特定の時間帯だけリソースを使うようなワークロードの場合、Aurora Serverless v2 だと特定の時間帯だけリソースを大きくしてその他の時間帯は小さくするといった運用を実現し、リソースを有効に使用できます。また、今回のケースのように障害時に備えて Reader インスタンスを構成している場合、Aurora Serverless v2 の Reader インスタンスの昇格階層を 2 〜 15 に設定することで指定された Aurora Capacity Unit(ACU) の最小値までスケールダウンして運用することができます。これにより、 Reader インスタンスのコストを大幅に削減することが可能になり、結果的に Provisioned の時と比較してほぼ同程度のコストで運用可能であると確認することができました。

性能影響
2 つ目が性能影響です。リクルート様では、本番の負荷が発生した際のレイテンシーやスループット、スケーリングについて Provisioned インスタンスと Aurora Serverless v2 で比較検証されました。検証の結果、レイテンシーについては、 Provisioned インスタンスとほぼ同程度の結果となり、問題ないことを確認することができました。スケーリングについては、スケーリング時の性能影響は問題ありませんでしたが、 MinACU が小さい状態で急激に処理量が増加したときにフェイルオーバーが発生することがありました。 ACU とは Aurora Capacity Unit の略で Aurora Serverless v2 のキャパシティの単位であり、ワークロードのトラフィックに応じてインスタンスの ACU が増減します。 MinACU は負荷がおさまってスケールインする際の ACU の最小値を意味します。今回の場合、 2 分の間に 10 倍の負荷が増加するワークロードを想定してテストしていましたが、 MinACU を小さく設定しすぎていたため、スケールアップ処理が完了する前に耐え切れないほど IO が増加してしまい、結果としてフェイルオーバーを引き起こしていることがわかりました。この為、このような処理量の増加を想定して MinACU もある程度大きく設定することで、フェイルオーバーの問題も回避することができました。以上の結果、Aurora Serverless v2 移行による性能面への影響は許容可能であるということを確認することができました。

移行性
3 つ目が移行性です。インスタンスを Provisioned インスタンスから Aurora Serverless v2 に変更する場合、Aurora Serverless v2 の Reader インスタンスを追加してフェイルオーバーするだけで、Provisioned インスタンスから Aurora Serverless v2 に簡単に切り替えることができます。この為、万が一、本番で Aurora Serverless v2 を起因した問題が発生した場合、再度フェイルオーバーすることで元の Provisioned インスタンスに切り戻すことが簡単にできます。また、アプリケーションとしても、Design for Failure にもとづき DB のフェイルオーバーがビジネス的に問題にならないよう障害を考慮した設計されていました。このように、Aurora Serverless v2 への切り替えや Provisioned への切り戻しが容易であるということで、本番トラブル時の切り戻しを考慮する必要がなくなり、本番導入への心理的な負担も抑えることができたことは短期間で採用することができた要因でした。

本番への導入

以上、 3 つのポイントについて検討、検証した結果、Aurora Serverless v2 の本番導入が決定されました。Aurora Serverless v2 の検討開始から本番への導入は、 1.5 ヶ月という短期間で実施することができました。導入は、 26 クラスタの中から数クラスタに対して変更を実施して問題がないことを確認した後で、その他のクラスタへの適用を進めました。Aurora Serverless v2 を採用してから 2024 年 3 月現在まで、導入後約 1 年近くが経過しましたが、導入当初は細かい事象が発生していたものの、現在は安定して運用することができています。

Aurora Serverless v2 導入効果と課題

今回、Aurora Serverless v2 を導入したことで気づいた点も何点かありました。導入して得られた効果については大きく 3 つでした。

想定外の負荷でも対処不要に
Provisioned インスタンスの時は、負荷を考慮したインスタンスサイズが割り当てられていましたが、それでも想定外に負荷が増加した場合はデータベースサーバーのリソースが不足する可能性があり、パフォーマンスへの影響調査や障害対応などの作業が発生していました。Aurora Serverless v2 に変更したことで、想定外の負荷でも動的にスケールアップ/ダウンされるため、負荷が増加した時のリソース不足の懸念がなく、 8 時台の状況を注視するような運用負荷を削減することができています。
Provisioned インスタンスの時と同程度のパフォーマンス
検証ではパフォーマンスについて確認していたものの、本番導入後のパフォーマンスについては心配もありましたが、Aurora Serverless v2 に変更したことによる大きな問題はありませんでした。
Aurora Serverless v2 でのコスト削減
Aurora Serverless v2 のコストは一般的に Provisioned インスタンスと比較して高くなることもありますが、『スタディサプリ』ではピーク時のインスタンスサイズを常時確保する必要がなくなったことと、Reader インスタンスのサイズを抑えられることができたため、結果として僅かですが Provisioned インスタンスの時よりコストを削減することができています。

Aurora Serverless v2 導入後の課題や気づき

一方、 Aurora Serverless v2 導入による課題や気づきもありました。

MinACU が小さいことによるフェイルオーバー
MinACU が小さいことでフェイルオーバーする事象が発生しました。MinACU が小さいと Aurora の CPU やメモリなどのリソースも小さい状態になるため、ディスク I/O が上昇してスケーリングが間に合わずにエラーになることがありました。Aurora のフェイルオーバーの時間は数十秒であり、アプリケーションとしても、エラー後に再接続するような処理になっていたため、ユーザーへの影響は極小化することができていましたが、再発防止のため、 MinACU を大きくしてリソースが小さくなりすぎないよう制御することで問題を解消することができています。また、Performance Insights を使用している場合、Reader インスタンスの MinACU の最小値は 2 (参考ドキュメント) である為、Reader インスタンス側の MinACU の値も変更されました。
Aurora Serverless v2 のコスト
今回のシステムの多くの Aurora クラスタでは、ワークロードの特性から Provisioned インスタンスと同程度で運用することができていますが、その他一部の Aurora クラスタでは Aurora Serverless v2 の方がコストが高いケースがあるため、特性を見定めて Aurora Serverless v2 を採用している状況です。Aurora Serverless v2 の料金がもう少し下がると他システムでの採用もしやすくなると考えています。

まとめ

今回のブログでは、Aurora Serverless v2 の導入により、短期間で Aurora の運用課題を改善した事例をご紹介しました。リクルートでは、今回の Aurora Serverless v2 導入のように、新しい機能やサービスも採用しています。
AWS の SA や Sales と連携し、新しい技術採用に関しても相談しながらシステム開発を進めることができている点も、今回のように Aurora Serverless v2 を短期間で導入することができた要因の一つと言えそうです。
今後も、リクルートでは AWS の新しい機能やサービスを利用しながら、システムの安定化やコスト最適化、サービス向上などを実現していく予定です。

Amazon Web Services ブログ