データベースのクラスタリングとは？

データベースのクラスタリングは、複数のデータベースサーバー（または ノード)を統一システムに統合し、可用性、耐障害性、パフォーマンスを向上させます。このアプローチは、ワークロードを分散し、冗長性を維持することでデータを管理し、継続的なアップタイムを確保し、ノード間の負荷分散を改善します。

この資料では、データベースのクラスタリングがどのように機能するかを説明し、関連する概念と比較する： シャーディング.

データベースのクラスタリングはどのように機能するのか？

データベースクラスタリングは、複数のサーバー（ノード）を組み合わせて、単一の統合データベースシステムとして機能させます。クラスタ内の各ノードはデータやワークロードの一部を担当しますが、それらが一体となってシステム全体が円滑に動作するようにします。この分散アプローチにより、パフォーマンス、フォールトトレランス、スケーラビリティが向上する。

クラスタリングの基本原理は冗長性である。1台のサーバーに依存するのではなく、複数のノードにデータを分散させる。1つのノードに障害が発生しても、他のノードがその責任を引き継ぐことができるため、継続的な運用が保証されます。この冗長性により、ダウンタイムとデータ損失を最小限に抑えることができるため、クラスタリングは特に高い処理能力を必要とするアプリケーションに有効です。 可用性.

一般的なクラスタでは、データとリクエストは2つの方法のいずれかでノードに分散される：

  • 複製： データはすべてのノードで複製される。各ノードには同じデータが格納されているため、1つのノードに障害が発生しても、他のノードは同じクエリに遅滞なく応答できる。 レプリケーション は、複数のノードが同じデータを同時に扱うことができ、負荷が分散されるため、読み込みの多いオペレーションに最適である。
  • パーティショニング： データはチャンクに分割され、各ノードは全体の一部のみを保存する。この方法は 水平スケーリングパーティショニングは、各ノードが全データのごく一部しか処理しないため、大規模なデータセットを効率的に処理できる。パーティショニングは通常、特定のデータを指定されたノードにルーティングする書き込みの多いワークロードに使用されます。

ノード間通信

クラスタ内のノードは相互に常時通信し、ヘルス、ステータス、ワークロードに関するデータを共有します。この連携により、トラフィックのバランスをとり、最適なパフォーマンスを確保することができる。この連携はクラスタ管理システムによって管理され、クエリの分散、データの複製、障害処理などのタスクを監視して割り当てます。

データの一貫性

クラスタリングにおける重要な課題は、すべてのノード間でデータの一貫性を維持することです。クラスタでは、システムの設計に応じてさまざまな一貫性モデルを使用します。これには次のようなものがあります：

  • 強い一貫性： ノードが常に最新のデータを反映することを保証するが、同期による待ち時間が発生する可能性がある。例えばCouchbaseは 耐久性 オプションは、信頼性を向上させる一方で、レイテンシーの増加をトレードオフにする（あるいはその逆）。
  • 最終的な一貫性： 更新の伝搬に多少の遅延は許容するが、可用性と速度を優先する。読み込みと書き込みが異なる速度や異なるリージョンで行われるシステムでよく使われる。例として、Couchbaseのクロスデータセンターレプリケーション（XDCR）がある。 クラスタ間でデータセット全体を複製する.

データベースのクラスタリングとシャーディングの比較

クラスタリングとシャーディングは互いに排他的なものではありません。実際、この2つのテクニックを併用することで、より堅牢で、スケーラブルかつ高性能なデータベースシステムを構築できることが多い。クラスタリングが冗長性、フォールトトレランス、ロードバランシングに重点を置くのに対し、シャーディングは複数のサーバーにデータを分散させることでスケーラビリティを重視します。以下は、これらのアプローチの主な違いを強調した表である。

特徴 クラスタリング シャーディング
データ分布 ノード間で複製または分割 シャード間の水平パーティション
フォールト・トレランス 自動フェイルオーバー機能付き 限定的、手動または複雑なリカバリーが必要
スケーラビリティ クラスタ内のノード数に制限あり 無制限、シャードを追加することで水平方向に拡張可能
パフォーマンス重視 読み取り負荷が高く、バランスの取れたワークロードに最適化されている。 書き込みが多く、大規模なデータセットに最適
データの分離 低い、ノードはデータを共有するか、ワークロードを分割する 高い、各シャードは独立している
データの冗長性 データはレプリケートまたはパーティショニングされる データは別々のパーティションに分割される
ロードバランシング トラフィックはノード間で分散される 本来はそうではないが、シャードごとに管理できる
複雑さ 自動化された管理でよりシンプルなセットアップ より複雑、カスタムシャード管理（または自動シャーディング機構）が必要

