Object Storage Service:キャッシュヒートマップを使用した OSS アクセラレータのキャッシュ容量の最適化

機能概要

アクセラレータのキャッシュ容量を調整するかどうかを判断するには、次の情報を合わせて確認します。

• OSS アクセラレータのキャッシュヒット率 (キャッシュヒット率)：現在のキャッシュのアクセラレーション効果を示します。

• OSS アクセラレータのキャッシュスペース使用率 (スペース使用率)：クエリ時点のスナップショットであり、各 seg セグメントが使用済み合計容量に占める割合を示します。

• キャッシュヒートマップ：選択した時間範囲内のアクセストラフィック分布と、クエリ時点でのキャッシュ済みデータのスペース分布のスナップショットを示します。この情報から、キャッシュヒット率が高い、または低い理由がわかります。

キャッシュヒット率はアクセラレーション効果を測定し、キャッシュヒートマップはアクセスパターンを明らかにし、スペース使用率は各 seg セグメントが占めるキャッシュ済みスペースの割合を示します。これらのメトリクスを組み合わせることで、現在のキャッシュ容量が適切かどうかを判断できます。

• キャッシュヒット率が低い場合：キャッシュされたデータのごく一部にアクセストラフィックの大半が集中している場合、そのワークロードには明確なアクセスホットスポットがあり、容量を増やすとキャッシュヒット率が向上する可能性があります。アクセストラフィックの分布がスペース使用量の分布と類似している場合、そのワークロードは通常、ランダムアクセスが主体となっています。容量を増やす前に、そのメリットを評価してください。

• キャッシュヒット率が高い状態が続く場合：スペース使用率と、最も最近アクセスされていないデータのアクセストラフィックおよびスペース使用量を確認して、容量を削減できるかどうかを判断します。測定されたキャッシュ容量とキャッシュヒット率の関係を使用して、容量削減の影響を評価します。

コンソールでキャッシュヒートマップにアクセスしてクエリを実行する方法については、「アクセラレータのモニタリング」をご参照ください。

グラフの説明

OSS アクセラレータのモニタリングページで、[キャッシュヒートマップモニタリング] カードにキャッシュヒートマップが表示されます。

水平軸は時系列ではなく、キャッシュデータの最終アクセス順序を表します。左から右へ、アクセスが新しいデータから古いデータへと変化します。この順序に基づき、システムはキャッシュデータを seg 0~9 から seg 90~99 までの 10 個のセグメントに均等に分割します。

• seg 0~9 はチャートの一番左にあり、最も最近アクセスされたデータを表します。

• seg 90~99は、チャートの最も右側にあり、最も長い間アクセスされていないデータを表します。

このトピックでは、アクセス順序を相対的な経過時間と呼びます。相対的な経過時間は、キャッシュのアクセス状況が続くにつれて変化します。これは、オブジェクトの作成時刻でも、オブジェクトがキャッシュされていた期間でもなく、固定の分数または時間数に変換することはできません。たとえば、seg 90~99 内のデータは、QPS が高い負荷の高いインスタンスでは数分間しかアクセスされなかったかもしれませんが、アイドル状態のインスタンスでは数時間アクセスされなかった可能性があります。相対的な経過時間は、現在のグラフにおけるキャッシュされたデータのアクセス順序のみを示します。同じインスタンスの異なる期間や異なるインスタンス間で同じ seg を直接比較したり、同じ時間の長さとして解釈したりしないでください。

OSS アクセラレーターのキャッシュが満杯になった後、新しいデータをキャッシュする必要がある場合、最近最もアクセスされていないデータが最初に破棄されます。したがって、このトピックでは seg 80~99 を破棄準備ゾーンと呼びます。コンソールの上部にあるバナーでは、この用語を破棄ゾーンと省略しています。

キャッシュヒートマップモニタリングカードには、次の要素が含まれています。

キャッシュされたデータへのアクセス頻度を評価しやすくするために、このトピックでは 10 個の seg セグメントを以下の 4 つのゾーンに分類します。

コンソールでは、エビクション準備ゾーンが薄い黄色の背景でマークされます。アクティブゾーン、ウォームゾーン、コールドゾーンは、分析を容易にするために本トピックで使用される用語です。コンソールのグラフには、これらのゾーンのラベルは表示されません。

IOPS が極端に高い場合、システムが一部のアクセスヒートデータを破棄することがありますが、seg セグメント間の相対的な比率と全体的な傾向は一貫しています。このことは、容量を増減する際の決定に影響を与えません。絶対的なアクセス トラフィックを表示するには、QPS または帯域幅メトリクスを使用します。

キャッシュ容量の調整

まず、次の表を使用してグラフのパターンを特定し、対応する例を確認します。ヒートマップのみに基づいてアクセラレータのキャッシュ容量を調整しないでください。アクセラレータのモニタリングでヒット率メトリクスからキャッシュヒット率を取得し、キャッシュヒートマップからエビクション準備ゾーンのアクセス比率とスペース比率を取得します。

キャッシュ容量を調整する必要があると判断したら、OSS アクセラレータの作成、変更、削除を参照して OSS アクセラレータのキャッシュ容量を変更します。

キャッシュヒット率が 80% から 95% の間の場合、しきい値のみに基づいて結論を出さないでください。目標のキャッシュヒット率、グラフのパターン、スペース使用率、オリジン帯域幅を総合的に考慮してください。

