このページは Cloud Translation API によって翻訳されました。

レプリケーション

このページでは、Spanner でのデータの複製方法、Spanner レプリカの種類、読み取り / 書き込みでのレプリカの役割、レプリケーションの利点について説明します。

概要

Spanner はバイトレベルで自動的にレプリケートします。Spanner の読み取りと書き込みのライフサイクルで説明されているように、基盤となるファイルシステムでこの機能を活用します。 Spanner は、このファイルシステムのファイルにデータベースの変異を書き込みます。マシンやディスクに障害が発生したときに、このファイルシステムがファイルの複製と復旧を行います。

Spanner が構築されている分散ファイルシステムでバイトレベルでのレプリケーションが行われている場合でも、Spanner はデータを複製してデータの可用性と地理的な局所性を維持します。簡単に言うと、Spanner のデータはすべて行に編成されています。Spanner は、これらの行の複数のコピー（レプリカ）を作成し、地理的に異なる場所に保存します。Spanner は、Paxos ベースの同期レプリケーション方式を使用しています。この方式では、書き込みを commit する前に、投票レプリカがすべての書き込みリクエストの採決を行います。これにより、グローバルに同期されたレプリケーションが実行され、Spanner 読み書きレプリカまたは読み取り専用レプリカから最新のデータを読み取ることが可能になります。

Spanner は、各データベースのスプリットのレプリカを作成します。スプリットは連続した行を保持します。ここで、行は主キーにより順序付けられます。1 つのスプリットのデータはすべて同じレプリカに物理的に保存さSpanner は独立した障害ゾーンに各レプリカを提供します。詳細については、タグの概要をご覧ください。

一連のスプリットは Paxos で保存と複製が行われます。Paxos レプリカセット内で、1 つのレプリカがリーダーとして選択されます。リーダーレプリカは書き込みを処理します。一方、読み取り / 書き込みレプリカまたは読み取り専用レプリカは、リーダーと通信を行わずに読み取りリクエストを処理できます。強力な読み取りがリクエストされた場合、通常はリーダーにコンサルトして、読み取り専用レプリカが最近のミューテーションをすべて受け取ったことを確認んする必要があります。リーダーレプリカからインスタンス構成のクロスリージョンレプリカに複製されるデータの変更率とデータ量をモニタリングするには、データレプリケーションをモニタリングするをご覧ください。

Spanner レプリケーションのメリット

Spanner レプリケーションのメリットには、次のものがあります。

データの可用性: データのコピーが増えるため、読み取り時にクライアントで利用可能なデータ量が増加します。投票レプリカの過半数を占めれば書き込みを commit できるため、レプリカの一部が使用できない場合でも、Spanner は書き込みを行うことができます。
地理的な局所性: Spanner と異なるリージョンや大陸にデータが配置されている場合、ユーザーやサービスから地理的に近い場所にデータが保存されます。
単一のデータベースエクスペリエンス: Spanner は、同期レプリケーションとグローバルの強整合性により、単一のデータベースエクスペリエンスを提供できます。
アプリケーション開発の省力化: Spanner は ACID に準拠し、グローバルな強整合性を提供するため、Spanner を利用するデベロッパーは、結果整合性に対処するロジックをアプリケーションに追加する必要がありません。アプリケーションの開発とその後のメンテナンスを迅速かつ簡単に行うことができます。

レプリカの種類

Spanner には、読み書きレプリカ、読み取り専用レプリカ、ウィットネスレプリカの 3 種類のレプリカがあります。ベースインスタンス構成を形成するリージョンとレプリケーショントポロジは固定されています。

ベースの単一リージョン（リージョン）インスタンス構成では、読み取り / 書き込みレプリカのみを使用します。
ベースのデュアルリージョンインスタンス構成では、読み取り / 書き込みレプリカとウィットネスレプリカを使用します。
ベースのマルチリージョンインスタンス構成では、3 種類のレプリカをすべて組み合わせて使用します。

カスタムインスタンス構成を作成し、リージョンインスタンス構成とマルチリージョンインスタンス構成に読み取り専用レプリカを追加できます。

次の表に、Spanner レプリカの種類とそれらのプロパティの概要を示します。

