OCI入門 Vol5 ストレージ入門 ブロック(VPU)・オブジェクト(3Tier)・ファイル(NFS)

1. この記事について — OCIの3種のストレージを深掘りする

1-1. 本記事のゴール

本記事を読み終えると、次の4つができるようになります。

• OCIの3種のストレージ(ブロックボリューム・オブジェクトストレージ・ファイルストレージ)の特性を理解し、用途に応じて最適な1つを選べるようになる
• ブロックボリュームのVPU(Volume Performance Units)Tierを見積もり、パフォーマンス要件とコストのバランスを取った設計ができるようになる
• オブジェクトストレージのライフサイクルポリシーとAuto-Tieringを使い分け、保存コストを自動的に最適化できるようになる
• ファイルストレージ(NFS)がどのような場面で必要になるかを、ブロック・オブジェクトとの違いから判断できるようになる

これら4点は、単独の知識としてではなく、実際のシステム設計の場面で「なぜその選択をするのか」を説明できる形で身につけることを狙っています。OCIのストレージサービスは一見するとAWSの構成と似ていますが、内部の設計思想は異なっており、表面的な機能名の暗記だけでは実務の判断に耐えられません。

たとえば、社内向けの分析基盤を新たに構築する場面を想定してみましょう。集計処理を行うデータベースには低レイテンシで書き込めるストレージが必要になり、収集したアクセスログの長期保管には低コストなアーカイブ機能が欲しくなり、複数のバッチ処理サーバーから同じ設定ファイルや共有ライブラリを参照したい場面も出てきます。これは典型的に、ブロックボリューム(データベース用)・オブジェクトストレージ(ログのアーカイブ用)・ファイルストレージ(設定共有用)の3つを組み合わせて設計する構成であり、本記事で扱う判断軸がそのまま生きる場面です。

具体的な成果物イメージとしては、次の2つの操作を、設計判断の根拠とともに理解できる状態を目指します。

第一の成果物イメージは、コンソール上でブロックボリュームを作成し、既存のコンピュート・インスタンスにアタッチする一連の操作です。この際、Balanced(既定のVPU Tier)のままでよいのか、それとも用途に応じてTierを変更すべきかを判断できるようになります。OCI CLIを使う場合は、oci bv volume create --availability-domain <AD名> --compartment-id <OCID> --size-in-gbs 100 --vpus-per-gb 10のようなコマンドでブロックボリュームを作成できます。

第二の成果物イメージは、オブジェクトストレージでバケットを作成し、「作成から14日でInfrequent Accessへ、90日でArchiveへ」といったライフサイクルルールを設定する操作です。アクセス頻度が読めないデータについては、ライフサイクルポリシーではなくAuto-Tieringを選ぶべき場面があることも理解できるようになります。CLIではoci os bucket create --compartment-id <OCID> --name <バケット名>でバケットを作成し、oci os object-lifecycle-policy putでライフサイクルルールを登録する流れになります。

単なる機能一覧の暗記ではなく、目の前のワークロードに対して「ブロックかオブジェクトかファイルか」「どのTierか」を自分の言葉で説明し、根拠を持って選択できることが本記事全体のゴールです。次章以降では、ブロックボリューム・オブジェクトストレージ・ファイルストレージをそれぞれ深掘りしたうえで、3種の使い分けとコスト設計・データ保護まで一気通貫で扱います。

OCIの学習コンテンツの多くは、機能そのものの紹介にとどまりがちです。本記事では、各章で①使い分けの判断根拠、②具体的な設計・ハンズオン例、③実務でつまずきやすい落とし穴、④AWSとの対比という4点を欠かさず盛り込むことで、読み終えてすぐに実務の設計判断に使える内容を目指しています。

本記事を読み終えた際の到達度を、簡単なチェックリストで確認してみてください。

• ブロックボリュームのVPU Tierを、用途に応じて4段階から選べる
• オブジェクトストレージのTierとライフサイクルルールを設計できる
• ファイルストレージが必要な場面を、ブロック・オブジェクトと比較して判断できる
• AWSのEBS/S3/EFSとの設計思想の違いを、他者に説明できる

これらの達成度は、8章のまとめでも改めて振り返ります。

判断に迷ったときは、まずこのチェックリストに立ち返ってください。

1-2. 読者像

想定読者は、AWSでEBS(Elastic Block Store)・S3(Simple Storage Service)・EFS(Elastic File System)を実務で使った経験があり、OCI(Oracle Cloud Infrastructure)のストレージサービスにはまだ触れたことがないクラウド実務者です。具体的には、次のような役割の方を想定しています。

• インフラ担当者・SRE — マルチクラウド構成やコスト最適化のためにOCIストレージの設計判断が必要になった方
• バックエンド開発リーダー — OCI移行プロジェクトでストレージ選定の意思決定を任された方
• クラウドアーキテクト — AWSとOCIを比較検討し、提案資料に落とし込む必要がある方

前提知識としては、Vol1〜3で扱ったテナンシ・コンパートメント・IAM・VCNの基礎、およびVol4で扱うコンピュートの基礎知識を読了済み、または同等の知識をお持ちであることを前提とします。これらの基礎(コンパートメント設計・IAMポリシーの文法・VCNのサブネット構成など)は本記事では再説明しません。同様に、コンピュート・インスタンスの形状選定やベアメタルとVMの違いといったコンピュート固有の話題もVol4の範囲であり、本記事では扱いません。

AWS経験者がOCIのストレージに初めて触れたとき、次のような戸惑いに直面しがちです。

• ブロックボリュームのパフォーマンスを決める「VPU」という聞き慣れない単位が何を意味するのか分からない
• オブジェクトストレージの3 Tierが、S3のStandard・Standard-IA・Glacier系とどう対応するのか整理できない
• ファイルストレージがEFSと同じNFSベースだと聞いても、料金体系やマウント手順の勘所が掴めない
• OCI固有の用語(コンパートメント、ネームスペース、可用性ドメイン)がストレージのドキュメントにも頻出し、AWSの用語感覚のまま読むと混乱する

本記事は、これらの戸惑いを1つずつ、AWSとの対比を軸にしながら解消していきます。

もし上記の前提知識に不安がある場合は、Vol1(テナンシ・コンパートメント)とVol3(VCN)を先に読むことをおすすめします。特にVol3で扱うVCN・サブネットの構成は、後述のファイルストレージのマウントターゲットの理解に直結します。

本記事を効率よく読み進めるためのヒントです。

• すでに使うストレージ種別が決まっている場合は、該当する種別を深掘りする章から読み進めても支障ない
• まだ判断がついていない場合は、判断軸を扱う章を先に読んでから該当章に戻るとよい
• AWSとの対比を優先して知りたい場合は、各章の「AWS対比」の記述を先に拾い読みするのも有効

1-3. シリーズでの位置づけ — Vol1〜4からストレージへ

Vol1では、OCIのテナンシ・コンパートメント・リージョンといった土台となる概念とAlways Freeの枠組みを扱いました。Vol2では、IAM Identity Domains・ポリシー・動的グループといったアクセス制御の仕組みを扱いました。Vol3では、VCN・サブネット・ゲートウェイ・セキュリティといったネットワーキングの基礎を扱いました。近日公開予定のVol4では、コンピュート(VMインスタンスの形状・ベアメタル・Always Free枠)を扱う予定です。

本Vol5は、これらテナンシ・IAM・ネットワーキング・コンピュートという「土台」の上に乗る、ストレージ専任の巻です。ブロックボリュームはコンピュート・インスタンスにアタッチして使うものであるため、Vol4のコンピュートと密接な関係にありますが、本記事ではコンピュートそのものの詳細(VMの形状選定など)には立ち入りません。あくまでストレージ側の設計判断に焦点を絞ります。

具体的には、「テナンシとコンパートメントの構造(Vol1)」「コンパートメントへのアクセスを制御するIAMポリシー(Vol2)」「VCNとサブネットによるネットワーク到達性(Vol3)」までが整っていることを前提に、ストレージそのものの選定・設計・運用に的を絞って解説します。ネットワーク到達性は特に重要で、後述のファイルストレージのマウントターゲットは、Vol3で構築したVCN・サブネットの上に配置される点を押さえておいてください。

逆に、本記事の範囲外となるのは、コンピュート・インスタンスの形状選定やOSレベルのチューニング(Vol4の範囲)、およびコンパートメント設計そのもの(Vol1の範囲)です。ストレージの性能や耐久性の設計に集中するため、これらの話題に立ち入る場合はVol1・Vol4を参照してください。

シリーズ全体は6本構成で、最終のVol6ではOKE(マネージドKubernetes)を扱う予定であり、本Vol5で扱うブロックボリュームは永続ボリュームとしてVol6にも関連してきます。各巻と本Vol5の関係を整理すると、次のようになります。

なお、Vol4の公開後は、本記事内のVol4関連リンクを実際のURLに差し替える予定です。それまでは「近日公開」の表記のまま読み進めてください。

1-4. AWS EBS/S3/EFSユーザーの読みどころ

AWSでストレージを使ってきた方であれば、OCIの3種のストレージは次のように対応づけて理解すると入りやすくなります。ブロックボリュームはEBS、オブジェクトストレージはS3、ファイルストレージはEFSに、それぞれ発想がほぼ対応します。

