結城浩 / Hiroshi Yuki
ハード的なサーバの分散と、名前や管理単位のコミュニティの分散とは分けて考えられないのかな。
現在、一つのサーバに人がたくさん集まっていると、たとえばそのサーバが落ちるとたくさんの人がアクセスできなくなる。でもそれは一つのサーバに集中しているから。同じmastodon.exampleの名前のもとで別々のサーバに分かれた同じコミュニティがあってもいいと思う。
サーバという「実装」が見えているからそれとコミュニティを重ねてしまうけど、（本来は）分けて考える方がいいのではないかと思った。
（あまりちゃんと考えてないけどとりあえず投稿）
zunda
@hyuki Mastodonの実装としては、サーバのドメイン名ごとにPostgresとRedisが用意されていて、その範囲で一貫性が保たれている必要があると理解してます。大きいサーバではそのドメインの裏でロードバランサとかアプリケーションサーバとかデータベースとか多数のハードウェアが動いていてそっちはそっちでクラウド業者的な観点での分散が実現していそうです。
大きいMastodonドメイン/コミュニティ内で複数のMastodonサーバを稼動させるには、サーバのドメイン名ごとにPostgresとRedisの一貫性が保たれているという前提を崩す必要があるので、例えばアカウントごとにどのMastodonサーバに処理を転送する(シャーディングする)か、というアルゴリズムと実装が必要になりそうです。
逆に、多くの小さいMastodonサーバを単一のサーバで動かすようにする(マルチテナントにする)とMastodonホスト業者さんは小さいサーバをより安く提供できるようになりますが、ソフトウェアの実装が複雑になるので実現していません。
なんばりょうすけ
@hyuki インスタンスの管理主体自体を実装ごとに分散化すると、そのインスタンスのユーザーとしては全実装の管理者を信頼しないといけなくなるのでアカウントのセキュリティに関わる部分は一箇所に集中しないといけないかも？
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.