「保存してから…」ではもう遅い リアルタイム処理が当たり前に
Confluentは、ビジネス特化型SNS「LinkedIn」の中で、オープンソースのストリーミング送受信基盤「Apache Kafka」を開発したメンバーによって、2014年に創業された。現在もApache Kafkaコミッターの80%が同社に在籍しており、2021年6月24日にはNASDAQに上場を果たしている。現在は世界15ヵ国、2,000名の社員が勤務しており、日本法人であるConfluent Japanは2021年4月に設立された。
現在、あらゆる業界で企業がデジタルファーストへの移行を進めている。単にソフトウェアを利用するのではなく、ビジネスの大半がソフトウェアなしでは成り立たなくなりつつあるのだ。世界中でオンラインショッピングが当たり前になり、オンラインバンキングであればATMの行列に並ぶ必要もない。米国ではタクシーに乗るために、以前は街で手を挙げるか電話で呼んでいたが、現在は配車アプリでの利用が主流になっている。
「こうしたサービスの裏側では、リアルタイムにデータがやりとりされています。顧客が期待する体験を提供するためには新しい考え方が必要で、データインフラストラクチャーにも新たな要件が求められているのです」(山之内氏)
銀行の窓口とオンラインバンキングでの、振り込み処理の違いを比較してみよう。店舗の場合は窓口に行き、身分証明書と通帳を提示して、銀行員は目視で口座との一致を確認。取引が完了したら口座の更新を行う。しかし、オンラインバンキングではアプリを開いて口座にログインし、一瞬で振り込み操作ができる。その裏側では、銀行側のシステムが取引の正当性をリアルタイムに確認しているのである。こういったリアルタイム処理を行うには、一部のプロセスを自動化するのではなく、End-to-Endでの変革が必要となる。
ところが変革を成し遂げるには、データはリアルタイムに処理が行われる必要があるものの、データのインフラはそれに対応できない場合がある。従来のデータベース上では、「データが保存され、休止状態にあること」が条件となっており、連続したリアルタイムのデータの流れに対応していないという制約があるからだ。この場合、各データは孤立した島のようになっており、周期的なバッチ処理で更新されている場合が多い。
「毎回バッチ処理を待っているようでは、必要なデータをすぐに使うことができず、迅速かつ柔軟な対応が難しい」と語る山之内氏。そこで、“躍動するデータ”を意味する「Data in Motion」、すなわちストリームデータをリアルタイムに、かつ継続的に処理するためのデータインフラを再構築する必要があるのだという。そこでConfluentは、ユーザーがバックエンドのデータをリアルタイムにフロントエンドの顧客体験につなげるための、データストリーム処理を行っているのである。
「Data in Motionは、ユーザーの日常を劇的に改善します。たとえば、オンラインバンキングで詐欺の疑いがある操作がされた場合にすぐに注意を受け取ったり、オンラインショッピングで注文した商品の場所をリアルタイムに把握できたりします。このように、継続的に躍動するデータの流れをつなぐことが必須になりつつあり、これを実現するのがConfluentの役割です」(山之内氏)