フェイルオーバー

Bigtable クラスタが応答しなくなった場合、レプリケーションにより受信トラフィックを同じインスタンスの別のクラスタにフェイルオーバーできます。フェイルオーバーは、アプリケーションが使用しているアプリ プロファイルと、アプリ プロファイルの構成方法に応じて、手動または自動で行えます。

このページでは、レプリケーションを使用しているインスタンスでの手動フェイルオーバーと自動フェイルオーバーの仕組みについて説明します。 フェイルオーバーを行う方法については、フェイルオーバーの管理をご覧ください。

このページを読む前に、Bigtable レプリケーションの概要を理解する必要があります。 また、使用可能なルーティング オプションについても理解しておく必要があります。

手動フェイルオーバー

アプリ プロファイルが単一クラスタのルーティングによりすべてのリクエストを 1 つのクラスタに送信している場合、別のクラスタへのフェイルオーバーをどの時点で行うかを自分で判断する必要があります。

別のクラスタにフェイルオーバーしたほうがよいことを示す兆候はいくつかあります。

  • クラスタが一時的なシステムエラーを大量に返すようになる。
  • 大量のリクエストでタイムアウトが発生するようになる。
  • 平均レスポンス レイテンシが許容限度を超えて増加する。

このような兆候はさまざまな理由で発生するため、別のクラスタにフェイルオーバーしても根本的な問題が解決するとは限りません。フェイルオーバーの前後でインスタンスをモニタリングし、指標が改善していることを確認してください。

手動フェイルオーバーを実行する方法については、手動フェイルオーバーの実行をご覧ください。

自動フェイルオーバー

アプリのプロファイルで複数クラスタ ルーティングを使用している場合、Bigtable は自動的にフェイルオーバーを処理します。最も近いクラスタがリクエストを処理できない場合、Bigtable は対応可能な最も近いクラスタにトラフィックをルーティングします。

クラスタが利用できない時間が非常に短い時間であっても、自動フェイルオーバーが発生することがあります。たとえば、Bigtable が 1 つのクラスタにリクエストをルーティングし、そのクラスタの応答が過度に遅い、または一時的なエラーを返す場合、Bigtable は通常、別のクラスタでそのリクエストを再試行します。

複数クラスタのルーティングを使用しており、期限付きでリクエストを送信した場合、Bigtable は期限を遵守するために必要な場合は自動的にフェイルオーバーします。リクエストの期限が近づいても、最初のクラスタがレスポンスを送信していない場合、Bigtable は次に近いクラスタにリクエストを再ルーティングします。

Bigtable は、最後の書き込みを優先する内部アルゴリズムを使用して、レプリケーションが完了する前にフェイルオーバーの結果として発生する可能性のあるデータの競合を処理します。詳しくは、競合の解決をご覧ください。

複数クラスタ ルーティングでレプリケーションを使用してアプリケーションの高可用性（HA）を実現する場合は、複数の Google Cloud リージョン内またはその近くにクライアント サーバーまたは VM を配置します。アプリケーション サーバーが Google Cloudでホストされていない場合でも、この推奨事項は適用されます。これは、データがアプリケーション サーバーに最も近い Google Cloudリージョンを介して Google Cloud ネットワークに入るためです。リクエストと同様に、フェイルオーバーは距離が短いほど早く完了します。

自動フェイルオーバーの多くは、非常に短時間で行われるため気付かれません。Google Cloud コンソールの [自動フェイルオーバー] グラフを確認して、一定期間内に自動的に再ルーティングされたリクエストの数を確認できます。インスタンスのリストを開き、インスタンス名をクリックし、[モニタリング] をクリックします。

次のステップ