OCI入門 Vol4 コンピュート入門 VM形状(Ampere A1/AMD/Intel)・ベアメタル・無料枠

1. この記事について — OCIのコンピュートを深掘りする

1-1. 本記事のゴール

本記事を読み終えたとき、読者の皆さんには次の4点ができるようになっていることを目指します。

1. 形状を選べる — Ampere A1(Arm)・AMD・Intelという3つのプロセッサ系統それぞれの特性を理解し、自分のワークロードにどの系統が適しているかを、根拠を持って判断できる状態
2. VMとベアメタルを使い分けられる — 「仮想化するか、専有するか」の判断軸を理解し、いつベアメタルインスタンスが必要になるかを見極められる状態
3. 手を動かして起動できる — Always Free枠を使い、実際にAmpere A1のインスタンスを1台起動し、SSHで接続するところまで完了している状態
4. コストを設計できる — OCPUとメモリの配分の考え方を理解し、AWS EC2の料金体系との対比を踏まえて、無駄のないコスト設計ができる状態

本記事で実際に手を動かして得られる成果物は、Always Free枠の範囲内で起動したAmpere A1インスタンス(VM.Standard.A1.Flex)1台に、SSH公開鍵認証で接続できる状態です。§5でインスタンス作成の基本フローを、§6でそれをAlways Free枠に当てはめた具体的な手順を扱いますので、実際にコンソールを操作しながら読み進めることをおすすめします。

この成果物にたどり着くまでの間に、単に手順をなぞるだけでなく、なぜその形状・その設定を選ぶのかという判断根拠を都度示しながら進めます。判断根拠を理解しておくことで、本記事で扱う構成以外のワークロードに直面したときにも、応用の利く考え方として活用できるはずです。

OCIのコンピュートは、AWSのEC2に相当するサービスですが、「形状(shape)」という単位の設計思想や、OCPUという課金・性能の単位、Flexible shapeという柔軟な配分方式など、AWSにはない独自の概念がいくつも登場します。本記事はこれらの概念をひとつずつ丁寧に解き明かしながら、最終的には「なぜその形状を選ぶのか」という設計判断ができる状態まで引き上げることを目指します。単なる機能一覧ではなく、実務でインスタンスを選定する際にそのまま使える判断基準を提供することが、本記事のゴールです。

本記事の対象範囲を明確にするため、扱わない内容もあらかじめ整理しておきます。

• ブロック・オブジェクト・ファイルストレージの詳細な設定手順(Vol5で扱います)
• OKE(Oracle Container Engine for Kubernetes)によるコンテナワークロードの構築(Vol6で扱います)
• Autonomous Databaseなど、コンピュート以外の個々のマネージドサービスの詳細設定

本記事はあくまで、コンピュートサービス(VM・ベアメタル)の選定と設計、Always Free枠での実践に絞って解説します。

読み終えた後は、単に手順を覚えるだけでなく、社内で「なぜOCIのこの形状を選んだのか」を説明できる根拠を持ち帰っていただくことも本記事の狙いです。設計判断の理由を言語化できる状態は、稟議やレビューの場で自分の選定を裏付ける材料にもなります。

本記事で登場する主な用語を、先取りして一言で整理すると次のとおりです。詳しい説明は§2以降で行います。

この対応関係はあくまで概略です。それぞれの用語の詳しい定義とAWSとの対比は、§2以降で順番に整理していきます。用語の意味がつかめないまま読み進めるよりも、まずこの一覧に軽く目を通しておくだけで、以降の解説の理解が早くなるはずです。

1-2. 読者像

本記事が想定する読者は、AWSのEC2は日常的に使っているものの、OCIのコンピュートサービスにはまだ触れたことがない、あるいは触れ始めたばかりのクラウド実務者です。具体的には、次のような方を想定しています。

• AWSでEC2インスタンスの起動・運用・コスト最適化を日常的に行っており、その知見をOCIでも活かしたいと考えている方
• マルチクラウド戦略の検討やコスト比較、特定顧客の要件などをきっかけにOCIの検証・導入を任されることになり、まずコンピュートサービスの全体像をつかみたい方
• 本シリーズのVol1〜3(テナンシ/IAM/VCN)を読了し、OCIのアカウント設計とネットワーク基盤についての理解を済ませ、次はいよいよインスタンスを動かす段階に進みたい方

前提知識としては、本シリーズVol1で扱ったテナンシ・コンパートメント・Always Free枠の基礎、Vol2のIAM Identity Domainsとポリシー、Vol3のVCN・サブネット・セキュリティリストの基礎知識を読了済み、またはそれと同等の知識をお持ちであることを前提とします。これらの基礎については本記事では再説明しませんので、必要に応じて各Volをご確認ください。

OCIのコンピュートを検討することになる典型的なきっかけとしては、次のような場面が挙げられます。

• コスト削減のため、既存のAWSワークロードの一部をマルチクラウド構成でOCIに分散させたい
• 特定の取引先や案件の要件で、OCI環境の構築・運用を任されることになった
• 障害対策(DR)の観点で、AWSとは異なるクラウド事業者にセカンダリ環境を持ちたい
• 純粋にAmpere A1のコスト効率に興味があり、個人の学習・検証で試してみたい

いずれの背景であっても、AWSでの経験を土台にしながら実務レベルの判断ができるようになることを、本記事は目指しています。

AWS経験者がOCIのコンピュートに触れて戸惑いやすいポイントは、主に3つあります。

1つ目は、形状の種類の多さです。AWSのインスタンスタイプ(m6i、c7gなど)と同様の概念として、OCIには「形状(shape)」がありますが、Ampere A1・AMD・Intelという3つのプロセッサ系統がある上、VM形状とベアメタル形状、さらにFlexible shapeとFixed shapeという軸も組み合わさっており、VM.Standard.A1.FlexやVM.Standard.E5.Flexといった名前を初めて目にしたとき、選択肢の多さに圧倒されがちです。

2つ目は、「Arm(Ampere)は本当に実務で使えるのか」という疑問です。AWSでもGravitonへの移行が進んでいますが、OCIのAmpere A1は無料枠の主力でもあり、実際にどこまで実用に耐えるのかを判断する材料が必要になります。

3つ目は、OCPUという聞き慣れない課金・性能単位の存在です。AWSのvCPUに慣れていると、OCPUをそのままvCPUと同一視してしまい、コストや性能の見積りを誤ってしまうケースが少なくありません。この点は§2-1で正確な換算方法を扱います。

本記事を読み終えることで、これらの疑問がすべて解消され、実際にOCIコンソールで形状を選ぶ場面で迷わなくなることを目指します。

1-3. シリーズでの位置づけ — Vol1〜3の基礎からコンピュートへ

本記事は「OCI入門シリーズ」全6本構成の第4弾にあたります。ここまでの3本で、コンピュートを実際に動かすための土台を順に築いてきました。

• Vol1: OCIアカウントの最上位概念であるテナンシ・コンパートメントの階層構造、リージョン/アベイラビリティドメイン(AD)/フォルトドメイン(FD)の物理配置、そしてAlways Free枠の全体像を扱いました
• Vol2: OCIの権限管理の仕組みであるIdentity Domains、英語風の文法を持つポリシー、グループ・ダイナミックグループを扱いました
• Vol3: 仮想クラウドネットワーク(VCN)・サブネット・各種ゲートウェイ・セキュリティリストという、インスタンスを配置するネットワーク基盤を扱いました

これで、インスタンスを起動するための「入れ物」(テナンシ・コンパートメント)、「土地」(VCN・サブネット)、「鍵の管理」(IAM)が揃ったことになります。特にVol3で解説したセキュリティリスト・NSGの考え方は、本記事の§5でSSH接続を許可する際にそのまま使いますので、必要に応じて振り返ってみてください。

本Vol4では、いよいよその土台の上に実際に動かすインスタンス、すなわちコンピュートリソースそのものを扱います。Vol1-3の基礎知識はすでに確立済みという前提で進めますので、本記事では再説明しません。

本シリーズ全体の構成を表で整理すると、次のとおりです。

なお本シリーズは、本Vol4の後にストレージを扱うVol5、OKEを扱うVol6と続きます。ストレージについては本記事では扱わず、「詳細はVol5で解説予定」という形で言及にとどめますので、あらかじめご了承ください。

コンピュートとストレージを別巻に分けているのは、それぞれが独立した設計判断を要するためです。コンピュートの形状選定とストレージのボリューム設計は、検討するタイミングも判断の観点も異なるため、本シリーズでは巻を分けることで各テーマに十分な深さを確保する方針を採っています。

1-4. AWS EC2ユーザーの読みどころ

AWSのEC2に慣れている方にとって、本記事で特に印象に残ってほしい対比ポイントをあらかじめ予告しておきます。

