#ssmjp で最近のサーバーレスの話をしました

2/16のssmonline #32にて、「最近のサーバーレスの話」を話してきました。

スライドはこちら:

 

おさらい:サーバーレスってなんだっけ?

まずは軽くおさらいからです。

サーバーレスは性質をあらわしているので0/1であてはまるものではないですが、やはり完全従量課金という課金モデルに近づける努力をしているものをそう呼んでいきたいところですね。

最近のサーバーレス開発

サーバーレスといえば、FaaS(AWS LambdaやAzure Functions)で様々なサービスをイベントドリブンでつないでいくアーキテクチャが注目されてきました。「もう古い」はちょっと盛りましたが、単純にFaaSで処理をつなぐのでは、そういったイベントドリブンな「ピタゴラ装置」を管理するのが大変です。

失敗時の再送や、異常データの除外(DLQへの積み替え)、イベントデータの書き換え・詰め替え、条件によるフィルタリングなど、イベントドリブンなシステム設計をする上で共通で必要そうな機能もはっきりしてきました。

それらを「オーケストレーション」と「コレオグラフィ」というふたつのアーキテクチャパターンから管理しやすく整理しようというのが現在の大きな流れです。

オーケストレーション型の管理

ワークフロー全体を一つのサービスの上で定義して様々なサービスを組み合わせるAmazon Step Functionsなどは、見方を変えれば中心となるオーケストレーターが他のサービスを呼び出す「オーケストレーション型」です。比較的密な結合をすることが得意です。

その一方で、より疎な結合をしたいのであれば、FaaSを挟むかわりに、イベントバスを介して接続するというパターンが増えています。これは中央集権的な管理ではなく「コレオグラフィー型」と言えます。イベントバスは技術的な要素としては賢いPub/Sub基盤ですが、イベント処理のための機能が盛りこまれています。

FaaS Updates

もちろんFaaSの仕事はサービスをつなぐだけでは無いので、FaaS自身も様々な拡張がされています。この数年の大きなアップデートをまとめたのがこのスライドです。コンテナとの融合や、対応言語の拡充は各社共通しています。同時実行数の制御など、弱みとされていた点もつぶしてきています。

FaaSの開発もいろいろ課題がありましたが、ここで「小ネタ」として紹介したように、地味にいろいろ改善がされています。少し前にためして辛いなーと感じた人もあらためてためしてみるチャンスです。

FaaSの次の戦場:CDNエッジ

いま一番ホットな戦場のひとつが「CDNエッジ」です。なかなかに技術的制約の強い環境ですが、フレームワークなども登場してきたことで一気に開発者体験が良くなってきました。

まとめ

これでサーバーレス分野に興味を持った方むけに、「Serverlessを支える技術」で詳しく解説しているので、よろしくおねがいします。

SecHack365 応募受付中

https://sechack365.nict.go.jp/og/ogimage22.png

情報通信研究機構(NICT)では、25歳以下のエンジニア向けに若手セキュリティイノベーター育成プログラム「SecHack365」というのをやっています。

sechack365.nict.go.jp

いままさに2022年度の参加者を募集していて、5月10日の12時までということで募集期間も残り少ないのですが、あらためて宣伝です。

SecHack365について

詳しいことは開催概要をみて欲しいのですが、(今のところ)オフラインのイベント(4回)と、オンラインのイベント(2回)をまぜる感じで、来年3月の成果発表会に向けて6回のイベントがあります。5つのコースと、もう少し細かくわけたゼミごとに、イベントに限らず年間を通していろいろな形で支援をおこなっていきます。

コース・ゼミごとですすめかたが結構ちがうので、そのあたりはコース概要をご一読くださいませ。

仲山ゼミについて

例年「開発駆動コース」にてゼミを担当しています。

詳しい内容や、過去の修了生の作品などは、こちらにまとめてあります。

nekoruri.notion.site

