ナビゲーションをスキップする

キャッシュとは

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

キャッシュを使用することで、データベースのコストを削減し、ほとんどのデータベースに備わったものより高いスループットと低い待機時間を実現し、クラウドおよび Web アプリケーションのパフォーマンスを向上させることができます。

データベースのキャッシュはどのように機能しますか?

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

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

キャッシュ レイヤーのメリットと、Redis とは何ですか?

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

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

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

キャッシュの種類

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

キャッシュ アサイド

読み込み重視のアプリケーションの場合、開発者は多くの場合にキャッシュ アサイドのプログラミング パターン、あるいは「サイド キャッシュ」を使用します。サイド キャッシュはアプリケーションの外部に設置され、アプリケーションはキャッシュに接続してデータのクエリおよび取得を行い、データがキャッシュにない場合はデータベースに直接接続できます。アプリケーションがデータを取得すると、将来のクエリに備えてデータをキャッシュにコピーします。

サイド キャッシュは、アプリケーションのパフォーマンスを向上させ、キャッシュとデータストアの間の一貫性を維持し、キャッシュ内のデータを最新の状態に維持するために使用できます。

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

リード スルー キャッシュは最新の状態を維持しますが、ライト スルー キャッシュでは、アプリケーションはデータをキャッシュに書き込み、その後データベースに書き込みます。両方のキャッシュがデータベースと一緒に配置され、アプリケーションによってメイン データ ストアとして処理されます。

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

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

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

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

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

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

セッション ストアとは何ですか?

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

セッション ストアの使用は、データベースのキャッシュとどのような違いがありますか?

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

通常、セッション ストアに書き込まれるデータは短期間ですが、プライマリ データベースを使用してキャッシュされたデータは通常、より長期間になることが意図されています。セッション ストアでは、トランザクション データが失われることなくユーザーが引き続き関与できるように、レプリケーション、高可用性、データ持続性が必要です。一方、サイド キャッシュ内のデータが失われた場合は、永続的なデータベースに常にそのデータのコピーが存在します。

キャッシュのメリット

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

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

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

キャッシュを使用すると、データベース インフラストラクチャのスケーリングの必要性を制限してスループットの料金を削減することで、データベース クエリの数が減り、パフォーマンスが向上し、コストが削減されます。

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

1 つのキャッシュ インスタンスは、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 Gen5 General Purpose インスタンスと Azure Database for PostgreSQL の 2 vCore General Purpose インスタンスを、Azure for Redis の 6 GB の P1 Premium インスタンスとともに使用しました。これらの結果は、Azure Cache for Redis を使用しない、Azure SQL Database の 8、16、24、32 vCore Gen5 General Purpose インスタンス、および Azure Database for PostgreSQL の 8、16、24、32 vCore General Purpose インスタンスと比較されました。ベンチマーク データは、GigaOm Web Application Database Load Test から取得します。このテストでは、増加する HTTP 要求にさらされている一般的な Web アプリケーションとバックエンド データベースのシミュレーションを行います。実際の結果は、構成や地域によって異なる場合があります。調査のすべてを見る

完全に管理された Redis サービスを使用して、アプリケーションに軽快なキャッシュ レイヤーを追加します。Azure Cache for Redis の使用を開始する方法をご紹介します。

高パフォーマンスなアプリケーションに柔軟なファイル ベースのキャッシュを実行する場合は、Azure HPC Cache をご覧ください。

どのようなご用件ですか?