メールマガジン

サイバーセキュリティや
ラックに関する情報をお届けします。

サービス・製品　|　
2026年1月 6日

OCIでローコード開発環境を用意してStreamingサービスと連携してみる（3）

石田翼

メルマガ登録する

メルマガ登録する

クラウドサービス部の石田です。

運用の場面でも使いやすいローコード開発環境をOracle Cloud Infrastructure（以下、OCI）上に構築する連載の第2回では、OCIのStreamingサービスとNode-REDが接続できるようになりました。第3回となる今回は、それを使って簡単なフローを作成して試してみましょう。実際の利用シーンが想像しやすそうな、運用の場面を想定したフローを作ってみます。

想定する利用場面
イベント・通知設定
OCI CLI設定
フロー作成
動作確認
おわりに

想定する利用場面

StreamingサービスはOCIの他のサービスと連携することができるので、それを使うとさらに応用の可能性が広がります。今回はイベントサービスから利用してみたいと思います。模式図にすると下記のようになります。

模式図。EventsからOCI Streaming、Kafka API互換機能でNode-RED OCI Computeへ、OCI CLIで各種OCIサービスへ。

該当するイベントが発生すると、イベントサービスの機能でその内容をOCI Streamingに書き込み、それをNode-REDがKafka API互換機能で読み込みます。Node-REDのフローでイベント内容を処理して、最終的にその結果を基にOCI CLIを実行します。それによって各種OCIサービスをコントロールできるようにします。

Streamingサービスの使い方としては、第1回の「ストリーミングとは」で紹介した中の、「非同期メッセージングハブ」に近い使い方になります。同様のイベントサービスとの連携システムではFunctionsサービスが使われることが多いですが、Functionsだと簡単とはいえコードの開発や管理が必要になり、付随する作業がそれなりに煩雑です。その点ローコード環境は、実際に動くフローがGUIで編集できるのでわかりやすく、またコードを別途管理する必要がないというメリットがあります。

今回はこの構成を使って、特定のサーバの起動・停止のイベントを契機として、そのイベント内容を整形してOCIの通知サービスからメールを送信するようなシステムを作ってみましょう。

イベント・通知設定

イベントと通知サービスの設定をしていきます。以前書いた記事^※1の「イベント・ルールの設定」の章で作成しているイベントと、こちらの記事^※2の「通知サービスとは」の章で作成した通知を使います。そちらを参照してイベント・ルールと通知サービスの設定を行ってください。「server01」というインスタンスの起動・停止というイベントと、指定したメールアドレスにメールを出すという通知が作成されます。

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

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

ただしイベント・ルールのアクション設定のみ異なり、以下のように設定します。

アクション画面。アクション・タイプを「ストリーミング」、ストリーム・コンパートメントを「ストリームが存在するコンパートメント」、ストリームを「to-mailing-topic」に設定。

項目	設定内容
アクション・タイプ	ストリーミング
ストリーム・コンパートメント	ストリームが存在するコンパートメント
ストリーム	今回作成したストリーム（to-mailing-topic）

また参照した記事にもありますが、用意した通知のOCIDは後程使用するので、控えておいてください。

OCI CLI設定

Node-REDが稼働しているサーバでOCI CLIを使用したいので、設定していきます。

一般にOCI CLIではインスタンス・プリンシパルを使用するので、OCI側で権限の設定をした後、OS上でOCI CLIの設定をしていきます。

権限設定

動的グループとポリシーを設定します。まず動的グループは任意の名前で、以下のように設定して特定のコンパートメント内のVMインスタンスをすべて含むようにします。<your compartment id>の部分は、Node-REDが稼働するサーバがあるコンパートメントのOCIDを指定します。

ALL {instance.compartment.id = '<your compartment id>'}

ポリシーは以下のように設定し、動的グループに含まれるリソースが通知サービスを利用できる権限を与えます。<dynamic_group_name>は上で設定した動的グループの名前、<your compartment>は通知サービスを作成したコンパートメント名を指定します。

Allow dynamic-group <dynamic_group_name> to use ons-topics in compartment <your compartment>

