Rapid Cache

重要: Anywhere Cache の名前が Rapid Cache に変更されました。特定のツールで Rapid Cache を使用している場合、ツールのインターフェースやサーフェスで Anywhere Cache の名前が参照されていることがあります。

このページでは、Cloud Storage バケットに SSD ベースのゾーン読み取りキャッシュを提供し、保存データのスループットを向上させ、レイテンシを短縮できる Rapid Cache について説明します。Rapid Cache は、ニーズに合わせて自動的にスケールアップまたはスケールダウンするストレージ容量と帯域幅を提供します。Rapid Cache はフルマネージド サービスであり、一貫したデータを返します。

Rapid Cache は、読み取り負荷の高いワークロードのパフォーマンスを向上させ、ネットワーク費用を削減するのに役立ちます。詳細については、特典をご覧ください。

Rapid Cache を使用してキャッシュを作成して管理する方法については、キャッシュを作成して管理するをご覧ください。

Rapid Cache の仕組み

Rapid Cache を使用すると、ワークロードと同じゾーンにキャッシュを作成できます。ゾーンにキャッシュを作成すると、ゾーンから発信されたデータ読み取りリクエストは、バケットではなくキャッシュによって処理されます。各キャッシュは、キャッシュと同じゾーン内のクライアントにサービスを提供します。

バケットのデータは、キャッシュと同じゾーンにある VM によって読み取られると、キャッシュに取り込まれます。書き込み時の取り込み動作を構成すると、データがバケットに書き込まれるときにキャッシュにも取り込まれます。

メタデータはキャッシュに保存されません。オブジェクト メタデータのリクエストは、常にキャッシュではなくバケットで処理されます。

データがキャッシュに取り込まれる方法の詳細については、データの取り込みをご覧ください。キャッシュの 有効期間（TTL）と 書き込み時の取り込み動作は、キャッシュの作成時または更新時に構成できます。

利点

Rapid Cache を使用してデータをキャッシュに保存すると、次の利点があります。

• データアクセスを高速化: Rapid Cache は、コンピュート リソースと同じゾーンにデータを配置し、SSD によって完全にバックアップされます。これにより、ワークロードで最大 2.5 TB/秒のスループットを実現し、レイテンシを短縮して読み取りを高速化できます。

• マルチリージョン データ転送料金を削減する: キャッシュから読み取られるデータには、マルチリージョン バケットから直接読み取られるデータと比べ、データ転送料金が削減されます。

• 取得料金を削減する: Nearline Storage、Coldline Storage、Archive Storage のバケットの取得料金は、キャッシュからのデータ読み取りには適用されません。

• 読み取りオペレーションの費用を削減する: Rapid Cache から提供される読み取りオペレーションの料金は、Standard Storage のバケットから提供されるクラス B オペレーションよりも低くなります。

• キャッシュ サイズを自動スケーリングする: Rapid Cache の動的 SSD キャッシュは、キャッシュ サイズを指定しなくても、使用状況に基づいて自動的にスケーリングされます。

• キャッシュを効率的に使用する: 既存のアプリケーションや API を変更することなく、既存のバケットで Rapid Cache を有効にできます。Rapid Cache に保存されたデータには強整合性があります。

料金の詳細については、Rapid Cache の料金をご覧ください。割り当てについては、Rapid Cache の割り当てをご覧ください。

Rapid Cache を使用するタイミング

変更頻度が低く読み取り頻度が高いデータには Rapid Cache を使用して、分析ワークロードと AI/ML モデルのトレーニングと読み込みのデータ読み取りを高速化します。

複数の Google Kubernetes Engine ノードで AI モデルをトレーニングしているとします。これらのノードはすべて、Cloud Storage バケットに保存されているデータを繰り返し読み取り、同じゾーンで実行しています。ワークロードが実行されているゾーンにキャッシュを作成すると、キャッシュによって追加の帯域幅が提供され、マルチリージョン バケットでのデータの読み取りに関連するデータ転送料金を削減できるため、大規模なスケールアウトされたワークロードをより効率的に実行できます。

キャッシュ サイズと帯域幅の上限の自動スケーリング

