オブジェクト・ストレージの概要

オブジェクト・ストレージ・リソース

Object Storageサービスでは、次のコンポーネントを使用してオブジェクト・ストレージに格納されているデータを編成します:

オブジェクト

コンテンツ・タイプに関係なく、あらゆるタイプのデータがオブジェクトとして格納されます。

オブジェクトは、オブジェクト自体とオブジェクトに関するメタデータで構成されます。各オブジェクトはバケットに格納されます。オブジェクトは単一のエンティティとして処理されます。

バケット

バケットは、オブジェクトを格納するための論理コンテナです。

ユーザーまたはシステムは、必要に応じてバケットを作成します。バケットは、バケットおよびバケット内のすべてのオブジェクトでユーザーが実行できるアクションを決定するポリシーを持つ1つのコンパートメントに関連付けられます。バケットはネストできません。

バケット名は決定しますが、各バケット名は1つのネームスペース内で一意である必要があります。

ネームスペース

Object Storageネームスペースは、すべてのバケットとオブジェクトの最上位コンテナとして機能します。

テナンシがプロビジョニングされると、テナンシには、システム生成で不変の一意のオブジェクト・ストレージ・ネームスペース名が1つ割り当てられます。ネームスペースは、テナント内のすべてのコンパートメントにわたります。

ネームスペース内では、バケットとオブジェクトはフラットな階層に存在しますが、ディレクトリ構造をシミュレートして、大きなオブジェクトのセットをナビゲートできます。

コンパートメント

コンパートメントは、クラウド・リソースの編成に使用される主要なビルディング・ブロックです。

テナンシがプロビジョニングされると、ルート・コンパートメントが作成されます。その後、ルート・コンパートメントの下にコンパートメントを作成して、リソースを編成できます。ユーザー・グループがそれらのコンパートメントのリソースに対して実行できるアクションを指定するポリシーを作成して、アクセスを制御します。オブジェクト・ストレージ・バケットは1つのコンパートメントにのみ存在できます。

オブジェクト・ネーミング・プレフィクスおよび階層

Object Storageネームスペース内で、バケットとオブジェクトはフラットな構造に存在します。ただし、1つ以上のスラッシュ(/)を含むプレフィクス文字列をオブジェクト名に追加することで、ディレクトリ構造をシミュレートできます。これにより、一度に1つのディレクトリをリストできます。これは、大量のオブジェクトをナビゲートする場合に役立ちます。

たとえば:

marathon/finish_line.jpg
marathon/participants/p_21.jpg

オブジェクト名にプレフィクスを追加すると、次のことができます:

OCI CLIまたは「コンピュートAPI」を使用して、階層の指定レベルのすべてのオブジェクトの一括ダウンロードおよび一括削除を実行します。
「コンピュートWeb UI」を使用して、仮想フォルダ内のオブジェクトの階層ビューを表示します。前述の例では、marathonはfinish_line.jpgという名前のオブジェクトを含むフォルダとして表示され、participantsはp_21.jpgという名前のオブジェクトを含むmarathonのサブフォルダになります。オブジェクトを階層の任意のレベルに一括アップロードし、バケットまたはフォルダ内のすべてのオブジェクトを一括削除できます。

階層の指定レベルのバルク操作は、上のどのレベルのオブジェクトにも影響を与えません。

オブジェクトに名前を付けるときは、デリミタなしでプレフィクス文字列を使用することもできます。デリミタでは、「コンピュートWeb UI」内の検索操作と、OCI CLIまたは「コンピュートAPI」内の特定のバルク操作がオブジェクト名のプレフィクス部分と一致することを許可しません。たとえば、次のオブジェクト名では、文字列gloves_27_は、一括操作の実行時に照合の目的でプレフィクスとして機能します:

gloves_27_dark_green.jpg
gloves_27_light_blue.jpg

UIを使用して一括アップロードを実行する場合は、アップロードするファイルの名前にプレフィクス文字列を追加できます。

オブジェクト名

