Discordは最初からElixirを積極的に使用しています。 Erlang仮想マシンは、作成を計画していた高度に並列なリアルタイムシステムを作成するための理想的な候補でした。 オリジナルのDiscordプロトタイプはElixirで開発されました。 今ではインフラストラクチャの基礎になっています。 Elixirの使命と目的は簡単です。より近代的で使いやすい言語とツールキットを使用して、Erlang VMの全機能にアクセスしてください。

二年が経ちました。 現在、 500万の同時ユーザーがあり 、 1秒あたり数百万のイベントがシステムを通過しています。 アーキテクチャの選択を絶対に後悔していませんが、この結果を達成するために多くの研究と実験を行わなければなりませんでした。 Elixirは新しいエコシステムであり、Erlangエコシステムには生産での使用に関する情報がありません（ただし、AngerのErlangは何かです）。 ElixirをDiscordで動作するように適合させようと試みた全体の旅の結果、いくつかの教訓を学び、いくつかのライブラリを作成しました。

メッセージのファン展開

Discordには多くの機能がありますが、基本的にはpub / subにな​​ります。 ユーザーはWebSocketに接続してセッション（GenServer）を解き、ギルドプロセス（GenServerも）が機能するリモートErlangノードとの接続を確立します。 ギルドで何かが公開されている場合（内部の命名規則は「Discord Server」です）、接続されているすべてのセッションでファンアウトします。



ユーザーがオンラインになると、ユーザーはギルドに接続し、接続されている他のすべてのセッションでプレゼンスのステータスを公開します。 他にも多くのロジックがありますが、簡単な例を次に示します。

def handle_call({:publish, message}, _from, %{sessions: sessions}=state) do Enum.each(sessions, &send(&1.pid, message)) {:reply, :ok, state} end 

これは、25人以下のユーザーのグループに対してDiscordを最初に作成したときの通常のアプローチでした。 しかし、 大勢の人々がDiscordを使い始めたとき、私たちは幸運にも成長の「良い問題」に遭遇しました。 その結果、 / r / Overwatchのような多くのDiscordサーバーには、一度に最大30,000人のユーザーがいるという結論に達しました。 ピーク時に、これらのプロセスはメッセージキューに対応できないことがわかりました。 ある時点で、負荷に対処するために、メッセージ生成機能を手動で介入して無効にする必要がありました。 この問題が広まる前に対処する必要がありました。

ギルドプロセス内で最も忙しいパスのベンチマークから始め、すぐにトラブルの明らかな原因を明らかにしました。 Erlangプロセス間でのメッセージの交換は、私たちに思えるほど効率的ではありませんでした。また、Erlangのプロセスシェディングの作業単位も非常に高価でした。 Erlangコールプロセスのスケジュール解除により、1回のsend/2コールの時間は30μsから70μsの間で変化することがわかった。 これは、ピーク時に、大きなギルドから1つのイベントを公開するのに900ミリ秒から2.1秒かかることを意味していました！ Erlangプロセスは完全にシングルスレッドであり、シャードが唯一の並列化オプションであると思われました。 このようなイベントにはかなりの努力が必要であり、より良い選択肢があることを知っていました。

メッセージを送信する作業を何らかの形で分散させる必要がありました。 Erlangの生成プロセスは安価であるため、最初に考えたのは、公開する各投稿を処理する新しいプロセスを単純に生成することでした。 ただし、すべてのパブリケーションは異なるタイミングで発生する可能性があり、Discordクライアントはイベントの線形化可能性に依存します。 さらに、そのようなソリューションは、ギルドサービスがますます多くの作業になっているため、うまくスケーリングできません。

