OCI Container Instances実践Vol1 Fargate比較と三者比較で選ぶ

1. この記事について — なぜOCI Container Instancesか

OCIには、コンテナを動かすための選択肢が複数存在します。Kubernetesクラスターをフルマネージドで運用するOKE(Oracle Container Engine for Kubernetes)、関数ごとにコードを実行するFunctions、そして本記事の主役であるContainer Instancesの3つです。Container Instancesは、Kubernetesのオーケストレーション機構を経由せず、コンテナイメージを直接指定するだけで起動できる、単発・常駐型のコンテナ実行基盤です。AWSでいえば、ECS FargateのスタンドアロンタスクをEKS/ECSクラスターを用意せずそのまま動かすイメージに近いサービスです。

本記事は、「OCI Container Instances実践」シリーズの第1弾として、Container InstancesをECS Fargateとの料金・起動フロー・制約の面で比較しながら、OKE・Functionsを含めた三者比較で「いつどれを選ぶか」を整理し、実際にコンテナイメージからContainer Instanceを起動するところまでを扱います。

「サーバーレスコンテナ」という言葉は、OCI・AWSいずれのクラウドでも複数のサービスにまたがって使われることがあり、名前だけでは実体を判断しづらい領域です。本記事は、Container Instancesを単体で紹介するのではなく、常に「OKEやFunctionsと比べてどう違うのか」という視点を持ちながら、実務での選択基準として使える形に整理することを重視しています。

1-1. 本記事のゴール

本記事は、Container Instancesという単一サービスの機能紹介にとどまらず、「OCIでコンテナを動かしたいときに、どの基盤を選ぶべきか」という設計判断そのものを扱うことをゴールにしています。読み終えた時点で、次の状態になっていることを目指します。

• Container Instancesの料金体系(標準シェイプ課金・停止中課金停止の仕組み)を正確に理解し、自分でおおよその費用を試算できる
• Container Instances・OKE・Functionsという3つの実行基盤について、実行モデル・起動単位・課金・運用負荷の違いを説明でき、案件に応じて選択できる
• コンテナイメージからContainer Instanceを起動し、環境変数やリソース割当を設定したうえで、動作確認・停止による課金制御までを一通り実践できる
• 「Fargateと同じ感覚で使える」という思い込みで見落としがちな制約(再起動ポリシー、シークレット注入経路の違いなど)を把握し、本番運用前に対策できる

Container Instancesは、2022年12月にGA(一般提供開始)したサービスで、2023年にかけて機能が拡充された後、2024年3月のコンテナレベルメトリクス追加を最後に、目立った新機能追加は見られない状態が続いています。これは「サービスが放置されている」ということではなく、コア機能はすでに安定期に入り、破壊的な仕様変更が起きにくいサービスになっていると捉えることもできます。本記事は、この事実を伏せずに提示したうえで、それでも採用する価値がある場面はどこかを、三者比較を通じて具体的に示していきます。

具体的な典型ユースケースとしては、次のようなケースを想定しています。いずれも「Kubernetesクラスターを常設するほどではないが、関数の短時間実行では収まらない」という条件に当てはまる場面です。

• 社内向けの管理画面やダッシュボードなど、常時稼働は必要だが負荷変動が小さく、オートスケーリングの複雑さを持ち込みたくないアプリケーション
• 夜間バッチ・日次集計処理など、一定時間だけコンテナを起動し、処理完了後は停止して課金を止めたい定期処理
• 新しいコンテナイメージの動作確認や、負荷試験の踏み台として、素早く使い捨てのコンテナ環境を立てたい検証用途
• 既存のOKEクラスターとは切り離して、独立した1つのサービスとして小規模なAPIサーバーを運用したいケース

これらのユースケースに共通するのは、「常時稼働のコンテナが必要だが、そのためだけにKubernetesクラスターを新設するのは過剰」という判断です。逆に、複数のマイクロサービスが相互に通信し、サービスメッシュやきめ細かなスケーリングポリシーが必要になってくると、Container Instancesの単純さでは対応しきれなくなり、OKEへの移行を検討すべき局面に入ります。この境界線をどこに引くかが、本記事の§3で扱う三者比較の核心部分です。

1-2. 読者像

本記事は、AWSでECS Fargateを使ったコンテナ運用の経験があり、OCIでの対応実装を実務レベルで把握したいエンジニアを主な読者として想定しています。具体的には、マルチクラウド戦略の一環でOCI上にもコンテナワークロードを持ちたいと考えているエンジニア、あるいはOCI案件でコンテナの実行基盤選定を任されたインフラ/クラウドエンジニアなどです。

特に、次のような疑問を持つ方に向けて、本記事は具体的な答えを用意しています。