まず最大の違いは、「Flexible shape」という考え方です。AWSのEC2では、m6i.large、c7g.xlargeといったインスタンスタイプごとにCPUとメモリの比率があらかじめ固定されています。ワークロードがその比率に合わなければ、CPU寄り・メモリ寄りいずれかの無駄を許容してインスタンスタイプを選ぶことになります。一方OCIのFlexible shapeでは、OCPU数とメモリ量を独立に指定でき、ワークロードに合わせて比率を自由に設計できます。この「タイプに縛られない」発想は、OCIのコンピュートを理解するうえで最初に押さえておきたいポイントです。

次に、OCPUという課金・性能の単位とAWSのvCPUとの換算です。単純に「1 OCPU = 2 vCPU」と一律に覚えてしまうと、実はプロセッサ系統によって換算が異なるという落とし穴があります。この点は§2-1で詳しく扱いますが、コスト比較する際に必ず押さえておくべき最重要ポイントの一つです。

さらに本記事では、各章でAWSの対応するサービス・概念との対比を随所に挟みながら解説を進めます。具体的には、次のような対比を予定しています。

• §3: Ampere A1・AMD・IntelとAWSのGraviton系・AMD EPYC系・Intel系インスタンスとの対応
• §4: ベアメタルインスタンスとAWS EC2の「.metal」系インスタンスとの対応
• §5: イメージの選択とAWSのAMI(Amazon Machine Image)との対応
• §6: Always Free枠とAWSの無料利用枠(期間制限の有無)との違い
• §7: OCPU/メモリ配分の設計思想と、AWS EC2の料金体系・インスタンスタイプ選定との対比

「AWSではこうだったが、OCIではこう考える」という橋渡しを意識して読み進めていただくと、理解がスムーズになるはずです。特にOCPU/vCPU換算とFlexible shapeの2点は、本記事全体を通じて繰り返し登場する土台となる考え方ですので、§2で一度しっかり押さえておくことをおすすめします。

それでは、§2から実際にOCIコンピュートの全体像を見ていきましょう。

← Vol3(OCIネットワーキング入門)を読む

2. OCIコンピュートの全体像 — 形状ファミリとVM/ベアメタル

2-1. 「形状(Shape)」とは — AWSのインスタンスタイプとの違い

OCIでインスタンスを起動する際、CPU・メモリ・ネットワーク帯域・ハードウェア構成をまとめて指定する単位を「形状(shape)」と呼びます。これはAWSでいう「インスタンスタイプ」(m6i.large、c7g.xlargeなど)に相当する概念です。ただし後述するように、OCIの形状には「Flexible shape」という、AWSのインスタンスタイプにはない自由度が備わっています。

コンソールでインスタンスを作成する際は、「形状の変更」というリンクから形状選択画面を開き、プロセッサ系統(Ampere/AMD/Intel)を選んだ上で、Flexible shapeであればOCPU数とメモリ量をスライダーまたは数値入力で指定します。AWSのようにあらかじめ用意された「m6i.large」のような完成品のリストから選ぶのではなく、まず系統を選び、次に自分でサイズを組み立てるという2段階の操作フローになっている点が、最初は戸惑いやすいポイントです。

OCIのコンピュートの性能・課金の単位は「OCPU(Oracle CPU)」と呼ばれます。OCPUは物理CPUコア1個を表す単位で、AWSの「vCPU」(仮想CPU)とは定義が異なります。ここで実務上もっとも重要な落とし穴になるのが、OCPUとvCPUの換算です。

多くのx86アーキテクチャ(Intel・AMD)は1つの物理コアで2つのスレッドを同時実行するハイパースレッディングに対応しており、OCIの公式ドキュメントでもx86形状については「1 OCPU = 2 vCPU」と明記されています。AWSのEC2でも、Intel・AMDベースのインスタンス(m6i、m6aなど)のvCPUは同様にハイパースレッドの本数を指しているため、OCIのAMD/Intel形状とAWSのx86インスタンスを比較する場合は「1 OCPU ≒ AWS 2 vCPU」という換算がそのまま使えます。

一方、Ampere A1(Arm)形状はハイパースレッディングを持たないため、1 OCPU = 1 vCPUです。AWSのGraviton系インスタンス(m7g、c7gなど)もArmベースでハイパースレッディングを実装していないため、vCPUは物理コア1個を指します。つまりAmpere A1とGravitonを比較する場合は、「1 OCPU ≒ AWS 1 vCPU」という、x86とは異なる換算になります。

この違いを見落として、Arm系のOCPUにも一律で2倍換算をあててしまうと、コスト・性能の見積りを実態の2倍に見誤ってしまいます。これはコスト見積り事故につながりやすい典型的な落とし穴であり、AWSとコスト対比する際は、必ず比較対象のプロセッサ系統(x86かArmか)を確認したうえで換算する習慣をつけてください。この換算ルールは§7のコスト設計でも繰り返し使用します。

具体的な数値例で確認してみます。VM.Standard.E5.Flexで4 OCPUを指定した場合、AWS換算では8 vCPU相当の性能となり、AMD系のm6a.2xlarge(8 vCPU)とおおむね近い処理能力になります。一方、同じ「4 OCPU」という数字でもVM.Standard.A1.Flex(Arm)で指定した場合は、AWS換算で4 vCPU相当となり、Graviton系のm7g.xlarge(4 vCPU)に近い処理能力です。同じOCPU数でも、系統によって実質的な処理能力が2倍近く異なる点は、見積り時に必ず意識してください。

この換算ルールは、OCI公式のCompute Shapesドキュメントに明記されている内容です。実際に見積りする際は、対象の形状ページで最新のOCPU/vCPU換算を確認することをお勧めします。

既存のAWS EC2インスタンスをもとにOCIの形状を見積もる際は、次のような手順で進めると換算ミスを避けやすくなります。

1. 移行対象のEC2インスタンスタイプのアーキテクチャ(x86かArmか)を確認する
2. x86(m6i/m6a等)であれば、vCPU数を2で割った値を目安のOCPU数とする
3. Arm(m7g/c7g等)であれば、vCPU数をそのまま目安のOCPU数とする
4. メモリ量はGB単位でそのまま対応させ、Flexible shapeでOCPU数・メモリ量を個別に指定する
5. 実測負荷を見ながら、OCPU数・メモリ量を微調整する

この手順を踏むことで、「vCPU数をそのままOCPU数として扱ってしまい、x86形状のスペックを実質半分に見積もってしまう」といった、逆方向の見積りミスも防げます。

課金の粒度についても触れておきます。OCIのFlexible shapeは秒単位(最低利用時間1分)で課金され、OCPU数は基本的に整数単位での指定になります。AWSのEC2も秒単位課金が基本ですが、インスタンスタイプという「まとまり」で課金される点が異なります。OCIでは「OCPU数×稼働時間」がそのままコストに直結するため、Flexible shapeで無駄なOCPUを積んでいないかどうかが、AWS以上にダイレクトにコストへ跳ね返ってくる構造だといえます。

形状名の読み方も押さえておくと、コンソールでの選択がスムーズになります。「VM.Standard.E5.Flex」であれば、「VM」(仮想マシン)・「Standard」(標準シリーズ)・「E5」(AMD第5世代を示す記号)・「Flex」(柔軟な形状)という要素の組み合わせです。ベアメタルであれば先頭が「BM」に、Ampere系であれば「A1」のようにプロセッサ世代の記号に置き換わります。

この命名規則を覚えておくと、コンソールやCLIの一覧からでも系統・世代を素早く読み取れるようになります。

なお、OCIにはGPUシリーズ(VM.GPU系)やHPC向けシリーズ(BM.HPC系)、大容量ストレージI/O向けのDenseIOシリーズといった特殊用途の形状も存在しますが、これらは機械学習・高性能計算・大規模データベースといった特定ワークロード向けの選択肢であり、本記事が対象とする一般的なWeb/アプリケーションサーバー用途からは外れます。本シリーズでは、汎用的なStandard/Optimizedシリーズを中心に解説を進めます。

AWSの実務者にとって、この「形状(shape)」という単位を理解する最大のメリットは、コンソールやCLIで目にする無数の選択肢を、迷わず絞り込めるようになることです。次の§2-2以降では、まずプロセッサ系統(どのCPUを使うか)、次にFlexible/Fixedの区分(比率を自由に組めるか)、最後にVM/ベアメタルの区分(専有するか共有するか)という3つの軸で段階的に整理していきます。この3軸を押さえておけば、コンソール上のどの選択肢がどの軸に対応するものかを迷わず判断できるようになります。

2-2. 3つのプロセッサ系統 — Ampere A1(Arm)・AMD・Intel

