分散という視点から見るMisskey
このNoteはMisskey Advent Calendar 2023 2枠目 12月25日の投稿用として記載されたものです。
この記事の一番下にAdvent Calender自体を添付してありますので、他の記事もぜひ…
Misskey.ggの管理人の1人である、@misaと申します。
今回はMisskeyはもっと分散するべきであるという話、Misskey.ggとしての分散へのアプローチについて書きたいと思います。
なぜ分散する必要があるのか
最近Misskeyを知った方はTwitterの騒動が原因の方が多いと思います。
実際、Misskey.ioのユーザ数を見てもTwitterからXへの変更、Xでの障害や仕様変更の度に大幅に増加しています。
Twitterの騒動で特定のサービスに依存することが危険であることは十分に理解が広まった感覚はあります。
MisskeyはTwitterのようなマイクロブログサービスではありますが、Twitterを代替するものとしては不十分です。
その上で、Twitterからの移行先としてMisskeyを選ぶ場合、Misskeyで特定のサーバに依存している状態は、Twitterに依存している状態と変わらず好ましくありません。
Fediverseについて
Fediverseはそれぞれのサーバが独立性を保ち、相互接続することで成り立っています。
MisskeyのGTL(グローバルタイムライン)で他のインスタンスやMastodonの投稿を見ることが出来るのは、FediverseのActivityPubで相互に投稿が交換できているからです。
それらの機能はサーバ(インスタンス)の分散には十分であるように見えます。
実際のMisskeyではどうでしょうか
そもそもMisskeyは分散志向ではない
そもそもMisskeyはTwitterを代替するものとして作られていないし、分散を目的としていません(確かしゅいろさんが言っていた気がします、その記述を見つけられていません。知っている方は教えてください)
そもそも現存する大きいサーバは、多くのユーザを受け止められる状態にありません。
Misskey.ioやにじみすが財政的に危機に陥ったことがあることや、Misskey.ioが独自機能で負荷を軽減しているのにも関わらず、オンラインユーザが増えたときに重くなることからも明らかです。
それを踏まえ、Twitterからの移行先としてMisskeyを選ぶ場合、ユーザ自身が分散を考える必要があります。
分散するにあたっての障壁
ユーザが分散志向でサーバを選びたいと思っていたとして、その際に障壁として挙げられるものは何があるでしょうか。
外部からサーバの安定性がわからない
Mastodonは公式が公開するサーバリストにMastodon Server Covenantが定められており、毎日のバックアップや、サーバを閉じる3ヶ月前にユーザに告知することなどが掲載の条件になっています。
Misskeyにこうした条件付きのサーバリストはなく、ユーザは運営元が信用に値するかどうか調べる必要があります。
もちろん、Mastodonも本当にServer Covenantを守っているかどうかは分かりませんが、サーバを選ぶ上での障壁にはなっていると思います。
それぞれのサーバの疎通性はあまり高くない
misskey.ioも昔はRelayに参加していたようですが、ユーザが増えて以降、接続を解除しています。リレーがなければ基本的にはフォローしなければ投稿は流れてきませんので、他のサーバのユーザの過去の投稿を見たければ、毎回他のサーバに飛ぶ必要があります。
これは一部のサーバへのユーザの集中を加速させる原因になっていると思います。
GTLで新たなユーザを見つけるのは容易くない
LTLにも言えることですが、すべての投稿が流れる中から自分の好みの、みたい投稿を見つけることは容易くありません。
ユーザが多ければタイムラインは速すぎて、少なければそもそも見つけられません。
Misskey.ggとしてのアプローチ
Misskey.ggはこれらのことを踏まえ、Twitterから移行するのに十分なサーバにするために活動しています。
特に特徴的なのはCDNやクラウドなど外部への依存を出来るだけ減らすことを目指し、その部分から分散を進めています。
また、サーバの運用状況についてユーザに公開し、サーバの選択材料になるようにしています。
Cloudflareを利用しない
以前、同じ運営チームで運用していた、Misskey.cfではCloudflareを利用していました。その際には無料プランでも97％程度キャッシュしてくれて、1日あたり1.1TB程度は転送量が節約されていました。
多くのインスタンスはCloudflareを利用しており、Cloudflareの障害時に.cfも含め多くのインスタンスにアクセスできなくなっていた事から、FediverseにCloudflareを利用しないサーバを構築したいと考えました。
現在は以下のような構成で、自分たちのサーバでCacheを行うことで、CloudflareはName Serverのみとなっています。(今後、Name Serverについても、移行を行う予定です。）
本ページ執筆時点ではIPv4はフレッツ光クロスのVNEの固定アドレスを利用し、IPv6は非営利の団体にIPv6の割当やトランジット提供を行っているプロジェクトより割当を受け運用しております。
今後、IPv4も割当を受ける予定であり、その際にはBGPでTokyo、Kanagawaどちらの拠点からも接続しTokyoとKanagawaの拠点に負荷分散(ECMP)を行うとともに、片方の拠点の接続性が失われた場合でも接続可能にする予定です。
現在ではTokyoでリバースプロキシとCacheを行っており、Tokyoが落ちた際は.ggへの接続性は失われます。
バックアップ
Object Storageは我々が所有する2拠点に複製され、Wasabiにも複製されるようになっています。
DBは毎日1回、Wasabi、我々の所有するもう1拠点のObject Storage、Wasabi Object Storageにバックアップされます。
もしバックアップが失敗した場合、Discordに通知が来るようになっています。
監視
Github Actionsを用いた監視については公開していますが、それ以外にもクラウドを用いて死活監視を行っております。
クラウドからの監視はPrometheusを用いて5拠点より行っており、正常な応答が帰ってきていることや、遅延を監視しています。
正常で無くなったときにはDiscordより通知が来るようになっています。
今後したいこと
新たなタイムラインの実装
現時点での全ての投稿が流れるGTL、LTLには限界があると感じています。
繋がりたいユーザを見つけるための役割もMisskey自体で担えるよう、おすすめタイムラインを実装したいと考えています。
安定性も考慮したサーバリスト
バックアップの基準や、外部からの監視による安定性評価など、様々な要因によるサーバリストを提供したいと考えています。
Twitterで利用されていた機能の実装
Twitterでよく利用されていた機能で、Misskeyに無いものにDMがあります。
MisskeyでDMのようなUIを実装する予定はあるようですが、MastodonのようなE2E暗号化を追加で実装したいと考えています。
これらはMisskey本家へのコミットになるか、フォークとなるかはまだ分かりませんが、私なりにMisskeyに貢献できる方法をこれからも模索して行きたいと思います。
最後までお読みいただきありがとうございました。
よいMisskeyライフを！
おまけ : Misskey.ggについて
misskey.ggはmisskeyというオープンソースソフトウェアを利用したインスタンスの1つです。
2023年7月4日より一般に登録を開放しました。
特徴として(現時点では)、
・バニラな状態でMisskeyの最新に追従する。(フォークは行わない)
・その他のSNSサービスと同じく、一般的な利用に十分なストレージ(メディアアップロード容量)を提供する。(現時点で1ユーザ100GB)
といったことが挙げられます。
同じ運営チームで、以前はmisskey.cfというドメインでインスタンスを公開しており、多くの方にご利用頂いていました。
misskey.cfのドメインが停止されてしまい、新たに安定したドメインを取得して、新たなインスタンスとして公開した形になります。
Misskey Advent Calendar 2023
この記事が気に入ったらサポートをしてみませんか？