High (Availability|Performance) WebSocket for Perl Real-Time Application

High (Availability|Performance) High (Availability|Performance) WebSocket for Perl Real-Time WebSocket for
Perl Real-Time Application Application macopy a.k.a @mackee_w YAPC::Okinawa 2018 ONNASON

自己紹介自己紹介インターネット及び会社ではマコピーと呼ばれています所属: 面白法人カヤック主な職業: スマホゲームのサーバサイドエンジニアゲーム開発, サーバ運用, ワークフロー構築
etc...

「トーカナイザの守護霊」興味があること: リアルタイム通信, 3D プリンタ, 自作キーボード最近の出来事: 右肘を骨折, リハビリ中
Twitter: @mackee_w GitHub: @mackee PAUSE: MACOPY

Perl Hackers Hub にDB を使ったテストの話などを寄稿させていただきました

予告編の内容予告編の内容課題と背景について説明しますサーバプッシュを従来の同期型Prefork アーキテクチャで扱った場合の問題点何故kuiperbelt が生まれたのかの説明スマホゲームの場合の事例です

このトークの内容このトークの内容背景があった上でどう解決したかを解説永続接続を扱うスケーラブルなミドルウェアの設計そのミドルウェアを趣味で作って運用に持っていく話 Proof of Concept から Production
Ready になるまで

!!! CAUTION!!! このトークでの High Availability High Availability 高可用性これほどコンテキストによって変わる高ナントカはあまりないと思う
SPOF がない片方落ちたときにクライアントの再接続でもう片方でサービス継続が可能リトライ可能

人間諦めが肝心人間諦めが肝心信頼性が期待されているミドルウェアは、何を提供するミドルウェアでどこからどこまでを保証するかをはじめに決めるはじめにルールを決めておけば信頼性を損ないかねない機能追加の要望を説明して突っぱねられる代替案は提案した方がいいけれど

!!! CAUTION!!! このトークでの High Performance High Performance WebSocket 同時接続数 10k
～ 100k 上記数字は実際の本番での運用での数字横に並べられるボトルネックになることを避ける設計もっといけるとは思う

!!! CAUTION!!! このトークでのリアルタイムリアルタイム「リアルタイムっていうからリアルタイムOS とかのリアルタイムかと思った」ごめんなさい違います。なのでそういうの言うだけのブクマはしないで欲しい Web
およびスマホゲームで使われる言葉。技術的観点からはサーバプッシュを用いた機能

第1 章第1 章リアルタイム通信がめんどくリアルタイム通信がめんどくさい件さい件

リアルタイム通信とはリアルタイム通信とはあるユーザの操作時間経過やゲーム内オブジェクトの状態によって引き起こされるイベントが別のユーザに即座に伝わるアーキテクチャ/ ゲームシステムのことを指す

例: ターン制カードゲーム例: ターン制カードゲーム相手のターンから自分のターンになる時に場に出すカードを選択するなどしてターンを終了する

例: ターン制カードゲーム例: ターン制カードゲーム既にターンが終了しているかどうかを出来るだけ素早く知るには？今の場の状態をサーバに定期的に問い合わせる(= ポーリング) サーバから情報が降ってくるのを待つ(= サーバプッシュ)

ターン終了時の通信ターン終了時の通信

ポーリングポーリング

サーバプッシュサーバプッシュ

実現するためには実現するためにはクライアントからのリクエスクライアントからのリクエスト無しでサーバから情報を送ト無しでサーバから情報を送る必要があるる必要がある => サーバプッシュ
=> サーバプッシュ

本物と擬似本物と擬似従来のクライアント起点のリクエストでも似たような体験を実現出来なくはないこれがポーリングクライアントが定期的にサーバに新しい情報がないかを取りに来る。更新されていたら画面とかも更新する疑似リアルタイムと呼ばれる

ポーリングサーバプッシュリアルタイム性低高通信量大小サーバリソース大
小技術的飛躍度低高枯れている感高低

モバイルの場合モバイルの場合ポーリングサーバプッシュ電池消費小大サーバプッシュはサーバに対してクライアントが通信を繋ぎっぱなしになるため電池を消費しがちポーリングは通信が間欠的になるため比較的電池消費をしない

