分散アプリケーションの構成要素。 二次近似

お知らせ

同僚の皆さん、夏の半ばに、キューイング システムの設計に関する別の記事シリーズ、「VTrade Experiment」、つまりトレーディング システムのフレームワークを作成する試みを公開する予定です。 このシリーズでは、取引所、オークション、ストアを構築する理論と実践を検討します。 記事の最後で、最も興味のあるトピックに投票してください。

これは、Erlang/Elixir の分散リアクティブ アプリケーションに関するシリーズの最後の記事です。 で 最初の記事 リアクティブ アーキテクチャの理論的基礎を見つけることができます。 XNUMX番目の記事 は、そのようなシステムを構築するための基本的なパターンとメカニズムを示しています。

今日は、コードベースの開発とプロジェクト全般の問題について取り上げます。

サービスの構成

実際には、サービスを開発するとき、多くの場合、XNUMX つのコントローラーで複数の対話パターンを組み合わせる必要があります。 たとえば、プロジェクト ユーザー プロファイルの管理の問題を解決するユーザー サービスは、req-resp リクエストに応答し、pub-sub 経由でプロファイルの更新を報告する必要があります。 このケースは非常に単純です。メッセージングの背後には、サービス ロジックを実装し、更新を公開する XNUMX つのコントローラーがあります。

フォールトトレラントな分散サービスを実装する必要がある場合、状況はさらに複雑になります。 ユーザーの要件が変更されたと想像してみましょう。

1. これで、サービスは 5 つのクラスター ノードでリクエストを処理する必要があります。
2. バックグラウンド処理タスクを実行できる、
3. また、プロファイル更新のためのサブスクリプション リストを動的に管理することもできます。

注： 一貫したストレージとデータのレプリケーションの問題は考慮していません。 これらの問題は以前に解決されており、システムには信頼性とスケーラブルなストレージ層がすでにあり、ハンドラーにはそれと対話するメカニズムがあると仮定しましょう。

ユーザーサービスの正式な説明はさらに複雑になっています。 プログラマの観点から見ると、メッセージングを使用するため、変更は最小限に抑えられます。 最初の要件を満たすには、req-resp 交換ポイントでバランシングを構成する必要があります。

バックグラウンド タスクを処理する必要性が頻繁に発生します。 ユーザーの場合、これはユーザー文書のチェック、ダウンロードされたマルチメディアの処理、またはソーシャル メディアとのデータの同期などです。 ネットワーク。 これらのタスクはクラスター内で何らかの方法で分散され、実行の進行状況が監視される必要があります。 したがって、解決策のオプションは XNUMX つあります。前の記事のタスク分散テンプレートを使用するか、それが適さない場合は、必要な方法でプロセッサのプールを管理するカスタム タスク スケジューラを作成します。

ポイント 3 では、pub-sub テンプレート拡張機能が必要です。 実装するには、パブリッシュ/サブスクライブ交換ポイントを作成した後、サービス内でこのポイントのコントローラーを追加で起動する必要があります。 したがって、サブスクリプションとサブスクリプション解除を処理するロジックをメッセージング層からユーザーの実装に移動しているかのようです。

その結果、問題を分解すると、要件を満たすためには、異なるノードでサービスの 5 つのインスタンスを起動し、サブスクリプションを担当する追加のエンティティ (パブリッシュ/サブスクライブ コントローラー) を作成する必要があることがわかりました。
5 つのハンドラーを実行する場合、サービス コードを変更する必要はありません。 唯一の追加アクションは、交換ポイントでバランシング ルールを設定することです。これについては後ほど説明します。
さらに複雑さも加わります。pub-sub コントローラーとカスタム タスク スケジューラーは単一のコピーで動作する必要があります。 繰り返しになりますが、メッセージング サービスは、基本的なものとして、リーダーを選択するためのメカニズムを提供する必要があります。

リーダーの選択

分散システムでは、リーダーの選出は、何らかの負荷の分散処理のスケジュールを担当する単一のプロセスを任命する手順です。

集中化が起こりにくいシステムでは、paxos や raft などの普遍的なコンセンサスベースのアルゴリズムが使用されます。
メッセージングは​​ブローカーであり中心的な要素であるため、すべてのサービス コントローラー、つまりリーダー候補について知っています。 メッセージングでは投票せずにリーダーを任命できます。

開始して交換ポイントに接続すると、すべてのサービスがシステム メッセージを受信します。 #'$leader'{exchange = ?EXCHANGE, pid = LeaderPid, servers = Servers}。 もし LeaderPid と一致する pid 現在のプロセスでは、リーダーに任命され、リストに Servers すべてのノードとそのパラメータが含まれます。
新しいノードが表示され、動作中のクラスター ノードが切断された瞬間に、すべてのサービス コントローラーは #'$slave_up'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} и #'$slave_down'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} それぞれ。

このようにして、すべてのコンポーネントがすべての変更を認識し、クラスターには常に XNUMX つのリーダーが存在することが保証されます。

