こんにちは IoT チームの田中です。
この記事は Luup Advent Calendar の 6 日目の記事です。
LUUP 車両の通信は SORACOM SIM を利用していて、SORACOM API を使って通信状況や稼働状況などを30分程度の間隔で定期的に記録するようにしています。
どのようにデータを記録して、そのデータをどう活用するかは、まだまだ試行錯誤の段階のため、プロトタイピングしやすいように Node-RED というローコードツールを GCP の中につくって SORACOM API からの SIM 情報取得を定期的に動かしています。
今日はこの仕組みの紹介と、いろいろな Tips をご紹介します。
ざっくりとこのような仕組みです。 Compute Engine 上に Node-RED を動かし、 Node-RED から SORACOM の List SubScriber API に問い合わせて SIM の情報を取得し BigQuery に記録する流れです。
もし、Compute Engine 上で Node-RED を動かす方法が気になる方は、最低限の設定ですが私の GCP Compute Engine の e2-micro で Node-RED に最低限の構築するメモ – 1ft-seabass.jp.MEMO の記事を見ていただくと雰囲気がつかめるかと思います。
実際の Node-RED の中身
さきほどの図の流れを Node-RED で、いま実現しているものがこちらです。2022 年 12 月現在、うまく動いています。
大きく以下のように分けられます。
- SORACOM API のトークンを定期的に更新する処理
- SORACOM API から大量の SIM 情報を取得する処理
- SORACOM API で取得した SIM 情報を BigQuery に記録する処理
ひとつひとつご紹介していきます。
SORACOM API のトークンを定期的に更新する処理
このあたりが、SORACOM API のトークンを定期的に更新する処理です。
はじめに: API キーと API トークンの取り扱いについて | SORACOM API 利用ガイド | ソラコムユーザーサイト - SORACOM Users
こちらにあるように、SORACOM API には API キーと API トークンの有効期間があるので、いまは 2 時間ごとに更新しています。
中心の処理をしている部分です。 http request ノードで SORACOM API に問い合わせをしています。Node-RED では inject ノードというノードで定期的な実行ができるので、今回の 2 時間ごとの実行も作りやすくて重宝しています。
有効期間はデフォルトでは 24 時間なので、もっと更新頻度を間隔をあけてもよいです。このあたりも、最初の試行錯誤の段階で、12 時間（半日）のような長く間隔を開けるのは不安だったので、この頻度です。もう半年以上無事に動いているので、大丈夫なはずですね。落ち着いたらもっと間隔をあけるつもりです。あとは変更する勇気だけですね！
SORACOM API から大量の SIM 情報を取得する処理
このあたりが、SORACOM API から大量の SIM 情報を取得する処理です。
メインはこのあたり。
inject ノードをきっかけに 30 分ごとで実行し SORACOM API の List Subscriber API に対して 100 件のSIM ごと問い合わせをしています。LUUP 車両で使われる SIM の数はかなり多いので、一気に取りに行ってしまうと API 取得数制限に引っかかってしまう可能性があるので 100 件取得を何度も回すようにしています。
そして「length チェックしてループ継続」の switch ノードあたりで、もし 100 件であれば次も継続、100 件以下だと最後まで取得できたな、ということで問い合わせを止めます。つづけて、次のデータを取得するときは API に問い合わせるときlast_evaluated_key という値に、いま取得した最後の IMSI を付与すると、直後の 100 件を取りに行く流れです。
SORACOM API で取得した SIM 情報を BigQuery に記録する処理
このあたりが、SORACOM API で取得した SIM 情報を BigQuery に記録する処理です。
さきほど SORACOM API から取得した 100 件ごとのデータを、そのまま BigQuery に記録しています。
絶え間なく 100 件ごとのデータが入ってくるところですが、このデータを一旦受け止めて遅延させる delay ノードが良い仕事をしています。
この delay ノードの設定はこのようになっています。5 秒間に 1 メッセージだけ流れるダムのような役割です。つまり SORACOM API からの繰り返し取得しているところは一気に行いつつ、これ以降は過剰にデータが流れず API へのアクセス制限にも優しく、かつ Node-RED 内の負荷もデータが詰まらず抑えられる処理になっています。BigQuery への書き込みにも優しいです。
はじめのころ、delay ノードがないときは容赦なくデータが送られていました。このときは処理やデータが滞り Node-RED の処理が極端に遅くなって不安定になったり、API の取得自体も動きが怪しくなっていたので、この仕組みの導入は良かったと思っています。あのころから、2倍くらいの SIM 数を扱ってますが、耐えられています。
シンプルな仕組みながら、もうひとつ注目ポイントはこちらの bigquery-insert ノードです。Node-RED ではこの node-red-contrib-google-cloud ノード群を使うと GCP の色々な仕組みにアクセスしやすいです。bigquery-insert ノードもその 1 つです。
この bigquery-insert ノードの設定はこのようになっています。詳細は伏せていますが、Project は BigQuery のプロジェクト、Dataset は BigQuery のデータセット、Table は BigQuery のテーブルという項目で分かりやすく設定できます。
Credentials の項目も注目ポイントです。本来であれば、サービス アカウントの設定ファイルが必要ですが作成していません。
同じ GCP のプロジェクトの中で、Compute Engine 側で API と ID の管理のところで BigQuery を有効にすることで、サービス アカウントを作成せず Node-RED から同プロジェクトの BigQuery に書き込めています。
ちなみに、このナレッジは Luup 社内で GCP に慣れた方からアドバイスいただいて実現できたもので、私自身とても勉強になりました。こういったやり取りはチームで動いてこそだと思います。
稼働確認ダッシュボード
Node-RED でダッシュボードを表示する仕組み node-red-dashboard ノードを使うと実現できるので、このような稼働確認ダッシュボードもあります。
たとえば、さきほどのSORACOM API から大量の SIM 情報を取得する処理の周辺で、取得処理の経過や完了をこちらのダッシュボードに必要な情報をグラフで表示しています。
はじめのころは、トークンの再取得がうまく継続するか不安だったり、delay ノードを使わず一気に処理を行って不安定になったりしていたためよく見ていました。最近は、ある程度安定して稼働しているので、これを見る機会が減ったのは良いことです。
おわりに
SORACOM API の定期取得を GCP で作った Node-RED で取得する Tips を、実際に動いているものを交えてお伝えしました。
大量の SIM のデータ取得はトライアンドエラーをしながらでしたので、このように Node-RED を使ってローコードで試行錯誤をして、ある程度の必要な処理を整えて安定できたのは良かったです。時間をあけて断続的にアップデートするときもあるので、実際のフローを目で見て思い出せるので安心感はありました。
また、必要時な情報が SORACOM API から欲しくなったり、整理したくなるときはあると思うので、うまく活用していきたいと思います。
Discussion