Trace Id is missing
メイン コンテンツにスキップ

キャッシュとは何ですか?

開発者や IT 担当者はキャッシュを使用して、従来のデータ ストレージに保存されているデータよりも、より速く、より少ない労力で、一時メモリにキーと値のデータを保存し、アクセスできるようにすることができます。キャッシュは、ランダム アクセス メモリ (RAM) を使用したコンピューター キャッシュ、コンテンツ デリバリー ネットワーク上のネットワーク キャッシュ、Web マルチメディア データ用の Web キャッシュ、クラウドアプリの耐障害性を高めるためのクラウド キャッシュなど、さまざまのテクノロジを使用したさまざまなシナリオで役立ちます。開発者は多くの場合、処理済みのデータをキャッシュし、それを再利用することで、標準的なデータベース クエリよりも高速にリクエストに対応できるようにアプリケーションを設計します。

キャッシュを利用することで、データベースのコストを削減したり、一般的なデータベースよりも高いスループットと低遅延を実現したり、クラウド アプリケーションや Web アプリケーションのパフォーマンスを向上させたりすることができます。

データベースのキャッシュの動作

開発者は、データベース キャッシュによってプライマリ データベースを補完することができます。これは、データベースやアプリケーションの中に配置したり、スタンドアロンのレイヤーとして設定したりすることができます。通常、大規模で耐久性のある完全なデータセットの保存に従来型のデータベースが利用されていますが、キャッシュを使用してデータの一時的なサブセットを保存することで、すばやく取得することができます。

キャッシュは、NoSQL データベースや、SQL サーバー、 MySQL、 MariaDB などのリレーショナル データベースを含む、あらゆる種類のデータ ストアで使用できます。キャッシュは、 Azure Database for PostgreSQL、 Azure SQL Database、 Azure SQL Managed Instance など、多くの特定のデータ プラットフォームでも適切に機能します。データ アーキテクチャの構成を開始する前に、どの種類のデータ ストアがお客様の要件を最も満たすかを調査することをおすすめします。たとえば、リレーショナルと非構造化のデータ ストアを組み合わせるために使用する前に、PostgreSQL とは何であるかを理解しておくことをおすすめします。

キャッシュ レイヤーのメリット、そして Redis とは

開発者は、キャッシュ レイヤーと呼ばれる複数レベルのキャッシュを使用して、需要に応じて異なる種類のデータを別々のキャッシュに格納します。キャッシュ レイヤーを 1 つ、または複数追加することで、データ レイヤーのスループットと待機時間のパフォーマンスを大幅に向上させることができます。

Redis は、ハイパフォーマンスのキャッシュ レイヤーやその他のデータ ストアの構築に使用される、人気の高いオープンソースのインメモリ データ構造です。最近の調査では、サンプル アプリケーションに Azure Cache for Redis を追加することで、データ スループットが 800% 以上向上し、待機時間のパフォーマンスが 1,000% 以上改善したこと1が示されています。

また、キャッシュを使用することで、データ レイヤーの総保有コスト (TCO) を削減することができます。キャッシュを使用して最も一般的なクエリに対応し、データベースの負荷を軽減することで、データベース インスタンスを過剰にプロビジョニングする必要性が減り、大幅なコスト削減と TCO の抑制が可能になります。

キャッシュの種類

お客様のキャッシュ戦略は、お使いのアプリケーションがどのようにデータを読み書きするかによって決まります。アプリケーションでの書き込みが多い、またはデータが一度書き込まれてから頻繁に読み込まれる、返されるデータは常に一意であるかなど、データのアクセス パターンが異なれば、キャッシュの設定方法も異なります。一般的なキャッシュの種類には、キャッシュアサイド、リードスルー/ライトスルー、ライトビハインド/ライトバックなどがあります。

キャッシュ アサイド

読み取り負荷の高いアプリケーションの場合、開発者はよくキャッシュ アサイドのプログラミング パターン、すなわち "サイドキャッシュ" を使用します。サイドキャッシュをアプリケーションの外部に配置することで、それがキャッシュと接続してデータをクエリして取得したり、データがキャッシュ内にない場合はデータベースに直接接続したりすることができます。アプリケーションによりデータが取得されると、後のクエリの実行に備えてデータがキャッシュにコピーされます。

