title: 一貫性のあるハッシュ アルゴリズムの概要
date: 2023-05-22 11:25:13
tags:
- アルゴリズムの
カテゴリ: - データ構造とアルゴリズム
カバー: https://cover.png
機能: false
1. 背景
写真をキャッシュするための 3 つのキャッシュ サーバーがあるとします。これら 3 つのキャッシュ サーバーに No. 0、No. 1、No. 2 と番号を付けます。現在、キャッシュする必要がある写真は 30,000 枚あります。これらの写真がこれら 3 つのサーバーに均等にキャッシュされ、キャッシュの負荷を分散できることが期待されます。つまり、各サーバーに約 10,000 枚の写真をキャッシュできればよいのですが、どうすればよいでしょうか?
30,000 枚の画像を規則性なく 3 台のサーバーに均等にキャッシュした場合、要件を満たすことができますか? できる！しかし、これを行うと、キャッシュ アイテムにアクセスする必要があるときに、30,000 個のキャッシュ アイテムからアクセスする必要があるキャッシュを見つけるために 3 つのキャッシュ サーバーを横断する必要があり、その横断プロセスは非効率的で時間がかかりすぎます。
元の方法は、キャッシュ アイテムのキーをハッシュし、ハッシュの結果をキャッシュ サーバーの数に取り、モジュラスの結果に基づいてキャッシュ アイテムをキャッシュするサーバーを決定することです。たとえば、イメージにアクセスするためのキーとしてイメージ名を使用するとします。イメージ名が繰り返されないと仮定すると、次の式を使用してイメージを保存するサーバーを計算できます。
ハッシュ (ピクチャ名)% N
ピクチャの名前は繰り返されないと想定されているため、同じピクチャ名に対して同じハッシュ計算を実行すると、結果は同じになるはずです。サーバーが 3 台あり、ハッシュの結果を使用して 3 の余りを計算する場合、余りは 0、1、または 2 でなければなりません。これは前のサーバー番号とまったく同じです。余りの結果が 0 の場合、現在のピクチャ名に対応するピクチャをサーバー 0 にキャッシュします。2、同じ理由です。
そして、任意の画像にアクセスする場合、画像名に対して上記の計算を再度行うだけで、該当する画像がどのキャッシュ サーバーに保存されているかがわかり、そのサーバー上で画像を検索するだけで済みます。
ただし、上記の HASH アルゴリズムをキャッシュに使用すると、いくつかの欠陥が発生するため、3 台のキャッシュ サーバーがキャッシュ要件を満たせなくなったら、どうすればよいでしょうか。そうです、とても簡単です。キャッシュサーバーを2台追加するだけです。キャッシュサーバーを1台追加すると、キャッシュサーバーの数は3から4に変わります。このとき、同じピクチャを上記の方法でキャッシュする場合、このピクチャのサーバー番号は元のサーバー番号3台とは異なるはずです。除数が3から4に変わるためです。除数が同じ場合、余りは異なるはずです。サーバーの数が変わると、1秒以内にすべてのキャッシュが無効になります。一定期間、アプリケーションがキャッシュからデータを取得できない場合、バックエンドサーバーにデータを要求します。
同様に、3 つのキャッシュのうち 1 つが突然故障してキャッシュできなくなった場合は、故障したマシンを削除する必要がありますが、キャッシュ サーバーを 1 つ削除すると、キャッシュ サーバーの数が 3 台から 2 台に変わってしまうため、これを回避する方法を考えなければなりませんが、前述の HASH アルゴリズム自体の性質上、キャッシュにモジュロ方式を使用する場合、この状況は避けられません。これらの問題を解決するために、一貫性のあるハッシュ アルゴリズムが誕生しました。
2. 基本的な考え方
実際、一貫性のあるハッシュ アルゴリズムでも法を使用しますが、今説明した法法はサーバーの数を法とするのに対し、一貫性のあるハッシュ アルゴリズムは2 32 2^{32}です。232 取模
まず、2 の 32 乗を時計と同じように円として考えます。時計の円は 60 個の点で構成される円として理解できますが、この円は 2 32 2^ {32} で構成されると考えます。232 個の点で構成される円の
リングの真上にある点は 0 を表し、0 点の右側の最初の点は 1 を表し、以下同様に 2、3、4、5、6... と 2 32 − 1 2^{32}-1 まで続きます。232−1、つまり点 0 の左側の最初の点は2 32 − 1 2^{32}-1232−1
この2点から32点までのリングをハッシュリングと呼びます
では、コンシステント ハッシュ アルゴリズムは、上の図の円とどのような関係があるのでしょうか?
前述のシナリオを例として、サーバー A、サーバー B、およびサーバー C の 3 つのキャッシュ サーバーがあると仮定すると、運用環境では、これら 3 つのサーバーが独自の IP アドレスを持つ必要があり、それぞれの IP アドレスをハッシュ計算に使用し、ハッシュされた結果のペア 2 32 2^ {32}232モジュロの場合、次の式を使用して表示できます。
ハッシュ (サーバー A の IP アドレス) % 2^32
上の式で計算された結果は、0 ～2 32 − 1 2^{32}-1でなければなりません。232−1の間の整数。この整数は 0 から2 32 − 1 2^{32}-1の間である必要があるため、サーバー A を表すために計算された整数を使用します。232−1の場合、この整数に対応する上の図のハッシュ リング上の点が存在する必要があります。この整数を使用してサーバー A を表すと、次の図に示すようにサーバー A をこのリングにマッピングできることを説明しました。
同様に、サーバー B とサーバー C も同じ方法で上図のハッシュ リングにマッピングできます。
上図のように 3 台のサーバーがハッシュ リングにマッピングされていると仮定すると (もちろんこれは理想的な状況です)、これまではキャッシュ サーバーをハッシュ リングにリンクしていました。上記の方法でキャッシュ サーバーをハッシュ リングにマッピングしました。次に、同じ方法を使用して、キャッシュする必要があるオブジェクトもハッシュ リングにマッピングできます。
画像をキャッシュするにはキャッシュ サーバーを使用する必要がありますが、画像を検索するキーとして画像の名前を引き続き使用します。その後、次の式を使用して画像を上の図のハッシュ リングにマッピングできます。
ハッシュ (ピクチャ名) % 2^32
マッピング後の概略図は次のとおりです。下図のオレンジ色の丸がその図を表します
これでサーバーと画像がハッシュ リングにマッピングされました。では、上の図の画像はどのサーバーにキャッシュされるべきでしょうか? 上の図の画像はサーバー A にキャッシュされますが、なぜですか? 画像の位置から時計回りに最初に遭遇するサーバーはサーバー A であるため、上図の画像は下図に示すようにサーバー A にキャッシュされます。
コンシステント ハッシュ アルゴリズムは、オブジェクトをどのサーバーにキャッシュするかを判断するためにこの方法を使用します。キャッシュ サーバーとキャッシュされたオブジェクトをハッシュ リングにマッピングした後、キャッシュされたオブジェクトの位置から時計回りに最初に見つかったサーバーが、現在のオブジェクトがキャッシュされるサーバーになります。キャッシュされたオブジェクトとサーバー ハッシュの値は固定されているため、サーバーが変更されていない場合、ピクチャは固定のサーバーにキャッシュされます。次にこのピクチャにアクセスするときは、同じアルゴリズムを再度使用するだけです。計算します。 、画像がどのサーバーにキャッシュされているかを計算し、対応するサーバーに直接アクセスして、対応する画像を見つけることができます。
前の例ではデモンストレーションのために 1 つのピクチャのみを使用しましたが、キャッシュする必要があるピクチャが 4 つあると仮定すると、概略図は次のようになります。
写真 No.1 と No.2 はサーバー A にキャッシュされ、写真 No.3 はサーバー B にキャッシュされ、写真 No.4 はサーバー C にキャッシュされます。
3. 利点
サーバー B に障害が発生したと仮定すると、サーバー B を削除する必要があります。その後、上図のハッシュ リングからサーバー B を削除できます。サーバー B を削除した後の概略図は次のようになります。
サーバー B が削除されない場合、画像 3 はサーバー B にキャッシュされる必要がありますが、サーバー B が削除された後は、前述の一貫したハッシュ アルゴリズムの規則に従って、画像 3 はサーバー C にキャッシュされる必要があります。これは、画像 3 の位置から開始して時計回りに最初に遭遇するキャッシュ サーバー ノードはサーバー C であるためです。つまり、サーバー B に障害が発生して削除されると、画像 3 のキャッシュの場所が変更されます。
ただし、画像 4 は引き続きサーバー C にキャッシュされ、画像 1 と 2 はサーバー A に引き続きキャッシュされます。これは、サーバー B が削除される前と同じです。これは、一貫性のあるハッシュ アルゴリズムの利点です。以前のハッシュ アルゴリズムが使用されている場合、サーバーの数が変更されると、すべてのサーバーのすべてのキャッシュが同時に無効になります。一貫性のあるハッシュ アルゴリズムを使用する場合、サーバーの数が変更されると、すべてのキャッシュが無効になるわけではなく、一部のキャッシュのみが無効になります。フロントエンドキャッシュは、すべてのプレッシャーをバックエンドサーバーに同時に集中させることなく、システム全体のプレッシャーを共有できます。
4. ハッシュリングのスキュー
コンシステント ハッシュの概念を導入する場合、理想的には、次の図に示すように、3 つのサーバーをハッシュ リングに均等にマッピングします。
実際のマッピングでは、サーバーは次のようにマッピングされます。
上の図に示すようにサーバーがマッピングされている場合、次の図に示すように、キャッシュされたオブジェクトのほとんどは特定のサーバーにキャッシュされる可能性があります。
上の図では、サーバー A には 1 番、2 番、3 番、4 番、6 番の写真がすべてキャッシュされ、サーバー B には 5 番の写真だけがキャッシュされ、サーバー C にはまったく写真がキャッシュされていません。上の図のような状況が発生すると、3 台のサーバー A、B、C が平均的に十分に活用されておらず、キャッシュの分布が非常に偏っています。また、このときにサーバー A に障害が発生すると、無効なキャッシュの数も最大値に達します。極端な場合には、システムクラッシュが発生する可能性がありますが、上図の状況をハッシュリングのスキューと呼びますが、ハッシュリングのスキューを防ぐにはどうすればよいでしょうか?
5. 仮想ノード
サーバーが 3 台しかないため、サーバーをハッシュ リングにマッピングすると、ハッシュ リングが歪む可能性が非常に高くなります。ハッシュ リングが歪んでいると、キャッシュが各サーバー上で非常に不均等に分散されることがよくあります。
3 つのサーバーにバランスよくキャッシュを分散したい場合、ハッシュ リング上にこれら 3 つのサーバーをできるだけ均等に配置するのが最善です。しかし、実際のサーバー リソースは 3 つしかありません。どうすれば無空間から増やすことができますか? 冗長な実物理サーバー ノードがないため、仮想的な方法で既存の物理ノードをコピーすることしかできません。実ノードから仮想的にコピーされたノードを「仮想ノード」と呼びます。仮想ノード参加後のハッシュリングは以下の通り
「仮想ノード」はハッシュリング上の「実ノード」（実際の物理サーバ）のレプリカであり、1つの実ノードが複数の仮想ノードに対応できます。
上の図からわかるように、3 つのサーバー A、B、C はそれぞれ 1 つの仮想ノードを仮想化していますが、必要に応じてさらに多くの仮想ノードを仮想化することもできます。仮想ノードの概念を導入した後、キャッシュの分散はよりバランスのとれたものになります。上の図では、ピクチャ No. 1 と No. 3 はサーバー A にキャッシュされ、ピクチャ No. 5 と No. 4 はサーバー B にキャッシュされ、ピクチャ No. 6 と No. 2 はサーバー C にキャッシュされます。それでも心配な場合は、より多くの仮想ノードを仮想化して、ハッシュ リング スキューの影響を軽減できます。仮想ノードが増えるほど、ハッシュ リング上のノードが増え、ハッシュ リング上のノードが増える確率が高くなります。キャッシュは均等に分散されます