Cloud Storage の削除（復元可能）を大規模に管理

※この投稿は米国時間 2024 年 5 月 2 日に、Google Cloud blog に投稿されたものの抄訳です。

誤ってデータを削除してしまったことはありませんか？残念なことに、私たちの多くがこのような経験をしています。そのため、パソコン上のほとんどのオペレーティング システムには、ファイルを取り戻せるようにゴミ箱が用意されています。企業側では、このような偶発的な削除ははるかに規模が大きくなる可能性があり、場合によっては数百万、数十億のオブジェクトに関わることもあります。また、誰かがあなたのデータに不正にアクセスし、ランサムウェア攻撃をしかけてデータを人質に取ろうとする、あるいは単純にデータを削除するといった可能性もあります。

Google は最近、Cloud Storage の削除（復元可能）をリリースしました。これは、既存のすべての Cloud Storage 機能とワークロードに対して互換性のある重要な新しいデータ保護機能です。直近に削除されたデータを保持、復元する方法をエンタープライズ規模で提供することで、偶発的な削除や悪意のあるデータ削除からの保護を可能にします。削除（復元可能）を導入することで、万が一のミスが発生した場合に「元に戻す」メカニズムを提供してくれるため、組織が古いデータを「プルーニング」する際も、より迅速に作業を進められるようになります。

今回のブログでは、削除（復元可能）を使用してビジネスの重要性に基づいてデータを保護できるように、規模が大きくなっても削除（復元可能）の設定を最適化するために必要なツールと情報をご紹介します。

削除（復元可能）の仕組みと請求方法は？

削除（復元可能）が有効になっている場合、削除されたオブジェクトは完全に削除されているのではなく、そのバケットに設定されている削除（復元可能）の保持期間中、非表示の復元可能な削除状態で保持されます。削除された（復元可能な）オブジェクトを戻す必要がある場合は、復元を実行するだけでライブ状態にコピーされます。

今回導入された削除（復元可能）では、既存のすべてのバケットに対して 7 日間の保持期間が有効になります。また、新規作成されるバケットについてはデフォルトで 7 日間の保持期間が有効になります。残念なことに、偶発的な削除は非常によくあることで、Cloud Storage に保存されているデータは本質的にビジネス クリティカルなものばかりであるため、削除（復元可能）はデフォルトで有効になっています。デフォルトの 7 日間に加えて、7～90 の間で任意の日数を選択できるほか、機能を完全に無効にすることもできます。

削除（復元可能）の使用量は、最近削除されたオブジェクトのストレージ クラスに基づいて課金されます。多くの場合、この機能を使用しても請求額は数パーセントしか増加しないため、削除（復元可能）が提供する保護に見合う適切な金額であると感じていただけると思います。ただし、存続期間の短い（頻繁に削除される）大量のデータを含むバケットに対して削除（復元可能）を有効にすると、1 時間後に削除されたオブジェクトにはオブジェクトが存続していた 1 時間分と削除（復元可能）の 7 日分の使用料が請求されるため、請求額が大幅に増加する可能性があります。

データにはどれほどの価値があるのか？

削除（復元可能）によってデータ削除のリスクから護られている状態（経済的影響が最も少ない状態）にするために、次の 3 つの問いについて検討することをおすすめします。

1. 自社組織のデータはどのくらい重要なのか？失われた場合に簡単に再生成できる一時的なオブジェクトやメディアのコード変換を保存していますか？このような場合には、削除（復元可能）による保護は価値を発揮できそうにありません。それとも、紛失した場合に自身のビジネスや顧客との関係を危険にさらすようなデータを保存していますか？このような状況下では、削除（復元可能）により重要なレベルの保護を提供できます。

2. 現状どのレベルのデータ保護が行われているのか？Cloud Storage にビジネス クリティカルなデータの唯一のコピーがある場合、すべてのデータの長期バックアップを別の Google Cloud リージョン、オンプレミス、または別のクラウド プロバイダに保存するよりも、削除（復元可能）による保護がはるかに重要になります。

3. どの程度のデータ保護が可能か？削除（復元可能）は、従来のエンタープライズ バックアップを実行するよりもはるかに低コストで済みますが、主に削除率に応じて、請求に大きな影響を与える可能性があります。削除（復元可能）は、ワークロード全体が依存するビジネスデータを保護するものであるため、ストレージだけではなく、Google Cloud の料金全体に対するコストを考慮することをおすすめします。すべてのバケットで削除（復元可能）を有効にしていても、クラウド請求額に与える影響は 1 桁のパーセンテージにしかならないかもしれません。偶発的な削除と悪意のある削除の両方に対して保護できることを考えれば、その価値はあるかもしれません。

