OCI Functionsサービスでイベント通知メールを成型してみる（1）

クラウドサービス部の石田です。普段はパブリッククラウド、特にOracle Cloud Infrastructure（以下、OCI）を活用したインフラ構築業務を担当しています。

さて、運用業務には監視業務が欠かせませんが、OCI運用も例外ではありません。OCIの監視業務でよく使われる機能の1つに、「イベント機能」があります。監査ログに記録される各種イベントをトリガーとして、様々なアクションを実行できる仕組みです。この機能を使って、監視したいイベントが発生した時にメールを送付して監視するのがOCI運用の定石なのですが......。

この時送られてくるメールの文面が、イベント内容のJSONそのままなのです。このような障害通知はいつでもどこでも届いてしまうので、瞬時に内容を理解できることが求められますが、JSONのままでは直感的に読み取るのが困難です。

ちなみに、同じく監視によく使われる機能「モニタリング」でも同様の機能を利用でき、ある程度成型されたメールを送れます。これらを併用している現場は多いと考えられますが、この双方の種類のメールが届く状況では、JSONそのままの通知が少し扱いづらく感じることがあります。そうなると改善案を求められたりするわけです（しかも現状予算内で......）。そんなときに活用できるのが、「OCI Functionsサービス」です。

そこで、この連載ではOCI Functionsサービスの運用業務での活用例として、イベント通知メールの成型機能を実装する様子を全4回にわたってご覧いただきます。また、監視対象が増えるたびに対応工数が比例してしまうのも運用施策を継続しにくくする要因となるので、作成したファンクションの再利用を容易にする機能も併せて紹介します。

第1回の今回は、OCI Functionsサービスの紹介と、簡単なFunctionsの作成・実行を試します。第2回ではFunctionsを実際にイベント・サービスから呼び出す方法について説明します。第3回ではイベント・サービスから呼び出したFunctions内でイベント情報をメールに成型し送信する方法について紹介し、最後の第4回ではFunctionsを再利用しやすくするための機能の利用方法について紹介します。ぜひ最後までご覧ください。

OCI Functionsサービスとは

OCI Functionsサービス（以下、Functions）は、OCI上で提供されるFaaS（Functions as a Service）サービスです。サーバを用意せずにアプリケーションコードを実行できるサービスで、AWSのLambdaやAzureのFunctionsに相当します。

実際にシステムの一環としてサービスのロジックを乗せる場合もありますが、運用面でも役立つことがあります。実は先述のイベント機能とも連携できるのです。特定のイベントが発生した際に、そのイベントの情報をFunctionsで処理できます。つまり、先ほど話に上がった通知メールの成型も、この機能を使えば実現できるわけです。

ただ、FunctionsはAWS Lambdaなどと比べて少しとっつきにくいという声を聞くことがあります。理由としては、OCIのFunctionsがFn ProjectやDockerといったOSSプロダクトを組み合わせてFaaSを実現している点が挙げられます。それぞれの役割などを把握しておかないと、「何をしていいのかわからない」「問題が発生しても原因がつかめない」といった事態に陥りやすいのです。

またそもそも、インフラエンジニアはコードを書くのがメインのお仕事ではありません。FaaSはサーバレスと言われますが、インフラエンジニアはそのレスになってしまったサーバの方をお世話する人なのです。そのため、コードだけ書けば良いFaaSの思想とはちょっと相性が良くない......かもしれません。

最近はDevOpsの普及などでこの辺の垣根も低くなりつつありますが、まだまだ立派な垣根が張り巡らされている現場も多いです。そのような現場では、「Functionsを使えばイベントの通知メール成型ができる」と言われても、実際に手を動かすまでのハードルが高いのが現状です。そのため少なくとも私の周辺では、OCI Functionsが運用業務で積極的に使われるケースはあまり見かけません。とはいえ、使いこなせれば便利なことに変わりはありません。

Functionsの機能