他のリソースとは異なり、オブジェクトにはOracleクラウド識別子(OCIDs)はありません。かわりに、ユーザーはオブジェクトをアップロードするときにオブジェクト名を定義します。

オブジェクトに名前を付ける際は、次のガイドラインに従ってください:

オブジェクト名およびバケット名の最大長は255文字です。
有効な文字は、文字(大文字または小文字)、数字、および改行、キャリッジ・リターン、およびNULL以外の文字です。
バケット名とオブジェクト名は大/小文字が区別されます。
UTF-8エンコーディングが1024バイトを超えないUnicode文字のみを使用してください。クライアントはURLエンコーディング文字を担当します。
バケット内で名前を一意にします。
オブジェクト名には、名前に1つ以上のスラッシュ(/)文字を含めることができます。「オブジェクト・ネーミング・プレフィクスおよび階層」を参照してください。

オプションのレスポンス・ヘッダーとメタデータ

オブジェクトをアップロードする際、オプションのレスポンス・ヘッダーとユーザー定義メタデータを指定できます。レスポンス・ヘッダーは、オブジェクトのダウンロード時にObject StorageクライアントからObject Storageクライアントに送信されるHTTPヘッダーです。

ユーザー定義メタデータは、オブジェクトとともに格納される名前と値のペアです。

「コンピュートWeb UI」、「コンピュートAPI」またはOCI CLIを使用して、これらのオプション属性を指定できます。

重要:

指定したレスポンス・ヘッダーまたはメタデータに対して検証は実行されません。

次のレスポンス・ヘッダーの値を指定できます:

Content-Disposition

オブジェクトのプレゼンテーション情報のみを定義します。このヘッダーの値を指定しても、オブジェクト・ストレージの動作には影響しません。オブジェクトを読み取るプログラムによって、指定された値に基づいて行う方法が決まります。たとえば、このヘッダーを使用すると、ユーザーはブラウザでカスタム・ファイル名を持つオブジェクトをダウンロードできます。たとえば:
```
attachment; filename="fname.ext"
```
Cache-Control

オブジェクトのキャッシュ動作を定義します。このヘッダーの値を指定しても、オブジェクト・ストレージの動作には影響しません。オブジェクトを読み取るプログラムによって、指定された値に基づいて行う方法が決まります。たとえば、このヘッダーを使用して、キャッシュ制限が必要なオブジェクトを識別できます。たとえば:
```
no-cache, no-store
```

メタデータ

ユーザー定義メタデータは、名前と値のペアの形式で指定します。ユーザー定義のメタデータ名は格納され、opc-meta-という必須のプレフィクス付きでObject Storageクライアントに戻されます。

マルチパート・アップロード

Object Storageサービスでは、特に大きなオブジェクトに対して、より効率的で自己回復性の高いアップロードのためのマルチパート・アップロードをサポートしています。

「コンピュートAPI」またはCLIを使用して、マルチパート・アップロードを実行できます。「コンピュートWeb UI」は、マルチパート・アップロードを使用して、64 MiBより大きいオブジェクトをアップロードします。

マルチパート・アップロードでは、オブジェクトの個々のパートを並行してアップロードすることで、アップロードに費やす時間を短縮できます。 APIを介して実行されるマルチパート・アップロードでは、オブジェクトのアップロード全体を再試行するのではなく、失敗したパートのアップロードを再試行できるため、ネットワーク障害の影響も最小限に抑えることができます。

マルチパート・アップロードでは、1つのアップロード操作に対して大きすぎるオブジェクトに対応できます。 APIを通じて実行される大規模なアップロードの場合、個々のパートのアップロード間で一時停止し、スケジュールとリソースが許すときにアップロードを再開する柔軟性を得ることができます。

オブジェクト部品

マルチパート・アップロードでは、アップロードするオブジェクトを個別のパートに分割します。個々のパートは50 GiBまでです。アップロードされたオブジェクトの最大サイズは10 TiBです。

各パーツに使用するパーツ番号を決定します。パーツ番号は1 ~ 10,000です。連続した番号を割り当てる必要はありませんが、Object Storageは、パート番号を昇順に並べることでオブジェクトを作成します。