OS設定

OS上でOCI CLIをセットアップしていきます。Node-REDが稼働しているサーバ上で以下コマンドを実行し、OCI CLIをインストールします。

sudo dnf install python39-oci-cli

インストールされた後は、OCI CLIをNode-RED上から実行できるように設定します。Node-REDはデフォルトですと「nodered」というユーザで実行されるので、そのユーザにスイッチしてから初期設定を行います。初期設定の際は、利用ユーザとテナンシーのOCIDと、利用するリージョンの情報が必要なので用意しておいてください。ただし利用ユーザの情報は実際使わないので、任意のユーザで構いません。

sudo su - nodered
oci setup instance-principal

説明のメッセージが表示された後、いくつかの質問をされます。各種メッセージを除外して質問部分だけ抜き出すと以下のようになるので、適宜回答します。

Do you want to create a new config file? [Y/n]: y ←新しい設定ファイルを作成するので「y」
Do you want to create your config file by logging in through a browser? [Y/n]: n ←ウェブブラウザ経由の設定はしないので「n」
Enter a location for your config [/home/nodered/.oci/config]:（空）←デフォルトを採用
Enter a user OCID: <your user OCID> ←利用者のユーザのOCIDを入力
Enter a tenancy OCID: <your tenancy OCID> ←テナンシーのOCIDを入力
Enter a region by index or name(e.g.
1: af-johannesburg-1, 2: ap-batam-1, 3: ap-chiyoda-1, 4: ap-chuncheon-1, 5: ap-chuncheon-2,
6: ap-dcc-canberra-1, 7: ap-dcc-gazipur-1, 8: ap-delhi-1, 9: ap-hyderabad-1, 10: ap-ibaraki-1,
11: ap-melbourne-1, 12: ap-mumbai-1, 13: ap-osaka-1, 14: ap-seoul-1, 15: ap-seoul-2,
16: ap-singapore-1, 17: ap-singapore-2, 18: ap-suwon-1, 19: ap-sydney-1, 20: ap-tokyo-1,
21: ca-montreal-1, 22: ca-toronto-1, 23: eu-amsterdam-1, 24: eu-budapest-1, 25: eu-crissier-1,
26: eu-dcc-dublin-1, 27: eu-dcc-dublin-2, 28: eu-dcc-milan-1, 29: eu-dcc-milan-2, 30: eu-dcc-rating-1,
31: eu-dcc-rating-2, 32: eu-dcc-zurich-1, 33: eu-frankfurt-1, 34: eu-frankfurt-2, 35: eu-jovanovac-1,
36: eu-madrid-1, 37: eu-madrid-2, 38: eu-marseille-1, 39: eu-milan-1, 40: eu-paris-1,
41: eu-stockholm-1, 42: eu-zurich-1, 43: il-jerusalem-1, 44: me-abudhabi-1, 45: me-abudhabi-2,
46: me-abudhabi-3, 47: me-abudhabi-4, 48: me-alain-1, 49: me-dcc-doha-1, 50: me-dcc-muscat-1,
51: me-dubai-1, 52: me-ibri-1, 53: me-jeddah-1, 54: me-riyadh-1, 55: mx-monterrey-1,
56: mx-queretaro-1, 57: sa-bogota-1, 58: sa-santiago-1, 59: sa-saopaulo-1, 60: sa-valparaiso-1,
61: sa-vinhedo-1, 62: uk-cardiff-1, 63: uk-gov-cardiff-1, 64: uk-gov-london-1, 65: uk-london-1,
66: us-ashburn-1, 67: us-ashburn-2, 68: us-chicago-1, 69: us-gov-ashburn-1, 70: us-gov-chicago-1,
71: us-gov-phoenix-1, 72: us-langley-1, 73: us-luke-1, 74: us-newark-1, 75: us-phoenix-1,
76: us-saltlake-2, 77: us-sanjose-1, 78: us-somerset-1, 79: us-thames-1): 20 ←使用するリージョンを入力。今回は「ap-tokyo-1」なので20を入力。
Do you want to generate a new API Signing RSA key pair? (If you decline you will be asked to supply the path to an existing key.) [Y/n]: y ←利用しないが「y」にしておく
Enter a directory for your keys to be created [/home/nodered/.oci]:（空）←デフォルトを採用
Enter a name for your key [oci_api_key]:（空）←デフォルトを採用
Enter a passphrase for your private key ("N/A" for no passphrase): N/A ←パスワードなしにするので「N/A」
Repeat for confirmation: N/A ←再入力