Rapid Cache は、キャッシュに保存されるデータの量に応じて自動的にスケールアップまたはスケールダウンする一時ストレージ容量と帯域幅を提供します。

キャッシュ帯域幅の上限は 100 Gbps から始まり、保存されているデータ 1 TiB あたり 20 Gbps のレートでスケーリングされます。キャッシュに保存されるデータの量を増やすか、ゾーンにキャッシュをさらに作成するか、テクニカル アカウント マネージャーまたは Google の担当者に連絡することで、開始帯域幅または合計帯域幅の上限を引き上げることができます。

Rapid Cache のサイズと帯域幅の上限の詳細については、Cloud Storage の割り当てと上限をご覧ください。

ゾーンでのデータのキャッシュ保存

バケットのキャッシュを作成する場合は、バケットのロケーション内のゾーンにキャッシュを作成する必要があります。たとえば、バケットが us-east1 リージョンにある場合、us-east1-b にキャッシュを作成できますが、us-central1-c には作成できません。バケットが ASIA デュアルリージョンにある場合は、asia-east1 リージョンと asia-southeast1 リージョンを構成する任意のゾーンにキャッシュを作成できます。

各バケットで、ゾーンごとに最大 1 つのキャッシュを作成できます。たとえば、バケットが us-east1 リージョンにある場合は、us-east1-b にキャッシュを作成して、us-east1-c に別のキャッシュを作成できます。バケットが us-central1 と us-east1 を含むマルチリージョンにある場合は、us-central1-a にキャッシュを作成し、us-east1-b に別のキャッシュを作成できます。

ゾーンの容量が利用可能な限り、ゾーンにキャッシュを作成できます。キャッシュの作成に必要な容量が使用できない場合、Rapid Cache は、容量が使用可能になるか、作成プロセスがユーザーによってキャンセルされるまで、キャッシュの作成を試行し続けます。容量が長期間使用できない場合があります。

Rapid Cache は、次のゾーンで使用できます。これらのゾーンは、バケットのロケーション タイプに応じて使用できます。

アジア

次の表に、アジア地域で Rapid Cache で利用可能なゾーンとロケーション タイプを示します。

ゾーン名	地域	デュアルリージョン	マルチリージョン	カスタム デュアルリージョン
asia-east1-a
asia-east1-b
asia-east1-c
asia-northeast1-a
asia-northeast1-b
asia-northeast1-c
asia-south1-a
asia-south1-b
asia-south1-c
asia-southeast1-a
asia-southeast1-b
asia-southeast1-c

ヨーロッパ

次の表に、ヨーロッパ地域で Rapid Cache で使用できるゾーンとロケーション タイプを示します。

ゾーン名	地域	デュアルリージョン	マルチリージョン	カスタム デュアルリージョン
europe-north1-a
europe-north1-b
europe-north1-c
europe-west1-b
europe-west1-c
europe-west1-d
europe-west3-a
europe-west3-b
europe-west3-c
europe-west4-a
europe-west4-b
europe-west4-c
europe-west4-ai1a （AI ゾーン）
europe-west6-a
europe-west6-b

米国

次の表に、米国地域で Rapid Cache で使用可能なゾーンとロケーション タイプを示します。

ゾーン名	地域	デュアルリージョン	マルチリージョン	カスタム デュアルリージョン
us-central1-a
us-central1-b
us-central1-c
us-central1-f
us-central1-ai1a （AI ゾーン）
us-east1-b
us-east1-c
us-east1-d
us-east4-a
us-east4-b
us-east4-c
us-east5-a
us-east5-b
us-east5-c
us-south1-a
us-south1-b
us-south1-c
us-south1-ai1b （AI ゾーン）
us-west1-a
us-west1-b
us-west1-c
us-west2-a
us-west3-a
us-west3-b
us-west3-c
us-west4-a
us-west4-b
us-west4-c

キャッシュのデータの取り込み

デフォルトでは、データは最初にリクエストされた後にキャッシュに取り込まれます。

この最初のリクエストが届いたとき、キャッシュは空であるため、キャッシュ内にデータはまだありません。これにより、初期キャッシュミスが発生し、システムは代わりにバッキング Cloud Storage バケットからデータを取得します。システムが取得したデータをユーザーに配信すると同時に、データがキャッシュに取り込まれます。