メディエータ

複雑な分散処理プロセスを実装するには、既存のアーキテクチャの最適化の問題と同様に、仲介者を使用すると便利です。
サービス コードを変更せずに、たとえば追加の処理、メッセージのルーティング、またはログ記録の問題を解決するには、サービスの前にプロキシ ハンドラーを有効にして、すべての追加作業を実行します。

パブリッシュ/サブスクライブ最適化の典型的な例は、市場の価格変動などの更新イベントを生成するビジネス コアと、Web クライアントに WebSocket API を提供するアクセス層である N サーバーを備えた分散アプリケーションです。
正面から判断した場合、顧客サービスは次のようになります。

• クライアントはプラットフォームとの接続を確立します。 トラフィックを終了するサーバー側で、この接続にサービスを提供するプロセスが起動されます。
• サービス プロセスのコンテキストで、更新の承認とサブスクリプションが発生します。 このプロセスでは、トピックの submit メソッドを呼び出します。
• イベントがカーネルで生成されると、接続を処理するプロセスに配信されます。

「ニュース」トピックに 50000 人の購読者がいると想像してみましょう。 サブスクライバーは 5 つのサーバーに均等に分散されます。 その結果、交換ポイントに到着する各更新は 50000 回複製されます。つまり、サブスクライバーの数に応じて、各サーバー上で 10000 回複製されます。 あまり効果的な計画ではありませんね?
この状況を改善するには、交換ポイントと同じ名前のプロキシを導入しましょう。 グローバル ネーム レジストラは、名前で最も近いプロセスを返すことができなければなりません。これは重要です。

このプロキシをアクセス層サーバー上で起動しましょう。WebSocket API を提供するすべてのプロセスは、カーネル内の元のパブリッシュ/サブスクリプション交換ポイントではなく、このプロキシをサブスクライブします。 プロキシは、一意のサブスクリプションの場合にのみコアをサブスクライブし、受信メッセージをすべてのサブスクライバーに複製します。
その結果、カーネル サーバーとアクセス サーバーの間で 5 メッセージではなく 50000 メッセージが送信されます。

ルーティングとバランシング

要求-応答

現在のメッセージング実装には、次の 7 つのリクエスト分散戦略があります。

• default。 リクエストはすべてのコントローラーに送信されます。
• round-robin。 リクエストは列挙され、コントローラー間で周期的に分散されます。
• consensus。 サービスを提供するコントローラーは、リーダーとスレーブに分けられます。 リクエストはリーダーにのみ送信されます。
• consensus & round-robin。 グループにはリーダーがいますが、リクエストはメンバー全員に分散されます。
• sticky。 ハッシュ関数が計算され、特定のハンドラーに割り当てられます。 この署名を持つ後続のリクエストは同じハンドラーに送られます。
• sticky-fun。 交換ポイントの初期化時に、ハッシュ計算関数が sticky バランスをとること。
• fun。 Sticky-Fun と同様に、追加でリダイレクト、拒否、または前処理できるのはユーザーだけです。

配布戦略は、交換ポイントが初期化されるときに設定されます。

バランスをとるだけでなく、メッセージングを使用するとエンティティにタグを付けることができます。 システム内のタグの種類を見てみましょう。

• 接続タグ。 イベントがどのような接続を通じて発生したかを理解できます。 コントローラー プロセスが同じ交換ポイントに接続するが、異なるルーティング キーを使用する場合に使用されます。
• サービスタグ。 ハンドラーを XNUMX つのサービスのグループに結合し、ルーティングおよびバランシング機能を拡張できます。 req-resp パターンの場合、ルーティングは直線的です。 リクエストを交換ポイントに送信し、交換ポイントがそれをサービスに渡します。 ただし、ハンドラーを論理グループに分割する必要がある場合、分割はタグを使用して行われます。 タグを指定すると、リクエストはコントローラーの特定のグループに送信されます。
• リクエストタグ。 回答を区別できるようになります。 私たちのシステムは非同期であるため、サービス応答を処理するには、リクエストの送信時に RequestTag を指定できる必要があります。 そこから、私たちに寄せられたリクエストに対する答えを理解することができます。

パブリッシュ/サブスク

パブサブの場合は、すべてが少し単純になります。 メッセージが公開される交換ポイントがあります。 交換ポイントは、必要なルーティング キーを購読しているサブスクライバー間でメッセージを配布します (これはトピックに似ていると言えます)。

スケーラビリティと耐障害性

システム全体のスケーラビリティは、システムのレイヤーとコンポーネントのスケーラビリティの程度によって異なります。

• サービスは、このサービスのハンドラーを備えたクラスターに追加のノードを追加することによって拡張されます。 試用時に最適なバランスポリシーを選択できます。
• 別のクラスター内のメッセージング サービス自体は通常、特に負荷の高い交換ポイントを別のクラスター ノードに移動するか、クラスターの特に負荷の高い領域にプロキシ プロセスを追加することによって拡張されます。
• システム全体の特性としてのスケーラビリティは、アーキテクチャの柔軟性と、個々のクラスターを共通の論理エンティティに結合する能力に依存します。