Functionsは、OCIが提供するサーバレスのファンクション実行環境サービスです。FaaSの一般的な機能である、以下の機能が実装されています。

• サーバレス
• イベントドリブンで単一の関数の実行
• スケーラビリティ・可用性
• 利用量に応じた課金
• リソース予約

さらにOCIならではの利点としては、OpenSourceプロダクトベースで構成されているので、ベンダーロックインがないことが挙げられます。OCI上ではコンソール、CLI、REST APIやイベント、通知、APIゲートウェイ、サービスコネクタハブといった様々なサービスと連携できるため、業務での活用の他に運用で発生する各種ニーズにも活用できる、利用範囲の広いサービスです。ロジックを実装する言語としては、JAVA/Python/Ruby/Go/Node.js/C#（.NET）とメジャーなものは一通り対応しています。

Functionsの構成

Functionsは以下のようなOpenSourceプロダクトで構成されています。

• Fn Project：サーバレスプラットフォーム実行環境
• Docker：コンテナ仮想環境プラットフォーム

※ Fn Project - The Container Native Serverless Framework

※ Docker: コンテナー アプリケーション開発の加速

またOCI上のサービスとして以下も利用します。

• コンテナ・インスタンス
• コンテナ・レジストリ

とはいえ、実際に使ってみる際にはファンクションを作成しながら自然と必要な要素に触れることになるため、当面は気にする必要ありません。これらがどう連携するかというと、以下のようになります。

• 1.作成したコード（ファンクションのロジック）と実行環境、Fn Projectが含まれたDockerイメージを作成し、コンテナ・レジストリにプッシュする
• 2.アプリケーション（OCI上でのファンクションの実行環境の設定）を登録し、そこにファンクションとして上記Dockerイメージを登録する
• 3.ファンクションが呼び出される度にDockerイメージがコンテナ・インスタンスにデプロイされ実行される

そのため、OCI Functionsに関する情報を探す際は、「OCI Functions」だけでなく、「Fn Project」や「Docker」といった関連技術のキーワードでも調べると、より多くの有用な情報が見つかることがあります。

ファンクションを動かしてみる

さて、Functionsを作成してサンプルコードを実際に動かしてみましょう。

事前準備

Functionsを動かすのに必要な様々なOCIリソースを設定していきます。

ポリシー

先述のようにFunctionsはいくつかのOCIサービスを使用します。そのため、Functionsを開発するユーザがそれらサービスを利用できるようポリシーを設定する必要があります。加えてサービス同士も連携をとるため、サービス間の権限も設定しなければなりません。

詳細はOCIの解説ページ^※1にも記載がありますが、ざっと数えて14個もの設定が必要になります。これだけ見るとかなりの作業量に感じるかもしれませんが、Oracleはポリシー・テンプレートを用意しています。ポリシー作成ページのポリシー・ビルダーの画面ではFunctionsのテンプレートが用意されているので、適切なグループを作成してFunctionsを開発するユーザを追加し、そのグループに対しこのポリシーを設定します。ポリシーの設定方法自体は本稿の範囲外なので公式ドキュメントなど参照ください。

※1 クラウド・シェルでのファンクションのクイックスタート

実行環境

Functionsの実際の動作は、OCIのVCNのサブネット内で実行されます。そのためVCN/サブネットの用意が必要です。

IPアドレスは実行される際に自動で割り当てられますが、実際に使用するIPアドレスの数はFunctionsに設定するメモリ量（デフォルトで128MB）と同時実行数に依存します^※2。運用要件ならメモリも同時実行数もさほど増えないので気にする必要はありませんが、業務ロジックを実装する場合などは事前に見積もっておく必要があるのでご注意ください。まとまったアドレス数が必要になる場合は、専用サブネットの用意も検討してください。

※2 CIDRブロックおよびOCI Functions

また、Functionsが動くサブネットはサービスゲートウェイに接続可能である必要があります。サービスゲートウェイやルート表・セキュリティリストなどを設定しておいてください。

開発環境

開発環境は、以下を実行できる必要があります。

