こんにちは。日々マネージドサービスの運用監視にまつわる業務をしているこまちといいます。
はじめに
Aurora Serverless v2 が一般利用が可能になってから久しく、本番運用されている方もいらっしゃると思います。 当然監視も必要になりますよね。
本稿ではAurora Serverless v2 ではローカルストレージ空き容量が監視できないことを説明してまいります。 CloudWatchメトリクスの FreeLocalStorage はAuroraやAurora Serverless v1 では提供されますが、Aurora Serverless v2 では提供されません。
問題の背景
本題に入る前に、そもそも Aurora Serverless とは何か？そして FreeLocalStorage とは何か？を簡単に振り返ってみましょう。
Aurora でローカルストレージを監視する意味
Auroraのストレージはクラスター全体で共有するクラスターボリュームと、個々のDBインスタンスが持つローカルストレージの２つに分かれています。 (ローカルストレージはDBからはTemporary storageとも呼ばれます)
Auroraのストレージは自動スケールするという事はご存知の方が多いと思いますが、自動スケールするのはクラスターボリュームのみです。
一方のローカルストレージを増やすには、DBインスタンスのインスタンスクラスを大きくする必要があります。
データベースの処理にはローカルストレージを使用するものがあります。ここでローカルストレージが足りないとエラーが発生する場合があるため、ローカルストレージが枯渇していないか監視する必要性がありました。
このローカルストレージの空き容量を監視できる CloudWatchメトリクスが、FreeLocalStorage です。
よろしければ詳細を以前当社ブログでご紹介していますのでご参照ください
Amazon Aurora のストレージに関連するメトリクスを理解する - サーバーワークスエンジニアブログ
Aurora Serverless とは
Aurora Serverless はその名からも想像できる通り、サーバーレスでデータベースを利用できるマネージドサービスです。
ここで「サーバー」はDBインスタンス部分を指しており、これが「サーバーレス」となったことで都度インスタンスタイプを変更してスケールアップ/ダウンする必要がなくなりました。
DBインスタンスに該当する部分のリソースが不足/過剰になるとACU(Aurora Capacity Unit)と呼ぶ単位の割り当てを増減させることで最適化します。
Aurora Serverless v1 と v2 で異なる構造
通常の Aurora と Aurora Serverless は大きく異なりますが、Aurora Serverless v1 と v2 も大きく異なります。
Aurora Serverless v2 については以下の当社ブログをご参照いただければと思いますが、
Amazon Aurora Serverless v2 がGAしました - サーバーワークスエンジニアブログ
ざっと各々の違いをまとめると以下のようになります。
| RDSのタイプ | クラスターのタイプ | インスタンスのタイプ |
|---|---|---|
| Aurora | プロビジョンド | プロビジョンド |
| Aurora Serverless v1 | サーバーレス | サーバーレス |
| Aurora Serverless v2 | プロビジョンド | サーバーレス |
蛇足までに、Aurora Serverless v2 のクラスタータイプがプロビジョンドだということは、Aurora のプロビジョンドインスタンスと Aurora Serverless v2 のサーバーレスインスタンスの両方を同じクラスター内に共存させることができるということです。
Aurora Serverless v2 ではローカルストレージ空き容量が監視できない
ようやくここから本題です。
Aurora Serverless v2 で監視設定をしようとすると分かるのですが、Aurora Serverless v2 ではローカルストレージ空き容量のメトリクスが取得できない事に気付きます。
そうなのです、実は通常の Aurora や Aurora Serverless v1 では FreeLocalStorage メトリクスが提供されているのですが、 Aurora Serverless v2 では FreeLocalStorage メトリクスがなかったのです。
FreeLocalStorage
使用できるローカルストレージの量。
<中略>
(これは Aurora Serverless v2 には適用されません。)
Amazon Aurora の Amazon CloudWatch メトリクス - Amazon Aurora
Aurora Serverless v2 ではローカルストレージ枯渇の問題が起きないのか？
ローカルストレージ枯渇の問題については Aurora Serverless v2 では一定の対策が行われています。
Aurora Serverless v2 のスケールアップはほとんどの場合はメモリとCPU使用率から行われますが、DB インスタンスとローカルストレージデバイス間のネットワーク量が多い場合にもスケールアップが行われます。
これはローカルストレージが不足するような状況でスケールアップが行われるという寸法となります。 従って、Auroraのようにシビアにローカルストレージを監視し、不足の場合にはインスタンスをスケールアップさせるといったオペレーションは不要となります。
なぜ Aurora Serverless v2 でだけ FreeLocalStorage がないのか？
Aurora Serverless v1 と v2 は全体の仕組みやACUの単位など多くの点が異なりますが、RDSインスタンスはサーバーレスタイプのインスタンスクラスを使用するため、ローカルストレージのスケールが自動で行える点は共通しています。
ではなぜ v2 でのみ FreeLocalStorage がないのでしょうか？
...申し訳ありませんが、そういう仕様であるという事の他、現時点でははっきりとした事は分かりませんでした。
しかしながら、Aurora Serverless v2 のスケーリングについては前述の通りローカルストレージデバイスの使用状況に応じて実施されるという仕様が公開されていますが、Aurora Serverless v1 に関してはそのような仕様は公開されておらず、またスケーリングに関しては以下のような制約があります。
Aurora Serverless v1 は、 次の理由により、スケーリングポイントを見つけることができない場合があります。
・クエリの実行時間が長い
・トランザクションが進行中である
・テンポラリテーブルまたはテーブルがロックされている
Aurora Serverless v1 の仕組み - Amazon Aurora
上記の制約があるため、ローカルストレージが枯渇した状態になっている事が原因でエラーが発生する可能性があるため、Aurora Serverless v1 においてはローカルストレージ空き容量を監視する事は意味のある監視であると言うことができるでしょう。
Aurora Serverless v2 ではローカルストレージ空き容量のことを考えなくて本当にいいのか？
さて、再び当初の疑問に立ち返ります。
答えとしては、Aurora Serverless v2 ではローカルストレージ空き容量のことをまったく考えなくていいわけではありません。
スケール可能な最大容量に達した場合にそれ以上スケールアップできない状況で、ローカルストレージが枯渇する場合があるためです。メモリもCPUも余裕があるにも関わらずローカルストレージが不足することでエラーが発生するケースでは、Aurora Serverless v2 から新しく登場したメトリクスである TempStorageIops と TempStorageThroughput を監視することで問題の特定に繋げることができます。
TempStorageIops。DB インスタンスにアタッチされたローカルストレージで実行された IOPS の数です。これには、読み取りと書き込みの両方の IOPS が含まれます。このメトリクスはカウントを表し、1 秒に 1 回測定されます。これは、Aurora Serverless v2 の新しいメトリクスです。
TempStorageThroughput。DB インスタンスに関連するローカルストレージとの間で転送されるデータの量です。このメトリクスはバイトを表し、1 秒に 1 回測定されます。これは、Aurora Serverless v2 の新しいメトリクスです。
通常、Aurora Serverless v2 DB インスタンスのスケールアップの大部分は、メモリ使用率と CPU アクティビティに起因しています。TempStorageIops および TempStorageThroughput のメトリクスは、DB インスタンスとローカルストレージデバイス間の転送のためのネットワークアクティビティが、予期しない容量増加の原因となるまれなケースを診断するのに役立ちます。
Aurora Serverless v2 でのパフォーマンスとスケーリング - Amazon Aurora
これら2つのメトリクスはすべての環境で一律に閾値設定してアラートを発報させる、といった性質のものではないため、原因調査の一助として考慮いただくのがよいかと思います。
本稿がどなたかのご参考になれば幸いです。
