OCI FunctionsおよびResource Schedulerを使用して、スケーリング・ベースECPUを自動化する方法 (2026/02/05)

OCI FunctionsおよびResource Schedulerを使用して、スケーリング・ベースECPUを自動化する方法 (2026/02/05)

https://blogs.oracle.com/datawarehousing/how-to-automate-scaling-base-ecpus-using-oci-functions-and-resource-scheduler

投稿者：Keith Laker | Senior Principal Product Manager | Autonomous AI Database

この投稿は、ゲスト著者の一人であるMuthukumar Sivagnanam氏（ISV Prime、クラウドエンジニアリング担当プリンシパルクラウドアーキテクト）によるものです。

ビジネスケース：
多くのお客様は、予測不可能なピーク時および非ピーク時のワークロードで運用されています。このようなケースにおいて、Oracle Autonomous AI Database（ADB）は、定義されたベースラインECPU/OCPUと最適な組み合わせに加え、強力な組み込み自動スケーリング（最大3倍）を提供します。Oracle Autonomous AI Databaseは、需要の急増に対応するためのインテリジェントな自動スケーリング機能を備えた、優れた耐障害性、自己管理性、パフォーマンス最適化を備えたプラットフォームも提供します。


予測可能なピーク時および非ピーク時のワークロードにおけるコスト効率をさらに向上させるため、時間ベースのベースラインECPU/OCPU自動化レイヤーを実装しました。このレイヤーは、ピーク時とオフピーク時にベースラインを動的に調整しながら、ADBのネイティブな自動スケーリングを最大限に活用します。これにより、お客様はインフラストラクチャコストを実際のビジネス利用パターンに合わせて調整し、Autonomous AI Databaseの価値を最大化できます。この要件は、複数のISV顧客との議論から生まれました。


ソリューション実装
OCI FunctionsとResource Schedulerを用いたサーバーレス自動化を実装し、事前定義されたスケジュールに基づいてベースラインECPUをプログラム的に増減させました。このソリューションは、リソースプリンシパル、動的グループ、IAMポリシーを使用し、認証情報は不要で、セキュリティ上の理由から完全にプライベートネットワーク内で動作し、Oracle ADBの自動スケーリングをシームレスに補完します。


この最適化により、すぐに経済的なメリットが得られるだけでなく、OCI に移行して追加のワークロードを実行することに対する顧客の信頼が高まり、戦略的なクラウド プラットフォームとしての Oracle と OCI への信頼がさらに強化されます。

アーキテクチャ

実装手順:

1. ファンクションの動的グループを作成する

リソースのアイデンティティを確立する必要があります。
「このアプリケーション内のすべての関数は、Vault APIとデータベースAPIを呼び出すことができます。」と定義します。

手順

  1. 「アイデンティティとセキュリティ」→「ドメイン」→「ドメイン」→「動的グループ」に移動します。 
  2. 動的グループの作成をクリックします 
  3. 名前: fn-adb-scale-dg
  4. 説明: ADBをスケールし、シークレットを読み取ることができる関数
  5. ルール (以下の OCID を実際のコンパートメント OCID に置き換えます):

すべて {resource.type = 'fnfunc'、resource.compartment.id = '<YOUR_FUNCTIONS_COMPARTMENT_OCID>'}

  • 保存をクリック 

注: このルールは事実上、
「この特定のコンパートメントに存在するすべての関数は、この動的グループに属します」と述べています。

2.  Autonomous AI Databaseへの機能アクセスのためのIAMポリシーを追加する

ここで、IAM に
「作成したこの動的グループは、Autonomous AI Databaseの更新を許可されています」と伝えます。

手順

  1. アイデンティティ→ポリシーへ移動 
  2.  リソースが存在するテナンシー または 特定のコンパートメントを選択します 
  3. 「ポリシーの作成」をクリック 
  4. 名前: fn-adb-scale-policy
  5. 説明: ADBを管理する機能を許可する
  6. ステートメント (コンパートメント名に合わせて調整してください):

Allow dynamic-group fn-adb-scale-dg to manage autonomous-databases in compartment <YOUR_ADB_COMPARTMENT_NAME>。

ヒント:
より厳密にしたい場合は、manage の代わりに use を使用できますが、最初のテストでは、manage が最も簡単な方法です。

3. Functionsアプリケーションを作成する

