WebRTC のようなリアルタイム通信で求められるのは「一部のノードに問題が起きても利用し続けられる」事だと考えています。
そのため時雨堂では自社製品である WebRTC SFU Sora にクラスター機能を搭載し、一つのノードに障害が起きた場合でも再接続を行えばすぐにまた利用できるような仕組みを実現しています。
2022 年 6 月にリリース予定の次のバージョンでは、クラスター機能を改善し、より障害に強く、さらにクラスターの運用コストを下げる仕組みを入れています。
まとめ
- 起動したら自動でクラスターを構築し始める
- スプリットブレインが発生し、クラスターの全ノード数に対して、参加しているノードが半数未満になったサブクラスターはすべての接続を受け入れなくなる
- 過半数のノードが参加しているクラスターに自動で再参加する
スプリットブレインについて
こちらがわかりやすいです。
https://docs.oracle.com/cd/E19787-01/820-6910/6ni73qiv8/index.html
クラスター機能
Sora のクラスター機能は「どのノードがどのチャネル（一般的にはルームや部屋）を担当するか」という情報をすべてのノードで共有しています。そのため、どのノードに繋ぎに行っても適切なノードに案内される仕組みが入っています。
またノードがどのチャネルを担当するかは、クラスターに参加しているノードそれぞれの同時接続数を確認し、空いているノードへ新規チャネルの担当を割り当てるため、負荷分散的な機能も含まれています。
クラスターの自動構築
今までのクラスター構築は手動でクラスターへの参加を行う必要がありましたが、次のリリースからはクラスターの構築を自動で行います。
仕組みとしては Sora の設定ファイルである sora.conf に、最初にクラスターの参加を試みるノード一覧を登録するだけです。
contact_node_name_list = sora1@192.0.2.1, sora2@192.0.2.2, sora3@192.0.2.3あとは Sora を起動させるだけで、これらのノードに自動でコンタクトを取りクラスターを構築します。
クラスターの分断（スプリットブレイン）発生時の挙動
クラスターで一番怖いのはスプリットブレインです。スプリットブレインとはクラスターがネットワーク切断などによりノードそれぞれが分断した状態になり、それぞれのノードが「相手のノードは死んだが自分は大丈夫」という状態になってしまう事です。
この状態が発生するとチャネル情報の共有がされていない状態になるため、複数のノードで同じチャネルが作られてしまい、サービスとしては破綻してしまいます。
これを回避するために Sora ではクラスターの分断が起きた際に「クラスターに参加しているノード数がもともとの半数未満になったサブクラスター」は「すべての接続を切断し、新規の接続を受け付けない」という仕組みを追加しました。
これにより、例えば 3 ノードで組んでいたクラスターが 2 と 1 に分かれてしまった場合、1 ノードの方は一切のリクエストを受け付けなくなります。そのためスプリットブレインが発生しなくなります。
ただ 3 ノードが 1 と 1 と 1 に分かれた時点で、サービス自体がすべて停止しますので、その場合は手動での復旧が必要になります。これを回避するにはクラスターのノード数を増やすことで発生確率を減らすことができます。
クラスター分断からの自動復旧
半数未満になったノードはすべての接続を切断し、すべての接続を受け入れなくしたタイミングから「自動でクラスターの再参加」を試みます。
クラスターに参加していた時に保持していた情報を利用し再度参加をしますが、このときに「過半数のノードが存在しているクラスター」へのみ参加を行います。この仕組みによりネットワークの分断が復旧さえすればクラスターも自動で復旧するようになっています。
WebRTC のような低遅延が重視される場合は同じノードに接続を集めるという処理が一番効果的です。時雨堂では低遅延でありつつ耐障害性を持たせるという仕組みを開発してきました。
今後も耐障害性を向上し、運用コストを減らし、低遅延を維持する製品を提供していきます。
Twitter で “The Nitche Programmer” という記事が流れてきたので、自分もおそらくニッチプログラマーのくくりには入ると思うので雑に何か書いておこうと思います。
思ったことを適当に書いていくので読みにくいと思います。適当に流し読みしてください。
まとめ
ニッチかどうかはどうでもいい。
ニッチプログラマー
はじめてのちゃんとしたプログラミングは Python 2.2 あたりから始まり、その後 Erlang/OTP へ切り替えて 10 年以上 Erlang/OTP を書いてご飯を食べています。
最近では WebRTC をメインでやっており、 Erlang/OTP + WebRTC という組み合わせであればおそらく日本では社員を除けば自分だけというくらいニッチです。世界的に見ても Erlang/OTP + WebRTC の製品を作ってパッケージを売っている会社は自社しか知りません。
なぜニッチプログラマーなのか
最初はウェブアプリに興味を持っていて Python + Django をやっていたのですが、そのうち Web サーバに興味が移り、仕事でミドルウェアに関わるように完全にミドルウェアの虜になり、通信系ミドルウェアを開発する言語として Erlang/OTP を知り、そこからずっと通信系ミドルウェア屋をやっています。
つまり、やりたいことやっていたらニッチプログラマーになっていたというだけです。別にお金が欲しいからとか採用が楽になるからとかで、狙ってニッチな言語やニッチな技術をやってるわけではありません。
ニッチプログラマーに求められるもの
ニッチプログラマーに求められるのは実はニッチな言語に強いことでもニッチな技術に強いことでもありません。それらニッチな技術を使ってお金を稼ぐ能力です。
ニッチな技術をお金に換えるのは実はとても難しいです。そのニッチな技術自体をお金に換えることが難しいからです。たとえば今国内で Erlang VM 系の仕事を探したとしても、良い金額で手を上げてくれるのは mixi くらいでしょう。
ニッチかどうかはどうでもいい
Erlang/OTP で製品を作っていて「Erlang/OTP というニッチ言語で作られているから製品を買わない」と言われた事は一度もありません。つまりニッチかどうかは顧客はどうでもいいのです。
たとえば最近は Rust に明るい社員が入ってきたので Rust + Erlang/OTPで動く WebTransport を利用した新製品を開発したりしています。Rust + Erlang/OTP + WebTransport の組み合わせは相当ニッチでしょう。ただニッチだから選んでいるのではなく、Rust に明るい社員が入ってきて、Rust で書かれた優秀な HTTP/3 ライブラリがあり、Erlang/OTP と Rust を組み合わせるライブラリがあり、プロトコル処理以外はすべて Erlang/OTP で書いた方が自社が持ってるパッケージ製品ノウハウが生かせるからです。
つまりニッチかどうかじゃなくて効率が良いから使ってるだけです。もちろん長年 Erlang/OTP を使ってきた事による影響はあると思います。ただ、何度も言いますがニッチだからその言語を使ってるわけではありません。作りたいものを作る事にマッチしていたからです。
気付いたらよくわからないが世間から見るとニッチなプログラマーになっていたというだけです。自分からすれば別にそんなのどうでもいいです。
自分がやりたいことがやれていればそれで十分なので。
元々の記事は「ニッチな言語の場合は賃金は素晴らしく、競争は少なく、面接のプロセスはほとんどの場合非常に人道的で、ニッチな言語が主流になったら別のニッチな言語を探す」という結論の話でした。
これは「好条件を得るためにニッチな技術を続けていく」という話なので、お金を稼ぐ戦略としては悪くないと思います。ただこれを続けられる人がどれだけいるのかは少し疑問です。
時雨堂では Erlang/OTP 関連の OSS を Fork して運用しています。Fork をするにあたって最低限の方針を雑にまとめてみました。
自社製品で利用する OSS である
当たり前ですが 一応。
OSS のライセンスが明確かどうか
LICENSE ファイルがあり、ライセンスが明確になっていること。さらに OSI 準拠の OSS であることを条件に Fork しています。
Pull-Request は可能な限りだす
Pull-Request を出さずに Fork するのは可能な限り避けています。ただし、 Pull-Request を出しても採用されにくい時雨堂固有の機能の場合は Pull-Request を出さずに Fork することもあります。
Fork する理由
Fork する理由はシンプルで、Pull-Request が採用されるまでの時間がもったいないからです。
Fork の運用
まず Fork したらかならず shiguredo というブランチを切り、デフォルトブランチに設定します。こちらに変更を加えていきます。コミットログは基本的に Fork 元にあわせており、ほとんどが英語になります。
利用する際は必ずタグを打ちます。タグは時雨堂バージョニングを採用します。YYYY.RELEASE.FIX というバージョン形式です。
Erlang/OTP 系のライブラリの場合は hex.pm への登録を行う際に、app.src の pkg で shiguredo_ という prefix をつけます。
実際に運用している Fork
実際に運用しているのは 3 つのリポジトリです。すべて Pull-Request や Issue は立てていますが、まだ対応されていないものがあるため Fork をしています。
- https://github.com/shiguredo/redbug
- https://github.com/shiguredo/erlang_ls
- https://github.com/shiguredo/sync
Fork を閉じるタイミング
Pull-Request がマージされて、タグがつけられ、リリースされたタイミングで閉じます。
LabStack LLC は Go のウェブフレームワークである echo を開発している企業です。
時雨堂では自社サービスのバックエンドには Go のウェブフレームワークである Gin を採用してきました。ただ Gin 自体が思った以上に活発にメンテナンスされていないことや、依存性が多いことが気になっていました。
もともと echo 自体は知っていて、昔試したことはあるのですが Gin の方が多機能で欲しい機能が一通りありそうということで Gin を採用していました。
ただ、 Go でのバックエンドの開発にも慣れてきたことから、よりシンプルなフレームワークの切り替えを検討しており、新規サービスを作っている中でせっかくなので Gin から echo に切り替えてみることにしました。
実際切り替え自体は 1–2 時間程度でおわりました。はまりどころは特になく、むしろコード自体がへりました。Gin で気になってた空 return ではなく error を返すモデルは Go っぽくて気に入っています。
仕組み自体もシンプルで echo.Context が少し特殊なくらいですが、ここはカスタマイズをする前提で考えると気にしなくてよさそうという判断にいたりました。
実際社員にも切り替えたコードをレビューしてもらいましたが、特に違和感はなかったようで、今後時雨堂では echo を利用していくという方針にしました。
echo を開発している LabStack が GitHub スポンサーを募集していたので、せっかくだしということで $250 (一番高いプラン) でのスポンサーになってみました。Logo or name on project website と書いてあったので、そのうち時雨堂のロゴが echo プロジェクトのウェブサイトに乗ると思います。
時雨堂は多くの OSS を利用して自社製品を開発しています。少しでも利用している OSS に還元しようと考えており、多くの OSS スポンサーになっています。
今後も自分たちが利用している OSS のスポンサーが継続できるよう、OSS を活用した良い製品を作り続けて、利益を上げ、OSS へ還元できればと思っています。
なんだそれという人がいると思うので、Cloudflare Blog の引用から紹介。
Cloudflare WARPをローンチしました。ボタンを押すだけで、ユーザーはWireGuardトンネルを使用して、近くのCloudflareデータセンターを経由しながら、モバイル端末をインターネット全体に接続することができます。Cloudflareが保護するサイトへのトラフィックはさらに高速化され、インターネット全体で、ユーザー体験がより安全でプライベートになりました。つまり、ざっくりいってしまうとプライベートリレー機能です。
WARPは、「VPN」が何を意味するのかを知らないユーザーでも、VPNが提供する保護を簡単に取得できるべきだという理念に基づいて構築されました。しかしながら、旧来の企業VPNに精通している当社では、これよりも優れた何かを必要としていました。BoringTunという独自のWireGuard 実装を新たに取り入れることになりました。導入はアプリをインストールするだけでよく、とても簡単です。
Cloudflareではお客様の個人データをスヌープしたり販売することはありません。また、DNS-over-HTTPS または DNS-over-TLSを当社の1.1.1.1リゾルバーにお使いの場合、DNSリクエストはセキュアなチャネルで送信されます。つまり、1.1.1.1リゾルバーを使うと、プライバシー保護に加えて、傍受者がユーザーのDNSリクエストを見ることができなくなるということです。信じられない方もいらっしゃるかもしれませんが、事実です。1 アカウント最大 5 デバイスまで指定可能で、価格は月 $4.99 で利用可能です。おすすめです。
導入すると以下のような感じのアプリがメニューバーに常駐します。無効化するのも簡単dえす。