この「仲山ゼミ」では、新しい技術を世の中に拡げることで世界を変える意欲がある人を募集しています。「この技術はすごい!自分ならこう活かしたい」というような開発テーマをすでに持っている人をターゲットに、まずは持ち込んだ開発テーマを進めてもらいながら、SecHack365をフルに活用し、自らの定めたビジョンに向けて走りながらそのテーマの方向性や、最初に見えていたゴールのその先を、表現と対話によって模索していきます。

たとえばこんな人を募集しています。

・サーバーレスでセキュアなアプリケーションを実現したい

・セキュアなウェブを支える技術スタックを改善したい

・新しい世界観を実現するウェブサービスを開発したい

これ以外でも私がサポートできそうなテーマは採用しますので、まずはぶつけてみてください。

私は決してELFバイナリがすらすら読めたりハイパーバイザーを書いたりするような優秀なセキュリティエンジニアではありません。ですが、トレーニーがやりたい事を様々な視点からどうやって拡げていくかという助言には自信があります。

自分が注目している技術の力で世界を変えたい人の応募をお待ちしています!

ポイント

あちこちで言ったり書いたりしていることをまとめておきます。

  • 応募課題はコミュニケーションです。私達に伝えたいと思っていることを漏れなく書いてきてください。
  • 技術力や表現力はこの1年で磨いていけます。でも、取り組みたいと思っているテーマについて、自分がどう考えているのか知っているのはあなただけです。あなたは、どんな技術が好きで、どこを面白く感じていて、それを使って何をしたいと考えていますか?その技術の力で、どんな世界を作っていきたいですか?
  • 技術的現実感を持ちつつ、夢は大きく!

というわけで、残り2日ですが、よろしくです!

 

 

 

LayerXに転職しました

まる6年お世話になったWHEREを退職し、2月からLayerXではたらいています。

WHEREでの6年間

だいたい3年くらいで転職していることが多いので、6年というのは過去最長でした。まあうしろの2年くらいはほとんど成果が出せていなかった(後述)ので、実際の長さとしてはそれほど変わらずかもしれません。

WHEREでは、ちょうど自分が入ったタイミングではじめたIoTビジネスにおいて、デバイス管理のためのデータ処理基盤を担当していました。

いわゆるお客さんに面するSaaS本体の部分は内部APIを介して別チームが見ていて、実際のデバイス側と向き合ってデータの送受信を受け持ち、センサーデータの一次処理などもここでやっています。Bluetoothメッシュネットワークを活用したEXBeaconという独自デバイスも作っていたので、立ち上げ期はエッジ側のゲートウェイの実装とかも見ていました。ウェブエンジニア10年以上続けてきて、ここでまさかのC言語を仕事で使う事になるとは。

当時自分ひとりチームだったということもあって、アーキテクチャについては自由にやらせてもらい、FaaSとPubSubを中心にしたフルサーバーレス構成で組んでいます。当時はまだ今ほどサーバーレス開発の道具が揃っていない状況でしたが、IoTデータ基盤というのは、高頻度に集まってくるデータを時系列データ処理していくというのがメインの仕事なので、ひとりチームというのを差し引いても、正しい選択だったと今でも思っています。

つくっていたもののざっくりとした概要は、過去のスライド見ていただければと。

IoTとの通信部分は、まだリリースしたばかりのSORACOMを活用していました。ちょうどSORACOM Funnelもリリースされたばかりで、立ち上げ時期にいろいろと楽をさせてもらいました。

どれだけFunnelが好きかはこちらの記事をご覧ください。

d.nekoruri.jp

いわゆる情報システム担当も兼務していたので、IDやデバイスの管理をしたり、情報セキュリティにまつわる社内ルール作ったりプライバシーマーク取ったり、そういったものも担当していました。

ちなみに前回の転職エントリはこちら。

d.nekoruri.jp

うつ病と転職