レプリカの種類	投票可能か	リーダーにできるか	読み込みを処理できるか	レプリカを手動で構成できる
読み書き	はい	○	はい	いいえ
読み取り専用	いいえ	×	はい	○^*
ウィットネス	はい	×	×	いいえ

^* 詳細については、カスタムインスタンス構成を使用してインスタンスを作成する方法をご覧ください。

読み取り / 書き込みレプリカ

読み書きレプリカは、読み取りと書き込みの両方をサポートします。このレプリカの特性は次のとおりです。

データの完全なコピーを維持します。
読み取りを処理します。
書き込みを commit するかどうかを投票できます。
リーダーの選出に参加できます。
リーダーになる資格があります。
リージョンインスタンスで使用できる唯一のレプリカタイプです。

読み取り専用レプリカ

読み取り専用レプリカは読み取りをサポートします（書き込みはサポートしません）。これらのレプリカは、リーダーや書き込みの commit を決める投票に参加しません。書き込みに必要なクォーラムサイズを増やさずに読み取り容量をスケーリングできます。読み取り専用レプリカの特性は次のとおりです。

データの完全なコピーを維持します。このデータはリーダーの読み書きレプリカから複製されます。
書き込みの commit を決める投票に参加しません。したがって、読み取り専用レプリカのロケーションは、書き込みのレイテンシに影響しません。
リーダーになることはできません。
読み取りを処理します。
アプリケーションに最も近いレプリカである場合、読み取り専用レプリカは通常、ステイルネスが 15 秒以上であると想定して、リーダーリージョンへのラウンドトリップなしでステイル読み取りを提供できます。有向読み取りを使用して、読み取り専用トランザクションと単一読み取りを、マルチリージョンインスタンス構成の特定のレプリカタイプまたはリージョンにルーティングすることもできます。詳細については、有向読み取りをご覧ください。

強力な読み取りを行う場合には、リーダーレプリカへのラウンドトリップが必要になる可能性があります。ラウンドトリップはタイムスタンプのネゴシエーションのみを行い、リーダーからの実際のデータの提供は行いません。タイムスタンプのネゴシエーションはリーダーでの CPU 効率の高いオペレーションであり、通常、データはすでに転送中です。この通信はシステムによって自動的に処理されます。

古い読み取りと強力な読み取りの詳細については、読み取りのセクションをご覧ください。

オプションの読み取り専用レプリカ

カスタムのリージョンまたはマルチリージョンインスタンス構成を作成し、オプションの読み取り専用レプリカを追加して、読み取りをスケーリングし、低レイテンシのステイル読み取りをサポートできます。[オプションのリージョン] にリストされているロケーションをオプションの読み取り専用レプリカとして追加できます。選択した読み取り専用レプリカのロケーションが表示されない場合は、新しいオプションの読み取り専用レプリカリージョンをリクエストできます。

オプションの読み取り専用レプリカはすべて、コンピューティング容量、ストレージ、レプリケーションの費用の対象となります。さらに、読み取り専用レプリカをカスタムインスタンス構成に追加しても、インスタンス構成の Spanner SLA は変更されません。リーダーリージョンとは異なる大陸に読み取り専用レプリカを追加する場合は、少なくとも 2 つの読み取り専用レプリカを追加することをおすすめします。これにより、読み取り専用レプリカのいずれかが使用できなくなった場合に、読み取りレイテンシを低く維持できます。

ベストプラクティスとして、まずカスタムインスタンス構成の非本番環境インスタンスでパフォーマンスワークロードをテストします。リージョン間のレイテンシの中央値データについては、リージョン間のレイテンシとスループットのベンチマークダッシュボードをご覧ください。たとえば、カスタムインスタンス構成を eur6 マルチリージョン基本構成で作成し、us-east1 でオプションの読み取り専用レプリカを作成した場合、europe-west4 のリーダーリージョンへのラウンドトリップ時間のため、us-east1 のクライアントの予想される高い読み取りレイテンシは約 100 ミリ秒になります。十分な古さの古い読み取りではラウンドトリップが発生しないため、はるかに高速です。ロック分析情報とトランザクション分析情報を使用して、レイテンシの増加につながるトランザクションを特定することもできます。

オプションの読み取り専用レプリカを追加する手順については、カスタムインスタンス構成を作成するをご覧ください。