ただし、対応する概念があるからといって仕様まで同じというわけではありません。特に注意したいのが、ブロックボリュームのパフォーマンス設計です。EBSではgp3ボリュームでIOPSとスループットを個別に指定したり、io2でIOPS要件を厳密に満たしたりしますが、OCIのブロックボリュームでは「VPU(Volume Performance Units)」という単位をボリュームサイズ(GB)に対して設定することで、IOPSとスループットの両方が決まる仕組みになっています。この設計思想の違いを序盤でしっかり押さえておくことが、後続の章の理解を大きく助けます。

本記事では、AWSとの対比を次のような切り口で随所に織り込みます。

• ブロックボリューム — VPU TierとEBSのgp2/gp3/io2の設計思想の違い
• オブジェクトストレージ — 3 TierとS3の各クラス、ライフサイクル・Auto-TieringとS3 Lifecycle・Intelligent-Tieringの対比
• ファイルストレージ — NFSの課金モデルとEFSのスループットモード・課金の違い
• コスト構造全体 — 3種の課金要素とEBS/S3/EFSの料金体系の対応関係

これらの対比は単なる用語の言い換えではなく、「AWSでこう設計していたものを、OCIではどう考え直す必要があるか」という移行・併用の実務判断に直結する内容です。各章で具体的に示していきます。

AWSからOCIへの移行プロジェクトでは、次のような誤解が典型的なつまずきポイントになります。

• 「EBSのgp3と同じ感覚でVPUを決めればよい」と考え、ボリュームサイズとVPU/GBの掛け算という設計の違いを見落とす
• 「S3のライフサイクルルールをそのままオブジェクトストレージに移植すればよい」と考え、Archiveの復元時間や最小保存期間の違いを見落とす
• 「EFSと同じ感覚でファイルストレージの料金を見積もる」と考え、課金体系の違いを見落とす

本記事を通読することで、これらの誤解を移行プロジェクトの前に解消できます。

この対応表は、各章で扱うAWS対比の入り口として活用してください。詳細な数値やAPIの違いは、それぞれの章で具体的に解説します。

← Vol4(OCIコンピュート入門)を読む

2. OCIストレージの全体像 — ブロック・オブジェクト・ファイルの3系統

2-1. 3種のストレージ — ブロック/オブジェクト/ファイル

OCIが提供するストレージサービスは、アクセス方式の観点から大きく3種類に分類されます。

ブロックボリュームは、OS側からは通常のディスク(ブロックデバイス)として認識されるストレージです。基本的に1つのコンピュート・インスタンスにアタッチして使うもので、複数インスタンスからの同時共有は限定的な用途に限られます。オブジェクトストレージは、HTTP/S経由のAPI(RESTベース)でアクセスするストレージです。バケットの中でオブジェクトとして保存し、容量の上限を意識せず無制限にスケールする設計です。ファイルストレージは、NFS(Network File System)プロトコルを使い、複数のコンピュート・インスタンスから同時にマウントして共有できるストレージです。

この3種類は、AWSの主要ストレージサービスとほぼ1対1で対応します。

代表的なユースケースも整理しておきます。

• ブロックボリューム — データベースのデータ/ログ領域、OSのブートディスク、低レイテンシが必要なアプリケーションのローカルストレージ
• オブジェクトストレージ — 静的Webアセットの配信、ログ・バックアップの長期保管、データレイクの格納先
• ファイルストレージ — 複数サーバーでの共有設定ファイル、コンテンツ管理システムのメディア領域、HPCクラスターの共有作業領域

AWSでの経験がそのままOCIの理解に生かせる部分が多い一方、内部の設計(パフォーマンス単位やTier構成)には差があります。

ストレージ間の技術的な違いを、接続・プロトコルの観点でも整理しておきます。

• ブロックボリューム(iSCSI接続) — 追加のOS側設定が必要な代わりに高いIOPS性能を引き出せる
• ブロックボリューム(パラバーチャライズ接続) — 設定は簡単だが性能上限がやや低い
• オブジェクトストレージ — OCI独自のREST APIに加えてAmazon S3互換APIも提供しており、既存のS3クライアントを流用できる場合がある
• ファイルストレージ — NFSv3プロトコルに対応し、NLM(Network Lock Manager)によるファイルロックもサポートする

暗号化についても3種で考え方が共通しています。

• ブロックボリューム — 既定でOracle管理キーによる保管時暗号化(encryption at rest)が有効
• オブジェクトストレージ — 既定でOracle管理キーによる保管時暗号化が有効
• ファイルストレージ — 既定でOracle管理キーによる保管時暗号化が有効
• 3種共通 — より厳格な鍵管理が必要な場合は、OCI Vaultの顧客管理キー(Customer-Managed Keys)に切り替え可能

補足として、オブジェクトストレージのバケット名は、テナンシごとに割り当てられる一意の名前空間(namespace)の中でユニークである必要があります。

また、「ブロックボリューム」という分類には、OSの起動ディスクとして使う「ブートボリューム」と、追加のデータ領域として使う「ブロックボリューム(狭義)」の2種類が含まれます。両者は技術的にはほぼ同じ仕組みですが、ブートボリュームはインスタンス作成時に自動的に用意される点が異なります。

ネットワーク到達性の観点でも違いがあります。

• ブロックボリューム — コンピュート・インスタンスに直結するため、通常は追加のネットワーク設計が不要
• オブジェクトストレージ — 既定はパブリックエンドポイント経由のアクセスだが、Service Gatewayを使えばVCN内からインターネットを経由せずプライベートにアクセスできる
• ファイルストレージ — マウントターゲットはVCN内のプライベートIPのみで提供され、パブリックアクセスの経路は存在しない

アクセス許可の管理方式にも触れておきます。OCIのIAMポリシーでは、これら3種のストレージへのアクセス許可がコンパートメント単位で一元管理されます。個別のバケットポリシーやボリューム単位のACLに頼るのではなく、IAMポリシーが最上位の許可レイヤーとなる点は、AWSのIAMポリシーとリソースベースポリシー(バケットポリシー等)を併用する二重構造とは考え方が異なります。

コストの全体感を早期に掴みたい場合は、OCIコンソールの「Cost Analysis」画面で、ストレージ種別ごとの現在の使用量・課金額を分解して確認できます。

以降の3〜5章では、この3種類それぞれをさらに深掘りし、具体的な設計判断とAWSとの対比を続けます。

2-2. 選定の4つの軸 — アクセス方式・性能・コスト・頻度

3種のストレージのどれを選ぶかは、次の4つの軸で整理すると判断しやすくなります。

• アクセスパターン — 単一インスタンスからの排他的なアクセスが前提ならブロック、複数インスタンスからの共有アクセスが必要ならファイル、HTTP/S経由でアプリケーションやサービスからアクセスするならオブジェクトが候補になる
• パフォーマンス要件 — 低レイテンシで高IOPSが必要な処理(データベースなど)にはブロックが向き、大容量データの保管や配信にはオブジェクトが向く
• コスト — オブジェクトストレージはTierとライフサイクルポリシーを組み合わせることで、アクセス頻度が低いデータの保存コストを大きく下げられる
• 耐久性とアクセス頻度 — 頻繁にアクセスするホットなデータか、長期保管が目的のコールドなデータかによって最適な選択が変わる

これら4軸は独立ではなく、互いにトレードオフの関係にあります。たとえば、アクセス頻度が低いデータをブロックボリュームに置き続けると、Balanced以上のVPU課金がかかり続ける一方で実際の性能はほとんど使われない、という無駄が生じます。逆に、頻繁に読み書きするデータをArchiveに置いてしまうと、復元のたびに待ち時間と取り出し手数料が発生します。「今どのくらいの頻度でアクセスされるデータか」を最初に見積もることが、4軸すべての判断の出発点になります。

4つの軸を実際のワークロードに当てはめると、次のような判断になります。

• 社内システムのRDBMS — アクセスパターンは単一インスタンス、パフォーマンス要件は高い → ブロックボリューム(Higher Performance以上)
• Webサイトの画像・動画配信 — アクセスパターンはHTTP/S API、アクセス頻度はホット → オブジェクトストレージ(Standard)
• 複数のバッチサーバーで共有する設定ファイル — アクセスパターンは複数共有、パフォーマンス要件は中程度 → ファイルストレージ
• 監査ログの長期保管 — アクセス頻度は低くコスト最優先 → オブジェクトストレージ(ライフサイクルでArchiveへ)

見積もりだけでなく、稼働後のモニタリングで判断を継続的に見直すことも重要です。

• ブロックボリューム — VolumeReadOps・VolumeWriteOpsなどのIOPSメトリクスをOCI Monitoringで確認する
• オブジェクトストレージ — リクエスト数・レイテンシのメトリクスを確認する
• 4軸の判断 — 実測値をもとに、定期的にTier・ライフサイクル設定を見直す

実務では、4軸のうち複数が同時に当てはまるケースも珍しくありません。たとえば「高頻度アクセスかつコスト感度が高い」といったトレードオフが競合する場合は、後述の「3種の使い分け」の章で扱う典型シナリオを参考に、どの軸を優先するかをチーム内で明確にしておくことをおすすめします。

軸の優先順位に迷う場合は、まずアクセスパターン(単一・共有・API)で大分類し、次にコスト、最後にパフォーマンスで微調整する、という順序がチームの合意形成には有効です。

判断の出発点として、次のような具体的な数値を最初に洗い出しておくと、以降の設計がぶれません。

• レイテンシ要件 — ミリ秒単位で必要か、秒単位で許容できるか
• スループット要件 — MB/s単位でどれだけ必要か
• 月間アクセス回数 — 数百回程度か、数百万回に達するか
• 保存期間 — 数日か、数年単位の長期保管か

逆に、次のようなアンチパターンには注意してください。

