Autonomous DBのCPU自動スケーリングを試してみた

# はじめに

Autonomous DatabaseはOracle社が提供するパブリッククラウドOracle Cloud Infrastructure(OCI)上で稼働するOracle Databaseのフルマネージドサービスになります。
Autonomous Databaseの特長の一つに、**無停止＆自動スケーリング**というものがあります。
具体的には、負荷に応じてCPUリソースを無停止でスケールアップ・ダウンしてくれる、という機能になります。
なお、秒単位で利用した分のコア料金が課金される、と説明されています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2313926/6a93faee-4ea6-c7d1-9e68-223ebceeae9a.png)

(出典：https://speakerdeck.com/oracle4engineer/adb-s-technical-detail-jp?slide=16)

同じように負荷に応じてCPUリソースがスケールアップ・ダウンされるDBaaSとして有名なものに AWS の Aurora Serverless があり、そちらはもともと v1 の時は 負荷に対するスケールアップに時間がかかっていたが v2 では改善されて秒単位でスケールアップできるようになりました。

Autonomous DBではどのような形でスケールアップされるのか気になったので、試してみました。

# Autonomous Databaseについて

Autonomous Databaseは前述のとおりOCIで提供されるOracle DatabaseのフルマネージドなDBaaSになります。
Dedicated(占有)とServerless(共有)の2つのデプロイメント方式があり、また、ATP、ADW、AJD、APEXという4つのワークロードがあります。

詳細は Oracle社の資料 [Autonomous Database Serverless 技術詳細](https://speakerdeck.com/oracle4engineer/adb-s-technical-detail-jp) や [Autonomous Database - Dedicated 技術詳細](https://speakerdeck.com/oracle4engineer/adb-d-technical-detail-jp) を参照頂ければと思いますが、今回は一番手軽に利用できる(と思われる) Autonomous Database Serverless の ATP (OLTP/汎用ワークロード向け) を中心に説明します。

また、Autonomous DBではCPUリソースを ECPU という単位で表しています。
2024/10時点では 1物理コア(OCPU) = 4ECPU となっていますが、今後CPUの進化があっても 1ECPU のパフォーマンスは一定にするという考え方のようです。

#### Autonomous Databaseの自動スケーリング機能について

Autonomous Databaseの自動スケーリング機能は次のようにまとめられています。

- システムの負荷状況に応じて、CPU/IOリソースを拡張、または縮⼩が可能
    - ベースECPUに対して最⼤3倍までオンラインで⾃動スケーリング、I/O帯域はベースECPU数の時の値の3倍になる
    - 最⼤セッション数やメモリサイズはベースECPU数に紐づくため変化しない
    - 上限は512 ECPU（ベースECPUが256の場合も上限はECPU=512）
    - SE BYOLの場合の上限は32 ECPU
    - セッション数やメモリサイズはベースECPUに紐づくため変化しない
        - 基本的にはHIGH/MEDIUM接続における⾃動パラレル設定のパラレル度もベースECPUに紐づく

  
- ⾃動スケーリング有効時の課⾦⽅法（設定値が8 ECPUの場合の例）
    - 負荷が低い場合はベースECPU数(8)
    - 負荷が⾼くベースECPUを超える場合は、ベースECPU数の3倍x 平均CPU使⽤率、⼩数点以下は切り上げ
    - ベースが8 ECPUで⾃動スケーリングをONにすると最⼤24 ECPUとなり、1時間あたりの平均消費ECPUが50%であれば12 ECPU分が課⾦される
- 設定⽅法
    - 新規インスタンス作成時、⾃動スケーリングの有効/無効を選択
    - 既存インスタンスに対してもオンラインで有効化、無効化が可能

(出典：https://speakerdeck.com/oracle4engineer/adb-s-technical-detail-jp?slide=77)

# Autonomous Databaseの自動スケーリング試してみた

Autonomous Databaseの自動スケーリングの計算は次のように説明されています。
> コンピュート自動スケーリングが有効になっている場合、データベースは、Oracle Cloud Infrastructure Consoleの「ECPU数」または「OCPU数」フィールドに示すように、ECPU数(データベースでOCPUを使用している場合はOCPU)で指定された数より最大3倍多いCPUおよびIOリソースを使用できます。

（出典：[Autonomous Databaseの自動スケーリングの計算](https://docs.public.oneportal.content.oci.oraclecloud.com/ja-jp/iaas/autonomous-database-serverless/doc/autonomous-auto-scale.html#GUID-82D88D8F-BDD6-499B-997E-57E586BABD4B)）

ちょっとわかり辛いですが、自動スケーリングを 有効 にした場合、あらかじめシステムとしては設定されたECPUの3倍のリソースが割り当てられる形となります。

では、実際に試してみます。

#### 自動スケールなし

ECPUを**2**に、自動スケーリングを **無効** にしたAutonomous Databaseをデプロイします。


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2313926/2caace26-f845-8e37-856a-b8cae974204b.png)

CPU_COUNTを確認すると **2** になっていることが確認できます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2313926/cc23a078-f371-25af-63b9-3f6a7386edf4.png)

CPUへの負荷をかけると、使用率が100%になっていることが確認できます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2313926/d6a0ffdb-9c65-aa6b-dc15-0dac06c810cf.png)


#### 自動スケールあり

ECPUを**2**に、自動スケーリングを **有効** にしたAutonomous Databaseをデプロイします。
（実際には変更しただけですが・・）

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2313926/2d9fba73-af1d-f05d-b84e-7bd0756a9c7c.png)


CPU_COUNTを確認すると **6** となり、設定値の3倍の値が割り当てられていることが確認できます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2313926/c36a8775-27fb-7e19-9b7b-7c5fcecf76a6.png)

同じ負荷をかけると、今度は40%弱くらいのリソース使用状況になりました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2313926/26c84f01-fa6c-f642-c787-1480fc399328.png)

# まとめ

Autonomous DatabaseのCPU自動スケーリングについて確認してみました。
負荷に対してのスケーリングとしては、(内部的には割り当て済ということもあり)タイムラグなくCPUリソースが利用できることを確認できました。

上述のとおり、IOリソース含めて3倍が割り当てられるため、だいぶお得な設定かと思いますので、Autonomous Databaseを利用する場合には有効化しておくとよさそうですね。

# おまけ

自動スケーリングはトランザクション影響なく行われています。
一方で、手動スケーリングだとどのような動きになるでしょうか？
ECPUを **2** から **4** に変更し、その間に一つのトランザクション内で 0.5秒ごとに insert を行ってみました。結果、以下の通り変更されている時間でもトランザクションへの影響がないことを確認できました。

CPUリソース消費が少しずつ増加してきた場合でも、自動スケールだけに頼ることなく対応ができますね。

- CPU手動スケール前
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2313926/21bf3dc2-b642-c6c0-10b3-6148bba6e4a9.png)

- CPU手動スケール後
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2313926/a661bf71-2f9a-fa93-b25b-2d8983a3bb17.png)


- (スケール後の)テーブルの状態

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2313926/9de97505-7945-3d42-a900-1eeab241fa47.png)