はじめのProfessional Cloud Data Engineer認定取得講座㉕BigQueryのデータバックアップ、Cloud Storageのターボレプリケーションとクロスバケットレプリケーション、Bigtable のガベージコレクションについて説明します！

クラウド

今回も、Professional Cloud Data Engineer認定取得するために、私が勉強した内容をアウトプットしていきます。

今回は、BigQueryのデータバックアップ、Cloud Storageのターボレプリケーションとクロスバケットレプリケーション、Bigtable のガベージコレクションについて説明します！

ぜひ、最後までご覧いただけると嬉しいです！

BigQueryのデータバックアップ

BigQueryのデータをバックアップする際のベストプラクティスは、単一の方法に頼らず、目的（リカバリ時間やコスト）に応じて複数の機能を組み合わせることです。

1. テーブルスナップショット（最も手軽な方法）

テーブルスナップショットは、特定の時点のテーブルデータを読み取り専用として保存できる機能です。
テーブルスナップショットは差分ストレージを利用しており、非常に低コストかつ高速に作成できます。

  • ベストプラクティス
    • 日次・週次などの定期スナップショットをスケジュール実行します。
    • 大規模な更新やスキーマ変更の直前に手動で取得し、問題発生時のリカバリポイントとして利用します。
  • メリット
    • 高速：数秒で作成可能。
    • 低コスト：元データとの差分のみ課金されます。
    • 即時リストア可能：既存テーブルへ簡単に復元できます。
  • デメリット
    • 同一リージョン内にしか作成できないため、リージョン障害対策（DR）には不向き。

＜補足＞

BigQueryには「タイムトラベル」機能もあり、短期間の誤更新ならスナップショットを取らずとも復旧可能です。BigQueryのタイムトラベル機能は、最大7日前までの過去のテーブル状態に遡ってデータを参照・復元できる機能です。データ誤削除や更新ミス時の復旧に役立ちます。

2. Cloud Storageへのエクスポート（災害対策）

テーブルやパーティションをCloud Storageにエクスポートすることで、BigQuery外にデータを保存できます。
これは、リージョン障害や削除事故に備える災害対策（DR）・長期保管の基本手段です。

  • ベストプラクティス
    • Multi-Region または Dual-Region バケットをエクスポート先に指定し、地理的冗長性を確保します。
    • Avro や Parquet 形式でエクスポートし、スキーマ情報を保持します。
    • Cloud Composer や Cloud Scheduler + BigQuery Data Transfer Serviceなどで定期エクスポートを自動化します。
  • メリット
    • 災害対策：BigQueryのリージョンが停止しても、別リージョンからデータを復旧可能。
    • 長期アーカイブ：Archive Storageなどの低コストストレージに移行できます。
    • 互換性：他の分析基盤（例：Dataproc, Spark, Pandasなど）でも再利用できます。
  • デメリット
    • 復元に時間がかかる：再ロードが必要。
    • コスト：エクスポート処理・ストレージの両方で課金されます。

3. データセットのクロスリージョンコピー（高可用性）

データセット全体を別リージョンへコピーすることで、災害時に迅速な復旧が可能になります。
BigQueryのData Transfer Serviceを使うと、スケジュール設定による自動コピーも可能です。

  • ベストプラクティス
    • 本番環境（例：us-central1）のデータセットを、DR用の別リージョン（例：us-east1）に定期的に複製します。
    • 海外拠点向けの分析やクエリ負荷分散にも活用できます。
  • メリット
    • 高速リカバリ：障害発生時、アプリケーション接続先をDR側に切り替えるだけで復旧。
    • 整合性：テーブル・ビュー・ルーチンが含まれます。
  • デメリット
    • コスト：コピー先でもストレージ料金がフルに発生。
    • 転送コスト：リージョン間コピーにはネットワーク転送料金がかかる場合があります。

BigQueryのデータバックアップのまとめ

目的推奨されるベストプラクティス
手軽な日次バックアップと即時復元テーブルスナップショット
長期アーカイブとリージョン障害対策Cloud Storageへのエクスポート
迅速なサービス復旧（DR）データセットのクロスリージョンコピー

Cloud Storageのターボレプリケーションとクロスバケットレプリケーション

Google Cloud Storageでは、データの冗長性と可用性を高めるために、「ターボレプリケーション（Turbo Replication）」と「クロスバケットレプリケーション（Cross-Bucket Replication）」という2つの主要なレプリケーション機能を提供しています。
どちらもデータ保護を目的としていますが、用途と仕組みが異なります。

ターボレプリケーション：最速のデータ保護

