分散システムアーキテクチャの1つであるマスターワーカーアーキテクチャ

[[409063]]

この記事はWeChatの公開アカウント「Mu Niao雑記」から転載したもので、著者はMunioです。この記事を転載する場合は、Mu Niao Za Ji の公開アカウントにご連絡ください。

分散システムには、デザイン パターンとも呼ばれる古典的なルーチンが数多くあります。各デザイン パターンは、典型的なタイプの問題を解決できます。それらを蓄積していくと、わずかな変更やトレードオフを行い、ニーズを満たすアーキテクチャ構成を設計できるようになります。しかし、この点に関して経験を共有している人はあまり多くないようですので、後ほど仕事や勉強の経験をメモとしてまとめ、皆さんの参考になればと思います。スペースと能力が限られているため、すべてを網羅することが困難であったり、正確さに欠ける場合があります。不適切な部分がありましたら、遠慮なくご指摘ください。

各記事は、概要の背景、アーキテクチャ モジュール、概要の拡張ごとに個別に分析されます。この記事は最初の記事です: Master-Workers アーキテクチャ。

概要

マスター ワーカー アーキテクチャ (大まかに言えば、マスター スレーブ アーキテクチャ) は、GFS のマスター サーバーやチャンク サーバーなどの分散システムで一般的な組織化方法です。 MapReduce のマスターとワーカー。分散システム内の多数の個別のマシン リソースに直面すると、マスター スレーブ アーキテクチャは最も自然で直接的な組織化方法です。これは、人々のグループと同様に、この人々のグループの外部出力機能を最大化するために、組織化と調整の最終決定権を持つリーダーが存在します。

これは、コンピュータ システムで一般的な分割統治の考え方を反映したものでもあります。つまり、複雑なシステムは、明確な機能境界と相互作用インターフェースを持つ、比較的凝集性が高く結合度の低いいくつかのサブモジュールに分割され、システムの理解、保守、拡張が容易になります。マスタースレーブアーキテクチャの場合、マスターは通常、クラスターのメタデータを維持し、スケジューリングにはこのメタデータを使用します。ワーカーは通常、特定のデータ スライスの読み取りと書き込み (ストレージ システム) を担当したり、サブタスクの実行ユニットとして機能したり (コンピューティング システム) します。

アーキテクチャモジュール

マスタースレーブアーキテクチャシステムは通常、単一のマスターと複数のワーカーで構成されます。ちなみに、ここでの英訳でSlaveを使わなかったのは、Workerの方が中立的だと思うからです。もちろん、単一のマスターではパフォーマンスのボトルネックや可用性の問題が発生するため、通常は複数の解決策がありますが、これについては後で詳しく説明します。しかし、単一のマスターの利点は明らかです。マスターは制御ノードとして、複数のコピーによって生じる一貫性の問題に対処する必要がないため、実装の難しさが大幅に軽減されます。

私がよく知っているストレージ システムのアーキテクチャを例にとると、そのアーキテクチャ図は通常次のようになります。

マスターワーカーアーキテクチャ

システム内のマスターとワーカーに加えて、システムを使用する外部ユーザーも存在します。通常、これをクライアントと呼びます。クライアントは、システムによって公開されるインターフェース (RPC、HTTP など) を介してシステムと対話します。

マスター

マスターは通常、システムのメタ情報を保存します。メタ情報とは何ですか?これは、マスターの頭の中にあるクラスター構成情報の反映、またはビューとして理解できます。たとえば、クラスター内にワーカーがいくつあるか、各ワーカーの残り容量はどれくらいか、負荷はどれくらいか、どのワーカーがどのデータを保存しているか、などです。

メタ情報はどのように収集されますか?主な状況は 2 つあります。

