分散キャッシュの高可用性ソリューションを実現する方法

[[284637]]

データベース ディスク IO の同時実行性の増加によりシステムのパフォーマンスのボトルネックが発生したため、システムにキャッシュを導入したことについて説明しました。また、開発時にキャッシュの読み取りおよび書き込み戦略を正しく使用する方法を学び、データの不整合を防ぐための事例に基づいたいくつかの提案を行いました。これが現在の私たちのシステムのアーキテクチャです。

上図に示すように、サービス層とデータベース層の間にキャッシュ層を追加します。現在、データを読み取るときは、まずキャッシュから読み取り、読み取れない場合はデータベースから読み取ります。

キャッシュを導入した以上、できるだけ多くのリクエストがキャッシュに入るようにしたいので、キャッシュヒット率に注意を払う必要があります。ヒット率が高ければ高いほど、バックエンドのストレージが低下してボトルネックになる可能性が低くなります。キャッシュ ヒット率が低下した場合は、その理由を突き止めなければなりません。同時実行性の高いリクエストの場合、1% の低下でも大惨事となるからです。

たとえば、現在のシステム QPS が 10,000 で、各リクエストでキャッシュが 10 回クエリされるとします。ここでヒット率が突然 1% 低下し、バックエンド データベース MySql に 10,000 * 10 * 1% = 1,000 件のリクエストが送信されることになります。これは、MySQL データベースが 1,000 件の同時リクエストの急増に直面することを意味し、非常に危険です。通常の MySQL マシンは約 2,000 件の同時リクエストしか処理できません。したがって、キャッシュヒット率に注意を払う必要があります。

今では、わずか 1% の低下でもシステムに大きな影響を与えます。キャッシュ ノードがクラッシュして使用できなくなった場合、振り出しに戻り、すべてのリクエストがデータベースに送信されます。したがって、キャッシュを使用する場合は、上記のシングルポイント キャッシュ アーキテクチャを回避するために、可用性の高いキャッシュを構築する必要があります。今日は、キャッシュの高可用性ソリューション、つまり分散キャッシュの高可用性ソリューションを構築する方法を学習します。

経験に基づくと、分散キャッシュの高可用性ソリューションに現在使用されている主な 3 つのソリューションは、アプリケーション側、中間プロキシ層、およびサーバー側です。

• アプリケーション側ソリューションは、アプリケーション側でキャッシュ ノードを構成し、キャッシュ書き込みおよび読み取りアルゴリズム戦略を通じて分散ストレージを実装し、キャッシュの可用性を向上させます。
• プロキシ レイヤー ソリューションは、アプリケーション コードとキャッシュ ノードの間に独立したプロキシ レイヤーを追加します。アプリケーション側はプロキシ層に直接接続します。プロキシ レイヤーには、キャッシュの可用性を向上させる独自の高可用性戦略が組み込まれています。
• サーバーサイドソリューション、つまり、Redis Sentinelなどのキャッシュサービス自体に提供される高可用性

次に、これら 3 つのソリューションを個別に検討します。

アプリケーション側のソリューション

アプリケーション側、つまりコード レベルでは、キャッシュの読み取りと書き込みを自分で管理する必要があります。つまり、主に次の 2 つのモジュールを記述して、分散キャッシュの書き込みと読み取りを行う必要があります。

1. キャッシュに書き込む際には、キャッシュの各ノードにデータを分散させる、つまりデータシャーディングを実装する必要があります。
2. キャッシュを読み取るときは、マスタースレーブまたは複数のレプリカを考慮し、フォールトトレランスのために複数のキャッシュセットを使用する必要があります。

次に、どのように設計するかを見てみましょう。実際、この設計アイデアは必ずしもキャッシュに限定されるわけではありません。私たちの基盤となる開発のほとんどでこれを使用できます。誰もがそれをマスターできることを願っています。

キャッシュデータを分割する方法

マシン自体のメモリ、ネットワーク帯域幅などのさまざまな理由により、単一ノードのキャッシュはより高い同時実行性に耐えられないことがわかっているため、データをシャードに保存する、つまりシャーディング アルゴリズムを通じて各キャッシュ ノードにデータを分散させる必要があります。実際、これは先ほど説明したデータベースとテーブルのシャーディングと非常によく似ており、アーキテクチャのアイデアのほとんどは同じであることに気付きましたか。

現在、データは各キャッシュノードに保存されているため、部分的な障害が発生しても、ビジネス全体に影響が及ぶことはありません。この時点で、データを各ノードに均等に分散する必要があるので、このシャーディング アルゴリズムをどのように記述すればよいのか疑問に思うかもしれません。心配しないでください。このシャーディング アルゴリズムの記述方法を以下で確認してみましょう。

データシャーディングアルゴリズム

一般的に、データ シャーディング アルゴリズムには 2 種類あります。誰もが知っておくべき。これらは、以前のデータベースおよびテーブル シャーディングで使用されます。

• ハッシュシャーディングアルゴリズム
• 一貫性ハッシュシャーディングアルゴリズム

ハッシュシャーディングアルゴリズム

ハッシュ シャーディング アルゴリズムでは、キャッシュされたキーを取得し、それに対してハッシュ操作を実行し、最後にハッシュ操作の結果の係数とキャッシュ ノードの合計数を取得します。結果の番号は特定のシャーディング ノードです。たとえば、現在 3 つのキャッシュ ノードがあります。データを書き込むときは、次の図に示すように、キーをハッシュして hash(key) を計算し、結果を 3 で割った剰余をとります。