OCIのコンピュートは、プロセッサのアーキテクチャによって大きく3つの系統に分かれています。

Ampere A1(Arm) — Ampere Altraプロセッサを採用したArm系の形状です。VM形状のVM.Standard.A1.Flexと、ベアメタル形状のBM.Standard.A1.160(160コア)が提供されています。省電力・高コア密度でコスト効率に優れ、後述するAlways Free枠の主力としても採用されています。AWSではGraviton系(m7g、c7gなど)が対応する系統です。

AMD — AMD EPYCプロセッサを採用したx86系の形状です。世代によってE4(EPYC Milan相当)・E5(EPYC Genoa相当、第4世代EPYC)などのFlex形状が提供され、OCPUあたりのメモリ量や最大OCPU数が世代ごとに拡張されています。標準的なx86ワークロードをコスト効率よく動かす選択肢です。AWSではAMD系EC2(m6a、m7aなど)が対応する系統です。

Intel — Intelプロセッサ(Ice Lake世代など)を採用したx86系の形状です。VM.Standard3.Flexなどが提供されています。ベンダー認証がIntel限定のソフトウェアや、特定のIntel命令セットに依存するワークロードなど、明確な理由がある場合に選択する系統という位置づけです。AWSではIntel系EC2(m6i、m7iなど)が対応する系統です。

3系統に共通する特徴として、いずれもFlexible shapeとして提供されており、OCPU数とメモリ量を独立に指定できます。系統ごとの違いは、あくまで「どのCPUアーキテクチャ・世代を使うか」という一点に集約されており、Flexible shapeの操作感そのものは3系統で共通しています。したがって、いったんいずれかの系統でFlexible shapeの使い方に慣れてしまえば、他の系統への切り替えは形状名を変更するだけで済み、追加の学習コストはほとんど発生しません。

表形式に整理すると次のとおりです。

どの系統を実際にどう選ぶかという具体的な判断基準は§3で詳しく扱います。ここではまず、OCIのコンピュートがAWSと同様に複数のプロセッサ選択肢を持っていること、そしてArm(Ampere A1)がAWSのGravitonと同じ位置づけにあることを押さえておいてください。

各系統は、世代交代によって継続的に拡張されています。Ampere A1に続く形状として、A2・A4といった新しいArm系形状も登場していますが、Always Free枠の対象という位置づけもあり、現時点ではA1が実績・情報量ともに最も充実した選択肢です。AMD系はE4(Milan)からE5(Genoa)へ、さらに直近ではE6も登場するなど世代を重ねており、本記事では東京リージョンでの提供実績を踏まえてE4/E5を中心に扱います。Intel系についても、Standard3に加えて高クロック志向のOptimized3という形状が用意されており、用途に応じた選択肢が広がっています。

以上を踏まえて、OCPU範囲の目安も含めて整理すると次のとおりです。

数値は形状の世代やテナンシ・リージョンの容量によって変動するため、実際の上限は必ずOCIコンソールの形状選択画面またはOCI公式ドキュメントで確認してください。

コスト面での大まかな序列としては、一般にAmpere A1が最も安価で、AMD Flexがその次、Intel系がやや高めという傾向にあります。ただしこれはOCPUあたりの単価の傾向であり、実際のワークロード単位あたりのコストはアーキテクチャ間の性能差(§2-1のOCPU/vCPU換算)を踏まえて比較する必要があります。単価だけを見てArm系が常に有利と判断せず、必要な処理性能に対してどれだけのOCPU数が必要になるかまで含めて比較することが、正確なコスト比較の第一歩です。

AWSですでにGraviton系インスタンスへの移行を進めている組織であれば、OCIでの選定はより見通しやすくなります。Arm対応の検証がすでに済んでいるワークロードは、そのままAmpere A1へ展開できる可能性が高く、逆にx86依存が残っているワークロードは、AWSでAMD/Intel系を使い続けているのと同様、OCIでもAMD/Intel系を選ぶ流れになります。「AWSでGravitonに載せているものはA1へ、AWSでx86のまま残しているものはAMD/Intelへ」という単純な対応関係を出発点にすると、初回の形状選定で迷いにくくなります。

落とし穴として、旧世代のFixed shape(VM.Standard1系・VM.Standard2系など)は新規のテナンシでは選びにくくなっており、今後も積極的に使うべき形状ではありません。ドキュメントやブログの古い記事では、これらの旧形状を前提とした説明が残っていることがありますが、新規に構築する際は本記事で扱うFlexible shape(A1.Flex、E4/E5.Flex、Standard3.Flex)を選ぶのが基本方針です。情報を調べる際は、記事の公開時期がいつのものかを確認する習慣をつけておくと、古い情報に振り回されず安心です。

2-3. Flexible shape — OCPUとメモリを自由に組む(AWSにない発想)

先述のとおり、OCIの形状には「Flexible shape」と「Fixed(固定)shape」の2種類があります。Fixed shapeはVM.Standard1.1(1 OCPU・7GB)のように、OCPU数とメモリ量があらかじめ固定された旧世代の形状です。一方Flexible shapeは、OCPU数とメモリ量を利用者が独立に指定できる形状で、現在提供されている主要な形状(A1.Flex、E4.Flex、E5.Flex、Standard3.Flexなど)はすべてこのFlexible shapeに分類されます。

これはAWSのEC2にはない発想です。AWSでは、m6i.large(2 vCPU・8GB)、m6i.xlarge(4 vCPU・16GB)のように、CPU:メモリの比率がインスタンスタイプごとに固定されています。ワークロードがメモリ集約型(たとえばインメモリキャッシュ)でCPUをほとんど使わない場合でも、必要なメモリ量を確保するにはCPUも比例して増えるインスタンスタイプを選ばざるを得ず、CPUリソースが余ってしまいます。逆にCPU集約型のワークロードでは、メモリが過剰に付いてくることになります。

OCIのFlexible shapeでは、たとえば「2 OCPU・64GBメモリ」のようなメモリに大きく振った構成も、「16 OCPU・16GBメモリ」のようなメモリを絞ってCPUを厚くした構成も、同じVM.Standard.E5.Flexという1つの形状の中でOCPU数とメモリ量を個別に指定するだけで実現できます。ネットワーク帯域とVNIC数もOCPU数に応じて自動的にスケールするため、比率を気にして形状を選び直す必要がありません。

この自由度は、コスト最適化の武器になります。ワークロードの実測プロファイル(CPU使用率とメモリ使用率)に合わせて、OCPUとメモリをそれぞれチューニングできるため、AWSのインスタンスタイプ選定でありがちな中途半端なオーバープロビジョニングを避けやすくなります。この配分設計の考え方とコストへの影響は、§7でさらに具体的に扱います。

さらにFlexible shapeは、起動後のリサイズにも柔軟性を発揮します。AWSでインスタンスタイプを変更する場合、いったん停止したうえで別のインスタンスタイプへ切り替える必要があり、変更後のタイプによってはネットワークやストレージまわりの構成に細かな差異が生じることもあります。一方OCIのFlexible shapeでは、同じ形状のまま(インスタンスを停止した状態で)OCPU数とメモリ量を調整するだけでリサイズが完了し、形状自体を切り替える必要がありません。

具体例で考えてみます。当初は2 OCPU・16GBで運用を開始したアプリケーションサーバーが、アクセス増加に伴いCPU負荷が高まってきた場合、メモリ量は16GBのままOCPU数だけを4 OCPUに引き上げる、といった非対称なスケールアップが可能です。AWSであれば、CPU:メモリ比が固定されたインスタンスタイプの中から次のサイズを選ぶことになり、結果としてメモリも比例して倍増してしまうケースが多くなります。ワークロードの成長に合わせて段階的にスケールアップしていく運用と相性がよい設計です。

ワークロード特性別に、Flexible shapeでの配分の考え方を整理すると次のとおりです。

なお、OCPU数とメモリ量には形状ごとに指定可能な範囲があり、無制限に組み合わせられるわけではありません。たとえばVM.Standard.E5.Flexであれば、OCPUあたり最大64GB程度までメモリを厚くできる一方、上限を超える組み合わせは指定できません。実際に設計する際は、対象形状の最小・最大メモリ比率をOCIコンソールの形状選択画面で確認しながら調整してください。

落とし穴として、OCPU数を極端に絞り込むと、ネットワーク帯域やI/O性能もOCPU数に比例してスケールダウンする点に注意が必要です。メモリだけを厚くしてOCPUを最小限にする構成はCPU負荷が低いワークロードには有効ですが、通信量の多いワークロードでは帯域不足という別のボトルネックを招く場合があります。この点は§7-3でさらに詳しく扱います。