まあそんなこんなで2016年からいろいろやらせてもらっていたのですが、2019年頃からうつ病を再発しまして、そこに2020年からのコロナ禍が直撃し、思ったように働くことができないという状態が続いていました。会社のステージとうつ病の改善というところが噛み合っていないというのが根本にあり、このままだらだらと続けてもお互いに良くないなと思い、転職することにしました。

ありがたいことに、「うつ病の寛解と転職をセットで」という希望を伝えた上でお声掛けいただいた会社さんと話をさせてもらい、最終的にLayerXに参加することにしました。

LayerXのポイント

きっかけはセキュリティ・キャンプなどでもお世話になったken5先生が居るということで気になっていたのですが、とにかく会社としてのあり方が気に入った、ということにつきます。

「すべての経済活動を、デジタル化する。」というのを会社のミッションにしていて、請求書の受注処理や企業内の申請においてきちんとITを活用するバクラクシリーズや、資産運用における様々な「負」をITで解決するアセットマネジメント事業、企業や行政の持つパーソナルデータを、法規制に準拠し、組織を横断して安全に活用するための次世代のプライバシー保護技術など、いまのところ3つの分野に展開しています。

bakuraku.jp

corp.mitsui-x.com

www.anonify.layerx.co.jp

内側を見てみると、この規模の会社としてめちゃくちゃに社内ITのセキュリティ統制ができているというのがあり、今までのキャリアを踏まえた上できちんと社内ITをやりたいという気持ちにうまくはまりました。

LayerXをひとことで言うと、「今どきのプラクティスをきちんとやっている会社」です。気に入っている行動指針は「徳」です。やっぱりそれなんよ。

いままでいろいろなステージのIT企業に参加してきたのですが、いわゆる「すごい伸びている最中のスタートアップ」には所属したことがなかったというのもポイントですね。

今後の役割

実は文章で書くと前職とあまり変わらないのですが、社内のITを見るコーポレートエンジニアと、バクラクシリーズを展開するSaaS事業部のSREの兼務です。Terraform書いてます。比重としてはコーポレートエンジニアがメインです。やってることは採用情報を見てください。是非見てください。絶対見てください。

open.talentio.com

open.talentio.com

今のところ、とにかく採用人数が多いうえにトライアル採用などもあるので、アカウント管理まわりを自動化したり、AWSやAzureAD、Google Workspacesなどを活用して安全なガードレールを整備したりといった、他の人たちが気持ちよく安心して仕事できる環境づくりを進めたりしています。

こういったことがどこの会社でも当たり前に行われるようになったらうれしいので、今後どんどん情報共有もしていくつもりです。アウトプットしないのは知的な便秘!

よろしくおねがいします

折角の連休ということで、Meetyも開けました。

あまり人と話すのが得意ではないのでたぶん期間限定になりそうですが、LayerXのことでも、LayerXに関係無いことでも、気軽に声掛けてください。

meety.net

採用も!頑張って進めているので!応募お願いします!!!(平伏)

 

モヒカンSlack クラウド関係たなおろし

モヒカンSlackは、参加者が育てるIT系情報収集用のSlack公開ワークスペースです。

qiita.com

酋長(スペース管理者のkanbeさん)以外はとくに誰がどうとかいう役割はないのですが、クラウド関係の購読フィードのメンテナンスを勝手につづけています。

モヒカンSlackができて5年ということで、クラウド関係でどんなフィードを購読しているのか棚卸ししてみました。モヒカンSlackに参加して見るなり、つまみぐいして自分のSlackチャンネルでフィード購読するなり参考になればと思います。

フィードのURLについては、過去記事も参考にしてください。

d.nekoruri.jp

気になる人が多そうなので先に書いておくと、タグや検索機能がないSpeaker Deckに関しては、はてなブックマーク頼りになっています。

