Sora 接続時のクライアントの挙動

クライアントは、基本的にクラスター構成を取るすべてのノードに対して WebScoket 接続を試み、その後、一番早く接続を確立したノードと通信を行います。

クラスターのリレー機能

※ この機能を利用するには、クラスターを構築するノードの数に合わせた「最大ノード数ライセンス」の契約が必要です。

Sora はクラスターのリレー機能を搭載しています。各ノード間で双方向にリレーができるため、どのノードに接続しても特定のチャネルに参加できます。 これまでのクラスター機能では、特定のチャネルに参加するクライアントは特定のノードにしか接続できない仕様でしたが、どのノードに接続しても特定のチャネルに参加できるようにし、スケールアウトを可能にしました。

上記の図では、クライアント B がクライアント A と異なるノードの Sora 2 に接続しても、クラスターのリレー機能により、クライアント A と同じチャネル (Channel ID = egg) に参加できます。

クラスターのアフィニティ機能

※ この機能を利用するには、クラスターを構築するノードの数に合わせた「最大ノード数ライセンス」の契約が必要です。

Sora ではクラスターのリレー機能と合わせて、アフィニティ (= 寄せ) 機能を提供しています。アフィニティ機能とは、同一のチャネルに参加するクライアントはできるだけ同じノードに集めるという仕組みです。 クラスターのリレー機能で無秩序にクライアントを各ノードに分散させるよりも、このアフィニティ機能も同時に利用して、同一チャネルに接続するクライアントは可能な限り同一ノードに寄せた方が、遅延は抑えられます。

上記の図では、先に Channel ID = egg に参加しているクライアントが Sora 1 に接続している状態で、新たにクライアント A が Channel ID = egg に参加しようとして Sora 2 に接続した場合、クライアント A はリダイレクトされ、Sora 1 に接続します。

ただし、アフィニティを有効にした場合でも、Sora 1 に接続しているクライアントの数が設定ファイルで指定する接続数の上限に達していたり、 Sora 1 に障害が発生したりしたような状況では、それ以降にクライアント B が Channel ID = egg に参加しようとして Sora 2 に接続した場合、Sora 1 にリダイレクトされることなく、そのまま Sora 2 に接続します。
※ もし Sora 2 よりも Sora 3 のほうが接続数の上限までに余裕がある場合は、Sora 3 にリダイレクトされます (図の③④)

アフィニティ機能はデフォルトでは有効になっていますが、コネクション単位で有効 / 無効を指定できます。

アフィニティ機能が無効な場合は、先に Channel ID = egg に参加しているクライアントが Sora 1 に接続している状態で、新たにクライアント A が Channel ID = egg に参加しようとして Sora 2 に接続した場合、Sora 1 にリダイレクトされることなく、クラスターリレー機能により、そのまま Sora 2 に接続した状態で、Channel ID = egg に参加できます。

ライセンスで決められた最大同時接続数の合計をクラスターで維持する機能

※ この機能を利用するには、クラスターを構築するノードの数に合わせた「最大ノード数ライセンス」の契約が必要です。

Sora のクラスター機能では、特定のノードが障害などで利用できなくなった場合でも、ライセンスで決められた最大同時接続数の合計をクラスターで維持することが可能です。
たとえば、Sora の 3 ノード構成のクラスターで、1 ノードあたり最大 100 同時接続だった場合、クラスター全体の合計同時接続数は最大で 300 ですが、いずれかの 1 ノードに障害が発生した際には、残りの 2 ノードがそれぞれ 50 同時接続ずつを引き受け、各ノード 150 同時接続ずつ、クラスター全体では 300 同時接続を維持できるようになっています。

クラスターのテンポラリーノード機能

※ この機能を利用するには、クラスターを構築するノードの数に合わせた「最大ノード数ライセンス」の契約が必要です。

テンポラリーノードとは Sora のクラスター構成の維持には影響しないノードのことで、通常のノードとは区別されます。 また、テンポラリーノードは通常のノードと異なり、停止させるだけでクラスターから削除できます。 そのため、追加のノードが必要になった場合には気軽にテンポラリーノードを追加してスケールアウトさせることができ、また、不要になった場合にはテンポラリーノードを停止させることで、手軽にスケールインさせることができます。 このテンポラリーノードは、たとえば、接続数の増減に合わせて一時的にノードを増やしたり減らしたりしたいような場合の利用を想定しています。

通常、クラスターを構築する場合は、クラスター構成の維持に影響するノードの数を奇数にすることを推奨しています。このテンポラリーノードはクラスター構成の維持には影響しないため、上記の図のように一時的にテンポラリーノードを追加した結果、ノード数の合計が偶数でも問題はありません。

クラスター機能の詳細は ドキュメント をご参照ください。
また、Sora をご契約中のお客様向けに、クラスターリレー機能をお試しいただくために必要な 「最大ノード数ライセンス」 を無料で 1 ヶ月間ご提供させていただいています。ご希望のお客様は、ご契約者様専用の Sora サポートまでご連絡ください。

Sora はどのように大規模かつ障害に強い配信を実現しているか

大規模配信について

Sora のリレー機能では、リレー先のノードが多い場合は、ツリー構造の経路を通してデータをリレーします。 以下の図のようなツリー構造を採用することで、特定のノードだけに負荷が集中せず、数百台規模のノードでも安定してリレーを行うことが可能です。 実際のマシンスペックやネットワーク環境によっても変わりますが、視聴者の数が数万〜数十万といった規模の配信にも対応できるようになっています。

障害に強い配信について

Sora では、リレーツリーの構築や維持、データ送信には、高いスケーラビリティと障害耐性を備えた分散アルゴリズムである Plumtree を採用しています。 Plumtree はデータのリレーに使用されるツリー構造の経路とは別に、冗長性を備えた代替経路を複数確保しています。
もし、リレー途中のノードやネットワークに障害や大幅な遅延が発生した場合には、一時的にその代替経路を使ってデータのリレーを行い、その間にツリー自体の再構築も行います。 そのため、部分的な障害が発生した場合でも、他のノードやユーザーへの影響を最小限に抑えることができます。

たとえば、上記の図のように S2 と S5 の間のネットワークが切断した場合、S5 とその配下にある S11・S12 には一時的に代替経路を使ってデータが送信されます。 同時に、あらたなツリー構造が構築され、その後は S2 から送信されるデータは、S6 を経由して S12 とその配下にある S5・S11 にリレーされます。