大規模クラスターでのデータ損失について

一般的に使用されるレプリケーション ルーチンは 3 つあります。データベースは、各データが 3 台の異なるコンピューター上の 3 つの独立したディスクに確実にコピーされるようにします。その理由は簡単です。ディスクが故障したのは特定の瞬間だけです。1 つのディスクが故障しても、それを交換する時間があり、残りの 2 つのコピーのうち 1 つを使用してデータを復元し、新しいディスクに書き込むことができます。 。復元する前に 2 番目のディスクが死ぬ確率は非常に低いため、両方のディスクが同時に死ぬ確率は、小惑星が地球に衝突するのと同じくらいわずかです。

また、1 つのディスクが故障する可能性はほぼ 0.1% (おそらく大まかです)、2 つのディスクが故障する可能性はほぼ 10 の 6 乗、そして 3 つのディスクが同時に故障する可能性は特別に計算されました。約 10 の -9 乗、つまり 10 億分の 1 です。この計算は、1 つのディスクの障害が他のディスクの障害から独立していることを示しています。これはあまり正確ではありません。たとえば、すべてのディスクが同じ生産ラインで生産されている場合、すべて不良である可能性があります。しかし、これで十分です。私たちのアイデアのために。

これまでのところ、これは合理的であるように思えますが、残念ながら、これは多くのデータ ストレージ システムには当てはまりません。このブログではその理由を説明します。

データベース クラスターに含まれるマシンが 3 台のみの場合、すべてのマシンが同時にクラッシュする可能性は非常に低くなります (データ センターの破壊などの関連エラーを除く)。ただし、より大きなクラスターを使用すると、問題はそれに応じて変化します。クラスター内で使用するノードとディスクが増えるほど、データが失われる可能性が高くなります。

これは計算に基づいています。「本当に? データを 3 つのディスクにコピーしました。クラスターが増加すると障害の可能性が高くなるのはなぜですか? クラスターの容量はどうなるのでしょうか?」と思われるかもしれませんが、可能性を計算して示しました。なぜ次のアイコンが付いているのか:

明らかに、これは 1 つのノードに障害が発生する可能性ではなく、データの 3 つのコピーすべてが永久に失われる可能性があるため、バックアップからデータを復元するのは保守的なアプローチにすぎません。クラスターが大きくなるほど、データが失われる可能性が高くなります。これは、データを複製するために料金を支払うことを考えると考えられないことかもしれません。

グラフの Y 軸は少し恣意的で、多くの想像力に依存していますが、線の方向は信じられないほどです。以前の仮定に基づくと、ある時点でノードが故障する確率は 0.1% ですが、この図は、8,000 ノードのクラスターでは、データの 3 つのコピーが永久に失われる確率は約 0.2% であることを示しています。はい、その通りです。3 つのコピーすべてを失うリスクは、1 つのノードのデータを失うリスクの 2 倍です。では、これらのコピーは何に使われるのでしょうか?

この図から直感的に判断すると、8,000 ノードのクラスターでは、特定の時間に一部のノードがダウンするのが一般的です。これは問題ではないかもしれません。一定の確率で混乱とノードの置き換えが発生することが推測でき、その一部は定期的なメンテナンスです。ただし、運悪くコピーしたノードデータの宛先ノードがダウンしてしまった場合、データは二度と取得できなくなります。データの損失は、クラスターのデータ セット全体の比較的小さな部分ですが、3 つのレプリカを失うと、「このデータを失いたくない」ではなく、「このデータを失いたくない」と考えるかもしれません。それほど大きくはありませんが、誤って一部のデータが失われます。「おそらく、失われたデータのこの部分はデータの重要な部分です。