メリット・デメリットあるけメリット・デメリットあるけれど本物が必要なアプリケーれど本物が必要なアプリケーションは多いので本物のリアションは多いので本物のリアルタイム技術を採用せざるをルタイム技術を採用せざるを得ない今日このごろ得ない今日このごろ

本物のリアルタイムでもラグ本物のリアルタイムでもラグはあるはある驚くべきことに光は1ms に300km しか進まない驚くべきことに通信回線の資源や計算資源は有限驚くべきことにインターネットはコンピュータのバケツリレーで出来ている

あなたはそばに相手がいると思うかもしれないが、それはインターネットの中だけで実は地球の反対側にいるかもしれない。それがインターネットの良いところ

ラグを見せないゲームデザイン [CEDEC 2010] ネットゲームの裏で何が起こっているのか。ネットワークエンジニアから見た，ゲームデザインの大原則行動パターンが送られてこない場合でも，それを誤魔化す小さいアクション（火を吹くなど）が用意されているとのこと

Web 以外のゲームでは Web 以外のゲームでは家庭用ゲーム機/ オンラインゲームの世界もっぱら生TCP/ 生UDP の世界各々がそれぞれやっている(
シリアライズ形式とか)

スマホゲーム界ではスマホゲーム界ではノウハウを持ってない会社が参入してきたのでミドルウェアを提供する会社が出てきた Photon Server / Photon Cloud (Exit
Games, Inc) モノビットエンジン ( モノビット株式会社)

一方我々は一方我々は面白法人カヤックって出自がWeb の会社なんですよね最近はゲームやったりハードウェアを設計する人もいるけれど使われる技術スタックはWeb 由来のものいきなり家庭用ゲーム機やPC ゲーム由来の技術を使おうとしてもノウハウがない
Photon 使っているゲームもある

Web の技術 Web の技術ニアリーイコールブラウザで使える技術ブラウザで使える技術

HTTP の世界観 HTTP の世界観リクエストとレスポンスは1 対1 レスポンスが生まれるにはリクエストが必要この時点でサーバプッシュとは矛盾している

HTTP はステートレスなプロトコルステートレスなプロトコルあるリクエスト/ レスポンスの対と、別のあるリクエスト/ レスポンスの対は独立している

重要な点重要な点一般的にWeb サービスの1 リクエストは長くても数秒以内にレスポンスが返ってくるこのへんが後々効いてくる大事な話です

HTTP の特性を踏まえた上での HTTP の特性を踏まえた上での Web でのサーバプッシュはど Web でのサーバプッシュはどうやる？うやる？

ロングポーリング/Comet ロングポーリング/Comet ふつうにHTTP リクエスト投げるサーバは送りたい情報が出るまでレスポンスを送らず焦らす送りたい情報が生まれたらレスポンスを返すクライアントは処理したらまたリクエストを投げる

ロングポーリング/Comet ロングポーリング/Comet メリット: 普通のHTTP 通信が長くなっただけデメリット: 一個情報を受け取るのに一回リクエスト送るオーバーヘッド, レスポンスを受け取ってから次にリクエストを送るまでは情報をリアルタイムに受け取れない

Sever-Sent Events(SSE) Sever-Sent Events(SSE) ふつうにリクエスト投げるサーバはコネクションを切らずにだらだら1 行ずつ書くクライアントは1 行データが送られてきたら読む、コネクションは切らない

Sever-Sent Events(SSE) Sever-Sent Events(SSE) メリット: ただのHTTP のアクロバティック的使用法デメリット: 一方通行, ライブラリ実装の少なさ

WebSocket WebSocket Upgrade ヘッダが入ったリクエストを投げるサーバがWebSocket を介したいんだなって思って101 Switching Protocols を返す HTTP
とは違う独自のWebSocket プロトコルによる通信が開始される

WebSocket WebSocket メリット: 現代においては広く使われている, 標準化もされている, 双方向デメリット: HTTPS じゃないWebSocket
だとフォワードプロキシがある環境で使えないことがある, デバッグ方法が通常のHTTP の作法と違う

他にも未来の技術達他にも未来の技術達 HTTP2 Server Push html を取りに来たクライアントにこれも必要だから持ってけって言ってJS やら画像を送りつけることが出来るやつゲームなどのサーバプッシュに使えるかどうかはあまりわからない……
この前のセッションでトークした人達に聞いてみましょう

