分散ストレージのメタデータ設計

[[247858]]

従来のストレージ設計方法には、主に以下のカテゴリが含まれます。

• GlusterFS などの分散型ストレージ設計。
• Hadoop などの集中型ストレージ設計があります。
• GridFS や HBase などのデータベース ベースのストレージ設計。
• FastDFS などのメタデータをバイパスするストレージ設計。

以下で一つずつ説明していきましょう。

分散型ストレージ設計: GlusterFS

現在、GlusterFS はインターネット業界ではあまり使用されず、大規模なコンピューターで多く使用されています。次のような設計上の特徴があります。

• POSIX ファイル システムと互換性があります。単一のマシン上のアプリケーションは、変更なしで GlusterFS 上で実行できます。
• 中央ノードなし: 単一障害点やパフォーマンスのボトルネックはありません。
• スケーラビリティ: 中央ノードが存在しないため、GlusterFS は無制限のスケーラビリティを備えており、任意の数のサーバーに拡張しても問題ありません。

ここでは、POSIX 互換性の長所と短所については説明しませんが、GlusterFS による分散ノード設計で発生する一般的な問題について重点的に説明します。

1. 破損したディスクを修復します。分散化とは、キーの保存場所をキーから推測できることを意味します。しかし、ディスクが壊れた場合（単一ディスク障害）はどうなるでしょうか?直接的な対処方法は、不良ディスクを削除し、新しいディスクと交換して、データをコピーすることです。このアプローチは小規模なシステムに非常に適しています。ただし、4T SATA ディスクはギガビット ネットワークでも 100MB/秒の速度でしか書き込めず、修復時間は 11 時間かかります。一般的なストレージフルは総ストレージ容量の 80% を指すことを考慮すると、修復時間は 8 ～ 9 時間に達するため、大規模なシステムには適していません。大規模なシステムには多数のディスクがあり、毎日多数のディスクが故障します。ディスクを同じバッチで購入した場合、対称的な設計のため、読み取りと書き込みの特性は非常に類似しています。そして、不良ディスクの修復にかかる 8 ～ 9 時間の間に、他のディスクも同時に故障する可能性が非常に高くなります。この時点では、システム全体の信頼性は比較的低く、6 または 7 ナイン程度にしか達しません。より高い信頼性を実現したい場合、レプリカの数を狂ったように増やすしか解決方法がありませんが、コストが大幅に増加します。

GlusterFS 自体は、この種の修復設計を使用しません。その修復方法は、ディスクの読み取り時に不良ブロックが見つかった場合に修復をトリガーすることですが、この設計では修復に時間がかかります。この問題を回避するにはどうすればよいでしょうか?最も簡単な方法は、ディスクを複数のパーティションに分割し、各パーティションをできるだけ小さくすることです。たとえば、4T ディスクは 50 のゾーンに分割され、各ゾーンは 80 GB のみで、各ゾーンのメタ情報が記録されます。キーから保存場所を推測する場合、まずキーが配置されているゾーンの番号を計算し、次に先ほどのメタデータを使用して、このゾーンに対応するマシン、ディスク、およびディレクトリを取得します。この利点は、ディスクに障害が発生した場合、ディスクの交換を待たずに修復を開始でき、同じディスク上で修復する必要がないことです。空き容量のある複数のディスク上で修復できるため、同時修復機能が得られます。 4T ディスクを 50 ゾーン (各 80G) に分割すると、修復時間を 8 ～ 9 時間から約 13 分に短縮できます。

2. 能力の拡大。前述したように、中央ノードのない設計では、キーからストレージの場所を推測できるため、キーを均等にハッシュする必要があります。このとき、クラスターサイズを 100 から 200 に拡張するとどのような問題が発生するでしょうか?ハッシュは均一であるため、新しく追加された 100 台のマシンのストレージ負荷は以前のものと一致する必要があり、データの半分を移行する必要があります。ただし、クラスターが大きい場合、データ移行プロセスには通常長い時間がかかり、ネットワークの輻輳が発生する可能性があります。同時に、データ移行中の読み取りおよび書き込みロジックは非常に複雑になります。解決策は、テストを追加し、コードの品質を向上させ、バグを回避することです。別のアプローチとしては、容量を固定して拡張しないようにすることですが、これはインターネットのスタイル（非常に小さなモデルから始めて徐々に拡張する）と一致しません。

