[!] この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
以前、Oracle Cloud Infrastructure (以下 OCI と表記) 上で利用している Compute リソースの自動起動 / 停止を行うために、常時稼働中のインスタンスで Cron を利用して実現する方法を紹介しました(前回の記事はこちら)。
2024 年 5 月に OCI リソースの自動起動 / 停止を管理する Resource Scheduler サービスが追加されたため、ご紹介します。
Resource Scheduler とは
Resource Scheduler ⧉ は、指定した日時に、指定した OCI 上のリソースを操作 (起動 / 停止) するサービスです。Resource Scheduler を利用して不要な時間帯は停止し、再び必要な時に起動することで、一元管理されたテナント・グループ内の Database および Compute リソースのコストを削減できます。
Resource Scheduler リソース (スケジュール) は、以下の 3 つの要素から成り立ちます。
- アクション: 起動と停止、どちらを実行するか
- 対象リソース: どのリソースに、アクションを実行するか
- 実行タイミング: いつ、アクションを実行するか

Resource Scheduler の利用に必要な権限
Resource Scheduler を利用するには、以下の権限が必要となります。
- スケジュールの作成ユーザ: スケジュールの作成権限
- スケジュール: 対象リソースの操作権限

スケジュールの作成手順
ここからは Oracle Cloud Infrastructure Documentation / Creating Schedules ⧉ を参考に、スケジュールの作成手順を示します。
- ユーザに、スケジュールの作成権限を付与
- スケジュールの作成
- スケジュールに、対象リソースの操作権限を付与
ユーザに権限を付与
スケジュールの作成を許可する権限
ユーザがスケジュールを作成できるように、Resource Scheduler の管理権限を付与します。
付与する権限は次のとおりです。
Allow group <Group_Name> to manage resource-schedule-family in tenancy<Group_Name>- 権限を付与するグループの名前
in tenancy- スケジュールのスコープはテナンシ全体であるため、コンパートメントごとの設定はできない
スケジュールの作成 - 新規作成
OCI コンソールのメニューから、「Governance & Administration」→「Resource Scheduler」→「Schedules」を選択します。

Resource Scheduler の一覧ページから、「Create a schedule」ボタンを押下して、スケジュールの作成画面に移動します。

スケジュールの作成 - 基本情報の設定
はじめにスケジュールの基本情報を設定します。
Schedule name- スケジュールの名前
Schedule description- スケジュールの説明
- 入力は任意
Action to be executed- 実行するアクション
StartとStopから選択

設定後、「Next」ボタンを押下します。
スケジュールの作成 - 対象リソースの設定
次に、実行するアクションの対象となるリソースを設定します。
Oracle Cloud Infrastructure Documentation / Resource Scheduler Overview - Benefits ⧉ では、Compute、Autonomous Database、Base Database リソースの操作ができるよう記載されていますが、東京リージョンにおいて 2024 年 8 月時点で対応しているリソースは Instance、InstancePool、Autonomous Database です。Base Database など他リソースについては、今後追加される可能性があるとのことでした。
ここで表示されるリソースは、スケジュールを作成するユーザの権限で異なります。表示されるリソースが想定と異なる場合は、権限を確認してください。
Resource selection method の設定
「Resource selection method」で、対象リソースの選択方法を指定できます。
以下のうち、どちらかを設定します。
Static(静的)- 対象リソースは、スケジュール作成時に選択したリソースのみ
- 対象リソースを変更する場合は、スケジュール自体を更新する必要がある
Dynamic(動的)- 対象リソースは、スケジュールの実行時に決定される
- 動的に設定される際の条件は、後述のフィルタが適用される

Search and filter の設定
「Search and filter」に条件を設定することで、一覧表示されているリソースを絞り込むことができます。
「Resource selection method」 で Static を選択した場合は検索条件として、Dynamic を選択した場合はフィルタとして利用されます。
設定できる値は以下のとおりです。
Compartment- 対象リソースが存在するコンパートメント
- デフォルトは
All
Resource Type- 対象リソースの種類
Instance、InstancePool、AutonomousDatabaseから選択 (複数選択も可能)- デフォルトはすべて選択済み
Status- リソースの状態
AVAILABLE、RUNNING、STOPPEDから複数選択可能- デフォルトは設定なし
Tags- 対象リソースに付与しているタグ
Free-form TagsまたはDefined Tagsから選択可能- タグを有しているか、または有しているタグの値まで一致しているか、を設定可能
- デフォルトは設定なし
※ ブログ執筆時点では、サービスの不具合により Free-form Tags ではリソースの自動起動 / 停止ができませんでした。そのためタグを用いた Dynamic な Resource Scheduler を作成する場合は、 Defined Tags を選択してください。

対象リソースの選択
表示されているリソースから、対象リソースを選択します。
Staticの場合- リソース名の左にあるチェックボックスをクリック
Dynamicの場合- 「Search and filter」で設定したフィルタに該当するリソース全て
Staticの場合に存在したチェックボックスは非表示
- 「Search and filter」で設定したフィルタに該当するリソース全て
Dynamic なスケジュールを作成する場合、ここに表示されるリソースは、フィルタに該当する 今現在の リソースの一覧になります。
スケジュール追加後も、フィルタ条件に一致するリソースを作成した場合は、そのリソースも対象に含まれます。
リソースの選択後、「Next」ボタンを押下します。
スケジュールの作成 - 実行タイミングの設定
次に、アクションを実行する日時を設定します。
記述方法は 2 パターンあり、Specify schedule using から設定可能です。
- A.
Form interface- 実行タイミングを GUI で選択
- B.
Cron expression- 実行タイミングを
Cron形式で記述
- 実行タイミングを

