ActivityPubに取って代わるかもしれないXQについての個人的見解
泡沫京水
What XQ?
突然生えてきたように見えるこのリポジトリ
めちゃくちゃ簡潔にいうとActivity PubのProtocol Buffer版。
泡沫京水
What Protocol Buffer?
Googleが提供する
特定の言語またはプラットフォームに依存せず、なおかつ拡張可能であるような
構造化データをシリアライズするためのメカニズムのこと。
- データの構造を定義
- その定義から生成する
- 生成したコードを使用して、構造化データをデータストリームに変換
- データストリームとして、言語やプラットフォームに依存しない状態で、構造化データを扱う
という仕組みになっています。
データストリームとは
データストリームはいわゆる「事前に定義された形式に従ったバイナリ」
バイナリであることによって、ストリーミング通信で次々送られてきても、JSONやYAMLなどの特別な形式なテキストデータと比べ、処理が高速になる
シリアライズとは
データ構造やオブジェクトの状態を、連続する文字列やバイト列などの形式に変換する操作
泡沫京水じゃあパフォーマンス上がる？
The performance benefits of using Protobuf don't seem significant.
As you can see from this README, performance is not the only objective. We also emphasize ease of application development.
Also, even if the benefits are “not that significant,” if they are even a little bit significant, it is worth adopting.
これは、パフォーマンスの向上だけではなく、
開発が容易になるようにすることも目的にしているようです。
どういうことかというと、Protocol Bufferを導入することによって、
パフォーマンスは当然向上するでしょう。
それに加えてXQでは、開発のしやすさも向上させたいという狙いがあるとのことで、
これはMisskeyのソースコードをForkし、ホスティングする運用側にとって、
自分のインスタンスにおいて、特色のある機能の開発によるカスタマイズがやりやすくなるというメリットがありますし、ソースコードを提供するmisskey-dev側もMisskey
に搭載したい基礎機能の開発がやりやすくなるメリットがあります。
protoファイルにデータ構造が定義されているので、
このファイルに使用されるデータ定義が入っているということがわかっていて、
様々な言語にコードを生成してくれるので、言語が違っても統一された構造のデータを
簡単に扱うことができます。また、型も設定されていることを踏まえると、
静的型付言語でプログラムを組む際、必要な型定義はすでにされているので、
型定義の宣言をする手間が省けます。
泡沫京水ちょっとChatGPTに計算させてみました。
プロンプト
Misskeyのような、様々なサーバから投稿データを取得したり、そのサーバ内で作成した投稿データを別のサーバに送信するなどの通信処理が常時行われるサーバにおいて、JSONで渡し合うのと、Protocol Bufferで渡し合うのはどれくらいのパフォーマンスの違いがあるでしょうか？ 1サーバにおいて、1秒あたり2個の投稿をするユーザが25人いるとして、100個のサーバが互いに通信し合っているとします。
結果
➡️ 1サーバあたり毎秒：2 × 25 = 50 投稿
➡️ 100サーバ全体で：50 × 100 = 5,000投稿/秒
通信量
| フォーマット | 1投稿のサイズ | 毎秒データ量 | 毎分データ量 |
|---|---|---|---|
| JSON | 2KB | 10MB | 600MB |
| Protobuf | 0.7KB | 3.5MB | 210MB |
エンコード/デコード速度
| 処理項目 | Protobuf | JSON |
|---|---|---|
| エンコード速度 | 高速（2〜10倍） | やや遅い |
| デコード速度 | 高速（5〜20倍） | 遅い（特に深い構造で） |
JSON/ProtoBufの違い
| 比較項目 | JSON | Protobuf |
|---|---|---|
| データサイズ | 大（通信量が多く、帯域圧迫しやすい） | 小（通信効率◎） |
| 処理速度 | 遅め（特に多階層構造） | 速い（構造定義済みなのでパース高速） |
| 可読性 | 高（デバッグしやすい） | 低（ツール必要） |
| 実装コスト | 低（普及していてツール豊富） | やや高（スキーマ定義、言語対応必要） |
🌟 高トラフィック＆リアルタイム性が重要なシステム（＝Misskeyのような分散SNS）においては、Protobufの導入は通信効率・サーバ負荷の両面で大きな改善が見込める
泡沫京水本当にパフォーマンスが上がるのか？
上記リンク記事において、
Protocol Buffers が有利なのはその逆と言えるでしょう。
データ構造が複雑である
将来、シリアライザの互換性を保ったままデータ構造を拡張したくなりそうである
多くのサービスとデータを交換する
そのデータを利用する言語が多岐に渡る
というもののうち、
「多くのサービスとデータを交換する」に関しては
様々なサーバインスタンスがあるので、それらとひたすら投稿データを交換しまくっているので
これはしっかりMisskeyにあてはまっていると言えます。
泡沫京水それをどうやって組み込むのか
今のところ、私はコントリビュータではないので、事実ではなく全て推測になりますが、
ブランチを切って開発をするか、もしくは別のリポジトリで開発を始めるのかについては、
Activity Pubとの互換を保証するか否かで変わってくると思っています。
しかし、わざわざProtocol Bufferを用いた効率的なものをメインとして実装するくせに、わざわざ効率が悪い側の方の互換性を作るでしょうか？私はそう思いませんし、私ならそうしません
また、同じリポジトリで作成すると、確実に混乱を生む（XQに切り替えるということをコントリビュータ全員が良しとする確証がないため）でしょう。
そのため、リポジトリを別に作成し、開発を進めていった後、
そこからActivity Pubと連携するように調整を始める可能性があると考えています。
Activity PubtoXQとなるような
コンバートプログラムの開発でしょうか…？🤔💭