ノード間のメッセージ受け渡しのパフォーマンスの改善に関するブログ投稿に触発されて、 Manifoldを作成しました。 マニホールドは、PID（Erlangのプロセス識別子）を使用してリモートノード間でメッセージを送信する作業を分散します。 これにより、配布プロセスは、リモートノードが関係する回数だけsend/2を呼び出しsend/2 。 Manifoldは、まずリモートノードでPIDをグループ化し、次にこれらの各ノードのManifold.Partitioner 「セパレータ」に送信します。 次に、区切り文字は:erlang.phash2/2を使用してPIDを順次ハッシュし、コアの数でグループ化し、子ワーカーに送信します。 最終的に、ワーカーは実際のプロセスにメッセージを送信します。 これにより、区切り文字が過負荷にならず、 send/2ようsend/2線形化可能性が引き続き提供されます。 このソリューションはsend/2効果的な代替となりました。

 Manifold.send([self(), self()], :hello) 

Manifoldの顕著な副作用は、ファンメッセージのCPU負荷を分散するだけでなく、ノード間のネットワークトラフィックを削減することもできたことです。


ノードギルドあたりのネットワークトラフィックの削減

マニホールドはGitHubにありますので、試してみてください。

一般的なクイックアクセスデータ

Discordは、 一貫したハッシュを使用する分散システムです。 この方法を使用するには、特定のオブジェクトのノードを検索するために使用できるリングデータ構造を作成する必要がありました。 システムをすばやく動作させたかったので、Erlang Cポート（Cコードとのインターフェイスを担当するプロセス）を介して接続することにより 、すばらしいChris Musライブラリを選択しました。 うまくいきましたが、Discordの規模が拡大するにつれて、ユーザーの再接続に伴う爆発の際に問題に気付き始めました。 リングの管理を担当するErlangプロセスは、リングへの要求に対応できず、システム全体が負荷に対応できなかったため、作業が非常に多くなり始めました。 一見すると、ソリューションは明らかなように見えました。すべての要求を処理するために、マシンのすべてのコアを最大限に活用するために、リングデータを使用して多くのプロセスを起動します。 しかし、これは非常に重要な作業です。 より良いオプションはありますか？



コンポーネントを見てみましょう。

• ユーザーは任意の数のギルドに参加できますが、平均は5です。
• Erlang VMセッションマネージャーは、最大500,000セッションをサポートできます。
• セッションに接続するとき、彼女は興味のある各ギルドのリモートノードを見つける必要があります。
• 要求/応答を使用した別のアーランプロセスとの通信時間は約12μsです。

セッションサーバーがクラッシュして再起動した場合、リングを検索するのに約30秒かかりました。 これは、他のリングプロセスの作業に関与する1つのプロセスのErlang側でのスケジュール解除も考慮していません。 これらのコストを完全に排除できますか？

Elixirを使用する場合、データへのアクセスを高速化する必要がある場合、最初に行うことはETSを使用することです。 これは高速で変更可能なC辞書です。 コインの裏側は、データがそこにコピーされ、そこから読み取られるということです。 ポートCを使用してリングを制御したため、リングをETSに転送することはできませんでした。そのため、純粋なElixirでコードを書き換えました 。 これが完了すると、他のプロセスがETSから直接データを読み取ることができるように、リングを所有し、ETSに継続的にコピーするプロセスができました。 これによりパフォーマンスは著しく向上しましたが、ETSの読み取り操作には約7μsかかり、リング内の値の検索操作に17.5秒かかりました。 リングのデータ構造は実際には非常に大きく、それをETSにコピーしてそこから読み取ることはほとんどの時間を費やしました。 がっかりしました。 他のプログラミング言語では、安全な読み取りのための一般的な意味を単純に作成できます。 Erlangでこれを行う方法が必要です。

