サーバー1台運用のリスク
- ハードウェア負担が大きい
- サーバー障害によるシステム停止
ハードウェア負担の例
- CPU処理能力を超えるリクエストが来る
- キャッシュ・ストレージ容量を超えるデータ保存が発生
結果、システムダウンに繋がる可能性がある。
さらに、サーバーが1台だけだと、システム全体が停止してしまう。
対策1：垂直スケーリング
- サーバーの性能を上げる（CPU・メモリ・ストレージを強化）
- しかし，物理的な限界がある
対策2：水平スケーリング
- サーバーの数を増やすことで負荷を分散
アプリケーションレベルのスケーラビリティ
水平スケーリングで必要な技術
1. ロードバランサー
- 複数サーバーへリクエストを適切に振り分ける
- 代表的：ラウンドロビン方式（順番に振り分ける）
2. キャッシング
- 一度取得したデータをメモリに保存し、再利用
- DBアクセス減らし＆速度向上
3. CDN（コンテンツデリバリーネット）
- 世界中に設置されたサーバーに静的ファイルを保存
- ユーザーは最寄りのサーバーからデータ取得
→ アプリケーションサーバーの負荷軽減
水平スケーリング特有の課題と対策
キャッシュデータの問題
- サーバー間で共有できない問題
対策：スティッキーセッション
- ロードバランサーがユーザーとサーバーを固定して管理
- だけど負荷偏りリスクもある
ステートレスサーバーとトークン認証
- サーバーはセッションを保持しない
- トークンベース認証（JWTなど）を利用
- デメリット：毎回認証が必要
サービスアーキテクチャ（マイクロサービス化）
- サービスごとにサーバーを分ける
- メリット：負荷分散
- デメリット：API連携実装コスト増大
データベースレベルのスケーラビリティ対策
1. マスター・スレーブレプリケーション
- 書き込み専用DB（マスター）
- 読み取り専用DB（スレーブ）複数
- 読み課題をスレーブに振り分けて負荷分散
2. データベースシャーディング
- 用途ごとにDBを分ける（例：投稿DB、決済DB、ユーザーDB）
- デメリット：システム設計複雑化
単一障害点（SPOF）
- 1つ壊れると全体が停止するポイント
- 例：ロードバランサー，書き込み用DB
- 完全な排除は難しいが、可能な限りシンプルに設計する
まとめ：スケールの考え方
- コピーして増やす（水平スケーリング）
- 役割ごとに分けて増やす（シャーディング）
バックエンド開発者として大切なこと
- 要件によって設計は変わる
- 背景知識があると開発の意図が理解できる