キャッシュとは?

キャッシュは、キーと値のデータをメモリに保存する手法です (非リレーショナルな構造化クエリ言語 (NoSQL) データベースなど)。これにより、アプリケーションは従来のストレージよりもすばやくデータを取得できます。クラウド ストレージ アーキテクチャでは、要求がネットワークをまたぎ、共有サービスにアクセスすることが多いため、キャッシュは応答時間を短く保ち、繰り返しの処理を減らすのに役立ちます。

多くのシステムでは、完全なデータセットのために永続的な「正本」 (データベース) を保持し、さらに頻繁に読み取られる一時的なサブセットのためにキャッシュを保持します。要求が届くと、アプリはまずキャッシュを確認します。データがあれば、バックエンドを再度クエリせずにすぐに返します。開発者は処理済みデータもキャッシュし、標準的なクエリよりも高速に要求を処理するためにそのデータを再利用します。対象はリレーショナル データベース、SQL データベース、またはオープン ソースの PostgreSQL データベースです。

1. よく読み取るデータをキャッシュする

適した候補は、繰り返し読み取られるデータと、変更頻度の低いデータです (たとえば、製品情報や価格情報、または作成コストの高い共有静的リソースなど)。

2. 繰り返し行う作業の結果をキャッシュする

操作でデータを変換したり、複雑な計算を実行したりする場合は、結果をキャッシュしておくことで、後続の要求で再計算するのを避けられます。

3. 必要なときにキャッシュ レイヤーを使用する

開発者は、複数レベルのキャッシュ ("キャッシュ レイヤー") を使用して、需要に応じて異なる種類のデータを別々のキャッシュに保存します。キャッシュ レイヤーを 1 つ以上追加すると、データ レイヤーのスループットと待機時間を改善できます。

4. レスポンシブ アプリのためにセッション状態を近くで保持する

インメモリ ストアは多くの場合、ユーザー入力、ショッピング カートのエントリ、個人用設定など、大量のセッション データを短期間保持するために使われます。ステートフル アプリでは、アプリをステートレスにできるように、チームはセッション状態もキャッシュに保存します。

キャッシュは、いくつかの具体的な方法でパフォーマンスを向上させることができます:

• インメモリ キャッシュからのデータ読み取りは、ディスクドリブン ストアからデータにアクセスするよりも高速です。
• クエリ数を減らすと負荷を削減し、データベース インフラストラクチャのスケーリングの必要性も抑えられるため、コスト削減にもつながります。
• キャッシュ レイヤーはスループットと待機時間を改善でき、インメモリ キャッシュは使用量の急増時の待機時間の緩和に役立ちます。
• キャッシュ インスタンスは 1 秒あたり数百万件の要求を処理でき、多くのデータベースは匹敵できないスループットを提供します。

多くのクラウド設計では、キャッシュはプライマリ データ ストア (たとえばデータベース) の隣に配置されます。プライマリ ストアはクラウド サーバー上に完全で永続的なデータセットを保持し、キャッシュは読み取りが速い、より小さな一時的なサブセットを保持します。

一般的な設定は、スタンドアロンのキャッシュ レイヤー、またはアプリ層やデータベース層の内部に配置されたキャッシュです。どこで高速な読み取りが必要かに応じて選択します。

システムによっては、マルチレベル キャッシュ (“キャッシュ レイヤー”) を使用して、需要に応じて異なる種類のデータを別々のキャッシュに配置します。キャッシュ レイヤーを 1 つ以上追加すると、データ レイヤーのスループットと待機時間が改善され、バックエンドの負荷が減ることで全体のコストが削減されます。

通常、チームはいくつかの種類に分類されるデータをキャッシュします:

• 頻繁に読み取られるデータ (特に変更頻度が低い場合)。たとえば、製品情報や価格情報、または作成コストの高い共有静的リソースなどです。
• 繰り返される計算。操作でデータを変換したり、複雑な計算を実行したりする場合、結果をキャッシュしておけば、後続の要求で同じ処理を再実行する必要がありません。
• セッション状態。ステートフル アプリでは、セッション状態をキャッシュに保存すると、アプリ層をステートレスに保つのに役立ちます。

アプリがキャッシュに対して読み取りおよび書き込みする標準的な方法はいくつかあります。ここでは、最も一般的なパターンと、実際にどのような意味を持つのかを示します。

• キャッシュ アサイド: データ ストアから必要に応じてデータを読み込みます。
• Read-through: キャッシュから読み取り、必要に応じてキャッシュがデータ ストアからフェッチします。
• ライトスルー: キャッシュに書き込み、同調してデータ ストアと再同期します。
• ライトバック (write-behind): キャッシュに書き込み、バッチでデータ ストアに書き戻します。
• Write-around: データ ストアに書き込み、キャッシュから読み取ります。キャッシュは必要に応じて更新されます。

キャッシュ レイヤーを使用すると、バックエンド ストアに繰り返しクエリする代わりに、一般的な要求をキャッシュから処理することで、スループットと待機時間を向上させることができます。これにより、第一にデータベースに到達する要求数が少なくなるため、データベース インフラストラクチャをスケーリングする必要性を低減できます。