国内ITアドベントカレンダー全部入れた #advent-calendar-2020 もよろしくです。

  • #cloud-aws
  • #cloud-azure
  • #cloud-gcp
  • #cloud-serverless
  • #docker
  • #cloud-k8s
  • #cloud-iac
  • プラットフォーム作る方へのお願い
続きを読む

Azure FunctionsでPlaywrightを使ったWebスクレイピング

この記事は、Serverless Advent Calendar 2020 1日目の記事です。

qiita.com

アドベントカレンダーの12月がはじまりましたが、みなさんどれくらい読んでますか?

私も情報収集に使っているモヒカンSlackでは、毎年 #advent-calendar-2020 などといったチャンネルがあり、気が向いた人がAdventarQiita Advent CalendarのカレンダーRSSフィードのURLを登録し、流れてくる記事を毎年楽しんでいます。

あ、モヒカンSlackというのは共有RSSリーダーのように使える公開Slackワークスペースで、Vulsでおなじみのサウナおじさんkotakanbeが運用しています。1万7千人くらいが登録していて、340のチャンネルでテーマ毎に様々なRSSフィードが流れてきます。無料プランということで1週間で10,000メッセージを使い切ってどんどん古い情報は見えなくなるので、古い情報は割り切りましょう!

qiita.com

さて、その昔はAdventarやQiitaのカレンダー一覧を見ながら、温かみのある手作業でRSSフィードを登録していたのですが、ちょうどこの記事が流れてきたので、Azure Functionsの上でPlaywrightを使ったバッチ処理を動かして、Webスクレイピングで全部のアドベントカレンダーを取ってきてSlackに登録するようにしました。

anthonychu.ca

ソースコードはここで公開しています。

github.com

Webスクレイピングには、URLから取得したHTMLをパースして欲しい情報を抽出するものと、ブラウザをHeadless(画面無し)で起動してAjaxなどを動かした結果からDOMなどを経由して抽出するものがあります。今回は、AdventarがgRPC APIを使っていて面倒くさい、SlackがレガシーAPIでないとスラッシュコマンドを投げられないなどいくつかの理由があり、Headlessブラウザを使うことにしました。

この手のHeadlessブラウザの操作ライブラリでは、Chromiumの開発者が作っているPuppeteerが定番かなと思いますが、FirefoxやWebKit(Safari)にも利用できるPlaywrightを今回は使ってみました。

つくりかた

この手のWebスクレイピングは、とにかくローカルで試行錯誤しながら組み立てていくことが多いかと思います。今回は、最初にベタなスクリプトとして動く部分を作り上げてから、それをAzure Functionsの関数アプリに変換するという手順を踏みました。開発環境としてはWSL2上のUbuntuにVSCodeで接続しています。VcXsrvを併用すると画面を使うアプリも動かせるので、一時的にHeadlessを解除して実際のブラウザ画面を見ながら試すこともできます。

動くスクリプトができてしまえば、host.json、functions.json、index.jsの三つを用意することで関数アプリとしてそのままデプロイできるようになります。対応するコミットがこれです。

github.com

いったんHTTP APIとして動作確認し、それからタイマートリガーに設定変更しました。これはfunction.jsonの変更だけでいけます。

github.com

これで10分に1回、スクレイピングして自動でSlackにRSSフィードのURLを足りない分だけ登録してくれます。

はまったところ

これだけ書くとさらっと動く感じですが、詰まるところが無いわけでは無いです。

1. Headlessを解除したときにダイアログが出ると操作ができない

動作確認のためにHeadlessを解除できる(lib/AdventCalendarCrawler.jsのL128あたりのheadless: false)のですが、Slackはブラウザで開くとデスクトップアプリを開くよう誘導され、Chromeのモーダルダイアログが開いてしまいます。この状態だとダイアログを閉じるまでウェブページ内の操作ができないため、後続の処理が失敗してしまいます。

dialogイベントをハンドリングしても上手くいかなかったので、とりあえず動作確認中はダイアログが出たらすぐに閉じるという運用でカバーしました。

