Confluent：Web3時代のデータブローカー①

先週までのProduct Led Growth（PLG）企業の流れから一転、今週は超エンプラのConfluentを選んだ。理由はいくつかあるのだが、上場から10ヶ月経ち、そのビジネスの展望が割と明瞭になってきたことと、AWS以後のクラウド時代のOSSミドルウェアとしておそらく最も成功したApache Kafkaの生みの親についてインフラ商売オタクとしてはどこかで触れなくてはいけないと、当該ニュースレターを始めた時から思っていたからだ。

とはいえ割とニッチな分野とプロダクトなので、まずはそのカテゴリについて丁寧に説明した上で、いつものようにConfluentのGTMについて、もうひとつのOSSミドルウェアの雄MongoDB（すでに当ニュースレターで解説済み）との比較も交えながら解説していきたい。今週と来週の二部構成となる。

Confluentのビジネスについて説明する前に復習しておく必要があるのがエンタープライズ・サービス・バス（ESB）である。字面からして既につまらなそうに思う読者もいるだろう。その直感は正しい。ESBは本当につまらない概念である。つまらないだけなら無視して良いのだが、少なくともこの30年、そしてこれからの30年において根幹的なアイデアとしてしぶとく生き残り続けるので、外郭くらいは把握しておいても損はないだろう。

大企業には様々なシステムが混在している。その出自は色々だ。志半ば潰えた新規事業の残骸、いつぞや系列SIerが作ってくれた謎システム、買収した子会社の四半期業績を計算するバッチジョブ…それらが複雑に組み合わさって動くことで今日も大企業の面子は保たれている。しかし大企業とてその全てを野放しにしているわけではない。十年に一度くらいは数億から数十億の予算をつけて平準化を試み、システム連携の見直しを進める。

そこで活躍を期待されるのがエンタープライズ・サービス・バスである。ここで言うバスはサヨナラバスのバスでもブラックバスのバスでもなく、各種デバイスがデータを交換するためのハードウェアである（データ）バスに由来する。ESBそのものは概念だという人もいるし、ソフトウェアだという人もいるが、求められる機能をまとめると、以下のようになる。

• ESBはデータ（メッセージとも呼ばれる）を（一時的に）保管することができる

• 各種サービスはESBにデータを置いたり取り出したりすることができる。置くサービスはデータの作成者（Producer）であり、取り出すサービスはデータの消費者（Consumer）である

• ここでいうサービスというのはソフトウェア群を指し、社内ツールもSaaSもすべて「サービス」である

基本的にはこれだけである。この他にもメッセージを加工したりする機能や、メッセージにタグ付けできるような機能が備わっているものもあるが、ESBの本質的な機能ではない。あえてソフトウェアの世界内で類例を探すなら、メールサーバーのようなものだと思ってくれて良い。メッセージを受け取り、メッセージを読ませる。たったそれだけである。

そんなものが何の役に立つのかと思うかもしれない。ということでメールサーバーの比喩を続け、メールサーバーがない世界を想像してみる。そうすると、AさんがBさんにメッセージを送りたいと思った時、AさんもBさんも同時にオンラインでなくてはならない。なぜならAさんがメッセージを作成した時に、それを一時的に置いておく場所がないからだ。これは大変非効率だ。AさんとBさんが違う時間帯に住んでいたら尚更である。仮にAさんがBさんとCさんとDさん3名にメッセージを送る必要があり、Aさんは東京、Bさんはニューデリー、Cさんはパリ、Dさんはロサンゼルスに住んでいるとしよう。そうするとメッセージのやり取りができるのは日本の深夜の1-2時間だけとなってしまう。さもないと誰かの就寝時間と被り、その人にメッセージが到達しないからだ。このシステム、非常に理不尽に聞こえるかもしれないが、我々が日常的に使っているもので、電話と呼ばれる同期コミュニケーションがまさにこれである。対してEメールは非同期コミュニケーションであり、これを円滑に行うためにはメールを一時的に保存しておくメールサーバーが必要になる、というわけだ。

