Webアプリケーションのキャッシュとパフォーマンス

キャッシュを使用すると、ネットワーク要求への応答や計算結果など、以前に保存されたデータを使用して、Webアプリケーションのパフォーマンスを向上させることができます。 キャッシュのおかげで、クライアントが次回同じデータにアクセスするときに、サーバーはリクエストをより速く処理できます。 ほとんどのプログラムは同じデータと命令に頻繁にアクセスするため、キャッシングは効果的なアーキテクチャパターンです。 このテクノロジーは、あらゆるレベルのコンピューティングシステムに存在します。 プロセッサ、ハードドライブ、サーバー、ブラウザにはキャッシュがあります。







今日翻訳を公開している資料の著者であるNick Karnikは、Webアプリケーションのパフォーマンスにおけるキャッシングの役割について、最低から始めてさまざまなレベルでキャッシングの方法を検討することを提案しています。 彼は、データがどのようにキャッシュされるかではなく、どのようにキャッシュされるかに特別な注意を払っています。



それぞれが外部の影響に対するアプリケーションの応答速度に一定の貢献をするキャッシングシステムの機能を理解することは、Web開発者の視野を広げ、高速で信頼性の高いシステムを作成するのに役立つと考えています。

プロセッサーキャッシュ

キャッシュについての話を、最低レベル-プロセッサから始めましょう。 プロセッサキャッシュは、プロセッサ（CPU）とランダムアクセスメモリ（RAM）間のバッファとして機能する非常に高速なメモリです。 キャッシュには、最も頻繁にアクセスされるデータと命令が保存されるため、プロセッサはほとんどすべてのデータと命令にすぐにアクセスできます。



プロセッサには、通常は情報の小さなストレージであるプロセッサレジスタで表される特別なメモリがあり、非常に高速なデータ交換を提供します。 レジスタは、プロセッサが動作できる最速のメモリであり、他のメカニズムに可能な限り近い場所にあり、少量です。 レジスタはゼロレベルキャッシュと呼ばれることもあります（L0キャッシュ、Lはレイヤーの略です）。



また、プロセッサは、さらにいくつかのレベルのキャッシュメモリにアクセスできます。 これは最大4つのキャッシュレベルであり、それぞれ第1、第2、第3、および第4レベルのキャッシュ（L0-L4キャッシュ）と呼ばれます。 プロセッサレジスタが属するレベル、特に、ゼロまたは最初のレベルのキャッシュになるかどうかは、プロセッサとマザーボードのアーキテクチャによって決まります。 さらに、異なるレベルのキャッシュアーキテクチャは、システムのアーキテクチャに応じて、プロセッサまたはマザーボードに物理的に配置されます。









一部の新しいCPUのメモリ構造

ハードドライブキャッシュ

永続的なデータストレージに使用されるハードディスク（HDD、ハードディスクドライブ）-これは、情報の短期保存用に設計されたRAMと比較して、デバイスの速度が非常に遅いです。 ただし、ソリッドステートドライブ（SSD、ソリッドステートドライブ）の急増により、情報の永続的な保存速度が向上することに注意してください。



長期的な情報ストレージシステムでは、ディスクキャッシュ（ディスクバッファーまたはキャッシュバッファーとも呼ばれます）は、プロセッサと物理ハードディスク間のバッファーとして機能する、ハードディスクに組み込まれたメモリです。









ハードドライブキャッシュ



ディスクキャッシュは、ディスクに何かを書き込んだり、ディスクから何かを読み取ったりするときに、近い将来このデータに再びアクセスする可能性があるという前提で動作します。

ハードドライブとRAMのパフォーマンスについて

RAMにデータを一時的に保存する場合と、ハードディスクに永続的に保存する場合の違いは、情報の処理速度、メディアのコスト、およびプロセッサの近くに表れます。



RAMの応答時間は数十ナノ秒ですが、ハードドライブには数十ミリ秒が必要です。 ディスクとメモリの速度の違いは6桁です！









1ミリ秒は100万ナノ秒に相当します

シンプルなウェブサーバー

コンピューターシステムの基本的なメカニズムでのキャッシュの役割について説明したので、Webブラウザーで表されるクライアントと、クライアントの要求に応じてデータを送信するサーバーとの対話でのキャッシュの概念の使用を示す例を考えてみましょう。 最初の段階では、クライアントの要求に応答してハードドライブからデータを読み取る単純なWebサーバーがあります。 同時に、クライアントとサーバーの間に特別なキャッシングシステムがないことを想像してください。 外観は次のとおりです。









