Go to Qiita Advent Calendar 2024 Top
LoginSignup
21
14

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

@ksonoda(Kenichi Sonoda)in日本オラクル株式会社

【総まとめ】Oracle Cloud Infrastructure オブジェクト・ストレージ・サービスの機能概要

Last updated at Posted at 2019-05-17

オブジェクト・ストレージサービス

容量計画や拡張作業などの煩わしい問題を気にせずに利用できるクラウド上のストレージサービスです。データのバックアップや災害対策だけでなく、ビッグデータ分析やリアルタイム処理のデータストアとしても利用いただけるサービスです。

#サービスの可用性やセキュリティは？
オブジェクトストレージ・サービスでは下記のような実装がなされており、大抵のシステム要件はクリアできるのではないかなと思います。

  • 可用性は99.9%、耐久性は99.999999999%(イレブン・ナイン)
  • 万一サービス利用中に何らかの障害が発生した場合はSLA(APIエラー率)に基づきサービス・クレジットされる(詳細は「Oracle Cloud Infrastructureサービス・レベル合意」を参照)
  • オブジェクトはリージョン内で自動的に複製され冗長化されます
  • オブジェクトはチェックサムで常に監視され、破損したオブジェクトが検出された場合は自動修復されます
  • データ容量制限、オブジェクト数の制限なし
  • オブジェクトの入出力時の通信経路はSSL/TLS(https)で保護され、格納されたオブジェクトはクライアントから透過的に暗号化、複合されます

その他、ほとんどの疑問は下記のFAQで解決できると思いますので是非ご参考にされてください。

英語版 Oracle Cloud Infrastructure Object Storage FAQ
日本語版 Oracle Cloud Infrastructure Object Storage FAQ

#オブジェクトストレージとアーカイブストレージ
Oracle Cloud Infrastructure(以下OCI)では2種類のオブジェクトストレージサービスがあります。一つはオブジェクトストレージサービス、もう一つはアーカイブストレージサービスと呼んでいます。

オブジェクトストレージは下図のようにデータの格納、データの取り出しともに任意のタイミングで処理できますので、単純なデータ保存用途だけでなく、リアルタイムにデータの読み書きが必要なサービスのデータストアとしても利用可能で、結構オールマイティなサービスです。

対して、アーカイブストレージは下図のように、データの格納こそ任意のタイミングで処理できるものの、データの取り出しはすぐに処理できず、事前に「リストア」と呼んでいる処理を実行する必要があります。(その分、価格が大幅に安いということになるのですが。)従って、アクセス頻度の低いデータを安価に長期保管する目的でご利用いただくことを目的としたサービスです。

具体的には下図のように、バケット作成時に「Standard」を選択するとオブジェクトストレージ、「Archive」を選択するとアーカイブストレージのバケットができあがり、これにより該当バケットがどちらの課金体系になるかが決まります。

#アーカイブストレージの特性
アーカイブストレージを運用するにはその特性をちゃんと理解しておく必要があります。その最たるものがアーカイブストレージに格納されたオブジェクトの「ステイタスの遷移」です。

まず、アーカイブストレージにアップロードされたオブジェクトは「Archived」というステイタスとなり、このステイタスのオブジェクトは即時ダウンロードはできません。アップロード実行後、即座にこの「Archived」というステイタスになります。アップロード後、あまり時間が経っていないのですぐにダウンロードできるのでは？ということはありませんのでご注意ください。

ダウンロードするためには事前にリストア処理を実行する必要があります。リストア処理を実行すると、オブジェクトのステイタスは「Restoring」となります。このリストア処理に最大4時間かかり、この間も該当オブジェクトのダウンロードはできません。

リストア処理が完了すると、「Resotred」というステイタスになり、このタイミングでやっとダウンロード可能となります。そして、「所定の時間」を経て、再び自動的に強制的に「Archived」のステイタスに戻ります。この「所定の時間」はリストア処理実行時に1時間から240時間の間でユーザーが指定します。つまり、指定した時間内にダウンロードが完了するようにする必要があります。

