MODE JAPAN Blog

IoTを活用したデジタルトランスフォーメーションのための情報、開発の現場から技術的な情報や取り組みについてお届けします。

新しいMODEプラットフォームのWebhooks。開発の裏話

2021年9月13日、MODEでは「MODE IoTプラットフォーム、外部システムへの連携を大幅強化」というプレスリリースを発表しました。

news.tinkermode.jp


f:id:etoamode:20210915150910j:plain
今日は、新しいMODEプラットフォームのWebhooksの開発を担当した松下に、開発の裏側について聞いてみました。

f:id:etoamode:20210915150934p:plain


- 新しいWebhooksによって、何ができるようになったのですか?

MODE IoTプラットフォームを使った多くのIoTユースケースでは、監視しているデータに何か異変があった時にはアラート通知を流すことがとても多いです。理想的には、Slackのように普段使っているコミュニケーションツールにアラートが流れてきたら嬉しいよね、というのがありました。
しかし、このときに一つ困ったことがあります。SlackでもLINEでもそうなんですけど、APIを公開している各社さんはそれぞれ「うちはこういうフォーマットじゃないとデータを受け付けませんよ」という取り決めがあるんです。そのフォーマットのメッセージを送ってくれたら、そのツールでメッセージ出してあげるよと。

ここではSlackを例にして話しますね。

今までのMODEのWebhooksって「MODEはこのフォーマットしか送らないよ」って決まってたんですよ。MODE形式でデータが飛んで行きますが、それってSlackが欲しい形式ではなかった。
そこでお客様が自分でサーバーを設置して、その中にMODEから受け取ったデータをSlack形式に変換してSlackに送ってあげるというプログラムを入れておく必要がありました。

f:id:etoamode:20210915151137p:plain
今回の開発では、送信データがMODE形式しか設定できなかったものを、カスタマイズできるようにしました。そうするとSlackに理解してもらえるフォーマットを最初からMODEが送信できるようになるわけです。

メリットは色々あって、最初にお客様がサーバーを設置する必要がなくなるし、データを変換するためのプログラムを開発する手間もない。サーバーを運用する維持費もかからないし、サーバーのメンテナンスの手間も省けます。
送信できるデータ形式も、外部連携を用意してくれているシステムであれば対応できます。

- 開発の裏話について聞かせてください。

今回、開発裏話的な話が2つあるんです。

1)サービス中断をさせないシステム移行

一つ目は、よりメンテナンス性の高いインフラ基盤に移行させたことです。

MODE IoTプラットフォームのインフラって、新しいものと古いものがあって、古いスタイルで作られた方は、維持コストが少し高いんですね。昨今はエンジニアの手間を省くために、作業が自動化されてたりするんですが、その自動化がされきっていないとか、エンジニアとして維持するのにコストが高いものになっているのが古いスタイル。なので途中からエンジニアの島川さんがその辺りがラクになるようなのを少しずつ入れていってくれてたんです。

実はWebhooksはもともと旧インフラで存在していたものなんです。なので、今回のバージョンアップを機に、新インフラの方にできるだけ移行させることにしました。今までは全て旧スタイルで運用していたんですけど、徐々に新スタイルに移行しているところなんですね。だから、旧スタイルと新スタイル両方をMODEのプラットフォーム上で動くようにしているんです。

旧バージョンのWebhooksでは、MODEフォーマットでしかデータ送信できないですが、新バージョンなら今回開発したAPIに応じたフォーマットを設定できるわけです。

今回のWebhooksが新バージョンになった通り、既存のお客様でも、様々なフォーマットで取り出せるようにしたいという課題認識はありました。
今までのお客様向けの旧サービスを一瞬たりとも止めずに新サービスに移行するため、旧Webhooksもそれはそれで残しておくことにして、新しいのは新しいインフラの上に作って並行稼働させました。その後、徐々に新バージョンへ移行していくという作戦を取りました。

- 古いものの上に新しいものを載せて開発するのではなくて、古いものと新しいものを同時に存在させて走らせておくんですね。

古いものの上に新しいものを載せて開発するスタイルも、世の中にはもちろんありますし、かなりスタンダードな考え方です。
では、なぜ並行稼働型にしたかというと、新インフラの上にWebhooksを構築したかったのと、既存のお客様の安全のためです。万が一、リリース途中で新しい仕組みや新Webhooksでトラブルがあったとなったら、移行作業を一旦止めて、旧スタイルを使い続けるということもできるので。

2)セキュリティを考えシンプルな独自テンプレートエンジンを開発

もう一つはテンプレートエンジンを独自開発したことです。

- 「テンプレートエンジン」って何ですか?

例えば、MODEのWebhooks設定画面で、SlackのAPIページにあるコードを真似して

{
     "text": "Hello, world."
}

と設定しておくと何かアラートが出た時、Slackに「Hello, world.」とテキストが送られて行くという意味だと思ってください。
ただこのままでは、冷蔵庫の温度が20度超えた場合でも「Hello, world.」と飛んでいくし、倉庫に誰か侵入したっぽいという場合も「Hello, world.」と飛んで行く。全部「「Hello, world.」という文字が飛んで言ってしまうんですよ。

テキストの内容は、起きている事柄に応じて変化して欲しいですよね。そこで今度は「この温度センサーで今何度になりました」という情報が送られるようにしてみます。

{
    "text": "センサーxxで温度がxxまで上がりました!"
}

この時「xx」となっている部分は、実際のデータに応じて書き換えられて欲しいですよね。そこでエンジニアの世界でよく使われるのがテンプレートです。
テンプレートという型があって、その型に色々なものをはめてアウトプットが出るようなイメージです。実際に「xx」っていうのをはめてくれるテンプレートの処理をしてくれるプログラムのことをテンプレートエンジンと呼びます。

実はこうした置き換えの処理をしてくれるプログラムというのは、世の中にたくさんあるんです。こういう処理ってすごくありふれているので、オープンソースとかでこういうテンプレートエンジンという処理をしてくれるものはたくさんあるんです。
でも世の中に出ているものって、色々なシチュエーションに耐えられるようにするために万能なんですね。でもMODEの使い方からすると、その万能さが邪魔というか、求めていない余計なことをしてしまうものがあったりしたので、MODEの使い方にフィットしたテンプレートエンジンを私が全部作りました。

- Webhooksによって、様々なツールと連携ができるようになり、機能がますます充実してきたMODE IoTプラットフォーム。これからも世界中のビジネスにおけるDXを加速させられるよう、使い勝手の良いシステムにして行きたいですね。
お話を聞かせていただきありがとうございました!