サイドキャッシュを使用することで、アプリケーションのパフォーマンスを向上させたり、キャッシュとデータ ストア間の一貫性を維持したり、キャッシュ内のデータが古くならないように維持したりすることができます。

リードスルー/ライトスルー キャッシュ

リードスルー キャッシュは、自分自身を最新の状態に保ちます。一方、ライトスルー キャッシュは、アプリケーションによりデータがキャッシュに書き込まれた後に、データベースに書き込まれます。どちらのキャッシュもデータベースと並置され、これらはアプリケーションでメインのデータ ストアとして処理されます。

リードスルー キャッシュを使用すると、同じデータが何度も要求されるアプリケーションを簡素化することができますが、キャッシュ自体は複雑なものであり、2 段階のライトスルー プロセスにより待機時間が発生します。開発者は、この 2 つを組み合わせることで、キャッシュとデータベース間のデータの一貫性を確保し、ライトスルー キャッシュの待機時間を短縮し、リードスルー キャッシュの更新を簡単なものにすることができます。

リードスルー/ライトスルー キャッシュを使用することで、開発者はアプリケーション コードを簡素化し、キャッシュのスケーラビリティを向上させ、データベースの負荷を最小限に抑えることができます。

ライトビハインド/ライトバック キャッシュ

このシナリオでは、アプリケーションによりデータがキャッシュに書き込まれ、それが認識された後すぐに、キャッシュ自身によりデータベースにデータがバックグラウンドで書き戻されます。ライトバック キャッシュとも呼ばれるライトビハインド キャッシュは書き込みの負荷の高いワークロードに最適で、次のタスクに移る前に書き込みが完了するのをアプリケーションで待機する必要がないため、書き込みパフォーマンスが向上します。

分散キャッシュとセッション ストアの比較

分散キャッシュとセッション ストアはよく混同されますが、これらは似ているようで要件や目的が異なります。開発者は、データベースを補完するために分散型キャッシュを使用するのではなく、Web アプリのようなセッション指向のアプリケーションにおいて、プロファイル、メッセージ、その他のユーザー データ向けに、ユーザー レイヤーの一時データ ストアであるセッション ストアを実装します。

セッション ストアとは

セッション指向のアプリケーションでは、ユーザーがアプリケーションにサインインしている間に行ったアクションが追跡されます。ユーザーがサインアウトしたときにそのデータを保持するために、それをセッション ストアに保存することができます。これによりセッション管理が改善され、コストが削減され、アプリケーションのパフォーマンスが向上します。

セッション ストアの使用と、データベース キャッシュの違い

セッション ストアでは、データは異なるユーザー間で共有されません。一方、キャッシュを使用すると、異なるユーザーが同じキャッシュにアクセスできます。開発者は、データベースまたはストレージ インスタンスのパフォーマンスを向上させるためにキャッシュを使用します。一方で、セッション ストアを使用してデータをインメモリ ストアに書き込むことによりアプリケーションのパフォーマンスを向上させることができ、データベースにアクセスする必要もまったくありません。

セッション ストアに書き込まれたデータは一般的に有効期間が短く、プライマリ データベースにキャッシュされたデータは通常、より有効期間が長くなります。セッション ストアでは、トランザクション データが失われないようにするため、レプリケーション、高可用性、およびデータの耐久性が必要です。一方、サイドキャッシュ内のデータが失われても、そのコピーが永続データベース内に常に維持されます。

キャッシュの利点

アプリケーション パフォーマンスの向上

インメモリのキャッシュからのデータ読み取りは、ディスクドリブンのデータ ストアからデータにアクセスするよりもはるかに高速です。また、データへのアクセスが高速化することで、アプリケーション全体のエクスペリエンスが大幅に向上します。

データベースの使用量とコストの削減

キャッシュによってデータベースへのクエリ回数が減り、パフォーマンスが向上するとともに、データベース インフラストラクチャをスケーリングする必要がなくなり、またスループット料金も減るため、コストを削減できます。

スケーラブルで予測可能なパフォーマンス