手順

  1. 開発者サービス → 機能 → アプリケーションに移動します 
  2. アプリケーションの作成をクリック 
  3. 名前: adb-scale-app
  4. コンパートメント: 動的グループルールで使用されているのと同じコンパートメントを選択します
  5. VCN + サブネット: ネットワークアクセスのあるサブネットを選択します
    （通常はサービスゲートウェイのあるプライベートサブネット）
  6. ログ記録: これを有効にする (デバッグには強く推奨)
  7. 作成をクリック 

このアプリケーションはファンクションのコンテナとして機能します。

4. Pythonファンクションコードを準備する

Autonomous AI Database Update APIを呼び出して CPU 数を設定するファンクションを作成します 。

ファンクションプロジェクト構造

Cloud Shell と Fn CLIを組み合わせて使用​​します  (最も簡単な方法、ローカル セットアップは不要)。

手順

  1. Cloud Shellを開きます  (OCI コンソールの右上にある >_ アイコンをクリックします)
  2. Cloud Shell から、アプリケーションとコンテキストを一覧表示します。

# fn list apps
# fn list context

  • リージョン、コンパートメント、レジストリのコンテキストを更新/使用します。

# fn use context ap-singapore-1
# fn update context <Compartment OCID>
# fn update context registry sin.ocir.io/axsfxxxxxbhpo/adb-auto.0.1

  • OCI コンソール → ユーザー設定から認証トークンを作成し  、そのトークンを使用して OCIR にログインします。

# docker login -u ‘axsfxxxxxbhpo/muthukumar’ sin.ocir.io

パスワード: <ユーザー認証トークン>

(注: この例はシンガポール地域用です。地域を適宜変更してください。)

  • 関数プロジェクトを初期化します。

# fn init –runtime python adb-scale-fn
# cd adb-scale-fn

これにより、定型ファイルを含む adb-scale-fn という名前のフォルダーが作成されます。

  1. Func.yaml
  2. Func.py
  3. requirements.txt

func.yamlを以下の内容で編集します 。

以下のように func.yaml を更新します。

schema_version: 20180708
name: adb-scale-fn
version: 0.0.11
runtime: python
build_image: fnproject/python:3.11-dev
run_image: fnproject/python:3.11
entrypoint: /python/bin/fdk /function/func.py handler
memory: 256

requirements.txt を 以下の内容で更新します。 

oci
fdk

func.pyを 次のコードに置き換えます 

# func.py

コードを GitHub リポジトリに追加しました:  https://github.com/muthus-ca/oci-automation.git

5. ファンクションをデプロイする

# fn -v deploy –app adb-scale-app

OCI コンソールで確認します。

  • 開発者サービス → ファンクション → アプリケーション → adb-scale-app
  • ファンクション adb-scale-fnを選択
  • 構成を確認する 

6. 機能をテストする

Cloud Shell から直接呼び出します。

CPUを増やす

# fn invoke adb-scale-app adb-scale-fn <<EOF
{“adb_ocid”: “ocid1.autonomousdatabase.oc1..xxxx”, “new_cpu_count”: 8}
EOF

データベースの状態が UPDATINGに移行していることがわかります。

CPUを減らす

# fn invoke adb-scale-app adb-scale-fn <<EOF
{“adb_ocid”: “ocid1.autonomousdatabase.oc1..xxxx”, “new_cpu_count”: 2}
EOF

7. リソーススケジューラで機能を自動化する

ステップ1：リソーススケジューラに移動する

  • OCIコンソールにログイン 
  • ガバナンスと管理 → リソース スケジューラに移動
  • スケジュールをクリック 

  1.  

  1.  

ステップ2: 新しいスケジュールを作成する

  • スケジュールを作成をクリック 
  • 以下の詳細を入力してください。

  1.  

基本情報

  • 名前: adb-scale-up-schedule (例)
  • 説明: OCI ファンクションをトリガーしてADB ECPU を増加させます
  • 実行するアクション: 開始
  • コンパートメント:  <コンパートメント名を選択>
  • リソース: 静的、デプロイされたファンクションを選択
  • パラメータの適用: パラメータタイプ – 本文、値 (JSON)

ペイロード/リクエストボディフィールドに  、関数に必要なJSON入力を入力します。  （CPU数は適宜調整してください）

ECPU数を増やす

{
“adb_ocid”: “ocid1.autonomousdatabase.oc1.ap-singapore-1.xxxxxxv5aq”, 
“new_cpu_count”: 8
}

# 上記の手順を繰り返し、以下のJSON入力を指定して、CPU数を減らす別のスケジュールを作成します。（CPU数は適宜調整してください）

ECPU数を減らす