• コードの編集
• Fn Projectの各種コマンド実行
• Dockerイメージの作成・リポジトリへのpush

OCIでは大きく3種類の選択肢があります。

上に行くほど設定箇所が少なくなる一方、カスタマイズの自由度が減ります。今回は手軽なクラウドシェルを使うことにします。

クラウドシェルとは、OCIのWebコンソールから使える簡易Linuxシェル環境です（2025年2月時点ではOracle Linux Server release 7.9環境）。OCI環境の操作によく使われるようなコマンドラインツールがインストール済みであることが特徴です。インフラ担当者に馴染みが深いもので例を挙げると、OCI CLIが使える状態のLinuxコマンドラインシェルがOCIコンソール上から使えるのです。

このクラウドシェル上ではFunctionsで使用するFn ProjectやDockerのコマンドラインツールも同様に利用可能であるため、Functionsの開発にも利用可能です。ただしクラウドシェルは、一定期間を過ぎるとホームディレクトリが消されてしまうので注意しておいてください（8か月で消去。6か月目に警告あり）。その他の選択肢の詳細についてはOCIのドキュメント^※3を参照ください。

※3 ファンクション開発環境の様々なオプション

Functionsを作成して実行してみる

事前に検討・用意しておくこと

Functionsを作成するにあたって事前に検討しておく事項があります。

今回は検証用に以下のようにします。

アプリケーションの作成

アプリケーションとは、Functionsの実行環境の定義のことです（アーキテクチャやネットワーク）。アプリケーションで実行環境を定義し、そこに実際に動作するコードを含むDockerイメージであるファンクションを紐付ける形で設定します。

OCIコンソールのハンバーガーメニューから「開発者サービス」、「ファンクション」、「アプリケーション」の順に選択し、表示された「XXXコンパートメント内のアプリケーション」の画面から「アプリケーションの作成」ボタンを押します。

新規アプリケーション作成画面になるので、先に決めておいた設定値（表示名とNW構成、採用アーキテクチャ）を入力します。アーキテクチャはこの画面では「Shape」の項目で設定します。「X86_64」アーキテクチャの場合は、Shapeの欄では「GENERIC_X86」を選択します。

入力し終わったら「作成」ボタンで作成されます。

これでアプリケーションが作成されました。

ファンクションの作成・実行

次は実際に動くロジックを含んだDockerイメージであるファンクションを作成してリポジトリに登録しますが、ここから先の手順はアプリケーションの詳細画面に記載があります。先に作成したアプリケーションの詳細画面を下の方にスクロールしていくと、開発環境でどのようなコマンドを実行すれば良いのか説明があります（表示されていないようなら、左側のメニューから「開始」を選択します）。

開発環境としてクラウドシェルを使うかOCIインスタンス/ローカルを使うかを選択すると、その下に実行すべきコマンドがコードスニペットで一つひとつ表示されます。それらをコピペしていけば、画面上に「Hello World」と表示するJAVA製のFunctionsができます。大筋はそちらに準拠することとし、本稿では主に今回の検証用に変更が必要な点や注意点について触れていきます。以下ではこのOCIコンソール上の手順を項番ごとに説明します。

項番1

クラウドシェルを起動させます。OCIコンソールの右上のメニューから起動します。

起動に多少時間がかかりますが、立ち上がると以下のように画面下部にクラウドシェルが表示されます。

「uname -a」も実行可能な普通のLinuxのコマンドラインであることがわかります。後はこのコマンドラインでファンクション作成の各コマンドラインを実行していくのですが、その前にクラウドシェルの環境を確認します。アーキテクチャとネットワークの選択の2つです。

• アーキテクチャの選択
  先ほどアプリケーションを作成する際にアーキテクチャを設定しましたが、クラウドシェルのアーキテクチャもそれに合わせる必要があります。クラウドシェルの左上の「アクション」メニューから「アーキテクチャ」で、クラウドシェルのアーキテクチャを確認、設定できます。

  

  

  今回はアプリケーションの方でX86_64と設定したので、こちらも同じにします。ARMに設定されていた場合は設定変更してください（クラウドシェルの再起動が発生するので変更反映まで多少時間がかかります）。