ターボレプリケーション（Turbo Replication）は、Dual-Regionバケット内でのデータ複製を15分以内に保証する高可用性機能です。
つまり、1つのリージョンに障害が発生しても、もう一方のリージョンに最新のデータが確実に存在します。

  • 特徴
    • RPO（目標復旧時点）：最大15分以内（SLAで保証）。
    • 利用対象：Dual-Regionバケット（例：asia1、nam4など）のみ。
    • 自動レプリケーション：データ書き込み後、Googleの内部ネットワーク経由で自動的に2リージョンに複製。
  • メリット
    • 高速なRPO保証により、ビジネスクリティカルなシステムに最適。
    • アプリケーション側の設定変更なしで利用可能。
    • Google CloudコンソールやAPIからRPO達成状況を可視化できます。
  • デメリット
    • 追加料金が発生（通常のDual-Regionよりも高コスト）。
    • 特定のリージョンペアのみ対応（例: 東京・大阪など一部ペアに限定）。

＜補足①＞
ターボレプリケーションは「Dual-Region構成」専用機能です。
Single-RegionやMulti-Regionバケットでは利用できません。

＜補足②＞
ターボレプリケーションは、デュアルリージョン バケット専用のオプション機能です。
通常のデュアルリージョンでは、2つ目のリージョンへのデータ複製に「非同期（少し遅延）」がありますが、ターボレプリケーションを有効にすると、99.95%のオブジェクトが15分以内に完全に複製されることを SLA で保証します。

クロスバケットレプリケーション：柔軟なデータコピー

クロスバケットレプリケーションは、任意の2つのバケット間で非同期にオブジェクトをコピーする機能です。
異なるプロジェクト・リージョン・組織間でもレプリケーション可能で、より柔軟な運用に対応します。

  • 主な用途
    • データ主権対応：国ごとにデータを保持し、各国の法規制に準拠。
    • 環境の分離：本番・開発・検証環境など、異なる環境で同一データを保持。
    • データ共有：パートナー企業や別組織とデータを安全に共有。
    • 分析用データ集約：各拠点から1つの分析用バケットにデータを集約。
  • 特徴
    • 非同期レプリケーション：コピー完了までの時間は保証されない（RPO保証なし）。
    • 削除操作は同期されない：ソースで削除しても、宛先のバケットでは保持されます。
    • フィルタリング：オブジェクト条件（プレフィックスやメタデータ）でレプリケーション対象を制御可能。
    • 管理の柔軟性：異なるプロジェクト・組織・IAMポリシー間でも設定可能。
  • デメリット
    • RPO保証がないため、リアルタイム性は低い。
    • レプリケーション先バケットのストレージ料金も別途発生。

＜補足＞
クロスバケットレプリケーションは「Dual-Region」や「Multi-Region」構成とは無関係に、任意のバケット間で設定可能です。
例：東京リージョン → ロンドンリージョン。

パフォーマンスと可用性の監視

Google CloudコンソールまたはCloud Monitoringを利用して、レプリケーションの進行状況やSLA達成率を確認できます。

項目ターボレプリケーション通常レプリケーションクロスバケットレプリケーション
RPO保証15分（SLAで保証）約12時間（保証なし）なし（非同期）
対象バケットDual-RegionのみDual-Region任意のリージョン間
削除の同期自動同期自動同期同期されない
監視機能RPO超過時間や割合を30日間グラフ化Cloud Monitoringで確認可能Cloud Audit Logsで監査可能

Cloud Storageのターボレプリケーションとクロスバケットレプリケーションのまとめ

目的推奨される機能
高可用性・ミッションクリティカルなデータ保護ターボレプリケーション
地理的なデータ分散・法規制対応・共有クロスバケットレプリケーション
シンプルな自動バックアップクロスバケットレプリケーション＋ライフサイクルルール

Bigtable のガベージコレクション

Bigtable におけるガベージコレクション（GC）は、テーブル中の期限切れ／不要となったデータ（古いバージョン・不要なセルなど）を自動的に削除する背景処理です。

主なポイント

  • ガベージコレクション ポリシーは列ファミリレベルで設定されます。各列ファミリごとに「いつ／どのバージョンを残すか」のルールを定義します。
  • ガベージコレクションは自動・非同期にバックグラウンドで実行されます（データの削除はコンパクション時に行われることが多いです）ため、ポリシーを設定しても即座にデータが消えるわけではありません。
    コンパクションとは、テーブル内の古いデータや削除マーク（削除フラグ）が付いたデータを物理的に整理・再構成し、ストレージの効率化や読み取り性能の向上を図る処理のことです。この処理によって不要なデータが完全に削除されます。
    そのため、通常は削除可能と判定されてから実際に削除が反映されるまで、数日～最大でおおよそ1週間程度かかることがあります。
  • ガベージコレクション を適切に設定することにより、以下のようなメリットがあります。
    • 行サイズ（row size）が肥大化するのを防ぎ、読み書き性能の低下を抑制できます。
    • 不要データをストレージに保持し続けることによるコスト増を抑えられます。
  • 注意点として、ガベージコレクションポリシーに合致して「削除対象」とマークされたデータでも、実際にはコンパクションが走るまで読み取り可能な状態にあります。つまり、読み出し時にはフィルタリングを設ける必要があるケースがあります。
  • また、すべてのセルが削除されて「空行」となった場合、その行が将来的に物理的に削除（“tombstoned” されること）される可能性があります。