また課金関連で注意すべき点として下記2つがあります。

  • リストア処理を実行し、ステイタスが「Resotred」になったオブジェクトに対してはアーカイブストレージだけでなく、オブジェクトストレージの課金が追加されます。言い換えるとこれは「リストア処理にかかる追加費用」と捉えることができます。したがって、リストア処理実行時に指定する「所定の時間」の値に気を付けましょう。「ダウンロードに何時間かかるかわからないからとりあえず最大の240時間で」というような感じで指定するとリストアデータ量によっては課金を大幅に増やしてしまいかねません。
  • 一旦、アーカイブストレージへデータアップロードすると、そのデータ量に対して最低90日は課金を止めることができません。つまりデータアップロード後、仮に一日でデータを削除したとしても、「最低90日分のお代は頂戴いたします。m(_ _)m」というものです。

以上、少し煩わしいルールが付きまとうアーカイブストレージサービスですが、このルールに沿っていただくと、非常にコスト効果の高い運用が可能になりますので是非ご利用をご検討ください。

#価格(2019/5/1現在)
オブジェクトストレージ、アーカイブストレージ利用時は下記項目が課金対象になりますのでこれらを足し算すると利用料金ということになります。

課金項目
1 　保存データ量に対する課金
2 　データ転送量に対する課金
3 　REST APIのリクエスト数に対する課金
4 　リストア処理に対する課金(アーカイブストレージのみ)

####1. 保存データ量に対する課金
単純に、オブジェクトストレージやアーカイブストレージに保存したデータ量に対して課金が発生します。下記が一月当たりかつ1GBあたりの価格になります。下記単価に容量と期間を掛け算した費用が発生します。

サービス 　 　 　　　　価格(一月あたり)　　　　
オブジェクトストレージ 3.06円/GB
アーカイブストレージ 0.312円/GB

####2. データ転送量に対する課金
インバウンドデータ転送(オラクルクラウドへデータを転送する場合)とアウトバウンドデータ転送(オラクルクラウドの外へデータを転送する場合)で価格が分かれ下記のようになります。

データ転種別 価格(一月あたり)
アウトバウンドデータ転送　 　 10TB/月まで無料、10TBを超えた場合1.02円/GB
インバウンドデータ転送 無料

アウトバウンドデータ転送が一月あたり10TBまで無料という点が非常に魅力的です。一か月あたり10TB以下で継続運用すると、データ転送に関しては全く費用がかからないことになり、非常にお得感があります。

また、更にうれしいことに、閉域網でオラクルクラウドに接続する場合は、アウトバウンドデータ転送が一か月あたり10TB以上でも無料となります。

オラクルクラウドのこのような価格体系を賢く利用していただければ、システム全体のコストを非常に安価に抑えて運用いただけると思います。

####3. REST APIのリクエスト数に対する課金
オブジェクトストレージはREST APIを使ってデータの入出力を行います。このAPIのコール数が課金対象となります。とはいえ、多くの場合、契約前にAPIのコール数を見積もることは難しいので、このコール数の課金については非常に大きな幅が設定されており、実運用で誤算があっても大きなミスにならないような課金体系になっています。具体的には下記のように10,000回単位で課金されます。

　　　　サービス　　　　 　　　　価格(一月あたり)　　　　
リクエスト数　　　 0.408円/10,000回

####4. リストア処理に対する課金(Archive Storageのみ)
上述しました通り、アーカイブストレージ上のオブジェクトに対して「リストア処理」を実行した場合、該当のオブジェクトのデータ量に対してアーカイブストレージだけでなく、オブジェクトストレージの課金が追加で発生しますので、この分を足しこむ必要があります。

なお、最新の価格は「ストレージとネットワークの価格」をご参照ください。

#代表的な使い方
オブジェクト・ストレージは基本的には非構造化データのデータストアとして利用されます。現在、ユーザーがかかえる非構造化データのデータ量は構造化データとは比べ物にならいほど増えました。数百ペタバイトという容量の非構造化データを保持している企業も少なくありません。文字通り、桁違いというやつです。この大規模なデータをいかに安く、安全に、効率よく保持するかという問題をオブジェクトストレージで解決する事例がたくさん出てきています。その代表例を見てゆきたいと思います。

まず、オブジェクトストレージに保持されるデータとしては代表的なものが下記のようなデータになります。

  • テキストデータ、画像、ビデオ、音声データなどのコンテンツリポジトリ
  • 日々のバックアップデータ
  • システムから発生するあらゆるログ・データ
  • 研究(制約試験、ゲノム分析、衝突実験などのシミュレーション)データやIoTで利用されるような大規模なデータセット

