メッセージをやりとりするサービスの難しさについて

チャット機能の難しさについて

前口上

新しい技術やプロダクトトレンドを追うのが好きで、よくピッチイベントを見たりするのですが、その中でプレゼンされるプロダクトの中にはチャット機能を持つものがしばしばあります。

システムは何かしらの利用料を得て生存するので誰かと誰かを繋ぐという意味ではわかりやすい機能なのですが、必ずしもリアルタイムである必要がない場所でも出てきがちな印象があります。

おそらく非エンジニア、特にITリテラシーが高くない創業者が一番よく使うアプリがLINEなんだと思います。

Facebookメッセンジャーやカカオトークなどもあるにはあるのですが日本国内ではLINEのシェアが高いです。

競合が現れない理由には技術的難しさもあって、以下チャット機能の難しさについて書きます。

法律の制限、個人情報の取扱

弁護士ではないので、この情報は参考程度のものですが、公開されている掲示板形式と違い、閉じたチャット機能だと電気通信事業の届出が必要です。法律の要件があるというのがまず一つ。

また、法律上越境自体は制限はないのですが、LINEのデータが中国から見れることが問題になりました。日々のチャットの内容はセンシティブな情報を含む場合もあり、ユーザー心理として国をまたいだデータ転送に抵抗感がある場合もあります。

現状日本では欧州のGDPRほど厳しい制限はないのですが、日本版GDPR導入が検討されたこともあります。チャット機能をまるまるSDKで提供してくれるサービスもあるのですが、日本以外にデータストアがあると将来的にリスクがあるかもしれません。

LINEではend to end暗号化も実施されています。設定がオンならサーバーには暗号化した状態で保存され、基本的にユーザーのみが元テキストを見ることができます。サービス提供側でも容易には閲覧できません。この仕組みを実装できているWebサービスは多くはありません。

RDBMSとの相性の悪さ

Rails, Laravel, Djangoなどよく使われるWebフレームワークではデータベースにRDBMSを使うことを多くの場合仮定しています。

RDBMSは概念と概念の関係を辿るのは得意ですが、関係が希薄で単一概念が時系列で増え続けるメッセージオブジェクトを格納するのに最適なわけではありません。LINEもメッセージ周りにはHBaseを使用しています。

調べたところ、チャット系のサービスで仕様しているデータストアをあげると

LINE: HBase + Redis
Facebook Messenger: HBase
Slack: Vitess(+ MySQL)
Chatwork: HBase + Kafka

になります。HBaseが人気ですね。

Vitess以外でもCockroachDBやTiDB, PlanetScaleのようなNewSQLが今後主流になる可能性はありますが枯れてはいないです。Spannerが一番運用実績がありますがGoogle Cloudにロックインされます。

Hadoop関連のスタックを運用するのはそれなりにノウハウが必要でインフラエンジニアがRDBMSより必要な認識です。TwitterがギリギリまでMySQLで頑張ったという話もあるので、0=>1でMySQLを採用するのも悪い選択肢ではないのですが、チャット機能はRDBMSだとスケールしなくなるタイミングが他より早いという認識は持つべきだと思います。