• OCIでKubernetesクラスターを構築せずにコンテナを1つだけ動かしたい場合、どのサービスを使えばよいのか
• Container InstancesはECS Fargateと同じ感覚で使えるのか、それとも運用上の勘所が変わるのか
• OCIでコンテナを動かす選択肢(Container Instances/OKE/Functions)は、それぞれどういう基準で使い分ければよいのか
• Always Free枠だけでContainer Instancesを試せるのか、それとも課金が必要になるのか
• Container Instancesは今も活発に機能追加されているサービスなのか、それとも採用を避けるべき停滞サービスなのか

こうした読者は、多くの場合「AWSで動かしている構成を、そのままOCIに置き換えられるか試したい」という動機で本記事にたどり着きます。マルチクラウド戦略においては、機能の有無だけでなく、料金体系や運用上の制約の違いを正確に把握することが意思決定の質を左右するため、本記事は起動手順だけでなく、そうした判断材料の提供にも重点を置いています。

なお、本記事は「OCI入門」シリーズでテナンシ・コンパートメント・IAMポリシーの基礎、および「OCI DevOps実践 Vol1」でOCIR(Oracle Cloud Infrastructure Registry)へのコンテナイメージpushの手順を扱い済みであることを前提としています。OCIRへのpush自体の再説明は行わず、本記事に固有の範囲(Container Instancesの作成・設定・運用)に絞って解説します。

これらの前提を満たしていない場合でも、各章で必要な範囲は都度補足しますが、ECS Fargateでのタスク定義・起動経験がない場合は、§3・§5で行うFargateとの対比部分の理解に多少の予備知識が必要になる点はご了承ください。

OCIそのものが初めての方は、まず「OCI入門」シリーズのVol1(テナンシ・コンパートメント・Always Free枠)から着手することをお勧めします。本記事は、テナンシとコンパートメントの基本的な操作にはすでに慣れていることを前提として進めます。

逆に言えば、本記事でContainer Instances自体を初めて触るという方でも、問題なく読み進められます。Container Instances固有の概念(標準シェイプ課金、コンテナインスタンスのライフサイクル状態など)は、本記事の各章で必要な範囲を都度説明します。すでにOKEでKubernetesクラスターを運用しており、Container Instancesとの使い分けだけを知りたいという読者は、§3の三者比較から読み始めても内容を把握できる構成にしています。

1-3. なぜ今これを書くか

本記事を今書く理由は、大きく3つあります。

1つ目は、Container Instances・OKE・Functionsという3つの実行基盤を横断して比較し、「いつどれを選ぶか」を体系的に整理した日本語記事が、現時点で見当たらないことです。個々のサービスの単体チュートリアルは存在しますが、実行モデル・起動単位・課金・運用負荷という共通の軸で3つを並べ、意思決定の材料として提示している記事は多くありません。

2つ目は、用語の衝突を正しく整理する必要があることです。OKEには「仮想ノード」という機能があり、これはKubernetesクラスター内でサーバーレスにPodを実行する仕組みで、AWSでいえばEKS Fargateに相当します。一方、本記事で扱うContainer InstancesはKubernetesを介さない単発のコンテナ実行サービスで、AWSでいえばECS Fargateのスタンドアロンタスクに相当します。両者は「サーバーレスコンテナ」という言葉で括られがちですが、実体はまったくの別物です。本記事の§3では、この対応関係を明確に書き分けます。

3つ目は、料金と機能履歴について、正直な情報を提示することです。Container Instancesは2022年12月6日にGAし、2023年にかけて機能を拡充しましたが、2024年3月8日のコンテナレベルメトリクス追加を最後に、目立った新機能追加のない状態が続いています。廃止やメンテナンスモードへの移行といった公式なアナウンスは確認できていませんが、この機能追加の停滞という事実を伏せて「今が旬のサービス」であるかのように紹介するのは、読者の判断を誤らせます。本記事では、この事実を明示したうえで、それでも安定期のサービスとして採用する価値がある場面を具体的に示します。

この3つの軸——三者比較記事の希少性・用語衝突の整理・機能履歴の正直な提示——が、本記事を今このタイミングで書く理由です。特に用語衝突の整理については、実際に案件でOKEとContainer Instancesのどちらを選ぶべきか相談を受けた際、双方の担当者が「サーバーレスコンテナ」という同じ言葉で異なるものを指していて話が噛み合わない、という場面を避けるために欠かせない整理だと考えています。

本記事は、次の構成で進みます。§2でContainer Instancesの料金体系(Always Free対象外という前提・標準シェイプ課金・停止中課金停止・Fargate対比)を整理し、§3でOKE・Functionsとの三者比較と使い分け決定表を示します。続く§4でコンテナイメージからContainer Instanceを起動するハンズオンを行い、§5で「Fargateと同じつもりで使うと躓く」運用上の制約を扱い、§6で採用判断のためのチェックリストとしてまとめます。

1-4. 本記事の対象外