当然、これらのデータはいろんなツールからオブジェクトストレージに保存され、またいろんなツールでいろんな目的で利用されます。その、「いろいろ」の代表例が下記のようなものになります。

ベンダー製やオープンソースのツールでアーカイブ・ストレージを利用する場合は「オラクルクラウドのアーカイブストレージに対応しているかどうか」をご確認いただくことを推奨します。オブジェクトストレージを利用する場合は、S3互換APIで大抵のツールから利用できます。ですが、アーカイブストレージ利用の場合は、そのツールがデータ取り出し前の「リストア処理」に対応しているかどうかで運用の煩雑さが大きく変わります。非対応のツールの場合は自分で必要なオブジェクトを特定し、自分でリストア処理を実行する必要があるので、システムによってはオペレーションが煩雑になりますので要注意です。

###代表的な使い方 その1) クラウドへのバックアップ先として利用する
オンプレミス上もしくはクラウド上のデータをオブジェクトストレージにバックアップするユースケースです。恐らく最もよくあるユースケースだと思われます。オブジェクトストレージへバックアップすることにより、「バックアップ・リストア」と「遠隔保管」の2つの要件を同時に満たせます。

代表的なバックアップソフトウェアは以下の通りです。基本的に、Oracle Cloud Infrastructureではオラクルが他社ベンダー様のツールをサーティファイするということはありません。どちらかというとオブジェクト・ストレージは「ツールから使われる側」なので他社ベンダー様にサーティファイしていただくという立場にあります。オラクルクラウドのサポートを謳っていなくても、大抵のツールはAWS S3互換APIを利用してオラクルのオブジェクト・ストレージサービスを利用することができますので動作するものが下記だけということではありませんのでご注意ください。

Veritas Netbackup
言わずと知れたシェア・ナンバーワンのエンタープライズ向けバックアップ・ソフトウェアです。現状、アーカイブ・ストレージのリストアAPIには対応しておりませんが、オラクルクラウドのオブジェクトストレージサービスでの動作実績はあり、ちゃんと動作することは確認されています。

【参考URL】

Commvault
ガートナー社マジック・クアドラントのバックアップ・リストアのカテゴリで長年リーダーのポジションをキープされているベンダーさんです。Veritas社、Symantec社と違い、比較的新しいベンダーさんですが、インストールやオペレーションも直感的に実行でき、ドキュメントも豊富かつ分かりやすく、幅広いクラウドベンダーのサービスをサポートしており、クラウドの新機能の対応も早いです。オブジェクトストレージだけでなくアーカイブストレージのリストアAPIも早くからサポートしていただいています。

【参考URL】

その他、Commvaultはバックアップ、リストアだけでなく、オンプレミスのVMwareの仮想マシンを簡単にオラクルクラウドに移行する機能も持っています。オンプレミスのVMware仮想マシンをバックアップし、オラクルクラウドにリストアする手順を自動的にCommvaultが実行してくれるという優れものです。

Cloudberry Backup / Explorer
こちらもクラウドが利用されるようになってから認知度が高くなったベンダーさんです。非常に簡単に導入できるツールでインターフェースもユーザーフレンドリーで分かりやすいです。CommvaultやNetbackupはエンタープライズのイメージが強いですが、Cloudberryはどちらかというと簡単に、クイックに使えるバックアップソフトウェアという印象です。Cloudberry Backupというバックアップツール以外にCloudberry Explorer と呼ばれる、アップローダーのようなツールがあり、両方ともオラクルクラウドで稼働実績があります。ただし、現時点ではアーカイブストレージのリストアAPI未対応。

###代表的な使い方 その2) クラウドへのデータ同期先、災害対策システムとして利用する
クラウドへのバックアップと似ていますが、こちらはデータ同期です。バックアップソフトウェアを利用して、クラウドへバックアップを取ると、そのオブジェクトは利用しているバックアップソフトウェア固有のフォーマットになります。対して、データ同期ツールを使うと、同期元と同じディレクトリ構造やファイル・フォーマットが同期先で再現されます。(厳密にいうと、オブジェクトストレージに「ディレクトリ」という考え方はありませんが、疑似的なディレクトリを作ります。)そのため、クラウド上にオンプレミスと同じシステムを構築し、同期されたクラウド上のデータを参照できるようにすることで災害対策システムをクラウド上で実現する目的としても利用可能です。代表的なツールとしてはRcloneがあります。