2. ガベージコレクション の仕組みと種類

ガベージコレクション がどのような条件でデータを対象とするか、主なルールを整理します。

2.1 ルールの種類

Bigtable では主に以下のような ガベージコレクション ルールが用意されています。

  • 存続期間（TTL 相当）
    あるセルのタイムスタンプが「現在時刻から一定以上前」であれば削除対象とします。
  • バージョン数ベース
    ある列ファミリで保持するバージョン数の上限を定め、それを超えた古いバージョンを削除対象とします。
  • 複合ルール
    存続期間＋バージョン数など、複数ルールを組み合わせて削除条件を定めることが可能です。例えば「30 日以上経過 AND 最新１バージョン以外削除」あるいは「(30日以上経過) OR (バージョン数が10を超えた)」といった設定が可能です。

2.2 タイムスタンプと人工タイムスタンプの扱い

  • 各セルにはタイムスタンプ（通常はミリ秒またはマイクロ秒単位）があります。通常はセルが書き込まれた「実際の時刻」が使われますが、用途に応じて 「人工的な」タイムスタンプを付与することも可能です。
  • 人工タイムスタンプを使うことで、たとえば 「逐次番号」をタイムスタンプ欄に用いて特別な ガベージコレクション 挙動を実現可能です（後述）。ただし、人工タイムスタンプを使うと、タイムスタンプが実際の書き込み時間を示さなくなるため “いつ書いたか” の判定に使えなくなるなどの注意があります。

2.3 いつ削除されるか

  • ガベージコレクション の対象となったセルは、次回の コンパクション処理の際に削除されます。あくまでバックグラウンド処理であり、即時性はありません。通常、「削除対象になってから最大で おおよそ1週間程度かかる可能性があります」。
  • データを確実に読み出し時に除外したい場合は、読み出し側でフィルタを設けて「有効なセルだけ」を返すよう設計することを推奨します。

3. ガベージコレクション の構成（設定方法）

ガベージコレクション ポリシーをどのように構成するか、実際のポイントを紹介します。

3.1 列ファミリレベルで設定

  • ガベージコレクション ポリシーはテーブル内の各 列ファミリ に対して設定します。他の列ファミリとは独立して設定可能なので、列ごとに「保存バージョン数」や「有効期間」が異なる設計が可能です。
  • 例：ユーザープロフィール情報を格納する列ファミリでは「最新1バージョンだけ保持」、ログを格納する列ファミリでは「30日以上経過したバージョンを削除」といった設計。

3.2 設定方法概要

主な設定例は以下の通りです。

  • バージョン数限定：例 max_versions = 1
  • 存続機関：例 max_age = 30d（30日）
  • 上記の組み合わせ： max_age = 30d AND max_versions = 5（30日経過 且つ バージョン数が5を超える場合に削除）
  • 複雑なネストルールも可能（たとえば “(age > 30d AND versions > 5) OR age > 365d” といった構成）

3.3 変更時の留意点（レプリケーション環境など）

  • レプリケーション構成されたインスタンスを持つ場合、ガベージコレクション による削除情報も複製されるため、バージョン数ルールを急激に変えると CPU 負荷や同期遅延が発生する可能性があります。
  • ポリシーを緩和（例：30日→50日）する場合、複数クラスタ間で同期が遅れることがあります。
  • ポリシーを厳しくする（例：保存バージョンを5から3へ減らす／TTLを短くする）場合も、既存データの整理（バックグラウンド削除）に時間がかかることがあります。

3.4 実装例（概要）

たとえば Go／Java／cbt CLI 等で以下のように設定できます。

SetGCPolicy(table = "my-table",
            family = "my-family",
            policy = GCPolicy(age: "30d", max_versions: 5))

4. 補足：特殊なユースケース

ガベージコレクション の標準ルールではカバーしきれない「セルごとの異なる TTL」や「タイムスタンプが連番」といった高度設計についても、Bigtable では工夫が可能です。

4.1 セルレベル TTL のシミュレーション

Bigtable では「セルごとに異なる TTL を設定する」という機能は直接用意されていません（ポリシーは列ファミリ単位）ですが、工夫して セルレベルの TTL をシミュレーションする方法があります。