この最初のリクエストが完了すると、データはキャッシュに保存され、以降の読み取りはすべて高速のキャッシュ ヒットとしてキャッシュから直接提供されます。この動作により、読み取りレイテンシが大幅に短縮され、データ取得が高速化されます。取り込まれたデータは、TTL が期限切れになるまでキャッシュに存在し、その後、キャッシュから強制排除されます。

最初のリクエストの遅延を完全に回避するには、最初の読み取り後にデータを取り込むだけでなく、書き込み時にデータを取り込むようにキャッシュを構成します。

データをチャンクとして取り込む

データをキャッシュに取り込むとき、Rapid Cache はオブジェクトを固定サイズの小さなチャンクに分割します。オブジェクトをチャンクに分割すると、特に特定の部分のみがアクセスされる大きなファイルの場合に、よりきめ細かいキャッシュ保存が可能になります。

チャンクは 2 MB のデータブロックです。オブジェクトのリクエストが行われると、Rapid Cache はリクエストされたバイト範囲をカバーする 2 MB のチャンクを特定し、それらのチャンクを個別に管理します。

データの取り込みの動作は、キャッシュに取り込まれるオブジェクトのサイズによって異なります。

• 2 MB を超えるオブジェクトに対する読み取りリクエストの場合、リクエストされたバイト範囲を含むチャンクのみが取り込まれます。たとえば、100 MB のファイルの最初の 1 MB を読み取ると、最初の 2 MB のチャンクのみが取り込まれます。

• 2 MB 未満のオブジェクト（500 KB の画像など）に対する読み取りリクエストの場合、オブジェクト全体がキャッシュに取り込まれます。

書き込み時にデータを取り込む

書き込み時にデータをキャッシュに取り込むようにキャッシュを有効にすると、データがバケットに書き込まれた瞬間にキャッシュに取り込まれます。この動作は、最初の読み取り後にデータを取り込むというデフォルトのキャッシュ動作に加えて、必要に応じて有効にできます。

書き込み時の取り込み機能により、最初のキャッシュミスが解消され、ワークロードは最初のデータ読み取りで即座にキャッシュ ヒットの恩恵を受けることができます。書き込み時のデータの取り込みにより、書き込み後の読み取りワークロード（システム チェックポイントの復元やモデル トレーニング用のデータ パイプラインの準備など）が高速化されます。

キャッシュの作成時または更新時に、書き込み時にデータを取り込むようにキャッシュを有効にできます。バケットに書き込まれたすべてのオブジェクトを取り込むようにキャッシュを構成することも（バケットレベルの書き込み時取り込みとも呼ばれます）、指定されたマネージド フォルダ（プレフィックス レベルの書き込み時取り込みとも呼ばれます）の下のバケットに書き込まれたオブジェクトを選択的に取り込むようにキャッシュを構成することもできます。

たとえば、バケット my-bucket 内のオブジェクトで、名前の接頭辞が red/ のオブジェクトに対して、接頭辞レベルの書き込み時取り込みを実行するようにキャッシュを有効にするとします。次に、my-bucket に 3 つのオブジェクト（red/my-dog.png、blue/my-cat.png、red/my-goldfish.png）をアップロードします。その結果、my-bucket にアップロードされると、オブジェクト red/my-dog.png と red/my-goldfish.png のみがキャッシュに取り込まれます。

特定のツール（Google Cloud コンソールなど）を使用して接頭辞レベルの書き込み時取り込みを構成する場合、既存のマネージド フォルダの名前ではない接頭辞を指定すると、新しいマネージド フォルダが自動的に作成されます。ただし、JSON API を使用する場合は、マネージド フォルダを手動で作成し、各キャッシュ ゾーンに ingestOnWrite 設定を適用する必要があります。各ツールを使用して書き込み時の取り込みを有効または無効にする手順については、Rapid Cache を使用するをご覧ください。

JSON API を使用してバケットまたは接頭辞レベルで書き込み時の取り込みを有効または無効にする方法については、書き込み時の取り込みを有効にする方法についてのセクションを開いてください。このセクションの情報は、主に JSON API にのみ関連しています。Google Cloud コンソールなどの他のツールでは、書き込み時の取り込みを有効にして管理しやすくするために、一部の設定が難読化されています。