本記事は、あくまで「Vol1」として、Container Instancesの基本的な料金理解・三者比較による使い分け判断・単一コンテナのハンズオンまでをスコープとしています。次のようなテーマは本記事のスコープ外とし、読者からの要望を踏まえて続編での取り扱いを検討します。

• 複数コンテナ(メインアプリケーション+サイドカー)を組み合わせた本格的なマルチコンテナ構成の設計パターン
• OCIRへのpushからContainer Instance起動までを自動化するCI/CDパイプラインとの統合(前述の通り「OCI DevOps実践 Vol1」のパイプラインを応用する形になります)
• プライベートサブネットのみで完結させる、インターネットゲートウェイを持たないネットワーク設計の詳細
• Container InstancesとOKEを併用し、段階的にKubernetesへ移行していくアーキテクチャ設計

これらのテーマは、いずれも本記事で扱う基本的な料金理解と起動手順が前提となるため、まず本記事でContainer Instancesの基礎を固めたうえで取り組むことをお勧めします。本記事があえてマルチコンテナ構成やCI/CD統合まで踏み込まないのは、これらのテーマを扱う前に、まずContainer Instancesという基盤そのものの料金感覚と、OKE・Functionsとの使い分け判断を確実に押さえておくべきだと考えているためです。

料金の話から始めるのは、実行基盤の選定において「機能でできるかどうか」だけでなく「その構成をどの程度の費用で維持できるか」が、実務上は同じくらい重要な判断材料になるためです。特にContainer Instancesは、後述の通りAlways Free対象外というOCIの中でも数少ない特性を持つサービスであるため、料金の全体像を先に押さえておくことが、後続の三者比較やハンズオンをより実感を持って読み進めるための土台になります。

それでは、次の§2でContainer Instancesの料金体系を正確に押さえたうえで、§3でOKE・Functionsとの三者比較に進みます。

2. サービス仕様と料金 — standard shape課金を先に知る

Container Instancesを実際に使い始める前に、まず押さえておくべきなのが料金体系です。Container Instancesには専用の課金SKU(Stock Keeping Unit)が存在せず、標準的なコンピュートシェイプのSKUがそのまま適用されます。この仕組みを理解しないまま「サーバーレスだから安いはず」「Always Freeで試せるはず」と思い込んで進めると、想定外の課金や、そもそも無料枠で完結できない構成に気づかないまま検証を始めてしまうことになりかねません。本章では、Always Free対象外という前提、実際の単価、最大リソース上限、停止中の課金停止という仕様、そしてECS Fargateとの料金対比までを、公式情報に基づいて整理します。

2-1. Always Free対象外という前提

まず明確にしておく必要があるのは、Container InstancesはOCIのAlways Free(永年無料)対象には含まれていないという点です。OCIのAlways Freeが対象とするコンピュートリソースは、VM.Standard.E2.1.Micro(AMD)およびVM.Standard.A1.Flex(Arm)のVMインスタンスのみであり、公式のAlways Free対象リソース一覧にContainer Instancesは含まれていません(2026年8月時点の公式ドキュメントで確認済みです)。

一方で、Container Instancesの作成ダイアログを開いて設定内容を確認する段階(実際にインスタンスを起動するまで)では課金は発生しません。課金が発生するのは、あくまでコンテナインスタンスが実際に起動し、稼働状態になった時点からです。この点は§2-4で改めて扱います。

AWSの経験がある読者は、「無料のFargateスポット枠のようなものはないのか」と考えるかもしれませんが、Container Instancesにはそうした特別な無料枠・割引起動タイプは用意されていません。あくまで通常のコンピュートシェイプと同じ従量課金が、起動から停止までの間、継続して発生する仕組みです。この前提を最初に押さえておくことが、後述する料金試算(§2-6)を正しく理解するための出発点になります。

2-2. E4/E3 Flex・A1 Flexのシェイプと公式単価

Container Instancesは、「standard shapes」と呼ばれる、通常のコンピュートインスタンスと共通のシェイプ体系を使って課金されます。本記事執筆時点でContainer Instancesがサポートする主なシェイプと、Oracle公式の価格表(Price List)に基づく単価は次の通りです。

いずれのシェイプも「Flex」の名の通り、OCPU数とメモリ量を個別に指定できる可変シェイプです。E4/E3 Flexはx86アーキテクチャの汎用シェイプ、A1 FlexはArmベースのAmpereプロセッサを使うシェイプで、A1 Flexのほうが低いOCPU単価に設定されています。なお、これらの単価はContainer Instances専用のものではなく、通常のコンピュートインスタンス(VM.Standard.E4.Flex等)と共通のSKUに基づいています。公式Overviewドキュメントにも、Container Instancesの課金は使用するシェイプに依存する旨が明記されています。