シンプルなウェブサーバー



上記のシステムが動作している場合、クライアントがサーバーに直接アクセスすると、クライアントは独自にリクエストを処理し、ハードディスクからデータを読み取り、クライアントに送信しますが、ディスクを操作するときにバッファが使用されるため、キャッシュなしでは実行できません。



最初の要求で、ハードドライブはキャッシュをチェックします。この場合、キャッシュは存在せず、いわゆる「キャッシュミス」につながります。 次に、データはディスク自体から読み取られてキャッシュに格納されます。これは、このデータが再び必要になる可能性があるという前提に対応しています。



同じデータを取得することを目的とした後続のリクエストでは、キャッシュ検索が成功します。これは、いわゆる「ヒットキャッシュ」です。 要求に応答するデータは、上書きされるまでディスクバッファーから送られます。上書きされると、同じデータに再度アクセスすると、キャッシュミスが発生します。

データベースキャッシング

サンプルを複雑にして、ここにデータベースを追加しましょう。 データベースサーバーは応答を形成するためにいくつかの計算を実行する必要があるため、データベースクエリは遅く、深刻なシステムリソースを必要とする場合があります。 要求が繰り返される場合、データベースツールで要求をキャッシュすると、応答時間が短縮されます。 さらに、キャッシュは、複数のコンピューターがデータベースを操作し、同じクエリを実行する状況で役立ちます。









データベースを備えたシンプルなWebサーバー



ほとんどのデータベースサーバーは、最適なキャッシュ設定のためにデフォルトで構成されています。 ただし、データベースサブシステムが特定のアプリケーションの機能によりよく一致するように変更できる設定は多数あります。

Webサーバーの応答キャッシュ

例を開発し続けます。 これで、以前は単一のエンティティと見なされていたWebサーバーが2つの部分に分割されました。 その1つであるWebサーバー自体は、現在、クライアントと、ストレージシステムで既に動作しているサーバーアプリケーションとの対話に従事しています。 Webサーバーは、応答をキャッシュするように構成できます。その結果、サーバーアプリケーションに同様の要求を絶えず送信する必要がなくなります。 同様に、メインアプリケーションは、リソースを集中的に使用するデータベースクエリまたは頻繁に発生するファイルクエリに対する応答の一部をキャッシュできます。









応答キャッシュとアプリケーションキャッシュ



Webサーバーの応答はRAMにキャッシュされます。 アプリケーションキャッシュは、ローカル、メモリ、またはデータをRAMに保存するRedisなどのデータベースを使用する特別なキャッシュサーバーに保存できます。

関数のメモ化

次に、メモ化によるサーバーアプリケーションのパフォーマンスの最適化について説明します。 これは、リソースを集中的に使用する機能で作業を最適化するために使用されるキャッシュの一種です。 この手法を使用すると、特定の入力データのセットに対して計算のフルサイクルを1回だけ実行し、同じ入力データで関数を次に呼び出すと、以前に見つかった結果をすぐに返すことができます。 メモ化は、キーと値を格納するいわゆる「ルックアップテーブル」を介して実装されます。 キーは関数の入力データに対応し、値はこの入力が渡されたときに関数が返す結果に対応します。









ルックアップテーブルを使用して関数をメモする



メモ化は、プログラムのパフォーマンスを向上させるために使用される一般的な手法です。 ただし、めったに呼び出されないリソース集約型の関数や、メモ化がなくても非常に高速に動作する関数を使用する場合は、特に有用ではない場合があります。

ブラウザのキャッシュ

次に、クライアント側に進み、ブラウザでのキャッシュについて説明します。 各ブラウザにはHTTPキャッシュ（Webキャッシュとも呼ばれます）の実装があり、HTMLページ、JavaScriptファイル、画像など、インターネットから受信した素材を一時的に保存するように設計されています。



このキャッシュは、サーバー応答に正しく構成されたHTTPヘッダーが含まれている場合に使用されます。HTTPヘッダーは、ブラウザーにサーバー応答をいつどの程度キャッシュできるかを伝えます。



データ交換のすべての参加者に以下の利点を提供する非常に有用な技術があります。

• ローカルキャッシュからのリソースが非常に迅速にロードされるため、サイトでの作業のユーザーエクスペリエンスが向上します。 応答を受信する時点では、要求がネットワークに送信されないため、クライアントからサーバーへの信号通過時間（RTT、往復時間）は含まれません。
• サーバーアプリケーションや、要求の処理を担当する他のサーバーコンポーネントの負荷が軽減されます。
• 他のインターネットユーザーが現在使用できるネットワークリソースの特定の部分が解放され、トラフィックの支払いにかかる費用が節約されます。