書き込み時の取り込みを有効にする方法について

このセクションでは、バケットに書き込まれたすべてのオブジェクト、またはマネージド フォルダの接頭辞の下のバケットに書き込まれた選択されたオブジェクトのみに対して、書き込み時の取り込みを有効にするために使用する JSON API 設定について説明します。

キャッシュがバケット内のすべてのオブジェクトの書き込み時にデータを取り込むか、接頭辞の下にある選択したオブジェクトのみを取り込むかを制御する設定は 2 つあります。

• 書き込み時の取り込みのバケットレベルでの有効化は、キャッシュ リソースの ingestOnWrite フィールドを使用して行います。フィールドは次のようになります。

  {
  "zone": "us-east1-a",
  "ttl": "24h",
  "ingestOnWrite": true
  }

  • true に設定すると、バケットに書き込まれたすべてのオブジェクトで書き込み時の取り込みが有効になります。これにより、接頭辞で選択したオブジェクトの書き込み時取り込みを有効にするマネージド フォルダ レベルの設定がオーバーライドされます。
  • false に設定すると、バケット全体のオブジェクトで書き込み時の取り込みが無効になります。この設定により、マネージド フォルダの設定で、接頭辞で選択したオブジェクトの書き込み時取り込みを有効にできます。

• 接頭辞レベルの書き込み時取り込みは、末尾にスラッシュが付いた接頭辞パス（my-prefix/ など）を表すマネージド フォルダを使用して実現されます。接頭辞レベルの書き込み時取り込みが有効になっている場合、オブジェクト名に接頭辞が含まれている場合にのみ、キャッシュは書き込み時にオブジェクトを選択的に取り込みます。

  接頭辞レベルの書き込み時取り込みは、マネージド フォルダ リソースの rapidCacheConfig.policies マッピングの ingestOnWrite フィールドで制御されます。rapidCacheConfig.policies マッピングで指定するには、キャッシュ インスタンスが存在している必要があります。

  マネージド フォルダの rapidCacheConfig.policies マッピングは次のようになります。

  "rapidCacheConfig": {
    "policies": {
      "us-east1-a": {
        "rapidCacheId": "us-east1-a",
        "ingestOnWrite": "unspecified"
      }
      "us-east1-b": {
        ...,
        ...
      }
    }
  }

  • プレフィックス レベルの書き込み時取り込みが機能するには、policies マッピングで指定されたキャッシュ インスタンスがすでに存在している必要があります。たとえば、policies マッピングで rapidCacheId: "us-east1-a" を指定するには、まずゾーン us-east1-a のキャッシュが必要です。
  • 1 回の API 呼び出しで、policies マッピングで指定された複数のキャッシュ インスタンスを更新できます。
  • ingestOnWrite が enabled に設定されている場合、このマネージド フォルダのプレフィックスの下にあるバケットに書き込まれたすべてのオブジェクトに対して、書き込み時の取り込みが有効になります。プレフィックス レベルの書き込み時取り込みは、キャッシュ リソースの ingestOnWrite フィールドが false の場合にのみ有効にできます。
  • unspecified（デフォルト）に設定されている場合、書き込み時の取り込みの有効化は、直近の親リソースから継承されます。親リソースは、親マネージド フォルダまたはマネージド フォルダ自体を含むバケットのいずれかになります。
  • ポリシー マッピングで指定されていないキャッシュは、ingestOnWrite 設定が unspecified に設定されているかのように扱われます。

次の表に、バケットレベルまたは接頭辞レベルで書き込み時の取り込みを有効または無効にするために、キャッシュとマネージド フォルダのリソースを構成する方法の概要を示します。

• バケットレベルの書き込み時取り込みを有効にする（プレフィックス レベルは有効にしない）

  • 構成: キャッシュ リソースの ingestOnWrite フィールドを true に設定します。

  • 動作: バケットに書き込まれたすべてのオブジェクトに対して書き込み時の取り込みが有効になります。このバケット全体の設定は、管理対象フォルダ レベルの構成をオーバーライドします（つまり、選択的な接頭辞レベルの構成はバイパスされます）。