いくつかの調査の後、仮想マシン関数を使用するmochiglobalモジュールを見つけました：Erlangが常に同じデータを返す関数に遭遇した場合、このデータを、プロセスがアクセスできる共有アクセスを持つ読み取り専用ヒープに配置します。 コピーは不要です。 mochiglobalは、1つの関数でErlangモジュールを作成してコンパイルすることでこれを使用します。 データはどこにもコピーされないため、検索コストは0.3μsに減少し、合計時間は750ミリ秒に短縮されました。 ただし、完全な景品はありません。 実行時にこのサイズのデータ​​構造を持つモジュールを作成すると、最大で1秒かかります。 幸いなことに、リングを変更することはめったにないため、喜んでその代価を支払います。

mochiglobalをElixirに移植し、アトマイゼーションを回避する機能を追加することにしました。 このバージョンはFastGlobalと呼ばれます 。

同時実行性の制限

ノード検索のパフォーマンスに関する重要な問題を解決した後、ギルドノードでguild_pid検索を処理するプロセスがバックアップし始めたことに気付きました。 ノードの保護に使用されるノードの低速検索。 新しい問題は、約5,000,000個のセッションプロセスがこれらのプロセスのうち10個（各ギルドノードに1個）をプッシュしようとしたことです。 ここでは、処理を高速化しても問題は解決しませんでした。 根本的な理由は、ギルドのこのレジストリにアクセスするセッションプロセスがタイムアウトになり、レジストリのキューにリクエストが残ったためです。 しばらくすると、リクエストが繰り返されましたが、リクエストが絶えず蓄積され、回復不能な状態になりました。 他のサービスからメッセージを受信すると、セッションはこれらの要求がタイムアウトするまでブロックします。これにより、メッセージキューが肥大化し、その結果、Erlang VM全体のOOMが発生し、結果として連鎖的な停止が発生しました 。

セッションプロセスをよりスマートにする必要がありました。 理想的には、失敗した結果が避けられない場合は、ギルドレジストリにこれらの呼び出しを行わないでください。 試行がまったく行われないときに、タイムアウトの急増が一時的な状態につながる状況が発生しないように、 回路ブレーカーを使用したくありませんでした。 他の言語でこれを実装する方法を知っていましたが、Elixirでそれを行う方法は？

他のほとんどの言語では、アトミックカウンターを使用して、発信要求とその数が大きすぎる場合の早期警告を追跡し、セマフォを効果的に実装できます。 Erlang VMはプロセス間の調整に基づいて構築されていますが、この調整に責任のあるプロセスをあまりロードしたくありませんでした。 いくつかの調査の後、ETSキーに含まれる数値に対して条件付き増分でアトミック操作を実行する:ets.update_counter/4に:ets.update_counter/4ました。 適切な並列化が必要だったため、ETSをwrite_concurrencyモードで実行することは可能でしたが、値を読み取ることは可能です:ets.update_counter/4は結果を返すからです。 これにより、 Semaphoreライブラリを作成するための基本的な基盤が得られました。 それは非常に使いやすく、高帯域幅で非常にうまく機能します：

 semaphore_name = :my_sempahore semaphore_max = 10 case Semaphore.call(semaphore_name, semaphore_max, fn -> :ok end) do :ok -> IO.puts "success" {:error, :max} -> IO.puts "too many callers" end 

このライブラリは、Elixirのインフラストラクチャを保護するのに役立ちました。 先週と同様に、前述のカスケード停止と同様の状況が発生しましたが、今回は停止はありませんでした。 プレゼンスサービスは別の理由で失敗しましたが、セッションサービスは動作しませんでした。プレゼンスサービスは、再起動後数分で回復できました。


プレゼンスサービス


同じ期間のセッションサービスによるCPU使用率

セマフォライブラリはGitHubにあります 。

おわりに

ErlangとElixirを選択して作業することは素晴らしい経験であることがわかりました。 私たちが戻って最初からやり直すことを余儀なくされた場合、私たちは間違いなく同じ道を選ぶでしょう。 私たちの経験とツールに関するストーリーが、他の開発者ElixirとErlangに役立つことを願っています。また、この作業の過程で私たちの仕事について話し、問題を解決し、経験を積んでいきたいと思います。