キャッシュとmemcached

この投稿では、 HighLoad ++-2008 に関するレポートに基づいて、一連の小さな投稿を開きたいと思います。 その後、テキスト全体が1つの大きなPDFとして公開されます。

はじめに

まず、一連の投稿のタイトル：投稿は、Webでのキャッシュ（高負荷のWebプロジェクト）、キャッシュのためのmemcachedの使用、およびWebプロジェクトでのmemcachedのその他の使用についてです。 つまり、さまざまな組み合わせの3つの構成要素名すべてが、この一連の投稿でカバーされます。



今日のキャッシュは、Webプロジェクトの不可欠な部分であり、必ずしも負荷が大きいわけではありません。 各リソースについて、ユーザーにとって重要な機能はサーバーの応答時間です。 サーバーの応答時間を長くすると、訪問者が流出します。 したがって、応答時間を最小限に抑える必要があります。そのためには、ユーザーへの応答を作成するのに必要な時間を短縮する必要があり、ユーザーへの応答には外部リソース（バックエンド）からデータを受信する必要があります。 これらのリソースは、データベースと他の比較的低速のデータソース（たとえば、空き領域の量を指定するリモートファイルサーバー）の両方にすることができます。 かなり複雑なリソースの1ページを生成するには、このような呼び出しを何十回も行う必要があります。 それらの多くは高速です：20ミリ秒以下、ただし、常に少数の要求があり、その計算時間は数秒または数分で計算できます（最適化されたシステムでも、数は最小限である必要がありますが）。 クエリの結果を待つために費やしている時間をすべて合計すると（クエリを並行して実行する場合、最も長いクエリの計算時間がかかります）、応答時間が不十分になります。



この問題の解決策はキャッシングです。計算結果を、優れた情報アクセス時間特性を備えたストレージ（memcachedなど）に格納します。 これで、低速で複雑で重いバックエンドにアクセスする代わりに、高速キャッシュのリクエストを完了するだけで十分です。

Memcachedとキャッシュ

局所性の原理

電子デバイス、ソフトウェアアーキテクチャ：CPUキャッシュ（第1レベルおよび第2レベル）、ハードディスクバッファー、オペレーティングシステムキャッシュ、カーラジオのバッファーのどこにでもキャッシュまたはキャッシュアプ​​ローチがあります。 そのようなキャッシュの成功を決定するものは何ですか？ 答えは局所性の原則にあります。プログラム、デバイスの場合、一定の期間、共通セットのデータの特定のサブセットを処理するのが一般的です。 RAMの場合、これは、プログラムがアドレス100にあるデータを処理する場合、次の呼び出しがアドレス10000ではなく、アドレス101、102などにある可能性が高いことを意味します。 ハードディスクでも同じことが言えます：比較的小さなファイルセットではなく、ハードディスクのすべてのコンテンツでプログラムが一時点で動作していた場合、バッファは最後の読み取りセクタに隣接する領域からのデータで満たされますが、バッファは無意味です。 カーラジオバッファーは、ディスクから音楽の次の数分を先取りします。これは、音楽セットなどをスキップするよりも音楽ファイルを順番に聴く可能性が高いためです。



Webプロジェクトの場合、キャッシングの成功は、サイトに常に最も人気のあるページがあること、一部のデータがすべてまたはほぼすべてのページで使用されていること、つまり、他のサンプルよりも頻繁に要求されるサンプルがあることによって決まります。 キャッシュを構築するために、バックエンドへの複数の呼び出しを1つの呼び出しに置き換えます。その後、すべての後続の呼び出しは高速実行キャッシュを通じて行われます。



キャッシュは常に元のデータソースよりも優れています。CPUキャッシュはRAMよりも桁違いに高速ですが、RAMをキャッシュほど速くすることはできません。経済的に非効率的で技術的に困難です。 ハードディスクバッファは、ハードディスク自体よりもはるかに高速にデータの要求を満たしますが、バッファには電源が​​オフになったときにデータを保存する機能がありません。この意味では、デバイス自体よりも劣っています。 同様の状況は、Webでのキャッシュの場合です。キャッシュはバックエンドよりも高速で効率的ですが、通常、サーバーの再起動またはクラッシュが発生した場合にデータを保存できず、結果を計算するロジックもありません。以前に入れたもの。

Memcached

Memcachedは、ネットワークプロトコル経由でアクセス可能なRAM内の巨大なハッシュテーブルです。 キーに関連付けられた値を保存するサービスを提供します。 単純なネットワークプロトコルを介してハッシュにアクセスします;クライアントは、任意のプログラミング言語で記述されたプログラムにすることができます（C / C ++、PHP、Perl、Javaなどのクライアントがあります）。



最も簡単な操作は、指定されたキーの値を取得（get）、キーの値を設定（set）、およびキーを削除（del）することです。 アトミック操作のチェーンを実装するには（並列プロセスからmemcachedへの同時アクセスの対象）、追加の操作が使用されます：キー値のインクリメント/デクリメント（incr / decr）、キー値へのデータの先頭または末尾への追加（append / prepend）、アトミックバンドル値の取得/設定（gets / cas）など。



Memcachedは、LiveJournalプロジェクトの一部としてBrad Fitzpatrickによって実装されました。 ページコンテンツを返すときに、クエリからデータベースをオフロードするために使用されました。 今日、memcachedは、ウィキペディア、YouTube、Facebookなどの多くの大規模プロジェクトのコアでそのアプリケーションを使用しています。

