BLOCK VOLUMEの 動的パフォーマンススケー リングを触ってみた asahide 2022/11/15 OCIjp 1

０．自己紹介 asahide • 主に金融システムに従事するSE ・ Oracle DB ：20年くらい？ ・ OCI ：3年 ・ その他クラウド ：7年くらい？ その他クラウド上 の Or a cl eと か Po s t g re S Q L を 中 心 に 、 、 OCIを使った活動 • 基幹系システム構築 ・ フロント系システムのOCIリフト（一部シフト含む） ・ バック系システムのOCI上でのリファクタリング （OKEを利用したコンテナ化） • その他 ・ こまい検証とか、、 OCIjp 2022/11/15 2

１．はじめに OCIjp 2022/11/15 3 • 2022年8月30日に「Announcing dynamic performance scaling with OCI Block Volume auto - tuning（OCI Block Storageの自動チューニングによる動的パフォーマンス・スケーリング）」という機能が発表され た(https: / / bl o g s . o r a cl e. c o m / o r a cl e4 en g i nee r / p o s t / ja - an n - d yna m i c - p e rf o rm an c e - s c ali n g ) • 一般的にクラウド上のブロックストレージでは、高性能ストレージを利用する場合には予めio等をプロビジョニングしておく 必要があり、しかも高価なものというイメージがある - AWS Provisioned IOPS SSD ボリューム - Azure Ultra Disk, Premium SSD - Google Cloud エクストリーム永続ディスク • 自動チューニングされるパフォーマンス・スケーリングは初？（OCIのAutonomousな思想？）

２．動的パフォーマンス・スケーリングって？ OCIjp 2022/11/15 4 • 動的パフォーマンス・スケーリングの二つのタイプ 1. パフォーマンス・ベースの自動チューニング:このオプションを有効にすると、ブロック・ボリュームでは、そのボリュームでモニ ターされたパフォーマンスに基づき、指定したレベルの中でボリュームのパフォーマンスが調整される。 2. デタッチ済ボリューム自動チューニング:このオプションを有効にすると、ブロック・ボリュームでは、ボリュームとインスタンス がアタッチされているかデタッチされているかに基づいて、ボリュームのパフォーマンス・レベルが調整される。 https://docs.oracle.com/ja-jp/iaas/Content/Block/Tasks/autotunevolumeperformance.htm

３．パフォーマンス・ベースの自動チューニング OCIjp 2022/11/15 5 • ボリュームで実際にモニターされたパフォーマンスに基づき、指定したレベルの中でボリュームのパフォーマンスが調整される • 自動チューニングによるパフォーマンス・ベースの動的スケーリングを有効にする場合は、デフォルトのパフォーマンス設定 (VPU/GB(※))を指定する（これが、ボリュームがインスタンスにアタッチされる際に調整される一番低いパフォーマン ス・レベルになる。ボリュームが調整される一番高いパフォーマンス・レベル(VPU/GB)も指定する） ※VPU/GBについては末尾で補足する https://docs.oracle.com/ja-jp/iaas/Content/Block/Tasks/autotunevolumeperformance.htm#perf

４．デタッチ済ボリューム自動チューニング OCIjp 2022/11/15 6 • ボリュームのアタッチ状況に基づいて、ボリュームのパフォーマンス・レベルが最適に調整される • ボリュームがデタッチされると、ブロック・ボリューム・サービスにより、ブロック・ボリュームとブート・ボリュームの両方のパフォー マンス・レベルが、「より低いコスト」(0VPU/GB)に調整される（デタッチ後14日経過後に変更される） • ボリュームが再アタッチされると、パフォーマンスは、デフォルトのVPU/GB設定で指定されたパフォーマンス・レベルに戻る • 自動チューニングによるパフォーマンス・ベースの動的スケーリングも有効になっている場合は、それがこの時点で有効にな り、ボリュームを使用するワークロードの必要に応じて、パフォーマンスがさらに動的にスケーリングされる https://docs.oracle.com/ja-jp/iaas/Content/Block/Tasks/autotunevolumeperformance.htm#detached

５．動的パフォーマンス・スケーリング試してみる OCIjp 2022/11/15 7 • 試してみる事 ① デフォルトのバランス・ボリュームと、スケーリング・ボリュームを作る ② 両方に負荷をかけて、スケーリング・ボリュームがチューニングされていることを確認する（複数回実施） ③ 負荷を止めてスケーリング・ボリュームがどうなるか確認する ④ デタッチしてスケーリング・ボリュームがどうなるか確認する ←14日後なので・・・

５．１．ボリューム作成 OCIjp 2022/11/15 8 ブロックボリュームの作成 OCIを使った活動 カスタムを選択

５．２．ボリューム・パフォーマンスのカスタマイズ OCIjp 2022/11/15 9 • 自動チューニングは最低10VPU/GB、 最大の120VPU/GBまでの間で選択 可能 【注意】：記載あるように、実際のブロック ボリュームのパフォーマンスはアタッチされて いるインスタンスシェイプの帯域に依存する また、超高速タイプ（30 VPU/GB以 上）はマルチパス構成が必要となる マルチパス構成は16コア以上の環境で自 動的に利用可能となる オンにするとVPU/GBが選択 できるようになる オンにするとVPU/GBが選択 できるようになる 最低値と最大値を選択可能 デタッチ済みのチューニング機 能のON/OFF

