🙀

BigQueryの本番データがすべて消えた日 - 大規模障害から学んだ復旧と再発防止策

に公開

はじめに

こんにちは!AI技術開発室のYTです。
ケアネットでは、本番データウェアハウスとしてBigQueryを導入しています。ユーザー向けサービスと連動はしておらず、データ解析を目的とし、複数の部署が単一のGoogle Cloudプロジェクトを共有してデータを集約する運用をとっています。
今回は、冷や汗が止まらなかった、BigQueryの本番データセットをすべて削除してしまったインシデントについて、その原因と復旧の過程、そして得られた学びを共有したいと思います。同じような環境でデータ運用されている方の参考になれば幸いです。

障害発生から復旧までのタイムライン

忘れもしない2025年8月某日、その事件は起こりました。

  • 10:41
    • システム開発本部から「BigQueryで障害が発生している」との第一報がSlackに投稿されました。
  • 11:00
    • 私が所属するAI技術開発室のミーティングでこの障害が話題に上がりましたが、この時点ではまだ私たちのチームが原因であるとは思いもよらず、静観していました。
  • 11:47
    • システム開発本部の調査により、AI技術開発室のサービスアカウントから本番環境のデータセットが削除されたことが判明しました。この報告を受け、私たちは血の気が引くのを感じながら、直ちに原因調査と復旧方法の検討を開始しました。
  • 12:44
    • システム開発本部から、データセットの復旧を試みる UNDROP SCHEMA クエリが動作しないとの報告がありました。復旧への道が閉ざされたかのように思え、焦りが募ります。
  • 13:06
    • AI技術開発室側で、Cloud Shell上で bq cp コマンドを実行することで、テーブル単位であれば復元できる可能性があることに気づきました。すぐにこの情報をシステム開発本部に共有し、復旧作業に取り掛かりました。
  • 16:00
    • 関係者の協力のもと、ほとんどのテーブルが無事に復旧しました。その後、AI技術開発室内でポストモーテム(振り返り)を実施し、原因と具体的な再発防止策をまとめて他部署へ共有しました。

原因

直接的な原因は、改修中のテストコードにありました。テスト環境のデータを初期化するための処理が、設定の不備により本番環境に対して実行されてしまったのです。具体的には、データセットを一度削除し、再度同じ名称で作り直すという一連の処理が、意図せず本番環境のすべてのデータセットに対して実行されてしまいました。

復旧に向けて試したこと

パニックに近い状況の中、私たちはいくつかの復旧方法を試しました。

UNDROP SCHEMA クエリ

最初に試したのは、BigQueryが提供する UNDROP SCHEMA クエリでした。これは削除されたデータセットを復元するための機能です。

UNDROP SCHEMA `your-project.your_dataset`;

しかし、今回はこのクエリが機能しませんでした。
原因セクションで述べたように、問題の処理が「データセットを削除した直後に、同名で新しいデータセットを作成する」という動作だったため、BigQueryのシステム上、復元対象のデータセットが存在しないと判断されてしまったようです。

Cloud Shell上でbq cpコマンド

次に試したのが、bq cp コマンドによるテーブルのコピーです。テーブルの存在を把握していることが前提となりますが、BigQueryには「タイムトラベル」という機能があり、過去7日以内のデータであれば、特定の時点の状態を復元できます。Cloud Shell上でこちらのコマンドを実行したところ、 UNDROP SCHEMA クエリとは異なり、データセット削除後に同名で新しいデータセットを作成した後でも機能し、障害発生前の特定の時点を指定してテーブルを復元することができました。

# 4時間前時点を指定
TIMESTAMP=$(date -d '4 hour ago' +%s000)
# bq cp コマンドでテーブルを復元
bq cp your-project:your_dataset.your_table@1753820400000 your-project:your_dataset.your_table_restored

この方法で、1テーブルずつ地道に復旧作業を進め、大半のデータを失うことなく復旧させることができました。
ただし、この方法ではビューやテーブル関数を復元することはできず、BigQueryの保存済みクエリに保存していた作成時のクエリで再作成しました。

改善策と学び

このインシデントから、私たちは多くのことを学びました。現在、以下の改善策に取り組んでいます。

  • テストコードが、本番環境にアクセスできないようにする制御を徹底化する
  • サービスアカウントに付与されていた過剰な権限を整理する
  • bq cp コマンドでの復旧は、テーブル名を把握していることが大前提となるため、データセットやテーブルの情報をメタデータとして管理しておく
  • bq cp コマンドではビューやテーブル関数を復元できないため、これらの作成クエリもGitHubなどで管理しておく
  • BigQueryのバックアップのあり方を検討する

まとめ

今回は、私たちのチームが経験したBigQueryのデータセット全削除という大きな失敗談について共有しました。幸いにも、BigQueryのタイムトラベル機能と bq cp コマンドのおかげで、データの大部分を復旧させることができました。この記事が、皆さんのデータ基盤運用におけるリスク管理の一助となれば幸いです。

We are hiring!

AI技術開発室とシステム開発本部では、エンジニアリングに情熱を持ち、失敗から学び共に成長していける仲間を募集しています!詳しくは以下をご覧ください。
https://hrmos.co/pages/carenet5800/jobs/1826582723293220966
https://hrmos.co/pages/carenet5800/jobs/0000020
https://hrmos.co/pages/carenet5800/jobs/1826582723293220923
https://hrmos.co/pages/carenet5800/jobs/1826582723293220924
https://hrmos.co/pages/carenet5800/jobs/1826582723293220920

CareNet Engineers

Discussion