削除（復元可能）をどこでどの程度使用するかについて方針が定まったら、次のステップに移りますが、これはアーキテクチャの選択と組織におけるクラウドの総合的な複雑さによって異なります。このブログの後半部分では、削除（復元可能）の影響を評価し、その情報に基づいて行動する方法について説明します。まず、バケットレベルの指標から始めて、次にプロジェクト内のバケットレベルの設定に基づいて行動し、管理には Terraform を使用します。最後に締めくくりとして、組織レベルの管理アプローチを説明します。

バケットレベルの影響の評価

Cloud Monitoring 指標を使用してバケットレベルの削除（復元可能）コストを見積もり、Metrics Explorer を使用して可視化できます。さまざまな種類のデータセットを代表するいくつかのバケットを検査して、削除（復元可能）で保護することでコストが高くなるバケットと、低くなるバケットを把握しておくことをおすすめします。

ストレージ指標

先日、ストレージ クラスごとにオブジェクト数、バイト数、バイト秒を分類し、さらにライブ、非現行、削除（復元可能）、マルチパートごとに分類できる新しいストレージ指標を導入しました。これらの内訳は、削除（復元可能）分析を実行する以外でも非常に有用です。さらに、新しい delete_bytes 指標を使用して削除率を検査できるようになりました。

storage/v2/deleted_bytes 指標は、ストレージ クラスごとにグループ化されたバケットあたりの削除バイト数のデルタカウントです。これは、削除（復元可能）が無効になっている場合や、検討されているものとは異なる保持期間が設定されている場合でも、削除（復元可能）による請求への影響を見積もるために使用できます。

たとえば、削除（復元可能）の絶対コストは、削除（復元可能）の保持期間 × 削除されたバイト数 × ストレージ料金、として計算できます。例: 1 か月間に 100,000 GB の削除を行う 7 日間の削除（復元可能）ポリシーを有効にする場合のコスト（us-central1 および Standard Storage を想定）は、（7 / 30.4375 日）× 100,000 GB × 0.02 ドル/GB-月 = 459.96 ドル（30.4375 は 1 か月の平均日数）。

削除（復元可能）の相対コストは、storage/v2/deleted_bytes 指標と既存の storage/v2/total_byte_seconds 指標を比較することによって計算することもできます（削除（復元可能）の保持期間 × 削除されたバイト数 / 合計バイト数）。上の例から引き続き、月のストレージが 1,000,000 GB-月とした場合、削除（復元可能）を有効にする相対コストは、（7 / 30.4375 日）× 100,000 GB / 1,000,000 GB = 2.3% の影響となります。

Metrics Explorer

Metrics Explorer を使用することで、特定のバケットの削除（復元可能）推定コストを可視化するチャートを作成できます。

1. Google Cloud コンソールのナビゲーション パネルで、[Monitoring] を選択し、次に [Metrics Explorer] を選択します（Metrics Explorer に移動します）。

2. [言語] トグルで [MQL] が選択されていることを確認します。

3. 次のクエリをクエリエディタに入力します。

注: このクエリは、7 日間（604,800 秒）の削除（復元可能）期間を想定しています。

プロジェクト内でのアクション

ご自身がプロジェクト内で削除（復元可能）の設定を決定するストレージ管理者である場合は、バケットのリストを手動で確認し、保護する必要のあるものと削除（復元可能）なしで実行できるものについて、ビジネス知識に基づいて決定してもいいでしょう。バケットの数が多い場合は、上述の指標を使用して、すべてのバケットで請求影響しきい値（例: 20% の影響）を超えるバケットのリストを作成し、それらのバケットで削除（復元可能）を無効にすることもできます。

この作業を支援するために、削除（復元可能）の請求影響 Python スクリプトを GitHub で公開しています。このスクリプトは、バケット内のオブジェクトのストレージ クラスを考慮して、指定した請求影響の割合を超えるプロジェクト内のバケットのリストを生成します。このスクリプトを使用して、指定された相対コストしきい値に基づいて削除（復元可能）ポリシーを更新することも可能です。

Google Cloud CLI を使用して、プロジェクト内の 1 つ以上のバケットに対して削除（復元可能）設定を構成することをおすすめします。インストールしてログインした後、指定したプロジェクト内で削除（復元可能）ポリシーを有効にする、更新する、または無効にするために実行できるアクションの例として、次の gcloud storage コマンドをご紹介します。