５．３．作ったボリュームの確認 OCIjp 2022/11/15 10 デフォルトのボリューム 動的パフォーマンスボリューム • 自動チューニングをオンにしたボリュームは「自動チューニ ング」がオンとなる • 今回のボリュームは動的パフォーマンスボリュームの最低 VPU/GBを10のデフォルトと同じ設定にしたので、パ フォーマンスは最初は同じとなる 【注意】：インスタンスシェイプがVM.Standard.E2.1.Microの 1OCPUモデルのため、マルチパスが設定できていない

５．４．負荷掛けの実施 OCIjp 2022/11/15 11 • 負荷掛け内容 - 1GBのファイルをデフォルトのボリューム、動的パフォーマンスボリュームそれぞれに作成 - デフォルトのボリュームより、動的パフォーマンスボリュームの方が5%程度速くなっている！？ デフォルトの ボリューム 動的パフォーマンス ボリューム 1048576000 bytes (1.0 GB, 1000 MiB) copied, 38.295 s, 27.4 MB/s 1048576000 bytes (1.0 GB, 1000 MiB) copied, 35.7843 s, 29.3 MB/s

５．５．負荷掛け直後の動的パフォーマンス・ボリューム OCIjp 2022/11/15 12 動的パフォーマンスボリューム 負荷掛け後 動的パフォーマンスボリューム 負荷掛け前 • 負荷掛け直後にスループットが向上してい る事が確認できる - パフォーマンスの自動チューニング バランス(VPU/GB:10) →より高いパフォーマンス(VPU/GB:20) - 自動チューニングIOPS 3,000IOPS → 3,750IOPS - 自動チューニング・スループット 24MB/秒 → 30MB/秒 (30VPU/GB以上にならないのはマルチパスではないため)

５．６．再度負荷掛けの実施 OCIjp 2022/11/15 13 • 二回目の負荷掛け内容 - 1GBのファイルを2並列でデフォルトのボリューム、動的パフォーマンスボリュームそれぞれに作成 - 初回よりも動的パフォーマンスボリュームの性能が向上している(二回目は最初からハイパフォーマンスになっていたため) デフォルトの ボリューム 動的パフォーマンス ボリューム 1048576000 bytes (1.0 GB, 1000 MiB) copied, 68.3002 s, 15.4 MB/s 1048576000 bytes (1.0 GB, 1000 MiB) copied, 70.7458 s, 14.8 MB/s 1048576000 bytes (1.0 GB, 1000 MiB) copied, 54.4484 s, 19.3 MB/s 1048576000 bytes (1.0 GB, 1000 MiB) copied, 56.7248 s, 18.5 MB/s 初回と同じ内容にすべきでした。。。 合計：30.2MB/s 合計：37.8MB/s

５．７．負荷掛け停止後のボリュームの確認 OCIjp 2022/11/15 14 動的パフォーマンスボリューム 無風状態で1時間経過後 動的パフォーマンスボリューム 二回目負荷掛け後 • 負荷を停止し、しばらくするとパフォーマンス の自動チューニングも元に戻っていた 【注意】：１時間後くらいに見たら戻っていたた め、いつ戻るのかは不明

まとめ パフォーマンス・ベースの自動チューニングは結構良いっぽい • 負荷に応じて、素早く（初回の負荷掛けは40秒弱）で自動チューニングされた • 負荷が少ない場合にも自動的にデチューンされ、コスト負荷を低減してくれる • 最初から巨大なIOをプロビジョンする必要がなく、必要な分を自動的に割り当ててくれる、Autonomous！ • 自動チューニングも少なくとも10⇒20は1分以内に実施されており、例えば夜間BT等を想定した場合でも全く問題なく立 ち上がると想定できる • 例えばオンライン時間帯はディスク負荷は少ないと想定され、その時間帯はデチューンされてコスト低減が期待できる OCIjp 2022/11/15 15

補足：動的パフォーマンス・ボリュームの性能指標と価格 OCIjp 2022/11/15 16 https://www.oracle.com/cloud/storage/pricing/ https://docs.oracle.com/ja-jp/iaas/Content/Block/Concepts/blockvolumeperformance.htm#perf_levels IO回数ではなく、あくまでボリュームに対 する課金となる 性能はボリュームサイズに も依存するので注意

補足：超高パフォーマンス・ボリュームのためのアタッチメントの構成 OCIjp 2022/11/15 17 https://docs.oracle.com/ja-jp/iaas/Content/Block/Tasks/configuringmultipathattachments.htm#multipath • 超高パフォーマンス・レベルで構成されたボリュームをアタッチして、最適なパフォーマンスを実現するには、ボリューム・ア タッチメントをマルチパス対応にする必要がある • ブロック・ボリューム・サービスでは、ボリュームをアタッチする際に、アタッチメントがマルチパス対応になるよう試行される。 • 満たしていない前提条件があると、ボリューム・アタッチメントはマルチパス対応にならない。（前提条件等は以下の URL で確認ください）

ありがとうございました