Oracle公式の価格表では、OCPU課金とメモリ課金がそれぞれ個別のSKU(Stock Keeping Unit)として管理されています。E4 Flex/E3 FlexのOCPU課金とメモリ課金は、それぞれ別々のSKUコードに対応しており、A1 Flexも同様にOCPU課金・メモリ課金で別のSKUコードが割り当てられています。Container Instances専用のSKUは存在せず、通常のコンピュートインスタンスと同じSKUが請求書上にも表示される点は、コスト管理・タグ付けの設計時に把握しておくとよいポイントです。

2-3. 最大OCPU/メモリ/コンテナ数の上限

Container Instance 1つあたりに割り当てられるOCPU・メモリには上限があります。公式ドキュメントに基づく、シェイプごとの最大値は次の通りです。

また、1つのContainer Instance内に配置できるコンテナの数にも上限があり、公式ドキュメントでは「1つのコンテナインスタンスにつき、最大60個のコンテナを作成できる」と明記されています。複数のサイドカーコンテナ(ログ収集・プロキシなど)をメインコンテナと同居させる構成でも、この上限内であれば問題なく設計できます。本記事のハンズオン(§4)で扱うのは単一コンテナの構成ですが、将来的にサイドカーパターンを採用する場合でも、60個という上限は実用上ほとんど問題にならない水準です。

なお、「拡張OCPU」とは、通常のOCPU割当に加えて、バーストトラフィックへの対応などのために追加で確保できるOCPU単位を指す概念です。前掲の表の最大値は、この拡張OCPU分を含んだ理論上の上限であり、実際に利用可能な上限はテナンシのサービス制限や、選択したリージョンの物理キャパシティにも依存します。大規模なワークロードを計画する際は、理論上の最大値だけでなく、実際にコンソールから確認できる利用可能量もあわせて確認してください。

なお、これらはあくまで1インスタンスあたりの上限であり、テナンシ全体で確保できるOCPU・メモリの総量には別途、サービス制限(Service Limits)が設定されています。この制限はコンピュートインスタンスとContainer Instancesで共有されており、支払い形態(Pay As You Go/Universal Credits)によって既定値が異なります。大規模に複数のContainer Instancesを並行稼働させる計画がある場合は、事前にOCIコンソールの「制限、割当量、使用状況」画面で現在の上限を確認し、必要に応じて引き上げ申請を行ってください。

公式ドキュメントで確認できる、テナンシ全体の既定サービス制限(コンピュートインスタンスとContainer Instances共有分)は次の通りです。

Pay As You Go(従量課金のみ・クレジット契約なし)のテナンシでは、この既定値がそのまま上限になります。本記事のハンズオンで使う1 OCPU・数GB程度の構成であれば、いずれの支払い形態でも既定値の範囲内に余裕で収まります。

これらの上限は、あくまで既定値であり、正当な業務上の必要性があれば、OCIコンソールから上限緩和のリクエストを申請できます。多くの場合、リクエストの承認には数営業日を要するため、大規模な検証やスケールテストを計画している場合は、実施日の直前ではなく余裕を持って事前に申請しておくことをお勧めします。

Container Instanceには、OCPU・メモリとは別に「エフェメラルストレージ」と呼ばれる一時ストレージも割り当てられます。公式ドキュメントによれば、この割当量はシェイプに関わらず全Container Instance共通で15GBであり、コンテナイメージ本体・コンテナログ・rootオーバーレイファイルシステム・emptyDirボリュームなどの用途で消費されます。公式ドキュメントは、コンテナイメージのサイズをこの半分程度、目安として7.5GB以下に収めることを推奨しており、これを超える大きなイメージを使うとpull失敗や起動失敗(FAILED状態)の原因になり得ます。本記事のハンズオン(§4)で使うイメージについても、着手前にサイズを確認しておくことをお勧めします。

また、本記事執筆時点の公式シェイプ一覧には、最大94 OCPU・1,504GBメモリという、E4 Flex(64 OCPU/1,024GB)を上回る大型シェイプ「CI.Standard.E5.Flex」も掲載されています。ただし、E5.Flexは提供リージョンが限定されており、公式ドキュメントに列挙された対象リージョン一覧(us-dallas-1、ap-delhi-1、ap-chennai-1など17リージョン)を実際に確認したところ、東京(ap-tokyo-1)・大阪(ap-osaka-1)はいずれも含まれていませんでした。

2-4. 停止による課金停止という仕様

Container Instancesの標準シェイプには、インスタンスを停止すると課金も停止するという特徴があります。公式Overviewドキュメントには、「standard shapesはコンテナインスタンスが停止すると課金を一時停止する」という趣旨の記載が明記されています。Container Instanceの課金について、公式ドキュメントで確認できる事実を整理すると、次の通りです。

• 課金は、選択したシェイプ(OCPU・メモリ)に基づき、コンテナインスタンスが稼働している間に発生します
• インスタンスを停止すると、standard shapesの課金は一時停止します(公式Overviewドキュメントに明記)
• 停止中・失敗(FAILED)状態のインスタンスも、削除しない限りサービス制限(作成できるインスタンス数の上限)にはカウントされ続けます