このシャーディング アルゴリズムの利点は、開発が簡単で理解しやすいことです。デメリットは、キャッシュ ノードの総数が変わると、データの不均一性が生じ、多数のキャッシュが無効になり、使用できなくなることです。ただし、私たちも開発でこのアルゴリズムを使用しています。たとえば、ビジネスでキャッシュヒット率をあまり気にしない場合は、このハッシュシャーディングアルゴリズムを使用できます。

一貫性ハッシュシャーディングアルゴリズム

上記の単純なハッシュシャーディングアルゴリズムは、高いキャッシュヒット率を必要とするビジネスに一定の影響を与えるため、キャッシュノードの増減によって発生するキャッシュヒット率の低下の問題を効果的に解決する一貫性のあるハッシュシャーディングアルゴリズムが登場しました。それでは、どのように行われるか見てみましょう。

1. まず、2^32 ハッシュ リングを維持します。
2. 次に、各キャッシュノードの IP またはマシン名のハッシュ値が計算され、各ノードに対して複数のハッシュが計算されます。これを仮想ノードと呼びます。データをより均一にし、ノードの雪崩を回避するためです。
3. 計算されたハッシュ値、つまり仮想ノードをハッシュ リングに配置します。
4. キーを書き込む場合、まずキーをハッシュしてハッシュ値を計算し、ハッシュ リング上の位置を決定します。
5. 最後に、リング上を時計回りに検索し、最初に見つかったキャッシュ ノードが保存するノードになります。

たとえば、以下の場合、key1 と key2 はノード 1 に、key3 と key4 はノード 2 に、key5 はノード 3 に、key 6 はノード 4 にそれぞれ格納されます。

上の図に示すように、ノード 1 とノード 2 の間に別のノード 5 を追加すると、以前はノード 2 にヒットしていたキー 3 が今度はノード 5 にヒットしますが、他のキーは変更されないことがわかります。同様に、ノード 3 をクラスターから削除すると、キー 5 のみが影響を受けます。したがって、ノードを追加および削除すると、少数のキーのみが他のノードに移動し、キーがヒットしたノードの大部分は変更されないため、ヒット率が大幅に低下することはありません。

生産開発の提案

一貫性ハッシュアルゴリズムを使用する場合は、キャッシュの有効期限を設定する必要があります。なぜそう言うのでしょうか?ここで、クラスター内に node1 と node2 の 2 つのノードがあり、node1 が (k, 5) を格納しているとします。次に、クライアントが 5 を 8 に変更することを要求します。この時点で、ネットワークの問題により、node1 のノード サービスとクライアントは切断されます。次に、この書き込み操作はノード 2 にルーティングされます。 node1 ネットワークが復元されると、クライアントは node1 の k を 5 として読み取りますが、実際には k はすでに 8 であり、ダーティ データが発生するため、有効期限を設定する必要があります。

Memcached はマスタースレーブメカニズムとしてどのように機能しますか?

Memcached は Redis 自体のようなマスター/スレーブ レプリケーション メカニズムをサポートしていないため、memcached の高可用性をどのように確保できるでしょうか?実際、これは以前のデータベース ソリューションに似ています。

1. memcached マスターのグループごとにスレーブのグループを構成します。
2. データが更新されると、マスターとスレーブ間で同期的に更新されます。
3. データを読み取るときは、まずスレーブから読み取られます。読み取れない場合は、マスターに送信され、その後、データがスレーブに書き戻されます。

マスタースレーブレプリケーションの利点は、スレーブに障害が発生した場合でも、マスターがバックアップとして機能し、大量のリクエストがデータベースに侵入することがないため、キャッシュシステムの高可用性が向上することです。

中間プロキシ層ソリューション

上記のアプリケーション側のソリューションは、基本的にほとんどの問題を解決できます。現在、多くの技術言語を持つ企業では、言語ごとにセットを開発する必要があります。例えば、弊社では Java、PHP などを採用しております。

net の場合は、中間プロキシ レイヤーを使用するのが最適です。ビジネス側はこれらの複雑な状況を考慮する必要がなく、プロキシ層に直接接続できます。

プロキシ層は、キャッシュノード自体の高可用性を管理し、Redis プロトコルなどのプロトコルを介してさまざまな言語のビジネス端末に接続します。業界には、Facebook の Mcrouter、Twitter の Twemproxy、Wandoujia の Codis など、中間プロキシ層ソリューションも数多く存在します。基本的なアーキテクチャは次のとおりです。

上図に示すように、中間層プロキシ ソリューションとは、すべてのキャッシュの読み取りおよび書き込み操作がプロキシ層を介して直接完了し、プロキシ層が上記のアプリケーション側のすべての操作を単独で完了することを意味します。

サーバーソリューション

サーバー側のソリューションは、主にキャッシュ サービス自体によって管理されます。私たち開発者は、コード管理を記述したり、中間層を導入したりする必要はありません。必要なのは、関連する運用と保守の構成サポートだけです。たとえば、Redis のセンチネル モードは、Redis がデプロイされるときに高可用性の問題を解決するために使用されます。マスターノードがハングアップした後、スレーブノードを自動的にマスターノードに昇格させ、クラスター全体の可用性を確保できます。したがって、サーバーは私たちの開発に大きな影響を与えません。 Redis Sentinel についてはまだ知っておく必要がありますが、これについては後で説明します。

まとめると、今日はキャッシュを使用する際に単一ノードによって発生するさまざまな問題を回避する方法について説明しました。そのため、高可用性のキャッシュ アーキテクチャを構築する必要があります。アプリケーション側、中間プロキシ層、サーバー側の合計 3 つのソリューションについて説明しました。企業のリソース状況に応じて適切なソリューションを選択できます。