2. Playwright内のchromeインストール場所

上の記事をよく読めばきちんと書いてあるのですが、Playwrightはnpm install中にChromeのバイナリをインストールしてくれます。してくれるのですが、普通に入れるとnode_modulesの下ではない場所にインストールしてしまうので、環境変数PLAYWRIGHT_BROWSERS_PATH0に設定する必要があります。

また、デプロイ時も、VSCodeからデプロイするなら.vscode/settings.jsonを、コマンドラインなら--build remoteを付けることでリモートでビルドが走り、その中でChromeのインストールが走ります。そのためデプロイに3分間ほどかかりますが待ってください。

3. Azure Functionsで動かしたらタイムアウトする

ローカルでは普通に動いていたんですが、じゃあいざAzure Functionsの関数として動かしてみたら見事にタイムアウトしました。まあ、こういうこともあるということで。

ちなみにAzure Functionsの従量課金プランでは一つの関数呼び出しの最大実行時間は10分間なので、それを超えると強制終了されます。試した範囲では5分ぐらいで終わっていたので、今回の範囲ではまあなんとかなるかなと。もしこれを超えるようであれば、処理を分解してDurable FunctionsでFan-outしたりする必要がありそうです。

4. Slackがクロールしてくれない

これは今回作ったものの問題ではないのですが、Slackに一度に大量の/feed subscribeを投げたせいか、今朝実際にフィードを登録したのですがアドベントカレンダーの初日の記事がまだSlackのチャンネルに流れてきていません。

設定では登録されているので大丈夫だとは思うのですが、最終的な確認ができていないのでまだ不安です……。

追記:日付変わったら来始めました。おそらくRSSフィードの時刻が0時になっていたために最初のエントリの検知に失敗していたように見えます。

まとめ

というわけで、Webスクレイピングができるとちょっとした自動化がささっとできるようになるので、手札として持っておくと便利です。またこういう雑なバッチ処理を適当に動かすのにFaaSは極めて強力なので、合わせ技で使っていくと良いかなと思います。

 

セキュリティ・キャンプ全国大会2020 応募期間延長!

セキュリティ・キャンプは、ITつよつよ人材の発掘と育成を目的とした取り組みです。毎年夏に行っている全国大会を、今年はオンライン形式で実施します。

www.ipa.go.jp

応募期間が当初は25日までだったのですが、大人の事情でちょっとだけ伸びて

2020-09-03 23:59 JST

になりました!

単に例年の講義をオンラインでやるというだけでは無く、10月から12月にかけて毎週ペースで講義が進むため、講義ごとの事前学習に時間が掛けられたり、特に集中コースのハッカソンは全体の開発期間が大幅に伸びたりなど、今回オンライン開催だからこそできることがたくさんあります。

また、今年度参加した人でも、来年度以降の「セキュリティ・キャンプ全国大会」にも応募可能です。

今からでも遅くないので是非応募をお待ちしています!

今年度のトラック構成おさらい

今年の全国大会オンラインは、以下のトラック構成です。

  • A【コンテストとワークショップトラック】 (選択コース)
  • B【プロダクトセキュリティトラック】 (選択コース)
  • C【脅威解析トラック】 (選択コース)
  • D【課題駆動トラック】  (選択コース)
  • L【暗号ファジングトラック】 (集中コース)
  • X【IoTセキュリティトラック】 (集中コース)
  • Y【システムソフトウェア自作トラック】 (集中コース)
  • Z【プラットフォームセキュリティトラック】 (集中コース)

www.ipa.go.jp

担当講義:クラウド時代における分散Webシステムの構成とスケーリング

それと、今年もクラウドを上手く使う講義を担当します。

よろしくです!

www.ipa.go.jp

 

 

IoTデータ処理の考え方

世の中いろいろな「IoT」がありますが、突き詰めればデバイスから上がってくるデータを処理して何かを実現するのがIoTです。IoTにおけるデータ処理を考える上で、ネットワークプロトコルの設計指針を参考にするとうまく整理できます。

