あなたは、銀行取引イベントを us-east にある Bigtable の cluster-a に送信するアプリケーションを持っています。新たに us-central1 に cluster-b を追加することにしました。cluster-a は cluster-b にデータをレプリケートします。
要件:
-
いずれかのクラスターが利用不能になった場合でも、Bigtableが読み取りおよび書き込みリクエストを受け付け続けること。
-
リクエストが自動的にもう一方のクラスターにルーティングされること。
どのようなデプロイ戦略を使用すべきですか。
正解：C
この問題の鍵は、マルチクラスター・インスタンスにおいて、高い可用性と自動フェイルオーバーを実現するための Bigtable の設定です。
1. アプリプロファイル (App Profile) とルーティング
Bigtableでは、アプリケーションからのトラフィックをどのようにクラスターにルーティングするかをアプリプロファイルで制御します。
-
シングルクラスター・ルーティング: 特定の単一のクラスターにトラフィックを送信します。そのクラスターがダウンすると、リクエストは失敗します。
-
マルチクラスター・ルーティング: 複数のクラスターをグループ化し、高可用性を実現します。トラフィックは自動的に最も近い利用可能なクラスターに送信されます。
2. 要件の達成
問題の要件は、「いずれかのクラスターが利用不能になった場合でも読み取り/書き込みを受け付け続け、自動的にもう一方のクラスターにルーティングされる」ことです。
-
可用性の維持と自動ルーティング: これは、まさに マルチクラスター・ルーティング が提供する機能です。これにより、両クラスター間でレプリケーションが有効になり、一方のクラスターがダウンしても、Bigtableクライアントライブラリが自動的に健全なクラスターに切り替えます（フェイルオーバー）。
3. カスタムアプリプロファイルの使用
-
デフォルトのアプリプロファイル: デフォルトのプロファイルは、インスタンス作成時に自動で作成され、通常はシングルクラスター・ルーティングを使用するように設定されます（特に単一クラスターのインスタンスの場合）。
-
カスタムの必要性: Bigtableは、アプリケーションごとに異なるトラフィックのルーティング、分離、またはリトライ動作を定義するためにカスタムアプリプロファイルの作成を推奨しています。特に、ルーティング戦略（シングルからマルチへ）を変更したり、特定のワークロードに対してフェイルオーバー動作を制御したりする場合は、デフォルトを変更するのではなく、新しいカスタムアプリプロファイルを作成するのがベストプラクティスです。
したがって、要件である「自動フェイルオーバーによる可用性の確保」を満たすために マルチクラスター・ルーティング を選択し、かつ Bigtable の設計原則に従って カスタムアプリプロファイル を作成するのが正解となります。
コメント