• 性質の異なるワークロード(ログとDBなど)を1つのボリュームに混在させ、パフォーマンス要件の見積もりを複雑にする
• 「とりあえずStandard/Balancedにしておけばよい」と思考停止し、コスト最適化の機会を逃す

この4軸を使った詳細な判断ロジックは、後述の「3種の使い分け」の章で具体的なシナリオとともに扱います。本章ではまず、判断軸の全体像を押さえておいてください。

2-3. VPUとは — ブロック固有のパフォーマンス単位(AWS EBSとの違い)

ブロックボリュームのパフォーマンスは、VPU(Volume Performance Units)という単位によって決まります。VPUはボリュームサイズ(GB)に対して設定する値で、VPU/GBの値が大きいほど、そのボリュームで得られるIOPSとスループットが向上します。VPU Tierには、Lower Cost(0 VPU/GB)・Balanced(10 VPU/GB、既定)・Higher Performance(20 VPU/GB)・Ultra High Performance(30〜120 VPU/GBを10刻みで指定)の4段階があります。

ここで重要なのがAWSとの設計思想の違いです。EBSのgp3ボリュームでは、ベースラインのIOPS・スループットに加えて、必要に応じてIOPSとスループットを個別に(容量とは切り離して)追加購入できます。io2ではさらに厳密なIOPS要件を満たす設計が可能です。一方、OCIのブロックボリュームでは、IOPSとスループットを個別に指定できず、VPU/GBという1つの値がボリュームサイズと掛け合わされることで、IOPSとスループットの両方が連動して決まります。つまり、同じVPU Tierでも、ボリュームサイズが小さいと得られる性能も低くなるという点に注意が必要です。

★落とし穴として特に強調したいのが、このVPUという概念はブロックボリューム固有のものであり、オブジェクトストレージやファイルストレージには存在しないという点です。オブジェクトストレージのパフォーマンスはTier(Standard・Infrequent Access・Archive)によって、ファイルストレージのパフォーマンスはマウントターゲットの設計によって決まるのであって、VPUという単位で性能を調整する対象ではありません。この違いを理解せずに「OCIのストレージ全般をVPUで最適化しよう」と考えてしまうと、設計の初期段階でつまずくことになります。

具体例で確認してみましょう。100GBのボリュームをBalanced(10 VPU/GB)で作成した場合、IOPS/GBは60であるため、理論上の上限は約6,000 IOPSです。同じ100GBのボリュームをHigher Performance(20 VPU/GB)に引き上げると、IOPS/GBは75まで上がり、理論上の上限は約7,500 IOPSまで伸びます。ボリュームサイズを大きくせずに性能だけを引き上げたい場合は、このようにVPU Tierを上げることで対応します。逆に、大容量だが低頻度アクセスのボリューム(バックアップの一時展開先など)であれば、Lower Costを選んでコストを抑える判断も有効です。VPU Tierの詳細な選定基準は、後述の「ブロックボリューム」の章でさらに深掘りします。

VPU Tier選定にあたっては、次の制約も押さえておく必要があります。

• Lower Cost(0 VPU/GB)はブートボリュームには選択できず、データボリューム専用のTierである
• Ultra High Performance(30 VPU/GB以上)を利用するには、インスタンス側でマルチパス対応の接続を有効にする必要がある
• ボリュームには、瞬間的な高負荷時にTierを一時的に引き上げる「オートチューン(自動チューニング)パフォーマンス」機能もあり、負荷が収まると元のTierへ自動的に戻る

参考として、代表的なボリュームサイズごとの理論上のIOPS上限(Balanced Tier、IOPS/GB=60)を示します。

Max IOPS/VolumeはTierごとに上限(Balancedは25,000)が設定されているため、ボリュームサイズを大きくしても、この上限を超えて性能が伸び続けるわけではない点に注意してください。

Balanced(10 VPU/GB)を超える範囲では、次の計算式でIOPS/GBとスループットを概算できます。

• IOPS/GB = 1.5 × VPU/GB + 45
• Max IOPS/Volume = 2,500 × VPU/GB
• KBPS/GB = 12 × VPU/GB + 360
• Max MBPS/Volume = 20 × VPU/GB + 280

たとえばUltra High Performanceで60 VPU/GBを選んだ場合、IOPS/GBは135、Max IOPS/Volumeは150,000という計算になります。実際の要件をこの式に当てはめて概算してから、Tierを選ぶと精度が上がります。

IOPS要件が特に高いデータベースワークロードでは、単一の巨大なボリュームでVPU Tierを引き上げるだけでなく、複数のボリュームをOS側でストライピング(LVM等)して束ねる構成も選択肢になります。

★落とし穴: ボリュームはインスタンスからデタッチしていても、削除しない限り容量課金は継続します。不要になったボリュームは早めに削除するか、バックアップを取ってから削除する運用を徹底してください。

2-4. 耐久性とデータ保護 — 概観

3種のストレージは、それぞれ異なる形でデータ保護の仕組みを備えています。

なお、耐久性(データが失われない確率)そのものは、いずれのストレージも複数の物理ストレージにまたがる冗長化によって高い水準で確保されています。ここでいうバックアップ・レプリケーション・バージョニング・スナップショットは、耐久性そのものではなく、誤操作や意図しない上書き・削除からの「復旧可能性」を高めるための仕組みである点に注意してください。

データ保護機能をもう少し具体的に見ておきます。

• オブジェクトストレージのバージョニング — バケット単位で有効/無効を切り替え、同名オブジェクトの上書き・削除があっても過去バージョンを保持する
• ファイルストレージのスナップショット — ファイルシステム単位でポイントインタイムの読み取り専用コピーを作成する
• ブロックボリュームのクロスリージョンレプリケーション — 初回同期後は非同期で継続レプリケーションされ、目標復旧時点(RPO)はおおむね30分未満とされる

補足として、ブロックボリュームのバックアップは内部的にはオブジェクトストレージ上へ保存される仕組みです。バックアップ自体の容量もオブジェクトストレージの課金体系に準じるため、頻繁なバックアップスケジュールを組む場合は、保持期間とコストのバランスも合わせて検討してください。

さらに、コンプライアンス要件がある場合は、オブジェクトストレージの保持ルール(Retention Rules)を使うと、指定期間内はオブジェクトの上書き・削除を禁止する不変性(WORM: Write Once Read Many)を実現できます。

★AWS対比: EBSのスナップショットにData Lifecycle Manager(DLM)を組み合わせる運用は、OCIのバックアップポリシーに相当します。オブジェクトストレージの保持ルールは、S3 Object Lock(コンプライアンスモード/ガバナンスモード)に相当する不変性機能です。

定期的なリストア訓練(実際にバックアップやスナップショットから復元してみるテスト)も、データ保護設計の一部として計画しておくことをおすすめします。

それぞれの具体的な設定方法や、RPO(目標復旧時点)・RTO(目標復旧時間)の観点からどう組み合わせるべきかについては、後述の「コスト設計とデータ保護」の章で詳しく扱います。本章では、3種ともそれぞれの方式でデータ保護に対応している、という全体像を押さえておいてください。

2-5. 東京リージョン(ap-tokyo-1)での提供状況

ブロックボリューム・オブジェクトストレージ・ファイルストレージの3種はいずれも、東京リージョン(ap-tokyo-1)で利用できます。これら3種は、コンピュートやVCNと並ぶOCIの基盤サービスであり、東京リージョンを含むすべての商用リージョンで提供される基本サービスに位置づけられています。

実務上は、OCIコンソール右上のリージョン選択で「Asia Pacific (Tokyo)」を選択したうえで、各サービスのメニュー(ブロックボリューム/オブジェクトストレージ/ファイルストレージ)が表示されることを確認すれば、提供状況を自分の目で確かめられます。新しいサービスや一部の先進的な機能は、東京リージョンへの展開が本国リージョンに比べて遅れることがありますが、ブロックボリューム・オブジェクトストレージ・ファイルストレージはOCIの立ち上げ当初から提供されている基盤サービスであるため、機能面での地域差はほとんどありません。

Always Free枠(無料枠)は、アカウントの種類によって範囲が異なります。

• ブロックボリューム — アカウント種別によらず、ブートボリュームと追加ボリュームの合計200GB(ボリューム・バックアップ5個を含む)
• オブジェクトストレージ(Always Free専用アカウント、Free Trial失効後) — Standard・Infrequent Access・Archiveの合計20GB、APIリクエスト月50,000回まで
• オブジェクトストレージ(Free Trialクレジットが残っている、または有償アカウント) — Standard・Infrequent Access・Archiveそれぞれ10GBずつ、APIリクエスト月50,000回まで
• ファイルストレージ — 本記事執筆時点でAlways Freeの無料枠は設定されていない

これらの無料枠は東京リージョンでも同様に適用されます。まずはこの範囲内でブロックボリュームとオブジェクトストレージを試し、必要に応じて有償プランへ拡張していく進め方をおすすめします。

運用上の注意点も押さえておきます。

• 東京リージョンは可用性ドメイン(AD)を1つ持つ構成であり、AD間冗長化ではなく、フォールトドメイン(同一AD内の独立した物理グループ)やクロスリージョンレプリケーションで耐障害性を設計する
• 無料枠の利用状況は、OCIコンソールの「ガバナンスと管理」>「制限、割り当ておよび使用状況」画面で随時確認できる
• 料金は変動する可能性があるため、実際の設計時にはコンソールの見積りツールで最新の単価を確認する

