分散データキャッシュ技術、その謎を解明

この講義では、分散ストレージにおける「棚」のキーテクノロジーであるキャッシュテクノロジーについて説明します。

[[324176]]

コンピュータ分野のあらゆる面において、キャッシュは非常に重要であり、アクセスパフォーマンスを向上させる重要な技術です。なぜそんなことを言うのですか？

単一のコンピューターのアーキテクチャの観点から見ると、メモリとプロセッサーの速度は大きく異なります。キャッシュ技術を使用しない場合、プロセッサのパフォーマンスは大幅に制限されます。

コンピュータアプリケーションを見てみましょう。キャッシュ テクノロジを使用しない場合、アプリケーションはリクエストごとにバックエンド データベースと対話する必要があり、データベース内のデータはディスクに保存されます。そのため、各リクエストはディスクと対話する必要があり、ディスク アクセスのパフォーマンスが非常に低くなり、アクセス遅延が発生します。

さらに、ネットワークアクセスもあります。キャッシュ メカニズムがない場合、ホストへのアクセスごとにリモート マシンと対話する必要があり、速度は想像に難くありません。

次に、分散キャッシュ技術について一緒に確認してみましょう。

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

例え話で言えば、キャッシュ技術は実際には水タンクのようなもので、通常は一定量の水を蓄えており、この水は深い井戸から汲み上げられます。毎回深い井戸に水を汲みに行くと、一方では井戸の口が比較的小さいため、一度に受けられる水の要求量が限られてしまいます。一方、井戸は比較的深く、水を汲む作業も比較的複雑で、結果的に時間がかかります。

この水タンクがあれば、深い井戸から水を汲む必要はありません。貯水タンクに水がなくなった場合、水ポンプが深井戸から水を汲み上げ、貯水タンクに一時的に貯水します。つまり、「キャッシュ技術」とは、人々が普段使用している「水の量」を一定期間内に蓄え、水の利用効率を高める技術です。

コンピュータの分野では、キャッシュ テクノロジーとは一般に、ユーザーがすばやくアクセスできるように、頻繁に使用するデータをより高速なストレージ デバイスに保存することを指します。ユーザーは毎回低速デバイスを操作する必要がないため、アクセス効率が向上します。

分散キャッシュとは、分散環境またはシステム内でユーザーやアプリケーションの近くに人気のあるデータを保存し、できるだけ高速なデバイスに保存してリモート データ転送の遅延を減らし、ユーザーやアプリケーションが目的のデータにすばやくアクセスできるようにすることです。これは比喩的に言えば、「身体、手、鍵、お金」を持ち歩くということでしょうか?

実際、私たちが通常分散データ キャッシュと呼んでいるものは、コンピューター アプリケーションにおけるキャッシュの一種です。コンピュータ アプリケーションにおけるキャッシュは、一般的にメモリを指します。つまり、メモリにはユーザーが頻繁にアクセスするデータが保存されます。ユーザーやアプリケーションは、対応するデータを取得するためにディスクにアクセスする必要がなくなり、アクセス速度が大幅に向上します。

下の図に示すように、データ A はアプリケーションによって頻繁にアクセスされますが、データ B はアプリケーションによってほとんどアクセスされません。したがって、アプリケーションがデータ A にアクセスする場合、ディスクにアクセスする必要はなく、メモリに直接アクセスして対応する値を取得できるため、より高速になります。逆に、データ B にアクセスする場合、データ B はメモリにキャッシュされていないため、アプリケーションはディスクにアクセスして対応する値を取得する必要があり、速度が遅くなります。

そこで今日は、メモリをディスク キャッシュとして使用する、分散データ ストレージに関連するキャッシュ テクノロジについてお話ししたいと思います。

分散キャッシュの原則

Redis 分散キャッシュの原理 Redis の正式名称は、Remote Dictionary Server です。辞書構造でメモリ上にデータを格納し、アプリケーションがRedisに格納されたデータをメモリに直接読み書きできることが直感的にわかります。

Redis クラスターは典型的な分散型構造です。各ノードはデータの一部を保存する役割を担います。同時に、各ノードはマスタースレーブ設計を実行し、Redis の信頼性を向上させます。具体的な原則については、前の記事の関連コンテンツを確認してください。

次に、キャッシュに最も密接に関連する Redis の 3 つの機能、つまり複数のデータ構造のサポート、永続性のサポート、マスターとスレーブの同期について説明します。

まず、Redis は複数のデータ構造をサポートしています。

Redis はメモリベースのキー値データベースです。テキスト型、データベースクエリ結果（フィールドとフィールドの対応する値）などのキャッシュなど、複数のアプリケーションのキャッシュを容易にするために、サポートされるデータ構造には、単純な k/v 型だけでなく、リスト、セット、ハッシュなどの複雑な型も含まれます。

