#Book ## [[🗃️データベースレプリケーション]] - データベースの1つがオフラインになった場合どうする？ - スレーブがオフラインになった場合 - スレーブ1つ場合 - 読み取り操作を一時的にマスターデータベースへ誘導 - スレーブ複数 - 読み取り操作は、他の健全なスレーブに任せる - マスターがオフラインになった場合 - スレーブデータベースがマスターになるように設定 - マルチマスターや循環レプリケーションと言った方法もある - 💭↑は後で調べたい ## [[🗃️キャッシュ]] - [[🗃️キャッシュ]]を使用するタイミングの決定 - データの読み取り頻度が高い& 変更頻度が低いデータを扱うとき - [[🗃️キャッシュ]]サーバーはデータの永続化には不向き - サーバ再起動でデータは失われる - 重要なデータは永続的なデータストアに保存する必要がある - 有効期限ポリシー[[🗃️DB]] - 有効期限を短くし過ぎると、システムが[[🗃️DB]]からデータを頻繁に再読み込みすることになるので有効期限を短くしすぎないことが推奨 - 逆に、有効期限を長くし過ぎるとデータが古くなる可能性がある - 一貫性 - 📝[Facebookの数千台規模のmemcached運用について - ゆううきブログ](https://blog.yuuk.io/entry/facebook-memcached-paper) - 障害の軽減 - 単一の[[🗃️キャッシュ]]サーバーは[[🗃️単一障害点(SPOF)]] - 複数の[[🗃️キャッシュ]]サーバーを使用することが推奨 - 必要なメモリを一定の割合で過剰にプロビジョニングする - 消去ポリシー - [[🗃️LRU(Least Recently Used)]]が一般的 - 他にも[[🗃️LFU(Least Frequently Used)]]や[[🗃️FIFO(First In First Out)]]などある ## [[🗃️CDN]] - [[🗃️キャッシュ]]有効期限の適切な設定 - [[🗃️CDN]]フォールバック - [[🗃️CDN]]が故障したときの対処を考えておく必要がある - オリジンサーバーからリソースをリクエストできるようにする - ファイルの無効化 ## [[🗃️ステートレス]]Web層 - 状態を[[🗃️WEB]]層の外に出す - 望ましいのは状態データを、[[🗃️DB]]に切り離すこと - そうすることで、各[[🗃️WEB]]サーバーから、データを参照できるようになる ### [[🗃️ステートフル]]アーキテクチャ - 状態をサーバーごとに管理してしまうと、ユーザーごとに各サーバーへルーティングをしないといけない - スケーリングしにくい ### [[🗃️ステートレス]]アーキテクチャ - [[🗃️ステートレス]]web層をもたせることによって、サーバー上に状態をもつことはなくなる - [[🗃️オートスケール]]しやすい ## [[🗃️メッセージキュー]] ## [[🗃️DB]]のスケーリング ### [[🗃️垂直スケーリング(スケールアップ)]] - 欠点 - ハードウェアには限界がある - [[🗃️単一障害点(SPOF)]]のリスクが大きい - コストが高い ### [[🗃️水平スケーリング(シャーディング)]] - user id % 4 の余り値で、データベースをわける。 - このときの user idをシャーディングキーと呼ぶ 💭 - なんとなく、いままで触ってきたシステムの構成と同じで、だいたいこんな感じなのだなという印象。 - [[🗃️単一障害点(SPOF)]]は、普段あまり意識できてなかったので学び。