★落とし穴: Always Free枠の適用先は、テナンシ作成時に選択した「ホームリージョン」に限られます。ホームリージョンを東京以外に設定した場合、東京リージョンでブロックボリュームを作成してもAlways Free枠は適用されず、通常課金の対象になります。東京をメインに使う予定であれば、テナンシ作成時にホームリージョンとして東京を選択しておくことが重要です。

なお、ホームリージョンが東京以外であっても、テナンシ管理画面からリージョンをサブスクライブすれば、東京リージョンの各サービスを通常料金で利用すること自体は可能です。Always Free枠が適用されないだけで、機能そのものが使えなくなるわけではありません。

★AWS対比: AWSの東京リージョン(ap-northeast-1)は複数のアベイラビリティーゾーン(AZ)を持つのに対し、OCI東京リージョンは可用性ドメイン(AD)を1つ持つ構成です。AWSのマルチAZ設計に慣れている場合、OCIでは可用性ドメイン内のフォールトドメインや、他リージョンとの組み合わせで同等の耐障害性を設計する発想の転換が必要になります。

CLIで確認したい場合は、oci iam region-subscription listコマンドを実行すると、現在のテナンシがサブスクライブしているリージョン一覧を取得できます。東京リージョン(ap-tokyo-1)が一覧に含まれていれば、そのテナンシから東京リージョンの各サービスを利用できます。

以上を踏まえると、東京リージョンでの初期検証はAlways Free枠から始め、要件が固まった段階で有償リソースへ段階的に移行していく進め方が安全です。

次章からは、ブロックボリューム・オブジェクトストレージ・ファイルストレージの順に、それぞれの設計判断を深掘りしていきます。

その後、6章で3種の使い分けを、7章でコスト設計とデータ保護をまとめて扱います。

3. ブロックボリューム — VPU Tierとパフォーマンス設計

3-1. VPU Tierの4段階 — Lower Cost/Balanced/Higher/Ultra High

OCIのブロックボリュームは、容量(GB)とは独立して「VPU(Volume Performance Units)」という単位でIOPSとスループットを設計します。VPUを1つ選ぶだけで、容量に比例したIOPS/スループットの上限が自動的に決まる点が最大の特徴です。

新規ボリュームは既定でBalanced(VPU 10)に設定されます。開発・検証用途のように低頻度IOしか発生しない場合はLower Costを選べば容量課金のみに抑えられますし、本番DBのように高いIOPSが求められる場合はHigher PerformanceやUltra High Performanceまで引き上げます。Ultra High Performanceは30から120まで10刻みで選択でき、VPUを上げるほどIOPS/スループットの上限が線形に伸びていきます。

★AWS対比: EBSのgp3は、容量とは別にIOPS(最大16,000)とスループット(最大1,000MB/s)を個別に購入するモデルで、gp2は容量に比例したバーストクレジット方式、io2はさらに高いIOPS(最大256,000)を提供します。一方OCIのVPUは「容量×VPU/GB」で性能が一意に決まるシンプルな設計です。EBSのように性能項目を個別に組み合わせる自由度はありませんが、Tierを1つ選ぶだけで設計が完結するため、判断はシンプルになります。

設計時の具体例として、100GBのボリュームをHigher Performance(20 VPU/GB)で使う場合、IOPS/GB=75なので理論値は7,500 IOPSとなります。Higher PerformanceでVolumeあたりの上限(50,000 IOPS)に達するには667GB以上の容量が必要です。100GBのままTierだけを最上位に引き上げても、容量起因のIOPS上限が先に効いてしまい、期待した性能を発揮できないため注意してください。Tierと容量の両方をセットで見積もることが重要です。なお、ブートボリュームも同じVPUモデルで性能が決まるため、OS起動やアプリケーション読み込みを高速化したい場合はブートボリューム側のTierを引き上げる、という選択肢もあります。

典型的なワークロード別に整理すると、次のようになります。

• 開発・ステージング環境の汎用ディスク → Lower Cost(容量課金中心。IOPSが低くてよい用途)
• Webアプリケーションのブートボリューム、一般的な業務システムのデータベース → Balanced(既定)
• トランザクション量の多いOLTP系データベース、検索インデックス → Higher Performance
• 大規模分析基盤やレイテンシ要件が極めて厳しいワークロードのログ/データ領域 → Ultra High Performance

VPUの選定に迷った場合は、まずBalancedで運用を開始し、OCIコンソールのメトリクスでIOPS使用率・レイテンシを確認してからTierを調整するのが実践的な進め方です。

3-2. オンラインリサイズとボリューム操作

ブロックボリューム/ブートボリュームは、インスタンスから切り離すことなくオンラインでサイズを拡張できます。既存サイズより大きい値を指定するだけで、コンソールまたはoci bv volume update --size-in-gbsコマンドから即座に反映され、アプリケーションを停止する必要はありません。リサイズは拡張のみに対応しており、縮小したい場合は新しいボリュームを作成してデータを移行する必要があります。

実際の操作手順は次の流れになります。

1. コンソールでボリュームの詳細ページを開き、「編集」からサイズ(GB)に現在より大きい値を入力する
2. Linuxインスタンスでは、リサイズ完了後にコンソールが提示するgrowpart・resize2fs(またはxfs_growfs)といったコマンドをインスタンス内で実行し、ファイルシステム側にも新しい容量を認識させる
3. Windowsインスタンスでは、ディスクの管理からパーティションを拡張する

このように、OCI側の容量変更とOS側のファイルシステム拡張は別工程である点に注意が必要です。OCI側の操作だけでは、OSからは容量が増えたように見えません。

VPU Tierの変更もオンラインで行えます。ボリューム作成後いつでもTierを引き上げ・引き下げでき、ボリュームの再作成は不要です。負荷試験の結果を見てから性能レベルを調整する、といった運用が可能です。

ボリュームの切り離し(デタッチ)・再アタッチも、コンピュート・インスタンスとブロックボリュームを疎結合に保つための基本操作です。データボリュームは稼働中のインスタンスから安全にデタッチして別インスタンスへ付け替えることができ、障害調査やインスタンスの再構築時に活用します。ブートボリュームについても、インスタンス本体を残したままブートボリュームだけを別のブートボリュームに差し替える、といった運用が可能です。

★AWS対比: EBSのElastic Volumesも、ボリュームをデタッチせずにサイズ・IOPS・スループット・ボリュームタイプ(gp2→gp3等)をオンライン変更できる点はほぼ同じ発想です。ただしEBSは同一操作でボリュームタイプ自体を切り替えられるのに対し、OCIはVPU Tier(性能レベル)の変更に限られ、ボリューム種別そのものは変わりません。

3-3. バックアップ・クロスリージョンレプリケーション・ボリュームグループ

バックアップにはフルバックアップと増分バックアップの2種類があります。最初のバックアップは指定に関わらず必ずフルバックアップとなり、以降の増分バックアップは差分のみを取得してチェーンを形成します。

バックアップの取得方法は2通りです。Oracle定義のバックアップポリシー(スケジュール・保持期間が固定で、2021年11月23日以降はフルバックアップを含みません)を使うか、ユーザー定義のカスタムポリシーでスケジュールと保持期間を自由に設定するかを選べます。カスタムポリシーでは、スケジュール(時間・日次・週次・月次)・保持期間に加えて、対象ボリュームをタグベースで自動アサインできます。タグベースのアサインを使えば、新規作成したボリュームに決まったタグを付けるだけでバックアップポリシーが自動適用されるため、設定漏れを防げます。またクロスリージョンへのバックアップコピーも、カスタムポリシーで自動化できます。

複数のボリュームを一体として保護したい場合はボリュームグループを使います。たとえば1台のデータベースインスタンスがデータ用とログ用の複数ボリュームを使う構成を考えます。個々のボリュームを別々にバックアップすると取得タイミングにズレが生じ、リストア後にデータの不整合を招きかねません。ボリュームグループでまとめてバックアップを取得すれば、全ボリュームが同一時点でクラッシュコンシステントな状態として保護されます。

クロスリージョンレプリケーションは、ボリューム・ブートボリューム・ボリュームグループ単位で他リージョン/可用性ドメインへ非同期の継続レプリケーションを行う機能です。初回同期完了後は継続的にレプリケーションされ、典型的なRPO目標は30分未満とされています。

たとえば東京リージョンで稼働する本番データベースに対して、他リージョンへのクロスリージョンレプリケーションを設定しておけば、東京リージョン側で障害が発生した場合でも、RPO30分程度のデータでレプリケーション先のボリュームからリカバリを開始できます。バックアップポリシーによる定期的なスナップショットと、クロスリージョンレプリケーションによる継続的な複製は目的が異なります。前者は誤削除やデータ破損からの復旧に、後者はリージョン単位の障害からの復旧に向いているため、本番システムでは両方を組み合わせて設計するのが基本です。

★AWS対比: EBSのスナップショットも増分方式でS3へコピーされ、Data Lifecycle Manager(DLM)でスケジュール・保持期間を自動化できる点はOCIのバックアップポリシーに相当します。複数ボリュームの整合性確保には、マルチボリュームスナップショットがボリュームグループに相当します。ただしEBSには継続的な非同期クロスリージョンレプリケーション機能自体はなく、スナップショットをリージョン間でコピーする(DLMのクロスリージョンコピー含む)運用で代替する点が、OCIのネイティブなレプリケーション機能との明確な違いです。

3-4. ブロックボリューム設計の早見表

まずはBalanced(既定)で運用を始め、実測のIOPS/レイテンシを見てからTierを上下に調整するのが安全な進め方です。VPU変更はオンラインでいつでも可能なため、初期設計で厳密に決め切る必要はありません。