Hash などの複合型の格納を例にとると、Redis は Hash 全体を扱い、データベースの値 (構造体オブジェクトなどのオブジェクトの場合もあります) として格納します。ハッシュ構造全体をオブジェクトと見なすと、ハッシュ構造内のキー値はオブジェクトの属性名と属性値に相当します。

たとえば、ハッシュ データ型を挿入するコマンド: HMSET test field1 "Hello" field2 "World" では、下の図に示すように、test がキー値、field1 "Hello" field2 "World" が値です。ハッシュ構造全体をオブジェクトとみなすと、field1 と field2 はオブジェクト内の属性名に相当し、「Hello」と「World」はオブジェクト内の属性値に相当します。

2 番目に、Redis は永続性をサポートします。

永続性とは、メモリなどの揮発性ストレージデバイスからディスクにデータを書き込んで、データを永続的に保存することを意味します。 Redis に保存されるデータはメモリベースですが、主に RDB と AOF の 2 つの方法で永続化メカニズムも提供されます。

RDB (Redis DataBase) はスナップショット モードとも呼ばれ、Redis がメモリ内のデータを定期的にディスクにバックアップしてスナップショットを作成し、たとえば過去 1 週間のデータを毎日保存することを意味します。この方法では、ノードに障害が発生した場合、スナップショットに基づいてデータの別のバージョンを復元できます。この方法には明らかな欠点があり、それはデータが失われる可能性があることです。つまり、ノードに障害が発生すると、新しいデータがディスクにバックアップされていない可能性があります。

AOF (Append Only File) の出現により、主に RDB データの不整合の問題が補われます。その考え方は、前回の講義で触れたデータベースレプリケーション技術におけるバイナリログに似ており、Redis での更新操作をすべて記録するものです。

• Redis では、AOF を実装するための 3 つの戦略が提供されています。AOF_FSYNC_NO (同期なし) は、書き込み操作の同期が自動的にトリガーされないことを意味します。
• AOF_FSYNC_EVERYSEC (1 秒ごとに同期)、つまり書き込み操作は 1 秒ごとにディスクに同期されます。
• AOF_FSYNC_ALWAYS (すべての書き込みを同期)、つまり、すべての書き込み操作がディスクに直ちに同期されます。

Redis で使用されるデフォルトの戦略は AOF_FSYNC_EVERYSEC (1 秒あたりの同期) です。この戦略はパフォーマンスが良好で、障害が発生しても最大で 1 秒分のデータしか失われないためです。

3 番目に、Redis はマスターとスレーブの同期をサポートしています。

マスタースレーブ同期といえば、前回の講義で触れたデータ複製技術を思い浮かべていただければと思います。 Redis では非同期レプリケーション テクノロジが使用されますが、Redis は min-replicas-to-write と min-replicas-max-lag の 2 つのパラメータを構成することで、データの一貫性を効果的に保証できます。

たとえば、min-replicas-to-write=3 および min-replicas-max-lag=10 に設定すると、プライマリ データベースに接続する少なくとも 3 つのスタンバイ データベース間の遅延時間が 10 秒未満の場合にのみ、プライマリ データベースが書き込み操作を実行できることになります。遅延は、スタンバイ データベースから受信した最後のハートビート (通常は 1 秒に 1 回送信される) から計算されます。

上記の書き込み操作の同期に加えて、Redis ではデータの同期が必要な状況が他に 2 つあります。

• 1 つの状況は初期同期、つまりスタンバイ データベースが起動されたばかりのときのデータ同期です。
• もう 1 つの状況は、ネットワーク障害によりプライマリ データベースとスタンバイ データベースが切断され、ネットワークが復旧した後にスタンバイ データベースのデータが同期されるというものです。

これら 2 つの状況に対して、Redis は完全再同期と部分再同期という 2 つの同期モードを提供します。

完全な再同期のプロセスは次のとおりです。

スタンバイ サーバーが起動すると、プライマリ サーバーに SYNC コマンドが送信されます。

コマンドを受信すると、マスター サーバーは RDB (スナップショット) ファイルを生成し、今後実行される新しい書き込み操作を記録します。

RDB が生成されると、スタンバイ サーバーに送信され、スタンバイ サーバーは RDB ファイルを通じてデータを更新します。

更新が完了すると、プライマリ サーバーは新しいレコードの書き込み操作をスタンバイ サーバーに送信します。スタンバイ サーバーがこれらの新しいレコードの書き込み操作を実行すると、データはプライマリ サーバーのデータと一致するようになります。

簡単に言うと、部分的な再同期とは、ネットワークが復旧すると、プライマリ データベースとスタンバイ データベースがスタンバイ サーバーに切断された後にプライマリ データベースが一連の書き込み操作を送信し、スタンバイ データベースがこれらの書き込み操作を実行してデータの一貫性を確保することを意味します。

この実装では、プライマリ データベースとスタンバイ データベースが共同でレプリケーション オフセットを維持するため、プライマリ データベースはどの書き込み操作をスタンバイ データベースに送信する必要があるかを認識し、スタンバイ データベースは同期時にどこで操作を続行するかを認識します。

