データの可用性と耐久性

このページでは、Cloud Storage がデータを冗長的に保存する方法、デュアルリージョンとマルチリージョンのデフォルトのレプリケーション動作、デュアルリージョンのターボ レプリケーション機能など、Cloud Storage のデータの可用性と耐久性に関連するコンセプトについて説明します。

主なコンセプト

  • Cloud Storage は、99.999999999%（イレブンナイン）の年間耐久性を実現するように設計されています。

    • これを実現するため、Cloud Storage では消失訂正符号を使用して、複数のアベイラビリティ ゾーンに配置された複数のデバイスに重複してデータを保存します。

    • Cloud Storage では、オブジェクトを 2 つ以上の異なるアベイラビリティ ゾーンに書き込み、冗長的に格納されると、書き込み成功とみなされます。

    • すべての保存データの整合性を予防的に検証し、転送中のデータ破損を検出するため、チェックサムが保存され、定期的に再検証されます。必要であれば、冗長データを使用した訂正が自動的に行われます。

  • Cloud Storage に保存されたデータの月間可用性は、データのストレージ クラスとバケットのロケーション タイプによって異なります。詳しくは、使用可能なストレージ クラスをご覧ください。

  • デュアルリージョン バケットまたはマルチリージョン バケットに保存されるオブジェクトは、少なくとも 2 つの地理的な場所に冗長的に保存されます。

    • デュアルリージョンの場合は、オブジェクトを保存する特定のリージョンを選択します。

    • マルチリージョンの場合、データの保存に使用される特定のデータセンターは必要に応じて Cloud Storage によって決定されますが、これらのデータセンターはマルチリージョンの地理的境界内にあり、100 マイル以上離れています。このため、デュアルリージョンよりもストレージ コストを抑えながら、リージョン間での冗長性を確保できます。

    • 自然災害などにより、リージョン全体が機能停止することはまれですが、そのような場合でも、ストレージパスを変更することなく、デュアルリージョンとマルチリージョンのバケットを引き続き使用できます。

  • 通常、デュアルリージョン バケットとマルチリージョン バケットに保存されるオブジェクトは、デフォルトのレプリケーションにより、地理的な場所にまたがって複製されます。

    • オブジェクトが正常にアップロードされ、2 番目のロケーションに複製される前にオブジェクトの格納先のいずれかが利用不能になると、Cloud Storage の強整合性により、オブジェクトの古いバージョンは提供されなくなります。これにより、リージョンが再び使用可能になったときに、後続の上書きが元に戻されないようにしています。

    • デュアルリージョンに保存されているオブジェクトの場合、ターボ レプリケーションを使用して、リージョン間でより高速で予測可能なレプリケーションを実現できます。

  • デュアルリージョンとして使用できないリージョンペア間で冗長性を実現するには、リージョンごとに個別のバケットを作成し、Storage Transfer Service のイベント ドリブン転送を使用してバケットの同期を維持できます。

複数のリージョンにわたる冗長性

従来のストレージ モデルは多くの場合、「プライマリ」と「セカンダリ」の地理的なロケーションを持つアクティブ / パッシブのアプローチに依存していますが、Cloud Storage は、リージョン間の冗長性を備えた単一のバケットに基づいてアクティブ / アクティブのアーキテクチャを提供します。これにより、ユーザーがバケット間でデータをレプリケートする必要も、プライマリ リージョンでダウンタイムが発生した場合にセカンダリ バケットに手動でフェイルオーバーする必要もないため、障害復旧プロセスが簡素化されます。

Cloud Storage はバケットの現在の状態を常に把握し、必要に応じて使用可能なリージョンのオブジェクトを透過的に提供します。その結果、デュアルリージョンとマルチリージョンのバケットは、目標復旧時間（RTO）がゼロになるように設計され、通常、リージョンの一時的な障害はユーザーに表示されません。リージョンで障害が発生した場合でも、デュアルリージョンとマルチリージョンのバケットは、リージョン間で複製されたすべてのデータを自動的に提供し続けます。