4. オブジェクトストレージ — 3 Tierとライフサイクル

4-1. 3つのTier — Standard/Infrequent Access/Archive

オブジェクトストレージには、アクセス頻度に応じて選べる3つのTierがあります。

Standardはストレージ単価が最も高い代わりに、取り出し無料・最小保存期間なしで自由に使えます。Infrequent Accessは単価を下げる代わりに31日以上の保存を前提とし、取り出し時にGiB単位の手数料が発生します。Archiveは最も安価ですが、90日以上の保存が前提で、かつ保存されているデータをすぐには読み出せません。

★落とし穴: Archiveのオブジェクトを読み出すには、まず復元(restore)リクエストを発行する必要があります。復元リクエストから最初の1バイトが取得可能になるまで最大1時間かかり、さらに復元後にダウンロードできる猶予は既定で24時間(1〜240時間の範囲で指定可能)に限られます。この時間内にダウンロードを完了しないと、オブジェクトは自動的にArchiveへ戻ります。「Archiveに入れたデータはすぐには読めない」という前提を設計に織り込まないと、障害対応時にデータ取得が数十分から1時間単位で遅延する事態につながります。

★AWS対比: S3の3クラスはStandard/Standard-IA/Glacier系(Instant Retrieval・Flexible Retrieval・Deep Archive)にそれぞれ対応します。取り出し時間はS3 Glacier Flexible Retrievalで数分(Expedited)から数時間(Standard/Bulk)、Deep Archiveで12時間程度と選択肢によって幅がありますが、OCIのArchiveは「最大1時間でTTFB」という一律の基準を持つ点が特徴です。ただしOCIには復元後のダウンロード猶予(既定24時間)を過ぎると自動的にArchiveへ戻る挙動があり、S3の復元コピーの保持期間(日数指定)とは考え方が異なるため、運用設計時に確認が必要です。

実際にArchiveのオブジェクトを読み出す際は、コンソールの「Restore」操作またはoci os object restoreコマンドで復元リクエストを発行し、ステータスが「Restored」に変わってから通常のダウンロード操作を行います。ダウンロード猶予を既定の24時間から延ばしたい場合は、リクエスト時に1〜240時間の範囲で希望の時間を指定します。障害復旧の手順書には、この「復元リクエスト→最大1時間待機→猶予時間内にダウンロード」という3ステップを明記しておくことをおすすめします。

典型的な使い分けとしては、次のように整理できます。

• 稼働中のWebアプリケーションが配信する画像・動的コンテンツ → Standard
• 過去のレポートや月次バックアップファイルなど、月に数回程度参照するデータ → Infrequent Access
• 法令・監査対応で保管が必要なログ、数年単位で保持するコンプライアンス関連データ → Archive

コンプライアンス目的でログを長期保管する場合、Archiveの90日という最小保存期間は障害にならないことがほとんどですが、監査対応で頻繁に参照する必要があるデータをArchiveに置いてしまうと、そのたびに1時間近い復元待ちが発生してしまいます。監査頻度が高いデータはInfrequent Accessに留める、といった判断が必要です。

4-2. ライフサイクルポリシー — 自動でコストを下げる

ライフサイクルポリシーは、オブジェクト名のプレフィックス・パターン一致条件(最大20パターン)と、作成/最終更新からの経過日数条件を組み合わせて、次のようなアクションを自動実行する仕組みです。

• Standardから Infrequent Access または Archiveへの移行(例: 作成/更新から60日後に移行)
• 古いオブジェクトバージョンの削除(例: バージョン移行から120日後に削除)
• 未完了のマルチパートアップロードの削除(例: 5日経過後に削除)
• オブジェクト自体の削除(例: 180日経過後に削除)

設計例として、「作成から14日後にInfrequent Accessへ移行、90日後にArchiveへ移行、さらに一定日数経過後に削除」というルールを組むと、アクセス頻度の低下に合わせて段階的にコストを下げつつ、不要になったデータを自動的に消去できます。

コンソールでの設定手順は、バケットの詳細ページから「Lifecycle Policy Rules」を開き、「Create Rule」でオブジェクト名のプレフィックス条件、経過日数条件、実行するアクション(Tier移行または削除)を指定するだけです。1つのバケットに複数のルールを設定でき、拡張子やプレフィックスごとに異なるライフサイクルを適用できます。

1つのバケットに複数のルールを組み合わせた設計例として、logs/プレフィックスのオブジェクトは14日でInfrequent Access、90日でArchive、365日で削除という3段階のルールを設定し、backups/プレフィックスのオブジェクトは30日でArchiveへ移行し180日で削除する、といった使い分けが可能です。プレフィックスごとに異なるライフサイクルを適用できるため、ログとバックアップのように保持要件が異なるデータを同じバケット内で管理する際に有効です。

★AWS対比: S3のLifecycle rulesも、プレフィックス/タグによるフィルタと経過日数によるTier移行・失効(Expiration)アクションを組み合わせる点でほぼ同じ発想です。未完了のマルチパートアップロードを自動削除するルールがある点も共通しています。

4-3. Auto-Tiering — アクセスパターンが読めない時

Auto-Tieringは、1MiBを超えるオブジェクトを対象に、OCIがアクセスパターンを監視し、Standard⇔Infrequent Accessの間を双方向に自動で移動させる機能です。ライフサイクルポリシーが「経過日数」という静的な条件で一方向にTierを下げるのに対し、Auto-Tieringは「実際にアクセスされたかどうか」を基準に動的に判断します。再びアクセス頻度が上がったオブジェクトは、取り出し手数料や日割りのストレージ費用を課金されることなくStandardへ自動的に戻ります。アクセスパターンを事前に読めないデータセット(アプリケーションログ、ユーザー生成コンテンツなど)に向いた機能です。

Auto-Tieringは既定では無効になっており、Standardをデフォルト階層とするバケットの「Features」セクションから有効化するか、CLIであればoci os bucket update --auto-tiering InfrequentAccessのように指定して有効化します。有効化すると、31日間アクセスがなかったオブジェクトは自動的にInfrequent Accessへ移動し、機能自体の利用に追加費用はかかりません。ライフサイクルポリシーとの併用も可能で、「Auto-TieringでStandard⇔IAを動的に最適化しつつ、ライフサイクルポリシーで90日経過後にArchiveへ移す」という組み合わせ設計もよく使われます。

たとえばユーザー投稿型のWebサービスで、アップロードされた画像や動画を保存する場合、公開直後はアクセスが集中しますが、時間が経つとアクセス頻度が急激に下がるという典型的なパターンがあります。このようなアクセスパターンが予測しづらいデータにAuto-Tieringを設定しておくと、個々のオブジェクトごとに最適なタイミングでStandardとInfrequent Accessの間を自動的に行き来させられるため、ライフサイクルポリシーで一律の日数を設定するよりもきめ細かいコスト最適化が期待できます。

★AWS対比: S3 Intelligent-Tieringもアクセスパターンを監視して自動でTierを移動する点は同じ発想ですが、S3はStandard/低頻度アクセスに加えてArchive Instant Access、さらにオプションでArchive Access/Deep Archive Accessまで含む多段Tier構成を持ち、監視対象オブジェクトごとに小額の監視課金が発生します。OCIのAuto-TieringはStandard⇔Infrequent Accessの2段構成に限られ、Archiveへの自動移行は対象外である点が明確な違いです。Archiveまで含めたコスト最適化をしたい場合は、ライフサイクルポリシーを別途組み合わせる必要があります。

4-4. バケット設計とアクセス制御 — PARと可視性

オブジェクトはバケットという単位でまとめられ、バケット名はテナンシ内のネームスペース(namespace)で一意になります。バケットの可視性はprivate(既定)またはpublicを選べ、public設定時は認証なしで世界中からオブジェクトを読み取り可能になるため、公開Webアセットのような用途以外では基本的にprivateを維持します。

一時的にオブジェクトへのアクセスを許可したい場合は、事前認証済みリクエスト(PAR: Pre-Authenticated Request)を発行します。PARは、IAM認証情報を持たない相手に対して、有効期限付きの署名済みURLでオブジェクト/バケットへのアップロード・ダウンロードを許可する仕組みです。

PARには、読み取り専用(ObjectRead)・書き込み専用(ObjectWrite)・読み書き両方(ObjectReadWrite)に加え、バケット内の任意のオブジェクトを対象にする(AnyObjectRead/AnyObjectReadWrite)といったアクセスタイプがあります。有効期限に上限はなく任意の未来の日時を指定できますが、既定値は作成から1週間です。一度作成したPARの有効期限やアクセスタイプは変更できないため、条件を変えたい場合は新しいPARを作り直す必要がある点に注意してください。

PARの典型的な活用場面としては、次のようなケースがあります。

• 社外パートナーに、IAMユーザーを発行せずに特定のレポートファイルだけをダウンロードさせたい
• Webアプリケーションのフロントエンドから、バックエンドの認証情報を経由せずに直接オブジェクトをアップロードさせたい
• 期間限定のキャンペーンで、静的コンテンツを一時的に外部公開したい

いずれの場合も、バケット全体をpublicにする必要はなく、必要な範囲・期間だけをPARで限定的に公開できる点が安全な設計のポイントです。

★AWS対比: バケット単位の可視性制御はS3のバケットポリシー/ブロックパブリックアクセス設定に、PARはS3の署名付きURL(presigned URL)にそれぞれ相当します。ただしOCIのオブジェクトには、S3のようなオブジェクト単位のACLという概念は薄く、アクセス制御はIAMポリシーとPARを中心に設計する点が、S3との運用上の違いです。