シャーディングなしのクラスタリング： シナリオによっては、データベース・クラスタリングを単独で使用することもある。例えば、大規模なeコマースサイトのような読み取り負荷の高いアプリケーションを持つ企業は、複製されたノードのクラスタをセットアップすることができる。各ノードにはデータベース全体のコピーがあり、クエリは各ノードに分散して負荷分散されます。1つのノードに障害が発生しても、別のノードが中断することなく迅速に引き継ぐことができる。このセットアップは、MySQLやPostgreSQLのようなリレーショナル・データベースでは一般的で、高可用性が優先され、データセットはシャーディングなしで管理できるほど小さい。

クラスタリングなしのシャーディング： 一方、書き込みの多いアプリケーションや、1台のマシンに収まらないような巨大なデータセットを持つシステムでは、クラスタリングなしでシャーディングを使うことができる。数百万人のユーザーを抱えるソーシャルメディア・プラットフォームでは、ユーザーIDごとにデータベースをシャーディングし、各シャードにユーザーデータのサブセットを格納することができる。この場合、各シャードは独立して動作し、障害を処理するための特別なメカニズムが実装されていない限り、冗長性はない。例えばMongoDB™は、クラスタリングを必要とせずに複数のサーバーでシャーディングを行うことができ、スケーラブルですが、内蔵のフォールトトレランスは限定的です。

シャーディングによるクラスタリング： 高可用性とスケーラビリティの両方が重要な大規模システムでは、シャーディングとクラスタリングが併用されることが多い。このハイブリッドアプローチは、Couchbaseのようなシステムで使われており、シャーディング(バケット)をクラスタリングと組み合わせることで、高いスケーラビリティと耐障害性を備えたシステムを構築し、両者の長所を融合させている。

データベース・クラスタ・アーキテクチャ

データベースクラスタのアーキテクチャは、複数のノード間でデータがどのように保存、アクセス、管理されるかを定義します。データベースクラスターアーキテクチャには主に3つのタイプがあります： 何も共有せず、ディスクを共有し、すべてを共有する.これらのアーキテクチャは、性能、スケーラビリティ、耐障害性のトレードオフが異なるため、さまざまなユースケースに適している。

シェアード・ナッシング・アーキテクチャー

シェアードナッシング・アーキテクチャでは、クラスタ内の各ノードは独立して動作する。各ノードは独自のCPU、メモリ、ストレージを持ち、他のノードとリソースを共有することはありません。データはノード間で分割され、各ノードがデータ全体のサブセットを管理する。

  • リソースの共有はない： ノードはメモリやディスクを共有しないため、ボトルネックが軽減される。
  • 高い拡張性： 中央リソースがないため、新しいノードを簡単に追加できる。
  • 故障の隔離： あるノードが故障した場合、そのノードが管理するデータだけが影響を受ける。他のノードは通常通り稼動し続ける（他のノードはおそらく レプリカ で挽回する)。

このアーキテクチャは、大規模なデータセットを持つウェブアプリケーションのような、水平に拡張する必要があるワークロードに最適である。Couchbaseのようなシステムは、シェアードナッシングアーキテクチャを使用しており、データはより良いパフォーマンスと信頼性のためにノードに分散されている。

共有ディスク・アーキテクチャ

共有ディスク・アーキテクチャでは、すべてのノードが同じストレージ・システムへのアクセスを共有しますが、各ノードは独自のCPUとメモリを持っています。これは、複数のノードがディスク上の同じデータにアクセスできることを意味し、データの一貫性と集中管理が容易になります。

  • 共有ストレージ： すべてのノードが同じディスクまたはストレージシステムにアクセスする。
  • データの一元化： すべてのノードが同じデータを参照するため、データのパーティショニングやレプリケーションの必要性が低くなる。しかし、これは共有ディスクの障害がシステム全体のダウンにつながる可能性があることも意味する。
  • 適度なスケーラビリティ： このアーキテクチャは拡張可能だが、共有ストレージシステムの帯域幅によってパフォーマンスがボトルネックになる可能性がある。