単一のキャッシュ インスタンスで 1 秒間に数百万のリクエストを処理することができるため、データベースでは実現不可能なレベルのスループットとスケーラビリティを実現できます。また、お使いのアプリケーションやデータ ストアをスケールアウトまたはスケールアップする際にも、キャッシュは柔軟に対応できます。これにより、バックエンドのデータベースの負荷を高めることなく、お客様のアプリケーションをお使いの多くのユーザーが同じファイルに同時にアクセスできるようになります。また、使用量が急増したり、スループットが高くなったりすることが多いアプリケーションでは、インメモリ キャッシュを使用することで待機時間を短縮することができます。

キャッシュの用途

出力キャッシュ

出力キャッシュを使用して、サーバーがレンダリングのためにブラウザーに送信する HTML やクライアント スクリプトなど、ページの完全なソース コードを保存することで、Web ページのパフォーマンスを向上させることができます。ユーザーがページを閲覧するたびに、サーバーにより出力コードがアプリケーションのメモリにキャッシュされます。これにより、アプリケーションでページ コードを実行したり、他のサーバーと通信したりすることなく、リクエストを処理できるようになります。

データ キャッシュとデータベース キャッシュ

データベースの速度とスループットは、アプリケーション全体のパフォーマンスを左右する重要な要素となります。データベース キャッシュは、価格や在庫データなど、あまり変更されないデータを頻繁に呼び出す場合に使用されます。これにより、Web サイトやアプリケーションの読み込みが速くなると同時に、スループットが向上し、バックエンド データベースからのデータ取得の待機時間が短縮されます。

ユーザー セッション データの保存

アプリケーションのユーザーは、短期間保存する必要のあるデータを生成することがよくあります。Redis のようなインメモリ データ ストアは、ユーザーの入力、ショッピング カートへの追加、パーソナライゼーションの設定などの大量のセッション データを、ストレージやデータベースよりも低コストで、そして効率的かつ確実に保存するのに最適です。

メッセージ ブローカーとパブリッシュ/サブスクライブ アーキテクチャ

クラウド アプリケーションでは多くの場合、サービス間でデータを交換する必要があり、キャッシュを利用してパブリッシュ/サブスクライブやメッセージ ブローカー アーキテクチャを実装することで、待機時間を減らし、データ管理を高速化することができます。

アプリケーションと API

ブラウザーと同様に、アプリケーションにより重要なファイルやデータが保存され、必要なときにすばやく情報が再度読み込まれます。キャッシュされた API 応答により、アプリケーション サーバーやデータベースへの要求や負荷が軽減され、応答時間の短縮やパフォーマンスの向上を実現できます。

[1] パフォーマンスの記述は、2020 年 10 月に Microsoft が依頼して GigaOm が実施した調査のデータに基づきます。この調査では、Azure データベースを使用するテスト アプリケーションのパフォーマンスを、キャッシュ ソリューションとして Azure Cache for Redis を実装した場合としない場合で比較しました。この調査では、Azure SQL Database と Azure Database for PostgreSQL をデータベース要素として使用しました。Azure SQL Database の 2 つの vCore Gen 5 General Purpose インスタンスと、Azure Database for PostgreSQL の 2 つの vCore General Purpose インスタンスを、Azure for Redis の 6 ギガバイト P1 Premium で使用しました。これらの結果を、Azure SQL Database の 8、16、24、32 vCore Gen 5 General Purpose インスタンスと、Azure Cache for Redis を使用しない Azure Database for PostgreSQL の 8、16、24、32 vCore General Purpose インスタンスと比較しました。ベンチマーク データは、「GigaOm Web Application Database Load Test」から取得しています。このテストでは、HTTP 要求が集中的に増加する一般的な Web アプリケーションとバックエンド データベースをシミュレートしています。実際の結果は、構成とリージョンにより異なる場合があります。 調査の詳細をご覧ください

無料アカウント

Azure クラウド コンピューティング サービスを 最大 30 日間無料でお試しください。

従量課金制

従量課金制の価格で利用を始めましょう。事前コミットメントはなく、いつでもキャンセルできます。

フル マネージドの Redis サービスを使用して、軽快に動作するキャッシュ レイヤーをお客様のアプリケーションに追加しましょう。Azure Cache for Redis の使用を開始する方法を詳しくご覧ください。

ハイパフォーマンスなアプリケーションで柔軟なファイルベースのキャッシュを実行したい場合は、Azure HPC Cache についてお読みください。