はじめに
エキサイト株式会社 バックエンドエンジニアの山縣（@zsp2088dev）です。
2022年3月末にエキサイトブログはAzure/SQL ServerからAWS/PostgreSQLの移行をしました。 詳細は下記記事をご参照ください。 優先度の高いAWSへの移行が終わったことで、次点で優先度の高いDBのコスト削減に取り組むことができるようになりました。
本記事ではAmazon AuroraのDBのインスタンスサイズを下げるために取り組んできたことについて紹介します。
実施内容
DBのインスタンスサイズを下げるために、Amazon AuroraのPerformance Insightsのメトリクスをもとに、クエリーの改善を行いました。 次の図のように、Performance Insightsを利用することで高負荷のクエリーを簡単に確認することができます。
改善するために取り組んできたことの詳細を以下でまとめます。。
既存のクエリーの見直し
既存のクエリーの見直しにあたり、PostgreSQLのEXPLAINコマンドとANALYZEオプションを使用して実行計画を確認しました。 その中で、インデックスの当たっていないクエリーがいくつかあり、適切なインデックスを貼ったり、不要なインデックスを削除したりすることで改善しました。
その他の取り組んだことは以下の通りです。
- 未使用インデックスの削除
- 不要なソートの削除
- 複雑な集計用クエリーは集計用のテーブルに切り出す(後述)
イベントトリガの活用
PostgreSQLのイベントトリガを活用し、ブロガーのデータの追加/更新/削除のイベントに応じて、別テーブルのデータを更新する処理を追加しました。 エキサイトブログは、ブログサービスという特性上、書き込み頻度より参照頻度のほうが高い傾向にあります。 そのため、高負荷である集計用クエリーは、集計用のテーブルにデータとして切り出すことで、効率の良いクエリーを実行できるようになりました。
ここで、アプリケーション側で対応せずにイベントトリガを使用したことについてもお話します。 下記図のように、バッチ処理や内部API、アプリ用APIなど多くのアプリケーションが記事テーブルを参照しています。 アプリケーション毎にフレームワークやO/Rマッパーが異なっているため、その全ての実行箇所で記事集計用テーブルを更新する処理を追加するのが、大変厳しい状況にありました。
そのため、記事テーブルの追加/更新/削除のイベントに応じて、集計用テーブルの更新ができるイベントトリガが適していると判断して利用することとしました。
一方で、アプリケーションと比較したときに、トリガはデバッグがしにくいことや、バージョン管理が難しいといった問題があります。 そのため、既存の一部のテーブルに対してのみトリガを適用し、新規テーブルではトリガを使用せずにアプリケーション側で集計用テーブルのデータ更新を行うようにしています。
マテリアライズドビューの活用
一定時間毎に更新するランキングをマテリアライズドビューで作成しました。 マテリアライズドビューの更新は、バッチ処理で行っています。 バッチ処理では、以下のクエリーを実行するだけでよいため、非常に簡単に組み込むことができました。
REFRESH MATERIALIZED VIEW CONCURRENTLY mv_table
また、マテリアライズドビューは、特定のレコードのみを更新する機能を提供していません。 そのため、上記リフレッシュコマンドを実行すると、テーブル全体を更新してしまうことに注意が必要です。
キャッシュサーバーの活用
Spring Bootでは@Cacheableアノテーションを付与することで簡単にキャッシュ操作を行うことができます。
これにより、「キャッシュがあればキャッシュサーバーからデータを取得、キャッシュがなければDBからデータを取得」といった操作を、
複雑なコードを書かずに実装できます。
以下にイメージ図を示します。
また、CacheManagerインタフェースを使用することで、より高度なキャッシュ操作を行うこともできます。
現在のアプリケーションでは、複数のキャッシュ削除を行うような実装にCacheManagerインタフェースを使用しています。
実施した結果
上記内容を実施した結果、移行前と現在を比較して約8割、移行後と現在を比較して約6割のインスタンスサイズを下げることに成功しました。 サーバーコストにおけるDBの料金は、全体の大きな割合を占めます。 DBのインスタンスサイズを下げたことにより、大幅なコスト削減を実現することができました。
| 状況 | データベース | サイズ | 性能 | 台数 |
|---|---|---|---|---|
| 移行前 | SQL Server 2016 | Standard_E16s_v3 | 16vCPU / 128GiB | 4台 |
| 移行後 | Aurora PostgreSQL | db.r6g.4xlarge | 16vCPU / 128GiB | 2台 |
| 現在 | Aurora PostgreSQL | db.r6g.xlarge | 4vCPU / 32GiB | 3台 |
おわりに
本記事では、Amazon AuroraのDBのインスタンスサイズを下げるために取り組んできたことについてまとめました。
既存のクエリーの見直し、イベントトリガの活用、マテリアライズドビューの活用、キャッシュサーバーの活用を行った結果、 インスタンスサイズを約6割下げることができました。 エキサイトブログでは、引き続きAWSのサーバー構成とコストの最適化、新機能の開発などに取り組んでいきます。
採用アナウンス
エキサイトではフロントエンジニア、バックエンドエンジニア、アプリエンジニアを随時募集しています。 また、長期インターンも歓迎しています。
カジュアル面談からもOKです。少しでもご興味がございましたら、お気軽にご連絡頂ければ幸いです。
▼ 募集職種一覧 ▼ recruit.jobcan.jp