5. ファイルストレージ — マネージドNFSとマウントターゲット

5-1. ファイルストレージとは — フルマネージドNFS

OCIのファイルストレージ(File Storage)は、NFSv3(Network File System version 3)プロトコルに準拠したフルマネージドの共有ファイルシステムサービスです。ブロックボリュームが原則1つのコンピュート・インスタンスに専有される「ディスク」であるのに対し、ファイルストレージは複数のコンピュート・インスタンスから同時にマウントして共有できる点が最大の違いです。ファイルロックについてもNLM(Network Lock Manager)プロトコルに対応しており、複数クライアントからの同時書き込みに対する整合性も確保されています。

ここまでの章で見てきたブロックボリューム(VPUによる性能設計)やオブジェクトストレージ(3 Tierによるコスト設計)とは異なり、ファイルストレージには性能や階層を選ぶための単位が存在しません。実際に使用しているデータ・メタデータの容量分に対するフラットな従量課金が基本であり、スループットやIOPSを引き上げるための追加課金の仕組みはありません。ストレージは最小8,192バイト単位のブロックで割り当てられ、小さなファイルであっても最低8KB分の容量として計上される点は、大量の小ファイルを扱うワークロードでは意識しておく必要があります。

スケーリングの面でも特徴があります。ファイルシステムは事前にサイズを指定する必要がなく、1バイトからエクサバイト級まで自動的に拡張されるフルマネージド設計です。ブロックボリュームのように「オンラインリサイズ」という操作すら不要で、書き込むデータ量に応じて容量が自動的に増えていきます。

★AWS対比: AWSのEFS(Elastic File System)がほぼ同じ位置づけのサービスです。ただしEFSは、Standard/One Zoneという2つのストレージクラス、それぞれにStandardとInfrequent Access(IA)という2段階の階層を持ち、さらにBursting・Provisioned・Elasticという3つのスループットモードを選択できる、多軸の設計になっています。一方OCIのファイルストレージには、これらのクラス・階層・スループットモードに相当する選択肢が一切なく、容量課金のみのシンプルな1本の料金体系です。EFSの細かい調整に慣れている場合、「OCIのファイルストレージでも階層やスループットモードを選ばなければ」と身構えてしまいがちですが、選ぶべき項目自体が存在しない点を最初に理解しておくと迷いません。

落とし穴として、この「選択肢のなさ」は裏を返せば、EFSのProvisioned Throughputのように性能を追加購入して引き上げることができないことも意味します。ファイルストレージの性能はマウントターゲットの設計やクライアント側の並列度に依存する部分が大きく、単一のワークロードで極めて高いスループットが必要な場合は、後述のマウントターゲット設計やファイルシステムの分割を検討する必要があります。

暗号化についても確認しておきます。ファイルストレージは既定でOracle管理キーによる保管時暗号化(encryption at rest)が有効です。ブロックボリューム・オブジェクトストレージと同様、より厳格な鍵管理が必要な場合はOCI Vaultの顧客管理キー(Customer-Managed Keys)への切り替えが可能で、3種のストレージ間で暗号化の考え方に差はありません。

具体例で考えてみます。数百台規模のCI/CDビルドエージェントが共有するパッケージキャッシュを、ファイルストレージ1つのファイルシステムに集約するケースを想定します。VPUのような性能引き上げの手段がない代わりに、マウントするクライアント数が増えても課金体系はデータ容量に対するフラット課金のまま変わらないため、接続数の増減がコストに直結しないというメリットがあります。一方でクライアント数が増えるほど、後述するマウントターゲットの接続数上限や、単一ファイルシステムへの同時アクセス集中によるレイテンシ増加には注意を払う必要があります。

5-2. マウントターゲット — VCN内のNFSエンドポイント

ファイルストレージを利用するには、まずファイルシステム(File System)を作成し、それを「マウントターゲット(Mount Target)」経由でネットワークに公開(エクスポート)する、という2段階の構成になります。ファイルシステム自体はデータを保持する実体であり、マウントターゲットはNFSクライアントが接続するためのエンドポイント(IPアドレス)を提供する役割を担います。

マウントターゲットは、Vol3で扱ったVCN内のサブネットに配置されます。ブロックボリュームがコンピュート・インスタンスに直結するのとは異なり、ファイルストレージはネットワーク経由でアクセスするサービスであるため、マウントターゲットをどのサブネットに置くか、そしてそのサブネットへの到達性をどう確保するかが設計の出発点になります。この点はVol3で解説したVCN・サブネット・ルートテーブルの基礎知識がそのまま前提になりますので、本記事では再説明しません。

マウントターゲットは高可用性(HA)構成で提供され、1つのマウントターゲットで複数のファイルシステムをエクスポート可能です。既定では、アカウント・可用性ドメインあたり2つのマウントターゲットが上限として設定されています。テナンシ全体で多数のファイルシステムを使う場合は、この上限を踏まえて設計するか、上限緩和(Service Limit Increase)をリクエストする必要があります。

アクセス制御は、Vol3で扱ったセキュリティリスト・ネットワークセキュリティグループ(NSG)による通信経路の制御と、ファイルシステム側の「エクスポートオプション(Export Options)」による制御の2段構えになります。エクスポートオプションでは、接続元のCIDR範囲ごとに読み取り専用/読み書き可否、rootスカッシュ(root権限でのアクセスを一般ユーザー権限に格下げする設定)の有無などを、1ファイルシステムあたり最大100個のルールとして設定できます。

実際にマウントする際は、対象のコンピュート・インスタンス上で次のようなコマンドを実行します。

sudo mount -o vers=3 <マウントターゲットのIPアドレス>:/<エクスポートパス> /mnt/shared

★AWS対比: マウントターゲットは、EFSの「マウントターゲット」とほぼ同じ概念です。EFSも同様にVPC内のサブネットにマウントターゲット(ENI)を配置し、セキュリティグループで接続を制御します。設計の発想自体はAWSでEFSを使った経験がそのまま活用できる部分ですが、OCIでは既定のマウントターゲット数がアカウント・AD単位で2個と少なめである点、rootスカッシュ等の細かい制御がエクスポートオプション側に集約されている点は、事前に押さえておくとよい違いです。

落とし穴として、マウントターゲットは既定で単一のADに配置されるため、東京リージョンのようなシングルAD構成のリージョンでは、AD障害時にマウントターゲット自体が失われるリスクを、フォルトドメイン単位の分散や定期的なスナップショット取得でカバーする設計が必要です。

複数のコンピュート・インスタンスから同じマウントターゲットに接続する場合、各インスタンスの/etc/fstabに同じマウント設定を記述しておくと、再起動時にも自動的に再マウントされます。

<マウントターゲットのIPアドレス>:/<エクスポートパス> /mnt/shared nfs vers=3,nointr,timeo=600 0 0

マウントターゲットの接続数にも上限があります。1つのマウントターゲットあたり最大100,000のNFSクライアント接続が可能ですが、TLSによる転送時暗号化を有効にした場合は上限が4,096接続まで下がります。セキュリティ要件でTLS暗号化が必須の環境では、この接続数上限を事前に見積もっておくことが重要です。

5-3. ファイルストレージのユースケース

ファイルストレージが最も力を発揮するのは、「複数のコンピュート・インスタンスから同じデータに同時にアクセスする必要がある」場面です。代表的なユースケースを整理すると、次のとおりです。

• 複数のWebサーバー・アプリケーションサーバーで共有する設定ファイル・ライブラリ・アップロードされたコンテンツ(CMSのメディアディレクトリ等)
• 複数ユーザーが利用する共有ホームディレクトリ(研究機関・大学等の計算環境でよく見られる構成)
• HPC(高性能計算)クラスターでの共有作業領域 — 複数ノードから並列にread/writeするジョブの中間データ置き場
• オンプレミスで稼働していたNFS依存アプリケーションをそのままリフト&シフトする移行案件 — アプリケーション側の変更を最小限にしたい場合
• CI/CDパイプラインでの共有キャッシュ・アーティファクト置き場 — 複数のビルドエージェントから同じキャッシュを参照したい場合

逆に、ファイルストレージが適さない場面も明確にしておきます。単一のインスタンスだけが低レイテンシでアクセスするデータベースのデータ領域には、共有機能を持たない分レイテンシに優れるブロックボリュームの方が適しています。また、HTTP/S経由でアプリケーションから広くアクセスされる静的アセットやログの長期保管には、スケーラビリティとコスト効率に優れるオブジェクトストレージの方が適しています。「複数インスタンスからの共有アクセスが本当に必要か」を最初に自問することが、ファイルストレージを選ぶかどうかの判断の起点になります。

★AWS対比: これらのユースケースは、AWSでEFSを採用する典型的な場面ともほぼ一致します。EFSがLambda関数やECS/EKSのPodからマウントされる共有ストレージとして使われるのと同様に、OCIのファイルストレージもOKE(Vol6で扱うマネージドKubernetes)のPodからマウントされる共有ボリュームとして利用できます。

判断に迷った場合のチェックリストとして、次の3点を確認してみてください。

• 同じディレクトリ構造・同じファイルパスを、複数のインスタンスから参照する必要があるか
• ファイルロックのような、複数プロセスからの同時書き込み制御が必要か
• オンプレミスのNFS運用経験があり、既存の運用ノウハウをそのまま活かしたいか

これらのいずれかに当てはまる場合は、ファイルストレージが有力な候補になります。逆にいずれにも当てはまらない場合は、オブジェクトストレージまたはブロックボリュームで代替できないかを先に検討することをおすすめします。