ここで比喩の世界から戻ってくると、ESBというのは「数多くの作成者と消費者の間での数多くのメッセージのやり取りに耐え得るメールサーバーのようなもの」と定義することができる。これがあるのとないのでは、先に触れたような複雑怪奇なエンタープライズ内の諸サービスの連携コストは大きく変わってくる。例えば下の図は2005年あたりのアメリカの大手保険会社MetLifeのアーキテクチャである。詳細は出典元のEnterprise Architecture As Strategyに譲るが、保険業のように顧客データの共有は必須だが、営業・引受査定・コンプライアンスなど専門性の高い部門が独立して動く必要があるタイプの組織（出典元ではCoordinationモデルと呼ばれる）では、特にESBの重要性が増す。各部門はお互いに直接顧客データに関する情報をやり取りするのではなく、全て（より現実的には業務上大事な）のアップデートをESBに投げ込み、ESBから取り込むことで、コミュニケーションの効率化を図ることができるからだ。

もちろん全ての企業にESBが必要というわけではない。ESBはあくまでも複雑な情報のやり取りをスケールさせるための考え方であり技術なので、中小企業よりも大企業、単一製品企業より製品ポートフォリオ企業の方がそのニーズは大きい。と同時に最近だとUberやメルカリのように製品が多数のソフトウェアサービスを組み合わせることで成り立っているデジタルビジネスも多く、そういう場面でもESBは活躍している。「どう平準化（Standardization）と連携（Integration）のバランスを取るか」という経営課題に対して、データのやり取りの観点から一定の解を提供するのがESBだと言える。

長々とESBについて説明したのは、ESBの概念をしっかり抑えることで、ConfluentのGTMを「ESBの民主化とクラウド化」と簡潔に記述できるからだ。より正確には、「Apache KafkaでESBを民主化し、それをConfluentがクラウド文脈で商用化している」と言える。

Confluentの物語はApache Kafka（Apacheは“Sir”みたいな栄誉称号だと思ってくれれば良く、以下Kafka）抜きには語れず、KafkaはLinkedIn抜きには語れない。2010年前後、当時LinkedInでデータ基盤のアーキテクトをしていたJay Kreps氏（現Confluent CEO）は、まさにESBの問題を解決しようとしていた。一大SNSに成長したLinkedIn社内には数多くの社内サービスが立ち上がっており、それらがうまくユーザーデータを共有する仕組みが必要だったのだ。加えてユーザーはすでに1億人を超えており、既存の商用ソフトウェアでは湧いてでてくるデータを捌ききれる確証はなかった。そこでKreps氏は同僚のJun RaoとNeha Narkhedeと協力して、独自のESBの開発に着手することになる。こうして2011年に誕生したのがKafkaだ。

僕も2012年ごろにKafkaについてKreps氏が発表するミートアップに行ったことがあるのだが、まさか当時はその後彼がRao・Narkhede両氏とKafkaを製品の中心に据えた会社、のちのConfluentを創業するとは思ってはいなかった。Kreps氏はいわゆるアルファギークで、プレゼンこそ上手だしソフトウェアアーキテクトとしても一流だったが、到底自分でビジネスをやるタイプの人間には見えなかったからだ。I/Oの効率を考えてsendfileを使っているのがKafkaのパフォーマンスの肝だ、みたいな話を熱弁していたことを覚えている。

しかしその2年後、Kreps氏はKafkaプロジェクトのコアメンバーを誘い、Kafkaの商用化を目的にConfluentを立ち上げる。2014年にBenchmarkがリードするかたちで$6.9MのシリーズAを調達、2015年に$24MのシリーズB、2017年に$50MのシリーズC、2019年に$125MのシリーズD、そして2020年コロナ禍に$250のシリーズEを調達し、満を持して2021年6月にNASDAQに上場した。売上はすでに年間$400M（約500億円）に迫る勢いだ。

コアの技術であるKafkaも、今やFortune 100のうち8割が使っていると言われ、新時代ESBのデファクト標準となりつつある。UberやDoordashといったメガベンチャーからBMWやGoldman Sachsといった伝統的企業、Dapper Labsのようなweb3の最新ユニコーンまで、至るところでKafkaは導入されており、その家元であり商用化ベンダーであるConfluentは、DXの中枢神経と呼んでも過言ではなく、その存在感は日々増すばかりである。

以上前置きが長くなった。ここからConfluentのビジネスについて順々に調べていくことにする。