ログボ
主に、Fediverseへの関心に基づいた投稿を行うアカウントです。DTP・印刷に関する話をしたり、同人の話をしたり、カレーをブーストしたりします。
Mastodonのcollaborator(開発者の一員)です。また、独自機能を盛り込んだFedibirdを管理・開発しています!
Mastodonサーバ『fedibird.com』の管理者アカウントでもあります。ご連絡は当アカウントへ、サーバインフォメーションについては https://fedibird.com/about/more と @info を参照してください。
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
豆を注文しましょうね〜
グァテマラ・ティピカ種100% ラ・ブルブハ農園
https://ncr.official.ec/items/61553504
やや浅めで酸味のあるコーヒー、字自分結構好きだったんだなーって思わせてくれた、グァテマラをオーダー。これ美味しいよ!
This account is not set to public on notestock.
体はカレーで出来ている
血潮はルウで心は具
幾たびの皿を越えて不敗
ただ一度の敗走もなく、
ただ一度の勝利もなし
担い手はここに孤り。
鍋の丘でカレーを鍛つ
ならば、我が生涯に意味は不要ず
この体は、
無限のカレーで出来ていた
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
@waratami マストドン日本語ウィキには大変お世話になりました。
ウィキのポジションや特性から、サーバ運営や開発側に属する立場を考慮し(一部訂正以外)編集へは加わりませんでしたが、非常に貴重な情報源で、調べ物のたびに参照させていただきました。これまで大変ありがとうございました。
また嗤民さんが顔を出した際に、いろいろと面白いものを見せられるよう、粛々と流れを進めていきたいと思いますので、いずれまた!
This account is not set to public on notestock.
This account is not set to public on notestock.
この記事の件ね。
https://atmarkit.itmedia.co.jp/ait/articles/2204/19/news005.html
データベース、関連する情報が相互に矛盾しない状態で維持されていること(整合性)が一つのポイントで、だからこそ便利というのがあります。
これを分散させる場合は、設計にいろいろと工夫がいる。
最初のうちは、なんでも一ヶ所につっこんであった方が簡単で、データの整合性はデータベース任せにしちゃう。
ただ、どんどん複雑になっていく一方で、とめられなくなっていくので、そのうちサービスの成長の足かせになります。
マネーフォワードは、ユーザーアカウント情報の他、銀行とかからデータ引っこ抜いてくる部分を共通して使いたかったようですね。
ゲームの、ログインサーバ(IDなどを管理)と、ゲームのシャードのサーバみたいな分け方をしたり、
共通利用していた基盤を切り出して、各サービスからそれを利用するようにシステムを分離して、データベースもわける、という設計変更をすすめているんだと思います。
(斜め読みです) [参照]
Mastodonもデータベースは一つです。(まあ単一サービスですが)
リードレプリカといって、読み出しだけですむ情報を入れておく複製をつくって、書き込みが必要なマスターデータベースとわけて、同期する方法もあって、一応はサポートされているのですが、
Mastodon内部がそれを意識して設計されているわけではないので、あんまりうまくいきません。整合性が必要なところではかえって遅くなるし、障害はむしろ増えますw
そんなわけで、大規模サーバではDBサーバにハイスペックサーバを割り当てて対応しています。ここに大規模化の限界があります。
TwitterやFacebookの規模のサービスが動いているのは、とてもスゴイことです。もちろんスペック積むだけでは無理です。
データを地域で分割したり、時系列で分割したり、IDなどで均等割したり、いろいろ工夫の余地がある、というところまでにしておきます……。
そういう難しい話とは別に、データベースの予備をもっておいて、死んだ時に切り替える『レプリケーション』は簡単にできます。
マネージドサービスを使って、Amazonとかに任せるって手もありますw
Fedibirdでやっているのは、
- 比較的パワーのあるデータベースサーバを使う
- 遠隔地に待機サーバを用意して、常時複製しておく(レプリケーション/ダメだと思ったら切り替える)
- 1日に一度フルバックアップ、分単位で差分バックアップして、7日分ぐらいとっておく(分単位で任意の時点に戻せるが、ちょっと時間がかかる)
です。
遠隔地においたサーバは、距離の分だけ通信に時間がかかります。これが案外馬鹿にならんのです。
なので、あくまで片方は待機系です。もったいなくて使いたくなるのですがw
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.