一般的なキャッシュスキーム

一般に、キャッシュスキームは次のとおりです。フロントエンド（ユーザーへの応答を形成するプロジェクトの一部）は、何らかのデータを取得する必要があります。 フロントエンドは、フェッチキャッシュ（取得要求）のためにチーターmemcachedサーバーとして高速にアクセスします。 対応するキーが見つかった場合、作業はそこで終了します。 それ以外の場合は、重い、遅いが強力な（象のような）バックエンドにアピールする必要があります。これは、データベースによって最も頻繁に再生されます。 結果はすぐにmemcachedにキャッシュ（セットリクエスト）として書き込まれます。 この場合、キーは通常、キャッシュのリセットの瞬間に対応する最大有効期間（有効期限）に設定されます。



この標準キャッシングスキームは常に実装されます。 memcachedの代わりに、一部のプロジェクトはローカルファイル、他のストレージメソッド（別のデータベース、PHPアクセラレータキャッシュなど）を使用する場合があります。ただし、後で示すように、負荷の高いプロジェクトではこのスキームは最も効率的な方法で動作しない場合があります。 それにもかかわらず、今後の話では、このスキームに正確に依存します。

Memcachedアーキテクチャ

memcachedはどのように配置されていますか？ サイトの1ページを処理する数十件のmemcachedリクエストでさえ、大幅な遅延につながらないほど高速に動作する方法 同時に、memcachedはコンピューティングリソースに対して非常に要求が厳しくありません。ロードされたインストールでは、memcachedによって使用されるプロセッサ時間が10％を超えることはめったにありません。



まず、memcachedは、すべての操作がアルゴリズムの複雑さO（1）を持つように設計されています。 操作の実行時間は、memcachedが保存するキーの数に依存しません。 これは、実装に線形（O（n））時間のみが必要な場合、一部の操作（または機能）が存在しないことを意味します。 したがって、memcachedにはキーを「フォルダに」結合する機能がありません。つまり、 キーのグループ化、キーまたはその値に対するグループ操作も見つかりません。



主な最適化された操作は、キーを格納するためのメモリブロックの割り当て/割り当て解除であり、メモリが不足しているときにキャッシュをクリアするための最も未使用のキー（LRU）のポリシーを決定します。 キーの検索はハッシュを介して行われるため、複雑さはO（1）です。



非同期入出力が使用され、スレッドは使用されないため、パフォーマンスが向上し、リソース要件が低くなります。 実際、memcachedはスレッドを使用できますが、これは、負荷が大きすぎる場合にサーバーで使用可能なすべてのコアまたはプロセッサを使用する場合にのみ必要です。いずれの場合も、接続ごとにスレッドは作成されません。



実際、memcachedサーバーの応答時間はネットワークコストによってのみ決定され、フロントエンドからmemcachedサーバー（RTT）にパケットを送信するのにかかった時間とほぼ等しいと言えます。 このような特徴により、memcachedを負荷の高いWebプロジェクトで使用して、データキャッシングなどのさまざまな問題を解決できます。

キー紛失

Memcachedは信頼できるストレージではありません-有効期限が切れる前にキーがキャッシュから削除される可能性があります。 このような状況に備えて、プロジェクトのアーキテクチャを準備し、キーの紛失に柔軟に対応する必要があります。 キーが失われる主な理由は3つあります。

1. 他のキーの値を保存するためのメモリが不足しているため、キーはその有効期限より前に削除されました。 MemcachedはLRUポリシーを使用するため、この損失はこのキーがほとんど使用されず、キャッシュメモリが解放されてより一般的なキーを保存できることを意味します。
2. キーは、その有効期限が切れたため削除されました。 厳密に言えば、キーの有効期間を制限しているため、この状況は損失ではありませんが、memcachedコードに関するクライアントの場合、そのような損失は他のケースと区別できません-memcachedにアクセスすると、「そのようなキーはありません」という答えが返されます。
3. 最も不快な状況は、memcachedプロセスまたはそれが配置されているサーバーの崩壊です。 この状況では、キャッシュに保存されたすべてのキーが失われます。 クラスター構成では、プロジェクトキーが「拡散」する多くのmemcachedサーバーの影響を少し緩和できます。そのため、1つのキャッシュの障害の影響は目立たなくなります。

memcachedで動作するソフトウェアを開発するときは、説明されているすべての状況に留意する必要があります。 memcachedに格納されているデータは、損失の重大度に応じて分離できます。



「失う可能性があります。 」 このカテゴリには、データベースフェッチのキャッシュが含まれます。 このようなキーを紛失してもそれほど心配することはありません。バックエンドに再度アクセスすることで簡単に値を復元できるからです。 ただし、頻繁にキャッシュが失われると、データベースへの過剰な呼び出しが発生します。



「負けたくない」 ここでは、サイト訪問者、リソースビューなどのカウンターに言及できます。 これらの値を直接復元することは直接不可能な場合もありますが、これらのキーの値には時間制限の意味があります。数分後、それらの値は関係がなくなり、新しい値が計算されます。



「彼らはまったく失うべきではありません 。 」 Memcachedはユーザーセッションを保存するのに便利です。フロントエンドクラスター内のすべてのサーバーからすべてのセッションに等しくアクセスできます。 そのため、セッションの内容を失うことは絶対にありません。そうしないと、サイトのユーザーは「ログアウト」されます。 回避する方法 クラスターから複数のmemcachedサーバーでセッションキーを複製できるため、損失の可能性が低くなります。