X

A blog about Oracle Technology Network Japan

  • November 20, 2019

第15回 Autonomous Databaseの自動スケーリングを設定してみよう

Eriko Minamino
Solution Engineer

もしもみなみんがDBをクラウドでうごかしてみたら 連載Indexページ

※本記事は2019/11/20時点のものになります

みなさん、こんにちは。

今回は、第13回で紹介したAutonomous DatabaseのOCPUスケール・アップ/ダウンを自動で行ってくれる、自動スケーリング機能について紹介したいと思います!

 

Autonomous Databaseの自動スケーリング機能とは

Autonomous Databaseの自動スケーリング機能は、負荷状況に応じてOCPUリソースを自動でアップ/ダウンしてくれる機能です。

負荷状況に応じて、OCPU数とI/O帯域が変動
・有効にしているOCPU数の最大3倍(*1)まで自動で即座に増減
インスタンス再起動やコネクション切断なく動的に実施
・課金は1時時間あたりのOCPU利用状況に応じて決定
 
(*1) Autonomous Database Serverlessの最大OCPU数は128 OCPUなので、3倍の数が128を超える場合は最大128まで


手動で実行する場合との違いはあるの?

自動スケーリングによるスケール・アップ/ダウンした場合は、OCPU数に応じて設定される各種設定はそのままの設定で動き続けます。具体的には、メモリサイズや事前定義済の接続サービスで設定されているパラレル実行数や同時実行セッション数等の設定などは、有効にしているベースのOCPU数に基づいた設定が利用されます。

事前定義済のサービスについてはこちら : Autonomous Databaseの接続サービスとシェアについて

 

設定方法

Autonomous Databaseを新規で作成する際に、そのインスタンスで自動スケーリング機能を有効にするかどうかを指定します。後からの変更も可能です。

新規作成時の設定

自動スケーリングを有効にする場合には、『自動スケーリング』にチェックをいれてインスタンスを作成します

設定情報は、サービス詳細ページの『Autonomous Database 情報』から確認できます。

設定の変更方法

コンソール(WebUI)やREST APIなどで設定変更が可能です。設定の変更も、オンライン(インスタンス再起動なし)で実施されます。

・コンソール

サービス詳細ページの上部の『スケール・アップ/ダウン』をクリック

『自動スケーリング』のチェック有無で有効化/無効化を切り替えられます。切り替えはオンラインで行われるので、インスタンスの再起動はありません。

 

・OCI CLI

#OCI CLIのセットアップは完了している前提ですすめますので、まだこれからという方は下記をご参考にセットアップしてみて下さい
・マニュアル Oracle Cloud Infrastructure Documentation > コマンド・ライン・インターフェース > クイックスタート
・Oracle Cloud 公式ブログ コマンドライン(CLI)でOCIを操作する – Oracle Cloud Infrastructureアドバンスド

OCI CLIで操作する際に対象リソースの識別子としてインスタンスのOCIDの情報が必要になるので、事前に確認しておきましょう。

設定状況は、oci db autonomous-database get でインスタンスの情報を出力することで確認可能です。

$ oci db autonomous-database get --autonomous-database-id <Autonomous Databaseインスタンスのocid> 

$ oci db autonomous-database get --autonomous-database-id xxxx  --query 'data.{"1.display-name":"display-name","2.cpu-core-count":"cpu-core-count","3.is-auto-scaling-enabled":"is-auto-scaling-enabled"}'
{
  "1.display-name": "ATPEM", 
  "2.cpu-core-count": 2, 
  "3.is-auto-scaling-enabled": false
}

変更は、oci db autonomous-database update で --is-auto-scaling-enabled の設定をtrueもしくはfalseに更新することで設定変更されます。

$ oci db autonomous-database update --autonomous-database-id <Autonomous Databaseインスタンスのocid> --is-auto-scaling-enabled [true/false]

$ oci db autonomous-database update --autonomous-database-id xxxx --is-auto-scaling-enabled true
....
$ oci db autonomous-database get --autonomous-database-id xxxx --query 'data.{"1.display-name":"display-name","2.cpu-core-count":"cpu-core-count","3.is-auto-scaling-enabled":"is-auto-scaling-enabled"}'
{
  "1.display-name": "ATPEM", 
  "2.cpu-core-count": 2, 
  "3.is-auto-scaling-enabled": true
}

・ マニュアル OCI CLI Command Reference DB > autonomous-database > update

 

 

自動スケーリング機能を使ってみよう