これは、EC2インスタンスの停止時課金停止と同じ発想であり、Fargateのタスクのように「起動している間だけ課金される」感覚に近いものです。ただし、停止中のContainer Instancesであっても、サービス制限(作成できるインスタンス数の上限)の対象としてカウントされ続ける点には注意が必要です。使わなくなったContainer Instanceは、停止するだけでなく削除まで行わないと、上限を圧迫し続けることになります。

停止操作自体は、OCIコンソールの「開発者サービス」→「コンテナ・インスタンス」から対象インスタンスを選び、「停止」を選択するだけで完了します。OCI CLIやSDKからも同等の操作が可能で、定期的なバッチ処理であれば、処理完了後に自動的に停止するスクリプトを組み込んでおくことで、停止忘れによる課金の積み上がりを防げます。この「停止し忘れによる課金」は、§6のチェックリストでも改めて取り上げる、実務上もっとも起きやすい落とし穴の1つです。

2-5. Fargateとの料金対比

ECS Fargateと料金を比較するにあたり、AWS公式の価格情報(執筆時点でのAWS Pricing情報、東京リージョン ap-northeast-1)を確認したところ、Linux/x86タスクとLinux/ARM(Graviton)タスクで次の単価が適用されています。

たとえば「1 OCPU(vCPU)+ 8GBメモリ」を1時間稼働させた場合の単純比較は、次のようになります。

x86同士で比較すると、OCI Container InstancesはECS Fargateのおよそ4割弱の単価、Arm同士で比較してもおよそ3割弱の単価という結果になります。ただし、この比較はあくまで単純な時間単価の比較であり、OCPUとvCPUの処理能力換算、ネットワーク・ストレージなど他のコンポーネントの費用、Savings Plansのような割引制度の有無までは含んでいません。実際の移行検討では、ワークロード全体のコストを含めて比較する必要があります。

同じ「1 OCPU(vCPU)+ 8GB」構成を、検証用途ではなく1ヶ月(730時間)常時稼働させ続けた場合の概算費用は、次の通りです。

なお、AWSにはFargate向けにCompute Savings Plansという1年/3年契約の割引制度があり、条件次第でオンデマンド価格から大きく割り引かれます。OCI側にも、Universal Creditsの年間コミットメント契約に応じて単価が変動する仕組みはありますが、本記事の比較はいずれもオンデマンド(Pay As You Go)の単価同士の比較である点に留意してください。長期の常時稼働ワークロードを前提に移行を検討する場合は、双方の割引制度を加味した見積もりを別途行う必要があります。

また、この料金対比はコンピュート部分(OCPU/vCPUとメモリ)のみを対象としており、ネットワーク転送量やロードバランサー、永続ストレージなど、実際のワークロードで発生しうる周辺コストは含んでいません。移行検討の初期段階でおおまかな水準感を掴むための比較としては有用ですが、本番移行の意思決定には、周辺コストも含めた総所有コスト(TCO)ベースでの試算を別途行うことをお勧めします。

2-6. 料金試算 — 数時間のハンズオンでいくらかかるか

本記事の§4で行うハンズオンを想定し、実際にどの程度の費用がかかるかを試算します。E4 Flexシェイプで1 OCPU・4GBメモリのContainer Instanceを2時間稼働させた場合の費用は、次の計算になります。

OCPU: $0.025 × 1 OCPU × 2時間 = $0.05
メモリ: $0.0015 × 4GB × 2時間 = $0.012
合計: 約 $0.062(2026年8月時点の為替レートでおよそ9円前後)

A1 Flexシェイプ(同条件)であれば、次の通りさらに安価になります。

OCPU: $0.010 × 1 OCPU × 2時間 = $0.02
メモリ: $0.0015 × 4GB × 2時間 = $0.012
合計: 約 $0.032

いずれの試算も1ドルに満たない金額であり、動作確認を含む数時間のハンズオンであれば数十円程度で完結します。OCIには新規登録者向けに一定期間・一定額のクレジットが付与されるトライアル制度もあり、通常はこの範囲内で本記事のハンズオンを問題なく完了できます。ただし、Always Free対象外である以上、課金が発生する前提でクレジットカード等の支払い情報を登録済みのアカウントが必要になる点は、あらかじめ認識しておいてください。

2-7. GA以降の機能履歴 — 正直な整理

Container Instancesは、2022年12月6日に一般提供(GA)が開始されたサービスです。GA後の2023年にかけては、リージョン展開の拡大や周辺機能の拡充が行われましたが、直近で確認できる大きな機能追加は2024年3月8日のコンテナレベルメトリクス(個々のコンテナ単位でのCPU・メモリ使用率などのモニタリング指標)の追加が最後であり、それ以降、目立った新機能の追加は確認できていません。

この事実は、次のように受け止めるのが妥当です。