Rclone
サーバー間のデータ同期ツールにrsyncという有名なツールがありますが、その兄弟分のツールです。サーバーから直接オブジェクトストレージにデータを同期(逆同期、非同期も可)できます。差分同期もできますし、並列処理用のオプションにより簡単にスループットの性能チューニングができる優れものです。現状、アーカイブストレージのリストアAPIには対応していない模様。

####バックアップソフトウェアの同期機能
Rcloneなどのデータ同期ツールだけでなく、実はバックアップソフトウェアもデータ同期機能を持っていたりします。上記にご紹介した、NetBackup、Commvault、Cloudberryともにデータ同期機能があります。バックアップソフトウェアならではのきめ細かな機能も同時に利用できるので便利な運用が可能になります。

###代表的な使い方 その3)　オラクル・データベースのバックアップ先として利用する
オラクル・データベースに、Oracle Database Cloud Backup Moduleをダウンロードして設定することで、オブジェクト・ストレージにRMANバックアップを取得することができるようになります。オブジェクト・ストレージをバックアップデバイスとして登録し、いつものようにRMANバックアップを実行するだけです。ローカルのRMANバックアップを別のツールでオブジェクトストレージにアップロードすると、そのバックアップデータはRMANのカタログからは認識できなくなりますが、このモジュールを使うと、RMANカタログでオブジェクト・ストレージへのバックアップ・リストアが完全に管理できるようになります。なお、現時点ではこのモジュールはアーカイブ・ストレージのリストアAPIには対応しておりません。

【参考URL】

###代表的な使い方 その4)　オラクル・データベースのクラウド・サービスの外部表として利用する
CSVやParquetファイルなどをオブジェクトストレージ上に配置し、専用のパッケージ(DBMS_CLOUDやDBMS_CLOUD_ADMIN)で外部表として定義できます。データ変換などの処理をオブジェクトストレージ上で行い、返還後のオブジェクトをそのまま外部表として利用することができ、非常にスマートなシステムが構築できます。

【参考URL】

###代表的な使い方 その5)　ビッグデータ分析システムのデータストアとして利用する
従来のストレージやIAサーバーを並べたHadoopの構成は、日々のHW障害対応や拡張作業の運用作業コストが極めて高く、対応が限界に達しているユーザーも少なくないと思います。このような分析システムのデータストアをオブジェクトストレージサービスに切り替えることで、日々の運用の一部をクラウドにオフロードすることができます。

MapReduceやSparkのジョブ実行用のデータストアとして
先ほどのデータベースの外部表の利用例と似ていますが、MapReduceやSparkのジョブ(ETL処理や分析処理など)をオブジェクト・ストレージ上のデータに対して直接実行することができます。後述するHDFS Connectorを利用することでこのような構成が可能になります。この構成により、従来のHadoopクラスタやSparkクラスタのデータストア部分はオブジェクト・ストレージサービスに置き換えられ、煩わしいデータストアの運用から解放されます。

【参考URL】

データレイクとして
ストリーミングデータの分析処理システムの中でよく使われるツール Kafka をオブジェクトストレージの前段に配置し、オブジェクトストレージそのものをデータレイクとして運用する構成ができるようになります。オブジェクト数無制限、容量無制限、あらゆるツールと連携できるオブジェクトストレージはビッグデータの分析システムとは非常に相性がいいです。データを貯め、変換し、分析するためのデータ配置をオブジェクト・ストレージ中心にすると各ツール間のデータの移動も少なくなり、非常にスマートなアーキテクチャとなります。

【参考URL】

###代表的な使い方その6) NFSとして利用する
オブジェクト・ストレージ・サービスは基本的にはREST APIを使って、入出力をコーディングする必要があるデータストアです。「単純にファイルを読み書きしたいだけなんだけど」という方には少々面倒と感じられるかもしれません。POSIXベースのファイルシステムのように、OSにマウントしてOSコマンドやマウス操作でオブジェクト・ストレージにデータを保存したり取り出したりできるツールをご提供しています。これらのツールを使うと、オブジェクトストレージをNFSとして利用できるようになり、面倒なREST APIから解放されます。