使用量が急増するアプリでは、インメモリ キャッシュを使うと、頻繁に要求されるデータを使用場所の近くに保持するため、待機時間の軽減に役立ちます。

ワークフローを選ぶときは、次を出発点として使用します:

• アプリで保存する内容と更新するタイミングを判断できる場合は、キャッシュ アサイドを優先します。
• “必要に応じて” データ ストアからのフェッチをキャッシュに処理させたい場合は、read-through を優先します。
• 書き込みの動作が重要で、定義された再同期アプローチが必要な場合は、ライトスルーまたはライトバックを検討します。

インメモリ キャッシュからの読み取りはディスクドリブン データ ストアからの読み取りより高速なため、キャッシュを使うとアプリケーションのパフォーマンスが向上します。より多くの要求がキャッシュから処理されると、システムがバックエンド データベースに送信するクエリが減り、データベース インフラストラクチャをスケーリングする必要性が減り、関連コストを低減できます。

通常のキャッシュによる利点

• 頻繁に要求されるデータはより高速なレイヤーから取得されるため、一般的な読み取りがさらに低遅延となります。
• キャッシュを使うとデータベース クエリが減り、データベース インスタンスをオーバープロビジョニングする必要性も減るため、データベースの負荷とコストを削減できます。
• キャッシュは、多くのデータベースと比べて非常に大量の要求を処理できるため、スループットがより予測しやすくなります。
• インメモリ キャッシュは高スループットの間の待機時間を軽減できるため、トラフィックの急増もより円滑に処理できます。

キャッシュは、繰り返される作業を減らすのに役立ちます。繰り返し読み取られるデータ、または作成コストの高いデータは、一度保存して再利用できます。操作で複雑な計算を実行したりデータを変換したりする場合、結果をキャッシュすると、後続の要求で繰り返される計算が削減されます。

一般的な “適したキャッシュ” 候補

• 変更頻度の低いデータ (たとえば、製品情報や価格情報)。
• 作成コストの高い共有静的リソース。
• 繰り返し計算される演算の結果。

Web サイト: ページの読み込みが速くなり、ラウンド トリップが減る

多くのサイトはページ出力 (HTML やクライアント スクリプトなど) をキャッシュするので、サーバーは、ページ コードを毎回再実行する代わりに、キャッシュされた出力を返すことができます。キャッシュは、コンテンツ配信ネットワーク (CDN) などの Web キャッシュやネットワーク キャッシュを通じて、Web マルチメディア シナリオもサポートします。

Web サイトでの一般的な使用法

• 繰り返し表示するためにページ出力全体をキャッシュします。
• ネットワーク/CDN キャッシュを使って静的アセットをキャッシュします。

アプリと API: 共有データの読み取りを高速化

アプリは通常、すばやく取得するために一時的なデータのサブセットをキャッシュに保存する一方、プライマリ データベースが完全で永続的なデータセットを保持します。処理済みデータをキャッシュして再利用すると、標準的なデータベース クエリよりも迅速に要求を処理できます。

一般的なアプリ パターン

• 頻繁に読み取られる参照データ (価格など) をキャッシュして、繰り返されるデータベース呼び出しを減らします。
• 計算済みの結果をキャッシュして、コストの高い作業の繰り返しを回避します。

サーバーとサービス: 読み取りのスケーリングと急増の平滑化

チームは通常、1 つ以上のキャッシュ レイヤーを追加してスループットと待機時間を改善し、一般的なクエリをキャッシュから処理してデータベースの負荷を削減します。使用量が急増し、スループット需要が高まるときは、インメモリ キャッシュを使うと、その期間の待機時間を軽減するのに役立ちます。

特に効果が大きい場所

• 同じキーが頻繁に要求される読み取り頻度の高いエンドポイント。
• 定期的にトラフィックの急増が見られるシステム。

ビジネス システム: セッション状態と共有運用データ

キャッシュは多くの場合、大量で有効期間の短いセッション データ (ユーザー入力や個人用設定など) を、インメモリ ストアに保存するために使われます。チームによっては、ステートフル アプリがアプリ層をステートレスに保持できるように、セッション状態もキャッシュに保存します。運用システムでは、変更頻度の低いデータ (製品情報や価格情報など) が一般的なキャッシュ対象です。

ビジネス ワークロードにマッピングできる例

• Web アプリおよびモバイル アプリのセッション データ (有効期間が短く、大量)。
• 頻繁に読み取られる運用上の参照データ (価格、共有リソース)。

ブラウザー キャッシュは、静的リソースのコピーをユーザーのデバイスに保存するため、繰り返しアクセスしても静的リソースを再度ダウンロードする代わりに、それらのファイルを再利用できます。

一般的なユース ケース

• 画像、CSS ファイル、JavaScript ファイルなどの静的サイト資産。
• 以前にフェッチしたリソースに関する、元のサーバーへのラウンドトリップを減らします。