OCPU数の指定は基本的に整数単位(1 OCPUきざみ)で行います。AWSのように「vCPU数固定の中からタイプを選ぶ」のではなく、「1 OCPUずつ積み上げる」という発想に慣れると、必要な処理性能を過不足なく組み立てやすくなります。特に検証段階では、まず小さめのOCPU数で起動して実測負荷を確認し、そこから段階的に増やしていくアプローチが、AWSでインスタンスタイプを1段ずつ上げていく感覚に近く、違和感なく移行できるはずです。

Flexible shapeの自由度は魅力的ですが、「とりあえず多めに積んでおく」という判断は避けるべきです。AWSでもオーバースペックなインスタンスタイプを選んでコストが膨らむ失敗はよくありますが、OCIのFlexible shapeでは調整の粒度が細かい分、逆に「調整すればいつでも直せる」という油断からOCPU数を厚めに設定したまま放置してしまうケースも見られます。定期的に実際のCPU/メモリ使用率を確認し、必要に応じてリサイズする運用を、最初から前提としておくことをおすすめします。

2-4. VM形状とベアメタル — 仮想化するか専有するか

OCIのコンピュートには、VM(仮想マシン)形状とベアメタル形状という2つの提供形態があります。VM形状は、ハイパーバイザ上で動作する仮想マシンであり、1台の物理ホスト(ベアメタルサーバー)を複数のテナントで論理的に分割して利用します。AWSのEC2の大半のインスタンスタイプと同様、通常はこちらを選択します。

一方ベアメタル形状は、物理サーバーを丸ごと1テナントが専有する形態です。ハイパーバイザを挟まないため、BIOSレベルの詳細設定が可能になり、仮想化のオーバーヘッドを排した性能や、ハードウェアレベルでの分離が必要な場合に選択します。AWSでいうEC2のベアメタルインスタンス(.metal系)と同じ発想です。

VM形状とベアメタル形状は、同じプロセッサ系統であれば対応関係にあります。たとえばAmpere A1系であればVM.Standard.A1.Flex(VM)とBM.Standard.A1.160(ベアメタル、160コア)が、AMD系であればVM.Standard.E4/E5.FlexとBM.Standard.E4/E5系が、Intel系であればVM.Standard3.FlexとBM.Standard3系が、それぞれ同じ系統の中でVM/ベアメタルのペアになっています。

1台のベアメタルサーバー上には、通常複数のVMインスタンスが同居します。VM形状を選ぶということは、そのホストのCPU・メモリ・ネットワークリソースの一部を切り出して使うということであり、他のテナントのVMと物理リソースを共有する形になります。一方ベアメタルを選ぶ場合は、そのホストに乗る唯一のテナントになるため、リソースの奪い合いを気にする必要がありません。

どちらを選ぶかの詳しい判断基準は§3(VM形状の選定)と§4(ベアメタルインスタンス)で扱いますので、ここではまず「同じプロセッサ系統の中に、仮想化された形状と専有する形状の2つの提供形態がある」という全体像だけを押さえておいてください。

両者の主な違いを整理すると次のとおりです。

落とし穴として、VM形状からベアメタル形状への切り替え(あるいはその逆)は、既存インスタンスをそのまま変換するのではなく、ブートボリュームを使って新しいインスタンスを作り直す作業になります。AWSでインスタンスタイプを大きく変更する場合と同様、ダウンタイムと作業手順を事前に見積もっておく必要があります。どちらの形状で始めるかを最初にある程度見極めておくことで、後からの手戻りを減らせます。

密度のイメージをつかむため、具体例で考えてみます。BM.Standard.A1.160(160コア)を1台のベアメタルホストとすると、その上には理論上、VM.Standard.A1.Flexで4 OCPUを指定したVMを最大40台程度まで同居させられる計算になります(実際にはネットワーク・メモリ等の制約でこれより少なくなるのが一般的です)。この「1台の物理ホストを多数のテナントで分け合う」構造こそがVM形状のコスト効率の源泉であり、逆に言えばベアメタルを選ぶということは、この分け合いによるコスト効率を放棄して専有性を取るという判断であることが分かります。

セキュリティ・コンプライアンスの観点からも、この違いは実務上の意味を持ちます。VM形状では、同じ物理ホストに他テナントのVMが同居する「マルチテナント」環境が前提となりますが、OCIのハイパーバイザによる分離は一般的なパブリッククラウドの標準的な隔離レベルを満たしており、通常のワークロードで問題になることはありません。一方、監査要件や契約上の理由で「他テナントとハードウェアを共有しない」ことそのものが求められる場合は、ベアメタルを選ぶ以外に選択肢がありません。この判断軸は§4-2でさらに具体的に扱います。

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

本シリーズVol1で確認したとおり、東京リージョン(ap-tokyo-1)は2026年7月時点でアベイラビリティドメイン(AD)が1つのみの「シングルAD構成」のリージョンです。これはコンピュートの可用性設計にも影響し、AD単位での冗長化(マルチAD配置)が東京リージョンでは選択肢にならないため、可用性を高めたい場合はフォルトドメイン(FD)単位での分散や、リージョンをまたいだ構成を検討する必要があります。この点はVol1・Vol3ですでに扱っているため、本記事では詳しく触れません。

AWSでいえば、東京リージョン(ap-northeast-1)が3つのアベイラビリティゾーン(AZ)を持つのに対し、OCIの東京リージョンはADが1つのみという違いになります。AWS実務者がOCIの可用性設計を初めて検討する際、この非対称性を知らずにAWSと同じ感覚でマルチAD配置を計画してしまうと、そもそも選択肢が存在しないことに後から気づくことになりかねません。設計の初期段階でこの制約を織り込んでおくことが重要です。

形状の提供状況については、東京リージョンでもAmpere A1(VM.Standard.A1.Flex)、AMD(VM.Standard.E4.Flex/E5.Flex)、Intel(VM.Standard3.Flex)といった主要な形状ファミリが提供されています。ただしAmpere A1は需要が集中しやすい形状であり、東京リージョンを含む一部リージョンでは、ピーク時にキャパシティ不足(Out of host capacity)によりインスタンスを起動できないケースが報告されています。この点は§6のAlways Freeハンズオンでも落とし穴として扱います。

主要形状ファミリの東京リージョンでの提供状況を整理すると、次のとおりです。

キャパシティ不足でインスタンス作成に失敗した場合の対処としては、時間帯を変えて再試行する、対象のフォルトドメインを変えて試す、あるいは一時的にOCPU数を減らして起動し後からリサイズする、といった方法が実務的です。恒常的に確保が難しい場合は、AMD/Intelなど代替系統への切り替えも選択肢になります。

シングルAD構成という前提は、可用性設計の考え方にも影響します。AWSのように複数AZへインスタンスを分散配置してAD障害に備えるという選択肢が東京リージョンにはないため、可用性を高めたい場合は次のような代替策を検討することになります。

• 同一AD内のフォルトドメイン(FD)を分けてインスタンスを配置し、ラック単位の障害に備える
• 東京以外のリージョン(大阪など)へのマルチリージョン構成を検討する
• アプリケーション層での冗長化(ロードバランサー配下に複数インスタンスを配置する等)を優先する

実際にどの形状がどのADで利用可能かを事前に確認したい場合は、次のようにOCI CLIから形状一覧を取得できます。

oci compute shape list \
  --compartment-id <compartment-ocid> \
  --output table

なお、OCIの形状提供状況やキャパシティは今後も更新される可能性があるため、実際にインスタンスを作成する際は、OCIコンソールの形状選択画面またはOCI公式ドキュメントの最新情報で、東京リージョンでの提供状況を確認することをお勧めします。

AWSでも、新しいインスタンスタイプがすべてのリージョンに同時展開されるわけではなく、東京リージョン(ap-northeast-1)への展開が他リージョンより遅れることがあります。OCIの東京リージョンにおける形状提供状況も同様の考え方で捉えると理解しやすく、「グローバルに使える形状の中で、東京ではどこまで使えるか」を都度確認する習慣は、AWS実務者にとってもなじみのあるアプローチです。

本番環境を東京リージョンで構築する予定がある場合は、事前検証の段階から東京リージョンで形状の起動テストを行っておくことを強くおすすめします。他リージョンでは問題なく起動できた形状・OCPU数の組み合わせが、東京リージョンのキャパシティ事情により起動できないことも起こり得るため、検証環境と本番環境のリージョンを揃えておくことが、思わぬ手戻りを避ける最も確実な方法です。

ここまでで、形状・OCPU・Flexible shape・VM/ベアメタル・東京リージョンでの提供状況という、OCIコンピュートを理解するための基礎知識が一通り揃いました。いずれもAWSでの経験を土台に理解できる内容でありながら、OCPU/vCPU換算やシングルAD構成のように、OCI独自の注意点も含んでいます。

