Aurora Serverless v2を有効活用するために導入検討時に考慮しておきたい観点

この記事は、アソビュー！ Advent Calendar 2023の8日目(B面)です。

アソビューでSRE部門を担当している鈴木です。

早いもので、もうこんな時期になってしまいました。今回は、Aurora Serverlessを実践するにあたり、検討した視点や、実際に導入して分かった、サーバレスの特徴について書いてみます。

はじめに
Aurora Serverless v2を検討するモチべーション
Aurora Serverless v2の損益分岐点について
Aurora Serverless v2のパフォーマンス面での考慮事項
Aurora Serverless v2の最大スペックに関する考慮事項
まとめ
最後に

はじめに

昨年、アソビューでは、Auroraのバージョンアップを実施しました。関連記事は、こちらになります。

アソビューにおけるSREとは？4,000万人のアクセスに耐えられるインフラと高い信頼性を目指して - asoview! TECH BLOG

これにより、Aurora Serverless v2を利用することが可能になり、その後Aurora Serverless v2の変更についてを検討して、今年の11月より、データベースの一部を Aurora Serverless v2を変更するという決断をしました。この決断の過程で議論されたポイントなどをご紹介して、今後Aurora Serverless v2を検討されている方の参考になればと思い、紹介します。

Aurora Serverless v2を検討するモチべーション

アソビューでは、電子チケットを販売するサービスを提供していますが、こちらは、負荷特性として季節性という要素があります。 GWや夏休みなどの期間中においては、多くの人にアクセスされ、アクセス数において季節変動がありました。従来は、この季節変動に合わせて、サーバのインフラスペックの変更をおこなっていたのですが、この際にダウンタイムが発生してしまうのというのと、負荷に合わせてスペックを調整するという運用負荷というのがSREチームの課題としてありました。

サービスを利用できない時間を減らすための方法論の一つとして、また、運用負荷の軽減ということを目的に、サーバレスという選択肢の検討を始めました。　

Aurora Serverless v2の損益分岐点について

まず、最初に、インフラコスト面という観点で検討をしました。

結論を先に言うと、Aurora Serverless v2は、基本的にそれほど安価ではないという点には、注意が必要です。同じインスタンスタイプでCPU利用率が一定の範囲内で年間運用ができるのであれば、プロビジョニングされたインスタンスで運用するのがいいと思います。

まず、価格を単純化して表現すると下記のようになります。

単純化のため、前提として、db.r6g.8xlargeのCPU利用率とACU利用率がほぼ同じになるという前提で考えます。 RI(Reserved Instance)の支払いパターンも、単純化のために全額前払いのみ考慮しています。その前提で言うと、大雑把には、下記のことがいえます。

RIを使わない場合には、CPU利用率が年間平均で大体２０％以上ならプロビジョニングされたインスタンスの方がコスト観点で優位
1年前払いのRIの場合には、CPU利用率が年間平均で大体１０％が1年以上継続する見込みならプロビジョニングされたインスタンスの方がコスト観点で優位
3年前払いのRIの場合には、CPU利用率が年間平均で大体７％が1年以上継続する見込みならプロビジョニングされたインスタンスの方がコスト観点で優位

と言うことから、価格だけで言うと、通年で同じインスタンスタイプで運用した場合に、平均的に CPU利用率が常に約１０％以上の場合には、プロビジョニングされたインスタンスで運用した方がいいと言う形式になります。

上記をベースに、最終的には、アソビューでは、下記の基本方針で、Servelessにするかしないかを分類していきました。

常時CPU利用率が高い前提のインスタンスは、プロビジョニングされたインスタンスで運用する
通年db.r5.xlarge以下のスペックで運用可能なインスタンスは、プロビジョニングされたインスタンスで運用する
社内テスト環境は、本番がServelessであればServelessで運用する。

Aurora Serverless v2のパフォーマンス面での考慮事項

Aurora Serverless v2の一つの売りでもある高速なスケールアップやスケールダウンは、実運用上は、ほぼ問題ないという状況かと思います。ただ、パフォーマンス面においても、実際に利用してみて、１点ほど注意すべき点がありました。

Aurora Serverless v2に変更することによって、ReadLatencyとWriteLatencyの比較をしてみたのですが、 ReadLatencyは、0.9ms->1.1msと　２０％くらいの悪化が見られました。これは、Aurora Serverless v2に変更することによって、利用可能な物理メモリが減って、データベースのインスタンスのメモリにデータが乗らなくなったことによるオーバーヘッドが一定程度発生していることに起因するのではないかと推察しています。プロビジョンされたインスタンスの場合には、メモリは、すべて占有できる一方 Aurora Serverless v2の場合には、負荷に応じて利用可能なメモリが変動することから、この程度の劣化は、受け入れる前提で、Aurora Serverless v2を選択すると言う決定をする必要がありそうです。

（参考：レイテンシーの変化グラフ）

バッファプールサイズの考慮も必要です。現在、プロビジョンされたインスタンスを利用している場合には、下記のクエリなどを使って実際に、どれだけのバッファプールに乗って処理されているのかと言うのを確認しておくのもいいと思います。おそらく、キャッシュヒット率はAurora Serverless v2に変更することによって低下するのではないかと思います。

参考）バッファプールの利用状況を確認するSQL

SELECT ( pagesdata * pagesize ) / Power(1024, 3) DataGB FROM (SELECT variable_value PagesData FROM performance_schema.global_status WHERE variable_name = 'Innodb_buffer_pool_pages_data') A, (SELECT variable_value PageSize FROM performance_schema.global_status WHERE variable_name = 'Innodb_page_size') B;

Servelessに置き換えた場合に、こちらのキャッシュが減ることになりますので、その場合には、ワークロードによっては、パフォーマンスなどが顕著に悪化する可能性はあるかと思います。

Aurora Serverless v2の最大スペックに関する考慮事項

Aurora Serverless v2のスペックは、ACUと言う単位で定められており、1ACUは 2 ギビバイト (GiB) のメモリと対応するCPUと言う形で表現されております。CPU自体は、いくつかという明言はないのですが、自社で実測した感覚で言うと、r系のインスタンスタイプの比率と同じCPU数が割り当てられていそうです。（2023/11現在）

つまり、最大スペックとしては、メモリ最適化の8xlargeがAurora Serverless v2の最大スペックとなり、これ以上のスペックが必要となる場合には、 Aurora Serverless v2は選択肢から外す必要があるということが言えると思います。

なお、先日、 Amazon Aurora Limitless Database と言う仕組みののプレビューが開始されました。これは、この最大スペックを超えるようなケースにも対応することが可能な新しい形のAuroraと言うことができそうです。現在は、 Aurora PostgreSQLベースのみのプレビュー版と言う提供ですが、今後、こちらの動向にも注目しておきたいですね。

aws.amazon.com