信頼性について

このドキュメントでは、可用性、耐久性、データ整合性、パフォーマンスの整合性、データ復旧、エラー処理に関する考慮事項の確認など、BigQuery の信頼性機能について説明します。

このドキュメントでは、次に挙げる 3 つの主要な検討事項への対処をサポートします。

  • BigQuery がジョブに適したツールかどうかを判断する。
  • BigQuery の信頼性の要素を理解する。
  • 具体的なユースケースに対する具体的な信頼性要件を明確にする。

BigQuery の選択

BigQuery は、大規模なデータセットを保存して分析するために構築された、フルマネージドのエンタープライズ データ ウェアハウスです。メガバイトからペタバイトまでのデータの取り込み、保存、読み取り、クエリを安定したパフォーマンスで行い、基盤となるインフラストラクチャを管理する必要はありません。その性能とパフォーマンスから、BigQuery はさまざまなソリューションでの使用に適しています。そのいくつかは、リファレンス パターンとして詳細にドキュメント化されています。

一般に BigQuery は、大量のデータを取り込み、分析するワークロードに適しています。具体的には、ストリーミング取り込みによるリアルタイムのデータ分析、BigQuery ML による予測データ分析、異常検出など、予測可能なパフォーマンスを示す大量のデータを分析することが重要になるユースケースの場合に、効果的にデプロイできます。ただし、オンライン トランザクション処理（OLTP）スタイルのアプリケーションをサポートするデータベースをお探しの場合は、Spanner、Cloud SQL、または Bigtable など、そうしたユースケースに適していると考えられる他の Google Cloud サービスを検討してください。

BigQuery の信頼性の要素

可用性

可用性により、ユーザーが BigQuery からデータの読み取りまたは BigQuery への書き込みを行える能力が定義されます。BigQuery は、どちらも 99.99% の SLA で高可用性を実現するように構築されています。どちらのオペレーションにも、次の 2 つのコンポーネントが関与します。

  • BigQuery サービス
  • クエリを実行するために必要なコンピューティング リソース

データの取得に使用される BigQuery API の働きによって、BigQuery サービスに信頼性がもたらされます。コンピューティング リソースの可用性は、クエリの実行時にユーザーが使用できる容量によって異なります。BigQuery のコンピューティングの基本単位と、結果として得られるスロット リソース エコノミーの詳細については、スロットについてをご覧ください。

耐久性

耐久性については、SRE Workbook の SLO の実装の章で説明されているとおり、「正常に読み取ることができるデータの割合」と言われています。

データの整合性

整合性により、書き込みまたは変更が行われたデータのクエリ方法に対するユーザーの期待が定義されます。データの整合性の一つの側面は、データの取り込みに対して「1 回限り」というセマンティクスを実施することです。詳細については、データの読み込みにおける導入事例の例の「ソリューションの信頼性」と失敗したジョブ挿入を再試行するをご覧ください。

パフォーマンスの安定性

一般的に、パフォーマンスは 2 つの要素で表すことができます。レイテンシは、クエリなどの長時間データ取得オペレーションの実行時間の測定値です。スループットは、BigQuery が特定の期間に処理できるデータ量の測定値です。BigQuery はマルチテナントに対応しており、水平方向にスケーラブルな設計のため、スループットは任意のデータサイズにスケールアップできます。レイテンシとスループットの相対的な重要度は、特定のユースケースによって決まります。

データ復旧

停止後にデータを復元する機能を測定する方法には、次の 2 つがあります。

  • 目標復旧時間（RTO）:インシデントの発生後にデータが使用できない期間。
  • 目標復旧時点（RPO）:インシデントの前に収集されたデータの許容できる消失量。

これらの検討事項は、ゾーンやリージョンで複数日または破壊的な停止が発生するといったまれなケースで特に重要です。

障害対策

「ディザスター」という言葉からは自然災害をイメージされるかもしれませんが、このセクションの範囲としては、個々のマシンの損失から、リージョンの壊滅的な消失に至るまで具体的な障害について説明します。前者は 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 から復元することで正常なデータに戻せます。

エラー処理

信頼性に影響するエラーに対処するためのベスト プラクティスは次のとおりです。

失敗した API リクエストを再試行する

クライアント ライブラリやパートナー ツールを含む BigQuery のクライアントは、API リクエストの発行時に切り捨て型指数バックオフを使用する必要があります。つまり、クライアントがシステムエラーまたは割り当てエラーを受け取った場合、一定回数まではリクエストを再試行しますが、その際バックオフ間隔はランダムに増加します。

この再試行方法を採用すると、エラー発生時のアプリケーションの堅牢性が大幅に向上します。通常の動作条件下でも、BigQuery の 99.99% の可用性 SLA に記載されているように、リクエスト 1 万件あたり約 1 件しか失敗しないことが期待されます。異常な条件下では、このエラー率は増加する可能性がありますが、エラーがランダムに分散されると、最も重大なケースを除きすべて軽減できます。

リクエストが繰り返し 5XX エラーで失敗する場合は、Google Cloud サポートにエスカレーションする必要があります。問題が適切に優先順位付けされるように、障害がビジネスに与える影響を明確に伝えてください。一方、リクエストが 4XX エラーで繰り返し失敗する場合は、アプリケーションを変更することで問題に対処できると考えられます。詳細は、エラー メッセージをご覧ください。

指数バックオフのロジックの例

