バケット容量を使用するデータ
W&B は、設定済みのオブジェクトストレージに複数のカテゴリのデータを保存します。BYOB の概要には、実験ファイルとメトリクス、アーティファクトファイル、メディアファイル、run ファイル、Parquet 形式でエクスポートされた履歴などの例が記載されています。これらのデータ全体がバケットのサイズとコストを左右します。W&B がストレージからデータを削除する仕組み
W&B アプリまたは Public API での削除では、まず W&B のメタデータが更新されます。プロダクトから run、アーティファクト、file を削除しても、報告されるバケットの使用量がすぐに減少するとは限りません。オブジェクトストレージのクリーンアップはバックグラウンドで実行されるため、特に負荷の高いインスタンスでは遅延する場合があります。アーティファクト
削除されたアーティファクトは論理削除され、その後アーティファクトのガベージコレクションで処理されます。セルフマネージドのデプロイでは、GORILLA_ARTIFACT_GC_ENABLED を設定し、バージョン管理や論理削除などのプロバイダー要件を満たす必要があります。アーティファクトを削除すると環境変数を設定するを参照してください。
run データと run ファイル
run または run に関連付けられたファイルを削除した後、基盤となる保存済みオブジェクトの完全な削除は、アーティファクトとは別に制御されます。専用クラウドおよびセルフマネージドのデプロイでは、GORILLA_DATA_RETENTION_PERIOD によって、削除された run データがストレージから削除可能になるまでの保持期間を設定します。この設定ではアーティファクトは削除されません。環境変数を設定する、専用クラウドのデータ保持ポリシー、および run とファイルの削除がストレージにどう関係するかについては run を削除するを参照してください。
バックグラウンドクリーンアップで期待されること
ガベージコレクションおよびオブジェクトストレージを解放する関連ジョブは、タイミングの保証なしに実行されます。W&B は、UI または API でコンテンツを削除した後、特定の時間内に指定されたオブジェクトがバケットから消えることを保証しません。run ごとに多数のメディアファイルをログする場合など、run あたりのファイル数が多い project では、ストレージ使用量が解放されるまでに長い遅延が予想されます。 cloud プロバイダーのバケットを監視し、クリーンアップが停止していると思われる場合は、W&B Support またはアカウントチームにお問い合わせください。バケットの使用量を削減する
このセクションでは、バケットの空き容量を増やすための推奨操作順序を説明します。安全なプロダクト内の手順から始め、より慎重な対応が必要なバケットへの直接操作へと進みます。 まず、サポートされるプロダクト内の手順を使用してください。- 不要になった run を W&B アプリで削除するか、Python で削除してください。
- 不要になったアーティファクトを削除し、ワークフローに適している場合はアーティファクトの TTL を使用してください。
- 削除したオブジェクトは、W&B を通じてダウンロードできなくなります。
- 削除対象のキーのみを削除してください。誤って削除すると、アプリが引き続き参照しているデータにアクセスできなくなる可能性があります。
- バケットでオブジェクトのバージョン管理またはプロバイダーの論理削除 (Google Cloud Storage など) を使用している場合、最新ではないバージョンや論理削除されたオブジェクトがクラウドのライフサイクルルールに従って期限切れになるまで、ストレージ料金が発生し続ける可能性があります。 :::