これらの基礎知識を、実際にどの形状を選ぶかという判断にどうつなげるかが、次章以降のテーマです。まずは§3で、VM形状のプロセッサ系統をどう選ぶかという、最も頻繁に直面する判断から見ていきます。

3. VM形状の選定 — Ampere A1・AMD・Intelをどう選ぶか

3-1. Ampere A1(Arm)を選ぶ場面 — コンテナ・Web・OSS

Ampere A1は、Arm(Ampere Altra)アーキテクチャを採用した形状ファミリです。VM形状はVM.Standard.A1.FlexというFlexible shape 1本に集約されており、OCPU数は1〜76、メモリは1GB〜472GBの範囲でOCPU数に応じて自由に組み合わせられます。目安としては、1 OCPUあたり最大約6GBのメモリを割り当てられる計算です。ベアメタル版のBM.Standard.A1.160は160コア・メモリ1024GBの固定構成で、大規模なArmワークロードを1台に集約したい場合の選択肢になります。

設計判断として押さえておきたいのは、Ampere A1の「1 OCPU = 物理コア1個」という単純な対応関係です。AMD/Intel系のOCPU定義(1 OCPU = 2 vCPU、ハイパースレッド込み)と異なり、A1はハイパースレッディングを行わないため、OCPU数がそのままコア数になります。この特性により性能を予測しやすく、単価もAMD/Intelより低廉に設定されているため、コストパフォーマンスを重視する用途では第一候補になります。

適したワークロードは、Arm対応が進んでいるOSSスタック全般です。具体的にはnginxやHAProxyなどのリバースプロキシ、Node.js/Go/Rustなどでビルドしたコンテナアプリケーション、PostgreSQLやMySQLといったOSS系DB、CI/CDのビルドランナーなどが挙げられます。特にコンテナワークロードでは、OCI Container Engine for Kubernetes(OKE)のワーカーノードにA1形状を採用するケースも増えています。

落とし穴として最も注意すべきは、x86バイナリへの依存です。商用ミドルウェアやレガシーアプリケーションの中にはArmビルドが提供されていないものがあり、移行前に必ずArm対応状況を確認する必要があります。またコンテナイメージについても、配布されているイメージがlinux/amd64専用でlinux/arm64のマニフェストを持たない場合、pull自体は成功してもエミュレーション経由での実行になり性能が大きく低下する、あるいは起動に失敗することがあります。ハンズオンで形状を確認する際は、次のようにOCI CLIから利用可能な形状一覧を取得し、対象コンパートメントでA1が有効かを事前に確認しておくと安全です。

oci compute shape list \
  --compartment-id <compartment-ocid> \
  --query "data[?contains(shape,'A1')].{Shape:shape, Type:\"processor-description\"}" \
  --output table

実行結果にはVM.Standard.A1.FlexやBM.Standard.A1.160といった形状名と対応するプロセッサ種別が一覧表示されます。この時点で対象の形状が表示されない場合、テナンシまたはリージョンでA1のサービス制限が0になっている可能性があるため、コンソールの「ガバナンスとアドミニストレーション」→「制限、割り当て、使用状況」からリソース上限を確認します。

Ampere Altraのプロセッサは1ソケットあたり最大128コアを搭載する設計で、OCIはその中からOCPU単位で切り出してVM形状に割り当てています。近年はOpenJDKやGraalVMといったJavaエコシステム、MySQL HeatWaveなどOracle自身が提供するミドルウェア類もArm向けに最適化が進んでおり、Oracle製品と組み合わせる場合はA1を選びやすい状況が整ってきています。

AWSとの対比では、Ampere A1はGraviton系インスタンス(m7g/c7g/r7gなど)と同じ設計思想に位置づけられます。すでにGravitonへの移行を済ませているワークロードであれば、Arm対応の検証は完了済みであることが多く、OCI A1への展開もスムーズに進められます。Graviton移行の経験がそのままA1選定の判断材料として転用できる点は、AWS実務者にとって理解しやすい対応関係です。

3-2. AMD形状を選ぶ場面 — x86のコスト効率

AMD系はE4(EPYC Milan)とE5(EPYC Genoa)の2世代がFlexible shapeとして提供されています。VM.Standard.E4.FlexはOCPU数1〜64・メモリ1GB〜1024GB、VM.Standard.E5.FlexはOCPU数1〜126・メモリ1GB〜1024GBの範囲で組み合わせられます。ベアメタルでもBM.Standard.E4.128(128 OCPU・2048GB)とBM.Standard.E5.192(192 OCPU・2304GB)が用意されており、大規模なx86ワークロードを1台に集約する選択肢です。

設計判断としては、x86命令セットとの互換性を保ちながらコストを抑えたい場合の第一候補です。既存のオンプレミスやAWS EC2からx86ベースのアプリケーションをそのまま移行してくるケース、あるいはArm対応が確認できていない標準的なDB(Oracle DatabaseやSQL Serverなど)を稼働させるケースで選ばれます。IntelのStandard3系と比べると同等のワークロードをより低いOCPU単価で処理できることが多く、x86が必須という制約の中ではコスト効率を優先する形状です。なお、AMD/Intel系の形状はAlways Freeの対象外であり、無料枠で試すことができるのはAmpere A1のみという点も選定時の判断材料になります。

実務でよくある具体例が、既存のOracle Databaseやサードパーティ製ミドルウェアをOCIへリフト&シフトするケースです。多くの場合ライセンス上x86アーキテクチャが前提とされているため、Arm移行はいったん保留し、まずAMD Flexで動作確認を行いながらコスト効果を見て、段階的にArm対応を検討するという進め方が現実的です。

落とし穴として、E4(Milan)とE5(Genoa)は世代が異なりコア単位の性能に差があります。Genoaの方が新しいマイクロアーキテクチャを採用しており、同じOCPU数でもE5の方が高いスループットを得られる場合があるため、古い構成例をそのまま踏襲してE4を指定すると、実質的に型落ちの性能で契約してしまう恐れがあります。新規構築時はE5を優先的に検討し、E4は既存資産との整合性が必要な場合に限定するのが無難です。

AWS対比では、AMD系はAWSのm6a/m7a、c6a/c7aといったAMD EPYC系インスタンスに相当します。AWS側でもMilan世代とGenoa世代が混在している状況は同様で、世代選定の考え方はそのまま応用できます。

3-3. Intel形状を選ぶ場面 — 認証・命令依存の時だけ

Intel系はVM.Standard3.Flex(Ice Lake、OCPU数1〜32・メモリ1GB〜512GB)とVM.Optimized3.Flex(OCPU数1〜18・メモリ1GB〜256GB)の2種類が提供されています。Optimized3は高クロック志向のワークロード向けに位置づけられており、Standard3より少ないOCPU数に絞られている代わりに1コアあたりの性能を重視した構成です。ベアメタルにはBM.Standard3.64(64 OCPU・1024GB)とBM.Optimized3.36(36 OCPU・512GB)があります。

Intel形状を積極的に選ぶべき場面は限定的です。具体的には、ソフトウェアベンダーの認証をIntelプロセッサに限定している場合、AVX-512など特定のIntel命令セットに依存する処理を伴う場合、あるいは既存のIntelベースのライセンス体系を維持する必要がある場合です。たとえば、AVX-512向けに最適化された数値演算処理を伴う科学技術計算が該当します。またIntel Xeonでの動作のみをサポート対象と明記している業務システムも当てはまります。「他に理由がなければとりあえずIntel」という選び方は推奨されません。コスト効率で見ると、Ampere A1やAMD Flexを優先すべき場面が多く、Intelは要件の明確な場合に限定して検討する選択肢です。

AWS対比では、Intel系はAWSのm6i/m7i、c6i/c7iといったIntelベースのインスタンスに相当します。AWSでも同様に、特別な理由がない限りはGravitonやAMD系がコスト効率で優位に立つ場面が多く、Intel選定の判断軸はOCIとAWSでほぼ共通しています。

3-4. 選定チェックリスト — 用途別の早見表

最終的な判断は、コスト・性能・互換性の3軸で整理すると迷いにくくなります。

迷った場合は、まずAmpere A1でArm対応を検証し、非対応であればAMD Flexへ倒すという順序で検討すると、コストを最適化しながら選定作業を進められます。この選定基準は、次章で扱うベアメタルとの使い分け、さらに§7で扱うコスト設計とあわせて検討することで、より精度の高い形状選定につながります。

4. ベアメタルインスタンス — 物理サーバーを丸ごと専有する

4-1. ベアメタルとは — 専有ハードウェアとBIOS制御