ウィットネスレプリカ

ウィットネスレプリカは、読み取りをサポートしませんが、書き込みの commit を決める投票に参加します。これらのレプリカにより、読み書きレプリカがデータの完全なコピーを保存し、読み取りを処理するために必要なストレージやコンピューティングリソースを使用せずに、書き込みクォーラムを簡単に実現できます。ウィットネスレプリカの特性は次のとおりです。

デュアルリージョンインスタンスとマルチリージョンインスタンスで使用されます。
データの完全なコピーは維持しません。
読み取りを処理しません。
書き込みの commit を決める投票に参加します。
リーダーの選出に参加しますが、リーダーレプリカになる資格はありません。

書き込みと読み取りでのレプリカの役割

このセクションでは、Spanner の書き込みと読み取りでのレプリカの役割について説明します。この役割を理解することで、デュアルリージョン構成とマルチリージョン構成で Spanner がウィットネスレプリカを使用する理由も理解できます。

書き込み

クライアントの書き込みリクエストは、リーダー以外のレプリカがクライアントの近くに存在している場合や、リーダーレプリカがクライアントから地理的に遠い場所に存在する場合でも、常にリーダーレプリカで最初に処理されます。デュアルリージョンまたはマルチリージョンインスタンス構成を使用し、クライアントアプリケーションがリーダー以外のリージョンにある場合、Spanner はリーダー認識ルーティングを使用して読み取り / 書き込みトランザクションを動的にルーティングし、データベースのレイテンシを短縮します。詳しくは、リーダー認識ルーティングをご覧ください。

リーダーレプリカは、受信した書き込みを記録し、この書き込みへの投票資格がある他のレプリカに同時に転送します。投票資格のあるレプリカは、書き込みを完了した後、書き込みを commit するかどうかの投票結果をリーダーに返します。投票レプリカ（書き込みクォーラム）の過半数が書き込みの commit に同意すると、書き込みが commit されます。バックグラウンドでは、ウィットネスを除く残りのすべてのレプリカが書き込みを記録します。読み書きレプリカまたは読み取り専用レプリカは、完全なデータを含む別のレプリカに不足データをリクエストします。

読み取り

読み取りリクエストの同時実行モードによっては、クライアントの読み取りリクエストでリーダーレプリカとの通信が必要になる場合があります。

リーダーレプリカがシリアル化に必要なロックを保持しているため、読み書きトランザクションに含まれる読み取りはリーダーレプリカから処理されます。
読み取りの同時実行モードによっては、単一の読み取りメソッド（トランザクションのコンテキスト外の読み取り）と読み取り専用トランザクションの読み取りでリーダーとの通信が必要になる場合があります同時実行モードの詳細については、読み取りタイプをご覧ください。
- 強力な読み取りリクエストは、任意の読み書きレプリカまたは読み取り専用レプリカに送信されます。リクエストがリーダー以外のレプリカに送信された場合、このレプリカはリーダーと通信を行い、読み取りを実行する必要があります。
- ステイル読み取りリクエストは、リクエストのタイムスタンプに従って、最も近い利用可能な読み取り専用レプリカもしくは読み書きレプリカに送信されます。読み取りリクエストを送信したクライアントに最も近いレプリカがリーダーレプリカの場合、リーダーレプリカに送信されます。

読み取り専用レプリカとウィットネスレプリカを使用する理由

ベースマルチリージョン構成では、読み取り / 書き込みレプリカ、読み取り専用レプリカ、ウィットネスレプリカを組み合わせて使用しますが、ベースのデュアルリージョン構成では読み取り / 書き込みレプリカとウィットネスレプリカを使用し、ベースリージョン構成では読み取り / 書き込みレプリカのみを使用します。この違いは、書き込みと読み取りでのレプリカのロールが異なることに関係しています。書き込みの場合、Spanner は、変異を commit するために投票レプリカの大半の同意を得る必要があります。つまり、Spanner データベースに書き込みを行うたびに、投票レプリカ間の通信が必要になります。この通信のレイテンシを最小限に抑えるには、投票レプリカの数を最小にし、これらのレプリカを可能な限り近くに配置します。そのため、ベースリージョン構成には読み取り / 書き込みレプリカが 3 つだけ含まれ、それぞれが独自のアベイラビリティゾーンにあり、データの完全なコピーが含まれ、投票可能です。1 つのレプリカで障害が発生しても、他の 2 つのレプリカが書き込みクォーラムを形成できます。この構成のレプリカは同じ地理的リージョンにあるため、ネットワークのレイテンシは最小限になります。

