クール アクセスを使用した Azure NetApp Files ストレージのパフォーマンスに関する考慮事項
データ セットは、いつもアクティブに使用されているわけではありません。 セット内のデータは最大 80% を "クール"、つまり、現在使用されていない、あるいは最近アクセスされていない、と見なすことができます。 クール データは再びアクセスされるまでハイ パフォーマンス ストレージを必要としないため、Azure NetApp Files などのハイ パフォーマンス ストレージにデータを格納すると、使用されている容量に費やされるコストは実質的には無駄です。
クール アクセスを使用した Azure NetApp Files ストレージは、Azure のクラウド ストレージのコストを削減することを目的としています。 特定のユース ケースでは、検討が必要なパフォーマンスに関する考慮事項があります。
クール層に移動したデータにアクセスすると、特にランダム I/O では待機時間が長くなります。 最悪のシナリオでは、アクセスされているすべてのデータがクール層にある可能性があるため、すべての要求でデータの取得を実行する必要があります。 アクティブに使用されているデータセット内のすべてのデータがクール層にあるのは珍しいため、待機時間がこのようになることはそれほどありません。
既定のクール アクセス取得ポリシーが選択されている場合、シーケンシャル I/O 読み取りはクール層から直接処理され、ホット層には再入力されません。 ランダムに読み取られたデータがホット層に再入力されることで、後続の読み取りのパフォーマンスが向上します。 シーケンシャル ワークロードの最適化により、多くの場合、クラウド取得によって発生する待機時間がランダム読み取りと比べて短くなり、全体的なパフォーマンスが向上します。
クール アクセスを使用した Azure NetApp Files の Standard Storage を使って実行された最近のテストでは、次の結果が得られました。
Note
公開されるすべての結果は、参照のみを目的としています。 実稼働ワークロードのパフォーマンスは多数の要因によって異なる可能性があるため、結果は保証されません。
ホット/クール層での 100% シーケンシャル読み取り (1 つのジョブ)
次のシナリオでは、Ultra パフォーマンス レベルを使って、50 TiB の Azure NetApp Files ボリューム上で 1 つのD32_V5 仮想マシン (VM) の 1 つのジョブが使用されました。 さまざまなブロック サイズが、ホット層とクール層でパフォーマンスをテストするために使用されました。
Note
Ultra サービス レベルの最大値は、割り当てられた容量テビバイトあたり 128 MiB/秒です。 Azure NetApp Files の通常のボリュームでは、最大約 5,000 MiB/秒のスループットを管理できます。
次のグラフは、さまざまなキューの深さを使用して、このテストのクール 層のパフォーマンスを示しています。 1 つの VM の最大スループットは約 400 MiB/秒でした。
ホット層のパフォーマンスは約 2.75 倍向上し、約 1,180 MiB/秒で上限に達しました。
このグラフは、256K のブロック サイズのクール層とホット層のパフォーマンスを左右に並べて表示し、比較しています。
ホット層とクール層の待機時間の原因
ホット層の待機時間はストレージ システム自体の要因であり、ここでは、処理できる数よりも多くの I/O が任意の時点でサービスに送信されたことで、システム リソースが使い果たされています。 このため、操作を、以前送信された操作が完了するまでキューに入れる必要があります。
クール層の待機時間は通常、クラウド取得操作であるオブジェクト ストアへの I/O に対するネットワーク経由の要求 (シーケンシャル ワークロード) またはホット層へのクール ブロック リハイドレート (ランダム ワークロード) のいずれによって確認されます。
結果の概要
- ワークロードが 100% シーケンシャルである場合、クール層のスループットはホット層に比べて約 47% 低下します (1742 MiB/秒と比べて 3330 MiB/秒)。
- ワークロードが 100% ランダムの場合、クール層のスループットはホット層に比べて約 88% 低下します (2,479 MiB/秒と比べて 280 MiB/秒)。
- ホット層で 100% シーケンシャル (3,330 MiB/秒) ワークロードと 100% ランダム (2,479 MiB/秒) ワークロードを実行した場合のパフォーマンス低下は約 25% でした。 クール層で 100% シーケンシャル (1,742 MiB/秒) ワークロードと 100% ランダム (280 MiB/秒) ワークロードを実行した場合のパフォーマンス低下は約 88% でした。
- ワークロードにランダム I/O が含まれている場合は、その割合に関係なく、クール層の全体的なスループットは、100% シーケンシャルよりも 100% ランダムに近くなります。
- 100% シーケンシャルから 80/20 のシーケンシャル/ランダム組み合わせに移行すると、クール層からの読み取りは約 50% 低下します。
- シーケンシャル I/O では Azure NetApp Files の
readaheadキャッシュを利用できますが、ランダム I/O では利用できません。 シーケンシャル I/O のこの利点は、ホット層とクール層の全体的なパフォーマンスの違いを減らすのに役立ちます。
考慮事項と推奨事項
- アクセス パターンがワークロードによって予期せず変更されることが多い場合、ホット層とクール層のパフォーマンスの違いから、クール アクセスは理想的でない場合があります。
- ワークロードにランダム I/O が含まれている場合は、その割合に関係なく、クール層のデータにアクセスするときのパフォーマンスの期待値を適宜調整する必要があります。
- クール ウィンドウとクール アクセス取得の設定をワークロード パターンに合わせて構成し、クール層の取得量を最小限に抑えます。
- クール アクセスのパフォーマンスは、アプリケーションが実行されているデータセットとシステムの負荷によって異なる場合があります。 クール アクセスのパフォーマンスの変動を理解し、考慮するために、データセットで関連するテストを実施することをお勧めします。