共有ディスク・アーキテクチャは、複数のノードが同じデータに同時にアクセスする必要があるオラクルのようなシステムでよく使われる。

シェアード・エブリシング・アーキテクチャー

共有型アーキテクチャでは、すべてのノードがストレージとメモリの両方のリソースを共有します。このモデルは、すべてのデータとメモリにすべてのノードがいつでもアクセスできることを保証します。このアーキテクチャは負荷分散とデータの可用性に役立ちますが、ノードが共有リソースへのアクセスを競合するため、性能に大きなボトルネックが生じる可能性もあります。

  • 完全なリソース共有： すべてのノードがストレージとメモリのリソースを共有するため、リソースの管理とデータの一貫性が容易になります。
  • ロードバランシング： 同じリソースにアクセスできるため、ノード間でワークロードを均等に分散できる。
  • 拡張性に限界がある： ノードを増やすと共有リソースの競合が増えるため、このアーキテクチャはうまく拡張できない。

シェアード・エブリシング・アーキテクチャは、スケーリングにおける固有の制限とボトルネックの可能性があるため、今日ではあまり一般的ではないが、IBM Db2が最も有名な例である。

データベース・クラスタリングの利点

データベースのクラスタリングにはいくつかの重要な利点があり、高負荷のアプリケーションに不可欠なソリューションとなっています。以下はその例である：

高い可用性

クラスタリングは、複数のノードにデータを複製することで高可用性を保証します。1つのノードに障害が発生した場合、他のノードが自動的に引き継ぎ、ダウンタイムを最小限に抑え、システムへの継続的なアクセスを維持します。

スケーラビリティ

クラスタリングは水平スケーラビリティを提供し、データやトラフィックの増加に応じてノードを追加できます。これにより、一貫したパフォーマンスと、ボトルネックなしに増加するワークロードを処理する能力が保証されます。

フォールト・トレランスとフェイルオーバー

フォールト・トレランスにより、クラスタリングは組み込みのフェイルオーバー・メカニズムを通じてノードの障害を自動的に処理し、リクエストが健全なノードに再ルーティングされることを保証し、サービスの中断を最小限に抑えます。

その他の利点としては、ロードバランシング、パフォーマンスの向上、データの冗長性、メンテナンスの柔軟性などがある。

データベース・クラスタリングのガイドライン

データベースクラスタをセットアップするとき、特定の原則は最適なパフォーマンスと信頼性を確保するのに役立ちます。幸いなことに、これらの多くはCouchbaseのようなクラスタリング用に構築されたシステムによって自動的に管理され、複雑さの多くを簡素化しています。

  • 目標を明確にする： 一般的には、高可用性、スケーラビリティ、パフォーマンスが目標となるでしょう。
  • 適切なアーキテクチャを選択する： クラスターをセットアップする際には、ワークロード（読み込みが多いか、書き込みが多いか、何も共有しないか）を考慮してください。
  • フォールトトレランスとフェイルオーバー： レプリケーションと冗長性を活用することで、ダウンタイムを最小限に抑え、フェイルオーバー構成の心配が少なくなる。
  • ロードバランシング： ワークロードを均一化し、最適なパフォーマンスを確保するために、ノード間でトラフィックをどのように分散するかを検討します。
  • スケーラビリティとキャパシティ： 成長を見据えて計画を立て、何も共有しないことが最も拡大しやすいアーキテクチャであることを忘れてはならない。
  • データの一貫性： アプリケーションのニーズに応じて、強力な、あるいは最終的な一貫性を確保することで、複数の選択肢が生まれます。
  • モニタリングとメンテナンス： システム内のツールを使用することで、パフォーマンスを追跡し、問題を特定することができます。

シェアード・ナッシング・アーキテクチャのCouchbaseは、特に大規模で成長し続けるシステム（例． LinkedIn そして トレンディオールレプリケーション、シャーディング、フェイルオーバーを自動的に処理するからだ。

データベースクラスタの作成方法

データベースクラスタの作成には、適切なテクノロジの選択、ノードの設定、クラスタ間の適切な通信の確保など、複数の段階が含まれます。ここでは、重要なステップの概要を説明する：