Storage Gateway
オラクルが提供するソフトウェアです。オンプレミスのサーバーやオラクルクラウドのComputeインスタンスに設定すると、このサーバーがNFSサーバーのように稼働します。別のサーバーや、ComputeインスタンスがNFSクライアントとなり、NFSサーバーとしてマウントしNFS領域にデータを読み書きすると、自動的にオブジェクトストレージに読み書きされるという挙動になります。このソフトウェアはdocker imageとなっており、インストールするサーバー(もしくはComputeインスタンス)にdocker環境を構築する必要があります。

【参考URL】

#Identity and Access Management(IAM)によるアクセス制御
OCIのクライアントアプリケーションは、予めOCIに作成したIAMユーザーを使ってOCI内のリソースへのアクセスや操作を行います。

クライアントアプリケーションから操作要求がくると、IAMは接続ユーザーの認証を行います。これは公開鍵暗号方式によって行われます。つまり事前に作成したか鍵ペアの秘密鍵をクライアント側に、公開鍵をOCI側に登録し、この鍵ペアのマッチングで認証が行われます。認証が通ると、このIAMユーザーは、事前に作成されたIAMポリシーで許されている権限の範囲内で、OCIのリソースへの操作が実行できます。

例えば、オブジェクトストレージの場合でいうと、オブジェクトの読み込みしかできないのか？書き込みまでできるのか？バケットの作成まで許すのか？といったようないろいろな権限をIAMポリシーで設定し、アクセスコントロールを行います。アクセスコントロールの詳細は下記マニュアルをご参照ください。オブジェクト・ストレージに関する代表的なIAMポリシーを確認できます。

代表的なポリシーだけでなく、オブジェクト・ストレージに関するIAMポリシーの設定体系はマニュアルの下記から参照できます。

IAMはオブジェクト・ストレージだけでなく、オラクル・クラウドの全サービスに関係しますので全体をきちんと理解しておきたいという場合は、下記IAMのマニュアルを見ていただいたほうがよいかと思います。

【参考URL】

#Pre-Authentication Request(PAR)
オブジェクトストレージの操作はIAMユーザーを使って行われますと上述しましたが、この機能を使うと、IAMユーザーアカウントを取得していない人でもオブジェクトやバケットを利用できるようにすることができます。つまり、自分が作成したバケットやオブジェクトを他人(もしくはプログラム)に共有したい場合に設定する機能です。

もちろん、この設定自体は、対象のバケット、オブジェクトへのアクセス権をもっているIAMユーザーで設定する必要があります。また、設定を実行するユーザーがもっていないアクセス権をその他の人に許可することは当然できません。つまり読み取り権限しかないIAMユーザーで書き込み権限まで許されるPARの設定はできないということになります。

下図のように、この機能を設定すると最終的に対象のバケットやオブジェクトにたいするアクセス用URLが取得できます。そのアクセス用URLを共有したいユーザー(やプログラム)に渡し対象のバケット、オブジェクトにアクセスできるようにするというものです。

セキュリティのため本機能設定時にはURLの有効期限(Expiration Date)設定が必須となります。また、設定できる項目は対象がバケットとオブジェクトで以下のように異なります。

  • バケットに設定する場合
    • 書き込み処理のみ(※読み込み処理はできません)
  • オブジェクト
    • 読み込み処理のみ
    • 書き込み処理のみ(※読み込み処理はできません)
    • 読み込み処理と書き込み処理の両方

書き込み権限と読み込み権限が明確にわけられているのでご注意ください。書き込み権限をつけると自動的に読み込みまでできるというようなアクセス体系にはなっていません。

【参考URL】

#Public Bucket
任意のバケットをパブリックに公開する設定です。本設定により不特定多数のユーザーが対象バケットの読み取り処理が行えるようになります。※バケットへの書き込みはできません。本機能設定時にバケット内のオブジェクトをリストする機能を有効にするオプションが選べます。(デフォルトはリスト不可です。)バケット作成後、任意のタイミングで対象バケットの属性をパブリックに変更するだけです。また任意のタイミングでデフォルトのプライベートバケットに戻せます。

