こんにちは！Life is Tech! インフラ/SREグループのふ〜みんです。

スポーツの秋と言いますか、タイガース18年ぶりのセ・リーグ優勝を目の当たりにし大変嬉しいのですが、クライマックスシリーズで4タテ食わらないか大変心配している今日このごろです。

さて、今日は私たちのプロダクトで導入しているAWS Aurora Serverless v2について2回に分けて書いていければと思います。今回は導入編です！

Aurora Serverless v2 導入の背景

私たち、インフラ/SREグループが担当している主なプロダクトは、中高生または先生が学校および学習塾で行う「情報」の授業で使っていただいています。

そして、この利用の特性上、一般的（？）なプロダクトのアクセス数の推移と異なり、1日の中でスパイクアクセスが繰り返されるパターンがほとんどです。

企業向けSaaSの場合では、朝方からアクセスが動き出し日中帯にピークがあり夕方・夜間にかけてゆるやかに落ちていくカーブを描くのかなと思いますが、私たちのプロダクトに関しては授業の行われる時間帯のみギュッとアクセス数が上がり休み時間はグンと減るといったスパイクアクセスが繰り返されます。

1日に何度か訪れる短時間のスパイクアクセスの最大に併せてシステムを構成したとしても、それ以外の時間帯に関しては余剰すぎるスペックとなりコスト的にも非常にもったいない感じになってしまいます。

アプリケーション側に関してはECSコンテナの数を調整する事である程度調整できるのですが、DBに関しては最大アクセスを想定し、Auroraの少し大きめのスペックで固定せざるを得ませんでした。

しかし、2022年4月にAurora Serverless v2がリリースされたことで、アクセスに対して弾性のあるDBを選択肢としてチョイス出来るようになりました。
そこで、新しく展開するプロダクトのDBに関しては要件が適合するのであれば、通常のAuroraではなく積極的にAurora Serverless v2を採用しています。

Aurora Serverless v2の導入に際しての検討ポイント

はじめにAurora Serverless v2の導入を検討し始めた際、Serverless v1のイメージが強く、開発環境やステージングへの導入に関しては問題なさそうなものの本番環境で利用するとなると、パフォーマンス面でどうなのか？という懸念がやはりありました。また、スケールのされ方やメンテナンス性に関しても未知の部分があり、まずはドキュメントベースで調査を行いました。

調査する際のポイントとしては下記の4つでした。

1. 従来のAuroraインスタンスとのスペック的な差分

2. コスト面での比較

3. スケーリング速度とスケーリングする際のユーザ影響

4. 可用性

これらをドキュメントから順々に追っていきました。参照したドキュメントはAWSのオフィシャルのものです。

資料はこちら

1. 従来のAuroraインスタンスとのスペック的な差分

まずまず、インスタンスのスペックについてですが、従来のAuroraインスタンスではvCPU（ECU）、メモリでインスタンスタイプが定義されますが、Aurora Serverless v2はACU（Aurora Capacity Unit）が基本単位として定義されます。

1ACUの考え方は公式ドキュメントによると

のように記載があります。例えば8ACUは16GBメモリとなり、db.r5.largeやdb.r6g.largeと同じぐらいのスペックを持つこととなります。

なお、Aurora Serverless v2のACUが取れる範囲は0.5（1GBメモリ）〜128（256GBメモリ）になります。

対応するCPUやネットワーク帯域に関しては明確な記載はありませんが、従来のAuroraインスタンス（r6g）と比較した例が載っていますので、r6g（もしくはr6i)インスタンスを参考にすれば大体はOKかなと思います。

ただし最大接続数に関してはACUに対応して変動する（参照：Aurora Serverless v2 の最大接続数）ため、パラメータグループで設定する最大接続数の定義を計算式で置くことが推奨されています。
これに関しては、すでにデフォルトのパラメータグループでは計算式で定義されているので変更は不要ですが、最大接続数周りでのパフォーマンスチューニングが求められる際には確認できるよう数式を抑えておくといいと思います。

2. コスト面での比較

インスタンス料金を比較すると、同等のスペックのAuroraインスタンスに比べてAurora Serverless v2の方が割高に設定されています💦

従来のAuroraインスタンスでは、時間あたりのインスタンスタイプ毎に定められた料金となりますが、ServerlessではACU・時間あたりの料金となります。

例えばAuroraインスタンスのdb.r6i.large（メモリ16GB）を採用した場合の1ヶ月（30日と仮定）のインスタンス料金コストは
$0.35( /時間) x 24(時間) x 30(日) = $252/月
となります。

同一スペック（8ACU=メモリ16GB）でスケールを考慮せずAurora Serverless v2を1ヶ月稼働させた場合のコストを計算すると、
$0.20( /ACU) x 8(ACU) x 24(時間) x 30(日) = $1,152/月
となります。

どれぐらいお高くなってしまうかというと、
$1,152(/月) ➗ $252(/月) = 約4.57(倍)
と結構な倍率となります。

そこで、普段は最小の1 ACUで稼働するが、トラフィックがバーストし最大の8 ACUで稼働するような想定をした場合（ちょっと極端ですが💦）の損益分岐点となるような時間を算出してみましょう。

