バケットを正常に再配置するには、バケットの再配置を開始する前に、目標を定義し、バケットの使用状況を把握します。以降のセクションでは、主な計画手順について説明します。
バケットの特性を確認する
バケットの再配置時間を推定するには、次の要素を考慮してバケットの特性と使用状況を分析します。
非アクティブなバイト数: バケットに保存されているデータの合計量は、ストレージ費用と転送時間に影響します。
レプリケーション: バケットを同期または非同期で他のリージョンに複製すると、データの可用性、耐久性、費用に影響します。詳細については、データの可用性と耐久性をご覧ください。
データ転送: 再配置中にバケットから転送されるデータの量は、データ転送費用の計算に影響します。バケットのデータ転送費用を計算するには、Cloud Storage の料金をご覧ください。
使用パターン: 使用パターンからバケットのアクティビティ レベル（バケットの使用状況）を把握すると、再配置中に予期しない競合を防ぐことができます。バケットの使用パターンを把握するには、ログを分析します。詳細については、使用状況ログとストレージ ログをご覧ください。
バケット書き込みオペレーション: 再配置プロセス中にバケット書き込みオペレーションが頻繁に行われると、費用と所要時間が増加します。バケットにオブジェクトが書き込まれる頻度を確認するには、Cloud Storage のモニタリングの概要をご覧ください。
移転の目標を定める
バケットの特性に関する分析に基づいて、バケットを移動する理由を特定します。バケットの再配置の一般的な目的は次のとおりです。
費用管理: 費用の低いリージョンに移行することでストレージ費用を削減したり、データアクセス ロケーションの近くにデータを移動することでデータ転送費用を最小限に抑えたりできます。Cloud Storage とデータ転送の費用を計算し、別のロケーションで発生する可能性のある費用と比較する必要があります。Cloud Storage の費用の計算の詳細については、 Cloud Storage の料金をご覧ください。
パフォーマンスの向上: バケットをユーザーまたはアプリケーションの近くに再配置することで、データアクセス速度とアプリケーションのパフォーマンスを向上させます。そのためには、パフォーマンスが重要な地理的なリージョンを特定し、バケットを再配置します。
信頼性の向上: デュアルリージョンまたはマルチリージョン構成を使用して、データの耐久性と障害復旧機能を強化します。
バケットのロケーションを決定する
分析と目標に基づいて、移行するバケットに最も適したストレージ ロケーションを次のオプションから選択します。
単一リージョン: 1 つの地理的なエリアにユーザーが集中しているアプリケーションに費用対効果の高い、単一のリージョンにデータを保存します。
デュアルリージョン: 同じ大陸内の 2 つのリージョンにデータの 2 つのコピーを保持し、特定の地理的領域内での高可用性と障害復旧機能を提供します。
マルチリージョン: データを複数のリージョンに分散し、最高レベルの可用性と耐久性を提供します。
ロケーションの選択の詳細については、ロケーションの選択に関する考慮事項をご覧ください。
転勤期間に影響する要因を理解する
移転に要する時間にはいくつかの要因が影響します。これらの要因を理解することで、必要な時間を見積もることができます。これらの要素は、転勤の計画とスケジュールを立てる際の出発点として役立ちますが、実際の転勤時間は推定時間よりも長くなる場合や短くなる場合があります。そのため、移行のスケジュールを立てる際は、遅延の可能性を考慮してバッファ時間を追加してください。以降のセクションでは、再配置時間に影響する要因について説明します。
転居サービスの上限
次の表に、転勤期間に影響する制限事項を示します。
| 要素 | 値 | 説明 |
|---|---|---|
| ジョブあたりの最大リクエスト レート | 10,000 オブジェクト/秒 |
これは、サービスが 1 秒あたり処理できるコピー リクエストの数です。 リクエスト レートが高いほど、同時に移動できるファイルの数が増えます。バケットに小さなファイルが多数ある場合は、リクエスト レートが高いほど移行が速くなります。大きなファイルが数個しかない場合は、この要因の影響は小さくなります。 |
| プロジェクトあたりの最大全体帯域幅 | 10 Gbps |
これは、ソース ロケーション内の 1 つのプロジェクトのデータ転送に使用できる最大速度または帯域幅です。同じプロジェクト内で複数のバケットを移動する場合、バケットは帯域幅を共有します。 帯域幅が広いほど、一度に転送できるデータ量が多くなります。リクエスト レートが高い場合でも、帯域幅が小さいと、全体的な転送速度が遅くなります。 |
| 単一オブジェクトあたりの最大帯域幅 | 8 MBps |
これは、1 つのオブジェクトを転送できる最大速度です。 1 つのオブジェクトあたりの帯域幅が大きいほど、オブジェクトをより高速に転送できます。これは、一度に 1 つのオブジェクトを移動する場合の速度制限です。リクエスト レートが高く、バケットあたりの帯域幅が大きい場合でも、個々のオブジェクトに速度制限がある場合は、転送に時間がかかることがあります。 |
再配置の有効期間の上限
リソースの効率的な使用を確保し、再配置が無期限に実行されないようにするため、すべてのバケットの再配置に有効期間（TTL）の上限が適用されます。TTL は、再配置プロセス全体が完了するまでに許容される最大時間を指します。
バケットの再配置を完了できる最長時間は 28 日間です。これには、初期コピー、増分更新、最終同期など、再配置プロセスのすべてのフェーズが含まれます。
再配置プロセスが 28 日間の TTL 上限を超えると、再配置オペレーションは失敗します。
進行中のバケット アクティビティ
再配置中に新しいオブジェクトの書き込み、既存のオブジェクトの削除、バケット内のオブジェクトの更新を継続すると、これらのオペレーションはコピー リクエストとリソースを競合し、再配置プロセスが遅くなる可能性があります。
ライフサイクル ルール
特定の時間が経過した後にオブジェクトを自動的に削除またはアーカイブするなど、バケットにライフサイクル ルールが構成されている場合、これらのアクションにより、全体的な再配置時間が長くなります。
管理ハブを有効にする
移行元と移行先の両方のロケーションで管理ハブを有効にする必要があります。Management Hub は、Google Cloud リソース階層のさまざまなレベルで有効にできます。包含フィルタと除外フィルタを使用して、関連するバケットを Management Hub プランに含めることもできます。詳しくは、Management Hub を有効にするをご覧ください。
他の機能に関する考慮事項
バケットを再配置すると、他の Cloud Storage 機能と次のように相互作用します。
削除（復元可能）を有効にする
バケットの再配置では、バケットで 削除（復元可能）を有効にして、保持期間を 7 日以上に設定する必要があります。保持期間は、削除済み（復元可能）オブジェクトを完全に削除する前に保持する期間です。削除（復元可能）の保持期間を構成する方法については、削除（復元可能）を使用するをご覧ください。
割り当てと上限を確認する
割り当てとクラウド容量評価は、特定のリージョンまたはゾーンに関連付けられています。そのため、バケットを新しい場所に移動する場合は、新しい場所にバケットのデータに対応できる十分な割り当てがあることを確認する必要があります。割り当てと上限の詳細については、割り当てと上限をご覧ください。
バケットの再配置タイプを決定する
バケットを再配置する場合は、最後の同期ステップで書き込みのダウンタイムが発生し、新しいオブジェクトを更新またはアップロードできない可能性があることを理解することが重要です。また、再配置プロセス中はバケットの構成を変更できません。移行にダウンタイムが発生するかどうかを確認するには、移行の種類を判断するをご覧ください。
既存のバケットタグを削除する
バケットタグが適用されているバケットを再配置することはできません。バケットの再配置前に、既存のタグをすべて削除する必要があります。移行元バケットから削除されるタグがアクセス制御に使用されている場合は、別の方法で IAM 権限を設定して、バケット内のデータを安全に保つ必要があります。手順は次のとおりです。
タグ設定のコピーを作成して安全に保管します。
転送元バケットから既存のタグをすべて削除します。
既存のアクセス制御ルールに合わせて IAM 権限を構成します。
バケットを再配置したら、再配置したバケットに既存のタグを適用します。
既存のインベントリ レポートの構成を保存する
既存のインベントリ レポートの構成は、移行プロセス中に保持されません。移行プロセスを開始する前に、既存の在庫レポートの設定を手動で保存することをおすすめします。移行プロセスの完了後に、これらの設定を再作成する必要があります。インベントリ レポートの構成の管理については、インベントリ レポートの構成を作成して管理するをご覧ください。
次のステップ
- バケットを再配置する方法を学習する。