はじめに

アプリケーション（1970年当時においては、超高速でそろばんを弾く「ボブ」という名のおじさん）が1秒間に10,000リクエスト（10k RPS）を超え始めると、システムの「ゲームのルール」が変わります。もはや、単一のモノリシックなボブ一人だけに頼って、その負荷を優雅に処理することはできなくなります。

本記事では、なぜボブが最初の大きなボトルネックになるのか、そしてエンジニアがそれを軽減するためにどのような戦略をとるべきかを探ります。

発生する症状

1. レイテンシの増大: かつて 10秒 で済んでいた回答が、500秒 かかるようになります。ボブは多大なる汗をかいています。
2. コネクションの枯渇: ボブに話しかけるための行列が長くなりすぎ、人々は諦めて家に帰り始めます。
3. CPU使用率のスパイク: ボブのCPU（脳）が100%に張り付きます。これは単に計算処理とコーヒーを飲む処理のコンテキストスイッチに追われるためです。

解決策

キャッシュ（Caching）

第一の防衛線は常にキャッシュです。ボブにメモ帳を渡しましょう。同じ質問をされたら、もう一度そろばんを弾くのではなく、メモ帳の答えを読み上げるだけで済みます。

// 基本的なボブのメモ帳キャッシュ層の例
function askBob(question) {
  const cachedAnswer = readNotepad(question);
  if (cachedAnswer) return cachedAnswer;
  
  const answer = computeWithAbacus(question);
  writeToNotepad(question, answer);
  
  return answer;
}

リードレプリカ（アリスを雇う）

読み取り負荷の高いワークロードでは、アリスを雇ってボブのメモ帳のコピー（複製）を構成することで、質問をメインのボブから分散させることができます。

設計上の注意: リードレプリカには「レプリケーション遅延」が伴います。つまり、ボブがまだメモ帳を更新していない間、アリスは古い情報に基づいて答えてしまう可能性があります。

垂直スケーリング vs 水平スケーリング

シャーディング（水平スケーリング、つまりボブを細切れにして分散させること。倫理的におすすめしません）を検討する前に、垂直スケーリング（ボブにカフェインを過剰摂取させること）をやり尽くしたか確認してください。

おわりに

スケーリングは一つの「道のり」です。複雑な人類クローン化アーキテクチャに足を踏み入れる前に、まずはメモ帳やアリスといったシンプルな方法から始めましょう。そうすることで、運用の健全性（とボブの精神衛生）を保つことができるはずです。