• プレフィックス レベルの書き込み時取り込みを有効にする（バケット レベルではない）

  • 構成:

    1. キャッシュ リソースの ingestOnWrite フィールドを false に設定します。
    2. マネージド フォルダ リソースで有効な policies マッピング（null 以外）を構成します。
    3. マネージド フォルダの ingestOnWrite フィールドを enabled に設定します（または、有効な親マネージド フォルダから enabled を継承する子フォルダの場合は unspecified に設定します）。

  • 動作: 書き込み時の取り込みは、一致するマネージド フォルダの接頭辞の下に書き込まれたオブジェクトに対してのみ行われます。

• 親マネージド フォルダと子マネージド フォルダでプレフィックス レベルの書き込み時取り込みを有効にする

  親マネージド フォルダで取り込み時書き込みを有効にせずに、子マネージド フォルダで取り込み時書き込みを有効にすることはできません。

• バケットと接頭辞の両方の書き込み時取り込みを無効にする

  • 構成:

    1. キャッシュ リソースの ingestOnWrite フィールドを false に設定します。

    2. すべてのマネージド フォルダの ingestOnWrite フィールドを unspecified に設定し、親マネージド フォルダの ingestOnWrite フィールドが enabled にならないようにします。

       または、policies マップ null をそのままにするか、rapidCacheConfig 構成を完全に省略して、ポリシーを構成しないようにします。

  • 動作: バケットとすべての接頭辞で書き込み時の取り込みがグローバルに無効になります。

親マネージド フォルダでプレフィックス レベルの書き込み時取り込みを有効にすると、親マネージド フォルダの下にネストされているすべての子マネージド フォルダで書き込み時取り込みが有効になります。リソースが書き込み時の取り込みの有効化と無効化を継承する仕組みについては、書き込み時の取り込みの継承の仕組みセクションをご覧ください。

書き込み時の取り込みの継承の仕組み

マネージド フォルダで書き込み時の取り込みが明示的に有効になっていない場合（マネージド フォルダの ingestOnWrite フィールドが unspecified に設定されている場合）、キャッシュの書き込み時の取り込み動作は、マネージド フォルダの親リソース（バケットまたは親マネージド フォルダ）から継承されます。

接頭辞レベルで書き込み時取り込みを使用する場合、親マネージド フォルダで構成した書き込み時取り込みの設定は、すべての子マネージド フォルダに継承されます。

たとえば、次のシナリオについて考えてみましょう。

• 親リソースがバケット my-bucket であるマネージド フォルダ a/ がある。
• 親リソースが my-bucket 内のマネージド フォルダ a/ であるマネージド フォルダ a/b/ がある。

a/b/info.txt という名前のオブジェクトが書き込まれると、Rapid Cache は構成階層を上から順に評価します。

1. 直近のマネージド フォルダを確認する: a/b/ が enabled に設定されている場合、a/b/ の下に書き込まれたオブジェクトに対して接頭辞レベルの書き込み時取り込みが有効になります。a/b/ が unspecified に設定されている場合、Rapid Cache は直近の親リソース（マネージド フォルダ a/）をチェックします。
2. 親マネージド フォルダを確認する: a/ が enabled に設定されている場合、a/ と a/b/ でプレフィックス レベルの書き込み時取り込みが有効になります。a/ が unspecified に設定されている場合、Rapid Cache は親バケットを確認します。
3. バケットのキャッシュレベルの ingestOnWrite 設定を確認する: キャッシュの ingestOnWrite フィールドが true に設定されている場合、バケットレベルの書き込み時取り込みが有効になり、接頭辞レベルの書き込み時取り込みが構成されているマネージド フォルダがオーバーライドされます。キャッシュの ingestOnWrite フィールドが false で、親と子の両方のマネージド フォルダの ingestOnWrite フィールドが unspecified の場合、親と子のマネージド フォルダの下にあるバケット内のオブジェクトの書き込み時取り込みは無効になります。このシナリオでは、バケットに ingest-on-write が構成された他のマネージド フォルダがない場合、バケット内のすべてのオブジェクトで ingest-on-write が無効になります。

有効期間（TTL）