指数バックオフのロジックでは、最大バックオフ時間に達するまで再試行の間の待ち時間を増加させることで、クエリまたはリクエストを再試行します。次に例を示します。

  1. BigQuery にリクエストを送信します。

  2. リクエストが失敗した場合、1 + random_number_milliseconds 秒待ってから、リクエストを再試行します。

  3. このリクエストが失敗した場合、2 + random_number_milliseconds 秒待ってから、リクエストを再試行します。

  4. このリクエストが失敗した場合、4 + random_number_milliseconds 秒待ってから、リクエストを再試行します。

  5. このようにして、最大 maximum_backoff 時間に達するまで繰り返します。

  6. 再試行の最大回数まで待機と再試行を続行しますが、再試行の間の待ち時間は増加させません。

次の点にご注意ください。

  • 待ち時間は min(((2^n)+random_number_milliseconds), maximum_backoff) で、n は繰り返される（リクエスト）のたびに 1 増加します。

  • 上記のフローで、random_number_milliseconds は、1,000 ミリ秒以下の乱数です。このランダム化によって、多数のクライアントが同期され、すべてが同時に再試行して、同期した波のようにリクエストを送信する状況を避けることができます。random_number_milliseconds の値は再試行リクエストの後に毎回再計算されます。

  • 通常、最大バックオフ間隔（maximum_backoff）は 32 秒または 64 秒です。maximum_backoff の適切な値はユースケースによって異なります。

クライアントは、最大バックオフ時間に達した後も再試行を続けることができます。この時点より後の再試行では、バックオフ時間を増加させ続ける必要はありません。たとえば、クライアントが最大バックオフ時間として 64 秒を使用する場合、この値に達した後は、クライアントは 64 秒ごとに再試行を繰り返すことができます。いずれかの時点で、クライアントが無限に再試行を行わないようにする必要があります。

適切な再試行間の待ち時間と再試行回数は、ユースケースとネットワークの状態により異なります。

失敗したジョブ挿入を再試行する

「1 回限りの挿入」セマンティクスがアプリケーションで重要な場合は、ジョブの挿入に関して追加の考慮事項があります。「1 回限り」のセマンティクスを実現する方法は、指定する WriteDisposition（書き込み処理）によって異なります。書き込み処理は、テーブル内に既存のデータが見つかった場合に行う処理（失敗、上書き、追加）を BigQuery に指示します。

WRITE_EMPTY または WRITE_TRUNCATE の処理では、失敗したジョブ挿入または実行を再試行するだけでこのセマンティクスが実現されます。これは、ジョブによって取り込まれるすべての行がテーブルにアトミックに書き込まれるためです。

WRITE_APPEND 処理では、クライアントはジョブ ID を指定して、同じデータが 2 回目の再試行で追加されないように保護する必要があります。前のジョブの ID を使用するジョブ作成リクエストが BigQuery で拒否されます。これにより、特定のジョブ ID に対して「1 回限り」のセマンティクスが実現されます。その後、以前のすべての試行が失敗したことを BigQuery で確認したら、新しい予測可能なジョブ ID で再試行することで、「1 回限り」を実現できます。

一時的な問題やネットワークの中断により、API クライアントまたは HTTP クライアントで、ジョブが挿入されたという確認を受信できないことがあります。挿入が再試行されると、そのリクエストは status=ALREADY_EXISTS で失敗します（code=409 と reason="duplicate"）。既存のジョブ ステータスは、jobs.get を呼び出すことによって取得できます。既存のジョブのステータスが retrieved になった後、呼び出し元は、新しいジョブ ID を使用して新しいジョブを作成するかどうかを判断できます。

ユースケースと信頼性に関する要件

BigQuery は、さまざまなアーキテクチャの重要な要素です。ユースケースとデプロイされるアーキテクチャに応じて、可用性、パフォーマンス、その他の信頼性に関するさまざまな要件を満たす必要があります。このガイドでは、2 つの主要なユースケースとアーキテクチャを選択して詳細を説明します。

リアルタイム分析

最初の例は、イベントデータ処理パイプラインです。この例では、Pub/Sub を使用してログイベントがエンドポイントから取り込まれます。その後、このログイベントに対してストリーミング Dataflow パイプラインでいくつかのオペレーションが実行され、Storage Write API を使用してデータが BigQuery に書き込まれます。このデータは、たとえば特定のエンドポイントの結果につながった可能性のあるイベントのシーケンスを再作成するためのアドホック クエリにも、可視化によるデータの傾向やパターンの検出を可能にするほぼリアルタイムのダッシュボードへのフィードにも使用されます。

この例では、信頼性のさまざまな側面を考慮することが求められます。エンドツーエンドのデータの更新頻度の要件は非常に高いため、取り込みプロセスのレイテンシは非常に重要です。データが BigQuery に書き込まれると、信頼性は、安定した予測可能なレイテンシでアドホック クエリを発行するユーザーの能力として認識され、ダッシュボードで使用するデータが確実に最新の利用可能なデータを反映するようにします。

バッチデータ処理

次の例は、金融サービス業界の法令遵守を軸とするバッチ処理アーキテクチャです。重要な要件は、日次レポートを夜間の決まった期限までに、規制当局へ提出することです。レポートを生成する夜間のバッチ処理が、この期限までに完了すれば、十分高速と考えられます。

データは、BigQuery で使用でき、他のデータソースと結合してダッシュボードに表示され、分析され、最終的には PDF レポートが生成される必要があります。こうしたレポートを時間どおりにエラーなく配信することは、ビジネス上の重要な要件です。したがって、求められる期限に間に合うように、データの取り込みと正しくレポートを生成することの両方で信頼性を確保することと、安定した時間枠で確実に行うことが重要です。

次のステップ