• 廃止・メンテナンスモードへの移行・新規受付終了といった、サービスの終了を示唆する公式アナウンスは確認できていません
• OCIのサービスステータスAPIでは、全パブリックリージョンで稼働中のサービスとして扱われています
• 一方で、直近1年以上、目立った新機能追加がないことも事実であり、「常に最新機能が追加され続けているサービス」という紹介は誤りです
• Datadogなど外部の可観測性ツールとの統合実績があるなど、周辺エコシステムとしては現役で使われ続けている形跡が確認できます

機能追加が停滞していること自体は、ネガティブな評価とは限りません。コンテナを1つ起動して常駐させるという、Container Instancesの役割自体が、すでにシンプルで完成されたものであり、追加すべき機能も少なくなってきていると捉えることもできます。実際、クラウドサービスの中には、コア機能が固まった後は安定運用を優先し、破壊的な変更を避けるフェーズに入るものも珍しくありません。重要なのは、この事実を隠さずに提示したうえで、読者自身が「今後も積極的に機能拡張されるサービスに賭けたいのか、それとも枯れた安定サービスを選びたいのか」を判断できる材料を提供することです。

Container Instancesは、シンプルな「コンテナを1つ動かす」というユースケースに対しては、既に必要十分な機能を備えたサービスと捉えることができます。逆に言えば、複雑なオーケストレーション機能やきめ細かなスケーリング制御が必要な場合は、次章で扱うOKEのほうが適した選択肢になります。この使い分けの判断こそが、本記事の中心的なテーマです。

2-8. 料金情報の一次情報源

本章で示した料金は、いずれも次の一次情報源を確認したうえで記載しています。

第三者のブログ記事やまとめサイトに記載された料金情報は、取得時期や前提条件の古さゆえに、そのまま引用すると読者に誤った印象を与えるおそれがあります。本記事では、料金・仕様に関する数値はすべて公式情報源を直接確認したうえで記載し、確認が取れなかった項目(たとえばA1 Always Free枠のContainer Instancesへの適用可否)については、推測で「できる」と書くのではなく、「公式情報に記載がないため対象外として扱う」という立場を明示しています。

料金は、クラウドサービスの中でも特に改定頻度が高い情報です。本記事に記載した単価は、いずれも執筆時点で確認した値であり、実際にContainer Instancesを利用する際は、OCIコンソールの請求・コスト管理画面、またはOracle公式の価格表ページで最新の単価を確認することをお勧めします。

続く§3では、このContainer InstancesをOKE・Functionsと並べて比較し、実務でどう使い分けるべきかを整理します。

3. 三者比較 — Container Instances vs OKE vs Functions

OCIでコンテナ化されたワークロードやアプリケーションコードを動かす方法は、Container Instancesだけではありません。Kubernetesベースのフルマネージド基盤であるOKE、そして関数単位でコードを実行するFunctionsという、性質の異なる2つの選択肢が既刊記事で扱われています。本章では、この3つを同じ軸で比較し、「いつどれを選ぶか」を整理します。

3-1. 実行モデル・起動単位・課金・運用負荷の比較表

まず、3つの実行基盤を「実行モデル」「起動単位」「課金の考え方」「運用負荷」という4つの観点で比較します。

この表からわかる通り、Container Instancesは「Kubernetesほどの複雑さは不要だが、Functionsのような短時間実行ではなく、コンテナとして常駐させたい」というニーズに応える、ちょうど中間に位置する選択肢です。

3-2. 用語衝突に注意 — CIとOKE仮想ノードは別物

ここで、AWSの経験がある読者ほど誤解しやすいポイントを整理しておきます。OKEには「仮想ノード」という機能があり、これはKubernetesクラスター内でノード管理を意識せずにPodをサーバーレスに実行できる仕組みです。AWSの経験に照らすと、この仮想ノードはEKS on Fargate(EKSのFargateプロファイル)に相当します。

一方、本記事で扱うContainer Instancesは、Kubernetesクラスターそのものを必要とせず、コンテナイメージを直接指定して起動する独立したサービスです。AWSの経験に照らすと、こちらはECS Fargateのスタンドアロンタスク(ECSクラスター上でFargate起動タイプのタスクを直接実行する構成)に相当します。

すでにOKEでKubernetesクラスターを運用しており、その中の一部のワークロードだけを手軽にスケールさせたい場合はOKEの仮想ノードが適した選択肢です。一方、Kubernetesクラスターそのものを持たず、単発のコンテナだけを動かしたい場合はContainer Instancesが適しています。この2つを同じ「サーバーレスコンテナ」という括りで混同しないよう、案件の要件を確認する際は、必ず「Kubernetesクラスターの管理が必要かどうか」を最初の分岐点にしてください。

3-3. いつどれを選ぶか — 決定フローチャート

実務で3つの選択肢のいずれかを選ぶ際の判断フローを、テキストベースで整理すると次のようになります。