次章では、ここまで見てきたブロックボリューム・オブジェクトストレージ・ファイルストレージの3種を、実際にどう使い分けるかという判断基準に進みます。

6. 3種の使い分け — パフォーマンス・コスト・耐久性・頻度で選ぶ

6-1. アクセス方式で分ける — 単一/共有/API

第一次分岐として最も重要なのが、アクセス方式です。次の3つの問いへ順番に答えることで、多くの場合は迷わず絞り込めます。

1. 複数のコンピュート・インスタンスから同時にファイルレベルで共有アクセスする必要があるか? → 必要ならファイルストレージ
2. アプリケーションやサービスからHTTP/S経由でアクセスし、実質無制限にスケールする容量が必要か? → 必要ならオブジェクトストレージ
3. 上記のいずれでもなく、単一のインスタンスから低レイテンシでブロックデバイスとしてアクセスしたいか? → ブロックボリューム

この順序で判断するのがポイントです。「共有が必要かどうか」を最初に問うことで、ブロックボリュームとファイルストレージの判断が明確になり、次に「HTTP/S経由の大規模アクセスかどうか」を問うことで、オブジェクトストレージかどうかが決まります。

具体的な当てはめ例を示します。

• データベースのデータ領域 — 単一インスタンスからの排他アクセス、低レイテンシ必須 → ブロックボリューム
• 複数のバッチサーバーで共有するライブラリ・設定ファイル — 複数インスタンスからのファイルレベル共有 → ファイルストレージ
• Webサイトが配信する画像・動画 — アプリケーションからHTTP/S経由でのアクセス、実質無制限のスケール → オブジェクトストレージ
• ログの集約・長期保管 — 書き込み元は複数でも、最終的な保存先はAPIアクセスで十分 → オブジェクトストレージ

★落とし穴: 「複数インスタンスから読み書きしたい」という要件だけを見て安易にファイルストレージを選ぶ前に、その複数インスタンスからのアクセスが本当にファイルシステムレベルの共有(同じディレクトリ構造・ファイルロックが必要)なのか、それとも単にオブジェクト単位で読み書きできれば足りるのかを見極めてください。後者であれば、スケーラビリティとコスト効率に優れるオブジェクトストレージの方が適している場合が多くあります。

★AWS対比: この第一次分岐の考え方は、AWSでEBS・EFS・S3のどれを選ぶかを検討する際の判断プロセスとほぼ同じです。AWS実務者であれば、「EBSかEFSかS3か」を選ぶときの思考プロセスをそのままOCIに応用できます。

判断が難しいケースとして、「複数のインスタンスから同じデータを読み取るだけ(書き込みは1箇所からのみ)」という要件があります。この場合、書き込み元を1台に限定できるのであれば、書き込み後にオブジェクトストレージへアップロードし、読み取り側は各インスタンスがオブジェクトストレージから直接ダウンロードする、という設計で十分なケースが多くあります。ファイルストレージが必要になるのは、複数の書き込み元が同じファイルを更新し合う、あるいはPOSIX準拠のファイルシステムAPI(ディレクトリ操作・シンボリックリンク等)がアプリケーション側で必須の場合に絞られます。

6-2. パフォーマンスとコストのトレードオフ

3種のストレージは、それぞれ異なる方法で「性能とコストのバランス」を調整します。この調整方法の違いを理解しておくと、要件に応じた最適な設定を選びやすくなります。

ブロックボリュームは、VPU Tierという単位で性能を「買う」設計です。Lower CostからUltra High Performanceまで、必要な性能に応じてTierを引き上げるほどコストも比例して増加します。高頻度・低レイテンシが必要なワークロードほど高いTierを選び、コストを許容する代わりに性能を確保するという、性能優先の調整軸です。

オブジェクトストレージは逆に、Tierという単位でコストを「下げる」設計です。StandardからInfrequent Access、Archiveへとアクセス頻度の低いデータを移すことで、単価を段階的に下げていきます。ただしTierを下げるほど取り出し時のレイテンシ・手数料が増えるため、コスト優先の調整軸である一方、アクセス頻度を見誤ると取り出しコストや復元待ち時間という別の代償を払うことになります。

ファイルストレージには、この「性能を買う」「コストを下げる」に相当する調整軸そのものがありません。容量に対するフラット課金のみで、VPUのような性能引き上げの手段も、Tierのようなコスト削減の手段も用意されていません。その代わりに、複数インスタンスからの共有アクセスという利便性を提供する、という位置づけです。性能を細かく調整したいワークロードには不向きですが、共有の利便性そのものが目的であれば、調整項目がない分シンプルに導入できるという利点にもなります。

アクセス頻度(ホット/ウォーム/コールド)という観点で3種を並べて整理すると、次のようになります。

この表からも分かるとおり、ブロックボリュームとオブジェクトストレージはアクセス頻度に応じて明示的にコスト・性能をチューニングできるのに対し、ファイルストレージはアクセス頻度によらず一律の課金・性能特性になります。共有が必要なワークロードでアクセス頻度による最適化まで行いたい場合は、ファイルストレージ側でのチューニングではなく、アプリケーション側でホットなデータとコールドなデータを分離し、コールドな部分はオブジェクトストレージへアーカイブするといった設計の工夫が必要になります。

★AWS対比: この構図はAWSでも共通しています。EBSはボリュームタイプ(gp3/io2等)で性能を買い、S3はストレージクラスでコストを下げ、EFSはStandard/IAという2階層こそあるものの、OCIのファイルストレージ以上に細かい性能調整の手段(スループットモード)を持っています。この点は、OCIのファイルストレージがEFSよりもシンプルな設計思想を採っている一例といえます。

コストと性能のトレードオフを見積もる際の実践的な進め方として、次の順序をおすすめします。まず対象データのアクセス頻度(ホット/ウォーム/コールド)を実測またはヒアリングで見積もり、次に許容できるレイテンシ・復元時間を確認し、最後にその条件を満たす最小コストのTier・VPUを選びます。「最初から高いTierを選んで様子を見る」のではなく、「低いTierから始めて実測に応じて引き上げる」方が、無駄なコストを抱え込むリスクが小さくなります。

6-3. シナリオ別の推奨構成

実務でよく登場する典型的なシステム構成を例に、3種の組み合わせ方を具体的に見ていきます。

ケース1: 3層Webアプリケーション — Webサーバーが配信する静的アセット(画像・CSS/JS)はオブジェクトストレージ(Standard)に置き、アプリケーションサーバーの共有設定ファイルやセッションキャッシュにはファイルストレージを使い、バックエンドのデータベースにはブロックボリューム(Higher Performance程度)を割り当てる、という組み合わせが典型的です。

ケース2: ログ収集・分析基盤 — 各サーバーから収集した生ログは、いったんファイルストレージまたはブロックボリュームの一時領域に書き込み、集計処理が完了したらオブジェクトストレージへ移してライフサイクルポリシーで段階的にコストを下げていく、という流れになります。分析用のデータベース(データウェアハウス等)自体には、高いIOPSが求められるためブロックボリュームのHigher Performance以上を割り当てます。

ケース3: コンテンツ管理システム(CMS) — アップロードされたメディアファイルはオブジェクトストレージに保存し、PAR(事前認証済みリクエスト)で配信用のURLを発行します。複数のCMSインスタンスが共有する設定・プラグインファイルにはファイルストレージを使い、CMS本体のデータベースにはブロックボリュームを割り当てます。

ケース4: リフト&シフト移行案件 — オンプレミスでNFS共有に依存していたアプリケーションをそのまま移行する場合、アプリケーション側の変更を避けるためにファイルストレージを選択します。移行後、余裕が出てきた段階で、アクセス頻度の低いデータをオブジェクトストレージへ再設計する、という段階的な最適化も選択肢になります。

ケース5: HPC・機械学習の前処理パイプライン — 複数の計算ノードが同じ入力データセットを並列に読み込む必要がある場合、ファイルストレージを共有作業領域として使い、前処理が完了した結果はオブジェクトストレージへアーカイブします。計算ノードが一時的に生成する中間ファイル(チェックポイント等)は、ノードごとのブロックボリュームに置くことで、ファイルストレージへの書き込み集中を避ける設計もよく用いられます。

シナリオ選定でよくある失敗例も挙げておきます。「複数インスタンスから参照したい」というだけの理由で、本来はオブジェクトストレージで十分なデータ(静的アセットや完成済みのアーカイブファイルなど)までファイルストレージに置いてしまうと、コスト効率・管理性のいずれの面でも不利になります。逆に、複数プロセスからの同時書き込みとファイルロックが本当に必要な場面でオブジェクトストレージを無理に使おうとすると、アプリケーション側で独自の排他制御を実装する羽目になり、開発コストが増大します。「本当に必要な機能は何か」を最初に見極めることが、ケース1〜5すべてに共通する出発点です。

いずれのケースにも共通するのは、「1つのシステムに1種類のストレージだけを使う」のではなく、データの性質(単一アクセスか共有か、アクセス頻度、コスト許容度)に応じて3種を組み合わせて設計するという発想です。3種を横断した、迷ったときの判断順序をまとめると、次のようになります。

1. 複数インスタンスからの共有が必要か(§6-1のアクセス方式)を確認する
2. アクセス頻度(ホット/ウォーム/コールド、§6-2)を見積もる
3. 性能要件(レイテンシ・IOPS)とコスト許容度のバランスを取る
4. 必要に応じて複数のストレージ種別を組み合わせる