初期設定終了後、ホームディレクトリの.oci/configファイルを編集して、userとfingerprintとkey_fileとの3エントリをコメントアウトします（インスタンス・プリンシパルでは不要なエントリ）。次に.oci/oci_cli_rcというファイルを新規作成し、以下の内容を記載します。<your compartment id>は通知を作成したコンパートメントのOCIDを設定してください。これで実行時に毎回同じ値を指定することになるオプションを省略できます。

[DEFAULT]
compartment-id = <your compartment id>
auth=instance_principal

ここまでできたら、動作確認をしてみましょう。先ほど用意した通知の情報を取得してみます。

oci ons topic list --all

これを実行すると、設定されている通知の一覧がJSON形式で出力されます。「name」属性の値が、先ほど作成した「test_topic」になっているものが表示されれば成功です。

フロー作成

以上を用意したうえで、このようなフローを作成していきます。

それぞれのノードでは以下のような処理を行っています。

順序	ノード	処理内容
1	to-mailing-topic	OCI StreamingからイベントJSONを取得
2	json	イベントJSONを解析する
3	タイムゾーン変更	イベントJSONの時刻がUTCなのでJSTに変更する
4	XX生成	ここから3並列に分かれ、それぞれOCI CLIに渡す内容である本文、表題、通知のトピックのOCIDの内容を生成する
5	オプション文字列化	生成された内容を元に、OCI CLIのオプション文字列のフォーマットに成型する
6	join 3	3つのオプション文字列を1つの文字列に連結する
7	exec ocicli	連結されたオプション文字列とともにOCI CLIを実行し、通知サービスを起動する
8	json	OCI CLIの出力JSONを解析する
9	debug 1	OCI CLIの出力をデバッグウインドウに出力する

それぞれのノードの詳細設定を紹介します。画面からわかりにくい設定値については表で補足しています。

to-mailing-topic

第2回の動作確認で設定した内容と同じになります。

json

「パーサ」の中にある「json」ノードを使用します。デフォルトのままです。

タイムゾーン変更

「機能」から「change」ノードを使用します。JSONata式^※3と呼ばれる処理系を利用して、イベントの発生時間のタイムゾーンがUTCなのをJSTに変換する処理を行っています。

※3 JSONata

項目	設定内容
代入する値	JSONata式
代入する値	$fromMillis($toMillis(payload.eventTime),'[Y0001]/[M01]/[D01] [H01]:[m01]:[s01] [z]','+0900')

本文生成

「機能」から「template」ノードを使用します。イベントJSON内の値を利用して、メールの本文を作成しています。テンプレートの書式は置換したい変数名を波括弧でくくるMustache^※4と呼ばれる形式で記述します。

※4 GitHub - mustache/mustache: Logic-less Ruby templates.

変数「payload」の下の階層に、Streamingサービスから渡されたイベントJSONがそのまま入っています。イベントJSONの実例が私の以前の記事^※5にあるので、そちらも合わせてご覧いただくと分かりやすいと思います。

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

変数展開後の文字列はHTMLエスケープされるので、そのままだと時刻文字列の「/」（スラッシュ）がエスケープされてしまいます。そのため「&」指定を入れて時刻文字列がエスケープされないようにしています。

項目	設定内容
テンプレート	インスタンスの操作を検知しました。コンパートメント： {{payload.data.compartmentName}} 対象サーバ： {{payload.data.resourceName}} 時刻： {{& payload.eventTime}} 操作内容：{{payload.data.additionalDetails.instanceActionType}}

オプション文字列化（「本文生成」の後）