Q1. 実行したい処理は、リクエスト/イベントごとに短時間(数秒〜十数分)で完結するか?
 └─ YES → Functionsが第一候補
 └─ NO  → Q2へ

Q2. 複数のマイクロサービスを協調動作させる、または高度なオーケストレーション
 (自動スケーリング・自己修復・ローリングアップデート等)が必要か?
 └─ YES → OKE(Kubernetesクラスター)が第一候補
 └─ NO  → Q3へ

Q3. すでにOKEクラスターを運用しており、その中の一部だけを
 サーバーレスに実行したいか?
 └─ YES → OKEの仮想ノードが第一候補
 └─ NO  → Container Instancesが第一候補
 (Kubernetesクラスター不要・単発/常駐のコンテナを最短で起動したい場合)

このフローが示す通り、Container Instancesが最適な選択肢になるのは、「Kubernetesクラスターを管理したくない」かつ「関数単位の短時間実行では収まらない」という条件が重なる場面です。具体的には、常駐が必要な軽量なAPIサーバー、定期実行されるバッチ処理、検証環境で素早くコンテナを立てて確認したいといったケースが典型例です。

OKEのクラスター構築・ノードプール管理・kubectl操作の基礎については、「OCI入門 Vol6 — OKE入門」で扱っています。Functionsのイベント駆動アーキテクチャやAPI Gatewayとの統合については、「OCI Functions & API Gatewayサーバーレス実践 Vol1」で扱っています。3つの実行基盤のうち、OKE・Functionsについてさらに深く知りたい場合は、あわせてこの2記事を参照してください。

→ OCI入門 Vol6: OKE入門(マネージドKubernetesのクラスター作成から運用まで)

→ OCI Functions & API Gatewayサーバーレス実践 Vol1: イベント駆動E2Eと正確な料金比較

それでは、次の§4で実際にコンテナイメージからContainer Instanceを起動するハンズオンに進みます。

4. ハンズオン — コンテナイメージからCI起動まで

本章では、実際にコンテナイメージを用意し、Container Instanceとして起動するまでの手順を扱います。OCIRへのイメージpush自体は「OCI DevOps実践 Vol1」で扱った内容と重複するため、本記事では要点のみを確認し、Container Instance固有の設定(作成ダイアログ・環境変数・リソース割当)に重点を置きます。

4-1. 前提・準備 — OCIRへのイメージpush

Container Instanceの起動には、あらかじめOCIR(Oracle Cloud Infrastructure Registry)にコンテナイメージがpushされている必要があります。OCIRへのログイン・タグ付け・pushの詳細な手順は、「OCI DevOps実践 Vol1」で扱っているため、本記事ではその手順を前提とし、要点のみ再掲します。

docker login <リージョンキー>.ocir.io -u <テナンシ名前空間>/<ユーザー名> -p <Auth Token>
docker tag <ローカルイメージ名>:<タグ> <リージョンキー>.ocir.io/<テナンシ名前空間>/<リポジトリ名>:<タグ>
docker push <リージョンキー>.ocir.io/<テナンシ名前空間>/<リポジトリ名>:<タグ>

東京リージョンのリージョンキーはnrtです。pushが完了したら、OCIコンソールの「開発者サービス」→「コンテナ・レジストリ」から、対象イメージが正しく登録されていることを確認しておきます。

4-2. Container Instance作成ダイアログ

OCIRへのpushが完了したら、OCIコンソールの「開発者サービス」→「コンテナ・インスタンス」から、新規のContainer Instanceを作成します。作成ダイアログで指定する主な項目は次の通りです。

作成ダイアログの入力を確認している段階では課金は発生しません。「作成」ボタンを押下し、インスタンスが起動して稼働状態になってから、§2-4で整理した通り課金が発生します。

4-3. 環境変数・リソース割当

作成ダイアログの「コンテナ」設定内では、コンテナごとに環境変数を指定できます。アプリケーションの設定値(接続先エンドポイント、動作モードなど)を、イメージに焼き込むのではなく環境変数として外部から注入する構成にしておくと、同じイメージを異なる設定で使い回せます。

環境変数の例:
  APP_ENV=production
  LOG_LEVEL=info
  PORT=8080

リソース割当については、コンテナ単位でOCPU・メモリの上限を個別に設定することも、コンテナインスタンス全体の割当を複数コンテナで共有させることも可能です。複数のコンテナ(メインアプリケーション+サイドカー)を1つのインスタンスに同居させる場合は、各コンテナに必要なリソースを見積もったうえで、インスタンス全体のOCPU・メモリ(§2-3で整理した上限内)を配分してください。

4-4. 起動確認

Container InstanceがACTIVE状態になったら、割り当てられたプライベートIP(パブリックサブネットに配置した場合はパブリックIPも)を使って、コンテナが正しく動作しているかを確認します。Webアプリケーションであれば、指定したポートに対してHTTPリクエストを送信し、期待したレスポンスが返ることを確認します。

