Part 1:コンフルエント(CFLT)データストリーミングリーダーの強み(競争優位性)分析と今後の成長見通し・将来性を徹底解説!

- コンフルエント(CFLT)はデータ・ストリーミングの領域でカテゴリーを定義するベンダーであり、顧客ベースが拡大し、持続的な成長の大きな可能性を秘めています。
- Part 1は、データ・ストリーミングの進歩を支えるメッセージ・キュー・テクノロジーについて、基礎的な理解を深めることを目的としています。
- この基礎を固めることで、同社と競合を完全に比較評価し、デジタルの進化が続く中で、同社の将来性を評価することが可能になります。
- Part 2では、技術的な理解をビジネス分析に移し、同社の詳細なバリュエーション分析を解説していきます。
コンフルエント(CFLT)の概要
コンフルエント(CFLT)は高水準のバリュエーションで取引されていることから、投資対象外と見られることも多い銘柄である。
以下が同社の重要なポイントである。
・データストリーミングのリーダーである。
・市場浸透の初期段階にあり、拡大するユーザーベースを収益化する大きな可能性を秘めている。
・ビッグデータのトレンドにも合致している。
・ニッチな分野ではほとんど競合に直面していない。
・コネクティビティ、ガバナンス、ストリーム処理など多くの成長機会がある。
・TAM(獲得可能な最大市場規模)は広大で、同社はデータ分析チェーンにおいて極めて重要である。
・経営陣は製品開発、マーケティング、投資家対応において有能で、ウォール街に消極的な通常のハイテク企業とは対照的である。
・同社のKoraアーキテクチャと刷新されたクラウド・サービスは、イノベーションを大きく前進させ、創業当初のような企業の活力を維持している。
※Koraアーキテクチャ:コンフルエントによって提供されるApache Kafkaのマネージドサービスの一部で、特にクラウド環境での高い可用性、スケーラビリティ、セキュリティを実現するために設計されたもの。このアーキテクチャは、Kafkaの強力なストリーミング機能を最大限に活用しながら、運用負荷を大幅に軽減する。
※Apache Kafka:オープンソースのストリーミングプラットフォームであり、高スループット、低レイテンシーのリアルタイムデータ処理を目的としている。Kafkaは、LinkedInによって開発され、Apache Software Foundationによって管理されている。
しかし、財務的な懸念、特に高額な株式ベースの報酬(SBC)が顧客の熱意を抑え、同社の技術的な強みを影に隠してしまうことが多い。
同社は、過去の分析で取り上げたスノーフレーク(SNOW)の投資家が経験したような、より良い投資機会を定期的に提供している銘柄である。
本稿では、メッセージ・キューイングシステム、主要技術、製品、アーキテクチャー、同社のビジネスモデルの技術的概要から触れていきたい。
これらの基本を理解することは、投資家がコンフルエントの将来を評価する上で極めて重要である。
次回のレポートでは、よりビジネス面にフォーカスする予定である。
コンフルエント(CFLT)のミドルウェア / メッセージ・キュー / Pub-Subに関して
オペレーティングシステム、データベース、ミドルウェアはITインフラのバックボーンを形成しており、中でもメッセージ・キューは重要なミドルウェアコンポーネントである。
そして、代替的なテクノロジーを作る上での難易度を評価することは、このような技術の重要性を評価するのに役立つと言える。
AGI、分散システム、リアルタイムシステムなどの分野は、エンジニアリングに大きな課題をもたらす。
メッセージ・キュー・ミドルウェアは、コンフルエント(CFLT)の業務の中心であるデータフローを効率的に管理する上で鍵となる。
同社は、Apache Kafkaオープンソースプロジェクトのソフトウェアを提供しており、Pub-Subモデルによるイベントストリーミングに焦点を当てている。
※Pub-Subモデル(Publish-Subscribeモデル):メッセージングシステムの一種で、送信者(パブリッシャー)と受信者(サブスクライバー)を直接結びつけずにメッセージを配信するアーキテクチャのこと。このモデルは、疎結合でスケーラブルなシステムを構築するために広く使用されている。
その製品には以下が含まれる。
・Confluent Platform(CP):オンプレミスのソフトウェアライセンスとサポート
・Confluent Cloud(CC):消費ベースのクラウド(cloud-delivered)as-a-Serviceを提供
これらの製品は、データコネクター、ストリーミング、ガバナンス、処理を容易にする。
イベント・ストリーミングは、システム間でイベント(新規ユーザー登録やIoTアラートなど)を転送するもので、同社が最も注力しているエリアである。
更に、同社は最近ストリーム処理に進出し、2023年1月にApache Flinkサービスを提供するImmerockを買収している。
まず、同社とその競合他社を検証する前に、メッセージ・キュー(MQ)の必要性を理解することが重要である。
※メッセージ・キュー(MQ):異なるシステムやコンポーネント間で非同期的にメッセージを送受信するための通信手段。メッセージ・キューは、メッセージを一時的に保管するキューを使用して、送信者と受信者が直接接続されていない場合でも通信を可能にする。
メッセージ・キュー(MQ)に関して
初期の始まり:1980年代から2000年
メッセージ・キューの登場
・1980年代:Teknekronがソフトウェア通信のパブリッシュ/サブスクライブモデルの先駆者であるThe Information Bus(TIB)を開発し、システムのモジュール性とスケーラビリティを強化。
・1994:ロイターがTeknekronを買収し、1997年にミドルウェアとリアルタイムデータに特化したTIBCOを設立。TIBCOは2014年に非公開となり、Vista Equity Partnersに買収される。
1990年代の商業的成長
・IBM(IBM)、オラクル(ORCL)、マイクロソフト(MSFT)などの大手企業がメッセージ・キューテクノロジーに投資。
・IBM MQが登場し、その信頼性とセキュリティで注目され、金融や通信などの重要な分野をターゲットにする。
オープンソースと標準の台頭:2000年から2007年
標準化とイノベーション
・2000年代前半:JMS(Java Message Service)やAMQP(Advanced Message Queuing Protocol)と並んでオープンソースのメッセージ・キューが登場し、標準化とクロスプラットフォームの相互運用性を推進。
ActiveMQとRabbitMQがこれらの標準の実装をリード。
※Apache ActiveMQ:オープンソースのメッセージングおよび統合パターン・プロバイダーであり、メッセージブローカーとして機能。ActiveMQは、Java Messaging Service(JMS)に準拠しており、メッセージの送信、受信、保存を効率的に行うための機能を提供。
※RabbitMQ:オープンソースのメッセージブローカーソフトウェアであり、メッセージキューイングと分散メッセージングを提供。RabbitMQは、さまざまなプログラミング言語やプラットフォームに対応しており、メッセージの送信、受信、保存を効率的に行うための機能を提供。
課題とソリューション
・サン・マイクロシステムズはJavaプラットフォーム向けにJMSを開発し、オラクルによる買収につながったが、オラクルは後に制限的な慣行に対する批判に直面する。2003年、ジョン・オハラがAMQPを提案し、JMSの限界を克服。
・2007年:高性能とマイクロ秒のレイテンシーで知られるErlangで開発されたRabbitMQが、AMQPの最初の完全な実装としてデビュー。
インターネットの時代とスケールアップ: 2007年から2018年
・モバイルインターネットの台頭により、より高いスループットが必要となり、KafkaやRocketMQのような分散メッセージ・キューがそれに対応。
・2009年にLinkedInによって開発されたKafkaは、リアルタイムのストリーム処理にメッセージ・キューの機能を適応させることで、大規模なデータストリームとビッグデータ分析をサポート。
・また、Kafkaはマイクロサービス・アーキテクチャに不可欠なトランザクションや遅延メッセージ処理の課題にも対応しており、マイクロサービスの採用も加速。
クラウドネイティブ、サーバーレス、ストリーム処理:2018年以降
・Kafkaは、Apache Sparkと同様にクラウド適応性の課題に直面している。ヤフーが2016年にリリースしたApache Pulsarは、メッセージ配信とストレージを分離した二層アーキテクチャでこれらの課題に対処し、クラウドネイティブの展開を強化。
・メッセージ・キューはクラウド・アーキテクチャの不可欠なコンポーネントへと進化し、マイクロサービス、リアルタイム・データ処理、IoTといった現在のITトレンドに沿った複雑なイベント駆動型アプリケーションをサポート。
※Apache Spark:オープンソースの分散処理システムであり、ビッグデータの処理と分析に特化している。Sparkは、スピード、使いやすさ、汎用性を兼ね備えており、リアルタイムデータストリーミング、機械学習、グラフ処理、バッチ処理など、さまざまな用途で使用されている。カリフォルニア大学バークレー校のAMPLab(Algorithms, Machines, and People Lab)で開発され、Matei Zahariaを含むSparkの開発チームのメンバーが、Databricksを設立。
※Apache Pulsar:オープンソースの分散メッセージングおよびストリーミングプラットフォームで、高スループット、低レイテンシーのメッセージ配信を提供。Pulsarは、リアルタイムデータのストリーミングとメッセージングの両方のニーズを満たすために設計されている。
メッセージ・キュー(MQ)のメリット
概要
メッセージ・キュー(MQ)は、ハイパフォーマンスでスケーラブルかつ信頼性の高いアーキテクチャを実現するために、ITにおいて不可欠な存在である。
そして、メッセージ・キューは、アプリケーションのデカップリング、非同期メッセージング、負荷管理に対応している。
デカップリング
メッセージ・キューは、複数のサービスが同じメッセージを処理することを可能にし、複数のリモートプロシージャコール(RPC)の必要性を減らす。
例えば、データベースやレコメンデーション・エンジンのような複数のシステム向けのメッセージは、直接接続することなく効率的にルーティングされる。
非同期メッセージング
プロデューサーは処理結果を待たないので、異なる間隔でシステムを更新でき、これによりシステムが非同期化され、パフォーマンスが向上する。
ピークカットと谷埋め
メッセージ・キューはトラフィックの急増と停滞を管理し、メッセージをバッファリングしてシステムが許す限り配信し、下流のI/Oサービスのスループットを最適化する。
メッセージ駆動型フレームワーク
メッセージ・キューは、サービスが独立してイベントをサブスクライブおよびパブリッシュするバスとして機能することで、イベント駆動型アーキテクチャを促進し、連携を強化し、ボトルネックを回避する。
その他の利点
・信頼性と耐障害性:メッセージ・キューは、プロデューサーとコンシューマー間のメッセージをバッファリングし、コンシューマーに障害が発生した場合でもメッセージの整合性を確保し、システムの信頼性を高める。
・ワークフロー管理:メッセージ・キューはワークフローをオーケストレーションし、ワークフローのステージ間でメッセージを移動させる。
・モニタリングと監査:メッセージ・キューは、メッセージフローとシステムの健全性に関する洞察を提供し、保存されたメッセージレコードを通じてボトルネックの特定と監査を容易にする。
・外部システムとの統合:メッセージ・キューは、多様なシステムやアプリケーション間の非同期通信を可能にし、直接の接続や統一された技術を必要とせずに、統合の可能性を広げる。
メッセージ・キューモデル
チューブとメッセージボード
RabbitMQ(初期のAMQPモデル)などの従来のメッセージ・キュー(MQ)システムは、KafkaのPub-Subアーキテクチャとは異なる機能を持つ。
RabbitMQはデータプロデューサーとコンシューマーを直接つなぐチューブのように機能し、Kafkaはメッセージバスを介して複数のプロデューサーとコンシューマーをつなぐメッセージボードのように機能する。
一般的にRabbitMQはキュー、KafkaはログまたはPub-Subシステムと呼ばれる。
例えば、大学の先生が生徒の期末試験の点数を伝えたい場合など:
キュー・システム:
・教師が点数を付け、メッセージ・キュー(ティーチング・アシスタントのようなもの)に渡す。
・メッセージ・キューは学生に直接得点を伝える。
ログベースシステム:
・教師はメッセージ・キューが管理するジャーナルにスコアを書き込む。
・生徒はいつスコアが入手できるかを確認し、メッセージ・キューから取得。
キューとログはストリーム処理には欠かせないもので、キューベースかログベースかという運用構造によって分類される。
キューは先入れ先出しで動作し、メッセージの順序を保持し、消費されるまでデータを保存する。
一方、ログはデータを永続的に保存し、複数のアプリケーションに分散させることができ、一対多のシステムとして機能する。
さらに、メッセージ・キュー・システムの「トピック」は、Pub-Subモデルにとって重要な、類似した特性を持つログを分類する。
このセットアップにより、コンシューマーはイベントのサブスクライブとパブリッシュを独立して行うことができ、連携が強化され、ボトルネックが回避される。
また、トピックはメッセージのフィルタリングをサポートし、サブスクライバーが関連性の高いメッセージのみを受信できるようにする。
このブロードキャストとフィルター機能により、Pub-Subシステムはイベント駆動型アプリケーションやリアルタイム処理に理想的なものとなるが、真のPub-Sub機能には、スケーラビリティを確保するためにトピックの使用以上のものが必要となる。
そして、メッセージ・キュー・モデルは、これらの機能性とトレードオフに基づいて変化する。
※続きは「Part 1:コンフルエント(CFLT):Kafkaの高スループットとメッセージングアーキテクチャのトレードオフを徹底解説!」をご覧ください。
その他のコンフルエント(CFLT)はに関するレポートに関心がございましたら、是非、こちらのリンクより、コンフルエントのページにアクセスしていただければと思います。
また、弊社のプロフィール上にて、弊社をフォローしていただくと、最新のレポートがリリースされる度に、リアルタイムでメール経由でお知らせを受け取ることが出来ます。
弊社のテクノロジー関連銘柄に関するレポートに関心がございましたら、是非、フォローしていただければと思います。
アナリスト紹介:コンヴェクィティ
📍テクノロジー担当
コンヴェクィティのその他のテクノロジー関連銘柄のレポートに関心がございましたら、是非、こちらのリンクより、コンヴェクィティのプロフィールページにアクセスしていただければと思います。