ベアメタルインスタンスは、ハイパーバイザを介さずに物理サーバーを1台まるごと専有する形状です。代表的なものとして、Ampere系のBM.Standard.A1.160(160コア・メモリ1024GB)、AMD系のBM.Standard.E4.128(128 OCPU・メモリ2048GB)とBM.Standard.E5.192(192 OCPU・メモリ2304GB)、Intel系のBM.Standard3.64(64 OCPU・メモリ1024GB)とBM.Optimized3.36(36 OCPU・メモリ512GB)、さらに高性能計算向けのBM.HPC.E5.144(144 OCPU・メモリ768GB、RDMAクラスターネットワーク対応)があります。

VM形状との最大の違いは、ハイパーバイザ層が存在しない点です。VM形状はホスト側のハイパーバイザがCPU/メモリ/ネットワークを仮想化して複数テナントに分割しますが、ベアメタルではOSが物理ハードウェアを直接制御します。この特性により、SMT(同時マルチスレッディング)の無効化、特定コアの無効化、NUMAノード単位でのメモリ配置最適化といったBIOSレベルのチューニングが可能になり、VM形状では手が届かない性能調整の余地が生まれます。

設計判断としては、ハイパーバイザのオーバーヘッドを完全に排除したい場合、あるいはハードウェアレベルでの分離が求められる場合にベアメタルが候補になります。特にレイテンシに敏感な処理や、CPUキャッシュ・メモリ帯域を隣接テナントと共有したくないワークロードでは、ベアメタルの専有性が有効に働きます。

ハンズオンの観点では、対象コンパートメント・リージョンでどのベアメタル形状が利用可能かをCLIで確認しておくと、後続の起動作業(§5)がスムーズになります。

oci compute shape list \
  --compartment-id <compartment-ocid> \
  --query "data[?contains(shape,'BM.')].shape" \
  --output table

実行結果にはBM.Standard.A1.160やBM.Standard.E4.128といった形状名が一覧表示されます。ベアメタル形状はキャパシティの制約が通常のVM形状より厳しいことが多く、必要なタイミングで確実に確保したい場合は、事前にOracleの営業窓口やサポートを通じてキャパシティ状況を確認しておくと安心です。

落とし穴としては、ベアメタルは1台単位の専有であるためVM形状のように必要な分だけOCPU数を細かく調整できず、最小構成でも該当形状のフルスペック分のリソースを確保することになります。小規模なワークロードにはオーバースペックとなりやすく、コスト効率の面では基本的にVM形状(Flexible shape)の方が有利です。ベアメタルは要件が明確な場合の選択肢と位置づけるのが実務的です。

4-2. ベアメタルを選ぶ場面 — ライセンス・分離・最高性能

ベアメタルが積極的に選択されるのは、次のような要件に該当する場合です。第一に、商用ソフトウェアのライセンス体系が物理コア単位・物理ソケット単位で課金される場合です。仮想化環境では正確なコアカウントの申告が難しく、ベアメタルであればライセンス監査への対応も明確になります。第二に、ハイパーバイザオーバーヘッドを完全に排除したい高性能計算(HPC)やレイテンシクリティカルな処理です。第三に、マルチテナント環境を避けたいセキュリティ・コンプライアンス要件がある場合です。監査上の要求事項として、他テナントとのハードウェア共有を禁止しているケースが該当します。

高性能計算向けのBM.HPC.E5.144は、複数ノードを低レイテンシのRDMAクラスターネットワークで接続できる点が特徴です。単体のベアメタル専有性能だけでなく、ノード間通信の性能が要件となる科学技術計算や機械学習の分散処理基盤としても選定されます。また、Oracle DatabaseなどをBYOL(Bring Your Own License)で持ち込む場合、物理コア数に基づくライセンス計算が必要になるケースがあり、正確なコア数が保証されるベアメタルを構成の基準として選ぶこともあります。

AWS対比では、ベアメタルはAWS EC2の「.metal」系インスタンス(m5.metal、c5.metal、i3.metalなど)と同じ発想に基づいています。判断軸も共通しており、「ライセンス要件」「ハイパーバイザ排除」「専有分離」のいずれかが該当するかどうかで検討するアプローチは、OCIとAWSのどちらでも変わりません。

落とし穴として、ベアメタルはVM形状に比べて起動までの所要時間が長くなる傾向にあり、前述の通りOCPU数を細かく調整できないため、まず小さく始めて後からスケールするようなワークロードには不向きです。要件が明確でない段階では、いったんVM.Standard.A1.FlexやVM.Standard.E5.Flexなどのフレキシブル形状で検証し、性能の天井が見えてきた時点でベアメタルへの移行を検討するという順序であれば安全です。

4-3. VMかベアメタルか — 判断のまとめ

まとめると、特別な理由がない限りはVM形状(Flexible shape)を既定の選択肢とし、ライセンス・分離・極限性能のいずれかの要件が明確になった時点でベアメタルを検討するという順序が、コストと運用の両面で無理のない進め方になります。次章では、ここまでの形状選定の判断を踏まえて、実際にインスタンスを作成する手順を解説します。

5. インスタンス作成の実践フロー — イメージ・SSH鍵・起動

5-1. 作成前の準備 — コンパートメントとネットワーク(既刊参照)

インスタンスを作成する前に、2つの前提が整っている必要があります。ひとつはリソースの置き場所となるコンパートメント(Vol1で解説)、もうひとつはインスタンスを配置するVCNとサブネット(Vol3で解説)です。これらの基礎はすでに確立済みという前提で、本章では再説明しません。まだの場合は先に既刊をご確認ください。

もうひとつの準備物がSSH鍵ペアです。OCIのインスタンス作成画面では公開鍵の登録を求められるため、事前にローカル環境で鍵ペアを用意しておきます。macOS/Linuxであればssh-keygen -t rsa -b 4096で生成でき、Windowsの場合もOpenSSHクライアントが標準搭載されているため同様のコマンドが使えます。秘密鍵は自分の端末外に持ち出さず、公開鍵(.pub拡張子のファイル)だけをOCI側に渡す点を徹底してください。

さらに、実行するIAMユーザー(またはグループ)に、対象コンパートメントでインスタンスを作成・管理できるポリシーが付与されている必要があります。Vol2で解説したIdentity Domainsのポリシー設計がここで効いてくるため、権限不足でインスタンス作成に失敗する場合はまずポリシーの割り当てを見直します。この点も基礎はVol2へ委譲し、本章では前提条件として触れるにとどめます。

5-2. イメージの選択 — Arm形状にはArm対応イメージ

OCIの「イメージ」は、インスタンス起動時に適用されるOS・ミドルウェアのテンプレートで、AWSのAMI(Amazon Machine Image)に相当する概念です。プラットフォームイメージとしてOracle Linux、Ubuntu、CentOS系などが用意されており、用途に応じてカスタムイメージを作成・共有できます。

ここで最重要の落とし穴が、CPUアーキテクチャの不一致です。Ampere A1(Arm)形状でインスタンスを起動する場合、イメージ一覧にはArm(aarch64/arm64)ビルドとx86(amd64)ビルドが並んで表示されるため、必ずArm対応ビルドを選択する必要があります。x86向けイメージをA1形状に指定しようとすると起動時にエラーとなるか、起動できても後続でインストールするバイナリがArm非対応で動作しないという事故につながります。AWSでもGravitonインスタンス向けにはarm64版AMIを選ぶ必要があり、発想としては同じ注意点です。

イメージ選定の設計判断としては、OCI標準ツール(OCI CLI、モニタリングエージェント等)との親和性を重視するならOracle Linux、コミュニティのパッケージ資産や既存の運用ノウハウを活かすならUbuntuを選ぶのが実務的な基準になります。オンプレミスやAWSからの移行であれば、移行元と同系統のディストリビューションを選ぶことで運用手順の差分を最小化できます。

5-3. 形状・ネットワーク・鍵を指定して起動

作成手順は次の順序で進みます。

1. コンパートメントを選択し、インスタンス名を入力する
2. イメージを選択する(5-2の基準に沿う)
3. 「形状の変更」から形状ファミリ(Ampere/AMD/Intel)を選び、Flexible shapeの場合はOCPU数とメモリ量を指定する(§2-3・§3の判断を適用)
4. ネットワーキング設定でVCNとサブネットを選択する。SSH接続を直接行う場合はpublicサブネットを選び、パブリックIP割り当てを有効にする
5. SSH鍵の項目で、5-1で用意した公開鍵ファイルをアップロードするか、テキストを直接貼り付ける
6. ブートボリュームのサイズを確認する(既定値のままで問題なければ変更不要)
7. 必要であれば「詳細オプションを表示」からInitialization scriptを設定する(後述)
8. 「作成」をクリックしてインスタンスをプロビジョニングする

