信頼性: 障害対策
このドキュメントでは、信頼性が障害対策にどのように適用されるかについて説明します。ディザスターという言葉からは自然災害をイメージされるかもしれませんが、このセクションの範囲としては、個々のマシンの損失から、リージョンの壊滅的な消失に至るまで具体的な障害について説明します。前者は BigQuery が自動的に対処する日常的に発生する事象ですが、後者は必要に応じて対応するようにアーキテクチャを設計する必要があります。障害対策は、お客様の責任と交差する範囲であることを理解いただくことが重要です。
BigQuery は業界トップクラスの 99.99% 稼働率の SLA を提供します。これは、2 つの異なるゾーンでデータを書き込み、冗長なコンピューティング容量をプロビジョニングする、BigQuery のリージョン アーキテクチャによって実現されます。BigQuery SLA は、リージョン（us-central1 など）とマルチリージョン（US など）で同じという点に留意することが重要です。
シナリオの自動処理
BigQuery はリージョナル サービスであるため、1 つのマシンやゾーン全体の損失でさえも自動的に処理する必要があります。BigQuery が複数のゾーン上に構築されているという事実は、ユーザーからは見えなくなっています。
マシンの損失
マシンの障害は、Google が運用している規模では日常的に発生します。BigQuery は、マシンの障害を自動的に処理するように設計されており、含まれるゾーンに影響を与えることはありません。
クエリの実行は、内部的には、多数のマシンに並行してディスパッチできる小さなタスクに分割されます。マシンのパフォーマンスの急激な減少や低下は、別のマシンに作業を再度ディスパッチすることで自動的に処理されます。このようなアプローチは、テール レイテンシを削減するために重要です。
BigQuery は、リード・ソロモン エンコードを使用して、データのゾーンコピーを効率的かつ永続的に保存します。万が一、複数のマシンの障害によってゾーンコピーが失われた場合には、データは他の少なくとも 1 つのゾーンにも同じ方法で保存されます。このような場合、BigQuery は問題を検出し、冗長性を復元するためにデータの新しいゾーンコピーを作成します。
ゾーンの損失
特定のゾーンのコンピューティング リソースの可用性は、BigQuery の 99.99% 稼働率の SLA を満たすには不十分です。BigQuery はデータとコンピューティング スロットの両方に自動化されたゾーン冗長性を備えています。短いゾーンの途絶は、頻繁には起こりませんが発生します。しかし、BigQuery の自動化により、重大な中断が発生してから 1～2 分以内で、クエリは別のゾーンにフェイルオーバーされます。すでに処理中のクエリは、すぐには復元されないかもしれませんが、新しく発行されたクエリは復元されます。これは、新しく発行されるクエリがすぐに完了する一方で、処理中のクエリは完了までに長時間を要することから表面化することになります。
1 つのゾーンが長期間使用できなくても、BigQuery は同期的に 2 つのゾーンにデータを書き込むため、データが失われることはありません。したがって、ゾーンが消失したとしても、お客様はサービスの中断を経験することはありません。
エラーのタイプ
障害には、ソフト障害とハード障害の 2 種類があります。
ソフト障害とは、ハードウェアが破壊されることのない、運用上の不全です。たとえば、停電、ネットワーク パーティション、マシン クラッシュなどが考えられます。一般に、ソフト障害が発生した場合でも、BigQuery のデータは失われません。
ハード障害とは、ハードウェアが破壊される運用上の不全です。ハード障害はソフト障害よりも深刻です。ハード障害の例として、洪水、テロ、地震、ハリケーンなどによる被害があります。
可用性と耐久性
BigQuery データセットを作成するときに、データを保存するロケーションを選択します。このロケーションは次のいずれかです。
- リージョン: アイオワ州（
us-central1）やモントリオール（northamerica-northeast1）などの具体的な地理的場所。 - マルチリージョン: 米国（
US）やヨーロッパ（EU）など、2 つ以上の地理的な場所を含む広い地理的なエリア。
どちらの場合も、BigQuery は選択したロケーションの 1 つのリージョン内にある 2 つの異なる Google Cloud ゾーンにデータのコピーを自動的に保存します。
BigQuery は、ストレージの冗長性に加えて、複数のゾーンにわたり冗長なコンピューティング容量を維持します。複数のアベイラビリティ ゾーンにわたり冗長ストレージとコンピューティングを組み合わせることで、BigQuery は高可用性と耐久性の両方を実現します。
マシンレベルの障害が発生した場合、BigQuery は数ミリ秒以下の遅延で稼働を継続します。現在実行中のクエリは、すべて処理を続行します。ゾーンでソフト障害またはハード障害が発生した場合に、データの損失が発生することがあります。ただし、現在実行中のクエリが失敗し、再送信が必要になる場合があります。停電、変圧器の破損、ネットワーク パーティションなどによるゾーンのソフト障害は十分に検証が行われています。この障害は数分以内に自動的に緩和されます。
リージョン全体のネットワーク接続が失われた場合など、ソフト リージョンに障害が発生すると、そのリージョンがオンラインに復旧するまで可用性が失われます。ただし、データが失われることはありません。リージョンのハード障害の場合（たとえば、障害によってリージョン全体が破壊された場合）は、そのリージョンに保存されているデータが失われる可能性があります。BigQuery では、別の地理的リージョンにデータのバックアップやレプリカが自動的に提供されません。リージョン間でデータセットのコピーを作成して、障害復旧戦略を強化できます。
BigQuery データセットのロケーションの詳細については、ロケーションに関する留意事項をご覧ください。
計画または復旧が必要なシナリオ
リージョンの消失
BigQuery では、前例のない物理的リージョン損失が発生した場合、耐久性や可用性は確保されていません。これは、「リージョンとマルチリージョン」の構成に当てはまります。そのため、このようなシナリオで耐久性と可用性を維持するには、お客様による計画が必要です。ネットワーク停止などの一時的な損失において、BigQuery の 99.99% の SLA では十分でない場合は、冗長な可用性を考慮する必要があります。
リージョンの破壊的な損失に直面した場合のデータ損失を避けるには、データを別の地理的位置にバックアップする必要があります。たとえば、データのスナップショットを、地理的に異なる別のリージョンの Google Cloud Storage に定期的にエクスポートできます。これは、バッチデータ処理のユースケースに従って実行できます。
BigQuery のマルチリージョンの場合は、マルチリージョンの範囲内にあるリージョンにはバックアップしないようにします。たとえば、米国のデータを us-central1 リージョンにバックアップしないでください。このリージョンとマルチリージョンは障害発生ドメインを共有し、災害時の運命を共有している可能性があります。代わりに、米国以外のリージョン（northamerica-northeast1 など）にデータをバックアップしてください。データ所在地の要件により、バックアップを米国内に保存する必要がある場合は、us-central1 と us-east1 などの 2 つのリージョンをペアリングすることをおすすめします。
長期にわたって使用不能となる状況を回避するには、地理的に離れた 2 つの BigQuery ロケーションに、複製されたデータとプロビジョニングされたスロットの両方を用意する必要があります。前述したように、リージョンとマルチリージョンを混在させないでください。これらは障害発生時に運命を共にする可能性があるためです。
リージョン冗長の設定で最も信頼性の高いアーキテクチャは、ホット - ホット実行（アクティブ - アクティブ）です。つまり、ワークロードはプライマリ リージョンとセカンダリ リージョンの両方で並行して実行されます。コストは高くなりますが、セカンダリ リージョンが継続的に検証を受け、フェイルオーバーが必要な場合に動作することが保証されます。リージョンの停止中の可用性がそれほど問題にならない場合は、データを別のリージョンにバックアップすることで耐久性を確保できます。
データの誤削除やデータの破損
BigQuery のマルチバージョン同時実行制御アーキテクチャにより、BigQuery はタイムトラベルをサポートしています。この機能により、過去 7 日間の任意の時点でのデータをクエリできます。これにより、過去 7 日間に誤って削除、変更、または破損されたデータのセルフサービスでの復元が可能になります。タイムトラベルは、削除されたテーブルに対しても機能します。
BigQuery は、テーブルをスナップショットする機能もサポートしています。この機能により、7 日間のタイムトラベル期間よりも長い期間、同じリージョン内でデータを明示的にバックアップできます。スナップショットは純粋にメタデータ オペレーションであり、追加のストレージ バイトは発生しません。これにより、誤削除に対する保護は強化されますが、データの耐久性は向上しません。
障害復旧のユースケース
リアルタイム分析
このユースケースでは、ストリーミング データがエンドポイントのログから BigQuery に連続して取り込まれます。リージョン全体で BigQuery が長期にわたって使用不能になるのを防ぐには、別のリージョンでデータを継続的に複製し、スロットをプロビジョニングする必要があります。取り込み経路に Pub/Sub と Dataflow を使用するため、BigQuery が利用できない場合でもアーキテクチャには復元性が備わっていますが、この高次の冗長性は費用の点で見合わない可能性があります。
ユーザーが us-east4 の BigQuery データを、us-central1 の Archive Storage クラスにある Cloud Storage へのエクスポート ジョブを使用して夜間にエクスポートするように構成したとします。これにより、us-east4 で壊滅的なデータ損失が生じた場合の耐久性の高いバックアップが実現します。この場合、最後にエクスポートされたバックアップは最悪の場合、最大 24 時間前のものになる可能性があるため、目標復旧時点（RPO）は 24 時間です。Cloud Storage バックアップから us-central1 の BigQuery にデータを復元する必要があるため、目標復旧時間（RTO）は数日になる可能性があります。BigQuery をバックアップが存在するリージョンとは異なるリージョンにプロビジョニングする場合は、まず、このリージョンにデータを転送する必要があります。また、リカバリ リージョンで冗長スロットをあらかじめ購入していない限り、要求される数量によっては必要な BigQuery 容量がプロビジョニングされるまでに遅延が生じる可能性があります。
バッチデータ処理
このユースケースでは、日次レポートが決まった期限までに完了し、規制当局に送信されることがビジネス上の重要事項です。処理パイプライン全体のインスタンスを 2 つ別々に実行して冗長性を実装することは、コストに見合う価値があります。us-west1 と us-east4 など異なる 2 つのリージョンを使用することで、地理的な分離と、1 つのリージョンが長期間使用できなくなった場合や、まれにリージョンが消失した場合に備えて 2 つの独立した障害ドメインを確保します。
レポートは 1 回だけ配信する必要があると仮定すると、両方のパイプラインが正常に終了するという想定される場合の整合性を取る必要があります。合理的な方法は、正常に完了したときに、たとえば Pub/Sub トピックを通知することによって、最初にパイプラインを終了した結果を選択することです。別の方法では、結果を上書きして、Cloud Storage オブジェクトのバージョンを変更します。後で終了したパイプラインが不正なデータを書き込んだ場合は、先に終了したパイプラインが書き込んだバージョンを Cloud Storage から復元することで正常なデータに戻せます。