スケーラビリティ

スケーラビリティとは、負荷の増大に応じてシステムが性能を維持・向上できる能力を指す。ユーザー数やデータ量が増えたとき、システムがどのように対応するかを事前に設計しておくことがアーキテクチャの重要な責務となる。スケーラビリティを考慮しない設計は、サービス成長とともに致命的なボトルネックを生む。

水平スケーリング（Horizontal Scaling）はサーバーを複数台に増やすアプローチで、コストの線形な増加とともに高い可用性を得られる。一方、垂直スケーリング（Vertical Scaling）は単一マシンのスペックを上げる方法で実装変更なく対応できるが、ハードウェアの上限という物理的な制約がある。クラウド環境ではオートスケーリングにより需要に応じてインスタンスを自動で増減させることで、コストと性能のバランスを取ることが一般的になっている。

データベース層のスケーラビリティは特に難しい問題である。リードレプリカを用いて読み取りを分散させることは比較的容易だが、書き込みスケーリングにはシャーディングが必要になる。シャーディングはデータをキーに基づいて複数のノードへ分散配置する手法で、運用の複雑さと引き換えに大規模なスループットを実現できる。

コードレビューで着目するポイント

ステートレス設計になっているか（セッション情報をアプリサーバーではなく Redis 等の外部ストアに持つ構成になっているか）
水平スケーリングを阻む共有状態（ローカルキャッシュ、ファイルシステムへの依存）がないか
データベースのシャーディングキーが均一な分散を生むよう設計されているか（ホットスポットが生まれないか）
N+1 クエリやフルスキャンなどデータ増加とともに劣化するクエリが含まれていないか
オートスケーリングのトリガー指標（CPU・RPS・キュー深度）が適切に設定されているか
依存するサービスのスケーリング上限がボトルネックになっていないか（RDB の接続数上限等）
キャパシティプランニングのためのロードテストが整備されているか

典型的なアンチパターン

スティッキーセッション依存: アプリサーバーにセッションを持つ設計は、特定のサーバーにリクエストを固定（スティッキー）しなければならず、水平スケーリングが実質不可能になる。セッション情報は外部ストアへ移す必要がある。

シャーディングキーの偏り: ユーザーIDのプレフィックスや地域コードをシャーディングキーにしたとき、特定のシャードに負荷が集中するホットスポットが生じやすい。均一なハッシュ分散を事前に検証すべきである。

データベースへの垂直スケーリング依存: 書き込み負荷の増大に対してデータベースサーバーのスペックアップで乗り切ろうとすると、いずれハードウェアの限界に到達する。読み書き分離・キャッシュ導入・シャーディングといった水平方向の戦略を早期に検討すべきである。

参考リソース

書籍: 「Designing Data-Intensive Applications」（Martin Kleppmann） - スケーラビリティの基礎から分散システムの設計まで網羅
書籍: 「System Design Interview」（Alex Xu） - 実際のシステム設計の思考プロセスを学ぶための実践的な参考書
ツール: k6 - JavaScript でロードテストを記述できるスケーラビリティ検証ツール
ツール: Apache JMeter - 負荷テストの定番ツール
標準: AWS Auto Scaling / GCP Autoscaler - クラウドプロバイダーのオートスケーリング設計のリファレンス