• ネットワークの選択
  ファンクションを作成するにあたっては元となるDockerイメージを外部サイトから取得するため、クラウドシェルがパブリックなインターネットに接続できる必要があります。クラウドシェルは通常ならOCIが用意しているパブリックなインターネットにアクセスが可能ですが、組織のポリシーによって禁止されている場合があります。そのような場合はこのような画面が表示されます。

  

  この場合は、NATゲートウェイなどに接続されたインターネットアクセスが可能なサブネットを用意し、クラウドシェルをそのサブネットに接続させることが必要です。アクセス可能なサブネットを用意して、クラウドシェルの左上の「ネットワーク」メニューから「プライベート・ネットワーク定義リスト」を選択します。

  

  プライベート・ネットワーク定義リスト画面からは「プライベート・ネットワーク定義の作成」ボタンを押します。

  

  プライベート・ネットワーク定義画面ではプライベート・ネットワーク定義の名前と、接続するサブネットとVCNを設定し（今回はFunctionsを用意するサブネットが条件を満たしていたので、そこを使います）、必要に応じてNSGなども設定します。すぐ使いたいので「アクティブなネットワークとして使用」もオンにします。

  

  「作成」ボタンを押すと作成されて、クラウドシェルがそこに接続されます。ついでにこのプライベート・ネットワークをデフォルトにしておきましょう。

  

  クラウドシェルでファンクションを開発する準備が整いました。

fn update context oracle.image-compartment-id <compartment-ocid>

fn init --runtime python python-test

cd python-test/

項番11

ファンクションを実際に実行します。ファンクション名を変えたのでコマンドラインは以下のように変わります。

fn invoke python-test python-test

「python-test」が2つ続いていますが、1個目がアプリケーション名、2個目がファンクション名です。 実際に実行すると、以下のようにJSON形式で世界に挨拶してくれます。

$ fn invoke python-test python-test
{"message": "Hello World"}

またこのファンクションは、標準入力に"name"というキーを定義したJSONを入力すると世界以外にも挨拶してくれます。

$ echo -n '{"name": "LAC"}'|fn invoke python-test python-test
{"message": "Hello LAC"}

ちなみにOCIメニューから「開発者サービス」、「コンテナとアーティファクト」、「コンテナ・レジストリ」の順に選択すると、レジストリにDockerイメージが今回使用したリポジトリ名とファンクション名でプッシュされていることがわかります。

Functionsの費用

冒頭で少し予算の話もしたので、最後にFunctionsの費用についても触れておきましょう。Functionsは呼び出し回数および実行時間によって課金されます。ただしパブリッククラウドでよくある無料枠がFunctionsにも存在します。

• 呼び出し回数は1か月あたり200万件以下
• 実行時間は1か月あたり40万時間以下

上記が無料となっており、今回のユースケースである監視通知での利用であるならば、ほとんどの場合無料枠に収まる可能性が高いです。それを超えても一呼び出しあたり0.0000002米国ドル、実行時間は0.00001417米国ドル/ギガバイト・メモリ秒という課金です。Functionsは呼び出された時しか実行時間が発生しないので、他のCompute Instanceなどのサービスと比べるとコストを抑えやすいサービスといえます。

おわりに

これでまずはファンクションを実行できるようになりましたが、イベント内容を成型してメールにするというゴールにはまだ及びません。次回はさらに一歩進んで、イベント・サービスからファンクションを呼び出してみようと思います。お楽しみに。

プロフィール

石田 翼
ハードウェア側からインフラ業務に入ったのに今や1mmもハードウェアを使わないクラウドのお仕事が中心になって困惑しているインフラエンジニア。LinuxやOracle DBの設計・構築などに従事しつつスキルをクラウドシフト中。