従来のAuroraインスタンスですと、db.r6i.largeを採用する形になるので、
先ほどの計算式から算出された$252が月額固定となります。

これをAurora Serverless v2で構築した場合、月額の計算式は8ACUで稼働する1ヶ月あたりの時間を$${x}$$とすると、1ACUで稼働する1ヶ月あたりの時間は$${24*30-x}$$となりますので、下記の数式で表すことができます。

$$
 0.2 * 8*x + 0.2*(24*30-x) \\
= 1.6x + 0.2(720-x) \\
= 1.4x + 144
$$

これらをグラフにすると損益分岐が交点より導け出せます。

交点を求めると$${x}$$は約77時間なので、1ヶ月のうち大体10％スパイクするようなトラフィックだとトントンということになります。ただし、今回の例は簡単化のためだいぶ極端な例を用いていますが、実際は1〜8ACUの中間値を取ることも多いと思いますので、その辺りも加味されるといいかもしれません。

このように最大トラフィックと最小トラフィックの変動幅が大きいプロダクトでないとお得とは言えなくなりますので、損益分岐点の見極めが必要な箇所かなと思います。

また単純な損益分岐だけでなくスパイクに対する保険料の意味合いをAuroraインスタンスの固定費として持つのか、Serverlessとして持つのかと言った視点も考えられますので、プロダクトの状況に合わせた選択が必要です。

3. スケーリング速度とスケーリングする際のユーザ影響

公式のドキュメントには「Aurora Serverless v2のスケーリング」という章に詳細の記述がありますが、もう少し簡単に知りたかったので、「Introduction and Deep Dive for Amazon Aurora Serverless v2」の動画で用いられている資料から読み解くことにします。

P.11〜P.16までにスケーリングに関しての記述があります。この辺りの内容を要約すると

• CPU、メモリの追加を伴うスケーリングは1秒以下で完了

• 数十万トランザクションを実行してもスケーリングによる影響はなし

• バッファプールのリサイズは自動的に行われ、メモリの縮小が行われてもアクセス頻度の高いバッファは優先的に保持される

• 下記の3つの要素に基づきスケールアップされる。スケールアップ率は現在の容量に比例し、大きな容量（ACU）ほどスケールアップ速度は速い

  • CPU使用率

  • メモリ使用率

  • ネットワークスループット

となっています。なるほど、1秒以下でスケーリングが完了しつつ、数十万トランザクションがあってもユーザ影響がないと言い切っているのは非常に心強いです。

ただ、これだとセールストーク感も否めないので、この基礎知識を持ちつつ「Aurora Serverless v1 のオートスケーリング」と先ほどの「Aurora Serverless v2のスケーリング」に目を移しましょう

まず、Serverless v1ではスケーリングを行う際、下記のような条件下ではスケーリングを行うことができません。

• クエリの実行中

• トランザクションが進行中

• テンポラリテーブルまたはテーブルがロックされている

また、上記の条件下においても強制的にスケーリングを行うことはオプションで可能ですが、その際実行中のクエリは強制的に中断させられます。

これでは、トランザクションが多くなった際に肝心のスケーリングを容易に行うことが難しくなり、僕がAurora Serverlessの本番適用を躊躇わせる大きな要因でした。

しかし、Serverless v2では無停止でスケーリングが行われるためユーザ影響を受けずスケーリングすることが可能となっていることがドキュメントからも読み取れます

過去にServerless v1を検討した際、スケーリングポイントでクエリの中断（もしくは実行させない）がネックで本番環境には使用しにくいなぁと思っていたのですが、Serverless v2では従来のAurora インスタンスと同様の扱いをしつつ、スケーリングを行ってくれるので、これに関しては本番に適用しやすくなったなという印象になりました。

4. 可用性

最後に可用性です。

「Aurora Serverless v1 とフェイルオーバー」にも記載があるのですが、Serverless v1ではDBインスタンスの障害発生時には別のAZにDBインスタンスを再作成されます。この際、フェイルオーバー時間に関しては明確に定義されておらず、従来のAuroraと同程度のフェイルオーバーは期待できません。（データに関しては引き継がれます）
またマルチAZ構成を組むことができないため可用性という面で弱くなっていました。

しかし、Serverless v2ではマルチAZ構成を組むことができ、従来のAuroraインスタンスと同様にWriterとReaderのインスタンスを作成することができます…！これは可用性的には非常に大きく、DBメンテナンスの際にもAuroraのフェイルオーバーの恩恵を受けつつダウンタイムを最小限にすることができるのでありがたいですね！！

また、私たちの要件的には不要なのですが、グローバルデータベースの構築も可能になっているので、これもServerless v1と大きく異なるところです。

導入編〜まとめ

以上の4つのポイントを確認した上で、従来のAuroraインスタンスと変わらないサービスレベルを保ちつつ、柔軟にスケールしてくれるAurora Serverless v2を採用することにしました。

実際に稼働しているプロダクトの数も増えてきており、すでに稼働から1年経っているものもありますが、サービス面・メンテナンス面の両方において、特に大きな課題もなく運用できています。

次回はAurora Serverless v2の運用にまつわるお話を書いていければと思います。お楽しみに！

おまけ

こちらにもAurora Serverless v2の紹介と資料がありましたので、ご興味ある方は参照ください！