キャッシュの TTL は、データが強制排除されるまでキャッシュに留まる期間を制御します。TTL は、データが最後の読み取りからキャッシュに残る期間です。たとえば、TTL が 24 時間に設定されている場合、月曜日の午前 11 時に最後に読み取られたデータのチャンクは、その後読み取られなかった場合、火曜日の午前 11 時にキャッシュから削除されます。

キャッシュの TTL は、キャッシュの作成時または更新時に設定できます。キャッシュの TTL は、24 時間から 7 日までの範囲で設定できます。指定しない場合、TTL はデフォルトで 24 時間になります。

キャッシュ オペレーション

このセクションでは、Rapid Cache キャッシュで実行できるオペレーションについて説明します。一部のオペレーションは非同期的で、長時間実行オペレーションを返します。他のオペレーションは同期的で、オペレーションはすぐに完了し、AnywhereCache リソースを返します。

キャッシュを作成する

キャッシュのロケーション、TTL、データ取り込み動作は、キャッシュの作成時に設定できます。キャッシュは作成中に [作成] 状態になり、アクティブに実行されると [実行] 状態になります。キャッシュ作成オペレーションには最大で 48 時間かかることがあります。この時間を超えると、オペレーションはタイムアウトします。

AnywhereCaches Create API は非同期的です。作成オペレーションを行うと、長時間実行オペレーションが返されます。長時間実行オペレーションにより、作成オペレーションのステータスが提供され、オペレーションが完了する前にオペレーションをキャンセルできます。

注: 作成オペレーションのキャンセルが試行された場合、サーバーは作成オペレーションのキャンセルに全力を尽くしますが、必ずしもキャンセルが成功するとは限りません。

キャッシュを更新する

キャッシュの TTL またはデータの取り込みの動作は、キャッシュの更新時に設定できます。更新できるのは、[実行] 状態のキャッシュのみです。ステータスが [作成] または [無効] のキャッシュは更新できません。

キャッシュの更新中、pending_update フィールドは true と評価されます。pending_update フィールドが true と評価されている間は、キャッシュを再度更新できません。キャッシュの TTL の更新が完了すると、新しい TTL がキャッシュ内の既存のデータと新しいデータの両方にすぐに適用されます。

AnywhereCaches Update API は非同期的で、長時間実行オペレーションを返します。

キャッシュを取得する

キャッシュを取得すると、Rapid Cache はキャッシュ インスタンスの状態と構成を返します。AnywhereCaches Get API は同期的で、AnywhereCache リソースを返します。

キャッシュのリストを表示する

特定のバケットに関連付けられたキャッシュのリストを返すことができます。AnywhereCaches List API は同期的で、ページ分割をサポートしています。

キャッシュを無効にする

キャッシュを無効にすると、バケットの構成からキャッシュを完全に削除できます。キャッシュを無効にすると、キャッシュは [無効] 状態になります。この状態の間、キャッシュから既存のデータを読み取ることはできますが、新しいデータをキャッシュに取り込むことはできません。

キャッシュを無効にすると、1 時間の猶予期間が設けられます。この期間中にキャッシュを再開すると、無効化をキャンセルできます。この 1 時間の猶予期間が過ぎると、キャッシュは削除されます。キャッシュが削除されると、キャッシュ内のすべてのデータが強制排除され、キャッシュはバケットから削除されます。

キャッシュが削除されるまでの 1 時間の間に、キャッシュを再開して [無効] 状態を元に戻すことができます。この時点で、キャッシュは [実行] 状態になります。

AnywhereCaches Disable API は同期的で、AnywhereCache リソースを返します。

キャッシュを再開する

無効なキャッシュが 1 時間の猶予期間内にある限り、[無効] 状態のキャッシュを再開できます。1 時間の猶予期間が過ぎると、キャッシュはいつでも削除される可能性があるため、再開オペレーションはベスト エフォート方式で実行されます。キャッシュが再開されると、[実行] 状態になります。

AnywhereCaches Resume API は同期的で、AnywhereCache リソースを返します。

Rapid Cache Recommender

Rapid Cache Recommender は、データ使用量とストレージを分析して、バケットゾーン ペアでキャッシュを作成するための推奨事項と分析情報を提供します。Rapid Cache Recommender の概要と使用方法については、Rapid Cache Recommender をご覧ください。