＜主な実装パターン＞

  • 1秒有効（One-second expiration）方式
    列ファミリを 「有効期間＝1秒」 の設定にして、書き込み時にセルのタイムスタンプを「有効期限となる時刻」に設定する。例えば、書き込み時刻 9:00:00 に “9:00:00” をタイムスタンプとして付与すれば、9:00:01 以降には削除対象になります。
    • メリット：セルごとにカスタム TTL を付与可能
    • デメリット：
      • 書き込みアプリケーションがタイムスタンプ付与を厳密に守る必要あり
      • タイムスタンプが実際の 「書き込み時刻」を示さなくなるため、別途「書き込み時刻」カラムが必要になる可能性あり
      • 既存データに実時刻タイムスタンプがある場合、混在すると想定外に早く削除される可能性あり
      • ガベージコレクション は非同期なので、読み取り時にフィルタ設計が必要。
  • デフォルト有効期間＋人工タイムスタンプ方式
    列ファミリにデフォルト TTL（例：2日）を設定し、もっと短くしたいセルには「書き込み時刻よりも古いタイムスタンプを付与」、もっと長く残したいセルには「将来時刻のタイムスタンプを付与」するというもの。こうすれば 「デフォルト＋セル個別調整」が可能。

4.2 タイムスタンプが連番（シーケンス番号）を使った ガベージコレクション

タイムスタンプ欄を実際の時刻ではなく、例えば「シーケンス番号」「書き込み回数」などの増分数値として使うアプローチがあります。これにより 「古い順に削除」 といったロジックを簡易に実現できます。

  • 例えば、セルのタイムスタンプを 1, 2, 3… のようにシーケンス値として付与し、「保持する最大シーケンス番号以下は削除」などと設定できます。
  • ただし、タイムスタンプが実時刻ではないため、時系列分析や「いつ書かれたか」の用途には注意が必要です。

5. 運用上の注意点とベストプラクティス

ガベージコレクション を正しく運用するためのチェックポイントを整理します。

  • 読み取り時のフィルタ設計
    ガベージコレクション 対象となったセルが「削除済み」と即座に消えるわけではありません。削除対象判定から実際の削除まで時間がかかるため、読み取り時に「有効セルのみ」を返すフィルタを設けることが推奨されます。
  • 行サイズの管理
    行が肥大化（例：バージョンが伸び続ける／古いセルが残り続ける）すると読み書き性能低下につながります。例えば、100 MB を超える行は望ましくないというガイドも示されています。
  • ストレージコストへの影響
    「削除対象＝未使用」とは異なり、ガベージコレクション対象セルは実際に削除されるまでストレージ課金が発生します。ポリシーを適切に設定することがコスト抑制の観点でも重要です。
  • レプリケーション構成での注意
    複数クラスタでレプリケートしているインスタンスでは、バージョン数制限の変更などで CPU 負荷が上がる・同期遅れが生じる可能性があります。運用時にはその影響を想定すべきです。
  • ポリシー変更の影響
    ガベージコレクション ポリシーを変更した際、例えば「保存バージョンを5から3へ減らす」といった制限を厳しくした場合、変更前のデータに対しても徐々に適用されますが、削除が完了するまで時間がかかります。
  • 既存データとの整合性
    セルレベル TTL シミュレーションや人工タイムスタンプを用いる場合、既に「通常の時刻タイムスタンプ」で書き込まれたデータが混在していると、予期せぬ削除が起きる可能性があります。移行時や設計時には十分検討してください。

Bigtableのガベージコレクションのまとめ

Bigtable におけるガベージコレクションは、列ファミリ単位で「古い／不要なデータ」を定期的に削除する仕組みです。適切に設計・設定すれば、行サイズの肥大化防止・ストレージコスト削減・読み書き性能維持に大きく貢献します。一方で、削除が即座ではなく非同期であるため、運用設計（例えば読み取りフィルタ・ポリシー変更時の影響・レプリケーション環境での同期遅れなど）を十分考慮する必要があります。

まとめ

今回は、下記３点について説明しました。

  1. BigQueryのデータバックアップ
  2. Cloud Storageのターボレプリケーションとクロスバケットレプリケーション
  3. Bigtableのガベージコレクション

本記事では、Google Cloudの主要なデータサービスである BigQuery・Cloud Storage・Bigtable におけるデータ保護と効率的な運用手法を解説しました。BigQueryでは、テーブルスナップショットやCloud Storageへのエクスポートによる柔軟なバックアップ戦略が重要です。Cloud Storageでは、ターボレプリケーションやクロスバケットレプリケーションによって高可用性と法規制対応を実現します。Bigtableでは、ガベージコレクションの最適化によりストレージコストの抑制と性能維持が可能です。これらを総合的に活用することで、耐障害性・コスト効率・運用の信頼性を高めた堅牢なデータ基盤を構築できます。

これからも、Macのシステムエンジニアとして、日々、習得した知識や経験を発信していきますので、是非、ブックマーク登録してくれると嬉しいです！

それでは、次回のブログで！

スポンサーリンク
タイトルとURLをコピーしました