ブラウザのキャッシュ

キャッシュとプロキシ

コンピュータネットワークでは、プロキシは特別なハードウェアまたは関連するアプリケーションで表すことができます。 これらは、クライアントと、これらのクライアントが必要とするデータを保存するサーバーとの間の仲介者として機能します。 キャッシングは、彼らが解決するタスクの1つです。 さまざまなタイプのプロキシを検討してください。

▍ゲートウェイ

ゲートウェイは、受信要求または送信応答を変更せずにリダイレクトするプロキシサーバーです。 このようなプロキシは、トンネリングプロキシ、Webプロキシ、プロキシ、またはアプリケーションレベルのプロキシとも呼ばれます。 これらのプロキシは通常、たとえば、同じファイアウォールの背後にあるすべてのクライアントによって共有されるため、リクエストのキャッシュに適しています。

▍直接プロキシ

通常、直接プロキシサーバー（多くの場合、単にプロキシサーバーと呼ばれるフォワードプロキシ）は、クライアント側にインストールされます。 ダイレクトプロキシサーバーを使用するように構成されたWebブラウザーは、このサーバーに発信要求を送信します。 その後、これらの要求はインターネット上にあるターゲットサーバーにリダイレクトされます。 ダイレクトプロキシの利点の1つは、クライアントデータを保護することです（ただし、インターネット上で匿名性を確保することについて話す場合、VPNを使用する方が安全です）。

▍Webアクセラレーター

Webアクセラレータ（Webアクセラレータ）-サイトへのアクセス時間を短縮するプロキシサーバー。 彼は、近い将来にクライアントが必要とする可能性があるサーバー文書から事前に要求することでこれを行います。 さらに、このようなサーバーは、ドキュメントの圧縮、暗号化操作の高速化、画像の品質とサイズの削減などを行うことができます。

▍逆プロキシ

リバースプロキシは通常、対話するWebサーバーと同じ場所にあるサーバーです。 リバースプロキシは、プライベートネットワーク上にあるサーバーへの直接アクセスを防ぐように設計されています。 リバースプロキシは、複数の内部サーバー間で負荷を分散し、SSL認証または要求キャッシュ機能を提供するために使用されます。 このようなプロキシはサーバー側のキャッシングを実行し、メインサーバーが多数のリクエストを処理するのに役立ちます。

▍エッジキャッシング

リバースプロキシはサーバーの近くにあります。 また、キャッシュサーバーをデータコンシューマのできるだけ近くに配置する技術もあります。 これは、コンテンツ配信ネットワーク（CDN）に代表される、いわゆるエッジキャッシングです。 たとえば、人気のあるWebサイトにアクセスして何らかの静的データをダウンロードすると、キャッシュされます。 同じデータを要求する次の各ユーザーは、キャッシングの期限が切れる前に、キャッシングサーバーからそのデータを受け取ります。 これらのサーバーは、情報の関連性を判断し、ソースデータを保存するサーバーに焦点を合わせます。









クライアントとサーバー間のデータ交換のインフラストラクチャ内のプロキシ

まとめ

この記事では、クライアントとサーバー間で情報を交換するプロセスで使用されるデータキャッシュのさまざまなレベルを調べました。 Webアプリケーションは、特にこれらのアプリケーションのサーバーとのデータ交換が必要なアクションに関連付けられているユーザーの対話に即座に応答できません。応答を送信する前に特定の計算を実行する必要があります。 サーバーからクライアントにデータを転送するのに必要な時間には、ディスク上の必要なデータを検索するのに必要な時間、ネットワークの遅延、要求キューの処理、ネットワーク帯域幅を調整するメカニズムなどが含まれます。 これがすべてクライアントとサーバーの間にある多くのコンピューターで発生する可能性があることを考慮すると、これらのすべての遅延により、サーバーに到着するリクエストに必要な時間が大幅に増加し、クライアントが応答を受け取ると言えます。



適切に構成されたキャッシングシステムは、サーバー全体のパフォーマンスを大幅に改善できます。 キャッシュは、ネットワーク経由でデータを転送するときに必然的に発生する遅延を減らし、ネットワークトラフィックを節約し、その結果、ブラウザーがサーバーから要求されたWebページを表示するのに必要な時間を短縮します。



親愛なる読者！ プロジェクトでどのキャッシングテクノロジーを使用していますか？