Rapid Cache を使用して BigQuery の読み取りを高速化する

Rapid Cache を使用して、BigQuery によって発行されたオブジェクト読み取りリクエストのデータを配信できます。Rapid Cache を使用すると、費用対効果を最適化しながら、アプリケーションのデータ読み取りを高速化できます。

BigQuery はリージョン サービスですが、基盤となるコンピューティング リソースはロード バランシングのためにゾーン間で移動することがあります。ベスト プラクティスとして、リージョンのすべてのゾーンで BigQuery ワークロードの Rapid Cache を有効にして、基盤となるコンピューティング リソースがゾーンを変更した場合に使用できるキャッシュを確保します。ゾーン内のキャッシュが使用されていない場合、Rapid Cache は従量課金制であるため、追加費用は発生しません。ワークロードのリソースがゾーンを変更すると、新しいゾーンのキャッシュでデータの再取り込みが必要になり、データ取り込み費用が一時的に増加する可能性があります。

キャッシュに保存されたデータの暗号化

データは、データの元のサーバーサイド暗号化形式でキャッシュに保存されるため、Cloud Storage でサポートされている暗号化オプションとの互換性が確保されます。

制限事項

• バケットを削除するには、まず関連付けられているすべてのキャッシュを削除する必要があります。唯一の例外は、 Google Cloud コンソールを使用してバケットを削除する場合です。この場合、バケットに関連付けられているすべてのキャッシュがバケットとともに削除されます。

• キャッシュの作成、無効化、再開、更新のオペレーションを実行する場合は、オペレーションのレートを 1 秒あたり 1 回以下に制限します。1 秒あたり複数のオペレーションを実行すると、失敗する可能性があります。

• Rapid Cache は耐久性のあるストレージではなく、さまざまなシナリオでデータがキャッシュから削除される可能性があります。たとえば、ワークロードに十分なリソースを確保するために、キャッシュのサイズが自動的に変更される場合があります。このシナリオでは、Rapid Cache サービスがキャッシュサイズの増加を完了するまで、一部のデータが LRU（最も長い間使われていないものを特定する）アルゴリズムに基づいて強制排除される可能性があります。

  いずれの場合も、データはソースバケットに安全に保存されます。TTL の期限切れ以外の理由でデータがキャッシュから削除されると、Rapid Cache サービスは、費用をかけず透過的にデータをキャッシュに再取り込みしようとします。データを透過的に再取り込みできない場合や、TTL の期限切れにより破棄された場合、Rapid Cache サービスは最初の読み取りでデータを再取り込みします。

• Rapid Cache Recommender によって生成された推奨事項と分析情報は、BigQuery を使用して読み取ることはできません。

パフォーマンスに関する注意事項

• チャンクミス: リクエストが複数のチャンクを対象としており、一部のチャンクがキャッシュに存在し、他のチャンクが存在しない場合、Rapid Cache は欠落しているチャンクをソースバケットから透過的に取得します。

• TTL と削除: 有効期間（TTL）と Least Recently Used（LRU）削除ポリシーもチャンクで動作します。大きなファイルで頻繁に使用される部分はキャッシュに残り、あまり使用されない部分は削除されることがあります。

料金

Rapid Cache の使用料金については、Rapid Cache の料金をご覧ください。

費用管理

キャッシュの実行コストを最小限に抑える方法については、次のヒントをご覧ください。

バケットの選択

キャッシュに保存するデータを含むバケットにのみキャッシュを作成する必要があります。

ゾーンの選択

ワークロードがキャッシュ化のメリットを得られるゾーンにのみキャッシュを作成する必要があります。

TTL の設定

キャッシュにデータを保存するために必要な最小 TTL を指定する必要があります。TTL は中断なく変更できます。デフォルトは 1 日です。

キャッシュを無効にする

キャッシュを無効にすると、サービスからキャッシュが完全に削除され、関連するすべてのキャッシュ料金が発生しなくなります。

一時的なリソース不足のトラブルシューティング