ベースとなるデュアルリージョン構成とマルチリージョン構成には、設計上、複数のレプリカが含まれます。これらのレプリカは異なるデータセンターにあるため、クライアントは複数の場所から迅速にデータを読み取ることができます。この追加のレプリカには次のような特性があります。これらのレプリカはすべて読み書きレプリカにすることもできますが、構成に複数の読み書きレプリカを追加すると書き込みクォーラムのサイズが大きくなるため、これは望ましくありません。相互に通信を行うレプリカが増えるため、ネットワークレイテンシが増加する可能性があります。特に、レプリカが地理的に分散した場所にある場合はレイテンシが増大します。また、読み書きレプリカにはデータの完全なコピーが含まれるため、必要なストレージも増加します。読み取り / 書き込みレプリカの数を増やすのではなく、ベースのデュアルリージョン構成には追加のウィットネスレプリカを使用し、ベースのマルチリージョン構成には読み取り専用レプリカとウィットネスレプリカを使用します。これらのレプリカは、読み取り / 書き込みレプリカよりも役割が少ないものです。

読み取り専用レプリカは、リーダーや書き込みの commit を決める投票に参加しません。書き込みに必要なクォーラムサイズを増やさずに読み取り容量をスケーリングできます。
ウィットネスレプリカは、リーダーと書き込みの commit を決める投票に参加しますが、データの完全なコピーは持たず、リーダーになったり、読み取りを処理したりはできませんこれにより、読み書きレプリカがデータの完全なコピーを保存し、読み取りを処理するために必要なストレージやコンピューティングリソースを使用せずに、書き込みクォーラムを簡単に実現できます。

データレプリケーションをモニタリングする

インスタンス構成のリーダーレプリカからクロスリージョンレプリカに複製されるデータの変化率と量をモニタリングできます。変化率は 1 秒あたりのバイト数で、データ量はバイト単位です。これを行うには、クロスリージョンレプリケートされたバイト数（instance/cross_region_replicated_bytes_count）モニタリング指標を使用します。

Google Cloud コンソールでこの指標を表示する手順は次のとおりです。

Google Cloud コンソールで [Monitoring] に移動します。

[モニタリング] に移動
ナビゲーションメニューで [Metrics Explorer] を選択します。
[指標] フィールドで、[指標を選択] プルダウンをクリックします。
[リソース名または指標名でフィルタ] フィールドで、[Cloud Spanner Instance] > [Instance] > [Cross region replicated bytes] を選択し、[適用] をクリックします。

この指標は、インスタンスでクロスリージョンレプリケーションアクティビティがある場合にのみ、[有効な指標] で確認できます。有効な指標にない場合は、[無効な指標] に表示されます。デフォルトでは、UI はアクティブな指標のみをフィルタして表示します。有効な指標と無効な指標の両方を表示するには、[有効] チェックボックスをオフにします。

このグラフは、指定した期間内のすべての Spanner インスタンスにわたる複製データの変化率（1 秒あたりのバイト数）を示しています。
省略可: 変更率ではなく、複製されたデータの量（バイト単位）を表示するには:
1. [集計] フィールドで [合計] プルダウンをクリックし、[整列指定子を構成] を選択します。
2. [アライメント関数] フィールドで [レート] プルダウンをクリックし、[デルタ] を選択します。
3. テーブルの種類として [グラフ] ではなく [表] または [両方] を選択します。
  
  この表には、指定した期間内にレプリケートされたデータの量（バイト単位）が表示されます。
省略可: 特定のインスタンスの使用状況または属性の使用状況を表示するには:
1. [フィルタ] フィールドを使用して、インスタンス ID、データベース ID、ソースリージョン、宛先リージョン、タグなどのフィルタを追加します。
2. [フィルタを追加] をクリックして複数のフィルタを追加します。

Google Cloud の指標の一覧については、Google Cloud の指標をご覧ください。