マルチパート・アップロードAPI

マルチパート・アップロード「コンピュートAPI」を使用する前に、アップロードするパートを作成する必要があります。 Object Storageは、残りのステップに対するAPI操作を提供します。

APIを使用して実行されるマルチパート・アップロードは、次のステップで構成されます:

アップロードを開始します。
オブジェクト・パートをアップロードします。
アップロードをコミットします。

また、このサービスでは、進行中のマルチパート・アップロードのリスト、進行中のマルチパート・アップロードのオブジェクト・パートのリスト、およびAPIから開始された進行中のマルチパート・アップロードの中断を行うためのAPI操作も提供します。

マルチパート・アップロードCLI

OCI CLIを使用してマルチパート・アップロードを実行する場合は、「コンピュートAPI」で行う必要があるため、オブジェクトをパートに分割する必要はありません。かわりに、選択したパート・サイズを指定すると、Object Storageによってオブジェクトがパートに分割され、すべてのパートのアップロードが自動的に実行されます。パラレルでアップロードできるパートの最大数を設定できます。デフォルトでは、CLIは、パラレルにアップロードできるパートの数を3つに制限します。 CLIを使用する場合、アップロードの完了時にコミットを実行する必要はありません。

CLIを使用して、進行中のマルチパート・アップロードをリストしたり、APIを介して開始されたマルチパート・アップロードを中断することもできます。

事前認証済リクエスト

事前認証済リクエストは、リクエスト作成者がオブジェクトにアクセスする権限を持っている場合、ユーザーが独自の資格証明を持たずにバケットまたはオブジェクトにアクセスできるようにする手段を提供します。

たとえば、ユーザーがAPIキーを所有せずにバケットにバックアップをアップロードする操作をサポートするリクエストを作成できます。または、ビジネス・パートナがAPIキーを所有せずにバケット内の共有データを更新できるリクエストを作成できます。

事前認証済リクエストの作成時に、一意のURLが生成されます。このURLを提供するユーザーは、curlやwgetなどの標準HTTPツールを使用して、事前認証済リクエストで識別されるObject Storageリソースにアクセスできます。

重要:

ビジネス要件と、バケットまたはオブジェクトへの事前認証済アクセスのセキュリティ上の影響を評価します。

事前認証済リクエストURLは、リクエストで識別されたターゲットへのURLアクセス権を持つすべてのユーザーに提供します。 URLの配布を慎重に管理します。

必要な権限

事前認証済リクエストを作成するには

ターゲット・バケットまたはオブジェクトに対するPAR_MANAGE権限が必要です。

また、付与するアクセス・タイプに対する適切な権限を持っている必要があります。たとえば:

オブジェクトをバケットにアップロードするための事前認証済リクエストを作成する場合、OBJECT_CREATEおよびOBJECT_OVERWRITE権限が必要です。
バケット内のオブジェクトに対する読取り/書込みアクセス用の事前認証済リクエストを作成する場合は、OBJECT_READ、OBJECT_CREATEおよびOBJECT_OVERWRITE権限が必要です。

重要:

事前認証済リクエストの作成者がリクエストの作成後に削除されるか、必要な権限が失われた場合、リクエストは機能しなくなります。

事前認証済リクエストを使用するには

事前認証済リクエストを使用するたびに、事前認証済リクエスト作成者の権限がチェックされます。

次のいずれかが発生すると、事前認証済リクエストは機能しなくなります:

事前認証済リクエスト作成者の権限が変更されました。
事前認証済リクエストを作成したユーザーが削除されます。
事前認証済リクエストを作成したフェデレーテッド・ユーザーが、リクエストを作成したときのユーザー機能を失いました。
事前認証済リクエストの有効期限が切れています。

事前認証リクエストのタイプ

事前認証済リクエストを作成する場合、次のオプションがあります:

事前認証済リクエスト・ユーザーが書込みアクセス権を持ち、1つ以上のオブジェクトをアップロードできるバケットの名前を指定できます。
事前認証済リクエスト・ユーザーが読取り、書込みまたは読取りおよび書込みを実行できるオブジェクトの名前を指定できます。