この判断順序は、新規システムの設計時だけでなく、既存システムの見直しの際にも使えます。定期的にワークロードの性質を棚卸しし、当初の想定からアクセスパターンがずれていないかを確認することで、3種の使い分けを継続的に最適化できます。

判断に迷う場面が続くようであれば、まずは小さく始めてみることをおすすめします。仮の判断でいずれかのストレージを選び、実際のメトリクスを確認しながら、必要であれば後から別のストレージへ移行する、という反復的なアプローチでも問題ありません。

次章では、この使い分けを前提に、3種それぞれのコスト構造とデータ保護の設計を詳しく見ていきます。

7. コスト設計とデータ保護 — バックアップ/レプリケーション/AWS対比

7-1. コスト構造 — 3種の課金要素とAWS対比

OCIの3種のストレージは、それぞれ異なる課金要素の組み合わせでコストが決まります。同じ「ストレージ」というくくりで比較すると誤解しやすいため、まずは要素を分解して整理します。

ブロックボリュームは、容量(GB/月)課金と、選択したVPU Tierに応じた性能課金の2要素で構成されます。VPU/GBの値が大きいTierを選ぶほど、同じ容量でも月額費用は増加します。バックアップも容量に応じた別課金であり、増分バックアップであっても保持世代数が多いとバックアップ用の容量は想定より積み上がりやすいため注意してください。

オブジェクトストレージは、容量課金(TierごとにStandard・Infrequent Access・Archiveの順で単価が下がる)に加えて、リクエスト課金と取り出し課金が組み合わさります。PUT・COPY・POST・LISTのリクエストは3 Tierすべてで課金対象になりますが、GETリクエストはStandardでは無料である一方、Infrequent AccessとArchiveでは課金対象です。取り出し課金は、Infrequent Accessでは取り出したGB単位で、Archiveでは復元(restore)操作に対して発生します。

ファイルストレージは、容量(GB/月)のみのフラット課金が基本です。ブロックボリュームのVPUやオブジェクトストレージのTierに相当する性能・階層区分は存在せず、シンプルな課金体系である一方、スナップショットで保持しているデータの分も容量として加算される点は見落としがちです。

この対比で押さえておきたいのは、OCIのブロックボリュームがVPUという1つの値で性能課金を完結させるのに対し、EBSはIOPSとスループットを個別に購入する分、細かい調整が利く反面、見積もりの要素が増えるという点です。同様に、ファイルストレージはOCI・AWSどちらも容量課金が基本ですが、AWS EFSはStandardとInfrequent Accessでクラスが分かれ、さらにスループットモード(Bursting・Elastic・Provisioned)によって課金が変わるのに対し、OCIのファイルストレージにはそうした階層・モードの概念がなく、容量課金のみで完結します。

★落とし穴として、オブジェクトストレージの取り出しコストは特に見落とされがちです。Infrequent AccessやArchiveは容量単価こそ低いものの、取り出し頻度が想定より高いワークロードに適用すると、取り出し課金の累計がStandardの容量課金を上回ることがあります。ライフサイクルポリシーで機械的に「〇日経過したらIA/Archiveへ」と設定する前に、実際のアクセス頻度をログや監視で確認し、必要に応じてAuto-Tieringのような動的な仕組みを選ぶ判断が欠かせません。

7-2. データ保護のベストプラクティス

3種のストレージは、RPO(目標復旧時点)とRTO(目標復旧時間)の要求水準に応じて、保護方式を組み合わせて設計します。

ブロックボリュームは、バックアップ(フル+増分)とクロスリージョンレプリケーションの2段構えで保護します。バックアップからのリストアはRTOが数十分から数時間単位になりやすいのに対し、クロスリージョンレプリケーションは典型的なRPOが30分未満とされ、リージョン障害時にも短い遅延で復旧できます。RPO要求が厳しい本番データベースには、バックアップだけでなくクロスリージョンレプリケーションの併用を検討する価値があります。また複数ボリュームで構成されるシステムでは、個別にバックアップを取得するのではなくボリュームグループでまとめて取得し、クラッシュコンシステントな状態を確保することが重要です。

オブジェクトストレージは、バージョニングとリージョン間レプリケーションで保護します。バージョニングは誤削除や誤上書きからの復旧に有効で、リージョン間レプリケーションはリージョン障害への備えになります。ライフサイクルポリシーによる自動削除ルールを設定している場合、バージョニングと組み合わせないと、削除ルールが誤って重要なデータを消してしまうリスクがある点にも注意が必要です。

ファイルストレージは、スナップショットによるポイントインタイムの保護が基本です。スナップショットはコピーオンライト方式で、変更分のみを追加容量として消費します。ただし、ブロックボリュームのクロスリージョンレプリケーションのような、リージョンをまたいだ自動継続レプリケーション機能はネイティブには提供されていません。リージョンをまたいだ保護が必要な場合は、スナップショットを取得したうえで、rsyncやFile Storage Parallel Toolsのようなツールを使って他のリージョンへ複製する運用を組む必要があります。

★AWS対比: EBSのスナップショット+Data Lifecycle Manager(既出)がOCIのバックアップポリシーに相当し、S3のバージョニング+Cross-Region Replication(CRR)がオブジェクトストレージの保護方式にほぼ対応します。一方でファイルストレージについては、AWS EFSにはリージョンをまたいだレプリケーション機能(EFS Replication)がネイティブに用意されています。これに対しOCIのファイルストレージには同等の機能はなく、スナップショットと外部ツールを組み合わせた運用によるカバーが必要な点は明確な違いです。

7-3. コスト最適化の実践

実際の運用では、次の3つの観点を定期的に見直すことで、ストレージコストを継続的に最適化できます。

これら3つの観点は、いずれも一度設定して終わりではなく、継続的な見直しが前提になります。オブジェクトストレージのライフサイクルポリシーは、運用開始時に見積もったアクセスパターンが実際とずれていることが珍しくなく、定期的に取り出し課金の実績を確認し、Tier移行のタイミングを調整する必要があります。ブロックボリュームについても、負荷試験や本番稼働後の実測値をもとにVPU Tierを見直すことで、過剰投資を防ぎながら必要な性能を維持できます。

さらに、バックアップやスナップショットは削除ポリシーを設定しない限り増え続け、気づかないうちにストレージコストの多くを占めるようになりがちです。カスタムバックアップポリシーで保持世代数を明示的に設定し、ファイルストレージのスナップショットについても不要になった世代を計画的に削除する運用ルールを、コンパートメント設計やタグ付けと組み合わせて仕組み化しておくことをおすすめします。

8. まとめ — OCIストレージの基礎と次のステップ

8-1. この記事の振り返り

本記事では、OCIが提供する3種のストレージ — ブロックボリューム・オブジェクトストレージ・ファイルストレージを、AWSのEBS・S3・EFSとの対比を軸に見てきました。

ブロックボリュームでは、容量とは独立したVPU(Volume Performance Units)という単位でIOPS・スループットが決まる設計を確認し、EBSのgp3やio2のようにIOPSとスループットを個別購入するモデルとの違いを押さえました。オブジェクトストレージでは、Standard・Infrequent Access・Archiveの3 Tierと、ライフサイクルポリシー・Auto-Tieringによる自動コスト最適化の仕組みを見て、S3の各ストレージクラスとの対応関係を整理しました。ファイルストレージでは、複数インスタンスから同時にマウントできるマネージドNFSとしての特性と、VCN内のマウントターゲットを介したネットワーク設計を確認しました。

これら3種を横断する使い分けの軸として、アクセス方式(単一・共有・API)・パフォーマンス要件・コスト・アクセス頻度の観点を整理し、本番データベースにはブロックボリューム、ログやバックアップの長期保管にはオブジェクトストレージ、複数インスタンス間の共有にはファイルストレージ、という典型的な選択パターンを確認しました。さらにコスト設計とデータ保護の章では、3種それぞれの課金要素の違いと、RPO・RTOの観点からバックアップ・レプリケーション・スナップショットをどう組み合わせるかを見てきました。

単なる機能名の暗記ではなく、目の前のワークロードに対して「なぜその1種を選ぶのか」を、性能・コスト・保護要件の3方向から説明できる状態を、本記事のゴールとして目指してきました。AWSでの設計経験がある方ほど、EBS・S3・EFSとの対比を手がかりにすることで、OCI固有の設計思想(VPUによる性能課金、3 Tierとライフサイクル、フラット課金のNFS)へすばやく頭を切り替えられるはずです。

8-2. 次のステップ — Vol6(OKE入門)へ

本記事で扱ったブロックボリュームは、OKE(マネージドKubernetesサービス)においても、Podが利用する永続ボリューム(Persistent Volume)のバックエンドとして登場します。Vol6では、OKEクラスターの構築とワークロードのデプロイを扱う中で、本記事で押さえたVPU Tierの考え方が、Persistent Volume Claim経由でどのように活用されるのかにも軽く触れる予定です。共有が必要なワークロードでは、本記事で扱ったファイルストレージがPod間の共有ボリュームとして関連してくる場面もあります。

ストレージの選定・設計という土台を押さえたうえで、次巻ではいよいよコンピュートオーケストレーションの領域に踏み込みます。テナンシ・IAM・ネットワーキング・ストレージという土台の上に、マネージドKubernetesという実行基盤を組み合わせることで、OCI上でのアプリケーション実行環境の全体像が見えてくるはずです。ストレージの使い分けを正しく理解しておくことは、Vol6でPersistent Volumeの設計判断を行う際の土台にもなります。

← Vol4(OCIコンピュート入門)を読む
OCI入門シリーズの一覧を見る →