次のセクションでは、一時的なリソース不足が発生した場合のトラブルシューティング方法について説明します。一時的なリソース不足とは、指定されたゾーンにキャッシュの作成、キャッシュ サイズの増加、キャッシュ帯域幅の上限の引き上げに十分な SSD 容量または処理能力がない状態を指します。

新しいキャッシュを作成できない

SSD 容量またはスループット サービング リソースが不足しているため、Rapid Cache で特定のゾーンに新しいキャッシュを作成できない場合、リソースが一時的に不足することがあります。この期間中、Rapid Cache は最大 48 時間、新しいキャッシュの作成を試みます。48 時間以内にリソースが使用可能になると、Rapid Cache はキャッシュ作成リクエストを正常に完了します。48 時間以内にリソースが使用可能にならない場合、キャッシュ作成リクエストは失敗します。

トラブルシューティング方法: キャッシュの停止を回避するには、キャッシュ作成オペレーションを手動でキャンセルし、容量が利用可能な別のゾーンに新しいキャッシュを作成します。キャッシュ作成オペレーションをモニタリングまたはキャンセルするには、長時間実行オペレーションの使用をご覧ください。

キャッシュ サイズを増やせない

必要な SSD 容量がキャッシュのゾーンで使用できない場合、Rapid Cache はキャッシュのサイズを増やせないことがあります。

Rapid Cache では、キャッシュ サイズの自動増加をオンデマンドで提供していますが、キャッシュサイズの増加は SSD 容量の可用性に依存します。キャッシュ サイズの自動増加リクエストが行われたときに SSD 容量を使用できない場合、Rapid Cache は、一時的なリソース不足が終了するか、キャッシュ サイズの増加が不要になるまでリクエストを送信し続けます。

一時的なリソース不足が発生した場合、新しいデータが取り込まれ、キャッシュ内の既存のデータが使用日が古い順番に基づいて強制排除されます。ホットデータのほとんどを保存するのに十分な大きさのキャッシュでは、キャッシュ指標への影響はほとんどありません。ホットデータの量よりも容量が小さいキャッシュでは、リソース不足の影響を受けないキャッシュよりも、データが強制排除され、同じデータが再取り込みされる頻度が高くなります。キャッシュの実際のサイズが必要な容量よりもはるかに小さい場合、リソース不足に関連する次の動作が発生することがあります。

• キャッシュ帯域幅の上限の低下、キャッシュ スループットの低下、データ転送帯域幅割り当ての消費量の増加、他の指標への影響の可能性
• 課金に次のような影響が生じる可能性があります。
  • キャッシュ取り込み料金による費用増加
  • キャッシュ ストレージ料金による費用削減
  • キャッシュ データ転送（送信）料金による費用削減
  • キャッシュ データ転送（送信）オペレーション料金による費用削減
  • マルチリージョン データ転送料金による費用増加
  • クラス B オペレーションの使用による費用増加

これらの料金については、Rapid Cache の料金をご覧ください。

トラブルシューティング方法: 一時的なリソース不足の際に最良の結果を得るには、キャッシュをモニタリングし、ニーズに応じて不要なキャッシュまたはワークロードを無効にすることをおすすめします。

キャッシュの帯域幅上限をスケールアップできない

特定のゾーンでスループット サービング リソースが、既存のキャッシュのキャッシュ帯域幅の上限を TiB あたり 20 Gbps にスケーリングするのに不十分な場合、キャッシュ サイズの増加中に、キャッシュ帯域幅の上限が一時的に不足することがあります。使用可能なキャッシュ帯域幅が不足している場合、Rapid Cache ではキャッシュ帯域幅の上限が 1 TiB のデータあたり 20 Gbps にスケーリングすることはありませんが、キャッシュは読み取りリクエストを引き続き処理します。キャッシュ帯域幅の増量をリクエストするには、テクニカル アカウント マネージャーまたは Google の担当者にお問い合わせください。使用可能なキャッシュ帯域幅が不足している場合、バケットのデータ下り（外向き）帯域幅の使用量が増加する可能性があります。

トラブルシューティング方法: 一時的なリソース不足の際に最良の結果を得るには、キャッシュをモニタリングし、ニーズに応じて不要なキャッシュまたはワークロードを無効にすることをおすすめします。

次のステップ

• キャッシュを作成、管理する。