サーバー側のキャッシュは、エンド ユーザーのデバイスではなく、リモートでビジネス サービスを実行するプロセス内で発生します。サーバー側キャッシュは、多くの場合、プライベート (1 つのアプリ インスタンスにローカル) または共有 (多数のアプリ インスタンスによって使用) のいずれかです。

一般的なユース ケース

• 単一プロセス内のプライベートなインメモリ キャッシュで、少量の静的データに適しています。
• 共有キャッシュ サービスを使うと、複数のアプリ インスタンスが同じキャッシュ値を読み取り、インスタンス間で “異なるバージョン” が生じるのを回避します。
• 頻繁に読み取られるが、変更頻度が低いデータ (たとえば、製品や価格の参照データ)。

CDN はエッジ サーバー上でエンド ユーザーの近くににコンテンツをキャッシュするため、要求は常に元のサーバーに戻るとは限りません。ブラウザー キャッシュ (1 人のユーザー) とは異なり、CDN キャッシュは共有されます。1 人のユーザーの要求によって、後で別のユーザーが受け取るコンテンツを事前設定することができます。

一般的なユース ケース

• エッジの場所からキャッシュ可能なコンテンツを共有配信することで、元のサーバーへの要求を削減します。
• ユーザーの近くで処理することから利点がもたらされる静的リソース (ブラウザーがキャッシュするのと同じ種類の資産ですが、ユーザー間で共有されます)。

キャッシュはクラウド コンピューティングのパターンだけではなく、ハードウェア レイヤーやメモリ レイヤーでも使用されます。

CPU キャッシュは、プロセッサの近く(またはその上) にある小さい高速メモリ領域で、頻繁に使われるデータや命令のコピーを保存し、メイン メモリの待ち時間を短縮します。

メモリ (インメモリ) キャッシュは、最も単純なソフトウェア キャッシュの種類です。単一プロセスのアドレス空間内で保持され、そのプロセスから直接アクセスされるインメモリ ストアです。

一般的なユース ケース

• CPU キャッシュ: メイン メモリへ頻繁にアクセスすることなく、同じ命令やデータに繰り返しアクセスします。
• メモリ内キャッシュ: 1 つの実行中のサービス内にある、少量の比較的静的なデータをすばやく読み取ります。

分散キャッシュは複数のサーバーにまたがるため、1 台のマシンを超えてキャッシュとトランザクション容量を拡張できます。多くの共有キャッシュ サービスはサーバーのクラスターを使用し、キャッシュされたデータをクラスター全体に分散します。キャッシュのスケーリングは、サーバーを追加するだけで済む場合があります。また、一部の分散設計ではキャッシュを階層化し、あるレイヤーでミスが発生すると上流のプロバイダーから取得して、その結果を次の要求のためにローカルに保存します。

一般的なユース ケース

• 複数のアプリ インスタンスおよびマシン向けの共有キャッシュ層。
• 単一のホストを超えるキャッシュ容量とスループットを必要とするワークロード。
• ミスが発生すると上流からフェッチし、後続の要求のためにローカル コピーを保持する階層型キャッシュ設定。

キャッシュを使うと、頻繁にアクセスされるデータが使用場所の近くに保持されるため、応答時間を改善し、システムがより多くの同時要求を処理できるようになります。また、データベースの接続数に制限がある場合など、元のデータ ストアでの競合を減らすこともできます。

分散アプリケーションでは、キャッシュは通常、クライアント側 (ブラウザーなど) とサーバー側 (アプリケーションまたは共有キャッシュ サービス内) の複数の場所で発生します。

小さく始めて、最も明確な成果が得られるデータに重点を置きます:

• 変更頻度が低く、読み取り負荷の高い、取り込みに時間がかかるデータ (たとえば、参照データ) をキャッシュします。
• データをキャッシュに入れるタイミングを決める:
  • 最初の要求の後に必要に応じてキャッシュし、実際に使用されるものだけを保存します。
  • 早期に要求されることが分かっている場合は、起動時にいくつかの項目を事前設定 (シード) します。ただし、元のストアへの起動時負荷に注意してください。
• 管理できるパターンを選びます。キャッシュ アサイド パターンは一般的で、そのガイダンスでは、有効期限、削除、および一貫性が結果にどのように影響するかが強調されています。

キャッシュには通常、プライマリ ストアのデータのコピーが保持されるため、鮮度に注意が必要です:

• 有効期限ポリシーを使用して、データが更新されるまでキャッシュ内に保持できる期間を制限します。
• キャッシュがいっぱいになったときの削除動作を確認します (多くのシステムでは、既定では最近最も使用されていない項目を無効にします)。
• キャッシュを重要なデータの唯一のホームとして扱わないでください。キャッシュが利用できない場合でもシステムを継続できるように、永続ストレージに正本を保持します。
• キャッシュに到達できない場合に備えて元のデータ ストアへの代替パスを計画し、読み取り発生時に再度事前設定します。

キャッシュは、単一サービスから分散アプリ、エッジ配信まで多くのアーキテクチャに適合するため、最新のシステムにおけるコアの構成要素です。マネージド インメモリ キャッシュ クラウド プロバイダーについては、Azure で詳細を確認できます。