シャーディング

シャーディングとは?

シャーディングは、単一の大規模な論理データセットをシャードと呼ばれる小さな独立した部分に分割できるデータベースアーキテクチャパターンです。各シャードはデータのサブセットを含む完全に機能するデータベースであり、すべてのシャードが合わさって全体のデータセットを構成します。各シャードは元のデータベースと同じスキーマを維持しますが、データの一部のみを格納します。通常、これはシャードキーによって決定されます。

垂直パーティショニング(列によるデータ分割)とは異なり、シャーディングは水平パーティショニングの一形態です。行によってデータを分割し、異なるレコードを異なるデータベースに分散します。これにより水平スケーリング(スケールアウト)が可能になり、システムは単一のより強力なサーバー(垂直スケーリング)に依存するのではなく、ノードを追加することで負荷の増加に対応できます。

例:
数百万人のユーザーを持つソーシャルメディアアプリケーションでは、ユーザーテーブルをユーザーIDでシャーディングし、ID 1〜1,000,000のユーザーをシャード1に、1,000,001〜2,000,000をシャード2に配置するといった具合です。各シャードは独立したデータベースであり、独自のサーバーまたはクラスター上で実行される可能性があります。

主要な概念と用語

シャード: データの明確なサブセットを保持する個別のデータベースまたはパーティション。各シャードは元のデータベースと同じスキーマを持ちます。

シャードキー: データレコードがどのシャードに属するかを決定するために使用されるデータベースフィールドまたは属性。シャードキーの選択は、バランスの取れた分散とパフォーマンスにとって重要です。

水平パーティショニング: テーブルの行を複数のデータベース(シャード)に分散すること。

垂直パーティショニング: テーブルの列を別々のテーブルまたはデータベースに分散すること。例えば、使用頻度の低い列を別のテーブルに分離します。

シェアードナッシングアーキテクチャ: 各シャードは、共有ハードウェア、ストレージ、状態なしで完全に独立して動作します。

シャーディングの使用方法

シャーディングは、スケーラブルで高性能、かつ耐障害性のあるシステムを設計するための基本です。以下の目的で使用されます:

水平スケーリング: データベースノードを追加することで容量を増やし、上限はありません。

パフォーマンスの向上: 各ノードが管理するデータ量を制限することで、クエリと書き込みのレイテンシが削減されます。

障害分離の向上: 1つのシャードが障害を起こしても、他のシャードは影響を受けず、障害の影響範囲を抑制します。

地理的最適化: コンプライアンス、パフォーマンス、レイテンシのニーズに応じて、シャードを異なる地域に配置します。

シャーディングは2つのレベルで処理できます:

アプリケーションレベルのシャーディング: アプリケーションロジックが各操作のシャードを決定します。柔軟性がありますが、複雑さが増します。

データベースレベルのシャーディング: データベース管理システム(DBMS)がネイティブにシャーディングをサポートし、ルーティングとストレージを内部で処理します。

シャーディング vs. パーティショニング

パーティショニングは、データをセグメントに分割する広範な概念であり、多くの場合、単一のデータベースインスタンス内で行われます。

シャーディングは特に水平パーティショニングを指しますが、異なるマシン上の別々の物理データベースにまたがります(シェアードナッシング)。

垂直パーティショニングは列でデータを分割し、水平パーティショニング/シャーディングは行で分割します。

パーティショニングは通常単一のマシン内に存在するため、本質的に水平スケーラビリティを提供しません。シャーディングは、ストレージと計算の両方を複数のマシンに分散し、真のスケールアウトを可能にします。

シャーディングを使用する理由

単一ノードデータベースのスケーリング制限

ストレージ容量: 各サーバーには有限のディスクとメモリの制限があります。

計算リソース: 処理できる同時クエリ/書き込みには限界があります。

ネットワーク帯域幅: ネットワークスループットがボトルネックになる可能性があります。

地理的制約: すべてのデータを1つのサイトに保存すると、レイテンシと規制の問題が発生する可能性があります。

代替手段とその限界

垂直スケーリング: サーバーハードウェアのアップグレード。物理的制約とコストによって制限されます。

レプリケーション: 読み取りスケーリングとフェイルオーバーのためにデータを複製しますが、書き込みをスケールせず、一貫性の問題を引き起こす可能性があります。

