もしもみなみんがDBをクラウドで動かしてみたら indexページ ▶▶
※本記事は2019/5時点のものになります
みなさん、こんにちは。
ついに、日本にOracle Cloudの第２世代のOracle Cloud Infrastructure がやってきました！
プレス・リリース オラクル、次世代クラウド・データセンターを東京に開設(2019/05/08)
東京リージョンでは、本連載で取り上げているOracle DatabaseのPaaSサービスである、Autonomous Database・Oracle Cloud Infrastructure Database (VM/BM)・Oracle Cloud Infrastructure Exadataももちろん利用可能です！現在利用可能なサービスはこちらData Regions for Platform and Infrastructure Services
今後も利用可能なサービスがどんどん拡充していく予定です。
そんな興奮冷めやらぬ中、今月はAutonomous Databaseでのスケール・アップ/ダウンについて解説していきます。
■1. Autonomous Databaseのスケール・アップ/ダウンの対象は？
Autonomous Database (Autonomous Data Warehouse (ADW)/Autonomous Transaction Processing (ATP))は、動的に、かつCPU・ストレージをそれぞれ個別に変更することが可能です。
- CPUコア数とストレージサイズ(TB)が対象
- どちらも１～１２８の数値で増減可能
- スケーリング(リソース変更)はオンラインで実施される
これらのリソースは、利用している”データベース”が利用可能なリソース割り当てを増やしたり減らしたりする形になります。
・マニュアル
Oracle Cloud Infrastructure Documentation > Database > Autonomous Databases > Autonomous Databaseの管理
では早速、スケール・アップ/ダウンについて、実施する方法やスケール・アップによる性能への効果について見ていきましょう。
■2. CPUスケール・アップで性能向上するのか
スケール・アップ/ダウンの方法について触れる前に、まずはCPUネックの処理を実行して性能向上するのかを確かめてみた結果を紹介します。果たしてCPUのスケール・アップで性能は向上するのでしょうか
<本検証の内容と設定>
- 2/4/8/16 OCPUの４ケースで実施
- CPUネックのクエリを利用(=CPU使用率100%の状態)
- リザルト・キャッシュは無効化(デフォルト有効)
- パラレル処理になるように、接続サービスは HIGH を利用(=自動でパラレル実行数が決まる状態)
今回のテストの内容はしばちょう先生の連載を参考にしていますので、簡単に試してみたい方は是非下記をご参照ください。
(下記の記事内のクエリを利用するとすぐに処理が終わってしまうので、本検証では扱うデータ量を大幅に増やすように少し書き換えています)
・ しばちょう先生の試して納得！DBAへの道 第５３回 SQLパフォーマンスの高速化の限界を目指せ!(1)
結果はこの通り！CPUをスケール・アップすると、その分実行時間が短くなっていますね。見事CPUのスケール・アップをするだけで、高速化できました！(ぱちぱち)
なぜ性能向上したかというと、一番大きな理由はCPUを追加すればその分パラレル実行できる数が増えるからです。
Oracle Databaseの自動パラレル機能がデフォルトで有効なサービス HIGH に接続して実行しているので、CPU数を増やすと、ユーザーが意識することなく自動でパラレル実行数を増やして実行してくれます。
また、CPU数に応じてI/O制御の割り当て帯域も増えるようになっています。
ただ、I/Oに関してはExadataの機能によってできるだけI/Oを削減させる動きをするので、もともとI/O量が少ないこともあり、CPUバウンドのクエリほど大幅な変化はありませんでした。そこは、処理を高速化するために処理量を削減させるというExadata上ならではメリットのですね。
補足ですが、スケール・アップすることで性能向上するかは処理によります。
今回はCPUネックの処理を対象にしたのでリニアに上がっていますが、CPU以外の部分がネックになっていれば大幅な改善は見られないケースや、並列度が増えていくと別の部分がネックになってくるケースもあります。とはいえ、「じゃあ効率のいい並列度はどれくらい？」というのを考えるのも大変ですよね。並列度はOracle Databaseの自動並列度の機能に任せることで、最適な並列度を判断して実行してくれるので、個人的には自動並列度を使うことをおすすめします。Autonomous Databaseでは自動並列度設定が接続サービスごとに異なりますが、有効なサービスを利用することで、赤字で前述したとおり、ユーザーが意識することなく並列処理が実行されます。自分で設定したい場合には、明示的に並列度を指定することも可能です。
また、パラレル実行が動くためにはOCPU2以上である必要があるので、OCPU2以上でお使いいたくことをお勧めします。
自動並列度の詳しい話を知りたい方は、こちらの津島博士の連載記事やホワイト・ペーパーがわかりやすいので見てみてください。
■3. スケール・アップ/ダウンしてみよう – コンソール編
では、実際にスケール・アップ/ダウンする方法を、まずはコンソール画面で見てみましょう。
対象のAutonomous Databaseの詳細ページにいくと現在のリソース、『CPUコア数』と『ストレージ(TB)』が表示されるので内容を確認し、ページの上部にある『スケール・アップ/ダウン』のボタンをクリック。
『CPUコア数』と『ストレージ(TB)』の2つの項目が表示されるので、変更したいリソース数を入力して、『更新』ボタンをクリックします。今回は、CPUコア数を2から４に変更してみます。
ステータスが『スケーリング進行中』から『使用可能』になると、リソースの内容も変わり、スケーリング成功です。
なお、オンラインでのスケーリングなので、ステータスがスケーリング進行中でもサービスの使用は可能です。
■4. スケール・アップ/ダウンしてみよう – CLI編
CLI(OCI CLI/REST/Terraformなど)でもスケール・アップ/ダウンは可能です。今回は、OCI CLIでの方法を紹介します。
<事前準備>
1. OCI CLIのセットアップ
今回はセットアップは完了している前提ですすめますが、まだこれからという方は下記をご参考にセットアップしてみてください。
・マニュアル
Oracle Cloud Infrastructure Documentation > コマンド・ライン・インターフェース > クイックスタート
・Oracle Cloud 公式ブログ コマンドライン(CLI)でOCIを操作する – Oracle Cloud Infrastructureアドバンスド
ちなみに、Oracle Cloud Developer ImageというOracle Cloudを利用する開発者向けのツールが全部入りのイメージが、マーケットプレイスから入手できるので、こちらを利用するとすぐにOCI CLIを使える状態になっているので簡単ですよ。
・参考 [OCI]Oracle Cloud Developer Imageの発表 (2019/04/02)
2. autonomous-database-idの確認
スケール・アップ/ダウンのコマンドで、対象リソースの識別子としてインスタンスのOCIDの情報が必要になります。
・コンソールからの確認
・OCI CLIでの確認
$ oci db autonomous-database list\
--query 'data[?"display-name"==`<表示名>`].{"display-name":"display-name","id":"id"}'
例
$ oci db autonomous-database list\
--query 'data[?"display-name"==`ADWEM1`].{"display-name":"display-name","id":"id"}'
[
{
"display-name": "ADWEM1",
"id": "ocid1.autonomousdatabase.oc1.phx.<xxxxxx>"
}
]
<スケール・アップ/ダウン>
では、OCI CLIでCPUとストレージをそれぞれスケール・アップしてみます。
・CPU数のスケール・アップ/ダウン
$ oci db autonomous-database update --autonomous-database-id <autonomous-database-id>\
--cpu-core-count <OCPU数>
例
--1.現在のOCPU数を確認 $ oci db autonomous-database get --autonomous-database-id xxx \ --query 'data.{"1.display-name":"display-name","2.cpu-core-count":"cpu-core-count",\ "3.data-storage-size-in-tbs":"data-storage-size-in-tbs"}' { "1.display-name": "ADWEM1", "2.cpu-core-count": 2, "3.data-storage-size-in-tbs": 1 } --2.OCPU数を4にスケール・アップ $ oci db autonomous-database update --autonomous-database-id xxx –-cpu-core-count 4 --3.変更されたか確認 $ oci db autonomous-database get --autonomous-database-id xxx \ --query 'data.{"1.display-name":"display-name","2.cpu-core-count":"cpu-core-count",\ "3.data-storage-size-in-tbs":"data-storage-size-in-tbs"}' { "1.display-name": "ADWEM1", "2.cpu-core-count": 4, "3.data-storage-size-in-tbs": 1 }
・データベース側で認識している利用可能なCPU数
SQL> col name for a15 SQL> col value for a20 SQL> select name,value from v$parameter where name='cpu_count'; NAME VALUE -------------------- -------------------- cpu_count 4
最初に「利用している”データベース”が利用可能なリソース割り当て」といったところで、Oracle Databaseになじみのある方は気付いたかもしれないですが、利用可能なCPUの数はCPU_COUNTパラメータで制御されています。そのため、スケール・アップ/ダウンをすると、CPU_COUNTの数が変わるので、利用可能なリソースの数が実際に指定した通りになっているかは、このパラメータを確認していただくとわかります。
・ストレージのスケール・アップ/ダウン
$ oci db autonomous-database update --autonomous-database-id <autonomous-database-id>\
-data-storage-size-in-tbs <ストレージサイズ(TB)>
例
--1.現在のストレージサイズを確認 $ oci db autonomous-database get --autonomous-database-id xxx \ --query 'data.{"1.display-name":"display-name","2.cpu-core-count":"cpu-core-count",\ "3.data-storage-size-in-tbs":"data-storage-size-in-tbs"}' { "1.display-name": "ADWEM1", "2.cpu-core-count": 2, "3.data-storage-size-in-tbs": 1 } --2.ストレージを2TBにスケール・アップ $ oci db autonomous-database update --autonomous-database-id <xxx> –-data-storage-size-in-tbs 2 --3.変更されたか確認 $ oci db autonomous-database get --autonomous-database-id xxx \ --query 'data.{"1.display-name":"display-name","2.cpu-core-count":"cpu-core-count",\ "3.data-storage-size-in-tbs":"data-storage-size-in-tbs"}' { "1.display-name": "ADWEM1", "2.cpu-core-count": 2, "3.data-storage-size-in-tbs": 2 }
数クリックで簡単にできますし視覚的にわかりやすいので、コンソールでの方法を紹介することが多いですが、実際にはCPUのスケール・アップ/ダウンにCLIを使いたい場面も多いのではないかと思います。
例えば、
- 特定の時間に実行されるように、スケジューリングしたい
- 夜間/月次バッチ処理など特定の処理の間だけスケール・アップするよう、処理の前後で実行したい
- 検証時に、テストケースごとにCPU数を変えて検証したい
・ マニュアル OCI CLI Command Reference DB > autonomous-database > update
■5. スケール・アップ/ダウンの影響は？
スケール・アップ/ダウンは、CPUもストレージもオンラインで行われます。そのため、実行中のトランザクションが中止されたり、セッションが切れるということがなく、必要な時=リソースが逼迫している処理中でもスケール・アップが可能です。
リソースを変更するということは、増減に合わせてリソースを使う側(今回でいえばデータベース側)の最適化作業が必要になります。リソースを簡単に追加できたとしても地味にこの作業が大変だったりしますが、Autonomous Databaseはリソース変更がオンラインで実行されるだけではなく、データベース側の変更・最適化作業(例えばデータベースのパラメータの設定や前述したパラレル度、ストレージ構成など)も、全て自動でやってくれます。
少し細かい話になりますが、利用可能なコア数はCPU_COUNTパラメータで制御されるので、CPU_COUNTに関連するパラレル関連のパラメータも動的に変わり、またprocessesやsessionsなども自動で変更されます。ストレージ構成についてはOracle Automatic Storage Management(ASM)を利用しているので、ストレージを拡張してもホットスポットが発生しないようにデータの分散配置が自動で行われ、表領域の拡張もオンラインで行われます。
■6. まとめ
今回は、Autonomous Databaseのスケール・アップ/ダウンについて取り上げましたが、いかがでしたでしょうか。簡単に、使いたいときだけ使いたい分のリソースを柔軟に利用できるのが、クラウドのメリットですよね。
検証結果をみて、「リソース足したんだから早くなって当たり前じゃないの？」と思う方もいるかもしれないですが、増やした分のリソースをきちんと使えるように最適化させるのって、自分でやろうとするとスキルも時間もそれなりに必要で、実は意外と大変なんです。こういったデータベース側の管理作業だけでなくアプリ側からみても使いやすくしているというのが、Full-Managedなデータベースのサービスといえる点の１つかと思います。
また、今回はAutonomous Databaseの内容として最適化の話をしましたが、これらはOracle Databaseの機能を利用して動いています。それらを制御したり動作させたりする部分はクラウド・ツールが行っているのでAutonomous Databaseならではですが、OCI DatabaseやOCI Exadata、オンプレミスのOracle Databaseでも機能を利用することができます。特に最適化の部分は、これまでOracle Databaseで培われた技術の上での実装・動作なので、そのあたりもぜひ実感していただければ嬉しいです。
・マニュアル
Oracle Cloud Infrastructure Documentation > Database > Autonomous Databases > Autonomous Databaseの管