Public Bucketに実行可能な処理としては下記3つです。(基本的には参照系のみの処理)

  • オブジェクト・メタデータの取得
  • オブジェクトのダウンロード
  • Bucket内のオブジェクトの一覧表示(オプション)

ユースケースとしては、対象バケット内のオブジェクト全てを広い範囲のユーザーに共有したい場合に利用可能です。悪意のあるユーザーがURLを推測してアクセスすることが可能な機能ですのですのでシステム要件を見極めて十分に注意しご利用いただく必要があります。

前出のPre-authentication Requestとの使い分けがよくわからないという方は下記比較表を参考にしてください。

【参考URL】

#互換API
オブジェクト・ストレージに限らず、クラウド環境のオペレーションはもっぱらREST APIを使います。世の中にはたくさんのクラウドベンダーがありますが、どのベンダーも基本的には自社ネイティブのREST APIと、互換APIを使えるようにしています。オラクルクラウドのオブジェクト・ストレージ・サービスでご利用いただけるREST APIは下記3つになります。

  • OCIネイティブAPI(Oracle Cloud Infrastructureの全ての仕組みが利用可能なAPIです。)
  • Amazon S3互換API(Amazon S3のAPIと互換性のあるAPIです。S3の全てのリクエストメソッドが使えるわけではありません。オラクルクラウドに実装されていないS3の仕組みや機能に関係するリクエストメソッドは使えません。また、オラクルクラウドにあって、S3にない仕組みや機能に関するリクエストメソッドも使えません。)
  • OpenStack Swift互換API(S3互換API同様の制約のあるAPIです。)

より詳細な互換性の注意点については下記マニュアルをご参照ください。

オープンソースやベンダーが開発したツールを使う場合は大抵 Amazon S3互換APIを使うことになります。OCIネイティブAPIをご利用いただきたいところなのですが、2019年4月現在、世の中のほとんどのツールはOCIネイティブAPIには対応しておらず、残りの2つのどちらかを使うしかありません。

僕が知っている範囲で言うと、OCIネイティブAPIに対応しているツールは下記2つくらいです。

  • OCICLI(オラクルが開発、提供しているCLIツール。プロビジョニングが主目的のツールですがオブジェクトストレージへのアップロード、ダウンロードなども可能です。)
  • COMMVAULT社のバックアップツール(ガートナー社のマジック・クアドラントでも長年に渡ってリーダーにポジショニングされるバックアップソフトウェアです。)

OCIネイティブAPIを使っていただくと、OCIの全ての機能が利用可能ですし、最大性能を求める場合は他のAPIと比較して有利なのでツール開発ベンダーさんの対応が待ち遠しい限りです。

対して、ユーザーが自分でAPIを選べる場合もあります。REST APIやSDKを使って自分でコードを書く場合などがこれに相当します。この場合は上述の理由から迷わず、OCIネイティブのAPIをご利用いただきたいところです。

#Multipart Upload
大きいサイズのファイルをオブジェクトストレージにアップロードする際に、その性能を向上させる仕組みです。ラージファイルを複数のパーツに区切って、並列にアップロードし、オブジェクトストレージ側でその複数のパーツをまた一つのオブジェクトに合体するという処理になります。この並列処理によりアップロード、ダウンロードのスループットが向上します。

クライアントツールを使う場合、マルチパート処理が実行されるかどうかはそのクライアントツールに依存します。マルチパート処理が実装されていないツールでは当然この処理は行われず、性能を求めることは難しくなります。オラクルのCLIツールであるocicliのアップロード機能はマルチパートに対応しており、簡単なコマンドで実行できます。

対して、REST APIやSDKを使う場合は上記の処理フローを自分でコーディングしてゆくことになります。少々面倒ですが、SDKを使われる場合は、マルチパート用のサンプルスクリプトが附属していますので参考にしていただけると思います。

なお、マルチパート処理を実行するということは、多数のスレッドを並列実行することになりますので、必然CPU使用率が上がりますのでご注意ください。

【参考URL】