3. 異機種混在ストレージはサポートされていません。クラウド ストレージ サービスを提供する企業は、多くの顧客が非常に小さなファイルを保存する一方で、他の多くの顧客が非常に大きなファイルを保存するという問題に直面することになります。通常、小さなファイルには高い IOPS 要件があります。より簡単な方法は、SATA ディスク (100 IOPS) を SAS ディスク (300 IOPS) または SSD ディスク (10,000 IOPS 以上) に置き換えて、より高い IOPS を取得することです。ただし、分散型ストレージの場合、キーがハッシュ化されるため、小さなファイルがどこに保存されるかはわかりません。現時点では、IOPS を向上させる唯一の方法は、すべてのマシンの機能を強化することです。たとえば、各マシンで 10 個の SATA ディスク、2 個の SAS ディスク、および 1 個の SSD ディスクがキャッシュ システム全体に追加され、システムの IOPS が向上しますが、全体的なコストと複雑さは大幅に増加します。もう 1 つの方法は、クラスターのサイズを可能な限り拡張して、全体的な IOPS 容量を自然に高くすることです。

同様の異種要件には、一部の顧客データのコピーを 2 つだけ保存し、他の顧客データのコピーを複数保存することが含まれますが、これは分散ストレージでは解決が困難です。

4. データの不一致の問題。たとえば、ハッシュに基づいてキーを上書きする場合は、ファイルを削除してから新しいファイルをアップロードすることになります。新しくアップロードされたファイルと以前のファイルは、同じディスク上の同じディレクトリで同じファイル名を使用します。上書き中に事故が発生し、3 つのコピーのうち 2 つまたは 1 つだけが上書きされた場合、誤ったデータが読み取られやすく、ユーザーは上書きは発生していないが元のデータが失われたと感じてしまいます。これは最も耐え難い問題です。解決策としては、ファイルを書き込むときに最初に一時ファイルを書き込み、最後に名前を変更して変更することです。ただし、分散アーキテクチャであり、複数のマシン間で動作するため、ロジックの複雑さが大幅に増加します。

簡単にまとめると、GlusterFS に代表される分散設計によって発生する問題の一部を次の図に示します。

集中型ストレージ設計: Hadoop

Hadoop は、大きなファイルを保存し、オフライン分析を実行し、優れたスケーラビリティを実現するように設計されています。 Hadoop のメタデータ ストレージ ノード (NameNode ノード) は、マスター スレーブ ストレージ モードに属します。データ アクセスのパフォーマンスを向上させるには、データをメモリにロードしてみてください。さらに、高可用性を放棄することで、メタデータの応答性がさらに向上します (NameNode の変更はスレーブに同期して更新されるのではなく、定期的なマージを通じて更新されます)。

Hadoop には次のような利点があります。

1. 大きなファイルを提供する。たとえば、ブロック サイズが 64 MB の場合、10 PB のファイルには 1 億 6000 万個のデータのみを保存する必要があります。各部分が 200 バイトの場合、約 32 GB のメモリが必要になります。メタデータの QPS はそれほど高くする必要はありません。各 QPS がファイル ブロックの読み取りと書き込みを提供できる場合、1000 QPS で 512Gb/s の読み取りおよび書き込み速度に到達でき、ほとんどのデータ センターのニーズを満たします。

2. オフラインビジネスに対応するために、高可用性サービスを部分的に犠牲にすることができます。

3. スケーラビリティを実現するために、ストレージ ノードはスケーリングできますが、メタデータ ノードはスケーリングする必要はありません。

しかし、このような設計上の利点を持つ Hadoop が、パブリック クラウド分野でのサービス提供には適していないのはなぜでしょうか。

1. メタデータの容量が小さすぎます。パブリック クラウド プラットフォームでは、1 億 6,000 万は非常に小さい数です。人気のあるインターネット アプリケーション 1 つあたりのデータは、それよりもはるかに多くなります。 1 億 6000 万個のデータは 32 GB のメモリを占有し、100 億個のデータは 2000 GB のメモリを必要とします。現時点では、Hadoop ではこれを処理できなくなりました。

2. メタ情報ノードはスケーリングできません。メタ情報は単一のサーバーに制限されており、単一マシンの容量 1,000 QPS または最適化された 15,000 QPS でも、パブリック クラウドのニーズを満たすにはほど遠いものです。

3. 高可用性は完璧ではありません。これは、前述した NameNode の問題です。業務量が大きすぎる場合、Hadoop では対応できません。