データベースソフトを選択する： まず最初に、 データベースシステムを選択する クラスタリングをサポートしています。Couchbaseのような人気のあるデータベースは、ビルトインのクラスタリング機能を提供している。ソフトウェアの選択はワークロードに依存する、 データモデルそしてスケーラビリティのニーズ。

ノードを提供する： データベースクラスタでは、ノードは一緒に動作する個々のサーバーです。これらのノードには、CPU、メモリ、ストレージなどの適切なハードウェアリソースをプロビジョニングする必要があります。インフラストラクチャに応じて、物理マシンまたは仮想サーバーにすることができます。

ネットワークを設定する： ノード間の円滑な通信を確保するには、ネットワーキングを設定する必要があります。このプロセスには、IPアドレスとサブネットを設定し、ノードが安全なチャネルで通信できるようにすることが含まれます。低レイテンシーで広帯域幅の接続は、パフォーマンスにとって極めて重要です。

データレプリケーションを設定する： クラスタリングの核となるコンポーネントの1つがレプリケーションで、複数のノード間でデータをコピーすることで、障害発生時の可用性を確保します。レプリケーション・メカニズムを設定し、ノード間でデータが一貫して同期されるようにします。こうすることで、フォールトトレランスも強化される。

ロードバランシング： データベースクラスタにこの機能が組み込まれていない限り、クラスタ全体にトラフィックを均等に分散させるためにロードバランサが実装されることがよくあります。ロードバランサーは、負荷と可用性に基づいて受信クエリを異なるノードに誘導し、単一のノードが過負荷になるのを防ぎます。

クラスタ管理ツールを設定する： クラスタ管理ソフトウェアは、クラスタの健全性を監視し、ノードのパフォーマンスに関する洞察を提供し、障害を警告するのに役立ちます。以下のようなツールがあります。 Kubernetes は、これらの詳細を管理し抽象化するためによく使われる。

フォールトトレランスのテスト： 初期セットアップの後、クラスタがノード障害に対処できるかをテストすることが重要です。テストにより、以下のような場合にダウンタイムやデータ損失を発生させることなく、残りのノードがワークロードを管理できることを確認します。 ノードがオフラインになる.

監視し、維持する： 一旦クラスタが稼動すれば、継続的な モニタリング が重要です。パフォーマンス・メトリクス、データ・レプリケーションの遅延、各ノードの健康状態に常に目を配る。クラスタを安全かつ効率的に保つために、定期的なアップデートとパッチを適用する必要があります。

データベースクラスタの作成には、ネットワークの設定からレプリケーションやロードバランシングの設定まで、複数の技術的なステップが必要です。適切な計画と管理により、クラスタが堅牢で、スケーラブルであり、高可用性要件に対応できることを保証します。

主な要点とその他のリソース

クラスタリングのみは、高可用性、フォールトトレランス、読み込みの多いワークロードのバランスをとるのに理想的です。シャーディング単独では、巨大なデータセットの処理や書き込みの多いワークロードのスケールアウトに最適だが、クラスタリングが提供する冗長性に欠ける。シャーディングとクラスタリングを組み合わせることで、大規模なスケーラビリティと高い耐障害性を両立させることができ、可用性とパフォーマンスを維持しながら膨大なデータ負荷を処理する大規模アプリケーションに最適なアーキテクチャとなる。

クラスタリングとシャーディングの長所を理解し、それらがどのように互いを補い合うことができるかを理解することで、高可用性、スケーラビリティ、またはその両方など、特定のニーズを満たすデータベースシステムをより適切に設計することができます。

データベースクラスタを自分で構築したいですか？Couchbaseのシェアードナッシングアーキテクチャを使えば簡単です。ここでは、クラスターをどの程度コントロールしたいかによって、いくつかのオプションを紹介します：

Couchbaseのクラスタリングに関連する概念について詳しく学ぶには、次のサイトをご覧ください。 blog そして コンセプト・ハブ.

建設開始

当社の開発者ポータルをチェックして、NoSQLを探求し、リソースを閲覧し、チュートリアルから始めましょう。

今すぐ開発する
カペラ無料体験

わずか数クリックでCouchbaseをハンズオン。Capella DBaaSは、最も簡単かつ迅速に始めることができます。

無料
ISVのためのCouchbase

複雑さとコストを抑えてパワフルなアプリを構築。

さらに詳しく