Storage performance best practices and considerations for Azure SQL DB Managed Instance (General Purpose) で、Managed Instance (MI) の General Purpose (汎用目的) のストレージのベストプラクティスが公開されました。
MI は、 General Purpose (汎用目的) と Business Critical (ビジネスに必要不可欠) の二つのサービスレベルが提供されており、これらのサービスレベルでは大きく次のような構成の違いがあります。
- General Purpose
- データベースのファイルは tempdb 以外は Premium ストレージ上に配置
- tempdb はローカルの SSD に配置
- データベースの冗長性は、Premium ストレージのストレージとしての冗長構成で担保
- 待機系となるサーバーは用意されており、障害が発生した場合には、そのサーバーを Active にし、Premium ストレージの同質の領域に接続を行う
- Business Critical
- すべてのデータベースをローカルの SSD に配置
- データベースの冗長性は AlwaysOn 可用性グループで担保
- プライマリ 1 × / セカンダリ × 3 の 4 台の構成
構成としては、SQL Database の Basic / Standard と Premium の関係に近いと思います。
冒頭で紹介した記事では MI の General Purpose のストレージの考慮点について、詳細に記載されています。
(Business Critical については、SQL Server に直結された、ローカル SSD がすべての DB で使用されるため、本投稿の制約は受けません)
以下の画像は、私が実施しているセミナー向けに作ったものになりますが、MI では、ユーザーデータベースは次のようなファイル構成となり、「データベースの各ファイル」がPremium Storage 上に Page BLOB として配置されるようになっています。
General Purpose で使用されている ストレージについては
- Premium ストレージ全体のキャパシティは 35 TB
- データベースで使用可能なファイルサイズは全体で 8TB
- 使用可能なストレージのサイズについては、MI として設定する必要があり、設定したストレージサイズに応じて課金が発生する
というようなキャップがあり、Premium ストレージ全体のキャパシティと、データベースで使用可能なデータ領域のキャパシティは異なっています。
各 Page BLOB のサイズについては、データベースのファイルの実際にに応じて変わり、以下のいずれかのディスクに割り当てられるような仕組みとなっています。
| ディスク サイズ |
128 GB |
256 GB |
512 GB |
1 TB |
4 TB |
|
ディスクあたりの IOPS |
500 |
1100 |
2300 |
5000 |
7500 |
|
ディスクあたりのスループット |
100 MB/秒 |
125 MB/秒 |
150 MB/秒 |
200 MB/秒 |
250 MB/秒 |
そのため MI を General Purpose で使用する場合には、データベースのファイルのレイアウトを考えることが、性能を最大限に発揮するためのポイントとなります。
この考慮点については、
- データファイルを大きなサイズのファイルで構成する
- データファイルを複数のデータファイルで構成する
- この場合、データファイルのサイズ / 自動拡張サイズを同一にし、データファイルが均等に使用されるような考慮が必要
- ログファイルを大きなサイズのファイルで構成する
- MI はログファイルは 1 ファイルでのみ構成が可能となっているため、ログファイルのスループットについては、ファイルサイズが性能に影響を与える大きな容易となる
というような内容が含まれています。
データファイルのスループットを上げるためには、
- 複数のデータファイルに均等にデータを配置し、各ファイルに I/O を分散させる
- 1 ファイルのサイズを大きくし、最大の IOPS を増加させる
ログファイルのスループットを上げるためには、
- ログファイルのサイズを大きくし、最大の IOPS を増加させる
というのが基本的な方針ではないでしょうか。
- 複数のファイルで DB を構成しても、CPU がボトルネックになり、性能の上限に達っしている
- ディスクを分割しすぎて、その分のーバーヘッドにより、性能が伸び悩み、大き目なファイルを複数で構成した方が良い
というようなことも考えられますので、データベースのファイルの I/O と CPU の適切なバランシングは考慮した方がよいかと。
MI はファイルグループが使用できますので、ファイルグループ + パーティショニングにより、パーティション単位の IO 分散を行わせるということもできるのではないでしょうか。
MI は、インスタンス単位で、サービスが提供される SQL Server ですが、SQL Server on Azure VM とは異なり、
- 管理されている PaaS としての SQL Server の環境のため、冗長化やバックアップ運用等は自動で実施され、監視の仕組みについても Azure のものが使用できる
- VM 単位のディスク性能に対しての上限は設定されていないため、IOPS の上限は、データベースの配置方法に依存する
というような特徴があり、2 番目の内容については冒頭で紹介した記事で詳しく解説されています。
SQL Database との違いとしては、次のようなものがあるのではないでしょうか。
- MI はインスタンスを全 DB で共通して使用するため、特定の DB のリソースの使用状況によって、他の DB の性能に影響を与える可能性がある
- SQL Database は DB 単位で独立してリソースが使用される
- MI はインスタンス単位で共通してリソースが使用され、特に CPU のリソースの共通の利用については注意する
- DB 単位の IO については、データファイルサイズによってそもそもの IOPS が変化するため、IOPS については、データファイルのサイズを調整することで性能のキャップを DB 単位で調整できる
品川の日本マイクロソフト様で、次の日程で Managed Instance も含まれたセミナーの講師を担当させていただいておりますので、MI に興味のある方がいらっしゃいましたらご参加いただければ幸いです。