「機能」から「template」ノードを使用します。「本文生成」でできたメッセージ本文を、OCI CLIに渡せるオプション文字列に整形します。本文生成時と同様の理由で「&」指定をしています。

表題生成

本文生成と同様にして、通知の表題を作成しています。

オプション文字列化（「表題生成」の後）

オプション文字列化（本文生成後）と同様です。

TOPIC OCID

本文生成と同様に、先に用意した通知のOCIDを生成しています。イベントJSONの内容は使用しておらず、OCIDを固定文字列として記載しています。

オプション文字列化（「TOPIC OCID」の後）

オプション文字列化（本文生成後）と同様です。

join 3

「シーケンス」から「join」ノードを使用します。半角スペースをデリミタにして、3つのフローから来た文字列を連結します。画面ショットではわかりませんが、「連結文字」には半角スペースが入っているのには気をつけてください。

exec ocicli

「機能」から「exec」ノードを使用します。Node-REDが稼働しているOS上でコマンドを実行するノードです。OCI CLIで通知サービスにメッセージを発行するコマンドラインを、これまでで生成したオプション文字列を引数として実行します。これによって通知サービスが動作します。

ちなみに画面を見るとこのexecノードには出力コネクタが3つあるのがわかりますが、これは上から標準出力、エラー出力、戻り値が出力されます。今回は一番上の標準出力を後続に繋いでいるので気をつけてください。

json

1つ目のjsonと同様デフォルトです（画面ショット省略）。OCI CLIのコマンド実行の出力結果のJSONを解析します。

debug 1

「共通」から「デバッグ」ノードを使用します。デフォルトのままです。OCI CLIの実行結果をデバッグウインドウに表示します。

動作確認

それでは作成したフローが動作するか確認するため、イベントの発生条件である「server01」というインスタンスの起動・停止を実際にやってみましょう。OCIコンソールから起動・停止操作をすると、うまく動けば暫しの時間の後、デバッグウインドウに以下のような表示が出てきます。OCI CLIの正常動作の出力結果になります。

これを踏まえて通知サービスに設定したメールアドレスのメールボックスを確認すると、以下のようなメールが届いているはずです。

フローで生成した表題や本文でメールが届いています。これでNode-REDを使用したメール通知が実現できました。

おわりに

OCIのイベントサービスとNode-REDのローコード開発環境、そしてOCI CLIを連携させることができました。かなり応用性が高そうなシステムになったのではないでしょうか。

例えば、オブジェクトストレージにテキストログファイルが配置された際、そのファイル名から適切なFunctionsを選びファイル内容を解析・集計してもらうという処理も、このシステムで実現できます。同じようなことはイベントサービスだけでもできますが、Node-REDを使うと複数のFunctionsの結果を引き渡しながら順次実行するフロー処理が可能になります。Functionsから戻ってきた内容を元に条件分岐もできるので、エラー対応も可能です（Sagaパターンと呼ばれるアーキテクチャ）。

また、OCIのオートスケーリング機能は、基本的にはメトリックやタイムスケジュールで制御されますが、Node-REDを利用すれば、マーケティング施策による急激なアクセス増など事前に予想される負荷変動への対応や、クラウド上のイベントを契機としたスケーリングなど、複雑な条件にも柔軟に対応できます。

基本的にはイベントサービスとFunctionsで実装できるものはほとんどが実現可能です。最初は試行錯誤しやすいNode-REDのフローで実装し、軌道に乗ってきたらより安定したサービスのFunctionsに実装し直すという運用ができると、棲み分けもできそうですね。活用のアイデアはまだまだ広がりますので、ぜひ皆さまの環境でも試してみてください。

さらに、OCI Streamingサービスについても、マネージド化によって利用が大きく広がりつつある領域であり、「Streaming Architecture」として注目されている分野です。本稿が理解を深めるきっかけになりましたら幸いです。

ラックではOCIだけではなく、AWS、Microsoft Azureも取り扱っており、マルチクラウドやハイブリッドクラウドを含め、お客様の課題や環境に合わせた最適な構成をご提案しています。クラウド活用やシステム構成に関するお悩みがありましたら、ぜひラックまでお問い合わせください。