Cloud Spanner のマルチリージョン リーダー配置機能でレイテンシを短縮

※この投稿は米国時間 2021 年 9 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。

Cloud Spanner は、無制限のスケーリング、強整合性、最大 99.999% の可用性を備えた Google のフルマネージド リレーショナル データベースです。

Spanner でデータベース インスタンスを設定する際は、デプロイ先をリージョン構成とマルチリージョン構成のどちらにするかを選択できます。

• リージョン構成は、名前のとおり単一のリージョンにデプロイされるもので、ゾーンが停止しても保護され、99.99% の可用性を提供します。

• マルチリージョン構成は、上記とは対照的に 3 つ以上のリージョンにデプロイされるもので、リージョンが停止しても保護され、99.999% の可用性を提供します。

現在 Google は、世界をまたぐ 13 のマルチリージョン構成を提供しています。各マルチリージョン構成は、デフォルトのリーダー リージョン、2 つ目の読み取り / 書き込みリージョン、ウィットネス リージョンという少なくとも 3 つのリージョンに分散しています。一部の構成では、読み取り専用のレプリカを含むリージョンが 1 つ以上存在する場合があります。

ブログ投稿記事の Cloud Spanner のマルチリージョン構成について理解するに記載されているように、クライアントのすべての書き込みリクエストはまずデフォルトのリーダーに送信されます。そこで書き込みがログに保存されてから、他の投票レプリカに送信されます。したがって、レイテンシを最小限に抑えるためには、デフォルトのリーダーとクライアント アプリケーションができる限り近い位置にあるマルチリージョン構成を選択することが重要になります。

しかし、自社のニーズをほぼ満たすマルチリージョン構成を特定した際に、アプリケーション クライアントがデフォルトのリーダーよりも 2 つ目の読み取り / 書き込みリージョンに近い位置にある場合はどうすればよいでしょうか？

例を見てみましょう。salesdb という名前のデータベースがあるとします。このデータベースのほとんどのトラフィックはベルギー（europe-west1）からのもので、データベースがリージョン障害に耐えられることが求められます。

この例では、レイテンシを最小限に抑えるために、デフォルトのリーダーがベルギー（europe-west1）で、読み取り / 書き込みレプリカがその近くのロンドン（europe-west2）などのリージョンに配置されているマルチリージョン構成を選択します。

構成に eur5 を使用することも可能かもしれませんが、詳しく調べてみると、eur5 のデフォルトのリーダーはロンドンにあり、2 つ目の読み取り / 書き込みリージョンはベルギーにあります。レイテンシを最小限に抑えるためには、それを逆（リーダーがベルギー、2 つ目のリージョンがロンドン）にしたいところです。

リーダー配置機能のおかげで、数回クリックするだけで salesdb のデフォルトのリーダー リージョンと 2 つ目の読み取り / 書き込みリージョンを切り替えることができます。

salesdb のデフォルトのリーダーを切り替える手順は次のとおりです。

1. Cloud Console の [Spanner インスタンス] ページに移動します。

2. リーダー リージョンを変更したい DB を含むインスタンスの名前（今回は salesdb）をクリックし、「デフォルト リーダー リージョン」の横の鉛筆アイコンをクリックします。

1. 次の DDL を実行します。

ALTER DATABASE salesdb SET OPTIONS(default_leader='europe-west1');

1. 更新されたデータベースの概要で、更新が成功したかを確認できます。

この手順を完了させると、europe-west1 は salesdb のデフォルト リーダーになります。

ユースケース

リーダーの配置機能は、特に以下の 2 つのシナリオで役立ちます。

1. アプリケーションのトラフィックのほとんどが 1 つの地理的リージョンから送信されている場合、そのリージョンにデフォルトのリーダー リージョンを配置してレイテンシを最小限に抑えることができます。

2. アクティブ / パッシブなアプリケーションのアーキテクチャでは、リージョン間における計画的または予期しないアプリケーションのフェイルオーバー後に、Cloud Spanner のデフォルトのリーダー リージョンをアプリケーションのアクティブ インスタンスと同じ場所に配置できます。これにより、リージョン間のリクエストを回避しレイテンシを最小限に抑えられます。

構成可能なリーダー配置機能を使用してアプリケーションのレイテンシを改善する方法の例は以下のとおりです。

アクティブ / パッシブなアプリケーションのアーキテクチャ

アクティブ / パッシブモデルは、高可用性を確保するための一般的なマルチリージョン アプリケーションのアーキテクチャです。1 つのリージョン内のアプリケーション インスタンスがアクティブ インスタンスであり、すべてのトラフィックに対応します。2 つ目のリージョン内のアプリケーション インスタンスは待機している状態（パッシブ）であり、アクティブ リージョンに障害が発生した場合に代わりにすべてのトラフィックに対応します。こうしたアプリケーションには Cloud Spanner のマルチリージョン構成やリーダー配置機能が有効です。