Terraform を使用したアクション

Terraform のようなオーケストレーション レイヤを使用している場合、削除（復元可能）への適応は、テンプレートを更新し、ワークロードごとに削除（復元可能）の保持期間を決定するだけで簡単に行えます。また、有効期間の短いデータ専用の新しいテンプレートを作成して、それらのテンプレートから作成されたバケットに対して削除（復元可能）を無効にできる場合もあります。設定を定義すれば、Terraform によりテンプレートに適合するように既存のバケットを更新でき、新しいバケットも目的の設定で作成されます。

Terraform を使用する場合、まずは削除（復元可能）ポリシーを含めるようにテンプレートを更新する必要があります。ここで、google_storage_bucket リソースで削除（復元可能）の保持期間を 7 日（604,800 秒）に設定する例を以下に示します。

代わりに削除（復元可能）を無効にするには、retention_duration_seconds = 0 に設定します。

詳細については、Terraform でストレージ バケットを作成してオブジェクトをアップロードするもご確認ください。

大規模な組織全体でのアクション

何千ものプロジェクトと何百万ものバケットを抱える大企業で働いており、オーケストレーション レイヤをほとんど使用していないとしたら、手作業でのアプローチは現実的ではありません。規模に応じた意思決定を行う必要があります。このような場合は、最初にバケットレベルの指標について学び、前述のプロジェクト内でアクションを実行する方法について学ぶことをおすすめします。このセクションでは、これらのテクニックを組織レベルまで拡張します。ここでも、このセクションで必要となる gcloud CLI の最新バージョンがすでにインストールされていることを前提としてご説明していきます。

最も複雑な組織であっても、全体にわたってポリシーを実装するには、gcloud コマンドライン環境を使用して次の 3 つのステップでアプローチする必要があります。

1. 権限の取得: 組織全体でバケットレベルの設定を一覧表示し、変更できることを確認します

2. 評価: 削除（復元可能）を無効にする影響しきい値を決定し、そのしきい値を超えたバケットのリストを取得します

3. 実行: バケットのリストで削除（復元可能）を無効にします

権限の取得

何かを実行する前に、組織全体のバケットレベルの構成を分析、変更するための十分なアクセス権限を持つユーザーを特定する必要があります。このユーザーは、既存の組織管理者の場合があります。あるいは、組織管理者がカスタムロールを作成し、削除（復元可能）設定の管理という特定の目的のために、それをあなたや別の管理者に割り当てる場合もあります。

すべてが完了し、このプロセスが終了してすべてのバケットが更新され、これらの設定に引き続きアクセスできるロールが必要なくなった場合には、組織管理者はこのカスタムロールを安全に削除できます。

評価

組織全体のバケットレベルの構成に対処できるようになったら、上記のプロジェクト レベルの分析を適用して、選択した影響しきい値を超える組織全体のすべてのバケットのリストを取得できます。あるいは、組織内のすべてのバケットに 0d や 14d といった一律の設定を適用することもできます。

実行

すべてのプロジェクトにわたって、すべてのバケットの削除（復元可能）ポリシーを更新するには、すべてのプロジェクトを反復処理して各プロジェクトのバケットに適切な変更を加えます。たとえば、次のコマンドは組織全体のすべてのバケットの削除（復元可能）を無効にします。

また、projects list の filter オプションを使用して、プロジェクトのサブセットのみをターゲットにすることもできます。たとえば、特定のラベル（--filter="labels.environment:prod"）や特定の親（--filter="parent.id:123456789"）を持つプロジェクトだけを更新できます。

ベスト プラクティスとして、上記のプロジェクトごとのアクションを、特定のバケット ID の削除（復元可能）を選択的に無効にするコマンドに置き換えるよう検討することをおすすめします。たとえば、プロジェクト リストをループして、プロジェクトごとに削除（復元可能）の請求影響 Python スクリプトを実行し、選択した影響 % しきい値に従ってバケット設定を更新して、よりカスタマイズされた結果を取得できます。

まとめ

このブログのベスト プラクティスに沿って利用可能なツールと設定を活用することで、請求への影響を最小限に抑えながら、削除（復元可能）によってビジネス クリティカルなデータを保護できると確信していただけることを願っています。

-グループ プロダクト マネージャー、Geoffrey Noer

-ソフトウェア エンジニア、Michael Roth