こんにちは。イオンスマートテクノロジー株式会社（AST）でSREチームの林 aka もりはやです。
本記事はAzureのマネージドなMySQLである”Azure Database for MySQL Flexible Server”の2つのIOPS設定の機能やコストについてまとめたものです。
TL;DR
始めにまとめです。本記事では以下について記述しました。
- Azure Database for MySQL Flexible ServerのIOPSの設定は2つある
- 従来の固定式なPre-provisioned IOPS
- 動的に最適化されるAuto scale IOPS
- サポート停止するAzure Database for MySQL Single Serverと異なり、IOPSのMAXはディスク容量ではなくCompute sizeによって決定される
- 幅位広いワークロードに対して有効なのはAuto scale IOPSである
- シンプルにコスト比較するなら実際に動作したインスタンスのStorage IO Count metricを見る
MySQL Single Serverのサポート終了
AzureユーザでAzure Database for MySQL Single Server（以後Single Server）を利用していた皆様は、2024年09月16日のサポート終了に向けて全てAzure Database for MySQL Flexible Server（以後Flexible Server）へ移行が終わった頃だと思います。（私たちASTも開発チームの頑張りによって無事に移行を終えました）
上記の公式アナウンスによれば、Single Serverが終了するのはセキュリティ影響が主な理由となっています。
Running the Single Server instance post sunset date would be a security risk, as there will be no security and bug fixes maintenance on the deprecated Single Server platform.
セキュリティは当社のような社会的責任あるサービスを運用する際に最優先すべき事項である一方、明確なメリットとして理解されづらい観点でもあります。
この点に関しても上記のアナウンスはフォローしておりFrequently Asked Questions (FAQs) の段落において明確にコストメリットや運用負荷軽減について記載があります。
Q. Why am I being asked to migrate to Azure Database for MySQL - Flexible Server?
A. Azure Database for MySQL - Flexible Server is the best platform for running all your MySQL workloads on Azure. Azure MySQL- Flexible server is both economical and provides better performance across all service tiers and more ways to control your costs, for cheaper and faster disaster recovery:
- More ways to optimize costs, including support for burstable tier compute options.
- Improved performance for business-critical production workloads that require low latency, high concurrency, fast failover, and high scalability.
- Improved uptime with the ability to configure a hot standby on the same or a different zone, and a one-hour time window for planned server maintenance.
今回焦点を当てるのは上記の中でも"More ways to optimize costs"の観点から"Auto scale IOPS"になります。
従来のSingle ServerにおけるIOPSはディスク容量に比例した
Flexible ServerのFlexible（柔軟）たるポイントの一つが"Auto scale IOPS"です。従来のSingle Serverにおいて、IOPSはディスク容量に紐づくものでした。
Resource limits for single databases using the vCore purchasing model
上記のSingle Serverの制約からIOPS部分について引用します。(上記ページはSingle Serverのサポート終了とともに消える可能性があります...）
| Storage type | Basic | General purpose v1 | General purpose v2 |
|---|---|---|---|
| Storage size | 5 GB to 1 TB | 5 GB to 4 TB | 5 GB to 16 TB |
| Storage increment size | 1 GB | 1 GB | 1 GB |
| IOPS | Variable | 3 IOPS/GB Min 100 IOPS Max 6,000 IOPS |
3 IOPS/GB Min 100 IOPS Max 20,000 IOPS |
表からSingle ServerのIOPSについてポイントをまとめます。
- General purpose v1とv2でMAX IOPSが3倍以上の差がある(
6,000 vs 20,000) -
3 IOPS/GBより、割り当てたディスク容量によってIOPSが決定される
具体的にはGeneral purpose v2のMAX IOPS 20,000 をサービス・アプリケーションが要求した場合、 20,000 / 3 = 約6,666.6GB = 約6.7TB 以上のディスク容量が必要であることを意味します。
この制約によって当社のSingle Serverの利用においてIOPSの確保を目的として大幅に超過したディスク容量を割り当てるケースがありStorage Used(%) が1%を下回るインスタンスが存在する状況でした...
Flexible Serverは柔軟なIOPS指定が可能になった、ただしCompute sizeによる
上述したSingle Serverの制約に対し、Flexible ServerはIOPSの指定がディスク容量の制約から完全に切り離されています。
には以下のように説明されています。
You can use pre-provisioned IOPS to allocate a specific number of IOPS to your Azure Database for MySQL - Flexible Server instance.
ここで気をつけなければならない点として、Flexible ServerのMAX IOPSはディスク容量に影響されなくなりましたが、Compute sizeによって制限される点です。
以下は実際にFlexible Serverを作成する画面です。Compute sizeによってMAX IOPSが明確に制限されていることがわかります。（例: Standard_D16ads_v5の場合 20,000 max iops）
この指定可能なIOPSの制限が、ディスク容量からCompute sizeによって制限される変更は多くのシステムにとって好意的な変更と言えるでしょう。一般的に高いIOPSを必要とするケースでは高いCPUやメモリが要求されることが多いためです。
Flexible Serverの"Auto scale IOPS"のメリット
上述したPre-provisioned IOPSだけでなく、Flexible ServerではIOPSについて"Auto scale IOPS"と呼ばれる柔軟なオプションが提供されています。
"Auto scale IOPS"の概要を以下に引用します。
Autoscale IOPS offer the flexibility to scale IOPS on demand. When you enable autoscale IOPS, your server automatically adjusts the IOPS limit of your database server based on the demand of your workload.
意訳すれば「Auto scale IOPSが有効な場合、DBに要求されたワークロードに応じて自動的にIOPSが最適化される」とあります。
夢のような機能に思えますが、Pre-provisioned同様にMAX IOPSはCompute sizeによって制限されます。
Pre-provisioned vs Auto scale
さてここでFlexible Serverを作成するにあたり、私たちはPre-provisioned IOPSかAuto scale IOPSか選択を迫られることになります。
この悩みに対してドキュメントは明確な回答を提供してくれます。
上記よりワークロード別のPre-provisioned IOPSとAuto scale IOPSの説明表を引用します。
| Workload considerations | Pre-provisioned IOPS | Auto scale IOPS |
|---|---|---|
| Workloads with consistent and predictable I/O patterns | Recommended, because it uses only provisioned IOPS |
Compatible, with no manual provisioning of IOPS required |
| Workloads with varying usage patterns | Not recommended, because it might not provide efficient performance during high usage periods. |
Recommended, because it automatically adjusts to handle varying workloads |
| Workloads with dynamic growth or changing performance needs | Not recommended, because it requires constant adjustments for changing IOPS requirements |
Recommended, because no extra settings are required for specific throughput requirements |
一つ一つの説明を読むことで納得がいきますが、簡略化するとその差は一目瞭然です。
| Workload considerations | Pre-provisioned IOPS | Auto scale IOPS |
|---|---|---|
| Workloads with consistent and predictable I/O patterns | ✅Recommended | 👌Compatible |
| Workloads with varying usage patterns | 🙅Not recommended | ✅Recommended |
| Workloads with dynamic growth or changing performance needs | 🙅Not recommended | ✅Recommended |
1行目の"Workloads with consistent and predictable I/O patterns"を除き、Auto scale IOPSが推奨されていますし、"Workloads with consistent and predictable I/O patterns"についても"Compatible"であることが明記されています。
ここから多くのワークロードのケースでAuto scale IOPSを選択することが適切であると読み取ることができました。
コストの損益分岐点は？
幅広いワークロードにおいてAuto scale IOPSが適していることが分かった一方で、SREやシステム管理者が気にすべき点の一つはコストです。
第47回 Tokyo Jazug Nightにおいて、同僚の岩崎さんの発表にもあったように、私たちのチームは日々Azureコストの最適化に奮闘しています。
Single Serverを利用していた際は必然的にPre-provisioned IOPSのような固定のIOPSを指定していたことで、それを実績としてFlebixble ServerにおいてもPre-provisioned IOPSを選択するのが安心と言えるかもしれません。
従来の実績がPre-provisioned IOPSにあるとすれば、Auto scale IOPSを選ぶ動機としてコストメリットが重要となります。
それぞれのコストについてPricingページより以下にまとめます。単位が同じではないため単純比較はできません。
| Type | Price | Unit |
|---|---|---|
| Pre-provisioned IOPS (Additional IOPS) |
$0.06 | IOPS/month |
| Auto scale IOPS (Paid IO Locally redundant storage (LRS)) |
$0.29 | per million IOPS |
| Auto scale IOPS (Paid IO Zone redundant storage (ZRS) |
$0.363 | per million IOPS |
例として Standard_D16ads_v5 16vCores, 64GiB memory, 20,000 max iops のケースで考えます。基準とする期間を1月(30日)間とし、平均IOPSを変数とした場合コストのグラフは以下のように変遷していきます。固定のPre-provisionedはMAXの20,000を指定しますが、実際には20,000以下を指定可能であることは留意ください。
具体的な計算方法
計算式は以下のように行なっています。
- Pre-provisioned IOPS: MAX 20,000 * $0.06 = $12,000/Month
- Auto scale IOPS: 月の平均IOPS N * 30(days) * 60(Hours) * 60(Minutes) / 1,000,000 = $コスト/Month
損益分岐点は月の平均IOPSが 1,000から2,000 の間に収まりました。つまりMAXの 20,000 に対して 月の平均IOPSが5%から10%以下であれば、Auto scale IOPSの方がコストメリットがあると言えます。
以下はとあるFlexible Serverに対し、Azure Portal -> Flexible Server -> Metrixの画面で以下を選択した結果です。
- Metric: Storage IO Percent
- Aggrigation: Average
直近1月間の平均Storage IO Percentが2.3484% = 約2.4%であるため、損益分岐点である平均IOPS 5% の半分以下であり、Pre-provisionedではなくAuto scale IOPSにした方がコスト削減につながる可能性が高いと判断できます。
もっとシンプルにIOPSコストを調べるためにはStorage IO Count metricを見る
グラフ化するために平均IOPSを利用するなどしてごちゃごちゃと計算しましたが、実際に稼働しているインスタンスのIOPSコストを調べるのは簡単です。
Frequently asked questionsから以下に引用します。
How do I know how many IOPS I've used in Azure Database for MySQL - Flexible Server?
Go to Monitoring in the Overview section, or go to the Storage IO Count metric on the Monitoring pane. The Storage IO Count metric gives the sum of IOPS that the server used in the selected timeframe.
以下はとあるFlexible Serverに対し、Azure Portal -> Flexible Server -> Metrixの画面で以下を選択した結果です。
- Metric: Storage IO Count
- Aggrigation: Sum
直近30日間のStorage IO Countの数値が1.23BとなっているためLRSの$0.29 per million IOPSで計算すると1,230,000,000 * 0.29 / 1,000,000 = $356/Monthとなります。
Pre-provisioned IOPSでMAX 20,000を指定した場合は 20,000 * $0.06 = $12,000/Monthとなりますので、Auto scale IOPSにするとIOPSコストを大幅(97%程度)に削減できると判断できます。
IOPSのオプションは動的に変更が可能
嬉しいことに、Pre-provisioned IOPSとAuto scale IOPSは動的に変更が可能です。
繰り返しの引用となるFrequently asked questionsに、変更にあたって多くの方が気になるだろう質問に対し回答が記載されています。
重要なポイントは以下の2点です。
- Pre-provisioned IOPSからAuto scale IOPSへ変更すると、即座に変更が反映される（あらゆる遅延は起きない）
- Auto scale IOPSからPre-provisioned IOPSへ戻すことも可能
遅延がない(The autoscale IOPS feature is applied to your database without any delay.)に力強さを感じつつ、必要に応じて行ったり来たりできる点は切り戻しの観点からも大変素晴らしい仕組みと考えます。
終わりに
以上、つらつらとAzure Database for MySQL Flexible ServerのAuto scale IOPSについてPre-provisioned IOPSと比較しつつまとめてみました。
内容について公式ドキュメントを参照しながら正確性に気をつけましたが、誤りは全て著者である私の責任となりますため、発見された方は（可能なら優しく）教えていただけると大変ありがたいです。（特に計算式のあたり）
それではみなさまEnjoy コスト最適化＆Azure！！
イオングループで、一緒に働きませんか？
イオングループでは、エンジニアを積極採用中です。少しでもご興味もった方は、キャリア登録やカジュアル面談登録などもしていただけると嬉しいです。
皆さまとお話できるのを楽しみにしています！
Discussion