バケット容量を消費するもの
W&B は、設定したオブジェクトストレージに複数の種類のデータを保存します。BYOB overview には、実験ファイルとメトリクス、artifact ファイル、メディアファイル、run ファイル、Parquet 形式でエクスポートされた履歴などの例が記載されています。これらの合計が、バケットのサイズとコストに影響します。W&B がストレージからデータを削除する仕組み
W&B App または Public API で削除を行うと、まず W&B のメタデータが更新されます。プロダクトから run、アーティファクト、またはファイルを削除しても、表示されるバケット使用量がすぐに減るとは限りません。オブジェクトストレージのクリーンアップはバックグラウンドで実行されるため、特に高負荷のインスタンスでは反映が遅れることがあります。Artifacts
削除されたアーティファクトはソフト削除された後、アーティファクト のガベージコレクションによって処理されます。セルフマネージドのデプロイでは、GORILLA_ARTIFACT_GC_ENABLED を設定し、バージョン管理やソフト削除などのプロバイダの要件を満たす必要があります。アーティファクトを削除するおよび環境変数を設定するを参照してください。
runデータとrunファイル
runまたはrunに関連付けられたファイルが削除された後、基盤となる保存オブジェクトの完全な削除は、アーティファクト とは別に制御されます。専用クラウドおよびセルフマネージドのデプロイでは、GORILLA_DATA_RETENTION_PERIOD で、削除されたrunデータがストレージから削除可能になるまで保持される期間を設定します。この設定で アーティファクト が削除されることはありません。runおよびファイルの削除とストレージとの関係については、環境変数を設定する、専用クラウド向けの データ保持ポリシー、および ランを削除する を参照してください。
バックグラウンド クリーンアップで想定されること
オブジェクトストレージを解放するガベージコレクションと関連ジョブの実行タイミングは保証されません。W&B は、UI または API でコンテンツを削除したあと、特定の時間内に対象のオブジェクトがバケットから消えることを保証しません。1 つのrunあたりのファイル数が多いプロジェクト、たとえば 1 つのrunで多数のメディアファイルをログしている場合は、ストレージ使用量が解放されるまでにより長い遅延が発生することがあります。 クラウドプロバイダ側でバケットを監視し、クリーンアップが滞っているように見える場合は、W&B Support または担当のアカウントチームにお問い合わせください。バケット使用量を減らす
このセクションでは、バケットの空き容量を増やすための推奨される操作順序について説明します。安全なプロダクトの機能から始めて、より注意が必要なバケットの直接操作へと進みます。 まずは、サポートされているプロダクトの機能で対応してください。- 不要になったrunは、W&B App で削除する か、Python で削除する ようにしてください。
- 不要になったアーティファクトを削除し、ワークフローに合う場合は アーティファクト TTL を使用してください。
- 削除したオブジェクトは、W&B 経由でダウンロードできなくなります。
- 削除するつもりのキーだけを削除してください。誤って削除すると、アプリがまだ参照しているデータにアクセスできなくなる可能性があります。
- バケットでオブジェクトのバージョン管理またはプロバイダのソフト削除 (たとえば Google Cloud Storage) を使用している場合、クラウドのライフサイクル ルールに従って非カレント バージョンやソフト削除されたオブジェクトの有効期限が切れるまで、ストレージ料金が発生し続けることがあります。 :::