スコープと制約

事前認証済リクエストに関する次のスコープおよび制約の理解:

ユーザーはバケット・コンテンツをリストできません。
事前認証済リクエストはいくつでも作成できます。
設定できる有効期限までの時間制限はありません。
事前認証済リクエストは編集できません。要件の変更に応じてユーザー・アクセス・オプションを変更する場合は、新しい事前認証済リクエストを作成する必要があります。
事前認証済リクエストのターゲットおよびアクションは、作成者権限に基づきます。ただし、リクエストは作成者アカウントのログイン資格証明にバインドされません。作成者のログイン資格証明が変更された場合、事前認証済リクエストは影響を受けません。
そのバケットまたはそのバケット内のオブジェクトに関連付けられた事前認証済リクエストがあるバケットは削除できません。

重要:

事前認証済リクエストの作成時にシステムによって提供される一意のURLは、ユーザーがリクエスト・ターゲットとして指定されたバケットまたはオブジェクトにアクセスできる唯一の方法です。 URLを永続ストレージにコピーします。 URLは作成時にのみ表示され、後で取得することはできません。

保持ルール

保持ルールは、データ・ガバナンス、規制コンプライアンスおよび法的保持要件のためにオブジェクト・ストレージに書き込まれるデータに対して、不変のWORM準拠のストレージ・オプションを提供します。

保存ルールは、偶発的または悪意のある更新、上書きまたは削除からデータを保護することもできます。保持ルールは、管理者がルールの変更やデータの削除や変更を行わないようにロックできます。

保持ルールはバケット・レベルで構成され、バケット内のすべての個別オブジェクトに適用されます。

Object Storageは、次のユースケースをサポートするデータ保持に対する柔軟なアプローチを提供します。

規制準拠

業界では、一定の期間データを保持することが必要になる場合があります。データ保持規則では、保持設定をロックする必要もあります。設定をロックした場合、変更できるのは保持期間を延長することのみです。

Object Storageの規制コンプライアンスのために、期限付き保持ルールを作成し、期間を指定します。指定した期間、オブジェクトの変更および削除は禁止されます。期間は各オブジェクトに個別に適用され、オブジェクトの最終変更タイムスタンプに基づきます。必要に応じてルールをロックします。
データ・ガバナンス

内部ビジネス・プロセス要件の一部として、特定のデータ・セットを保護する必要がある場合があります。定義された期間のデータを保持する場合、その期間は変更される可能性があります。

時間制限のある保持ルールを作成し、期間を指定します。指定した期間、オブジェクトの変更および削除は禁止されます。期間は各オブジェクトに個別に適用され、オブジェクトの最終変更タイムスタンプに基づきます。ルールを削除し、必要に応じて期間を変更できるようにするには、ルールをロックしないでください。
法的保留

潜在的な訴訟や継続的な訴訟に対応して、特定のビジネス・データを保持する必要がある場合があります。法的保留には保存期間が定義されておらず、削除されるまで有効です。

Object Storageの法的保留の場合は、無期限の保持ルールを作成します。オブジェクトの変更および削除は、ルールを削除するまで防止されます。無期限の保持ルールは期間がないためロックできません。

時間制限ルールの保持期間を理解することが重要です。バケットの保持ルールを作成している場合でも、ルールの期間はバケット内の各オブジェクトに個別に適用され、オブジェクトの最終変更タイムスタンプに基づきます。バケットに2つのオブジェクトObjectXおよびObjectYがあるとします。 ObjectXは14か月前に最終変更され、ObjectYは3か月前に最終変更されました。 1年間の保持ルールを作成します。このルールは、次の9か月間のObjectYの変更または削除を防止します。保持ルールの期間(1年)がオブジェクトの最終変更タイムスタンプ(14か月)より短いため、このルールではObjectXの変更または削除が許可されます。 ObjectXが翌年の何度か上書きされた場合、残りのルール期間の間、変更および削除は禁止されます。