手順7の「詳細オプション」では、初回起動時に実行するcloud-init形式のスクリプトを指定できます。これはAWS EC2の「ユーザーデータ」に相当する機能で、パッケージの自動インストールや初期設定をインスタンス作成と同時に済ませたい場合に使います。ハンズオンとしてはまず未指定のまま作成し、慣れてきたら活用する程度で問題ありません。

見落としやすい落とし穴は、パブリックIPを割り当てただけでは外部から到達できない点です。Vol3で解説したセキュリティリストまたはNSGにおいて、インバウンドのTCP 22番ポートを許可しておかないと、後述のSSH接続がタイムアウトします。接続できない原因を鍵の問題と誤認しがちですが、まずネットワーク側の許可設定を確認するのが定石です。なお本番運用を見据える場合は、インスタンスをprivateサブネットに置きOCI Bastionサービス経由で接続する構成の方が望ましいのですが、本章ではまず仕組みの理解を優先し、publicサブネット+直接SSHのシンプルな構成を扱います。

AWSのEC2起動ウィザードでは「AMI選択→インスタンスタイプ選択→ネットワーク設定→ストレージ設定→キーペア選択→セキュリティグループ設定→起動」という流れを踏みますが、OCIでは形状の選択とFlexible shapeのOCPU/メモリ指定が1つのステップに統合されている点が異なります。ステップの粒度は違えど、最終的に決める項目(イメージ・スペック・ネットワーク・鍵)はAWSと共通しています。

5-4. SSH接続 — 既定ユーザと疎通確認

インスタンスが実行中(Running)状態になったら、割り当てられたパブリックIPアドレスに対してSSH接続します。事前に秘密鍵のパーミッションをchmod 600に設定していないと、SSHクライアント側が鍵を拒否する点にも注意してください。

chmod 600 ~/.ssh/id_rsa
ssh -i ~/.ssh/id_rsa opc@<パブリックIPアドレス>

ここでの落とし穴が既定ユーザ名です。Oracle Linux系イメージの既定ユーザはopc、Ubuntu系イメージの既定ユーザはubuntuになります。AWSではAmazon Linuxがec2-user、Ubuntuがubuntu、Debianがadminというように、ディストリビューションごとにユーザ名が異なる点は共通の注意点ですが、OCI特有のopcユーザを知らずにAWSの感覚でec2-userを指定してしまい、「Permission denied (publickey)」のエラーを鍵の不備と誤解して時間を浪費するケースが実務でよく見られます。ユーザ名の候補を切り分けの最初のチェック項目にしておくと迷いません。

接続が成功すればログインバナーが表示され、インスタンス作成フローは完了です。次章では、この手順をAlways Free枠の制約内で実践します。

6. Always Free枠でのコンピュート実践 — 無料でArmを動かす

6-1. Always Free枠で使えるコンピュート — A1(Arm)とMicro