したがって、集中型クラウド ストレージを実行する場合、通常のアプローチでは、元の単一センター ノード設計を完全に放棄し、他の設計を導入します。

最も一般的なのは、データに対して複数のサンプルを準備する WRN アルゴリズムです。 W コピーの書き込みは成功したとみなされ、R コピーの読み取りは成功したとみなされます。 W+R は N より大きい (N はコピーの総数)。これにより、前述の高可用性の問題が解決されます。いずれかのレプリカがダウンしても、システム全体の読み取りと書き込みにはまったく影響がありません。

このシステムでは、このテクノロジを使用する際に注意すべき点がいくつかあります。

W、R、N はいくつ選択すればよいですか?

最初のオプションは 2、2、3 で、合計 3 つのコピーがあります。 2 つのコピーへの書き込みは成功し、2 つのコピーからの読み取りは成功したと見なされます。ただし、いずれかのマシンがオフラインになると、データを読み取ることができなくなり、データが使用できなくなります。

2 番目のオプションは 4、4、6 または 6、6、9 で、単一のマシン障害を許容できます。しかし、マシンの数が増えるほど、平均応答時間は長くなります。

書き込みに失敗するとデータが破損する可能性がある

たとえば、4、4、6 のシナリオでは、3 つのコピーのみが正常に書き込まれた場合、書き込み操作は失敗したと見なされます。ただし、書き込みによって元のメタデータが上書きされると、正しいデータのコピーが 3 つ、誤ったデータのコピーが 3 つ存在することになります。そのため、どのデータのコピーが正しいか、どのデータのコピーが誤りかを判別することは不可能になります。これを回避する方法は、データをバージョン付きで書き込む（上書きではなく追加のみ）、つまり、データベースに新しいデータを挿入することです。クラウド ストレージの使用方法の中には、M3U8 ファイルを使用したライブ ストリーミングなど、ファイルを繰り返し変更する必要があるものもあります。ライブ放送が進むにつれて、ファイルは約 5 秒ごとに継続的に変更されます。 1 時間以内に、ファイルは 720 回変更されます。この時点で、データベースからファイル情報を読み取るときに、1 レコードではなく、マシンごとに 720 レコードを読み取ることになり、データベースのパフォーマンスのボトルネックが発生しやすくなります。

以下では、Hadoop に代表される集中型ストレージ設計に存在する問題を簡単にまとめます。

データベースに基づく分散ストレージ設計: GridFS、HBase

グリッドFS

GridFS は、ファイル ストレージ システムと同等の MongoDB に基づいています。各ブロックサイズが 255KB のブロック ストレージ形式です。データは 2 つのテーブルに保存されます。1 つはチャンクで、メタデータを追加した後の 1 つのレコードは 256 KB 以内になります。もう 1 つは、ファイルのメタデータを保存するファイルです。

GridFS の利点については以下に説明します。

1. データベースとファイルの永続性の 2 つの要件を同時に満たすことができます。ほとんどのアプリケーションのデータベース データは永続化する必要があり、ユーザーがアップロードした写真も永続化する必要があります。 GridFS は 1 セットの設備でこれらのニーズを満たすことができるため、全体的な運用・保守コストと機械調達コストを削減できます。

2. オンライン ストレージ、高可用性、スケーラビリティ、データ センター間のバックアップなど、MongoDB のすべての利点を備えています。

3. 削除時にスペースを解放できる Range GET をサポートします (スペースを解放するには MongoDB の定期的なメンテナンスが必要です)。

GridFS の欠点については以下で説明します。

1. oplog が使い果たされました。 Oplog は MongoDB 上のすべての操作を記録する MongoDB 上の固定サイズのテーブルです。 MongoDB の ReplicaSet の同期は oplog に依存します。通常、oplog のサイズは約 5 GB ～ 50 GB で、24 時間のデータベース変更操作をサポートするのに十分です。ただし、 GridFSに使用する場合、複数の大きなファイルを書き込むと oplog がすぐに使い果たされ、セカンダリ マシンが対応できなくなり、手動で修復する必要が生じる可能性があります。ご存知のとおり、MongoDB の修復には非常に時間がかかり、労力がかかります。簡単に言えば、これはデータベースの設計コンセプトに関連する耐衝撃性の低さです。結局のところ、これはファイルの保存用に設計されたものではありません。手動修復によって引き起こされる問題に加えて、影響によりマスター データベースとスレーブ データベース間の差異も拡大し、読み取りと書き込みの分離、または二重書き込みしてから返すなどの使用シナリオに大きな課題が生じます。