{
“adb_ocid”: “ocid1.autonomousdatabase.oc1.ap-singapore-1.xxxxxxv5aq”, 
“new_cpu_count”: 2
}

注: このペイロードは、  リクエスト本体としてファンクションのhandler()に直接渡されます。

ステップ3: スケジュールのタイミングを設定する

次のいずれかを選択します。

  • オプションA: シンプルなスケジュール（フォームインターフェース）  - デモではこの方法を使用しました
  • 頻度: 1 回 / 毎時 / 毎日 / 毎週 / 毎月 (デモでは 1 回使用)
  • 繰り返し：1
  • 時間: 時間を選択 (UTC タイムゾーン – 24 時間形式)
  • 開始日: <開始日> 終了日: <オプション>

レビューして保存

ステップ4: 実行を検証する

A. スケジュール実行ステータスを確認する

  • スケジュールを開く
  • 実行/実行履歴へ移動 
  • ステータスを確認 = 成功

  1.  

  1.  

B. ファンクションログを確認する

  • 開発者サービス → ファンクション → アプリケーションに移動します
  • アプリケーションを選択してください
  • 機能を開く
  • クリック ログ
  • 実行成功メッセージを確認する

  1.  

  1.  

  1.  

  1.  

C. Autonomous AI Databaseの検証

  • Autonomous AI Databaseへ移動 
  • ターゲットDBを開く
  •  チェック：
    • コンピューティングモデル (ECPU/OCPU)
    • CPU/ECPU 数が更新されました
      • ライフサイクルの状態は「UPDATING → AVAILABLE」と表示されます

    1.  

    1.  

    ステップ5: スケールアップとスケールダウンのスケジュールを別々に作成する

    推奨設定

    スケジュール名時間CPU
    adbスケールアップ営業時間8 ECPU
    adbスケールダウン営業時間外2 ECPU

    各スケジュールは、  異なる JSON ペイロードを使用して同じファンクションを呼び出します。

     

    まとめ

    ピーク時とオフピーク時の予測可能なワークロードに合わせてベースラインECPU/OCPUを動的にスケーリングすることで、お客様はデータベースあたり約40～50%という大幅な月間コスト削減を実現しました。複数のAutonomous AI Databaseと環境に適用することで、パフォーマンスに影響を与えることなく大幅なコスト最適化を実現しました。

    これらの節約分は、新しいワークロードの導入や追加のビジネス イニシアチブのサポートに再投資できます。

    このソリューションは完全に自動化され、サーバーレスで、運用上のオーバーヘッドがなく、プライベート接続ときめ細かいアクセス制御によって設計上安全であり、統合された監視、ログ記録、監査を通じて完全な観測可能性と監査可能性を提供します。

    ゲスト著者のMuthukumar Sivagnanam氏（プリンシパルクラウドアーキテクト、ISV Prime、クラウドエンジニアリング）
    に心より感謝申し上げます。Muthukumar氏は20年以上のIT経験を持ち、特に10年以上はクラウドテクノロジーを専門としています。Oracleでは、OCI ISVのお客様から信頼されるアドバイザーとして、クラウドアーキテクチャとソリューション、自動化、コスト最適化の取り組みを主導しています。ビジネス要件を安全でスケーラブルなOCIソリューションへと変換し、CXOレベルのビジネス成果と整合したテクノロジー戦略を提示することで、お客様のビジネスとOracleの両方に付加価値を提供することを専門としています。

    コメント

    コメントを投稿

    このブログの人気の投稿

    Oracle Database 19cサポート・タイムラインの重要な更新 (2024/11/20)

    イメージ
    Oracle Database 19cサポート・タイムラインの重要な更新 (2024/11/20) https://mikedietrichde.com/2024/11/20/important-update-to-oracle-database-19c-support-timelines/ 長い沈黙は、私が隠れているという意味ではありません。つまり、今はとても忙しいということです。そして、より少ない旅行で、私はあなたのコメントにもブログと返信するより多くの時間を持っていることを願っています。それでも、Oracle Database 19cサポート・タイムラインの非常に重要な更新について説明します。 * 更新された内容 2024年11月19日現在、Oracle Database 19cのサポート・タイムラインが調整されています。 MOSノート: 742060.1 – 現在のデータベース・リリースのリリース・スケジュールを見ると、新しい日付が表示されます。 Premier Support、2029年12月31日まで 2030年1月1日から2032年12月31日までの拡張サポート 2033年1月1日から2034年12月31日までのアップグレード・サポート これは知ることがとても大切です。 他のリリースの更新はありますか。 MOSノートの終わりにある変更ログ: 742060.1 – 現在のデータベース・リリースのリリース・スケジュールでは、Oracle Database 21cの最新の更新も確認できます。このリリースのPremier Support期間は、2027年7月31日まで延長されました。 また、Oracle Database 23aiのパッチ適用終了日は2032年12月31日に設定されています。 Lifetime Support Policy 更新は、Oracle Technology Productsの Oracle Lifetime Support Policy (6ページ)でも確認できます。 From: Oracle Lifetime Support Policy for Oracle Technology Product s – page 6 – Nov 19, 2024 特に、次の表に示す制限事項に注意してください。 Oracle Database 1...
    続きを読む

    ミリ秒の問題: BCCグループとOCIが市場データ・パフォーマンスを再定義する方法(AWSに対するベンチマークを使用) (2025/11/13)

    イメージ
    ミリ秒の問題: BCCグループとOCIが市場データ・パフォーマンスを再定義する方法(AWSに対するベンチマークを使用) (2025/11/13) https://blogs.oracle.com/cloud-infrastructure/post/milliseconds-matter-bcc-group-and-oci-vs-aws 投稿者： Steven Riley | Senior Cloud Architect William Bierds | Business Analyst and Systems Engineer - BCC Group International Travis Liles | Master Principal Cloud Architect Puru Patel | Cloud Architect - FSI これは、BCC グループと Oracle Cloud Infrastructure (OCI) 間の市場データ パートナーシップを紹介するブログ シリーズの第 2 部です。   はじめに 金融市場データアプリケーションは、トレーダー、金融機関、そして市場参加者が情報に基づいた意思決定を行えるよう、リアルタイムデータを提供することで、取引エコシステムにおいて重要な役割を果たしています。 前回のブログ で述べたように、取引環境において最適なパフォーマンスを確保するには、市場データを超低レイテンシかつ高い信頼性で配信する必要があります。 今日の急速に変化する金融市場において、クラウドは市場データ・アプリケーションにとって強力な推進力として台頭しています。適切なネットワークとインフラストラクチャがあれば、企業は実行時間の短縮、可用性の向上、そして堅牢なセキュリティを実現できます。しかし、企業によるクラウド導入は遅れており、ワークロードのクラウド移行計画を中止しているケースもあります。そこで、BCCグループとOracle Cloud Infrastructure（OCI）のパートナーシップが注目されています。 BCCグループは、主力市場データアプリケーションであるONE PlatformをOCI上に導入しました。このブログでは、以下の点について説明します。 このパートナーシップがなぜこれほど相乗効果をもたらすのかを探る OC...
    続きを読む

    OCIサービスを利用したWebサイトの作成 その4～Identity Cloud Serviceでサイトの一部を保護 (2021/12/30)

    イメージ
    OCIサービスを利用したWebサイトの作成 その4～Identity Cloud Serviceでサイトの一部を保護 (2021/12/30) https://blogs.oracle.com/cloudsecurity/post/using-oci-services-part-4 投稿者： Christopher Johnson 今回は、OCI Native Servicesを使って完全にサーバーレスでWebサイトをホスティングするシリーズの第4弾です。     パート1 では、OCI WAF + API Gateway + Functionを使用して、OCI Object Store Bucketから静的コンテンツを提供する基本的な方法を紹介しました。     パート2 では、バケットを（公開ではなく）非公開にし、Resource Prinicpalを使用して安全にアクセスする方法を紹介しました。     パート3 では、ハードコードされた設定を削除し、代わりにそれらの設定をアプリケーションに保存する方法を紹介しました。 パート4では、サイトの一部をログインの後ろに置いてみようと思っています。 この記事は、ちょっとした「フクロウの描き方」のようなものになりそうです。でも、コードを見ればきっと理解できるはずです! IDCSでアプリケーションを作成 注：OCI Identity Domains は、OCI の新規顧客に対して IDCS の機能を直ちに提供します。現在 IDCS を使用している顧客については、既存の IDCS ストライプは今後数ヶ月の間に OCI Identity Domains に移行される予定です。詳細については、OCI Identity Domainの ドキュメント を参照してください。この変更は、このブログで説明したセキュリティ・パターンに影響を与えるものではありません。このブログで IDCS に起因するセキュリティ機能は、OCI Identity Domainsでも提供されます。 まず最初に、サイトを表現するために IDCS で実際にアプリケーションを作成する必要があります。 IDCSコンソールを開き、「アプリケーション」に移動し、「作成」をクリックします。Functionアプリケーシ...
    続きを読む