A. Form interface の設定値
Interval- スケジュールが実行されるタイミングを設定
One-time(1 回のみ)、Hourly(毎時)、Daily(毎日)、Weekly(毎週)、Monthly(毎月) から選択可能- デフォルトは
Weekly
Repeat every- 実行間隔を設定
- 隔日や 3 か月ごとなどを設定する場合に利用する
IntervalでOne-timeを選択している場合は、入力フォームは非表示- デフォルトは
1
- 実行間隔を設定
Day(s) of the week- 実行する曜日を設定
IntervalでOne-time、Hourly、Dailyを選択している場合は、入力フォームは非表示IntervalでMonthlyを選択している場合は、フォーム名がDay(s) of the Monthに変更される- その場合は、実行する日付を設定する

B. Cron expression の設定値
Recurrence details- 実行タイミングを
Cron形式で記述 - 設定は任意で、設定しない場合は実行タイミングが設定されない
Cronの記述方式は、Oracle Cloud Infrastructure Documentation / Creating a Cron Expression Schedule ⧉ を参照- 30 分未満の間隔で実行されるスケジュールは作成できないため注意
- 実行タイミングを

A、B 共通の設定値
どちらの記述方法を選択しても、以下の設定は共通して行います。
Time- スケジュールが実行される時間を設定
- デフォルトはスケジュール作成時の時刻
Cron形式の場合、Recurrence details内で実行時刻を設定しているため、この設定値がどのように影響するか不明- UTC 指定のため注意
Start date- スケジュールの実行を開始する日付
- デフォルトはスケジュール作成時の日付
End date- スケジュールの実行を終了する日付
- 設定は任意で、デフォルトは設定なし

実行タイミングの設定後、「Next」ボタンを押下します。
スケジュールの作成手順 - スケジュールの確認
最後に、作成するスケジュールの設定を確認します。
問題がない場合は、「Create schedule」ボタンを押下して、スケジュールを作成します。

スケジュールに権限付与
次に、作成したスケジュールに対象リソースを操作する権限を付与します。 付与する権限は次のとおりです。
Allow any-user to manage <Resource_Type> in compartment <Compartment_Name> where all{request.principal.type='resourceschedule',request.principal.id='<Resource_Scheduler_OCID>'}manage <Resource_Type>- 今回作成したスケジュールが操作するリソースの種類
- インスタンスなど、
use権限に起動 / 停止が含まれるリソースの場合は、manageではなくuseで代替可能
in compartment <Compartment_Name>- リソースが存在するコンパートメント名を
<Compartment_Name>に記述 - コンパートメントの OCID で指定する場合は、
in compartment id <Compartment_OCID>と記述する
- リソースが存在するコンパートメント名を
where all{request.principal.type='resourceschedule',request.principal.id='<Resource_Scheduler_OCID>'}- 作成したスケジュールの OCID を
<Resource_Scheduler_OCID>に記述- スケジュールごとに権限を付与
- リソースの種類やコンパートメントが一致している全てのスケジュールに対して、まとめて権限を付与する場合は
where all{request.principal.type='resourceschedule'}と記述- この場合は、スケジュールの追加により、意図しないスケジュールが実行される可能性があることに注意
- 作成したスケジュールの OCID を
スケジュールの実行を確認
スケジュールの実行は、スケジュールの OCI コンソール上に表示されている Work requests で確認できます。
Work requests には、以下の情報が表示されています。
Run date- スケジュールの実行時刻
Operation type- 実行アクションの種類
Resources- 対象リソースの合計数
- リソースの状態は影響しない (対象リソースを起動するスケジュールがある場合、対象リソースが既に起動していた場合でも、合計数に含まれる)
Status- スケジュール実行の成否を表示 (失敗した場合も、原因は表示されない)
Duration- スケジュールの実行にかかった時間

スケジュールの編集
スケジュールの編集は、OCI コンソール上から行うことができます。 リソースのページを開き、「Edit schedule」ボタンを押下することで、リソースの編集ができます。

リソースの編集を実施しても OCID は変更されませんが、対象リソースの種類やコンパートメントを編集した場合は、権限の修正もあわせて実施する必要があります。
おわりに
今回は OCI に追加された新サービス Resource Scheduler について、作成方法と編集方法を確認しました。
以下に、スケジュール作成時のポイントをまとめました。
- 対象リソースの設定
Static- アクションが実行される対象リソースを、スケジュール作成時に設定
- 対象リソースを変更する場合は、再度スケジュールを編集する必要がある
Dynamic- アクションが実行される対象リソースを、アクション実行時に設定
- フィルタ設定を誤ると、意図しないリソースを操作する可能性があるため、注意が必要
- 実行タイミングの設定
Form interface- 値を選択していくことで、簡単に実行タイミングが設定可能
Cron expressionForm interfaceよりも細かい実行タイミングが設定可能- 今まで
Cronを利用して自動起動 / 停止を実現していた場合は、その設定をそのまま活用できる
Resource Scheduler はリソースを操作することができるため、コスト削減が期待できます。
また、このサービスを利用することで、リソースの起動 / 停止を実現するために自前で構築していた環境が不要になるので、その点でもコストの削減につながります。
サービス開始直後ということもあり、対応するリソースが少ないため、今後も増えていくことを期待しています。