次の方法で共有

  • [アーティクル]

可用性とスケーラビリティの両方の向上

多くのアプリケーションでは、可用性とスケーラビリティの両方を向上させることが重要です。レプリケーションは、これら両方を実現するためのソリューションの重要な役割を担います。アプリケーションによっては、可用性とスケーラビリティのどちらかのみを向上させるためにレプリケーションを使用する場合もあります。いずれかのみを向上させればよい場合は、以下の対応するシナリオを参照してください。

以下の 2 つの図は、それぞれ、レプリケーションを使用することにより可用性とスケーラビリティが向上するアプリケーションを示しています。どちらの図でも、3 つのデータベースは相互にピアとなります。各データベースに、同一のスキーマとデータが格納されています。これらのデータベースに対する書き込み操作は、パーティション分割する必要があります。たとえば、データベースに製品カタログが含まれている場合は、名前が A ～ I で始まる製品については最初のデータベース、J ～ R で始まる製品については 2 番目のデータベース、S ～ Z で始まる製品については 3 番目のデータベースが更新されるように設定することができます。この更新は、その後で他のデータベースにレプリケートされます。

最初の図は、各 Web サーバーとアプリケーション サーバーが特定のキャッシュ サーバーのデータを使用する構成を表しています。ユーザーの読み取りや更新を特定のアプリケーション サーバーに送り、次に、特定のキャッシュ サーバーに送ります。アプリケーション サーバーがキャッシュを直接更新するため、集中管理を行う更新元サーバーは不要です。各キャッシュの更新は、他のキャッシュに反映されます。

レプリケーションを使用した読み取り処理の分散

2 番目の図は、地理的に分散した 3 つのサーバーを表しています。これらの 3 つのサーバー間で、データ フローが発生します。各サーバーが読み取り要求をサポートしており、可用性を向上させることができます。

分散した場所へのピア ツー ピア レプリケーション

Adventure Works Cycles の例

Adventure Works Cycles は、データベースの概念とシナリオを説明するために使用する架空の製造会社です。詳細については、「AdventureWorks サンプル データベース」を参照してください。

Adventure Works Cycles は、ロサンゼルス、ロンドン、台北など、世界中に多数のオフィスを展開しています。顧客の注文情報は、それぞれの場所で収集されてから、他の場所にレプリケートされます。

注文情報は、どの場所からでも読み取ることができます。そのため、ロンドン オフィスで読み取り操作の負荷が大きい場合は、内部アプリケーションによって、この操作の一部を他の 2 つのオフィスに分散することができます。

たとえば、ロンドン オフィスのサーバーがメンテナンスのために停止されている場合でも、注文は他のオフィスから取得できるため、ロンドン オフィスの職員はデータの読み取りや入力を続行できます。ロンドンのサーバーがオンラインに戻った後で、停止中に取得した変更がロンドンのサーバーに反映されるため、このサーバーには最新の状態が反映されます。

このシナリオの一般的な要件

レプリケーションを使ってスケーラビリティと可用性を高めるアプリケーションには一般的に以下のような要件があり、適切なレプリケーション ソリューションで対処する必要があります。

  • 変更を任意のサーバーで実行できる必要があり、その変更を他のすべてのサーバーにレプリケートする必要があります。

  • システムでトランザクションの一貫性を保つ必要があります。

  • システムの待機時間が短く、あるサーバーで行われた更新が速やかに他のサーバーに反映される必要があります。

  • 多数のトランザクションのレプリケーションを処理できる、高いスループットが必要です。

  • レプリケーション処理のオーバーヘッドをできるだけ少なくする必要があります。

このシナリオで使用するレプリケーションの種類

MicrosoftSQL Server では、出版業界にたとえてレプリケーション システムのコンポーネントを表しています。コンポーネントには、パブリッシャ (出版社)、サブスクライバ (購読者)、パブリケーション (出版物) とアーティクル (記事)、およびサブスクリプション (定期購読物) があります。

上記の図では、すべてのキャッシュ サーバーがパブリッシャとサブスクライバです。パブリケーションには、各サーバーにあるレプリケートされたデータベース内のすべてのデータが含まれます。各データ テーブルはアーティクルです (アーティクルは、ストアド プロシージャなどの他のデータベース オブジェクトの場合もあります)。各サーバーは、他のサーバーからパブリケーションへのサブスクライブを行い、サブスクリプションとしてスキーマとデータを受信します。システムのコンポーネントの詳細については、「レプリケーションのパブリッシング モデルの概要」を参照してください。

SQL Server では、さまざまなアプリケーション要件に対して各種のレプリケーション (スナップショット レプリケーション、トランザクション レプリケーション、およびマージ レプリケーション) を用意しています。このシナリオはピア ツー ピア トランザクション レプリケーションで最適に実装され、前のセクションで概説した要件によく適合します。ピア ツー ピア トランザクション レプリケーションの詳細については、「ピア ツー ピア トランザクション レプリケーション」を参照してください。

注意注意

アプリケーションで、複数のノードの特定の行に対する変更を同時に行う場合は、データの競合が発生する可能性があります。このような場合は、競合の処理に適しているマージ レプリケーションを使用してください。マージ レプリケーションの詳細については、「マージ レプリケーションの概要」を参照してください。

トランザクション レプリケーションは、以下に示すこのシナリオの主な要件に対応するように作られています。

  • 任意のサーバーで変更が可能

  • トランザクションの一貫性

  • 短い待機時間

  • 高いスループット

  • 最小限のオーバーヘッド

トランザクション レプリケーションのピア ツー ピア オプションを使用すると、複数のサーバーが同じデータに対してパブリッシュおよびサブスクライブを行うことができます。ピア ツー ピア トポロジのすべてのノードはピアです。各ノードは同じスキーマとデータにパブリッシュおよびサブスクライブします。変更 (挿入、更新、および削除) はすべてのノードで実行でき、その後、その他のすべてのノードにレプリケートされます。

このシナリオの実装手順

このシナリオを実装するには、最初にパブリケーションとサブスクリプションを作成してから、各サブスクリプションを初期化してください。詳細については、以下を参照してください。

サブスクリプションの初期化が終わり、ピア間でデータ フローが発生したら、共通の管理および監視作業の詳細について以下のトピックを参照してください。

関連項目

その他の技術情報

サーバー間環境でのデータのレプリケート