高負荷のWebSocketサービス開発

同時に数十万の接続をサポートしながら、リアルタイムでユーザーと対話するWebサービスを作成する方法は？



みなさん、こんにちは。開発者のアンドレイ・クリエフです。 最近、私はそのような仕事に直面しました-ユーザーが自分の行動に対して迅速なボーナスを受け取ることができるインタラクティブなサービスを作成すること。 問題は、プロジェクトの負荷要件がかなり高く、条件が非常に短いという事実によって複雑になりました。



この記事では、プロジェクトの困難な要件、開発プロセス中に発生した問題に対してWebSocketサーバーを実装するためのソリューションをどのように選択したかを説明します。また、Linuxカーネル構成が上記の目標の達成にどのように役立つかについても少し説明します。



この記事は、開発、テスト、および監視ツールへの便利なリンクで締めくくられています。

タスクと要件

プロジェクト機能の要件：

• リソース上でのユーザーの存在を追跡し、視聴時間を追跡できるようにします。
• ユーザーがボーナスを受け取る時間は厳密に制限されているため、クライアントとサーバー間で迅速なメッセージングを提供します。
• ユーザーが複数のタブまたはデバイスを同時に使用してサービスを操作する場合、すべてのアクションを同期する動的なインタラクティブインターフェイスを作成します。

負荷要件：

• アプリケーションは、オンラインで少なくとも15万人のユーザーに耐える必要があります。

実装期間は1か月です。

技術の選択

プロジェクトのタスクと要件を比較すると、WebSocketテクノロジーを開発に使用するのが最も適切であるという結論に達しました。 サーバーへの永続的な接続を提供し、ajaxおよびロングポーリングテクノロジーを使用した実装に存在するすべてのメッセージの新しい接続のオーバーヘッドを排除します。 これにより、適切なリソース消費と組み合わせて必要な高速メッセージングを取得できます。これは、高負荷の場合に非常に重要です。



また、インストールと切断が2つの明確なイベントであるという事実により、ユーザーがサイトにいる時間を正確に追跡することが可能になります。



プロジェクトのスケジュールがかなり限られているため、WebSocketフレームワークを使用して開発を行うことにしました。 PHP ReactPHP、PHP Ratchet、Node.JS websockets / ws、PHP Swoole、PHP Workerman、Go Gorilla、Elixir Phoenixのように思えました。 Intel Core i5プロセッサと4 GBのRAMを搭載したラップトップの負荷に関して、これらの機能をテストしました（このようなリソースは研究には十分でした）。



PHP Workermanは、非同期のイベント指向フレームワークです。 その機能は、websocketサーバーの最も単純な実装と、非同期イベント通知の処理に必要なlibeventライブラリを操作する機能によって使い果たされます。 コードはPHP 5.3であり、標準に準拠していません。 私にとっての主な欠点は、フレームワークが高負荷のプロジェクトの実装を許可しないことでした。 テストベンチでは、開発されたHello Worldレベルのアプリケーションは何千もの接続を保持できませんでした。



ReactPHPとRatchetの機能は一般にWorkermanに匹敵します。 Ratchetは内部的にReactPHPに依存しており、libeventを介して動作し、高負荷のソリューションを作成できません。



SwooleはCで書かれた興味深いフレームワークであり、PHPの拡張機能としてプラグインし、並列プログラミング用のツールを備えています。 残念ながら、フレームワークは十分に安定していないことがわかりました。テストベンチでは、1秒おきに接続が切断されました。



次に、 Node.JS WSを確認しました。 このフレームワークは良好な結果を示しました-追加の設定なしでテストベンチで約5,000の接続。 しかし、私のプロジェクトは負荷が著しく高いことを暗示していたため、Go Gorilla + Echo FrameworkとElixir Phoenix frameworksを選択しました。 これらのオプションはすでに詳細にテストされています。

負荷試験

テストには、大砲、ガトリング、flood.ioサービスなどのツールが使用されました。



テストの目的は、プロセッサリソースとメモリの消費量を調査することでした。 マシンの特性は同じでした-Intel iCore 5プロセッサーと4 GBのRAM。 GoとPhoenixでの最も単純なチャットの例でテストが行​​われました。



これは、25〜3万人のユーザーの負荷の下で、指定された容量のマシンで正常に機能する簡単なチャットアプリケーションです。