他にも未来の技術達他にも未来の技術達 WebRTC ブラウザでビデオチャットとかするやつ条件が合えばP2P 通信ができる。また画像や音声以外にもデータも送れる。さらにUDP を選択できるのでオーバーヘッドも少ない。ただしNAT 越え……
gRPC みたいなWeb の技術に乗っかっているサーバプッシュの仕組みを持ったものもあるが、ブラウザでは使えない

Web サーバアーキテクチャの Web サーバアーキテクチャの話話サーバプッシュを適用するにはアーキテクチャの変更が必要になる場合がある……

太古の昔: CGI 太古の昔: CGI HTTP リクエストが飛んできたらサーバ内のコマンドを起動してリクエストを起動したプロセスに渡すプロセスが吐いた出力をレスポンスとして返す

太古の昔: CGI 太古の昔: CGI メリット: 簡単, 分かりやすい, デバッグしやすいデメリット: プロセスの起動ってコストがかかるんや……

時代が移ろいでいきPerl 界では mod_perl perl インタプリタの起動とモジュールの読み込みは予めしておく FastCGI Apache からの解脱, lighttpd
ってのがあってだな PSGI もうperl がHTTP をしゃべっちゃう Perl ウェブ開発の中世～CGI と Plack の間～ - YAPC::Kansai 2017

しかしプロセスの使われ方はしかしプロセスの使われ方は変わっていない変わっていない

同期的Prefork モデル同期的Prefork モデル Pre(= 事前に)fork あらかじめリクエストを処理するプログラムのプロセスを複数立てておき、リクエストが来たら暇しているプロセスに配る 1 プロセスだと1
度に一つのリクエストしかさばけないが、 Prefork モデルはfork したプロセス分さばける

Prefork モデルは他のLL でも使 Prefork モデルは他のLL でも使われているわれている Perl/PSGI -
starman, starlet Ruby/Rack - unicorn Python/WSGI - gunicorn

同期的Prefork モデルが使われ同期的Prefork モデルが使われる理由る理由 -> 簡単 -> 簡単

マルチスレッドではないのでデータ競合で変数壊れるとか無いそもそも並行プログラミングを考えなくて良い、コードも上から下に読んでいけば良い LB とインスタンスの関係と同じなので同じ考え方が適用できる共有リソースがないのでサーバを横に簡単に並べられる => スケールアウト

しかし同期的Prefork モデルにしかし同期的Prefork モデルにも限界がも限界がもし、一つのHTTP リクエストが数十秒、数百秒かかっていたら？ Prefork モデルはfork
したプロセス分さばける

Prefork したプロセス以上のリクエストがHTTP リクエストの寿命の間に殺到したときに破滅する

刹那的な場合はプロセス数以上のリクエストが来てもなんとかさばける

ここに永続的な場合にプロセス数以上のリクエストが来るとレスポンスが詰まる

破滅です破滅です同時接続数が少ないアプリケーションでは破滅しないこともあります

Q. 何故、同期的Prefork モデル Q. 何故、同期的Prefork モデルが成り立っていたかが成り立っていたか A. 普通のHTTP
通信は刹那的な A. 普通のHTTP 通信は刹那的なプロトコルだからプロトコルだから

今までのHTTP では1 つのリク今までのHTTP では1 つのリクエストが1 つのプロセスを専エストが1 つのプロセスを専
有する時間が短い。だからこ有する時間が短い。だからこれでやってこれたれでやってこれた

刹那的接続から永続的接続刹那的接続から永続的接続へ…… へ…… ロングポーリング, SSE, WebSocket... これらはすべて1 回のHTTP リクエストの寿命が長い
従来のアーキテクチャではプロセスが枯渇する

C10K の話をしています C10K の話をしています C10K = Connection 10,000 Problem サーバリソースはあるのにアーキテクチャの問題でリクエストを
さばくことが出来ない問題本来はHTTP Keep-Alive の文脈からも論ぜられますが、Keep-Alive はnginx とかが維持してくれるし、刹那的HTTP に変換可能なのでアプリケーションの変更はいらない