「保持ルールのロックは元に戻せない操作です」。テナンシ管理者がロックされたルールを削除することはできません。ルールがロックされるまで、必須の14日間の遅延があります。この遅延により、ルールが完全にロックされる前に、ルールまたはルール・ロックを完全にテスト、変更または削除できます。ルールは作成時にアクティブになります。ロックは、ルール自体を変更できるかどうかのみを制御します。ルールがロックされると、期間の増加のみが許可されます。オブジェクトの変更は禁止されており、ルールはバケットを削除することによってのみ削除できます。バケットを削除する前に、空にする必要があります。

スコープと制約

保持ルールは、オブジェクト・ストレージのバケットに適用できます。
アクティブな保持ルールがあるバケットに対して実行できるアクションは制限されています。保存ルールが削除されるか(無限ルール)、指定した期間(期限付きルール)まで、オブジェクトまたはオブジェクト・メタデータを更新、上書きまたは削除できません。期限付きルールの期間は、各オブジェクトに個別に適用され、オブジェクトの最終変更タイムスタンプに基づきます。
1つのバケットに対して複数の保持ルールを作成できます。無期限の保持ルールは、時間制限ルールが考慮される前に適用されます。
保持ルールがロックされている場合、ルールはバケットを削除することによってのみ削除できます。バケットを削除する前に、空にする必要があります。

保持とその他のオブジェクト・ストレージ機能間の相互作用

使用している他のObject Storage機能のために配置されているポリシーおよびルールを慎重に確認します。これらのポリシーおよびルールの一部は保持ルールで有効にならない場合があります。この項では、保持ルールとその他のオブジェクト・ストレージ機能間の相互作用について知っておく必要がある重要な事項について説明します。

マルチパート・アップロード

コミットされていない(未終了または失敗)マルチパート・アップロードは、保存ルールによって保護されず、いつでも削除できます。

バージョニング

バージョニングが有効になっているバケットには保持ルールを追加できません。
アクティブな保持ルールがあるバケットでバージョニングを有効にすることはできません。
バージョニングが一時停止されているバケットに保持ルールを追加できます。ただし、アクティブな保持ルールでバージョニングを再開することはできません。

保持ルールのトラブルシューティング

保持ルールを作成できません

保持ルールの作成に失敗した場合、最も可能性の高い原因は、IAM権限が欠落しているか、不完全であることです。ルールの作成には次が必要です:

バケットにアクセスし、それらのバケット内のオブジェクトを管理できるユーザー権限。
少なくとも、BUCKET_UPDATEおよびRETENTION_RULE_MANAGE権限です。
少なくとも、BUCKET_UPDATEおよびRETENTION_RULE_MANAGE権限です。

保持ルールをロックできません

保持ルールのロックに失敗した場合、最も可能性の高い原因は、IAM権限が欠落しているか、不完全です。保持ルールをロックするには、少なくともBUCKET_UPDATE、RETENTION_RULE_MANAGEおよびRETENTION_RULE_LOCK権限が必要です。

保持ルールを削除できません

ロックされている期限付き保持ルールは削除できません。保持ルールがロックされている場合、ルールはバケットを削除することによってのみ削除できます。バケットを削除する前に、空にする必要があります。

無期限の保持ルールの削除に失敗した場合、最も可能性の高い原因は、IAM権限が欠落しているか、不完全であることです。ルールの削除には次が必要です:

バケットにアクセスし、それらのバケット内のオブジェクトを管理できるユーザー権限。
少なくとも、BUCKET_UPDATEおよびRETENTION_RULE_MANAGE権限です。

オブジェクト・バージョニング

オブジェクト・バージョニングは、偶発的または悪意のあるオブジェクトの更新、上書きまたは削除に対するデータ保護を提供します。

オブジェクト・バージョニングはバケット・レベルで有効化されます。バージョニングは、次のいずれかのアクションが発生するたびにオブジェクト・バージョンを自動的に作成するようObject Storageに指示します:

新しいオブジェクトがアップロードされます。
既存のオブジェクトが上書きされます。
オブジェクトが削除されたとき。

