OCI Functions

解決する課題

サーバーを常時立てておく無駄や運用負荷を避けつつ、イベント発生時だけコードを動かしたい、というニーズに応えます。

• サーバーを常時立てておくのはもったいない/面倒 → イベント時だけ動かす
• 急なスパイクに自動でスケールしてほしい
• 「オブジェクトがアップされたら処理」「キューにメッセージが来たら処理」を接着剤的に書きたい
• 既存の Docker / Fn Project のスキルや成果物をそのまま活かしたい

主要概念と用語

• 関数（Function）: 実行単位のコード。OCI Functions ではコンテナイメージとしてパッケージされ、OCI Registry（OCIR） に push して使う
• アプリケーション（Application）: 複数の関数をまとめる論理グループ。VCN/サブネット・共通の構成値（config）・ログ設定をこの単位で持つ
• トリガー / イベントソース: Events サービス、API Gateway、Notifications、Streaming、Connector Hub、OCI CLI/SDK からの直接呼び出しなど
• Fn Project: OCI Functions の基盤となる OSS。fn CLI でローカル開発・デプロイができる
• リソースプリンシパル（Resource Principal）: 関数自身に与える ID。これを使って他の OCI サービスへ認証する（AWS の実行ロール相当）
• 動的グループ（Dynamic Group）+ ポリシー: 関数に IAM 権限を与える仕組み。条件に合うリソースを動的グループ化し、ポリシーで許可
• コールドスタート: 関数コンテナの初回起動にかかる遅延。Provisioned Concurrency で軽減できる

仕様・制限・クォータ

• 同期呼び出しの実行時間は最大 300秒。非同期の Detached呼び出しは 5〜3600秒で、処理開始時にHTTP 202を返す
• メモリは 128 / 256 / 512 / 1024 / 2048 / 3072 MB の離散値から選択（任意値ではない）。メモリに比例して CPU も割り当てられる
• 関数は コンテナイメージで提供し、OCIR に格納する。イメージサイズの上限あり
• リクエストとレスポンスのペイロードはそれぞれ最大 6MB。この上限は変更できない
• 同時実行はリージョン単位の 合計メモリ上限（total-concurrency-mb）で管理され、上限到達時はHTTP 429になる
• アプリケーションは VCN のサブネットに紐付き、関数はそのサブネット経由でプライベートリソースにアクセスする

内部の仕組み

OCI Functions は Fn Project をマネージド化したもので、関数はコンテナとして隔離実行されます。呼び出しが来ると、対象イメージを OCIR から取得して計算資源とネットワークを準備するため、初回はコールドスタートになります。実行基盤は一定時間保持され、後続呼び出しではホットスタートとして再利用されます。同時に多数のリクエストが来れば、複数コンテナを起動して水平スケールします。

• 各関数はアプリケーションに設定された VCN サブネットにネットワーク接続される。プライベートサブネットなら NAT/Service Gateway 経由で外部・OCI サービスへ
• 認証は リソースプリンシパルで行うのが基本。鍵をコード内に置く必要がない
• Detached呼び出しは開始後すぐ制御を返し、成功・失敗の実行記録を Notifications / Queue / Streaming へ送れる

横にスクロール

設計パターン / ベストプラクティス

• ステートレスに作り、状態は Object Storage / Autonomous Database / NoSQL Database などへ
• 小さく・速く（ベースイメージや依存を減らし、コンテナ起動と初期化を軽く）
• 非同期＋Streaming / Queue で失敗時のリトライ・退避を担保し、サービス間を疎結合に
• 秘密情報は config（環境変数）に直書きせず Vault（Secrets） から取得する
• API Gateway を前段に置き、認証・レート制限・ルーティングを集約する

運用・監視・トラブルシュート

• ログは OCI Logging（アプリケーション単位で関数ログを有効化）
• メトリクスは OCI Monitoring。名前空間 oci_faas で FunctionInvocationCount FunctionExecutionDuration FunctionResponseCount（エラー含む）FunctionThrottledCount などを確認
• スロットリング多発時はサービス制限やダウンストリーム（DB・外部 API）の限界を確認
• 分散トレースは Application Performance Monitoring（APM） と連携して可視化

コスト

呼び出し回数 ＋ 実行時間（GB秒 ＝ メモリ × 実行秒数） で課金され、毎月の無料枠が用意されています。メモリを上げると CPU も増えるため、処理が速くなって総額が下がる場合もあります（要計測）。

セキュリティ

• 関数にはリソースプリンシパルを使わせ、資格情報のハードコードを避ける（AWS の実行ロール相当）
• 動的グループ＋ポリシーで最小権限を付与。関数が触れる OCI リソースを限定する
• プライベートサブネット配置と NSG / セキュリティリストでネットワーク境界を制御
• アプリケーションをプライベートサブネットへ置いても関数の呼び出しエンドポイント自体は非公開にならないため、IAMポリシーで呼び出し主体を制限する
• 秘密情報は Vault（Secrets） で管理し、実行時に取得する
• 入力検証（API Gateway / イベントペイロード）でインジェクション対策を行う

関連サービス・比較（AWS との対応）

ハンズオン / CLI例

OCI Functions の作成・呼び出しは、Fn Project の fn CLI（イメージのビルド/デプロイ）と OCI CLI（アプリ作成・関数管理・呼び出し）を組み合わせて行います。

# OCI CLI: アプリケーションを作成（VCN サブネットに紐付け）
oci fn application create \
  --compartment-id ocid1.compartment.oc1..xxxxx \
  --display-name demo-app \
  --subnet-ids '["ocid1.subnet.oc1..xxxxx"]'

# Fn CLI: コンテキストをそのアプリに合わせ、関数をビルドして OCIR にデプロイ
fn deploy --app demo-app

# OCI CLI: アプリ内の関数一覧から OCID を確認
oci fn function list \
  --application-id ocid1.fnapp.oc1..xxxxx \
  --query "data[].{name:\"display-name\", id:id}" --output table

# OCI CLI: 関数を手動で呼び出して結果を確認
oci fn function invoke \
  --function-id ocid1.fnfunc.oc1..xxxxx \
  --file - \
  --body '{"name":"world"}'