C10K の解法並行プログラミングの導入並行プログラミングの導入イベント駆動(Node.js, AnyEvent, etc...) 1 プロセスで複数の接続を扱うために、処理を細切れにして動かす
コールバック地獄になる...

ネイティブスレッド(Java 族, C 族, etc...) データ競合... マルチスレッドプログラミングはバグを知るのが難しい... fork よりはマシだけれどネイティブスレッドも重いからスレッ
ドプールが必要なのよねえ今のPerl5 では使えない( そもそもithread は……) ithread はメモリ共有モデルではない

軽量スレッド(Erlang/OTP, Elixer, Go, etc...) もっとも今まで通りに書けるが1 プロセスで複数の処理が並行で走るのは変わらないので、バグ潰しが難しい

リアルタイム通信をやりたいリアルタイム通信をやりたいだけでアプリケーション全体だけでアプリケーション全体の言語やプログラミングパラの言語やプログラミングパラダイムを変更するのは理にかダイムを変更するのは理にかなっているかなっているか

わからん! わからん! 場合による!! 場合による!! 自分で考えてくれ!!! 自分で考えてくれ!!!

イチから作るか、動いている物に導入するか今の言語で出来るかどうか移行先の言語やパラダイムに精通している人がいるかどうかカネと時間があるかどうか作ったもののパフォーマンスが出るか、検証できるかどうか

別件: アプリケーションと密結別件: アプリケーションと密結合の問題合の問題アプリ更新したいから再起動するぞ！！！！ ↓ プロセスが殺されるから全部一旦切るで～～ ↓
え？？？？？？クライアントの再接続が一気に起こります

別の解法 => サーバプッシュだ別の解法 => サーバプッシュだけ別にやるけ別にやる Node.js でSocket.IO
しゃべってRedis pub/sub でWebApp からつなげる Go で似たようなことをgRPC/SSE でやる ActionCable Ruby on Rails でWebSocket をしゃべる機能 kuiperbelt <- 本日はコレの話 openfresh/plasma

第1 章まとめ第1 章まとめ同期的Prefork では大量の寿命の長い接続をさばくのは困難である現実的にやるには並行プログラミングを導入するか、サーバプッシュだけ別のサーバでやる手法が考えられる

第2 章第2 章 kuiperbelt とは kuiperbelt とは

kuiperbelt とは kuiperbelt とは WebSocket とHTTP/1.1 の相互変換プロキシサーバ by 独立したWeb サーバデーモンとして動作する
Go で書かれているが使うのにGo の知識は要らない mackee/kuiperbelt README.ja.md

機能機能 WebSocket の接続を維持する及び現実的にやるための仕組みの提供接続認証の方法スケールアウト戦略

思想思想 WebSocket をしゃべるサーバを直接インターネットに晒さない。ロードバランサーに入れる他の事例では直接インターネットにさらしているケースが多い大量接続に耐えるWebSocket アプリケーションサーバ構築のコツ -
pixiv inside

何故ロードバランサーに入れ何故ロードバランサーに入れる？る？ LB に入れることで管理コストを下げる WebApp とWebSocket を疎結合にする

思想思想独自のデータ構造を作らない。HTTP の仕組みをそのままできるだけ使う HTTP がしゃべれるアプリケーションであれば適用可能

接続時の通信の流れ接続時の通信の流れ

試し方試し方から最新版のバイナリを落としてパスを通す Go のコマンドやデーモンはバイナリリリースがあれば自分でビルドせずバイナリリリースを使うのが好ましいのチュートリアルを読むか、のPlack アプリを読むと良い
GitHub Releases README.ja.md example