seg                  0~9  10~19  20~29  30~39  40~49  50~59  60~69  70~79  80~89  90~99
Access traffic ratio  62%    18%     8%     5%     3%     2%     1%     1%     0%     0%
Space usage ratio     16%    19%    13%    10%     8%     5%     4%     3%     1%     21%

Banner: Eviction zone access ratio: 0%; space ratio: 22%

seg                  0~9  10~19  20~29  30~39  40~49  50~59  60~69  70~79  80~89  90~99
Access traffic ratio  88%    10%     2%     0%     0%     0%     0%     0%     0%     0%
Space usage ratio     58%    34%     8%     0%     0%     0%     0%     0%     0%     0%

Banner: Eviction zone access ratio: 0%; space ratio: 0%

seg                  0~9  10~19  20~29  30~39  40~49  50~59  60~69  70~79  80~89  90~99
Access traffic ratio  30%    20%    14%    11%     8%     6%     5%     3%     2%     1%
Space usage ratio     30%    19%    14%    11%     8%     6%     5%     4%     2%     1%

推奨事項

1. 代表的な期間を選択する。 オフピーク時のデータによって容量要件が過小評価されるのを防ぐため、日中のビジー期間にキャッシュ容量を評価します。夜間のバッチジョブなど、日次または週次のピークが明確なワークロードについては、ピーク時とオフピーク時を別々に観察してください。

2. 連続した複数のサイクルを観察する。 単一のサンプルや短い観察期間は、一時的な変動の影響を受ける可能性があります。少なくとも 6 時間、連続した複数のビジネスサイクルを観察し、観察期間中はキャッシュ容量の頻繁な調整を避けてください。

3. 容量を段階的に削減します。 領域使用率が示す使用可能な容量に基づいて、キャッシュ容量を段階的に削減します。削減のたびに、キャッシュヒートマップとキャッシュヒット率を再度確認します。続行する前に、アクティブゾーン (seg 0~9) が圧縮されておらず、退避準備ゾーン (seg 80~99) が空でないことを確認します。

4. 弾性的な容量レベルを個別に調整する。 夜間に容量を増やし、日中に減らすなどの弾性スケーリングシナリオでは、ピーク時とオフピーク時のヒートマップを使用して、2 つのキャッシュ容量レベルを個別に調整します。

5. モニタリングメトリクスを合わせて確認する。 キャッシュヒートマップを使用してキャッシュヒット率の変化を解釈し、キャッシュヒット率とオリジン帯域幅を使用して調整の結果を検証します。メトリクスから導き出される結論に一貫性がない場合は、まずワークロードのアクセスパターンが最近変更されたかどうかを確認してください。

よくある質問

OSS アクセラレータのキャッシュスペース使用率が 100% の場合、キャッシュ容量を増やす必要がありますか。

いいえ。OSS アクセラレータは Least Recently Used (LRU) のエビクションポリシーを使用し、キャッシュがいっぱいになった後にのみデータのエビクションを開始します。合計データ量がキャッシュ容量を超えると、スペース使用率は 100% に達します。低いキャッシュヒット率と、エビクション準備ゾーンのスペース比率が 0% に近い状態が組み合わさると、キャッシュ容量の不足を示します。

エビクション準備ゾーンがスペースを占有しているのに、アクセストラフィックがないのは異常ですか。

いいえ。エビクション準備ゾーンには、新しいデータに置き換えられようとしているコールドデータが格納されます。このゾーンがほとんどアクセスされずにスペースを占有するのは正常です。このゾーンのスペース比率が 0 に近い場合、データはコールドになる前にエビクションされる可能性があります。キャッシュヒット率を使用して、容量を増やすかどうかを判断してください。

キャッシュ容量を削減すると、キャッシュヒット率はどのくらい低下しますか。

まず、スペース使用率によって示される利用可能なキャッシュ容量を確認し、次に測定されたキャッシュ容量とキャッシュヒット率の関係を参照します。アクセスの局所性を持つワークロードの場合、80/20 のアクセスパターンテストでは、キャッシュ容量を半分にするとキャッシュヒット率が 98.0% から 86.9% に、約 11 パーセントポイント低下しました。ランダム読み取りの場合、キャッシュヒット率はキャッシュ容量の比率とほぼ線形に変化します。容量を削減すると、キャッシュヒット率もほぼ比例して低下します。容量は段階的に削減し、調整のたびにキャッシュヒット率とキャッシュヒートマップを再度確認してください。

なぜ、ほとんどすべてのアクセストラフィックが seg 0~9 に集中するのですか。

2 つの状況が考えられます。スペースの分布を使用して、それらを区別します。第一に、アクセスの局所性が強く、キャッシュが正常に機能している可能性があります。この場合、後のセグメントも正常なスペース分布を保ち、キャッシュヒット率は高くなります。第二に、容量が著しく不足しており、データがすぐにエビクションされている可能性があります。この場合、エビクションゾーンのスペース比率も 0 に近く、キャッシュヒット率は低くなります。2 番目の状況では、容量の増加が必要です。「キャッシュヒット率が高い場合：容量削減の評価」と「キャッシュヒット率が低い場合：容量増加の評価」のシナリオを比較してください。

キャッシュヒートマップはどのくらいの頻度で確認すべきですか。

キャッシュ容量を評価する際は、ビジネスのピーク時に分単位の間隔でサンプルを収集し、複数のビジネスサイクルを観察します。定期的なチェックとしては、構造的な変化がないか、毎日または毎週グラフを検査します。グラフのパターンに大きな変化が見られる場合、通常はワークロードのアクセスパターンが変化したことを示します。