Oracle Cloud の Autonomous Transaction Processing（ATP）の利点の一つでもありますが、CPUコア数及びストレージのスケールアップ・ダウンを無停止で行う事ができます。
コンソール画面からも簡単にスケール操作を行う事ができるのですが、今回は Oracle Cloud Infrastructure CLI を使用してスケール操作を行ってみたいと思います。
Oracle Cloud Infrastructure CLI のインストール方法はこちらをご確認下さい。
CPUコア数の変更
まずは、操作対象とする インスタンス名「ss-atp01」のインスタンス情報を確認します。
|
1 2 3 4 5 6 7 8 9 10 11 |
# oci db autonomous-database list --display-name ss-atp01 \ > --query "data [*].{\"1.Name\":\"display-name\", \"2.OCID\":\"id\", \"3.CPU-CORE\":\"cpu-core-count\", \"4.STORAGE\":\"data-storage-size-in-tbs\", \"5.AUTO-SCALE\":\"is-auto-scaling-enabled\"}" [ { "1.Name": "ss-atp01", "2.OCID": "ocid1.autonomousdatabase.oc1.ap-tokyo-1.abxhiljr6a・・・(略)", "3.CPU-CORE": 1, "4.STORAGE": 1, "5.AUTO-SCALE": false } ] |
以下のように出力項目を設定しています。
| 出力項目 | 項目説明 |
|---|---|
| 1.Name | インスタンス名 |
| 2.OCID | インスタンスのOCID |
| 3.CPU-CORE | CPUコア数（※） |
| 4.STORAGE | ストレージ容量（TB） |
| 5.AUTO-SCALE | 自動スケールの有効化（true:有効／false:無効） |
※リファレンスやコンソール画面上では「CPUコア数」と記載されていますが、Oracle CloudでCPU1つの物理コア相当にあたる「OCPU数」と同義です。
コンソール画面上でも、同様の情報を確認できます。
それでは、CPUコア数を「1」→「2」に変更してみます。
ATPの構成は oci db autonomous-database update で変更できます。CPUコア数は --cpu-core-count パラメータで制御します。
ATPを操作する autonomous-database に対して、Autonomous Data Warehouse Cloud（ADW）では autonomous-data-warehouse を使用しますので、誤りのないようご注意下さい。
|
1 2 3 |
# oci db autonomous-database update \ --autonomous-database-id ocid1.autonomousdatabase.oc1.ap-tokyo-1.abxhiljr・・・（略） \ --cpu-core-count 2 |
実行後にコンソール画面を確認すると、ライフサイクル状態が「スケーリング進行中」になっています。
40秒程度で完了し、CPUコア数が 2 に変更されました。
CLIで確認してもCPUコア数が 2 に変更されています。
|
1 2 3 4 5 6 7 8 9 10 11 |
# oci db autonomous-database list --display-name ss-atp01 \ > --query "data [*].{\"1.Name\":\"display-name\", \"2.OCID\":\"id\", \"3.CPU-CORE\":\"cpu-core-count\", \"4.STORAGE\":\"data-storage-size-in-tbs\", \"5.AUTO-SCALE\":\"is-auto-scaling-enabled\"}" [ { "1.Name": "ss-atp01", "2.OCID": "ocid1.autonomousdatabase.oc1.ap-tokyo-1.abxhiljr・・・（略）", "3.CPU-CORE": 2, "4.STORAGE": 1, "5.AUTO-SCALE": false } ] |
ストレージ容量の変更
--data-storage-size-in-tbs パラメータを指定して、ストレージを「1」(TB) →「3」(TB) に変更してみます。
|
1 2 3 |
# oci db autonomous-database update \ > --autonomous-database-id ocid1.autonomousdatabase.oc1.ap-tokyo-1.abxhiljr・・・（略） \ > --data-storage-size-in-tbs 3 |
２分程度でスケール操作が完了し、3 TB に変更されました。
CLIでも変更されている事を確認します。
|
1 2 3 4 5 6 7 8 9 10 11 |
# oci db autonomous-database list --display-name ss-atp01 \ > --query "data [*].{\"1.Name\":\"display-name\", \"2.OCID\":\"id\", \"3.CPU-CORE\":\"cpu-core-count\", \"4.STORAGE\":\"data-storage-size-in-tbs\", \"5.AUTO-SCALE\":\"is-auto-scaling-enabled\"}" [ { "1.Name": "ss-atp01", "2.OCID": "ocid1.autonomousdatabase.oc1.ap-tokyo-1.abxhiljr・・・（略）", "3.CPU-CORE": 2, "4.STORAGE": 3, "5.AUTO-SCALE": false } ] |
自動スケーリングの有効化・無効化
--is-auto-scaling-enabled パラメータを指定して、自動スケーリングを「有効」にしてみます。
|
1 2 3 |
# oci db autonomous-database update \ > --autonomous-database-id ocid1.autonomousdatabase.oc1.ap-tokyo-1.abxhiljr・・・（略） \ > --is-auto-scaling-enabled true |
30秒程度で完了し、自動スケーリングが有効になりました。
CLIでも変更されている事を確認します。
|
1 2 3 4 5 6 7 8 9 10 11 |
# oci db autonomous-database list --display-name ss-atp01 \ > --query "data [*].{\"1.Name\":\"display-name\", \"2.OCID\":\"id\", \"3.CPU-CORE\":\"cpu-core-count\", \"4.STORAGE\":\"data-storage-size-in-tbs\", \"5.AUTO-SCALE\":\"is-auto-scaling-enabled\"}" [ { "1.Name": "ss-atp01", "2.OCID": "ocid1.autonomousdatabase.oc1.ap-tokyo-1.abxhiljr・・・（略）", "3.CPU-CORE": 2, "4.STORAGE": 3, "5.AUTO-SCALE": true } ] |
まとめ
CLIでスケール操作を行う事でスケジューラや cron を使用して、アクセス数が多く負荷が高くなる時間帯にスケールアップ、逆に負荷の少ない時間帯にはスケールダウンをする事で、コストの軽減が見込めます。
冒頭に記載した通りスケール操作は無停止で制御できるので、有効に活用して安定したパフォーマンスを発揮させましょう。
今後、スケール操作による性能の変化についても検証し、本ブログで紹介していきたいと思います。