1. 構成。これは、システムに最初に存在するワーカーの数、ワーカーの物理トポロジ、各ワーカーの容量など、クラスターの静的情報として理解できます。マスターは起動時にこの構成情報をロードします。
2. 報告。主にクラスターの動的情報が含まれます。ワーカーが実行中の場合、ワーカーがアクティブであるかどうか、ワーカーの負荷情報、ワーカーが保存するデータなど、ワーカーの状態がマスターに積極的に報告されます。システムの実行中、ワーカーはハートビートやその他の方法を通じてマスターに定期的に報告します。

このメタデータにより、マスターはクラスター全体を十分に理解し、一連の決定を下すことができます。以下にいくつか例を挙げます。

1. スケジュール。新しいデータ書き込み要求が届いた場合、どのワーカーを割り当てる必要がありますか?通常は、負荷の少ないワーカーが選択されます。
2. バランス。ワーカーが変更され、データが追加または削除されると、データがマシン間で均等に分散されなくなり、一部のマシンで読み取り/書き込みのホットスポットが発生し、他のマシンでリソースが無駄になり、システム全体のパフォーマンスに影響する可能性があります。したがって、リアルタイムの監視とタイムリーな移行が必要です。
3. ルーティング（位置特定/ルート）。読み取りまたは書き込み要求が届いたが、マスターがどのワーカーを見つけるべきかわからない場合、マスターはメタデータを照会し、対応するデータのワーカー情報を提供します。

マスターの可用性

システム全体の可用性はマスターに完全に依存していることがわかります。業界には次のような多くのソリューションもあります。

1. プライマリとバックアップを使用します。つまり、マスターのクローンを作成し、バックアップ マスターのすべてのメタデータが常にメイン マスターと一致している必要があります。メインマスターが切断されると、クローンがすぐに追いつきます。 Hadoop は後にこれを実現しました。
2. コンセンサスアルゴリズムを使用します。簡単に言えば、マスター マシンのグループが委員会を形成し、各状態の変更は特定のアルゴリズムを通じて合意に達する必要があります。これが Google の Spanner の機能です。
3. 所有者なし。システムにはマスターは存在せず、全員が平等であり、作業はコンシステント ハッシュなどの何らかの戦略を通じて分割されます。これが Amazon の Dynamo の機能です。

各戦略は比較的大きなトピックであり、将来的には別の記事で説明される可能性があります。スペースの制限により、この記事では詳しく説明しません。

労働者

ストレージ システムでは、ワーカーが実際のデータを保存し、外部にデータ IO サービスを提供します。

スタンドアロンの観点から見ると、Worker はビジネス ニーズを満たし、データを効率的に保存するスタンドアロン エンジンを設計する必要があります。スタンドアロン エンジンの設計も大きなトピックなので、ここで簡単に触れておきます。

1. インデックス設計: B+ ツリー、LSM ツリー、ハッシュ インデックスなど。
2. 基盤となるシステム: RAW ディスクを使用するか、ファイル システムを使用するか。
3. ストレージ メディア: 永続メモリ、ソリッド ステート ドライブ、または機械式ハード ドライブのいずれを使用するか。

複数マシンの観点から見ると、マシンの数が増えるにつれて、システム内の単一マシンの障害の可能性が大幅に増加します。この正規化された障害に対処するには、次のことが必要です。

運用と保守の自動化。マシンが使用できなくなった場合は、自動的に削除され、修理後にすぐにオンラインに戻る必要があります。

データの冗長性。マシン障害後にデータが失われないように、各データを複数のコピーで保存し、冗長性のために EC アルゴリズムを使用する必要があります。

まとめ

マスターワーカーアーキテクチャは、分散システムで最も一般的に使用される組織化方法です。このアーキテクチャは、人間のコミュニティが組織される方法に似ています。システムの役割は次の部分に分かれています: マスターはメタデータを収集し、それに応じてタスクをスケジュールします。ワーカーは実際の作業負荷を担当し、効率的なスタンドアロン エンジンとグローバルな冗長性の設計を必要とします。アーキテクチャはシンプルでわかりやすいですが、強力です。