キャッシング: インメモリキャッシュ(例: Redis、Memcached)は読み取りを高速化しますが、ストレージや書き込みのスケーリングは解決しません。

パーティショニング: 単一ノード内で管理性を向上させますが、スケールアウトはしません。

シャーディングは、データとワークロードの両方を多数のマシンに分散することでこれらを克服し、真の水平スケーラビリティ、パフォーマンスの向上、障害の封じ込めを実現します。

シャーディングの仕組み

1. シャードキーの選択:
各レコードのシャードを決定するために使用されるフィールド(例: ユーザーID、地域、日付)を選択します。シャードキーは安定しており、高いカーディナリティを持ち、均等に分散されている必要があります。

2. データの分散:
選択したシャーディング戦略(ハッシュ、範囲、ディレクトリなど)を使用して、シャードキーに基づいてデータをシャードに割り当てます。

3. クエリと書き込みのルーティング:
システム(アプリケーションコードまたはDBMS)が各操作を正しいシャードにルーティングします。

実装オプション:

• アプリケーションレベルのシャーディング: クエリと書き込みをルーティングするためのアプリケーション内のカスタムロジック
• データベースレベルのシャーディング: データベースシステムがネイティブにシャーディングを処理。例としてMongoDB、Cassandra、シャーディング拡張機能を持つ一部のSQLデータベースがあります

シャーディング戦略

選択する方法は、データ分散、パフォーマンス、スケーラビリティ、運用の複雑さに影響します。

キーベース(ハッシュ)シャーディング

仕組み:
シャードキー(例: ユーザーID)にハッシュ関数を適用し、結果がターゲットシャードを決定します。例えば、hash(user_id) mod N(Nはシャード数)。

利点:

• 均等なデータ分散(ハッシュ関数とキーが適切に選択されている場合)
• アルゴリズムによるルーティング。ルックアップテーブル不要

欠点:

• シャードの追加/削除には再バランシングが必要(多くのレコードを移動する必要がある)
• コンシステントハッシングで緩和可能

例:
3つのシャードの場合、キー123のレコードはシャードhash(123) mod 3に配置されます。

範囲ベースシャーディング

仕組み:
シャードキーの連続した値の範囲に基づいてデータをシャードに割り当てます。

利点:

• 実装と理解が簡単
• 範囲クエリに効率的

欠点:

• 不均等な分散(「ホットスポット」)。一部の範囲がはるかにアクティブな場合

例:
ID 1〜1Mのユーザーをシャード1に、1M〜2Mをシャード2に配置など。

ディレクトリベースシャーディング

仕組み:
各キー(または範囲)を特定のシャードにマッピングするルックアップテーブルを維持します。

利点:

• 非常に柔軟。任意のマッピングをサポートし、再バランシングが容易

欠点:

• ディレクトリが単一障害点およびパフォーマンスボトルネックになる可能性

例:
アプリケーションがディレクトリサービスに、ユーザーID 1057を保持するシャードを問い合わせます。

垂直シャーディング

仕組み:
列でテーブルを分割し、異なる列(機能)を異なるマシンに配置します。

使用例:
機能が独立してアクセスまたは更新される場合。

例:
ソーシャルネットワークで、ユーザープロファイルを1つのシャードに、ユーザー投稿を別のシャードに配置。

シャーディングの利点

欠点と課題

実装と運用の複雑さ: 複数のデータベース、ルーティング、バックアップ、監視、スキーマ変更の管理により複雑さが増します。

データホットスポット/不均等な分散: シャードキーの選択が不適切だと、特定のシャードに過負荷がかかり、ボトルネックが発生します。

再バランシング/リシャーディング: シャード数の変更や偏りの修正には大量のデータの移動が必要で、多くの場合ダウンタイムやパフォーマンスへの影響があります。

クロスシャードクエリ: 複数のシャードにまたがるクエリは遅く、調整が複雑です。

一貫性と参照整合性: シャード間で強い一貫性と外部キー制約を強制することが困難です。

「一方通行のドア」: シャーディングアーキテクチャからモノリシックなものに戻すことは困難です。

限定的なデータベースサポート: すべてのデータベースがネイティブにシャーディングをサポートしているわけではありません。カスタムロジックやミドルウェアが必要な場合があります。