シンタックス、セマンティクス、そしてコンテキスト

ネットワークプロトコルを設計するときにはシンタックス(Syntax; 文法)とセマンティクス(Semantics; 意味)に分けて考えます。そしてネットワークプロトコルの外側にあるコンテキスト(Context; 文脈)に基づいて処理が行われます。

それぞれ掘り下げていきます。

シンタックス:どのようにデータをやりとりするか

どのようにデータを送り、受け取るかという「文法」を決めるのがシンタックスです。

たとえばHTTPであれば、HTTPクライアントがHTTPサーバにTCPで接続し、以下のフォーマットでリクエストを送り、

[HTTPメソッド](空白)[URI](空白)[プロトコルバージョン]
(いくつかのヘッダ)
(空行)
(もしあればメッセージ本体)

HTTPサーバから以下のようなレスポンスが返ってくる、というのがシンタックスに相当します。

[プロトコルバージョン](空白)[ステータスコード](空白)[テキスト]
[いくつかのヘッダ]
(空行)
(もしあればペイロード本体)

ステータスコードは3桁の整数であるまでは決めますが、どの数字がどんな意味を持つか、例えば404が「URIが存在しない」を表すなどはシンタックスでは決めません。

これをIoTの分野で考えてみます。

Case 1: MQTT

MQTTでセンサーのデータを集める場合を考えてみます。

性能やコストをそこまで詰める必要が無い場合、後々の拡張性などを考えてメッセージに直接値を埋め込むのでは無く、JSONなどの汎用フォーマットに入れて送ることが多いかと思います。また、デバイスのIDをトピック名に入れて識別できるようにします。

そうすると、このようなシンタックスが考えられます。

  • トピック名は「sensors/{デバイスのID}」
  • ペイロードはJSON形式で符号化

シンタックスの段階ではどのようなセンサーがありどんな値を含めるかなどは決めず、セマンティクスに任せます。

f:id:nekoruri:20200811034013p:plain

JSONオブジェクトに含まれるキーや値の型までをシンタックスとみなす場合もありますが、この記事ではもう少し緩いところまでをシンタックスとみなしています。あくまでシンタックスかセマンティクスかは分類方法でしかないので、視線の先をどこに置くかでその境目は変わってきます。

Case 2: LoRaWAN

LPWAで代表的なLoRaWANでは、一番小さな設定ではメッセージサイズが11バイトになります。11バイトに集めたいデータを全て詰め込む必要があるため、1ビットは血の一滴と無駄にすることができません。

たとえばGPSトラッカーからデータを集めたい時に、以下のようなシンタックスが考えられます(この例はソラコムさんの記事をもとにしました)。

  • 先頭1バイトはヘッダ
  •  ヘッダの上位2bitはステータス(0~3)
  •  ヘッダの下位6bitはバッテリー(0~100を1bit右シフトして符号化)
  • 次の4バイトは緯度
  • 次の4バイトは経度
  • 次の2バイトは高度
  • 緯度経度海抜は浮動小数点数とし、ビッグエンディアンで符号化

f:id:nekoruri:20200811034827p:plain

MQTTの例と同様に、ステータスの意味はセマンティクスの範疇となります。

 

このように、データの形を決めるのがシンタックスです。たとえばSORACOM Beamバイナリパーサーはシンタックスの変換と考えることができます。

セマンティクス:データをどのように扱うか

受け取れるデータの形を決めるのがシンタックスなら、受け取ったデータの意味を決めるのがセマンティクスです。

先ほどのHTTPならば、受け取った3桁の数値が「404」ならば指定したURIにデータが存在しない、「301」ならばレスポンスのヘッダ「Location」で示されたURIに移動してしまった、というようなことを決めます。また、どのようなリクエストメソッドがあるのかもセマンティクスに相当します。