2026年7月時点でOracle公式のAlways Freeページ(https://docs.oracle.com/en-us/iaas/Content/FreeTier/freetier_topic-Always_Free_Resources.htm )を直接確認したところ、OCI Ampere A1(Arm)コンピュートの無料枠は、月間1,500 OCPU時間および9,000 GB時間分の時間クレジットとして提供されています。常時起動し続ける前提で換算すると、おおよそ「2 OCPU・メモリ12GB」相当のインスタンスを1か月動かし続けられる計算です。この構成は1台の2 OCPU/12GBインスタンスとしても、2台の1 OCPU/6GBインスタンスとしても、クレジットの範囲内であれば自由に配分できます。

インターネット上には「Always Free A1は4 OCPU・24GBまで無料」という記述が広く出回っていますが、これは2026年6月15日にOracleが無料枠を縮小する前の旧仕様であり、現時点では正確ではありません。無料枠の数値は変更される可能性があるため、実際に構築する際は必ず公式ページで最新の値を確認することをお勧めします。

x86系ではVM.Standard.E2.1.Microシェイプ(1/8 OCPU・メモリ1GB)を最大2インスタンスまで無料で起動できます。ArmのA1と異なりOCPU/メモリのFlex配分はできない固定シェイプですが、A1と併用することで軽量な複数台構成を組むことも可能です。

6-2. ハンズオン — 無料枠でAmpere A1を起動する

§5で解説した作成フローを、Always Free枠に収まる設定で実践します。手順自体は§5と同じですが、次の点を無料枠向けに読み替えます。

• イメージ: Arm対応ビルド(Oracle LinuxまたはUbuntuのaarch64版)を選択する
• 形状の変更: 「Ampere」系統からVM.Standard.A1.Flexを選ぶ。コンソール上でAlways Free対象の構成には目印(Always Free対象である旨の表示)が付くため、この表示を確認しながらOCPU数とメモリ量を指定する
• OCPU/メモリの配分: テナンシ全体でのA1無料枠上限(6-1で確認した数値)を超えないように指定する。1台構成なら上限いっぱいまで、2台構成なら分割して割り当てる
• ネットワーク・SSH鍵: §5-3・§5-4と同じ手順でVCN/サブネット・公開鍵を設定する

コンソールの形状選択画面では、Always Free対象の形状や可用性ドメインに「Always Free-eligible」というラベルが表示されます。このラベルが付いた組み合わせを選んでいるかを都度確認することで、意図せず課金対象の構成を選んでしまうミスを防げます。

無料枠特有の落とし穴が2つあります。ひとつは容量制約です。Always Free対象のArmキャパシティは共有プールから割り当てられるため、リージョンやAD(可用性ドメイン)によっては「Out of host capacity」のようなエラーで作成に失敗することがあります。この場合は時間を置いて再試行するか、別のADを試すことで解消するケースが多いです。もうひとつは課金境界です。テナンシ内のA1インスタンス群が合計で無料枠の上限(2 OCPU/12GB相当)を超えると、超過分は通常の課金対象に切り替わります。1台ごとに無料かどうかを判断するのではなく、テナンシ全体での合計消費量を常に意識する必要があります。

AWSのEC2無料利用枠は、アカウント作成から12か月間に限定された時間制の無料枠(t2.microまたはt3.microを月750時間まで等)であり、12か月を過ぎると自動的に通常課金へ切り替わります。一方でOCIのAlways Freeは期間の制限がなく、リソース量の上限(OCPU/メモリの時間クレジット)で無料範囲を区切っている点が設計思想として異なります。長期の学習用途であればOCIの方が期限切れを気にせず使い続けられる利点があります。

6-3. 無料枠の使いどころと限界

Always Free枠のコンピュートは、学習・検証環境や、個人の小規模なWebサイト・監視エージェント・CI用の軽量ランナーといった軽量な常時稼働用途に向いています。期限なく使い続けられるため、資格学習や技術検証の題材として気兼ねなく利用できる点が最大の利点です。

一方で、本番システムの土台として過信すべきではありません。無料枠のキャパシティは共有プールに依存するため、スケールアウト時の確保が保証されるわけではなく、また東京リージョンは§2-5で触れた通りシングルADのため、AD間での可用性設計そのものが選択肢にありません。Always Free枠は「気軽に試せる無料の実験場」として位置づけ、可用性やSLAが求められる本番ワークロードは、次章で扱うコスト設計を踏まえた有償構成で検討することをお勧めします。

7. パフォーマンス&コスト設計 — OCPU/メモリとAWS EC2料金対比

7-1. OCPU/メモリ配分の設計 — Flexで無駄を削る

Flexible shapeの最大の価値は、OCPU数とメモリ量を独立して指定できる設計にあります。コスト設計の第一歩は、対象ワークロードがCPU律速なのかメモリ律速なのかを見極め、その特性に合わせた比率を組むことです。

たとえば、リクエストをさばくだけの軽量なWeb/APIサーバーであればOCPUは少なめでメモリはそこそこ厚めに、逆に画像・動画のエンコードやバッチ集計のようなCPU律速のワークロードであればOCPUを厚くしメモリは最小限に絞る、といった配分の最適化ができます。インメモリキャッシュ(Redis等)のようにメモリだけを大きく確保したい用途でも、OCPUを増やさずにメモリ量だけを引き上げる構成が可能です。

AWS EC2ではインスタンスタイプごとにCPU:メモリの比率があらかじめ固定されています(たとえばm6i系はおおむね1 vCPUあたり4GB、r6i系は1 vCPUあたり8GB、c6i系は1 vCPUあたり2GB)。ワークロードの実際の比率がこれらのいずれにも合わない場合、必要なメモリ量を確保するために上位のインスタンスタイプへ乗り換えざるを得ず、結果として不要なvCPUまで課金対象になる「オーバープロビジョニング」が発生しがちです。OCIのFlexible shapeはこの構造的な無駄を排除でき、実測したCPU使用率・メモリ使用率をもとに1 OCPU単位・1GB単位で必要な分だけを組み立てられます。

設計上の落とし穴として、OCPU数を極端に絞り込むとネットワーク帯域やI/O性能もOCPU数に比例してスケールダウンする点に注意が必要です(詳細は7-3で扱います)。メモリだけを厚くしてOCPUを最小限にする構成はCPU負荷が低いワークロードには有効ですが、通信量の多いワークロードでは帯域不足という別のボトルネックを招く場合があります。

7-2. 課金モデルとコスト効率 — AWS EC2との比較

OCIコンピュートの課金は、稼働した分をOCPU時間とGB時間で積み上げる時間単位の従量制です。支払い方式は大きく2つに分かれます。ひとつは、コミットメントなしで実際に使った分をリスト価格でそのまま請求される「Pay As You Go(PAYG)」です。もうひとつは、年間の利用金額をあらかじめコミットして前払いする「Universal Credits(Annual Flex)」で、実質的な単価はPAYGのおよそ66%程度まで下がりますが、コミット期間内に消化しきれなかったクレジットは繰り越せず失効します。

AWSでいえば、PAYGはコミットなしで都度課金されるOn-Demandに、Annual FlexはSavings Plans(1年または3年のコミットで最大66〜72%の割引)にそれぞれ相当する設計です。ただし、AWSのSavings Plansは未消化分を気にする必要がないのに対し、OCIの年間コミットは使い切れなかった分がそのまま失効する点は、コミット額を検討する際に見落としやすい違いです。

もうひとつの割引手段が「Preemptible Instances」で、オンデマンド価格から一律50%引きになります。2分前通知で中断されうる点はAWSのSpotインスタンスと同じ発想ですが、AWSのSpotは需給に応じて価格が変動し最大90%引きになることもある代わりに予測しづらいのに対し、OCIのPreemptible Instancesは常に一律50%引きで金額をあらかじめ確定できる点が異なります。バッチ処理やCI、ETLのような中断耐性のあるワークロードでは、まずPreemptible Instancesの適用を検討する価値があります。

そしてコスト比較で最も見落としやすいのが、OCPUとvCPUの換算です。x86系(AMD/Intel)の形状は物理コア1個がハイパースレッディングで2スレッドを提供するため、1 OCPU ≒ AWSの2 vCPUという換算が成立します。ところが、本記事の主役であるAmpere A1はシングルスレッド設計のコアのため、1 OCPU ≒ 1 vCPUとなり、x86と同じ換算は当てはまりません(後継のArm A2/A4系では再び1 OCPU ≒ 2 vCPUに戻ります)。たとえば4 OCPUのA1インスタンスは4 vCPU相当でAWSのGraviton系m7g.xlarge(4 vCPU)とほぼ同じ土俵で比較できますが、4 OCPUのAMD E4インスタンスは8 vCPU相当となり、比較対象はm6a.2xlarge(8 vCPU)になります。この違いを踏まえずに「1 OCPU=2 vCPU」を一律に当てはめると、Arm形状のvCPU数を実際の2倍に見積もったり、コスト効率を過大・過小評価したりする見積り事故につながるため、必ずプロセッサ系統ごとに換算を確認してください。

なお、OCPU単価そのものもプロセッサ系統によって大きく異なり、Ampere A1がもっとも安価な単価帯、AMD E4/E5はその数倍の単価帯に位置づけられます(2026年7月時点の目安。正確な単価はOracle公式のPrice Listで随時ご確認ください)。

7-3. パフォーマンス設計 — 一定性能・帯域・NUMA

OCIのVM/ベアメタル形状は、指定したOCPU分の処理性能を常時安定して得られる「一定性能」の設計です。AWSのバースト型インスタンス(T2/T3/T4g等)のように、平常時は低い基準性能に抑えつつCPUクレジットを消費してバーストする、といった性能変動モデルはOCIには存在せず、割り当てたOCPUがそのまま常時性能に直結します。負荷が読みにくいワークロードでは、バーストモデルのような「クレジット枯渇による急な性能低下」を心配する必要がない一方、常に相応のOCPUを確保しておく必要があるとも言えます。

ネットワーク帯域も設計要素のひとつです。VM.Standard.A1.Flexの場合、1 OCPUあたりおよそ1Gbpsの帯域が割り当てられる設計になっており、OCPU数を増やすほど帯域も比例して広がります。7-1で触れたようにOCPU数を極端に絞り込む配分は、通信量の多いワークロードでは帯域不足という別のボトルネックを生む可能性があるため、CPU/メモリだけでなく帯域の観点も含めて配分を検討してください。

ベアメタルインスタンス(4章)では、ハイパーバイザを介さず物理ハードウェアを直接制御できるため、BIOS設定でのNUMA最適化やコア配置の調整によって、VM形状では手が届かない追加の性能チューニングが可能です。マルチソケット構成のワークロードでメモリアクセスのレイテンシを詰めたい場合など、性能を突き詰める局面ではベアメタルの選択肢が効いてきます。

AWSでは、Nitro Systemという専用ハードウェアオフロードの仕組みでVM上でも高い性能を実現するアプローチを取っていますが、OCIはOCPU/メモリの明示的な配分設計とベアメタルという専有ハードウェアの選択肢によって性能を作り込む発想が中心になっています。どちらも「仮想化のオーバーヘッドをいかに抑えるか」という同じ課題に対する異なるアプローチと考えれば理解しやすくなります。

7-4. まとめ — 形状選定とコスト設計の総合早見

ここまでの選定基準(3章)、配分設計(7-1)、課金モデル(7-2)、パフォーマンス設計(7-3)を、コンピュート設計の要点として整理します。

設計判断の起点は、まずプロセッサ系統(3章)を決め、次にOCPU/メモリの配分(7-1)を組み、最後に課金モデル(7-2)とパフォーマンス要件(7-3)を踏まえてPAYG・Annual Flex・Preemptible Instancesのいずれで運用するかを選ぶ、という順序です。AWSから移行する場合は、現行インスタンスのvCPU数・メモリ量・CPU使用率を棚卸しし、本節の換算表を使ってOCI側の等価な配分に落とし込むところから着手すると、見積りのズレを抑えられます。

8. まとめ — OCIコンピュートの基礎と次のステップ

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

本記事では、OCIコンピュートを4つの軸から整理しました。まず全体像として、Ampere A1(Arm)・AMD・Intelという3つのプロセッサ系統と、それらを組み合わせるVM形状・ベアメタルという2つの提供形態、そしてAWSのインスタンスタイプにはないFlexible shapeの自由度を確認しました。

続いて、VM形状の選定では「Arm対応かつコスト効率を優先するならAmpere A1、既存x86資産を活かすならAMD、ベンダー認証やIntel命令に依存する場合のみIntel」という判断軸を示し、ベアメタルについては、ハイパーバイザを介さない専有ハードウェアが必要な場面(ライセンス要件・性能チューニング・分離要件)に絞って選ぶべき理由を整理しました。

実践面では、コンパートメント・VCN・SSH鍵の準備からイメージ選択、起動、接続確認までの一連の流れを追い、Always Free枠ではAmpere A1を使って無料の範囲内で実際にインスタンスを起動できることを確認しました。

そして7章では、OCPU/メモリの配分設計、課金モデル(PAYG・Annual Flex・Preemptible Instances)、パフォーマンス設計の3つの観点から、AWS EC2との詳細なコスト対比をしました。プロセッサ系統によってOCPU:vCPUの換算比が異なる点は、コスト見積りにおいて特に注意が必要なポイントとして押さえておいてください。

8-2. 次のステップ — Vol5(OCIストレージ入門)へ

本記事ではコンピュートに専念し、ストレージについては意図的に扱いませんでした。OCIでは、コンピュートインスタンスへアタッチするブロックストレージ、オブジェクトストレージ、そしてNFS互換のファイルストレージという3種類のストレージサービスがあり、それぞれAWSのEBS・S3・EFSに相当する位置づけです。

コンピュートとストレージは表裏一体の関係にあり、たとえばブロックストレージの性能特性(IOPS/スループット)はアタッチ先のインスタンスの形状やOCPU数とも密接に関わってきます。次巻のVol5では、これらのストレージサービスの選び方と、AWSの対応サービスとの詳細な対比を扱う予定です。

Vol1でテナンシとコンパートメント、Vol2でIAM Identity Domains、Vol3でVCNとネットワーキング、そして本Vol4でコンピュートという流れで、OCIを使いこなすための基礎的な足場がひと通り揃いました。次はストレージ、さらにその先のOKE(マネージドKubernetes)へと進み、AWSで培った知見をOCI側でも活かせる形に広げていきます。

← Vol3(OCIネットワーキング入門)を読む
→ 次巻: OCI入門 Vol5 ストレージ入門