Conversation

Notices

1. のえる (noellabo@fedibird.com)'s status on Friday, 22-Apr-2022 15:50:31 JST のえる

   この記事の件ね。https://atmarkit.itmedia.co.jp/ait/articles/2204/19/news005.html

   データベース、関連する情報が相互に矛盾しない状態で維持されていること（整合性）が一つのポイントで、だからこそ便利というのがあります。

   これを分散させる場合は、設計にいろいろと工夫がいる。

   最初のうちは、なんでも一ヶ所につっこんであった方が簡単で、データの整合性はデータベース任せにしちゃう。

   ただ、どんどん複雑になっていく一方で、とめられなくなっていくので、そのうちサービスの成長の足かせになります。

   マネーフォワードは、ユーザーアカウント情報の他、銀行とかからデータ引っこ抜いてくる部分を共通して使いたかったようですね。

   ゲームの、ログインサーバ（IDなどを管理）と、ゲームのシャードのサーバみたいな分け方をしたり、

   共通利用していた基盤を切り出して、各サービスからそれを利用するようにシステムを分離して、データベースもわける、という設計変更をすすめているんだと思います。

   （斜め読みです） [参照]

   • がにょ🛫 and ゆらのふ repeated this.
   • のえる (noellabo@fedibird.com)'s status on Friday, 22-Apr-2022 16:00:07 JST のえる

     in reply to

     Mastodonもデータベースは一つです。（まあ単一サービスですが）

     リードレプリカといって、読み出しだけですむ情報を入れておく複製をつくって、書き込みが必要なマスターデータベースとわけて、同期する方法もあって、一応はサポートされているのですが、

     Mastodon内部がそれを意識して設計されているわけではないので、あんまりうまくいきません。整合性が必要なところではかえって遅くなるし、障害はむしろ増えますw

     そんなわけで、大規模サーバではDBサーバにハイスペックサーバを割り当てて対応しています。ここに大規模化の限界があります。

     TwitterやFacebookの規模のサービスが動いているのは、とてもスゴイことです。もちろんスペック積むだけでは無理です。

     データを地域で分割したり、時系列で分割したり、IDなどで均等割したり、いろいろ工夫の余地がある、というところまでにしておきます……。

     そういう難しい話とは別に、データベースの予備をもっておいて、死んだ時に切り替える『レプリケーション』は簡単にできます。

     マネージドサービスを使って、Amazonとかに任せるって手もありますw

   • のえる (noellabo@fedibird.com)'s status on Friday, 22-Apr-2022 16:07:41 JST のえる

     in reply to

     Fedibirdでやっているのは、

     - 比較的パワーのあるデータベースサーバを使う

     - 遠隔地に待機サーバを用意して、常時複製しておく（レプリケーション／ダメだと思ったら切り替える）

     - 1日に一度フルバックアップ、分単位で差分バックアップして、7日分ぐらいとっておく（分単位で任意の時点に戻せるが、ちょっと時間がかかる）

     です。

     遠隔地においたサーバは、距離の分だけ通信に時間がかかります。これが案外馬鹿にならんのです。

     なので、あくまで片方は待機系です。もったいなくて使いたくなるのですがw