実際に自動スケーリングを使った場合と使わない場合で負荷をかけて、どのようになるかを違いをみてみました

本検証の内容と設定

・ 利用サービス :Autonomous Transaction Processing (ADWでも可)
・ OCPU数 : 2 
・ CPUボトルネックになる処理を並列実行
・ 接続サービスはLOWを利用
・ 自動スケーリングを有効/無効した環境でのCPU使用率や実行数などを確認

テストデータや利用したSQLは第13回同様、しばちょう先生の連載を参考にしていますのでぜひご参考までに。
しばちょう先生の試して納得!DBAへの道 第53回 SQLパフォーマンスの高速化の限界を目指せ!(1)

 

結果

Autonomous Databaseのサービス・コンソールから確認できるアクティビティ情報の各グラフを利用して、解説していきます。(平均値が表示されているグラフなので左右で全く同じグラフにはなりません)
左側が自動スケーリングが無効なインスタンスで、右側が有効にしているインスタンスです。09:59頃から処理を流し始め、10:03頃からCPU使用率が高くなっています。

まずはCPU使用率からみてみましょう。

無効化しているインスタンスは、処理数を増やしたところからずっとCPU使用率が100%で張り付き、リソースが逼迫している状態で動き続けています。対して有効化しているインスタンスは処理数を増やしたところで一気にCPU使用率が上昇しますが、スケール・アップされたため利用可能なコア数が増えことから、100%にはならずにリソースに余裕がある状況で実行されていますね。(もちろん負荷によっては3倍のリソースでも不足することもあるので、スケール・アップしたとしてもリソース枯渇する可能性はあります)

次に、Database Activityの情報を見てみます。

無効化しているインスタンスは、処理数を増やしたところからグレーの層(Scheduler)が出てきていますね。これは待機している処理/セッションがある状態を示しています。対して有効化しているインスタンスは、処理数が増えてCPU使用率が上昇したことから自動的にコア(OCPU)が増やされたため、処理に対して割り当てられるコアが増え、待機せずに処理が動いていることがわかるかと思います。

その結果、無効化の場合には22分かかった処理が、有効化にした場合には7分で完了しました。

さて、最後に課金がどのようになったのか見てみます。こちらもサービス・コンソールの画面から確認できるOCPU数のグラフ(1時間単位)です。今回、下記のグラフの矢印のあたりが自動スケール・アップされた時間帯ですが、、、あれ?OCPU数が2のまま?!お得?!

課金に関しては、ベースのOCPU数もしくは最大OCPU数 x 平均CPU使用率のどちらか大きい方になります。今回はスケールアップされたのは数分のみだったこともあり、上記計算式で課金対象のOCPU数はスケール・アップされたOCPU数ではなくベースの有効にしている2のほうが大きくなったので課金も2になったようですね。もちろん、計算式で最大OCPU数 x 平均CPU使用率の方が大きくなれば結果は変わるのでご注意ください。

※課金の部分に関しては2019/11時点の情報であり利用状況によって異なりますので、あくまで参考情報として見てください。

 

まとめ

自動スケーリングを実際に利用してみて、CPU使用率が上昇し割り当て済のリソースよりも多くのリソースが必要となる状態において、処理実行中においても影響なく自動でコアが増え(スケール・アップ)、それにより処理が遅延せずに実行されたことがわかりました。

負荷状況に応じて自動でスケール・アップ/ダウンされる場合、課金面や実行中のトランザクションへの影響について気になる人も多いと思います。実行中のトランザクションの影響に関しても、インスタンスの再起動なく行われ、実際に高負荷な状況になっている際に勝手にリソースが増えていたので、実行中の処理に影響なくリソースが割り当てられて即座に利用できるというのは助かりますね。課金に関しては、ベースのOCPU数もしくは最大OCPU数 x 平均CPU使用率のどちらか大きい方。1時間あたりの最大値ではなく実際の利用状況に応じた決定になるというのはいい点ですね。

 

 

関連リンク

・Oracle Cloud Infrastructure ドキュメント Autonomous Database 英語/日本語
・Autonomous Transaction Processing マニュアル 英語/日本語
・Autonomous Data Warehouse マニュアル 英語/日本語
・Release Note(英語) Auto scaling Autonomous Databases 
・Autonomous Database サービス・アップデート 日本語
・Autonomous Database 技術詳細資料 日本語

 

もしもみなみんがDBをクラウドでうごかしてみたら 連載Indexページ

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.