Autoclass 機能を使用すると、バケット内のオブジェクトが、各オブジェクトのアクセス パターンに基づいて適切なストレージ クラスに自動的に移行されます。この機能は、アクセスされないデータをアクセス頻度の低い（コールドな）ストレージ クラスに移動することでストレージ費用を削減します。また、アクセスされるデータを Standard Storage に移動することで、今後のアクセスを最適化します。Autoclass は、Cloud Storage データのコスト削減を簡素化して自動化します。
概要
有効にすると、Autoclass がバケットのストレージ クラスのすべての側面を管理します。
バケットに追加されたオブジェクトはすべて、リクエストで別のストレージ クラスが指定されていても、Standard Storage で開始されます。
バケット自体は、常にデフォルトのストレージ クラスが Standard Storage に設定されているため、このプロパティを Standard Storage 以外のストレージ クラスに変更しようとするリクエストが失敗します。
書き換えまたはコピー オペレーション中にオブジェクトのストレージ クラスを手動で変更しようとすると、全体的なオペレーションは成功します。ただし、ストレージ クラスの変更は無視され、オブジェクトは常に Standard Storage に設定されます。
アクセスされていない場合、ほとんどのオブジェクトは徐々にアクセス頻度の低い（コールドな）ストレージ クラスに移行されます。
デフォルトでは、Autoclass のターミナル ストレージ クラスは Nearline Storage です。オブジェクトは Nearline Storage に移行され、アクセスされるまでそのストレージ クラスに留まります。必要に応じて、ターミナル ストレージ クラスが Archive Storage になるように Autoclass を構成できます。
128 KiB 未満のオブジェクトは、よりコールドなストレージ クラスに移行しません。代わりに、Standard Storage に永続的に保存されます。オブジェクトが 128 KiB より小さいかどうかを判断するときは、オブジェクト メタデータではなく、オブジェクト データのみが考慮されます。
削除（復元可能）状態のオブジェクトは、保持期間が終了するまで既存のストレージ クラスを保持します。
まだ Standard Storage に保存されていないオブジェクトのデータが読み取られた場合、オブジェクトは Standard Storage に移行されます。
- オブジェクトのメタデータの読み取りや編集によって、オブジェクトが Standard Storage に移行されることはありません。
削除済み（復元可能）オブジェクトを復元すると、そのオブジェクトは、削除前のオブジェクトのストレージ クラスに関係なく、Standard Storage に作成されます。
料金
Cloud Storage の料金は、次の例外を除いて、Autoclass が有効なバケットと同じです。
- 取得料金は発生しません。
- 早期削除料金は請求されません。
- すべてのオペレーションには Standard Storage の料金が適用されます。
- Autoclass がオブジェクトをコールドなストレージ クラスに移行しても、オペレーションの費用は発生しません。
- Autoclass が Nearline Storage から Standard Storage にオブジェクトを移行する場合、クラス A オペレーションの費用は発生しません。
- Autoclass がオブジェクトを Coldline storage または Archive storage から Standard storage または Nearline storage に移行する場合、そのような移行ごとにクラス A オペレーションの料金が発生します。
- Autoclass を使用する場合は、管理料金とイネーブルメント料金が適用されます。
既存のバケット向け Autoclass
既存のバケットに対して、Autoclass 構成を有効化、無効化、または変更できます。
Autoclass の構成に対する変更が有効になるまでに最大 1 日かかる場合があります。その間、Cloud Storage は以前の構成に基づいてアクションの実行を継続する場合があります。
既存のバケットで Autoclass を有効にすると、次のようになります。
削除済み（復元可能）オブジェクトを除き、バケット内のすべてのオブジェクトが Standard Storage に移行されます。
Autoclass を有効にした時点ですでに Standard Storage にあるオブジェクトは、Standard Storage に移行した直後であるかのように扱われます。そのため、このようなオブジェクトはさらに 30 日間のアクセス不可期間の経過後に Nearline Storage に移行できます。
Autoclass の有効化に対して 1 回のみ課金されます。詳細については、Autoclass の料金をご覧ください。
既存のバケットで Autoclass を無効にすると、次のようになります。
- 各オブジェクトは、Autoclass が無効になった時点で保持しているストレージ クラスに保存されたままになります。その後、Autoclass 以外のバケットと同様に、オブジェクトのストレージ クラスを変更できます。
- Autoclass の料金体系は適用されなくなります。
- 1 日経過するまで、バケットで Autoclass を再度有効にすることはできません。これを行おうとすると失敗します。
Autoclass 構成でターミナルのストレージ クラスを変更すると、次のようになります。
ターミナル ストレージ クラスを Archive Storage から Nearline Storage に変更すると、変更時に Archive Storage と Coldline Storage にあるオブジェクトは Nearline Storage に移行されます。
ターミナル ストレージ クラスを Nearline Storage から Archive Storage に変更すると、変更時に Nearline Storage にあるオブジェクトは、Nearline Storage に移行した直後であるかのように扱われます。そのため、このようなオブジェクトは、さらに 60 日間のアクセス不可期間の経過後に、Coldline Storage に移行できます。
Autoclass を使用する必要がある場合
有効にすると、Autoclass は必要なデータ マネジメントの量を減らし、他のバケットに適用される特定の料金の発生を防ぎます。Autoclass は、次の一般的なアクセス パターンを可能にする便利な機能です。
- データにはさまざまなアクセス頻度がある。
- データへのアクセス パターンが不明であるか、予測できない。
ただし、バケットデータの大部分が特定のストレージ クラスのユースケースに該当する場合は、Autoclass はおすすめしません。たとえば、バケットに 2 つのユースケースがあり、一部のデータは週単位でアクセスし、一部のデータはアクセスされないバックアップ データであるとします。このシナリオでは、オブジェクトがどのユースケースに分類されるかわかっている場合は、Autoclass の使用はおすすめしません。
他の Google Cloud サービスがバケットからデータを定期的に読み取る場合も Autoclass をおすすめしません。たとえば、Sensitive Data Protection を使用してバケットの内容をスキャンする場合、Autoclass はおすすめしません。
移行の動作
Autoclass を有効にすると、次のようにサイズが 128 KiB 以上のオブジェクトがストレージ クラス間で移行されます。
オブジェクトのデータにアクセスすると、オブジェクトが Standard Storage に移行します。
30 日間アクセスされなかったオブジェクトは Nearline Storage に移行されます。
ターミナル ストレージ クラスとして Nearline Storage を使用するようにバケットが構成されている場合、Autoclass では、Nearline Storage に格納されたオブジェクトのアクセス時にのみ、オブジェクトの状態が変更されます。
バケットが Archive Storage をターミナル ストレージ クラスとして使用するように構成されている場合、オブジェクトは次のようにコールド ストレージ クラスに引き続き移行します。
90 日間アクセスされなかったオブジェクトはすべて Coldline Storage に移行されます。そのようなオブジェクトは、Standard Storage に少なくとも 30 日間、Nearline Storage に 60 日間滞在しました。
365 日間アクセスされなかったオブジェクトはすべて、Archive Storage に移行されます。このようなオブジェクトは、Standard Storage に少なくとも 30 日間、Nearline Storage に 60 日間、Coldline Storage に275 日間滞在しました。
Autoclass では、Archive Storage に保存されているオブジェクトがアクセスされた場合にのみ、その状態が変更されます。
オブジェクトがストレージ クラス間で移行可能になると、Cloud Storage は非同期的に移行を行います。このため、オブジェクトが移行可能になってから実際に移行が行われるまでに時間差が生じることがあります。
- この間、オブジェクトに対して引き続き移行前のストレージ クラスのレートで課金されます。ただし、Autoclass を有効にした結果として Standard Storage に移行する場合は除きます。
制限事項
バケットで AutoClass を有効にせず、オブジェクトのライフサイクル管理構成で次のいずれかを設定することはできません。
SetStorageClassアクションを使用するルール。matchesStorageClass条件を使用するルール。
バケットで Autoclass を有効にし、上記のオブジェクトのライフサイクル管理ルールのいずれかを設定するリクエストは失敗します。
オブジェクト作成では、ソース オブジェクトと作成されるオブジェクトのすべてが同じストレージ クラスを使用する必要があるため、作成リクエストの時点ですべてのソース オブジェクトが Standard Storage として保存されていない限り、Autoclass バケットへのオブジェクトの作成は失敗します。
ストレージ クラスの使用状況と移行のモニタリング
Monitoring では、次のストレージ指標を使用してストレージ クラスの移行を追跡できます。
autoclass/transition_operation_count: Autoclass が開始したストレージ クラスの移行数。Autoclass の有効化の一環として発生した遷移は除きます。
autoclass/transitioned_bytes_count: Autoclass によって移行された合計バイト数。Autoclass の有効化の一環として移行されたバイトは除きます。
必要に応じて、移行に関連するソース ストレージ クラスまたは宛先のストレージ クラスごとに両方の指標をグループ化できます。
Monitoring を使用して指標を追跡する方法については、Metrics Explorer を使用してグラフを作成するをご覧ください。
また、Google Cloud コンソールでバケットの [構成] タブに移動し、[パフォーマンスを確認] をクリックすると、Autoclass 対応バケットの各ストレージ クラスに格納されているバイト数の時間による変化をモニタリングできます。
次のステップ
- Autoclass を有効にします。
- オブジェクト ライフサイクル管理について学習する。