認証用のHTTP サーバを作る my $app = sub { my $env =
shift; my $req = Plack::Request->new($env); # some authentication processes my $endpoint = $req->header("X-Kuiperbelt-Endpoint"); my $session_id = generate_uuid(); $KVS->set("$user_id:kuiperbelt_session", { session => $session_id, endpoint => $endpoint }); return [200, [ "Content-Type" => "application/json", "X-Kuiperbelt-Session" => $session_id, ], ['{"message": "Hello WebSocket World!"}'],

認証用のアドレスを設定して起動さっきのをで保存して起動する kuiperbelt 用config に立てたサーバのアドレスを設定ファイル ( ) に書く書いた設定を使ってkuiperbelt
を起動する $ plackup --port=5000 app.psgi callback: connect: http://localhost:5000/ $ ekbo -config=config.yml

メッセージ送信時の通信の流れ

Perl からメッセージを送るなんでもいいけれどHTTP でAPI 叩けば良いです。Body の形式は問いません。 # $target_user_id 対
$message 送 my $furl = Furl->new; my $session = $KVS->get("$target_user_id:kuiperbelt_session"); $furl->post( $session->{endpoint} . "/send", [ "X-Kuiperbelt-Session" => $session->{session_id} ], $message, );

もともとの動機もともとの動機 Perl5 でWebSocket とかSSE を喋りたかったが、 AnyEvent とかMojo 使えばPerl5 でWebSocket
使えるやん？あ、そのせいでイベント駆動プログラミングをしないといけなくなった…… DB のトランザクションかけようとしたら、混ざるんじゃないのこれ？

そこで思いついたそこで思いついた WebSocket の接続を維持するだけのサーバを作ればよいのでは？それが普通のHTTP API の口を持っていて、アプリケーションサーバからAPI を叩いてWebSocket に送るメッセージを送信すればよ
いのでは？

先人の知恵 APNS::Agent APNS::Agent iOS 端末にプッシュ通知( スリープしていても届くと音がなって振動するやつ) をサーバから送るAPI が独自の生TCP かつ、非同期型
Net::APNS::Extended などの同期型のモジュールもあるが、Prefork のWebApp から送ると当然詰まる

先人の知恵 APNS::Agent APNS::Agent AnyEvent::APNS と言うモジュールもあるが、イベント駆動にしないと AnyEvent::APNS を単体デーモンに切り出したのがAPNS::Agent

仕組み仕組み 1. HTTP API でWebApp からメッセージを受け取る 2. AnyEvent::APNS を使ってApple
のサーバにつながっているソケットにメッセージと送り先トークンを書き込む 3. プッシュ通知が届く HTTP でiOS のpush 通知を送れる未来がやってきた(APNS::Agent の紹介)

偉大なところ偉大なところやることに合わせたアーキテクチャを使い分けれるようにデーモン化して切り出した一つのことをうまくやる土管に徹する UNIX 哲学 HTTP API
というどの言語でも持っているようなインターフェイスで触れる現在ではというデーモンに思想は引き継がれてAndroid にも通知が送れるようになっています Gunfish

これだ！と思ってWebSocket これだ！と思ってWebSocket でも同じことをやろうとしたでも同じことをやろうとした

kuiperbelt という名前の由来 kuiperbelt という名前の由来もともとはロングポールをやろうと思ってComet って言う別名もあるので、じゃあ彗星の起源ということでエッジワース・カイパーベルトから名前を取った同じような言葉でオールトの雲というのがありoort は短いから良いなあと思ったんですがこの名前のOSS
は既にあった

kuiperbelt はWebSocket の接続 kuiperbelt はWebSocket の接続を維持するデーモンとしてどを維持するデーモンとしてどのような課題の解決を行ってのような課題の解決を行って
いるかいるか

一般的なWebSocket の接続を一般的なWebSocket の接続を考える考える 1. クライアントから普通のHTTP リクエストが来る 2.
サーバは繋いで良いクライアントだったらUpgrade する 3. WebSocket 接続を開始する 4. 適宜送ったり、受け取ったりする 5. 切りたいときに切る

課題課題認証の方法誰に送るかの指定方法送る内容の形式切断検知

認証の方法認証の方法 kuiperbelt に認証機構を実装するのも考えたが…… ユーザDB に接続する？ OAuth する？土管に徹したいので認証機構は他所に投げたい一発目は普通のHTTP
リクエストだからこれをWebApp にプロキシすればいいのでは？

コールバックを投げるコールバックを投げるクライアントからのHTTP リクエストをそのままバックエンドの WebApp に飛ばす 200 だったらWebSocket 開始認証はWebApp
に委ねることでkuiperbelt の実装自体はコンパクトになり堅牢になる

宛先の指定方法宛先の指定方法接続ごとに識別子を指定して欲しい気持ち接続の識別子は認証時のWebApp のレスポンスのヘッダにという名前で送ってもらってそれを使うメッセージを投げるときもというヘッダに入れてもらう

Body はApp のもの Body はApp のもの WebApp がメッセージを投げるときに叩くHTTP API のリクエスト
のBody の内容をそのままWebSocket に書き込んでいるを指定すればバイナリも突っ込める msgpack を使っているプロジェクトもあります

Body はApp のもの Body はApp のものつまり何をどう送るかはWebApp に委ねられている => 土管に徹す
る思想からなので送信オプションとかはHTTP ヘッダを使うようにしている

土管に徹すると何が良いか土管に徹すると何が良いか言語非依存になる Perl 専用のデーモンだとユーザが広がりにくい。OSS プロダクトにおいてユーザ数というのは力になる役割が明確になるアプリケーション非依存になる

切断検知切断検知 WebSocket はTCP なのでお行儀よく切断すれば接続が切れたことを検知することが出来るアプリケーションによっては切断を知ることは重要なのでクライアントから接続が切れたら設定したコールバックURL を kuiperbelt
が叩くように設定できる

が、お行儀よく切断されないことはモバイルの世界だと大いに有り得るので、すぐに切れたことを検知する事はできない

kuiperbelt での検知 kuiperbelt での検知メッセージを送ろうとして書き込めなかったら切断と認定無通信時間が一定秒数以上続けば切断と認定 WebSocket のping フレームをクライアントが一定間隔で送ってくることが前提の機能

無通信時間による切断検知は使用プロジェクトの要望で追加した機能です

第2 章まとめ第2 章まとめ WebSocket に必要な要素をステートレスHTTP に分解すると普通の WebApp でもWebSocket を扱えるようになる
土管に徹することで様々なWebApp でも使えるようになる

第3 章第3 章本番投入への道本番投入への道

作り始めたときは趣味だった作り始めたときは趣味だった社内でリアルタイムゲームのプロジェクトが立ち上がったときに「ぼくがかんがえたさいきょうのWebSocket アーキテクチャ」を披露し、既に実装はありますと言ったら採用された

趣味プロダクトはそのままで趣味プロダクトはそのままでは本番投入はおそらく出来なは本番投入はおそらく出来ない…… い……

そもそもどこのサービスにも投入されていないユースケースが妄想かもしれない Proof of Concept のつもりこういうの考えてみたけれどどう？っていう実装

プロジェクトへの導入をしながら機能を追加していったスケールアウト用の機能ベンチマーク監視API, ログ

スケールアウト( 複数台) 戦略スケールアウト( 複数台) 戦略何故複数台構成に出来るようにするか？ WebSocket 受ける君が1 台だと1
台落ちるだけでサービス全体が障害に陥る(HA 目的)

何故複数台構成に出来るようにするか？ 1 台のスペックが上げられる上限は決まっているまたAWS だとスペックは倍倍に上がっていくのでちょうどいいスペックに設定できないというのもあります

先行事例先行事例 PC ゲームなどのオンラインゲームそれぞれのインスタンスがPublic IP を持っていてクライアントに接続先IP を指定同じ部屋の人は同じインスタンスに固めるなどが出来る
インスタンス落ちたときのことをApp が考えないといけない

先行事例先行事例 Node.js やActionCable など Redis pub/sub を用いる( メッセージキュー) WebSocket
の接続を持つサーバが部屋ごとに作られたtopic を subscribe しておいて、WebApp 側が部屋のtopic に対してメッセージをpublish する Redis さえスケールさせれば、そうRedis さえ落ちなければ……

やりたくないことやりたくないこと WebApp からつなぐ先を指定させたくない外から繋げられるPublic IP がそれぞれのインスタンスに必要負荷の偏りが生じる

やりたくないことやりたくないこと特定のミドルウェアに依存したくない Redis pub/sub を使うとスケール限界がRedis の性能になるインフラ構成でRedis が必須になる

必要なのはどの接続がどのインスタンスどの接続がどのインスタンスにあるかをクライアントにあるかをクライアント (WebApp) が知っておくこと (WebApp) が知っておくこと

KVS のシャーディング方法を KVS のシャーディング方法を参考にする参考にする libketama とかtwemproxy とかクライアントがキーから値が入っているホストを特定して取って
くる KVS 自体は分散されていることを別に知らなくても良い

WebSocket の場合 WebSocket の場合どこにつなぐべきかを接続時に指定すれば同じようなことは出来るが…… やりたくないリストに入っている前段にLB を立てる場合はどこに繋ぐかはランダムなので接続識別子からどこに入っているかを導き出すことは出来ない
スティッキーセッションを使えばランダムじゃなくすることは出来ますがどこに繋ぐべきかを指定するパターンと同じになる

接続コールバックにアドレス接続コールバックにアドレスを埋め込むを埋め込む callback のリクエストにkuiperbelt は以下のヘッダを付ける X-Kuiperbelt-Endpoint: 192.168.100.1:9180

接続コールバックにアドレス接続コールバックにアドレスを埋め込むを埋め込むこれをWebApp 側は接続識別子と一緒に入れておいてどこにつながっているかをKVS とかに保存しておく

Q. 結局KVS 使っているので Q. 結局KVS 使っているのでは？？？は？？？ A. ユーザID
と接続識別子の変 A. ユーザID と接続識別子の変換にKVS とか使うでしょ換にKVS とか使うでしょ

Q. 識別子= ユーザID とかにす Q. 識別子= ユーザID とかにすればKVS 必要じゃなくない？
ればKVS 必要じゃなくない？ A. 1 人のユーザが複数のWS 接 A. 1 人のユーザが複数のWS 接続持つケースがあって続持つケースがあって

これでスケールの上限はこれでスケールの上限は WebApp 側の識別子解決の方 WebApp 側の識別子解決の方法に依存する法に依存する

もしくはネットワークトポロもしくはネットワークトポロジがフルメッシュになっていジがフルメッシュになっているのでそこも性能限界になりるのでそこも性能限界になりうるうる

メッセージ送信時の通信の流れ

kuiperbelt インスタンスが持っているSend API への接続数は WebApp 側インスタンスの数に依存する超大規模環境でWebApp が多いと階層構造にするみたいなのが必要そう？ Perl
はメモリを食わないので横の台数が少なくて済むので便利

どこがボトルネックになりうどこがボトルネックになりうるかをちゃんと知るのが大切るかをちゃんと知るのが大切

ベンチマークベンチマーク理論上OK でも実際どうなのかというのは実際に動かさないとわからない.... 実際のアプリケーションで想定される負荷をかけてみるミドルウェアのベンチをとっとけば他のアプリでも採用がすんなりいきやすい

ベンチの条件ベンチの条件クライアントは指定した数だけWebSocket のコネクションを貼る降ってきたメッセージはログに吐く WebApp 側は接続中の接続の識別子を取ってきてメッセージを送るここは実アプリの挙動を真似すると良い n 人に同じメッセージを送るパターン
メッセージサイズetc...

結構古いバージョンの結果なので今とは性能が違う場合がありますサーバは2 コア2 台です clients event CPU Mem(RSS) msgs/sec 1000
1000 13% 68MB 2666 5000 2000 24% 366MB 5388 5000 4000 49% 355MB 10916 10000 10000 120% 688MB 26666 10000 1666 22% 737MB 4466

わかることわかることメモリ使用量はクライアント数に依存する CPU は秒間メッセージ数に依存するここからチューニングポイントが分かる

さらにクライアント数を伸ばしていくと... clients event CPU Mem(RSS) msgs/sec 20000 3333 47% 1400MB
8666 40000 6666 130% 1500MB(4a383f2) 17880

40000 clients のところでメモリ使用量が減っている？けれどメモリが結構辛くなったのでチューニングを行いました

メッセージを書き込むときに確保するバッファサイズを最適化した use io.CopyBuﬀer by @fujiwara io.Copy makes 32KB buﬀer
automatically, but it is too large for kuiperbelt use case.

これらベンチマークはfujiwara さんにやっていただきました

監視系の機能も@fujiwara さんに入れてもらったものが多い

監視系のAPI 監視系のAPI 時間を返すだけのAPI ロードバランサーからのヘルスチェックに必要 kuiperbelt 固有の監視項目を返す生きてるコネクション数/ エラー数はこれを使っている運用と監視は切っても切れない関係にあることがわかりますね
mackerel-plugin-kuiperbelt

ログはガンガン出すログはガンガン出すただしパフォーマンスにも影響するのでログレベルで調整できるようにする

ログレベルログレベル Perl だとがよく使われている CRITICAL, WARN, INFO, DEBUG に出力するログを分類する
kuiperbelt はDEBUG にガンガンログを出している => WebSocket のデバッグがめんどくさいので開発中に躓いて出したログはだいたい残しているその代わりに運用中にはDEBUG やINFO のログは切っている Log::Minimal

ログうるさすぎ問題ログうるさすぎ問題アクセスログをINFO で出していたけれどログ流量が半端なくて他のログが埋まって機能しなくなった…… そもそも前段にnginx やALB がいるときはそっちでログが出せるのでは？導入プロジェクトの人の要望から
オプションを追加した

デバッグ時には必要だけれど運用時には必要ないログみたいなのがある

そしてプロダクションへそしてプロダクションへカヤックでゲームをリリースするときは事前に専用のシナリオで負荷試験を行っています kuiperbelt 導入プロジェクトはkuiperbelt 含めた負荷試験も行っているそれもクリアして、本番で実際に動いています

これでこれで Production Ready Production Ready と言えると言える

第3 章まとめ第3 章まとめ本番運用できるミドルウェアにするためには、いくつかの機能追加やベンチマークなど作り始めとは違う視点が必要ミドルウェアは信頼されてなんぼなので、これらは必要な労力だと思う

まとめまとめミドルウェア作りは産みの苦しみもあるけれど、概念作れるし小説の世界観設計に似ている俺がミドルウェアを作るからその上で面白いゲームを作ってくれと日々思っています一回概念を提唱するとそれについてくる人がいて助かる Thanks for @fujiwara,
@shogo82148, and Users!

提供提供面白法人カヤックでは攻めのゲームづくりを一緒にする仲間を募集しています！！！ Perl とかGo とかUnity/C# とか。今やってなくても応募はタダ！！

その他やったことその他やったこと本当にWebSocket をスマホが喋れるか検証レースコンディション解消 Docker 対応 ALB が半死したときにhttp2 になっててkuiperbelt
も巻き込まれた話

Docker 対応 Docker 対応カヤックでもECS にWebApp を載っけるのを進めています WebApp をコンテナに押し込んだら、kuiperbelt もコンテナに押し
込みたいが、kuiperbelt を複数台構成にしたときは個別のコンテナにつながるホストとポートをkuiperbelt 自身が知る必要がある

自分につながるホスト名の取自分につながるホスト名の取得得オプションにホスト名orIP アドレスを書くか、無ければを使うコンテナ内ではコンテナ起動時のネットワーク設定によってはで正しいものが取れない

自分につながるホスト名の取自分につながるホスト名の取得得コンテナ起動時にconfig を書き換えてX-Kuiperbelt-Host を正しいものにしている以上はECS の場合です。k8s
とかの場合はまだ試行錯誤中です。誰か助けてくれ

その他課題その他課題 kuiperbelt 単体でスケールアウトさせる需要の声ドキュメント日本語ドキュメントはちゃんと書いてあるのだがロゴがほしい社外のユーザ現状社内しかユーザはいない

これからの展望これからの展望 ekbo-router(cluster mode) 上り対応( 需要があれば) WebSocket 以外の対応 WebRTC が個人的に有望そう
WebSocket over HTTP/2

Net::Kuiperbelt, Alien::Kuiperbelt HTTP 喋れば良いとは言えライブラリがあったほうがみんな使いそう Plack::Middleware とかで実現しても良いですができるのか？

未実装の未来の話: ekbo-router 未来の話: ekbo-router 専用デーモンをWebApp 側に立ててプロキシする識別子の発行はekbo-router が行う

未来の話: ekbo-router 未来の話: ekbo-router prefix base routing kuperbelt インスタンスと識別子のprefix を対応させる
ここは分散KVS が必要...... WebApp はどこに接続があるかを気にせずにローカルのekbo- router に投げれば良い

High (Availability|Performance) WebSocket for P...

High (Availability|Performance) WebSocket for Perl Real-Time Application

More Decks by mackee

Other Decks in Programming

Featured

Transcript