#WORM(Write Onece Read Many)
WORMコンプライアンス対応のための機能です。IAMポリシーの設定で格納済オブジェクトの改ざんを防止します。具体的にはオブジェクトの上書き(IAMポリシーのOBJECT_OVERWRITE)とオブジェクトの削除(OBJECT_DELETE)の2つの処理を実行不能にすることでWORMを実装します。長期保管データに適用が義務付けられるケースが多いためArchive Storage利用時にご利用を検討いただくとよいと思います。

【参考URL】

#Object Lifecycle Management
事前に設定したルールに基づき、Standard Bucketから、より安価なArchive Bucketへオブジェクトを移動したり、削除したりする処理を自動化します。つまり、オブジェクトのライフサイクルを管理することによりストレージサービスのトータルコストを削減する機能です。

ルール作成はバケットに対して下記の設定を行います。

  • 対象のバケットと実行処理内容
  • Standard Bucketを選択した場合、Archiveへの移動か削除が可能
  • Archive Bucketを選択した場合、削除のみ
  • 経過日数(一日単位)
  • オブジェクト名の条件(プリフィックスやパターンマッチングによる条件)

設定例としては下図のように、Standard Bucketに作成されたオブジェクトが30日経過後にArchiveされ90日後にオブジェクトが削除されるというような処理を自動実行することができます。

【参考URL】

#Cross Region Copy
任意のオブジェクトを別のバケットにコピーする機能です。異なるテナント、異なるリージョン、異なるコンパートメントのバケットへのコピーが可能です。下記のようなダイアログでコピー先のバケット、コピー処理のルール(コピー先に同じオブジェクトがあった場合には上書きするしないなど)などを設定します。

現時点では自動コピーのようなことはできず、手動でこのコピー処理を設定します。そして、その設定のタイミングとは非同期で指定したバケットにオブジェクトがコピーされます。したがって、本設定自体は”コピー処理を予約する”というイメージになります。たいていの場合、設定後、すぐにコピー処理が実行されますし、コピー処理自体のステイタスもモニタすることができます。

【参考URL】

#HDFS Connector
HadoopおよびSparkのジョブから直接オブジェクトストレージへデータの入出力を行えるようにするための機能です。オブジェクトストレージへのアクセス処理は、通常REST APIを使って入出力処理のコードを書く必要があり、これがまたなかなか面倒です。このHDFS Connectorと呼んでいるモジュール(githubからダウンロードできます。JARライブラリファイルです。)を使うことで、HadoopやSparkジョブのコードにオブジェクトストレージのネームスペースを埋め込むことができるようになります。

例えば、Sparkジョブからオブジェクトストレージ上のtest.txtというオブジェクトを読み込む場合、HDFS Connectorを使うと、下記のように「oci://...」という記述でオブジェクトストレージのネームスペースを表現することができます。これはちょうど、HDFSのネームスペースを「hdfs://...」と表現するのと似ています。

val text_file = sc.textFile("oci://<bucket_name>@<tenant_name>/test.txt")

もちろん内部的には、このHDFS ConnectorがREST APIの処理を代行してくれているということになります。この例からコードの可読性向上やコード量の削減をメリットに感じていただけると思いますがそれは副次的なものです。HadoopやSparkを利用する際、そのデータストアを構築する選択肢として従来のブロックストレージだけでなく、より安価なオブジェクトストレージも利用可能だという点にも着目していただければと思います。

【参考URL】

#Object Storage Metrics
Object Storage Metricsを使ってオブジェクトストレージの下記3つの属性を監視できます。また、REST APIやSDKで監視したいメトリックを開発し、カスタムメトリックとして定義することも可能です。

  • 使用容量
  • オブジェクト数
  • マルチパートアップロードの未完了パーツの容量

利用容量とオブジェクト数については対象のバケットの画面でMetricがグラフ化されており、マルチパートアップロードの未完了パーツの容量はメトリックエクスプローラーで確認が可能です。

アラーム機能でしきい値を設定し、その値を超えた場合には、Oracle Notificationsに登録したメールアドレスやPagerDutyへ通知することも可能です。

【参考URL】

#SDK
OCI用にアプリケーションを簡単に開発していただけるよう下記各言語で使えるSDKを提供しています。いずれのSDKもサンプルコードが同梱されていますので是非ご参考にしていただければと思います。

  • Java SDK
  • Python SDK
  • Ruby SDK
  • Go SDK

【参考URL】

#ドキュメント

21
14
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
21
14

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?