先ほどのIoTの例でセマンティクスを考えてみます。

Case 1: MQTT

実際のセンサーデータはJSON形式で符号化することがシンタックスで決まっていますが、その中身はセマンティクスに委ねられました。

今回使うセンサーでは、温度と湿度が取得できるので、temperatureとhumidityのキーでそれぞれのセンサーで取得した値を入れる事にします。温度は摂氏、湿度は100分率で表現します。このように数字の意味を細かく決めていきます。

Case 2: LoRaWAN

ステータスは、以下のような値を出すこととします。

  • 0: GPS位置情報の取得ができなかった
    (後に続く緯度経度高度のデータは正しくない)
  • 1: GPS位置情報の取得に成功した
  • 2: 未定義
  • 3: 故障している

バッテリーはフル充電時の最大電圧と、停止直前の最小電圧の間を100分率で表します。

緯度経度高度は、GPSで使われるWGS 84測地系で表現された値を利用します。緯度経度はともかく、高度はWGS 84測地系では地球をきれいな楕円体とみなしたときの表面からの高さになるので、実際の標高である平均海水面との差を計算したりするなどは、データを受け取った側の責任になります。

このように決めていくことで、ようやくセンサーで集めた情報が、正確にその意味をくみ取って利用できるようになります。それぞれの「値」に対してそれをどのような意味を持っているのかを細かく決めていくのがセマンティクスの役割です。

コンテキスト:文脈の上でデータの価値を見いだす

ここまでで、IoTデバイスから上がってきたデータをしっかり解釈することができましたが、それを具体的に役に立つようにするにはもう一手間必要です。それがコンテキスト(文脈)による価値付けです。

コンテキストも、細かく分けると2種類があります。

データの履歴と状態遷移

例えば温度センサーで30度という値を受け取ったとします。温度に応じて冷房のon/offを制御したいとき、たとえば部屋の温度が29度から30度に上がったときには冷房の電源を入れ、27度まで下がったときに冷房を止めて欲しいわけです。また、センサーからの値には誤差が含まれるため、移動平均なども計算したいです。

f:id:nekoruri:20200811035626p:plain

これを実現するには最新の温度データだけがあっても駄目で、過去のデータや冷房の状態があったうえで新しいデータを使って判断する必要があります。

このようにデータの履歴や状態をつかった処理を行うため、データを収集した側で様々な道具を使う必要があります。たとえばAWS IoT Eventsなんかはそのためのエンジンですし、Azure FunctionsやAWS LambdaなどのFaaSを使って自分で実装することもできます。

qiita.com

www.slideshare.net

外部のデータ

GPSで測位した位置情報が分かったとして、その座標を使って何かを行うためには、たとえば登校前後に親御さんにメールする「みまもりサービス」であれば自宅と学校の座標など、そもそも他のデータと組み合わせる必要があります。

先ほどの冷房on/offであれば、そのセンサーの所有者が設定した目標温度も必要になります。

いわゆるETLの範疇にもなりますが、リアルタイムデータを別のマスタデータとJOINするようなケースでは、Azure Stream AnalyticsやAmazon Kinesis Data AnalyticsなどでリファレンスデータとJOINしたりできます。

docs.microsoft.com

docs.aws.amazon.com

データ量によってはリアルタイムで処理することにこだわらず、RDBMS等に放り込んで閲覧時やバッチでJOINしても良いでしょう。

このように、IoTデバイスからのデータは、ただそこに存在するだけでは価値が発揮できず、過去のデータ・状態や外部のデータと紐付けることでようやく様々な役に立つことができます。逆に言えば、この領域で何をやるかこそが「IoTを活用する」ということそのものと言えます。

まとめ

IoTにおけるデータ処理は全体をふわっと見ると複雑ですが、データの表現方法を決めるシンタックス、その意味を細かく決めるセマンティクス、そこから価値を見いだすコンテキストに分けて整理すると分かりやすいです。