図に示すように、プライマリ データベースのレプリケーション オフセットが 5000 の場合、100 バイトのデータがスタンバイ データベースに送信されます。送信が完了すると、レプリケーション オフセットは 5100 になります。

この時点で、プライマリ データベースとスタンバイ データベース間の接続は切断されており、スタンバイ データベースは 100 バイトのデータを受信して​​いません。スタンバイ データベースがプライマリ データベースに再接続されると、スタンバイ データベースは、自身のレプリケーション オフセット 5000 を使用してプライマリ データベースに PSYNC コマンドを送信します。プライマリ データベースは、この情報を受信した後、受信したレプリケーション オフセットに基づいて 5000 以降のデータをスタンバイ データベースに送信し、データの部分的な再同期を完了します。

上記は、サポートされるデータ構造、データ永続化方法、データ同期方法など、分散キャッシュ システム Redis に関係する主要なテクノロジです。上記の紹介を通じて、分散キャッシュ技術についてある程度理解していただけたと思います。

次に、別のキャッシュ データベースである Memcached について説明します。

Memcached 分散キャッシュの原理

Redis と同様に、Memcached もメモリに基づく高性能なキー値キャッシュ データベースです。 Memcached は Redis よりも早く導入され、Facebook、Vox、LiveJournal など多くの企業で使用されています。

実際、Memecached のキャッシュ原理は Redis のキャッシュ原理と似ています。したがって、次のコンテンツでは、サポートされているデータ構造、永続性、マスターとスレーブの同期におけるこれら 2 つのデータベースの違いについて説明することに重点を置きます。このようにして、これら 2 つのデータベースを比較して研究し、より包括的かつ詳細な理解を得ることができます。

まず、Memcached のクラスター構造を理解していただきます。

Redis のクラスター構造では、各ノードがハッシュ スロットの一部を担当し、各ノードをマスターまたはスレーブとして設計できます。 Redis とは異なり、Memcached クラスターは一貫性ハッシュの考え方を採用し、Ketama アルゴリズムを使用します。このアルゴリズムの主なアイデアは、仮想ノードを使用した一貫性のあるハッシュ アルゴリズムです。

実際のアプリケーションでは、各物理ノードは 100 ～ 200 個の仮想ノードに対応し、適切なストレージ バランスを実現します。理解しやすいように、Memcached クラスターの構造を簡略化しました。次の図に示すように、物理ノード 1 は 2 つの仮想ノード 1-1 と 1-2 に対応し、物理ノード 2 は 3 つの仮想ノード 2-1、2-2、2-3 に対応します。

仮想ノードでコンシステント ハッシュを使用する利点の 1 つは、ノードを追加または削除するときに大規模なデータ移行が発生しないことです。もう一度復習してもいいですよ（データ分散法ハッシュとコンシステントハッシュ、私は天才です）

データ構造のサポートに関しては、Memcached は単純な k/v データ型のみをサポートします。 List、Set、Hash などの複雑なデータ型を保存する場合、クライアントはそれを自身で処理し、文字列に変換してから保存する必要があります。これにより、操作が柔軟でないという欠点が生じます。たとえば、Memcached に保存されている配列内の要素を変更する必要がある場合、配列全体のデータを取り出して変更し、データベース全体に書き込む必要があります。

Memcached は永続性をサポートしていません。つまり、停電が発生すると、Memcached に保存されているすべてのデータが失われます。メモリは揮発性ストレージデバイスであるため、電源が切れるとデータは保存されません。

Memcached では、サーバー間の通信は行われません。つまり、マスターとスレーブの関係はサポートされません。高可用性を実現したい場合は、サードパーティを使用する必要があります。たとえば、Repcached は Memcached のレプリケーション機能を実装し、1 つのマスターと 1 つのバックアップをサポートするため、Memcached の可用性が高まります。

比較分析

上記では、分散キャッシュ テクノロジーについて説明するために、2 つの主流の分散キャッシュ システムである Redis と Memcached を例に挙げました。次に、理解しやすく参照しやすいように、表で分析して比較します。

要約する

今日は主に分散データのキャッシュ技術についてご紹介しました。

まず、水槽の例を使ってキャッシュとは何かを直感的に理解してもらい、次に分散データ キャッシュとは何かを紹介しました。分散データ キャッシュは、メモリをディスク キャッシュとして使用し、ユーザーが頻繁にアクセス速度を上げるために必要とするデータを保存します。

次に、主流のRedisとMemcachedを例に、サポートされているデータストレージ構造（k/v、Set、Listなど）、永続化技術（スナップショット方式など）、データ同期技術（具体的な技術原理については、分散データレプリケーション技術を参照してください。今日は、クローン作成の本当の技術をお教えします）など、分散キャッシュ技術の主要技術を紹介します。

最後に、今日のコアとなる知識のポイントをマインドマップでまとめたいと思います。