2. メモリの誤用。 MongoDB は MMAP を使用してディスク ファイルをメモリにマップします。 GridFS の場合、ほとんどのシナリオでは、ファイルの読み取りと書き込みは 1 回だけ行う必要があります。このようなシナリオを最適化する方法はなく、結果としてメモリが大量に浪費され、通常のメモリ使用量を必要とするデータ (インデックスなど) が排除されることになります。これも設計インピーダンスの不一致によって発生する問題です。

3. スケーラビリティの問題。スケーラビリティが必要な場合は、MongoDB シャーディングを導入し、シャーディングに files_id を使用する必要があります。プログラムが変更されない場合、files_id が増加し、すべての書き込みは均等に分散されるのではなく、最後のノード グループにプッシュされます。この場合、ドライバーを書き直し、新しい files_id 生成方法を導入する必要があります。さらに、高容量の圧力下での MongoDB Sharding の運用と保守は苦痛です。 MongoDB シャーディングを分割する必要があり、分割中に応答が非常に悪くなるため、サービス全体が利用できなくなります。

GridFSの概要は以下のとおりです。

HBase

前述したように、Hadoop は NameNode の容量の問題により、小さなファイルの保存には適していません。では、HBase は適しているのでしょうか?

HBase には以下の利点があります。

1. スケーラビリティと高可用性は最下層で解決されます。

2. 容量が非常に大きく、上限はほとんどありません。

しかし、最も重大であるのは欠点です。 HBase には以下の欠点があります。

1. 微妙なユーザビリティの問題。 1 つ目は、Hadoop NameNode の高可用性です。次に、HBase データはリージョンに配置されるため、リージョン分割が発生する可能性があります。分割および結合プロセス中は、リージョンは使用できません。ユーザーがデータを読み書きするかどうかに関係なく、問題は失敗します。この問題は事前分割によって回避できますが、全体のサイズが事前にわかっていて、キーの分布がほぼ均一であることが必要です。マルチユーザー シナリオでは、キーが順序どおりに並べられる必要があるという要件を放棄しない限り、均一なキー配布を実現することは困難です。

2. 大容量ファイルのサポート。 HBase は 10 MB を超える大きなファイルを適切にサポートしていません。改善されたソリューションは、データを大きなファイルに連結し、HBase がファイル名、オフセット、サイズのみを保存することです。この改善計画はより現実的ですが、スペースの回復という点で多くの開発作業が必要になります。

解決策は、メタデータの保存に HBase を使用し、データの保存に Hadoop を使用することです。しかし、Hadoop はオフラインでの使用を想定して設計されており、NameNode の高可用性が十分に考慮されていません。 HBase のリージョン分割とマージにより、一時的に利用できなくなります。可能であれば事前に分割するのが最善ですが、事前分割にも問題があります。このソリューションは、可用性の要件が低い場合に適しています。

問題を回避するストレージ設計: FastDFS

Hadoop の問題は NameNode に過度の負荷がかかっていることです。そのため、FastDFS の考え方は NameNode への負荷を軽減することです。解凍方法は、NameNode 情報をキーにエンコードすることです。例の URL: group1/M00/00/00/rBAXr1AJGF_3rCZAAAAEc45MdM850_big.txt の場合、NameNode が実行する必要があるのは、group1 を特定のマシン名に変換することだけです。キーの場所を気にする必要はなく、グループ情報の場所だけを気にすればよいのです。グループ情報はキー内に配置され、以前の問題を回避します。

FastDFS の利点は次のとおりです。

1. シンプルな構造と低いメタデータノードの圧力。

2. 拡張は簡単で、拡張後に再バランス調整は必要ありません。

FastDFS の欠点は次のとおりです。

1. キーをカスタマイズできないため、マルチテナントには致命的な打撃となり、自分で使用すると柔軟性も低下します。

2. 修復速度: ディスクイメージの配布、修復速度はディスクの書き込み速度に依存します。たとえば、書き込み速度が 100MB/秒の 4TB ディスクの場合は、少なくとも 11 時間かかります。

3. 大きなファイルの影響の問題は解決されていません。まず、ファイル サイズには制限があります (ディスク サイズを超えることはできません)。 2 つ目は、大きなファイルが断片化されないため、大きなファイルの読み取りと書き込みが 1 つのディスクで処理され、ディスク ネットワークに大きな影響を与えます。

要約する

いくつかのストレージ設計は次のようにまとめることができます。