このページでは、Cloud Storage バケットに SSD ベースのゾーン読み取りキャッシュを提供する Rapid Cache について説明します。これにより、保存されたデータのスループットを向上させ、レイテンシを短縮できます。Rapid Cache は、ニーズに合わせて自動的にスケールアップまたはスケールダウンするストレージ容量と帯域幅を提供します。
このようなメリットがあるため、Rapid Cache は、パフォーマンスの向上と、読み取り負荷の高いワークロードに関連するネットワーク コストの削減に役立ちます。
Rapid Cache でキャッシュを作成して管理する方法については、キャッシュを作成して管理するをご覧ください。
仕組み
Rapid Cache を使用すると、ワークロードと同じゾーンにキャッシュを作成できます。ゾーンにキャッシュを作成すると、ゾーンから発信されたデータ読み取りリクエストは、バケットではなくキャッシュによって処理されます。各キャッシュは、キャッシュと同じゾーン内のクライアントにサービスを提供します。データは、キャッシュと同じゾーンにある VM によって読み取られた場合にのみ、バケットからキャッシュに取り込まれます。また、書き込み時の取り込みを構成すると、データがバケットに書き込まれたときにデータを取り込むことができます。メタデータはキャッシュに保存されず、オブジェクト メタデータのリクエストはキャッシュではなくバケットで処理されます。
Rapid Cache はフルマネージド サービスであり、常に一貫したデータを返します。
利点
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-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 |
データの取り込み
デフォルトでは、データは最初にリクエストされた後にのみキャッシュに取り込まれます。この最初のリクエストではキャッシュが空であるため、最初の読み取りではキャッシュミスが発生し、システムは代わりにバケットからデータを取得します。データがユーザーに配信されると同時に、キャッシュに取り込まれます。その結果、後続の読み取りはすべてキャッシュ ヒットとしてキャッシュから直接提供され、パフォーマンスが大幅に向上します。
最初のリクエストの遅延を完全に回避するには、書き込み時にデータを取り込むようにキャッシュを構成します。つまり、データがバケットに書き込まれた瞬間にデータが読み込まれます。書き込み時にデータをキャッシュに読み込むことは、システム チェックポイントの復元やモデル トレーニング用のデータ パイプラインの準備など、最初の読み取りから高速な速度を必要とするワークフローに最適です。
データをキャッシュに取り込むとき、Rapid Cache はオブジェクトを固定サイズの小さなチャンクに分割します。オブジェクトをチャンクに分割すると、特に特定の部分のみがアクセスされる大きなファイルの場合に、よりきめ細かいキャッシュ保存が可能になります。
チャンクは 2 MB のデータブロックです。オブジェクトのリクエストが行われると、Rapid Cache はリクエストされたバイト範囲をカバーする 2 MB のチャンクを特定し、それらのチャンクを個別に管理します。
データの取り込みの動作は、キャッシュに取り込まれるオブジェクトのサイズによって異なります。
2 MB を超えるオブジェクトに対する読み取りリクエストの場合、リクエストされたバイト範囲を含むチャンクのみが取り込まれます。たとえば、100 MB のファイルの最初の 1 MB を読み取る場合、最初の 2 MB のチャンクのみが取り込まれます。
2 MB 未満のオブジェクト（500 KB の画像など）に対する読み取りリクエストの場合、オブジェクト全体がキャッシュに取り込まれます。
キャッシュの構成
次のプロパティは、作成または更新オペレーション中にキャッシュを構成するときに設定できます。
有効期間（TTL）
TTL は、データ チャンクが最後の読み取りからキャッシュに残る最長時間です。たとえば、TTL が 24 時間に設定されている場合、月曜日の午前 11 時に最後に読み取られたデータのチャンクは、その後読み取られなかった場合、火曜日の午前 11 時にキャッシュから削除されます。TTL は 24 時間～ 7 日の範囲で設定できます。指定しない場合、TTL はデフォルトで 24 時間になります。
書き込み時に取り込む
オブジェクトの書き込み時にデータをキャッシュに取り込むと、チェックポイントやトレーニング ジョブのデータ準備の出力など、書き込み後の読み取りワークロードが高速化されます。書き込み時にデータを取り込むようにキャッシュを構成すると、データがバケットにアップロードされると同時にキャッシュに書き込まれます。このプロアクティブなアプローチにより、最初のキャッシュミスが解消され、ワークロードは最初の読み取りで即座にキャッシュ ヒットの恩恵を受けることができます。
キャッシュ オペレーション
このセクションでは、Rapid Cache キャッシュで実行できるオペレーションについて説明します。一部のオペレーションは非同期的で、長時間実行オペレーションを返します。他のオペレーションは同期的で、オペレーションはすぐに完了し、AnywhereCache リソースを返します。
キャッシュを作成する
キャッシュを作成すると、キャッシュは作成中に [作成] 状態になり、アクティブに実行されると [実行] 状態になります。キャッシュ作成オペレーションには最大で 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 ワークロードの高速キャッシュを有効にして、基盤となるコンピューティング リソースがゾーンを変更した場合に使用できるキャッシュを確保します。ゾーン内のキャッシュが使用されない場合、高速キャッシュは従量課金制であるため、追加費用は発生しません。ワークロードのリソースがゾーンを変更すると、新しいゾーンのキャッシュでデータの再取り込みが必要になり、データ取り込み費用が一時的に増加する可能性があります。
キャッシュに保存されたデータの暗号化
データは、データの元のサーバーサイド暗号化形式でキャッシュに保存されるため、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 の担当者にお問い合わせください。使用可能なキャッシュ帯域幅が不足している場合、バケットのデータ下り（外向き）帯域幅の使用量が増加する可能性があります。
トラブルシューティング方法: 一時的なリソース不足の際に最良の結果を得るには、キャッシュをモニタリングし、ニーズに応じて不要なキャッシュまたはワークロードを無効にすることをおすすめします。