オブジェクト・バージョニングは、バケット作成時以降で有効化できます。

バージョニング対応のバケットには、オブジェクトの多数のバージョンを含めることができます。オブジェクトの最新バージョンは常に1つで、それ以前のバージョンは0つ以上あります。

オブジェクト・バージョン削除

バージョニングが有効になっているバケットからオブジェクトは、明示的なアクションを実行するまで物理的に削除されません。

特定のバージョンをターゲットとせずにオブジェクトを削除すると、最新のオブジェクト・バージョンが以前のオブジェクト・バージョンになり、削除ポイントをマークする特別な削除マーカーが作成されます。削除マーカーには最小限のメタデータのみが含まれます。フォルダを削除すると、フォルダ内のオブジェクトごとに削除マーカーが作成されます。削除マーカーを削除して、削除したバージョンを最新のオブジェクト・バージョンにすることもできます。

削除マーカーと同じ名前のオブジェクトをアップロードすると、アップロードされたオブジェクトはオブジェクトの最新バージョンになります。削除マーカーは残ります。 1つのオブジェクトに複数の削除マーカーがあり、以前のオブジェクト・バージョンのいずれかをリカバリできます。

オブジェクト・バージョンの削除が異なります。オブジェクト・バージョンを削除すると、そのバージョンは完全に削除されます。バージョンIDによって最新バージョンを明示的に削除した場合も、完全に削除されます。特定のオブジェクト・バージョンIDをターゲットとするすべての削除操作では、データが完全に削除されます。

スコープと制約

バージョニングはオブジェクト・ストレージのバケット上で有効化できます。
オブジェクトの最新バージョンの名前は変更できますが、以前のオブジェクト・バージョンの名前は変更できません。オブジェクトの名前を変更すると、新しいオブジェクトが作成されます。

バージョニングとその他のオブジェクト・ストレージ機能間の相互作用

この項では、オブジェクト・バージョニングと他のオブジェクト・ストレージ機能との相互作用について知っておく必要がある重要な事項について説明します。

オブジェクトのコピー

オブジェクトの最新バージョンを別のバケットにコピーすると、オブジェクトのみがコピーされます。オブジェクトの以前のバージョンはコピーされません。以前のバージョンのオブジェクトを別のバケットにコピーできますが、そのアクションでは、新しいオブジェクトの最新バージョンまたは宛先バケット内の新しいオブジェクト・バージョンのいずれかが作成されます。

保持ルール

バージョニングが有効になっているバケットには保持ルールを追加できません。
アクティブな保持ルールがあるバケットでバージョニングを有効にすることはできません。
バージョニングが一時停止されているバケットに保持ルールを追加できます。ただし、アクティブな保持ルールでバージョニングを再開することはできません。

バージョニングのトラブルシューティング

バージョニングを有効化できません

バージョニングの有効化に失敗した場合、最も可能性の高い原因は、IAM権限が欠落しているか、不完全であることです。バージョニングの有効化には次が必要です:

バケットを使用し、そのバケット内のオブジェクトを管理できるユーザー権限。
Minimally, BUCKET_UPDATE permissions.

バケットを削除できません

バケットの削除に失敗した場合、最も可能性の高い原因はバケットが空でないことです。

空のバケットを完全に削除できます。次のいずれかを含むバケットは削除できません:

すべてのオブジェクト
オブジェクトの前のバージョン
マルチパート・アップロードが進行中です
事前認証済リクエスト

ヒント:

バージョン対応バケット内のオブジェクトを削除すると、そのオブジェクトの以前のバージョンが作成されます。削除済オブジェクトの表示を選択して、バケットの削除を妨げる可能性のあるオブジェクト・バージョンを表示します。

前のバージョンを削除できません

以前のオブジェクト・バージョンの削除に失敗した場合、最も可能性の高い原因は、IAM権限が欠落しているか、不完全であることです。オブジェクト・バージョンの削除には次が必要です:

バケットを使用し、そのバケット内のオブジェクトを管理できるユーザー権限。
Minimally, OBJECT_VERSION_DELETE permissions.