一つの例として、北バージニア リージョンにアクティブ インスタンス、サウスカロライナ リージョンにパッシブ インスタンスを持つアプリケーションがあるとしましょう。アプリケーションの高可用性ニーズを満たすため、Cloud Spanner の nam3 マルチリージョン構成を使用できます。デフォルトのリーダー リージョンは北バージニアに設定されています。通常、アプリケーションのアクティブ リージョンは Cloud Spanner のデフォルトのリーダー リージョンと同じなため、読み取りおよび書き込みレイテンシは小さくなります。

ここで、起こりうる障害シナリオを考えてみましょう。

1. 北バージニアでアプリケーション インスタンスのみに障害発生

アプリケーションはサウスカロライナにフェイルオーバーします。アプリケーションのリージョンが Cloud Spanner のデフォルトのリーダー リージョンと異なるため、アプリケーションのレイテンシは大きくなります。これは、すべての書き込みリクエストが北バージニアへのクロスリージョン リクエストになるためです。

レイテンシを改善するには、リーダー配置機能を使用して、Cloud Spanner のデフォルトのリーダー リージョンをサウスカロライナに更新します。これにより、アプリケーションと Cloud Spanner のリーダー リージョンがどちらもサウスカロライナに配置され、レイテンシが小さくなります。なお、デフォルトのリーダー リージョンを更新しても、アプリケーションには一切影響なくダウンタイムも発生しません。

2. 北バージニアで Cloud Spanner のみの障害発生

この場合、Cloud Spanner によってリーダーは自動的にサウスカロライナに移動します。なお、このシナリオでは RPO と RTO は 0 とします。アプリケーションのアクティブ インスタンスはそのまま北バージニアに残るので、アプリケーションのレイテンシは大きくなります。

長期間の停止の場合、Cloud Spanner のリーダー リージョンに合わせてアプリケーションをサウスカロライナにフェイルオーバーして、パフォーマンスを向上させます。Cloud Spanner のデフォルトのリーダー リージョンを明示的にサウスカロライナに更新して、リージョン復旧後に北バージニアに戻るのを阻止することもできます。

3. 北バージニア全体に障害が発生し、アプリケーションのアクティブ インスタンスも Cloud Spanner も停止

この場合、Cloud Spanner によりリーダーが自動的にサウスカロライナに移行されます。アプリケーションへの影響はありません。同様に、アプリケーションもサウスカロライナにフェイルオーバーされます。これでリージョンに障害が発生しても、アプリケーションとデータベースは引き続き使用できます。さらに、データベースの新しいリーダー リージョンはアプリケーションのフェイルオーバー リージョンと同じなので、アプリケーションのレイテンシは小さいままです。

なお、北バージニアが復旧すると、リーダーは Cloud Spanner によって自動的に北バージニアに戻されることに留意してください。復旧後もリーダー リージョンとしてサウスカロライナを引き続き使用し、アプリケーションのアクティブ インスタンスと連動させたい場合、Cloud Spanner のデフォルトのリーダー リージョンをサウスカロライナに明示的に更新できます。

マルチテナント アーキテクチャ

マルチテナントのアプリケーション モデルで、テナントごとに別のデータベースを使用している場合、リーダー配置機能を使用してデータベースごとのリーダー リージョンを構成し、テナントのアクセスパターンと連動させることができます。たとえば、nam3 構成を使用したマルチテナントのアプリケーションで考えてみましょう。リーダー リージョンを、サウスカロライナが拠点のテナントのデータベースにはサウスカロライナに、北バージニアが拠点のテナントのデータベースには北バージニアに設定します。そうすることで、両方のリージョンのテナントのレイテンシを小さく抑えることができます。

終わりに

Cloud Spanner のリーダー配置機能を使用してデフォルトのリーダー リージョンとアプリケーションのトラフィックを連動させることで、書き込みレイテンシを最小限に抑えられます。デフォルトのリーダー リージョンの構成方法の詳細については以下をご覧ください。https://cloud.google.com/spanner/docs/instance-configurations#configuring_the_default_leader_region

詳細

• Spanner を使用開始するには、インスタンスを作成するか、Spanner Qwik Start でお試しください。

• Spanner のリージョン構成やマルチリージョン構成を詳しく知りたい場合は、Cloud Spanner のマルチリージョン構成について理解するをご覧ください。

-Cloud Spanner プロダクト マネージャー Mark Donsky