config: target: "ws://127.0.0.1:8080/ws" phases - duration:6 arrivalCount: 10000 ws: rejectUnauthorized: false scenarios: - engine: “ws” flow - send “hello” - think 2 - send “world”
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 Class LoadSimulation extends Simulation { val users = Integer.getInteger (“threads”, 30000) val rampup = java.lang.Long.getLong (“rampup”, 30L) val duration = java.lang.Long.getLong (“duration”, 1200L) val httpConf = http .wsBaseURL(“ws://8.8.8.8/socket”) val scn = scenario(“WebSocket”) .exes(ws(“Connect WS”).open(“/websocket?vsn=2.0.0”)) .exes( ws(“Auth”) sendText(“““[“1”, “1”, “my:channel”, “php_join”, {}]”””) ) .forever() { exes( ws(“Heartbeat”).sendText(“““[null, “2”, “phoenix”, “heartbeat”, {}]”””) ) .pause(30) } .exes(ws(“Close WS”).close) setUp(scn.inject(rampUsers(users) over (rampup seconds))) .maxDuration(duration) .protocols(httpConf)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

テストを開始したところ、示された容量のマシンで、25〜3万ユーザーの負荷ですべてが静かに動作することが示されました。



CPU消費：



フェニックス







ゴリラ







両方のフレームワークの場合、20000接続の負荷でのRAM消費量は2 GBに達しました。



フェニックス







ゴリラ







同時に、GoはパフォーマンスにおいてもElixirよりも優れていますが、Phoenix Frameworkはさらに多くの機能を提供します。 ネットワークリソースの消費を示す下のグラフでは、フェニックステストで1.5倍のメッセージが送信されていることがわかります。 これは、このフレームワークには、元の「箱入り」バージョンのハートビートメカニズム（定期的な同期信号）が既にあり、Gorillaで自分で実装する必要があるためです。 限られた時間枠で、追加の仕事はフェニックスを支持する強力な議論でした。



フェニックス







ゴリラ

Phoenix Frameworkについて

Phoenixは、Railsに非常によく似たクラシックMVCフレームワークです。その開発者およびElixir言語の作成者の1人は、Ruby on Railsの主要な作成者の1人であるJose Valimです。 構文にもいくつかの類似点が見られます。



フェニックス ：

 defmodule Benchmarker.Router do use Phoenix.Router alias Benchmarker.Controllers get "/:title", Controllers.Pages, :index, as: :page end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

レール：

 Benchmarker::Application.routes.draw do root to: "pages#index" get "/:title", to: "pages#index", as: :page end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Mix-Elixirプロジェクトの自動化ユーティリティ

PhoenixとElixirを使用する場合、プロセスの大部分はMixユーティリティを介して行われます。 これは、アプリケーションの作成、コンパイル、テスト、依存関係およびその他のプロセスの管理におけるさまざまなタスクを解決するビルドツールです。

ミックスは、Elixirプロジェクトの重要な部分です。 このユーティリティは、他の言語のアナログよりも決して劣らず、決して優れているわけではありませんが、完璧に機能します。 また、Elixir-codeがErlang仮想マシンで実行されるという事実により、Erlangの世界からライブラリを追加することが可能になります。 さらに、Erlang VMを使用すると、便利で安全な並行性と高い耐障害性が得られます。

問題と解決策

すべての利点を備えたPhoenixには欠点があります。 その1つは、高負荷状態でサイト上のアクティブユーザーを追跡するなどの問題を解決するのが難しいことです。

実際、ユーザーはさまざまなアプリケーションノードに接続でき、各ノードは自身のクライアントについてのみ知ることができます。 アクティブなユーザーのリストを表示するには、すべてのアプリケーションノードをポーリングする必要があります。

フェニックスでこれらの問題を解決するために、開発者が文字通り3行のコードでアクティブユーザーを追跡できるプレゼンスモジュールがあります。 クラスタ内でハートビートメカニズムと競合のないレプリケーションを使用し、PubSubサーバーを使用してノード間でメッセージを交換します。







良さそうに聞こえますが、実際には次のようになります。 数十万の接続ユーザーと切断ユーザーがノード間の同期のために数百万のメッセージを生成します。そのため、プロセッサリソースの消費が許容範囲を超えており、Redis PubSubを接続しても状況は保存されません。 ユーザーのリストは各ノードで複製され、新しい接続ごとの差分の計算はますます高価になります-これは計算が既存の各ノードで実行されることを考慮しています。







このような状況では、10万人の顧客のマークでさえ達成できなくなります。 このタスクの他の既成のソリューションを見つけることができなかったため、次のことを行うことにしました。ユーザーのオンラインプレゼンスを監視する責任をデータベースに割り当てます。



一見すると、これは複雑なことは何もありません。データベースに最後のアクティビティフィールドを保存し、定期的に更新するだけです。 残念ながら、高負荷のプロジェクトの場合、これはオプションではありません。ユーザー数が数十万人に達すると、システムはユーザーからの数百万のハートビートに対応できなくなります。



取るに足らない、より生産的なソリューションを選びました。 ユーザーが接続すると、一意の行がテーブルに作成されます。この行には、ユーザーの識別子、エントリの正確な時刻、接続先のノードのリストが格納されます。 ノードのリストはJSONBフィールドに格納され、行が競合する場合は更新するだけで十分です。

 create table watching_times ( id serial not null constraint watching_times_pkey primary key, user_id integer, join_at timestamp, terminate_at timestamp, nodes jsonb ); create unique index watching_times_not_null_uni_idx on watching_times (user_id, terminate_at) where (terminate_at IS NOT NULL); create unique index watching_times_null_uni_idx on watching_times (user_id) where (terminate_at IS NULL);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このリクエストは、ユーザーのログインを担当します。

 INSERT INTO watching_times ( user_id, join_at, terminate_at, nodes ) VALUES (1, NOW(), NULL, '{nl@192.168.1.101”: 1}') ON CONFLICT (user_id) WHERE terminate_at IS NULL DO UPDATE SET nodes = watching_times.nodes || CONCAT( '{nl@192.168.1.101:', COALESCE(watching_times.nodes->>'nl@192.168.1.101', '0')::int + 1, '}' )::JSONB RETURNING id;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ノードのリストは次のようになります。







ユーザーが2番目のウィンドウまたは別のデバイスでサービスを開くと、別のノードにアクセスでき、リストにも追加されます。 最初のウィンドウと同じノードにある場合、リスト内のこのノードの名前の反対の数が増加します。 この数は、特定のノードへのアクティブなユーザー接続の数を反映しています。



以下は、セッションが閉じられたときにデータベースに送信されるクエリです。

 UPDATE watching_times SET nodes CASE WHEN ( CONCAT( '{“nl@192.168.1.101”: ', COALESCE(watching_times.nodes ->> 'nl@192.168.1.101', '0') :: INT - 1, '}' )::JSONB ->>'nl@192.168.1.101' )::INT <= 0 THEN (watching_times.nodes - 'nl@192.168.1.101') ELSE CONCAT( '{“nl@192.168.1.101”: ', COALESCE(watching_times.nodes ->> 'nl@192.168.1.101', '0') :: INT - 1, '}' )::JSONB END ), terminate_at = (CASE WHEN ... = '{}' :: JSONB THEN NOW() ELSE NULL END) WHERE id = 1;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ノードのリスト：







特定のノードでセッションが閉じられると、データベース内の接続カウンターが1つ減り、ゼロに達すると、ノードはリストから削除されます。 ノードのリストが完全に空になると、この瞬間は最終的なユーザー終了時間として修正されます。



このアプローチにより、ユーザーのオンラインプレゼンスと視聴時間を追跡できるだけでなく、さまざまな基準に従ってこれらのセッションをフィルタリングすることも可能になりました。



このすべてにおいて、唯一の欠点があります-ノードが落ちた場合、そのすべてのユーザーがオンラインで「ハング」します。 この問題を解決するために、このようなレコードからデータベースを定期的にクリーニングするデーモンがありますが、これまでのところこれは必要ありませんでした。 プロジェクトの運用開始後に実行された負荷の分析とクラスタの監視は、ノードのドロップがなく、このメカニズムが使用されていないことを示しました。



他にも困難がありましたが、より具体的であるため、アプリケーションの復元力の問題に移る価値があります。

パフォーマンスを向上させるためのLinuxカーネルの構成

優れたアプリケーションを生産的な言語で書くことは、戦いの半分にすぎません。読み書きのできるDevOpsがなければ、少なくとも高い成果を上げることは不可能です。

ターゲット負荷に対する最初の障壁は、Linuxネットワークカーネルでした。 リソースのより合理的な使用を実現するには、いくつかの調整が必要でした。

Linuxでは、開いている各ソケットはファイル記述子であり、その数は制限されています。 制限の理由は、カーネル内の開いているファイルごとに、再利用できないカーネルメモリを占有するC構造が作成されるためです。



最大メモリを使用するには、送信バッファと受信バッファのサイズを非常に大きく設定し、TCPソケットバッファのサイズも大きくしました。 ここでの値はバイト単位ではなくメモリページ単位で設定されます。通常、1ページは4 kBであり、負荷の高いサーバーの接続を待機している開いているソケットの最大数を15,000に設定します。

ファイル記述子の制限：

 #!/usr/bin/env bash sysctl -w 'fs.nr_open=10000000' #      sysctl -w 'net.core.rmem_max=12582912' #       sysctl -w 'net.core.wmem_max=12582912' #       sysctl -w 'net.ipv4.tcp_mem=10240 87380 12582912' #   TCP  sysctl -w 'net.ipv4.tcp_rmem=10240 87380 12582912' #    sysctl -w 'net.ipv4.tcp_wmem=10240 87380 12582912'#    <code>sysctl -w 'net.core.somaxconn=15000' #    ,  
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

カウボーイサーバーの前でnginxを使用している場合は、制限を増やすことも検討する必要があります。 ディレクティブworker_connectionsおよびworker_rlimit_nofileがこれを担当します。



2番目の障壁はそれほど明白ではありません。 このようなアプリケーションを分散モードで実行すると、CPU消費が急激に増加する一方で、接続数が増加することに気付くでしょう。 問題は、デフォルトではErlangがPollシステムコールで動作することです。 Linuxカーネルのバージョン2.6には、多数の同時オープン接続を処理するアプリケーションにより効率的なメカニズムを提供できるEpollがあります。O（n）の複雑さではなくO（1）の複雑さです。



幸いなことに、Epollモードは1つのフラグでオンになります。

投票対 エポール

 #!/usr/bin/env bash Elixir --name ${MIX_NODE_NAME}@${MIX_HOST} --erl “-config sys.config -setcookie ${ERL_MAGIC_COOKIE} +K true +Q 500000 +P 4194304” -S mix phx.server
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

3番目の問題はより個人的なものであり、誰もがそれに直面できるわけではありません。 ChefとKubernetesを使用した自動展開と動的スケーリングのプロセスは、このプロジェクトで編成されました。 Kubernetesを使用すると、多数のホストにDockerコンテナーをすばやく展開できますが、これは非常に便利ですが、新しいホストのIPアドレスを事前に見つけることはできません。また、Erlang構成に登録しないと、新しいノードを分散アプリケーションに接続できません。



幸いなことに、これらの問題を解決するためにlibclusterライブラリが存在します。 APIを介してKubernetesと通信し、彼女はリアルタイムで新しいノードの作成について学び、それらをerlangクラスターに登録します。

 config :libcluster, topologies: [ k8s: [ strategy: Cluster.Strategy.Kubernetes, config: [ kubernetes_selector: “app=my -backend”, kubernetes_node_basename: “my -backend”]]]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

結果と展望

選択されたフレームワークと正しいサーバー設定により、プロジェクトのすべての目標を達成することができました：設定された時間枠（1か月）以内に、リアルタイムでユーザーと通信し、同時に15万以上の接続からの負荷に耐えることができるインタラクティブなWebサービスを開発します。



本番環境でのプロジェクトの開始後、監視が実行され、次の結果が示されました。最大接続数が80万までの場合、プロセッサリソースの消費は45％に達します。 60万の接続での平均負荷は29％です。







このグラフでは、それぞれが8 GBのRAMを搭載した10台のマシンのクラスターで作業しているときのメモリ消費量。











このプロジェクトの主な作業ツールであるElixirとPhoenix Frameworkについては、今後数年のうちにRubyやRailsと同じくらい人気になると信じる理由がありますので、今すぐ開発を開始するのは理にかなっています。

ご清聴ありがとうございました！

参照資料

開発：

elixir-lang.org

phoenixframework.org

負荷テスト：

gatling.io

flood.io

監視：

prometheus.io

grafana.com