3 つのレプリカがすべて不良ノードである可能性は、システムで使用されるレプリケーション アルゴリズムによって異なります。上の図は、データが特定の数のパーティション (またはシャード) に分割され、各パーティションにランダムに選択された 3 つのノード (または擬似ランダム ハッシュ関数) が格納されることに単純に依存しています。これは、(私の知る限り) Cassandra と Riak で使用される一貫性のあるハッシュの特殊なケースです。他のシステムがレプリケーション作業をどのように分散しているかわからないので、マルチストレージ システムの内部に詳しい人から見て考えています。

複製されたデータベースの確率モデルを使用して上記のグラフをどのように計算したかを説明しましょう。

独立したノードがデータを失う確率が p=P (ノード損失) であると仮定します。このモデルでは時間を無視して、特定の期間における失敗の確率を簡単に見ていきます。たとえば、p=0.001 が特定の日にノードが故障する確率であると仮定できます。ノードを交換し、失われたデータを新しいノードにダンプするのに 1 日を費やすのが妥当です。簡単に言うと、ノード障害とディスク障害を区別する必要はなく、永続的な障害についてのみ説明します。

n をクラスター内のノードの数としましょう。 f は障害が発生したノードの数 (障害が比較的独立していると仮定) であり、二項分布です:

この式は、f 個のノードが失敗する確率です。これは、n からさまざまな方法で抽出された f 個のノードの数です。 「n 選択 f」と発音され、次のように定義されます:

。 。 。 。 。 。

特定の導出プロセスについては、ここでは詳しく説明しません。上記の式に基づいて、n 個のノードとレプリケーション係数 (複製されたバックアップ ノードの数) を持つクラスターで 1 つ以上のパーティションが失われる確率を導き出すことができます。障害が発生したノードの数 f がレプリケーション係数よりも小さい場合、データは失われていないと確信できます。ただし、 f が r と n の間にある場合は、すべての可能性を追加する必要があります:

これは少し冗長ですが、正確だと思います。 r=3、p=0.001、k=256n、n を 3 ～ 10000 とすると、上の図が得られます。この計算を実装するために Ruby プログラムをいくつか書きました。

より単純な推測を得るためにユニオン バインディングを使用します。

1 つのパーティションの障害が他のパーティションから完全に独立しているわけではありませんが、この推測は依然として当てはまります。これは実験結果に近いようです。途中で、データ損失の確率は直線に近く、ノードの数に比例します。推測によれば、確率は数値と正の関係にあり、各ノードには固定の 256 個のパーティションがあると仮定します。

実際にどのように機能するかはわかりません。しかし、これは計算に敏感な興味深い現象だと思います。大規模なデータベース クラスターを持つ企業が実際にデータ損失を経験したという状況を聞いたことがあります。しかし、記事やレポートではあまり一般的ではありません。もしあなたが現在このテーマを勉強しているのであれば、教えてください。

計算結果は、データ損失の可能性を減らしたい場合は、パーティションの数を減らし、レプリケーション係数を増やす必要があることを示しています。より多くのバックアップを使用するとコストも高くなるため、大規模なクラスターを考慮すると、これはすでにコストが高くなります。ただし、パーティションの数は、意味のある負荷分散プロセスを示しています。 Cassandra は当初、ノードごとに 1 つのパーティションを持っていましたが、その後、より優れた負荷分散と効率的なセカンダリ バランシングに対応するために、ノードごとに 256 のパーティションに変更されました。

これらが実際に機能する前に、適度に大規模なクラスターを見つける必要がありますが、数千レベルのクラスターが多くの大企業で使用されています。したがって、この分野で実際の経験を持つ人々からの意見を聞くことに興味があります。 10,000 ノードの永久的なデータ損失の確率が毎日 0.25% 以内に制御される場合、1 年でデータの 60% が失われることになります。

分散データ システムの設計者として、この記事を読んでどう思いますか?私の言っていることが正しければ、レプリケーション スキームの設計についてさらに考慮する必要があります。この記事があなたの現実への認識を高めることを願っています。 3 つのレプリケーション ノードは実際にはそれほど安全ではないためです。

以上が大規模クラスターでのデータ損失についての詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。