イーロン・マスクは、ユーザーが1日に読めるツイート数に厳しい上限を設けると発表しました。具体的には、認証済みアカウントは1日最大6000件、未認証アカウントは600件、新規未認証アカウントは300件に制限されます。
マスク氏は、この閲覧制限は「データスクレイピングやシステムの操作」に対処するためだと主張していますが、その主張の正当性には疑問があります。Twitterは世界最大級のソーシャルメディア・プラットフォームのひとつであり、すでにデータスクレイピング対策として厳格なポリシー（https://developer.twitter.com/en/developer-terms/agreement-and-policy 参照）を整備しています。10年以上にわたり、データスクレイピングやシステムの悪用に対して積極的に対策を講じてきました。WebサイトがユーザーのIPアドレスをブロックしてスクレイピングを防ぐ技術は広く知られています。大規模言語モデル（LLM）の登場により、大量の学習データを巡る懸念が高まっているのは事実ですが、それを理由に認証済みアカウントまで制限するのは合理的とは言えません。認証済みアカウントはすでに料金を支払い、政府発行の証明書で本人確認を済ませているため、リスクは非常に低いはずです。エンジニアとしての経験から言えば、「データスクレイピングやシステム操作」は単なる口実であり、真の理由はTwitterのデータ基盤がスケールできない、または運用コストが高すぎるという問題にあるのではないかと考えています。
Twitterとその基盤となるデータインフラに関する事実
イーロン・マスクによるTwitterの買収が完了した2022年10月27日以降に起きた主な出来事を振り返ってみましょう。
-
Twitterアプリのパフォーマンス問題：
イーロン・マスクは、Twitterが多くの国で動作が遅いという問題を公に認めました。彼はこの問題の原因として、ホームタイムラインを表示するために1000件以上の不適切にバッチ化されたRPC（リモートプロシージャコール）を実行していたことを挙げています。 -
人員削減：
Twitterは大規模な人員整理を実施し、従業員の約80%にあたる6,000人以上が解雇されました。 -
Twitter Blueの導入：
Twitterは「Twitter Blue」と呼ばれる月額有料サブスクリプションサービスを開始しました。このサービスの加入者は、アカウントに青い認証バッジが付与されるなど、追加機能を利用できます。 -
ツイート機能の強化：
Twitter Blueの加入者は、最大25,000文字のツイートを投稿できるようになり、最大2時間・1080p解像度の動画もアップロード可能となりました。
では、世界最大規模のソーシャルメディアを支えるTwitterのデータインフラはどうなっているのでしょうか？Twitterは数年前から、自社のデータセンターからGoogle Cloud（GCP）への移行を進めてきました（こちら のTwitterエンジニアリングブログを参照）。彼らは、自社データセンターからGCPへ移行することで、数十億件のイベントをリアルタイムで効率的に処理し、膨大なユーザーにシームレスな体験を提供できると考えました。
これらの要素を総合的に見ると、マスク氏はGCPのスケーラビリティとコスト効率に自信を持っていたと推測できます。そのため、エンジニアの大規模な解雇はプラットフォームに大きな影響を及ぼさないと考え、新機能を次々と導入して既存のユーザーベースの収益化を図ったのでしょう。しかし、現実は厳しく、GCPのサービスは非常に高額で、望まれる高スケーラビリティを適正なコストで提供するには至りませんでした。
Elonを助けるかもしれないオープンソースソリューション
数億人のユーザーが1日600件以上の投稿を読めるようにし、運用コストを削減するためには、高額なGCPネイティブサービスの代わりとして、オープンソース技術を活用することを強く推奨します。Twitterの内部アーキテクチャを詳しく見ると、代替可能な主要コンポーネントが4つ存在します。
Cloud Pub/Sub
Cloud Pub/SubはGoogle Cloudが提供するメッセージキューサービスです。これは分散型でフォールトトレラントかつスケーラブルなメッセージングシステムであり、大規模なデータストリームの処理を効率的に行えます。メッセージングキューは、送信側と受信側の分離を実現し、分散システム内の非同期通信を可能にします。
Twitterでは、ユーザーの投稿、返信、リツイート、いいねなどの各種イベントがCloud Pub/Subに取り込まれ、その後他のシステムで処理・保存されます。
TwitterはApache Kafkaを内部的に使用していますが、GoogleのCloud Pub/Subも併用しています。しかし、以下のようなオープンソースの代替手段に切り替えることも可能です：
- Apache Pulsar：Apache財団が開発した分散型メッセージングプラットフォームで、低レイテンシ、マルチテナンシー、地理的レプリケーション、階層型ストレージなどの特徴があります。
- Redpanda）：C++で実装された、Kafka互換の高速・高効率なメッセージングサービスです。Kafkaの6倍のコスト効率と、最大10倍のパフォーマンスを誇るとされています。
Dataflow
DataflowはGoogle Cloudが提供するストリーム処理サービスです。ストリーム処理システムは、生成されるリアルタイムデータを即時に分析・処理するために設計されており、組織が即座にインサイトを得て、リアルタイム分析を行い、発生したイベントに即応することを可能にします。
Twitterは、メッセージングキューから流れてくるデータを変換・分析し、その後の基盤システムへと取り込むために、ストリーム処理システムを活用しています。
Dataflowの代替として、Twitterが利用可能な有力なオープンソースの選択肢には以下があります：
- Apache Flink：Apache財団が開発した、バッチ処理とストリーム処理を統合したプラットフォームです。Java APIとSQLインターフェースを提供し、Kafka、Pulsar、HDFS、Iceberg、Hudiなど多様なシステムと容易に統合できる、広範なエコシステムを持ちます。
- RisingWave：Rustで書かれた分散型SQLデータベースで、ストリーム処理に特化しています。リアルタイムアプリケーション構築の複雑さを軽減し、コストを削減することを目的としています。Flinkの10倍の性能を誇り、特に現代のクラウド環境において高いコスト効率を実現します。PostgreSQL互換であるため、ストリーム処理初心者にも扱いやすい設計となっています。
BigQuery
BigQueryはGoogle Cloudのレイクハウス型ソリューションです。レイクハウスは、データの保存、管理、分析を統合することで、構造化および半構造化データを大規模に扱うためのスケーラブルなアーキテクチャを提供します。
Twitterでは、Dataflowからのデータが継続的にBigQueryに書き込まれており、Twitter社員はそれを使って高度なデータ分析を行っています。
BigQueryの代替には、計算レイヤーとストレージレイヤーの両方が必要となるため、置き換えはやや複雑になります。以下は、BigQueryの計算レイヤーに代わり得るオープンソースのシステムです：
- Presto：複数のデータソースをまたいで高速かつインタラクティブな分析を可能にする、オープンソースの分散SQLクエリエンジンです。多様なデータフォーマットとストレージとの統合をサポートします。
-
Trino：Trino（旧PrestoSQL）は、高性能な分散SQLクエリエンジンであり、複数のデータソース（ファイル、データベース、データレイク等）に対する効率的なクエリ実行を実現します。
※PrestoとTrinoの背景：PrestoはもともとFacebookが開発したプロジェクトであり、2020年12月にコミュニティの多くがTrinoとしてフォークしました。詳細はこちら。 - Velox：VeloxはFacebookが開発した、高性能な分散SQLクエリエンジンであり、C++で実装されたPrestoの再構築版です。非常に高速であり、MetaやByteDanceといった大手企業でも導入されています。
- ClickHouse：ClickHouseは、超高速なリアルタイム分析に特化したカラム型データベースです。大規模データの高速処理が可能で、世界最速のリアルタイム分析基盤とも言われています。
BigQueryのストレージレイヤーに相当するオープンソースの代替候補は以下の通りです：
- Apache Hudi：レコード単位での更新・削除、インクリメンタル処理、ライフサイクル管理などに対応する、リアルタイム指向のデータレイクストレージシステムです。
- Apache Iceberg：スキーマ進化やACIDトランザクション、時系列クエリなどに対応した、大規模データ分析向けのテーブルフォーマットです。
- Delta Lake：既存のデータレイクの上に構築されるストレージレイヤーで、ACIDトランザクション、スケーラブルなメタデータ管理、データバージョン管理などを提供します。ビッグデータ処理における信頼性とパフォーマンスを向上させます。
Bigtable
Bigtableは、Google Cloudが提供するNoSQLデータベース、あるいはキーバリューストア型のサービスです。これは分散型で高性能かつスケーラブルなデータベースシステムであり、従来のリレーショナルデータベースとは異なるユースケースに特化しています。
Twitterは、エンドユーザー向けのサービスを支えるためにBigtableを利用しています。Twitterはユーザーを対象としたプラットフォームであり、膨大なデータ量とインタラクションに対応できる、非常に高速かつスケーラブルなデータベースシステムが必要とされます。
もしTwitterがBigtableのオープンソース代替を検討するのであれば、以下のような選択肢があります：
- MongoDB（https://www.mongodb.com/）：柔軟性とスケーラビリティに優れた、ドキュメント指向のNoSQLデータベースです。多様なユースケースに対応でき、使いやすさと豊富なクエリ機能で広く採用されています。
- Cassandra（https://cassandra.apache.org/）：大規模なデータを複数の一般的なサーバーに分散して処理することができる、非常にスケーラブルかつ耐障害性に優れたNoSQLデータベースです。高可用性を必要とするデータ集約型アプリケーションに適しています。
- ScyllaDB（https://www.scylladb.com/）：Cassandraと互換性を持つNoSQLデータベースで、パフォーマンスの向上とリソース消費の削減を目的とした設計がなされています。ScyllaDBはCassandraに対して2倍〜8倍の性能を提供し、ノード数の削減によるコスト削減も実現できるとされています。
結論
イーロンは、ユーザーのツイート閲覧数に制限を設けるべきではありません。スケーラビリティを確保しつつ、コストを削減するための方法は他にも多数存在します。有料・無料を問わず、閲覧数の制限はTwitterの健全なエコシステムに深刻な悪影響を及ぼす可能性があります。
その代わりに、Google Cloudの高額なサービスに依存するのではなく、オープンソースの代替技術を積極的に取り入れ、Twitterをより良く、自由で、閲覧無制限なソーシャルメディアプラットフォームとして進化させていくべきです。