スレーブ/プール モジュールを見ていましたが、私が望むものと似ているように見えますが、アプリケーションに単一障害点があるようにも見えます (マスター ノードがダウンした場合)。
クライアントには、接続を受け入れるゲートウェイのリストがあり (フォールバックのために - すべて同じことを行います)、クライアントによってランダムに 1 つが選択されます。クライアントが接続すると、すべてのノードが検査され、負荷が最小のノードが特定され、負荷が最小のサーバーの IP がクライアントに戻されます。その後、クライアントはこのサーバーに接続し、そこですべてが実行されます。
要約すると、すべてのノードが両方のゲートウェイとして機能し、クライアントの要求を実際に処理する必要があります。ロード バランシングは、クライアントが最初に接続したときにのみ実行されます。実際のパケットはすべて、クライアントの「ホーム」ノードで処理されます。
どうすればいいですか？
このモジュールがまだ実装されているかどうかはわかりませんが、負荷分散が過大評価されていると言えます。私が主張できるのは、将来どのように負荷がかかるかについてはるかに多くの情報を知っていない限り、ランダムにジョブを配置するのが最善であり、ほとんどの場合、実際にはそうではありません。何を書きましたか：
クライアントが接続すると、すべてのノードが調べられ、負荷が最も低いノードが確認されます。次に、負荷が最も低いサーバーのIPがクライアントに転送されます。
これらの最も負荷の少ないノードが、次のミリ秒で最も負荷が高くなるわけではないことをどうやって知っていますか？リストに含めない高負荷のノードがすべて、次のミリ秒で負荷を落とさないことをどのように知っていますか？非常にまれなケースがない限り、あなたは本当にそれを知ることができません。
ノードのパフォーマンスを測定（または計算）し、それに応じて選択されるノードの確率を設定するだけです。現在の負荷に関係なく、ノードをランダムに選択します。これを最初のアプローチとして使用します。それを設定すると、より洗練されたアルゴリズムを作成してみることができます。この最初のアプローチを打ち負かすのは非常に難しい作業になると思います。私を信じて、とても大変です。
編集：1つの微妙な詳細をより明確にするために、現在および過去の負荷から将来の負荷を予測することはできないが、タスク期間の確率とタスクの存続期間の現在の分解に関する知識を使用する必要があることを強く主張します。この仕事を成し遂げるのはとても難しいです。
監視ツリーの目的は、必ずしもリクエストを転送しないプロセスを管理することです。別のコードを使用して、使用可能なプロセスのリストのメンバーに直接リクエストを送信できない理由はありません。これらのリストを取得する 1 つの方法については、pool:get_nodes または pool:get_node() 関数を参照してください。
プール モジュールにプロセスの管理 (再起動、監視、強制終了) を処理させ、他のモジュールを使用して要求をプロセスのプールに透過的にリダイレクトすることができます。分散プールを探していたのではないでしょうか? 分散ノードに行かずに、erlang のマスター プロセスから逃れるのは難しいでしょう。実行中のシステム全体は、ほぼ 1 つの大きな監視ツリーです。
最近、プロセスグループをセットアップできる pg モジュールを思い出しました。グループに送信されたメッセージは、グループ内のすべてのプロセスに送られます。それはあなたが望むものの途中にあなたを導くかもしれません. どのプロセスがリクエストを実際に処理するかを決定するコードを作成する必要がありますが、マスターがそれを使用せずにプールを取得します。