ただし、リージョン間の冗長化は非同期で行われるため、リージョンが使用不能になる前にリージョン間のレプリケーションを完了していないデータは、停止したリージョンがオンラインに戻るまでアクセスできません。ごくまれなことですが、リージョンが物理的に破壊された場合はデータが失われる可能性があります。

Cloud Storage のデフォルトのレプリケーションでは、新しく書き込まれたオブジェクトの 99.9% に対しては 1 時間以内を目標にリージョン間の冗長性を確保し、残りのオブジェクトに対しては 12 時間以内を目標に確保するよう設計されています。新しく書き込まれたオブジェクトには、アップロード、書き換え、コピー、作成が含まれます。

ターボ レプリケーション

ターボ レプリケーションではデュアルリージョン バケット内のデータがリージョン間でより高速に冗長化されるため、データ損失のリスクが軽減され、リージョンで障害が発生した後も中断なくサービスを提供できます。

  • 有効になると、オブジェクトのサイズに関係なく、ターボ レプリケーションは新しく書き込まれたオブジェクトの 100% を、デュアルリージョンを構成する両方のリージョンに目標復旧時点の 15 分以内で複製するように設計されています。

なお、デフォルトのレプリケーションでも、ほとんどのオブジェクトは数分でレプリケーションが終了します。

リージョン間の冗長性とターボ レプリケーションは、ビジネスの継続性と障害復旧（BCDR）の取り組みをサポートしますが、管理者はワークロードに適した完全な BCDR アーキテクチャを計画して実装する必要があります。

詳細については、Google Cloud でアプリケーションの障害復旧を設計するための設定ガイドをご覧ください。

制限事項

  • ターボ レプリケーションは、デュアルリージョンのバケットでのみ使用できます。

  • ターボ レプリケーションは XML API では管理できません（ターボ レプリケーションを有効にして新しいバケットを作成するなど）。

  • バケットでターボ レプリケーションが有効になっている場合、新しく書き込まれたオブジェクトへの適用が開始するまでに最大で 10 秒かかります。

  • バケットでターボ レプリケーションを有効にする前に開始されたオブジェクトの書き込みは、デフォルトのレプリケーション率で地域間でレプリケートされます。

    • 直近 12 時間以内にデフォルトのレプリケーションで書き込まれたソース オブジェクトを使用してオブジェクトの作成を実行すると、デフォルトのレプリケーションも使用する複合オブジェクトが作成されます。

パフォーマンス モニタリング

Cloud Storage は、複製されていない最も古いオブジェクトをモニタリングします。オブジェクトが RPO（目標復旧時点）時間よりも長く複製されていないと、RPO がない状態とみなされます。オブジェクトに RPO がない時間は「不良」時間として計算されます。

たとえば、あるオブジェクトに午前 9 時から 9 時 20 分まで 20 分間の不良時間があり、別のオブジェクトに午前 9 時 15 分から 9 時 25 分まで 10 分間の不良時間がある場合、その月は RPO を過ぎているオブジェクトが 2 つ存在することになります。午前 9 時から午前 9 時 25 分まで、RPO を過ぎたオブジェクトが少なくとも 1 つ存在していたため、その月の不良時間の合計は 25 分になります。

  • ターボ レプリケーションを使用するバケットの場合、オブジェクトの RPO は 15 分です。

Google Cloud コンソールの [RPO（目標復旧時点）のない時間（分）] グラフでは、過去 30 日間のバケットの不良時間をモニタリングできます。このサービスレベル指標を使用して、バケットの月間レプリケーション時間の適合性をモニタリングできます。同様に、ターボによるオブジェクト レプリケーション グラフでは、RPO 内に発生したオブジェクトのレプリケーションが追跡されます。このサービスレベル指標を使用して、バケットの月間レプリケーション量の適合性をモニタリングできます。詳細については、Cloud Storage のモニタリングと Cloud Storage SLA をご覧ください。

次のステップ