Clubhouseがクラウドonクラウドであることのコストメリット
Clubhouseが国内で広まるとすぐ、エンジニアたちがその通信先を調べて（パケットをキャプチャして）、どのような技術の積み上げでできているのかを推測し始めました。そのあたりの調査や議論をきちんと追えている自信はないのですが、以下の2件は興味深い情報が集まっていました。
音声の転送プロトコル、圧縮アルゴリズム、スピーカー側とリスナー側で仕組みを変えている点など、興味深い情報が満載です。
Clubhouseのクラウドの3階建て構成
ただ個人的に特に興味をひかれたのは、通信先でした。まずパケットキャプチャ結果で出てくる主要IPアドレスは107.155.29.138で、これはZenlayerが押さえているものです。
送り先は以下の2箇所だけ
107.155.29.138 4005 これが9割以上
164.52.32.58 8913 たまにこれが交じる
（大久保康平 - Facebook）
IPで調べたらZenlayerというサービスで持ってるIPみたい。それの東京のアクセスポイントじゃないかな。
（高橋 達矢 - Facebook）
一方でドメイン名を見ると、こちらはAgora.ioのものであるとのことです。
・利用しているリアルタイム配信サービスは Agora.io
・DNS 見ただけ
・ap-japan.agora.io が見えた
（Clubhouse リアルタイム配信の仕組みについて）
IPアドレスとドメイン名が違う理由は、難しくありません。
まずAgora.ioはリアルタイムの「クリスタル・クリアな」ボイスチャットなどのサービスを提供するPaaS事業者です。これにはソフトウェアの優秀性と同時に、利用者の近くにサーバーを持ち低遅延のネットワークで通信することが必要ですが、ここにAgora.ioはZenlayerをはじめとするインフラサービスを使っているようです。
Agora.ioは複数の（Rackspace、DigitalOcean、Zenlayerなどを含む）コロケーションホスティングを使っています。パブリッククラウド（例えばAWS）のノードも使っていますが、これは確実なバックアップとキャパシティバースト（一時的な急激な利用増）に備えるためのものです。
（James Fang's answer to What servers does agora.io use? - Quora）
Zenlayerはまさに、グローバルな超低遅延ネットワークやベアメタルクラウドを提供するエッジクラウドのIaaS事業者です。
同社は目下、世界に120のノードを持ち、基幹ネットワークの速度は8.3Tbpsに達する。[...]Zenlayerの創業者でCEOをつとめるJoe Zhu氏は「現在、我々のプラットフォームを利用する企業は25ミリ秒（0.025秒）以内に世界中の約80%のユーザーにリーチすることができるが、これではまだ不十分だ。我々はこの数字を10ミリ秒（0.01秒）にまで速めたい」と語った。
（世界でエッジコンピューティングサービスを提供する「Zenlayer」、0.01秒で膨大データ処理を目指す | 36Kr Japan）
これらを考え合わせると、ClubhouseというSaaSはAgora.ioというPaaSサービスの上に構築されていて、Agora.ioはZenlayerなどのIaaSサービス上に構築されているというクラウドの3階建て構成が見えてきます。
もちろん、Clubhouseは音声を流す以外の機能や処理もありますから、他のクラウドもつかっているでしょうし、自前のサーバーを持っている可能性もないではありません。こちらではAWSやCloudflareの使用を想定していますし、前述のパケットキャプチャが示すもう一つのIPアドレス「164.52.32.58」は米国に籍を置くデータセンター事業者Capitalonline Dataの香港サイトのものです。ですが一番興味深く大きな部分は、このクラウドの3階建て構成だと考えられます。
ClubhouseがAgora.io上にあるメリット
「Clubhouseのリアルタイム配信の仕組みについて」では次のような雑感が付されています。
・配信部分が自力ではなく、利用時間単位で課金されるサービスを利用しているので利益を出すのが大変そう
・小規模な間はいいが、中規模以降になると明らかに費用を圧迫してくる
ここはちょっと考えさせられる、面白いポイントだと思いました。Clubhouseの3階建てクラウド構成のコスト影響は、スタートアップのクラウドコンピューティングとの付き合い方を考えるいいサンプルになりそうです。まずAgora.ioやZenlayerの料金体系は、実際にはどうなっているのでしょう。
Agora.ioで使われていそうなサービスとしては音声チャットの「Voice Call」と録音機能の「Cloud Recording」がまず挙げられそうです。Agora.ioの料金プランは公開されていて、Voiceは通話時間1,000分につき0.99ドル、Recordingは録音時間1分につき0.00149ドルです。Zenlayerでは「Baremetal Cloud」「Cloud Network」「Contents Delivery Network」あたりでしょうか。Baremetal Cloudは月額制でSサイズ$99～Lサイズ$599。残る2サービスは詳細不明ですが、仮に類似AWSサービスと同じ料金体系だとするとCloud Networkは接続時間毎＋転送量毎、Contents Delivery Networkは転送量毎＋リクエスト数毎の従量料金が考えられそうです。
ご存知の通り、Clubhouseは現在急成長中です。ここ数日、5,000人級の「満員」ルームがいくつか開催され、その裏側では勝手に終了してしまうルームが発生し「Clubhouse不安定」とささやかれるほどでした（私も今日の15時ごろ、ルームが落ちる経験を初めてしました）。では利用が急増した時に、コストはどうなるでしょう？Agora.ioの料金体系では、使った分だけ請求されます。zenlayerの料金体系では、使ったか否かを問わず事前に契約した分だけ請求され、契約した分以上のニーズを掘り起こせた（営業上の大勝利！）としても使うことができません（大勝利の放棄）。
Zenlayerのリードタイムと賞味期限と最少発注量
もう少しここは掘り下げたいと思います。上の図中、青地で書いているのは「実際にルームが使われた時間」にコストが比例するものです。赤字で書いているものは「あらかじめ準備しておくキャパシティ」にコストが比例するものです。Agora.ioを使っている分には、コストは実際にルームが使われた分、つまりサービスの成長に応じた支払い、Pay-as-you-Growになっています。Zenlayerを使う場合、ひと月分の成長を見込んで、ピークに合わせたキャパシティを契約し、その分を固定費用で支払うことになります。
ITサービスにおける「キャパシティ」は、製造販売における「在庫」に近い性格があるとおもいます。クラウドの主要モデルはキャパシティが需要増減に合わせて即座に自動的に必要なだけ拡縮する「Rapid elasticity」「Auto Scalilng」ですが、オンプレミスやそれに近いベアメタルクラウドでは「需要予測」「事前調達（契約）」です。ここではAgora.ioは前者のモデルですが、Zenlayerは1か月分を事前契約する後者のモデルに見えます。
必要なだけ即日配送されるAmazon取扱商品を仕入れるなら需要予測はほとんど要らないでしょう。しかし追加注文してから納品までの基幹、いわゆる調達リードタイムが2週間とか1か月の商品仕入れでは慎重に需要予測し、在庫をコントロールするでしょう。加えて、それが賞味期限のあるものだったらどうなるでしょう。長い調達リードタイムの間に欠品せず、短い賞味期限内に売り切れる分量という絶妙の需要予測が求められます。オンプレミスサーバーは賞味期限の長い（減価償却期間5年）在庫ですが、as a Serviceで契約するベアメタルクラウドインスタンスは賞味期限の短い（月額課金なら1か月）の在庫です。売れなければ廃棄（ムダ）確定であるここでの需要予測はシビアです。
Clubhouse側の事情も、在庫予測面から考えるとハードです。Clubhouseは急成長期にあります。その需要予測は、日用品ではなく特需の需要予測に近くなります。それも前述の通り賞味期限が短く特需傾向の食品、例えばクリスマスケーキや恵方巻のような需要予測になってきます。売切れることより品切れを出さないことを優先していた時期、これらがどれだけのフードロスを生んでいたかは大きな話題になりました。ただし来年も特需が来るこれらと違い、Clubhouseには次の機会があるか分かりません。キャパシティ不足でユーザーが使えないという「欠品」を出すわけにはいかないフェーズです。
もう一つ難しいのは、Zenlayerの調達単位です。Zenlayer1台分のコストは、SサイズでAgora.ioの通話＋録音約4万分（665時間強）、Lサイズでは約24万分（4,000時間強）に相当します。「1個から買えます」「1,000個単位での注文になります」といった制約を最少発注量と言いますが、これが大きいと、仕入れが過剰だった時に出る無駄の量や、仕入れが不足した時に売り損ねる欠品量が大きくなります。
まとめると、Zenlayerは調達リードタイムが1か月と長く、最少発注量がSサイズ665時間分、Lサイズ4,000時間分と大きく、賞味期限1か月と足の速い、在庫管理と需要予測の腕がシビアに問われるリソースなのです。それを急成長特需の中でハンドリングするというのは非常に難しいし、それだけで一人ぐらい手がふさがる業務です。Clubhouseにとって「エンドユーザーが使う分のリソースが不足なく提供され、エンドユーザーが使った分だけの支払いで済む」Agora.ioを直接のインフラに使うことは、シビアな需要予測と在庫管理のアウトソースという側面もあると思います。これにより、Clubhouseは無駄も不足もない「サービス規模とコストが連動する」コスト構造を確実なものにできます。
Zenlayerが特殊なのではなく、一般に物理レイヤーに近いほど固定費の性格を強め低額で、より抽象化されたマネージドサービスになるほど従量課金の性格が強まり単価が高額な傾向があります。配信部分のようなバックエンド機能を自前化することの是非は、Agora.io相当の仕組みを自前で作れるかということ、Agora.ioの単価が高いか安いかということの他に、こうしたコストとサービス規模の連動性、困難な需要予測と在庫管理が不要であるということも一つのキーポイントになるのだと思います。
ZyngaやDropboxのクラウドジャーニー
ではClubhouseはいつまでAgora.io上にあるのでしょう。技術的に配信側を自力で持てるようになるまででしょうか。小規模から中規模に成長した時でしょうか。何か参考になる例はあるでしょうか。
バックエンドをパブリッククラウドにするのか自前（オンプレミス）にするのかという議論は、SaaSやPaaSなど上位レイヤーのサービス事業者について回る議論です。それは用途によるという考え方が一般的ですが、規模によるという考え方もあります。これはどちらかというと社内ITインフラを意識したものではないかと思われますが、クリエーションラインの鈴木逸平氏が「適切なクラウド利用の1つの尺度として企業のサイズがある」という見方を示しています。
おもしろいことに、記事中では事例として挙げられているのは、企業内ITインフラではなく当時ソーシャルゲームのためのゲームプラットフォームのPaaSを提供していたZyngaです。Zyngaはゲームプラットフォームを当初AWS上に構築していましたが、この時期にコスト削減を目的の一つとして、オンプレミスの自社クラウド「zCloud」構築に舵を切りました。利用の急増減がある従量課金が向いている時期から、安定した利用量が見込め単価の低いキャパシティをあらかじめ固定費で持っておく時期に移った、と言えます。Zyngaはこの時期「IaaS市場に参入、AWSと競合へ」と報じられます。
しかしZyngaは、最終的にzCloudを廃止し、またAWS上に戻ります。これによる恩恵の一つは「予測モデルに依存するのではなく、テクノロジーの需要にリアルタイムで適応するため、コストとリスクが削減された」ことだとされています。これは「Zenlayerのリードタイムと賞味期限と最少発注量」に書いた在庫管理と需要予測のアウトソース、そのメリットそのものです。
サービス事業者のクラウドジャーニーとしてよく知られた他の事例としては、Dropboxがあります。同社は長年AWS（特にS3）をバックエンドとして構築・提供されてきたサービスでしたが、2018年に「自社データセンターに“先祖返り”」しました。この理由としてまず「Amazon S3の利用で発生するランニングコストを削減」することが重要だったと語られています。同様にFacebookは自社データセンターを自社設計で構え、同社傘下に収まったInstagramもそこを基盤としているようです。
逆にGunghoは2019年にAWSへの完全移行を果たし、自社データセンターをクローズしました。Twitterは2010年から自社データセンターへの移行を行い、一部の処理でAWSやGCPも使うにとどまっていましたが、2020年に最重要機能であるフィードの提供を自社DCとAWSにまたがるハイブリッドクラウド化する計画を立ち上げました。
DropboxやFacebookやInstagramのグループ、そしてZyngaやGunghoのグループを比較すると、一つはコアサービスが固まっていて利用規模が安定しているかという違いが挙げられそうです。ZyngaやGunghoはゲームタイトル一つ一つが個々のサービスで、その中でユーザーと利用規模の増減が大きな山を描き、世代交代していきます。DropboxやFacebookやInstagramはコアサービスの追加はあっても世代公開はなく、利用規模ももはや急激に増減するフェーズではありません。でもTwitterの事例はどう整理すればよいでしょう。
この議論は結局、一筋縄でいかないのですが、少なくとも「単価を下げるために自前化する」以外にもいろんな結論があることだけは分かります。
Clubhouseの脱Agora.ioを考える
ClubhouseがいつまでもAgora.ioの上にあり続けるのか、それとも配信部分を自力にするのかというのは、これからウォッチしていきたい点の一つです。「コアサービスの固定化と利用規模の安定」という点が判断の一つの基準になるとすれば、それはClubhouseの「サービスの成長」や「サービスのフェーズ」に連動するかもしれません。
Clubhouseのコアの機能は音声チャットルームであり続けるでしょうが、ユーザー数は明らかに急成長中で、利用規模（ルームでの通話量）はそれに輪をかけて急成長中かつ、おそらくその伸び方は乱高下しているでしょう。この急成長フェーズが続く限り、自前化によるコスト低減の余地より、Agora.ioのような完全従量性のコスト構造を望むかもしれません。もしそうなら、Clubhouseの脱Agora.ioは資金調達シリーズAの要である利用規模拡大、シリーズBの要である収益化のフェーズを抜けて、売上拡大時期から利益率重視の時期に移ることの兆しになるわけです。
もちろん、もっと別の判断もあるかもしれません。別の要因が絡むかもしれません。例えばClubhouseはどこに買われてExitするかといった話題も出ていますが、もしFacebookに吸収されればInstagramの前例のように同社データセンターに移り、Zenlayerなどの上に構築されたAgora.ioというサービスとは別れざるを得なくなるでしょう。
クラウドの三階建て構成からスタートし、目を見張るほどの急成長を見せているClubhouseは、サービス事業のクラウドとの付き合い方を考えていくうえでの注目の題材にもなるかもしれないと思います。
（追記）
「Zenlayerのリードタイムと賞味期限と最少発注量」の説を追加し、前後の説明を多少修正しました。