ストレージ システムの説明 - 分散ストレージ システムの問題の考慮

分散システムは、主にストレージ モデルとコンピューティング モデルの 2 つのカテゴリに分けられます。この記事では主にストレージモデルの紹介について説明します。コンピューティング モデルの分散システム原理は、独自のコンピューティング特性に基づいて特別なスケジューリング ロジックが追加されていることを除いて、ストレージ モデルのものと似ています。

あらゆる分散システムでは、次の 5 つの問題を考慮する必要があります。

1. データはどのように配布されますか?

それはすべての卵を一つのカゴに入れるようなものです。一般的に、バスケットのサイズは同じですが、システムによっては異なるサイズのバスケットをサポートするものもあります。卵にはさまざまなサイズがあるため、多くのシステムでは卵を同じサイズに「カット」してからバスケットに入れます。また、卵によっては、コンピューター ルーム/ラック スペースの要件など、バスケットに対する要件があるものもあります。

データ分散アルゴリズムの品質は、すべてのマシンの負荷の変動が十分に小さくなるようにデータが十分に均等に分散されているかどうかによって測定されます。

[[245103]]

2. 災害からの復旧を実現する方法

分散システムの非常に重要な位置付けは、プログラムがマシンを自動的に管理し、人間の関与を最小限に抑えることです。そうしないと、分散システムの運用および保守コストが許容できないものになります。

災害復旧は非​​常に複雑な問題です。多くの成熟したシステムであっても、それが特に優れていることを保証することはできません。一般的なシステムで発生する可能性のある問題を見てみましょう。

（１）機械の停止時間

これは最も一般的な欠陥です。システム内で最も脆弱なハードドライブの故障率は年間 10% になる可能性があります。この計算によると、1,000 台のマシンのクラスターでは、毎週 2 台のマシンがダウンすることになります。したがって、マシンの数が増えた後は、これはごく普通のことです。

通常、機械が故障した後の修理サイクルは 24 時間であり、このプロセスでは機器を交換したり、機械を再起動したりするために手動でアクセスする必要があります。マシンを復元すると、メモリ情報は完全に失われますが、ハードディスクの情報は保存される可能性があります。

分散システムでは、マシンの障害がサービスに影響を与えないこと、また、修復されてクラスターに戻された後も正常に動作できることを保証する必要があります。

（２）ネットワーク障害

これは最も一般的かつ致命的な欠陥です。この問題により、分散システム設計の難易度が大幅に高まります。障害は通常、ネットワークの輻輳、ルーティングの変更、機器の異常などにより発生します。問題は、パケット損失、遅延、または接続の完全な喪失である可能性があります。

これを考慮して、分散システムを設計する場合、4 層プロトコルとして TCP を使用するのが一般的であり、UDP/UDT プロトコルを使用することはほとんどありません。さらに、TCP プロトコルでは、データが相手側に送信されることを完全に保証することはできません。例えば、再度データを送信する場合、データがローカル バッファーに書き込まれていれば、オペレーティング システムはアプリケーション層にデータが正常に送信されたことを通知しますが、データが相手側にまったく送信されていない可能性もあります。したがって、通常は、ネットワーク層の動作が予測可能であることを保証するために、アプリケーション層 ACK を追加する必要があります。

ただし、アプリケーション層の ACK があっても、要求が送信された後に ACK が受信されません。このとき、送信側は相手が要求を受け取らずに直接電話を切ったのか、要求を受けて電話を切ったのかは分かりません。これは、一部の制御コマンド要求を送信する場合に特に致命的です。

一般的なシステムソリューションは 2 つあります。

1. クエリコマンドを送信して、どの状況であるかを判断します。
2. プロトコルを「べき等性」（つまり、データを繰り返し送信しても最終データに影響しない）になるように設計し、再試行を続ける

（３）その他の異常

たとえば、ディスク ブロックが不良ですが、マシンはダウンしていません。マシンはまだ稼働していますが、さまざまな操作が非常に遅くなっています。ネットワークの混雑によりネットワークが切断され、その後データを送信しなくなった後に正常に戻り、その後検出されて再度使用されると再びクラッシュする、など。

これらの異常は実際の状況に基づいて分析し、長期的なエンジニアリングの実践の中で調整および解決する必要があります。

そして、非常に苛立たしい事実は、設計段階で考慮した例外が実際の運用で必ず発生する一方で、考慮しなかった例外も実際の運用で発生するということです。したがって、分散システム設計の原則の 1 つは、目に見える例外を見逃さないことです。

3. 読み書きプロセスの一貫性を確保する方法

一貫性の確率は非常に単純です。つまり、更新/削除要求が返された後、他のユーザーが私が書き込んだ新しい値を読み取ることができるかどうかです。スタンドアロン システムの場合、この一貫性を実現するのは非常に簡単で、最悪の場合でも書き込み効率がわずかに低下するだけです。しかし、分散システムの場合、これは複雑になります。災害復旧の目的では、データの複数のコピーが必要なので、これらの複数のコピーを更新し、読み取りおよび書き込みプロトコルを制御する方法が大きな問題になります。

また、一部の書き込み操作は複数のシャードにまたがる場合があり、さらに複雑になります。先述のネットワーク障害以外にも、データの同期時にさまざまなネットワーク障害が発生する可能性があり、考えただけでも頭が痛くなります。

また、一貫性が確保できたとしても、読み取りおよび書き込みのパフォーマンスが大幅に低下する可能性があります。システムを設計するとき、それはスライドバーのようなものです。左側は一貫性、右側はパフォーマンスです。これら 2 つを同時に満たすことはできません (CAP 原則)。一般的なシステムでは妥協が必要になります。適切に設計されたシステムでは、ユーザーは構成を通じてスライダーの位置を制御し、さまざまなニーズを満たすことができます。

一般的に一貫性はどのように損なわれるのでしょうか?一貫性の次の定義を見てみましょう。強い一貫性を除き、他の一貫性特性は互いに競合しないことに注意してください。システムは、1 つまたは複数の一貫性特性を同時に満たすことができます。

強い一貫性

言うまでもなく、これは最も厳格な一貫性要件です。いずれかのユーザーが何かを書き込むと、書き込み要求が返された瞬間に他のすべてのユーザーが新しい値を読み取ることができます。

最終的な一貫性

これも頻繁に言及される概念であり、多くのシステムではこのタイプの一貫性がデフォルトで提供されています。つまり、システムは最終的に「強い一貫性」の状態に到達しますが、それまでにシステムが不整合な状態になる不確実な期間が存在します。

セッションの一貫性

これも理解しやすく、多くのシナリオのニーズを満たすことができます。同じセッションで、ユーザーは「強力な一貫性」サービスを体験します。

単調な一貫性

これはセッション一貫性よりも少し弱いです。これは、ユーザーが特定のデータを読み取った後に、最後に読み取った値よりも古いデータを読み取らないようにするだけです。

4. パフォーマンスを向上させる方法

分散システムは、もともとマシンを積み重ねることでシステム全体のパフォーマンスを向上させるように設計されているため、システムのパフォーマンスも非常に重要です。パフォーマンス部分は、一般的に一貫性/災害復旧やその他の設計によって影響を受け、一定の妥協が必要になります。

分散システムを測定するためのパフォーマンス指標は、通常、次のようになります。

• ***容量
• qps を読む
• qps を書き込む

5. 水平展開を確実にするには

水平拡張とは、マシンを追加することでクラスターのサービス容量を線形に拡張できるかどうかを指します。