コンソールの「ログ」タブからは、コンテナの標準出力・標準エラー出力を確認できます。起動が失敗した場合(FAILED状態になった場合)は、この出力からエラー内容を特定します。よくある失敗要因としては、イメージのプルに失敗している(OCIRへのアクセス権限不足)、コンテナ起動時のコマンドが誤っている、指定したメモリ量がアプリケーションの要求を満たしていない、といったケースが挙げられます。

4-5. 停止による課金制御

動作確認が完了し、一時的にContainer Instanceを使わない場合は、削除ではなく「停止」を選択することで、設定内容を保持したまま課金を止められます。停止したインスタンスは、コンソールから「開始」を選択することでいつでも再度ACTIVE状態に戻せます。

続く§5では、「Fargateと同じ感覚で使うと躓く」運用上の制約を扱います。

5. 運用と制約 — Fargateと同じつもりで使うと躓く点

Container Instancesは、ECS Fargateのスタンドアロンタスクに近い性質を持つサービスですが、細部の挙動は完全に一致するわけではありません。本章では、「Fargate相当」という理解のまま進めると躓きやすい3つのポイントを整理します。

5-1. 再起動ポリシー

Container Instancesには、コンテナが異常終了した際の再起動ポリシーを指定する設定があります。「ALWAYS(常に再起動)」「NEVER(再起動しない)」「ON_FAILURE(失敗時のみ再起動)」といった選択肢が用意されていますが、この再起動ポリシーはコンテナインスタンス全体に対して適用される設定であり、Kubernetesのように個々のPod・コンテナ単位で細かく制御できるわけではありません。複数コンテナを1つのインスタンスに同居させている場合、いずれか1つのコンテナの異常終了が、インスタンス全体の再起動判定にどう影響するかを、実際の構成で確認しておく必要があります。

ECS Fargateのタスク定義における再起動ポリシー(コンテナ単位のessential/non-essentialフラグなど)に慣れている場合、Container Instancesではこの粒度の制御ができない点に注意してください。細かい再起動制御が必須の要件であれば、Container InstancesよりもOKEのほうが適している可能性があります。

5-2. コンテナレベルメトリクス

§2-7で触れた通り、Container Instancesには2024年3月にコンテナレベルメトリクス(個々のコンテナ単位でのCPU使用率・メモリ使用率などのモニタリング指標)が追加されています。ただし、これはインスタンス単位のメトリクスに加えて利用可能になったものであり、Amazon CloudWatch Container Insightsのようなコンテナオーケストレーション全体を俯瞰する高度な可観測性機能とは、機能の広さが異なります。

本番運用でアラート設定や詳細なパフォーマンス分析をしたい場合は、標準のモニタリング機能だけでなく、外部の可観測性ツール(Datadog等のエコシステム統合)との連携も検討してください。Container Instances自体が、OKEほど豊富な可観測性エコシステムを持っているわけではないことを、事前に認識しておくべきです。

5-3. Vaultイメージプルシークレットとシークレット注入経路の差

Container Instancesでプライベートなコンテナレジストリ(OCIR含む)からイメージをプルする際、認証情報はOCI Vaultのシークレットとして管理する構成が推奨されています。これは、AWSでECS FargateがAWS Secrets ManagerやSSM Parameter Storeと連携してイメージプル認証情報や環境変数を注入する構成と、発想としては近いものです。

ただし、シークレットの注入経路には差があります。ECS Fargateでは、タスク定義の中でSecrets Managerの特定のシークレットARNを指定し、コンテナ起動時に環境変数として自動的に注入する仕組みが、比較的柔軟に設定できます。Container Instancesでも同様にVaultのシークレットを環境変数やイメージプル認証情報として利用できますが、設定できる注入経路の種類や粒度は、ECS Fargateの実装と完全に一致するわけではありません。「Fargateで組んでいたシークレット管理の設計を、そのままOCIに移植できる」という前提で進めると、注入経路の違いに気づかないまま設計を進めてしまうおそれがあります。

6. まとめ・落とし穴チェックリスト

本記事では、OCI Container Instancesについて、料金体系・OKE/Functionsとの三者比較・ハンズオン・運用上の制約という順に整理してきました。最後に、採用を判断するうえで必ず確認しておきたい4つのポイントをチェックリストとしてまとめます。

Container Instancesは、派手な新機能が追加され続けているサービスではありませんが、「Kubernetesクラスターを管理せずに、コンテナを1つ手早く動かしたい」という明確なニーズに対しては、今も十分に実用的な選択肢です。OKE・Functionsとあわせて、案件の要件に応じた使い分けの判断材料として、本記事を活用してください。

次回の「OCI Container Instances実践」シリーズでは、本記事で扱いきれなかった、より複雑なマルチコンテナ構成やCI/CDパイプラインとの統合について扱う予定です。