シャーディング

🐾 猫で例えると？

写真の2匹は、別々のハンモックでくつろいでいます。このように一か所へまとめず、猫の記録も猫IDに応じて複数の保存先へ分けると考えます。各保存先がシャード、行き先を決める猫IDがシャードキーです。一部の保存先にばかり作業が集中すると、分けても混雑が残ります。

💻 データベース運用における「シャーディング」とは？

サービスが成長し、ユーザー数やデータ量が爆発的に増加すると、単一のデータベースサーバー（1台のハイスペックマシン）ではいずれ処理の限界を迎えます。CPUの使用率が跳ね上がり、メモリが枯渇し、ディスクI/Oがボトルネックとなってレスポンスが極端に遅くなるのです。

この問題を解決するために、データベース自体を複数台のサーバー（シャード）に分割し、データを分散して保存・処理させる手法がシャーディングです。例えば、ユーザーIDが1〜10万の人はサーバーAへ、10万1〜20万の人はサーバーBへと分けます。データ量やアクセスが適切に分散すれば、1台あたりの負担を減らせます。ただし、特定の範囲へアクセスが集中すると負荷の偏りが残ります。

⚠️ シャーディングの仕組みと注意点

シャーディングを導入する上で最も重要かつ難しいのが、「どのデータをどのサーバーに振り分けるか」を決めるシャードキー（分散キー）の設計です。

シャードキーの設計ミスは命取り

重要なのはデータ量だけでなく、アクセスも偏らないキーを選ぶことです。例えば顧客IDで分けても、特定の大口顧客に注文が集中すれば、そのシャードだけが混雑します。日時や連番の範囲で分ける場合も、最新の範囲へ書き込みが集中することがあります。

// 振り分けの考え方を示すJavaScript例（DB接続は行わない）
function shardIndex(userId) {
  if (!Number.isSafeInteger(userId) || userId < 0) {
    throw new Error("userIdは0以上の安全な整数にしてください");
  }
  return userId % 3;
}
console.log(shardIndex(101)); // 2

これは剰余による単純な振り分けです。3台を4台へ変えると多くのデータの行き先が変わるため、移行や再配置が必要です。実際の製品では、ルーティング、データ再配置、障害時の複製なども含めて管理します。

🛠️ シャーディングを賢く使うためのポイント

シャーディングは最終兵器とも言える強力な手法ですが、安易に導入すると後悔することになります。以下のポイントを現場で考慮してください。

• シャードをまたぐ処理：複数シャードを対象にした検索・JOIN・集計・トランザクションは、製品によって対応やコストが異なります。同じシャード内で完結する処理を増やせるか検討します。
• 運用コストの増大： バックアップや復旧の対象が複数に分かれるため、シャード間の整合性と復元の順序も考える必要があります。
• まずはスケールアップから検討する： すぐにシャーディングに逃げるのではなく、まずはインデックスの最適化や、サーバー自体のスペックを上げる（スケールアップ）、参照系をリードレプリカに逃がすなどの対策をやり切りましょう。

猫の記録を保存先ごとに分けると、一つの保存先の負担を減らせる一方、複数の保存先をまたぐ作業は増えます。シャーディングも容量や負荷への対策であり、デッドロックや障害を自動でなくす仕組みではありません。