プロジェクトの成功は、多くの場合、スケーリングのシンプルさと速度に依存します。 現在のバージョンのメッセージングは​​、アプリケーションとともに成長します。 50 ～ 60 台のマシンのクラスターが不足している場合でも、フェデレーションに頼ることができます。 残念ながら、フェデレーションのトピックはこの記事の範囲を超えています。

予約

負荷分散を分析する際に、サービス コントローラーの冗長性についてはすでに説明しました。 ただし、メッセージングも予約する必要があります。 ノードまたはマシンがクラッシュした場合、メッセージングは​​可能な限り最短時間で自動的に回復する必要があります。

私のプロジェクトでは、転倒時に荷重を拾う追加のノードを使用しています。 Erlang には、OTP アプリケーション用の標準分散モード実装があります。 分散モードでは、障害が発生した場合に、以前に起動した別のノードで障害が発生したアプリケーションを起動することによってリカバリを実行します。 このプロセスは透過的であり、障害が発生すると、アプリケーションは自動的にフェイルオーバー ノードに移動します。 この機能の詳細については、こちらをご覧ください ここで.

Производительность

少なくとも、rabbitmq とカスタム メッセージングのパフォーマンスを大まかに比較してみましょう。
見つけました 公式結果 openstack チームによる Rabbitmq テスト。

6.14.1.2.1.2.2項。 元のドキュメントには、RPC CAST の結果が示されています。

事前に OS カーネルやアーラン VM に追加の設定を行うことはありません。 テストの条件:

• erl オプション: +A1 +sbtu。
• 単一の erlang ノード内のテストは、モバイル バージョンの古い i7 を搭載したラップトップで実行されます。
• クラスター テストは、10G ネットワークを備えたサーバーで実行されます。
• コードは Docker コンテナ内で実行されます。 NAT モードのネットワーク。

テストコード:

req_resp_bench(_) ->
  W = perftest:comprehensive(10000,
    fun() ->
      messaging:request(?EXCHANGE, default, ping, self()),
      receive
        #'$msg'{message = pong} -> ok
      after 5000 ->
        throw(timeout)
      end
    end
  ),
  true = lists:any(fun(E) -> E >= 30000 end, W),
  ok.

シナリオ1： テストは、古い i7 モバイル バージョンを搭載したラップトップで実行されます。 テスト、メッセージング、およびサービスは、XNUMX つの Docker コンテナー内の XNUMX つのノードで実行されます。

Sequential 10000 cycles in ~0 seconds (26987 cycles/s)
Sequential 20000 cycles in ~1 seconds (26915 cycles/s)
Sequential 100000 cycles in ~4 seconds (26957 cycles/s)
Parallel 2 100000 cycles in ~2 seconds (44240 cycles/s)
Parallel 4 100000 cycles in ~2 seconds (53459 cycles/s)
Parallel 10 100000 cycles in ~2 seconds (52283 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (49317 cycles/s)

2スクリプト: Docker (NAT) 下の異なるマシン上で実行されている 3 つのノード。

Sequential 10000 cycles in ~1 seconds (8684 cycles/s)
Sequential 20000 cycles in ~2 seconds (8424 cycles/s)
Sequential 100000 cycles in ~12 seconds (8655 cycles/s)
Parallel 2 100000 cycles in ~7 seconds (15160 cycles/s)
Parallel 4 100000 cycles in ~5 seconds (19133 cycles/s)
Parallel 10 100000 cycles in ~4 seconds (24399 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (34517 cycles/s)

すべてのケースで、CPU 使用率は 250% を超えませんでした。

結果

このサイクルがマインドダンプのように見えないことを願っています。私の経験が、分散システムの研究者と、ビジネス システム用の分散アーキテクチャの構築のまさに初期段階にあり、Erlang/Elixir に興味を持っている実践者の両方にとって真の利益となることを願っています。 、しかし、それだけの価値があるかどうか疑問があります...

フォト @chuttersnap

登録ユーザーのみがアンケートに参加できます。 ログインお願いします。

VTrade Experiment シリーズの一環として、どのようなトピックをさらに詳しく取り上げるべきですか?

• 理論: 市場、注文、およびそのタイミング: DAY、GTD、GTC、IOC、FOK、MOO、MOC、LOO、LOC

• 注文書。 グループ化を使用して書籍を実装する理論と実践

• 取引の視覚化: ティック、バー、解像度。 保存方法と貼り方

• バックオフィス。 企画・開発。 従業員の監視とインシデント調査

• API。 どのようなインターフェースが必要なのか、そしてそれらを実装する方法を考えてみましょう

• 情報ストレージ: 取引システムにおける PostgreSQL、Timescale、Tarantool

• 取引システムの反応性

• 他の。 コメントに書きます

6 人のユーザーが投票しました。 4名のユーザーが棄権した。

出所： habr.com