シャーディングを使用すべき場合

適切なシナリオ

• データセットが単一ノードのストレージ、計算、ネットワーク容量を超える
• 書き込み/読み取りスループット要件が単一ノード(およびそのレプリカ)で処理できる範囲を超える
• マルチテナンシー。各テナントのデータを別々のシャードに分離できる
• 特定の地域にデータを保存するための規制またはパフォーマンス要件
• テナント、地域、データドメインの独立したスケーリングが必要

使用すべきでない場合

• 垂直スケーリングやレプリケーションで簡単に処理できる小〜中規模のデータセット
• より単純な最適化(インデックス作成、クエリチューニング、キャッシング)で十分な場合
• 運用のオーバーヘッドと複雑さがスケーラビリティの利点を上回る場合

意思決定のガイダンス:
シャーディングの前に、常に垂直スケーリング、レプリケーション、クエリ最適化を使い切ってください。他のアプローチがスケーリングまたは分離のニーズに不十分な場合にのみシャーディングを行ってください。

ベストプラクティス

適切なシャードキーの選択:

• 安定している必要がある(時間とともに変化しない)
• ホットスポットを避けるために均等に分散
• 最も一般的なクエリパターンに合わせる

将来の成長を計画:

• データ分散の変化を予測。シャードの追加/再バランシングの容易さを考慮して設計

クロスシャード操作の最小化:

• クロスシャードのジョインやトランザクションを最小限に抑えるようにクエリとスキーマを設計

参照データのレプリケート:

• 静的または変更頻度の低いデータ(ルックアップテーブルなど)を各シャードに保存し、クロスシャードルックアップを回避

操作の自動化:

• 監視、バックアップ、フェイルオーバー、バランシングに自動化を使用

ホットスポットの監視:

• シャードごとの負荷を追跡。必要に応じて再バランシング

結果整合性の検討:

• 複数のシャードにまたがる操作では、結果整合性モデルが強い一貫性よりも実用的な場合があります

使用例

ソーシャルネットワーク

問題: 数十億のユーザープロファイル、投稿、関係。高い読み取り/書き込みボリューム。

解決策: ユーザーIDまたは地域でユーザーデータをシャーディング。各シャードはユーザーのサブセットとそのコンテンツを管理。

利点: ユーザーの成長に応じてスケールし、障害を分離し、グローバル分散をサポート。

Eコマースプラットフォーム

問題: 大規模な製品カタログと注文履歴。高い同時実行性。

解決策: 注文IDの範囲または顧客地域で注文データをシャーディング。カテゴリまたは価格帯で製品データをシャーディング。

利点: ワークロードを並列化し、クエリパフォーマンスを向上させ、地域規制をサポート。

SaaSアプリケーション(マルチテナンシー)

問題: 各テナントには異なるデータと使用パターンがある。

解決策: テナントIDでテナントをシャードに割り当て(ルックアップまたはハッシュ戦略を使用)。

利点: テナントデータを分離し、顧客ベースに応じてスケールし、テナント固有のスケーリングをサポート。

AIインフラストラクチャ

問題: トレーニング/推論用の大規模データセット。分散計算。

解決策: データソース、時間範囲、データタイプでデータセットをシャーディング。計算ノード間で分散。

利点: 並列処理を可能にし、データアクセスを高速化し、モデルのトレーニングと提供のスケーラビリティを実現。

シャーディングの代替手段

垂直スケーリング: サーバーハードウェアのアップグレード(CPU、RAM、ディスク)

レプリケーション: 負荷分散と高可用性のための読み取りレプリカの追加

キャッシング: インメモリキャッシュ(例: Redis、Memcached)を使用してデータベース負荷を削減

パーティショニング: 単一のデータベースノード内でテーブルを分割

コンテンツ配信ネットワーク(CDN): 静的/読み取り中心のデータをオフロード

シャーディングにコミットする前に、これらのオプションを検討してください。

参考文献

• GeeksforGeeks: Database Sharding – System Design
• Hello Interview: Sharding in System Design
• Medium: Understanding Sharding in System Design
• Microsoft Learn: Sharding Pattern
• MongoDB: Database Sharding Explained
• DigitalOcean: Understanding Database Sharding
• Aerospike: What is Sharding?
• YouTube: What is Database Sharding?