もう「サーバーレスだけどサーバあるじゃん」という話をしたくない

3年ぐらい同じ事を言い続けてるんだけど、そもそもサーバーレスという言葉の由来はソフトウェアアーキテクチャの話*1

一つのタスクの実行期間を超えて、ファイルシステムやメモリ上の変数などサーバ固有のリソースに依存しないという、12 Factor Appから死ぬほど言われ続けている制約を満たすプログラミングモデルがサーバーレスの本質です。この制約に視点を置くとサーバーレスとしか言いようがない。

これを真面目にやろうとすると、キューやPub/Subによる非同期タスク(イベント駆動)が必要になってきます。これを整理したのがリアクティブシステム、わかりやすく関数という枠にはめたのがAWS LambdaをはじめとするFaaSです。

 

その一方で、これを満たしたソフトウェアは、AWSなりAzureなりGCPなりクラウド基盤側が勝手にサーバを増やしたり減らしたりできて、完全従量制にできたりメリットがたくさんでてきます。そういうゼロからスケールできるフルマネージドサービスの性質もサーバーレスと呼んでいます。

メリットが分かりやすいためクラウドベンダーが主張したいのはこちらの性質なんですが、でもこれって「所有せず利用する」というクラウドコンピューティング全体の流れの延長線上でしかないんですよね*2

 

この設計と運用の二つの性質が混ざったのが現在の「サーバーレス」です。

というわけで、サーバーレスという単語に関しては、

 × サーバが無い
 ○ プログラマがサーバを気にしない
 ◎ プログラマがサーバを(設計上)気にしてはいけない+(運用上)気にしない

と捉えるのが良いと思います。単純に「サーバが無い」というだけの解釈をしやすいのは事実なので、こういう理解をした方が楽しいよ、という話です。

日本語圏だとサーバと言えばサーバマシン(ハードウェア)を指すことがほとんどですが、英語Wikipedia見ると、サーバマシンよりも先にクライアント・サーバにおける提供側の"a computer program or a device"が先に来ますし、サーバの仮想化はVirtual ServerではなくVirtual Machineなんですよね。この英語と日本語でのニュアンスの違いが大きいのかなという気はします。

 

という話をまとめて書いてあるのでみんな買ってください😇

nekoruri.booth.pm

追記

(2019-05-11 10:00)

あまり記事の意図が伝わってない感じなので、脚注に書いていたことを本文に組み入れました。

こんな読まれると思っていなかったのでポイントをあまり気にせず書いていたのですが、伝えたいのは以下の2点です。

  • サーバーレス(Serverless)という単語にも理由があるし、サーバマシン、サーバプロセスへの依存排除というこの抽象化の世界は面白いので、そう単語自体を否定しないで欲しい。
  • 「こういう背景もあるのか」ということで一定の納得をしてもらい、この名前の話はとっととやめて、サーバーレス技術を使っていかに楽に楽しくシステムを作るかの話をしたい。

 

*1:「Developers working in a distributed world are hard pressed to translate the things they’re doing into sets of servers.」とあるとおり、そもそも分散システムでものを作ってる人達はサーバとかいう考え方じゃないよね、という背景

*2:まあ実は一つめの話も、関数型プログラミングで言われるような、副作用排除、宣言型などのプログラミングの抽象化の流れの延長線上ではあります。

CROSS Study #2 で登壇してきた #cross_study

技術書典でふらふらしていたら、当日のじゃない方の非公式アフターで喋ることになりました。

cross-party.connpass.com

 

パネルセッション前半の「技術書典6 非公式振り返り」で、ssmjp同人部からほかに2人もいるので、どちらかというと個人サークル「めもおきば」の人よりの立場で好き放題話させていただきました。

まあ詳しい内容は実況勢がたくさん居たのでTogetterを見ていただくとして。

togetter.com

話したこととその補足です。

書き手として

もともと「普段考えていることを整理してアウトプットする機会」と位置付けていることもあり、技術書典の一般の「売れ筋」であるような解説書とかとはちょっと違う路線で、クラウドやセキュリティをテーマに、全体像や技術トレンドから勝手に分析した考え方のような「読んだ人に新しい視点を提供できる本」というエモい路線を中心にひた走っています。

そこを評価していただいている方がいて本当にありがたいかぎりです。

引き続き、エモいポエムコラム本というジャンルを確立すべく頑張っていきます。
d.nekoruri.jp

ネタ出し

私の場合は、Workflowyにネタ帳の階層を作って放り込んでます。

workflowy.com

まあぶっちゃけツールは何でも良いですが、スマホロック解除して10秒ぐらいで入力できる状況で敷居を下げておくとよいです。24時間常時ブレスト状態。とにかくキーワードを放り込んでおいて、あとで考えます。

人によってはボイスメモとかもありかもですね。最近だとScrapboxが人気なのかな。

scrapbox.io

scrapbox.io

あと、Twitterとかに書いちゃって満足してしまったネタをあとからきちんとまとめたいときは、Twilogでキーワード検索してその日の自分の前後ツイートを読み返したりします。外部記憶と検索重要。

twilog.org

入稿について

頑張れば短い時間でも本は出ます。

とはいえ極道入稿は悪です。誰も幸せにしないので早めに頑張ろう。

湊川さんも言っていたとおり早割(今回のねこのしっぽ様だと最大20%割引)で出せばその分同じ予算で1.25倍刷れて完売リスクを減らせますし、告知などにも時間を割けます。

今回の締切ラッシュの中で、自分の中で1ページ1時間というペース配分がはっきり確立したのは良かったなと思っています。要するに100ページの本を書こうと思ったら100時間かかるので、毎日3時間掛けても一ヶ月かかるわけです。3日徹夜しても24ページにしかなりません。いいですねおれ。はやくフォルダとファイルとレポジトリを作るんだ。

読み側として

今回もたくさんフルスタックしました。ありがてえ。

とはいえ途中で力尽きてしまい、お昼ぐらいまでに回れたのは1/3ぐらいで、残りはかなり遅めの時間でしかも最後の方まで人が多かったため流す感じになってしまったので、あとで他の方の戦利品写真をみて入手し損ねた本がかなりあったのが残念なところです。

それでもかんたん後払いシステムの電子書籍サービスが始まったこともあり、電子書籍での頒布を続けているサークル様がたくさん増えたという印象を受けました。じつにありがてえ。

今回は使えるサークル全てかんたん後払いシステムで決済しました。入手した本のリストも取れるしDLCもあるしほぼ良いことづくめなのですが、その結果として人類は頒布価格を見なくなり書典破産の危機が迫っています。ありがてえ。

 

まあ、そんな感じで「めもおきば」「ssmjp同人部」ともども引き続きよろしくお願いします。

 

パスポートと公開鍵の議論ポイント

www.osstech.co.jp

 

この記事をきっかけに公開鍵暗号やPKIの在り方について議論が盛り上がってるので、ポイントになりそうな話をまとめてみます。

パスポートにおける公開鍵暗号のおさらい

上の記事を読んでください、という感じなのですが、ざっくりまとめると以下の仕組みです。

・ICカードにアクセスするためのBasic Access Control:いわゆるPINとかに相当します。「パスポート番号 + 生年月日 + パスポートの有効期限」とのことなので、要するにパスポートの顔写真のページを見た人ならば分かる情報です。

・データの電子署名を確認するPassive Authentication:Basic Access Controlを通ると、券面のデータ及び、そのハッシュ値:SOD(Security Obeject Document)、SODに対する電子署名が取得できます。この電子署名は、最終的に各国が運用する独自ルートCAである「CSCA:Country Signing CA」が最上位となっています。

・カードが複製されないことを保証するActive Authentication:パスポート上のICカードが一枚ずつ持つ鍵対(秘密鍵・公開鍵)を利用した電子署名によって、物理的な耐タンパー性とあわせてそのカードが複製されていないことを保証します。

今回は、このCSCAの公開鍵証明書の入手が問題となっています。

情報開示請求に対する外務省の回答

技術的に判断できる前半については、散々言われているとおり、公開鍵証明書の秘匿性そのものにパスポートの安全性を依存するようでは論外なので、この不開示理由ははっきり間違っていると断言できます。

後半は「共通認識」があるとのことなので、外務省の回答者がそう思うんならそうなんでしょう、外務省の回答者の中では。

外務省はCSCAの公開鍵証明書を公開すべきかどうか

それでは一つ戻って「外務省はCSCAの公開鍵証明書を公開すべきかどうか」というポイントに戻ると、技術的にはいくつかの議論ポイントがあるように思います。あえて擁護側の立場を取ってみます。

なお本筋である「情報公開制度への対応として公開するべきかどうか」の話はこの記事ではスコープ外とし、あくまで暗号学的観点からの思考実験です。

1. そもそも公開鍵証明書を公開する理由がない

公開鍵暗号アルゴリズムにおける公開鍵は、その利用相手にのみ公開鍵を届ければ良く、公開鍵という名前に反して「万人に公開される」必要はありません。これはPKIにおける公開鍵証明書に関しても同様で、ルートCAにより発行される下位の公開鍵証明書を検証する相手が入手できれば良いものです。

今回で言えば、外務省が手間を掛けて(後述)その公開鍵証明書を、想定された利用者(ここも後述)以外に公開する必要はありません。

2. 公開鍵証明書を安易に開示すると、公開鍵配送問題が発生する

公開鍵暗号を利用したPKIの信頼性は、その「トラストアンカー(信頼の起点)」となるルートCAの公開鍵証明書を、いかに安全に入手するかに依存しています。

安易にトラストアンカーを送ってしまうと、その途中で差し替えられてしまうなどの攻撃が考えられます。

CSCAの公開鍵証明書を入手しようと言うからにはそれを利用することが想定されるわけですが、情報開示請求という手続きの仕組みで、公開鍵証明書をセキュアに開示することが困難である、という判断はありえます。少なくとも「手間」は掛かるでしょう。

個人的には、国民からの請求に応じてトラストアンカーを開示するからには、それを正しく利用できるようにするために「請求した国民まで安全に届ける義務」が発生するのではないかと考えます。なので、もし情報公開制度により開示されるのであれば、そういった条件付けは必要かも知れません。

3. 公開鍵証明書を公開したほうが安全になるわけではない

暗号アルゴリズムの安全性は、そのアルゴリズムがたくさんの研究者の目に晒されることによって維持されていることはご存知の通りです。パスポートのICカードの場合は、利用しているRSAは既知のアルゴリズムであり、公開鍵そのものを公開したからといって「よりセキュアになる」わけではないです。

むしろ、今後新しいRSAへの攻撃手法が見つかった際に、公開鍵を知っていることで秘密鍵を入手しやすくなる可能性は否定できません。その場合に、脆弱になった古い鍵対を捨て(revoke)、対策されたアルゴリズムでCSCA鍵対を作り直して公開鍵を再配布する必要がありますが、利用している相手が限られている方が良い、とは言えます。

4. かといって公開鍵を秘匿した方が暗号学的に安全になるわけでもない

発端の記事にもある通り、CSCA公開鍵証明書そのものがもともと公開情報であるため、外務省が秘匿したからと言って、言うまでもなく暗号学的に安全になることはありません。

ここからは、一般論として別の可能性に触れておきます。

たとえば、鍵対(公開鍵と秘密鍵)を生成するときに、脆弱性のある実装を用いると公開鍵から秘密鍵を入手できます*1

ほかにも、RSAには脆弱な運用パターンがいくつもあります。 

とはいえ、さすがにそんな脆弱性のある実装でCSCAの鍵対を生成することはさすがに考えられない(うえに、さすがに他国から指摘されているだろう)と思われるので、この可能性は考えないことにしたいです。

いずれにせよ、現実的にCSCA公開鍵証明書は公開状態にあるため、直接は関係無い話です。おそらく暗号解読研究者の方々はとっくに入手できるルートから入手して攻撃を試みていることでしょう。 

マイナンバーカードとの違い

似たような話題として、同じブログの方によって話題となったマイナンバーカード上の公的個人認証に関する仕様公開がありました。

www.osstech.co.jp

マイナンバーカード(の公的個人認証)とパスポートの最大の違いは、そもそもが利活用を目的として設計されているはずの公的個人認証の公開鍵証明書に対して、パスポートは相手国や航空会社での利用のみが想定されているという部分です。

そもそもカジュアルにパスポートのICカード上の情報が認証として一般的に利用されるようになると、そこにはパスポート上の記載事項が載っています。顔写真のデジタルデータが取得できるほか、指紋や虹彩情報などの生体情報を記録することも今後考えられます。

www.mofa.go.jp

日本が導入したIC旅券に記録される生体情報は、ICAO(国際民間航空機関)が策定したIC旅券の国際標準において必須と規定されている顔画像・国籍・氏名・生年月日・旅券番号など旅券面の記載事項が記録されます。しかし、指紋は記録されません。なお、いくつかの国では、指紋を記録しており、また、虹彩情報を記録するための研究が進められています。

そういった前提がある以上、入出国や航空機搭乗のような場面でなく広く利活用されるべきものではないように思います。

《追記:2019-04-25 10:23》

……と思っていた時期もありましたが、以下の意見を見て考えを変えました。

この現状を鑑みると、暗号学的な多少のリスクよりも、民間がパスポートの暗号学的検証をできないことによる社会的なリスクの方が大きいように思います。

もともとGitHub SSH公開鍵などの過去を踏まえた上で、公開鍵だから必ずしも万人に公開することが良いわけでは無いというモチベーションからの記事でしたが、少なくともパスポートに関しては、政府としてCSCA公開鍵証明書を公開し活用を促進するべきでしょう。

個人の生体情報を含みうるデジタルデータが幅広く利活用されてしまうのには抵抗があるのですが、次世代のIC旅券とかでうまい落としどころがあると良いなと思います。とはいえ現状では犯罪対策の方が優先でしょうね。

《追記:2019-04-26 06:00》

公開鍵証明書を単に公開鍵と書いていたところを、公開鍵証明書と公開鍵にきちんと分けました。これにあわせ、PKIと公開鍵暗号の話を整理しました。

自分としては、公開鍵アルゴリズムとの関係が分かりやすいよう、ルートCAの自己署名証明書を公開鍵と簡略化したつもりだったのですが、かえって混乱を招いてしまったようです。申し訳ありません。

また最上位CAとルートCAなど表現がブレていた部分も直しました。

結論

まとめると、あくまで技術的には「公開鍵は一般に公開されても公開されなくても良い」というように思います。その上で、パスポートのCSCA公開鍵証明書に関しては公開が望ましい、というのが結論です。

このように、いくつかの議論ポイントがある以上、公開鍵暗号だから「公開」されるべきだろう、という直感的な発想で思考停止してしまうのはちょっともったいないな、と感じたので思考実験気味にまとめてみました。

 

まあでもそれはそれとして、外務省の中の人そこまで考えてないと思います。

ちなみに、パスポートの規格を決めるICAO(国際民間航空機関)は以下のようにおっしゃっています。

https://www.icao.int/security/mrtd/Lists/FAQ/FAQ.aspx

Can CSCA Certificates be published on a state’s website, or would this be a breach of ICAO standards?
(公開して良い?ICAO違反にならない?)


Certificates are public information and as such can be published on a website. This is not a breach of ICAO standards. 
(証明書は公開情報だから好きにして。違反じゃないよ)

 

 

暗号技術入門 第3版

暗号技術入門 第3版

 

 

*1:詳しくはこちら。何度見てもひどい……。

新刊オンライン頒布のお知らせ

技術書典6おつかれさまでした。

今回の新刊を含めて、Gumroadでのオンライン頒布を始めました。

めもおきば TechReport 2019.04 (¥500)

■ いまどきのコンピューティングについて考えよう

サーバーレスや、Kubernetesを中心とするクラウドネイティブの動きが盛んですが、そういった中で、開発のしやすさ、スケーラビリティ、セキュリティ、様々な観点で「きれいで実用的な設計」について、流行りのキーワードを入口に掘り下げてみた、というのが今回のテーマです。自分のアプリケーションを設計するときに、少しでも取り入れられるエッセンスがあればな、と思います。

以下のようなキーワードを取り上げました。

コンピューティング/Function as a Service/関数型プログラミングと副作用とスケーラビリティ/分散処理による並列と複製/イベント駆動とCQRSとGraphQL/認証と認可とマイクロサービス/エッジとクラウドとオンプレミス/No-Codeとエンドユーザコンピューティング

■ ストリーミング処理エンジンためしてみた

上の記事にも書いたとおり、非同期のストリーミング処理の重要性が大いに増えています。そんな中、PubSub + FaaSだけではつらい場面が増えてきているため、いわゆるデータ解析の文脈からいくつも生まれているストリーミング処理エンジンがあります。

その中で、特に最近注目しているものについて、Getting Startedレベルですがさわってみたのでその紹介です。

Apache Spark Streaming/Kafka Streams/Apache Flink

■ ねこるり用語辞典

「めもおきば」の中の人の発言に出てくる用語を解説します。Jargon file 的なやつ。一度やってみたかったんですよね、こういうの。

アウトプットしないのは知的な便秘/世の中のことはだいたいガチャで説明ができる/もったいない・ほんともったいない・超もったいない/○○したら負け/制約/抽象化戦争

Serverlessを支える技術 第3版 (¥1,000)

サーバーレス本第3版です。

第2版の2018年8月からの8ヶ月で、Azure Functions 2.0、AWS Lambdaの大幅バージョンアップなどがあったため、細かく現状にあわせて追加された機能の紹介も入れています。また、昨年あたりからのGraphQLの急速な普及に伴って、CQRSまわりやストリーミング処理の解説も増やしました。

さらに、2018年のKnativeの公開に始まり、技術書典6直前のGoogle Cloud Next 2019で発表されたGoogle Cloud Runを中心に、Kubernetes/Dockerの世界観とFaaSの世界観の関係について、個別に節を設けて解説しました。

ボリューム的には、本文が96ページから105ページになりました。

めもおきば TechReport 総集編 Vol.1 (¥1,000)

特に説明も不要かなあと思うのですが、昨年までの総集編です。

・TechReport 2015.12(コミックマーケット89)
  Hardening 10 ValueChain 体験記
  クラウド四方山話「サーバーレスアーキテクチャ」
  2015 年振り返りと2016 年予想
・TechReport 2016.12(コミックマーケット91)
  2016 年振り返りと2017 年予想
・TechReport 2017.08(コミックマーケット92)
  SORACOM 買収からわかるIoT の未来
  私もセキュリティ・キャンプに参加したい!
  Bluetooth mesh ってどうよ
・TechReport 2017.12(コミックマーケット93)
  Hardening 2017 Fes レポート
  2017 年振り返りと2018 年予想
・TechReport 2018.04(技術書典4)
  なろう!フルスタックエンジニア
  htc vive 買ってみた
  Microsoft MVP Global Summit 行ってきた
・TechReport 2018.10(技術書典5)
  サーバーレスで実現するストリーム処理徹底活用術

めもおきば TechReport 2018.12 (¥200)

毎年冬コミでは、その年の振り返りと来年はやりそうな技術についてキーワードを紹介しています。2018年末は、以下のキーワードを取り上げました。

「2018 年予想」の振り返り/GraphQL によるAPI 設計手法の変化/非同期通信/ストリーム処理/ワイヤレスIoT/VR エコシステム/技術系同人誌/カラオケの原盤権/新しいプログラミング言語の普及

 

 

技術書典6に参加します

4月14日(日)の技術書典6に、サークル「めもおきば」として参加します。 

techbookfest.org

 

techbookfest.org

また、ssmjp同人部として合同誌にも参加しています。

techbookfest.org

 

今回の「めもおきば」としては、以下の4冊を頒布予定です。

新刊:めもおきばTechReport 2019.04

ねこるり節炸裂の超絶エモエモ回です。

判型:B5/ページ数:28/頒布価格:500円
GumroadにてPDF版頒布予定

f:id:nekoruri:20190412004943j:plain

・いまどきのコンピューティングについて考えよう

クラウドネイティブだとかサーバーレスだとかよく分からないバズワードが跋扈する昨今ですが、いまどきのコンピューティングについて、いろいろなキーワードを元にあらためて考えてみようという記事です。

Function as a Service/関数型プログラミングと副作用とスケーラビリティ/分散処理による並列と複製/イベント駆動とCQRSとGraphQL/認証と認可とマイクロサービス/エッジとクラウドとオンプレミス/No-Codeとエンドユーザコンピューティング

・ストリーミング処理エンジン試してみた

ここしばらくPubSubとFaaSでストリーミング処理をやっているのですが、だんだんつらくなってきたので、きちんとしたストリーミング処理のためのエンジンをさらっと一通り触ってみました。
Apache Spark Streaming/Kafka Streams/Apache Flink

・ねこるり用語辞典

「めもおきば」の中の人の発言に出てくる用語を解説します。Jargon file的なやつです。

アウトプットしないのは知的な便秘/世の中のことはだいたいガチャで説明ができる/もったいない・ほんともったいない・超もったいない/○○したら負け/制約/抽象化戦争

新刊:Serverlessを支える技術 第3版

ぶっちゃけまだ改稿中なのですが、サーバーレス本の第3版を出す予定です。

第2版までを入手済みの方も多いと思われるので、電子書籍限定です。

既刊(2018冬コミ):めもおきばTechReport 総集編 Vol.1

過去のTechReportのうちサーバーレス関連本を除く6冊をまるっと収めた「めもおきばTechReport 総集編 Vol.1」を新刊として頒布します。電子書籍DLカードが付きます(DLカードのみの頒布もOK)。

判型:B5/ページ数:116/頒布価格:1000円
GumroadにてPDF版頒布予定

f:id:nekoruri:20181227023014p:plain

以下の記事を収録しています。

  • TechReport 2015.12 (コミックマーケット89)
    • Hardening 10 ValueChain 体験記
    • クラウド四方山話「サーバーレスアーキテクチャ」
    • 2015年振り返りと2016年予想
  • TechReport 2016.12 (コミックマーケット91)
    • 2016年振り返りと2017年予想
  • TechReport 2017.08 (コミックマーケット92)
    • SORACOM買収からわかるIoTの未来
    • 私もセキュリティ・キャンプに参加したい!
    • Bluetooth meshってどうよ
  • TechReport 2017.12 (コミックマーケット93)
    • Hardening 2017 Fesレポート
    • 2017年振り返りと2018年予想
  • TechReport 2018.04 (技術書典4)
    • なろう!フルスタックエンジニア
    • htc vive買ってみた
    • Microsoft MVP Global Summit行ってきた
  • TechReport 2018.10 (技術書典5)
    • サーバーレスで実現するストリーム処理徹底活用術

既刊(2018年冬コミ):めもおきばTechReport 2018.12

判型:B5/ページ数:8/頒布価格:200円

年末恒例の「2018年振り返りと2019年予想」です。

f:id:nekoruri:20190412011314p:plain

GraphQLによるAPI設計手法の変化/非同期通信/ストリーム処理/ワイヤレスIoT/VRエコシステム/技術系同人誌/カラオケの原盤権/新しいプログラミング言語の普及

コミックマーケット95(冬コミ)に参加します

コミックマーケット95の2日目(12/30)に「めもおきば」として参加します。

www.comiket.co.jp

東6ホール「ト45a」です。

  * めもおきば | Comike Web Catalog

 

新刊:めもおきばTechReport 総集編 Vol.1

過去のTechReportのうちサーバーレス関連本を除く6冊をまるっと収めた「めもおきばTechReport 総集編 Vol.1」を新刊として頒布します。電子書籍DLカードが付きます(DLカードのみの頒布もOK)。

判型:B5/ページ数:116/頒布価格:1000円

f:id:nekoruri:20181227023014p:plain

以下の記事を収録しています。

  • TechReport 2015.12 (コミックマーケット89)
    • Hardening 10 ValueChain 体験記
    • クラウド四方山話「サーバーレスアーキテクチャ」
    • 2015年振り返りと2016年予想
  • TechReport 2016.12 (コミックマーケット91)
    • 2016年振り返りと2017年予想
  • TechReport 2017.08 (コミックマーケット92)
    • SORACOM買収からわかるIoTの未来
    • 私もセキュリティ・キャンプに参加したい!
    • Bluetooth meshってどうよ
  • TechReport 2017.12 (コミックマーケット93)
    • Hardening 2017 Fesレポート
    • 2017年振り返りと2018年予想
  • TechReport 2018.04 (技術書典4)
    • なろう!フルスタックエンジニア
    • htc vive買ってみた
    • Microsoft MVP Global Summit行ってきた
  • TechReport 2018.10 (技術書典5)
    • サーバーレスで実現するストリーム処理徹底活用術

 

新刊:めもおきばTechReport 2018.12

いつものコラム本です。多分前日夜まで書いてます。

 「2018年振り返りと2019年予想」と、時間があれば何か書きます。

 

既刊:Serverlessを支える技術 第2版

たぶんこれが最終頒布になる予定です(お察しください) 。

判型:B5/ページ数:100/頒布価格:1000円

f:id:nekoruri:20180808165012p:plain

 

 

例のボタンをツマミにSORACOMの世界観をただの利用者が勝手に解説してみた

はじめに

この記事は「SORACOM LTE-M Button powered by AWS Advent Calendar 2018」の6日目です。

ところで、「例のボタン」こと「SORACOM LTE-M Button powered by AWS」、皆さんもう手に入れていますよね?

 

f:id:nekoruri:20181207035544p:plain

先日のSORACOM Technology Camp 2018ではこのSORACOM Buttonのバックエンドシステム構成の話がありました。

見て欲しいのはこのページです。 

 

SORACOM Technology Camp 2018 ベーシックトラック4 | SORACOM LTE-M Button の始め方 from SORACOM,INC

SORACOM Buttonは携帯電話ネットワークの「SIM」を活用することで、IoTデバイスにありがちな様々な面倒ごとを解決しています。

単なるIoT/M2M機器向けに従量制価格プランを作り込んだだけの安価なMVNOキャリアと勘違いされがちなSORACOMですが、このSORACOM Buttonのしくみに代表されるように、その真価は「通信とクラウドを融合したIoT通信プラットフォーム」であることです。これから、これがどういうことか解き明かしていこうと思います。

 

というわけで、この記事はコミックマーケット92にて頒布した同人誌「めもおきば TechReport 2017.08」第1特集の再編集版です。

追記した部分は「※追記:」としています。

d.nekoruri.jp

 

SORACOMとは

端的に言えば、SORACOMは株式会社ソラコムが提供するIoT通信プラットフォームです。 

正直「IoTなんちゃらプラットフォーム」という単語自体にバズワード感がありますが、一般的にはIoT*1 デバイスが通信をするために必要なものを揃えたパッケージという感じで使われているようです。

SORACOMのように通信にフォーカスしたものだけでなく、(ネットワーク接続を前提に)IoTデバイスから集まってきたデータを分析・可視化するサービスや、デバイスからデータをクラウドに投げるときのライブラリ群、あるいはそれらを包括的に提供するものといくつかのパターンがあるようです。

 

 SORACOMはざっくり三つの役割を提供しています。

※追記:図は2017年8月当時のものです。

  

f:id:nekoruri:20181207012321p:plain

 

SORACOMはこれらを下から上まで「垂直統合」で提供し相互に価値を高め合うことで、利用者に対して高度なサービスを提供しているわけです。

 

回線接続サービス

IoTデバイスがネットワークに接続するための回線を提供する、プラットフォームとしては一番低い部分です。サービス名称としては「SORACOM Air」が対応し、SORACOMの最初のサービスでもあります。

 当初はNTTドコモのMVNOとして日本国内向けにサービスを開始しましたが、その後海外でも利用可能なグローバル向けAir SIMが提供されたほか、920MHz帯のLPWA(Low Power Wide Area Network((間欠的に通信を行うことで、低電力(設定によっては乾電池で数ヶ月以上)で広域(数km)の通信を実現しようとする無線通信のカテゴリ )であるLoRaWANSigfoxにも対応しました。

※追記:その後、KDDI回線を利用できるSORACOM Air SIM(plan-K)と、今回のSORACOM Buttonも利用しているLTE-M(plan-KM1)が提供されました。

 

また、株式会社ソラコムとしてのサービスではありませんが、ソラコムが開発したSORACOMのエンジンである「SORACOM vConnec Core」をKDDIが採用した「KDDI IoTコネクト Air」があります。MVNOと同等の接続サービスとしては同じように提供されていますが、この後に紹介する上位層の機能は残念ながらSORACOM本家から若干遅れての提供になっているようですが。KDDIグループへの参加により、サービス内容の共通化も進んでいくと考えられます。なお、技術的詳細は明かされていないので、KDDIとしてのサービスについて、これ以降は触れません。

※追記:上記のとおりSORACOM本体よりplan-Kが提供したことにより、こちらのKDDI IoTコネクト Airの新規申し込みは終了になった模様です。その結果、全てのサービスがドコモ回線と同じスピードで提供されるようになっています!

 

SORACOM AirはNTTドコモとL2卸契約するMVNOですが、NTTドコモからの専用線から先のMVNOキャリアとして必要なシステム全てをAWS上で構築しています。データトラフィックの転送や通信網の管理を、クラウドネイティブな設計でソフトウェアによって実装しています。これにより、利用数の増加を見込んだ設備投資を避けつつ、高い頻度での開発サイクルを回しています。その副産物として、1日10円+最低0.2円/1MB(たとえば月間1GBであれば約500円)という低トラフィックでは極めて安価な従量課金を実現しています。

ただ、安いことはSORACOMの価値の中ではぶっちゃけ些細なことではないでしょうか。単に安いインターネット接続回線だけが欲しいのであれば、月額300~500円や、一定転送量まで0円というMVNOキャリアも登場している昨今です。

 

SORACOM Airの価値の半分は、その管理機能をAPIとして提供していることにあります。APIからSIMごとの設定(回線速度や回線自体の有効・無効など)を変更でき、通信量などを監視してAWS Lambdaを呼び出すイベントハンドラー機能もあります。これを利用することで、SORACOMの上に仮想MVNO事業者を構築したり、SIMを組み込んだ形で製品を出荷してから契約状況に合わせて通信を有効化・無効化したりといったことが可能になるわけです。

残りの半分は、SORACOM Airという回線契約があることで、安全にデバイスを識別でき、それによって上位層の機能を提供できるということです。セルラー(いわゆる3G/4Gなど携帯電話回線ベースの技術)であればSIMが、Sigfoxであればデバイス内蔵のセキュアエレメントが耐タンパー性(壊しても中身の暗号鍵などを見られない性質)を持ち、デバイス識別のための秘密情報が安全に保存されています。またLoRaWANの場合にも、出荷時にSORACOM側と同期されてデバイスに設定されるAppKeyを使ってセッション鍵を作成するため、耐タンパー性とまではいきませんがそれなりに保護されています。

 

接続回線という一番下の層において個別のデバイスを一つのID基盤上で識別できているからこそ、異なる通信網を性質の違いのみを意識するだけで、その上に多種多様なサービスを統一的に提供できます。

概念的な表現をすると、閉域網の中でデバイス別にIPアドレスが割り振られる旧来のネットワークセキュリティのモデルに対して、回線の接続点で直接認証されるIDベースのセキュリティという新しいモデルがあり、それに基づいてSORACOMのあらゆるサービスが実現されています。

要するに、「Air」に続く「B」以降のサービスのために、SORACOM Airとしては様々な通信方式に対応する必要があり、今後来る5Gベースの携帯通信網や、グローバルの世界制覇のためにKDDIと手を組んだのだと思います。

 

ソフトウェアベースの高機能な仮想ネットワーク

先ほど書いたとおり、SORACOMのネットワークは全てクラウド上のソフトウェアで構築されています。つまり一種のSoftware-defined Network(SDN)やNetwork Function Virtualization(NFV)です。通信回線の反対側にそのままSDN/NFVの世界を接続したことで、閉域網として様々な機能を提供しています。

閉域網という視点では、接続先に応じて3種類のサービスを提供しています。AWS上の自分のVPCに接続する最も安価な「SORACOM Canal」、物理専用線としてAWS Direct Connectを利用する「SORACOM Direct」、インターネットVPNを利用する「SORACOM Door」です。

これらを利用する場合は、Virtual Private Gateway(VPG)という仮想ルータを構築して、SORACOM Airの回線ごとにVPGに接続します。

自分独自のVPGを利用することで、デバイスに割り振られるIPアドレスレンジ(デフォルトでは10.128.0.0/9)を変更したり、デバイス毎に固定のIPアドレスを指定したりといったことも可能です(次に紹介するSORACOM Gateを使わない限り、そのIPアドレスが直接見えることはありません)。ただし、これらは閉域網と言ってもVPGでNAPTされるため、あくまでデバイス側からクラウド側への方向の接続のみを提供しています。

 

クラウド側からデバイス側への接続、あるいはデバイス同士の接続を実現するのが「SORACOM Gate」です。SORACOM Gateを有効にするとデバイス毎のIPアドレスを利用して相互に通信が可能となります。さらに、SORACOM Canal等で接続されたネットワーク上にGate Peerと呼ばれるルータ(実際にはVXLANが設定されたLinuxホスト等)を構築することで、そこからデバイスまで一つの仮想L2ネットワークが提供され、自分のネットワークからデバイスに直接接続できるようになります。Gate PeerまでL2で伸びてきてくれるため、そこから自分のVPC内のネットワークにさらにL2ブリッジしても良いですし、もっとシンプルにNAPTするのも手軽です。

 

さて、このあたりまでは気合いの入った閉域網サービスであれば実現できるところですが、SDNであることを最大限に活かすSORACOMらしいサービス「SORACOM Junction」がつい先日(※2017年7月)リリースされました。これはVPGを通過するパケットに対して、ミラーリング、リダイレクション、インスペクションの3つの操作を提供します。

ミラーリングとリダイレクションは、名前の通りパケットを複製したり転送先を変更したりすることで、ユーザ企業が独自の監視システムを通したりトラフィックの制御を行ったりと言うことが可能となります。インスペクションは、パケットの統計情報を外部のクラウドサービス((送信先にできるクラウドサービスはこの後紹介するSORACOM Funnelと同じようです。内部的には同じ枠組みに載っていると思われます。に送信します。

 

これらSORACOMの高機能な仮想ネットワークは、全てクラウドネイティブな設計で実現されているため、SORACOMの利用者やその転送速度・秒間パケット数などが増えても(万が一AWSのリソースが頭打ちしない限り)いくらでもスケールすることができます。

その一方で、たとえばSORACOM CanalのVPGは1時間あたり50円(30日間で36,000円)と、きちんと利用者にそれなりの負担が求められます((月36,000円で用意できるAWSのインフラ環境は何だろう……と考えていくと、VPGの仕組みが妄想できそうな気がしてきます。。このあたりはうまく技術上の制約をビジネスとして成立させていると感じます。

 

モバイル通信網の課金体系は、行き過ぎたインセンティブなどにより極めて歪になってしまっていますが、SORACOMの素直な課金体系を見るとほっとします。

 

クラウド連携

SORACOMの真価はクラウドとの統合にあります。

IoTでビジネスをするために必要なのは、単にIoTデバイスをIPネットワークに接続することだけではなく、そのIPネットワークを介してクラウドの向こう側に大量のデータを期待する品質で届けることです。通信とクラウドの融合を謳っているように、SORACOMにはIoTデバイスをクラウドと連携するための仕組みが数多く用意されています。

SORACOMのクラウド連携機能は、大きく二つに区別できます。

 

一つは、AWSやAzure、GCP、あるいは独自に構築したサーバなどの、「クラウド側」との橋渡しをする機能です。

サービスとしては「SORACOM Beam」と「SORACOM Funnel」があります。単純にデータを左から右へと転送するだけで無く、クラウドに送る際の認証や暗号化処理、データ量の限られたLPWAを利用する時のデータ形式変換など、「IoTデバイスがクラウドと通信する際のあるある処理」をSORACOMが肩代わりしてくれます。

※追記:AWS IoTなどへのデバイス登録(プロビジョニング)を行う「SORACOM Krypton」が加わりました。

 

もう一つはSORACOM自身がクラウドとして直接的な機能を提供するもので、「SORACOM Endorse」「SORACOM Harvest」「SORACOM Inventory」が対応します。SORACOM Harvestのように単体で完結するものもあれば、SORACOM Endorseのように別の枠組みと連携するための機能もあります。

※追記:SORACOM Harvestに蓄積されたデータを可視化する「SORACOM Lagoon」が加わりました。

このあと、これらを個別に掘り下げていきます。

 

SORACOMの世界観

SORACOMのクラウド連携について具体的な機能を紹介する前に、まずSORACOMがIoTプラットフォームとして提供しようとしている世界観について触れておきます。

IoTにおける代表的な脆弱性をOWASPがまとめているので、以下に引用します。

Top IoT Vulnerabilities - OWASP

  • I1 Insecure Web Interface
    安全でない(製品の)Webインターフェース
  • I2 Insufficient Authentication/Authorization
    不十分な認証/認可
  • I3 Insecure Network Services
    安全でないネットワークサービス
  • I4 Lack of Transport Encryption/Integrity Verification
    転送路における暗号化・完全性確認の欠如
  • I5 Privacy Concerns
    プライバシーに帯する懸念
  • I6 Insecure Cloud Interface
    安全でないクラウド上のWebインターフェース
  • I7 Insecure Mobile Interface
    安全でないモバイルアプリのインターフェース
  • I8 Insufficient Security Configurability
    不十分なセキュリティ設定
  • I9 Insecure Software/Firmware
    安全でないソフトウェア・ファームウェア(の更新)
  • I10 Poor Physical Security物理セキュリティが弱い

 IoTデバイスが関連するのはI1、I2、I3、I4、I8、I9、I10あたりですが、IoT固有の物理セキュリティ(I10)を除いて、一般的なウェブアプリ等であれば当然のようにどれも考慮されているべきはずのものばかりです。これらがなぜIoTデバイスで特に問題にされるかと言えば、IoT固有の理由でそれらを設計時に「妥協」してしまうからです。

 

IoTデバイスが一般的なサーバ側システムと異なるのは大きく2点あります。

一つは計算機としての性能です。最近になってようやくARMベースなどの比較的高性能なデバイスも増えてきましたが、消費電力であったりサイズであったり、あるいは予算や部材の都合で依然として性能の低いIoTデバイスとはまだ何年も付き合っていく必要があります。ところがデバイス自身を正しく認証する、あるいはデバイスに接続するユーザを認証するには、公開鍵暗号やハッシュ関数などの計算が必要となり、決して低くない演算能力が必要となります。さらに大量のデータをクラウドに送信するようなデバイスでは継続的な暗号化も必要となります。

旧来のネットワーク制御デバイスでは、ネットワークレベルのセキュリティなどを前提として「妥協」をしてきました。その結果として、USBメモリなど様々な手法を組み合わせたStuxnetなどの被害が発生しています。これからは、何らかの手段で、低い処理性能しか持たないIoTデバイスからクラウドまでの通信を暗号学的に守っていく必要があることは確定的に明らかです。

 

もう一つが、IoTデバイスの数が多いということです。

様々なデバイスをネットワークに接続して安全に機能させるには、それぞれのデバイスを個別にセキュアに識別する必要があります。そのためには、電子証明書あるいは事前共有鍵どちらでも良いですが、デバイス毎に何らかの秘密の認証情報を持たせる必要があります。

ところが、数百数千が前提となるようなIoTデバイスでは製造時に個別の情報を持たせ、それをそのまま運用時にも利用するということが難しくなってきます。したがって運用開始時に認証情報を投入する必要が出てくるわけですが、物理的な作業をどう減らすかが重要であり設計の難しさが一気に上がります。また故障時の交換なども踏まえると、開始時だけではなくシステムの運用ライフサイクル全体の中でデバイスの識別方法を設計する必要があります。

 

SORACOMはこの課題に対して「まず接続回線を安全に識別し、その上でSORACOM側に処理を委譲する」という解決策を提示しています。

SORACOM Airの回線は、3G/4G網やLoRaWAN/Sigfoxのそれぞれの暗号学的手段によって安全に認証・暗号化されています。そこで、IoTデバイスは純粋にやりとりしたいデータだけをSORACOMに送り、SORACOMが認証や暗号化など本来IoTデバイス上で行うはずだった処理を肩代わりします。 

また、IoTデバイスは必ずネットワークに接続する必要があり、設置時にSIMを挿したり、LoRaWANやSigfoxのデバイスIDを登録したりします。これまでは別の手段で証明書を配布するなど認証のためだけの作業が必要でしたが、通信路に紐付いてクラウド連携を行うことでそういった作業をゼロにします。

 これこそが、SORACOMの世界観において核となる考え方です(偉そうに書いていますが、一ユーザから見た勝手な決めつけです😇)。

 

プラットフォームというものを提供するということは、そのプラットフォームの世界観──すなわち、IoT/M2Mデバイスにおける通信とはどういうものなのか、運用も含めたシステム全体をどういう抽象化に基づいてIoTデバイスやクラウドを設計するのか、という共通認識──のシェアを取り合う「抽象化戦争」に参加することです。

このSORACOMの世界観は、IoTプラットフォームにおける抽象化戦争においてかなり強い魅力を持っているように思います。

 

SORACOMの様々なサービス

さて、そろそろ個別のサービスを紹介していきます。

SORACOM Beam

SORACOM Beamは、端的に言えば高機能なアプリケーションプロキシサーバです。

SORACOM内のエントリポイントにIoTデバイスから送りやすいプロトコルで送信すると、上手い具合にプロトコルを変換したりしてクラウド側に送信してくれます。SORACOMが提供するクラウド連携機能のなかでもっともシンプルなものですが、SORACOMが提供しようとする世界観に触れる入口として一番相応しいものです。

また、全てのSORACOM Air回線はグループ単位で管理されますが、SORACOM Beamはこのグループに対して設定されます。したがってグループのBeam設定を変更するだけで、そこに紐付いた全てのIoTデバイスからの送信先が一括で管理できます。当然ながら、Beamに限らずこのような設定をSORACOM APIで変更することも可能であり、デバイスを含むシステムのオンライン開通などを構築することもできるでしょう。

利用するプロトコルで分類すると、6種類の動作に分けられます。

HTTP ⇒ HTTP/HTTPS

IoTデバイスからHTTPでエントリポイントにリクエストを送信すると、そのリクエスト内容をクラウド側のURLに対してHTTPもしくはHTTPSでリクエストを転送します。

 クラウド側がインターネットの向こう側にある場合など、HTTPSによる通信の暗号化処理をSORACOM側にオフロードできます。IoTデバイスからSORACOMまでは各通信手段による暗号化や、NTTドコモからSORACOMまでの専用線で守られているため、SORACOMまではHTTPで良いわけです。

 クラウド側にリクエストを送信するときに、接続元IoTデバイスのIMSI(International Mobile Subscriber Identity:SIMごとに割り当てられるID)・IMEI(International Mobile Equipment Identity:3G/4Gの携帯電話機・モデムごとに割り当てられるID)や、事前共有鍵に基づいた電子署名、個別に指定したカスタムヘッダをHTTPリクエストヘッダに追加することができます。これによって、クラウド側は「誰からの通信なのか」を識別することができます。これはこの後の他のHTTP転送先でも共通です。

 細かく分けると、ドメイン上の全てのパスをそのまま利用する「Webエントリポイント」と、パスごとに個別の転送先を設定できる「HTTPエントリポイント」の2種類が用意されています。

TCP ⇒ HTTP/HTTPS

TCPでエントリポイントに接続して生のデータ列を投げると、HTTP POSTリクエストに変換してクラウドに送信します。

 データ列は、以下のようにBase64エンコードでJSONに埋め込まれて本文として送られます。

{"payload":"Base64エンコードされたメッセージ"}

クラウドからのレスポンスもそれっぽく返ります。

400 Message from server

UDP ⇒ HTTP/HTTPS

TCPと同様に、受信したデータをHTTP/HTTPSに変換して送信します。

TCP ⇒ TCP/TCPS

TCPで送られた内容を、そのままTCPでクラウドに送信します。IMSIやIMEI等を送りたい場合は、HTTPリクエストヘッダの代わりに、先頭行として送信されます。

MQTT ⇒ MQTT/MQTTS

クラウド側のMQTTブローカーと相互にPublish/Subscribeを転送します。

LoRaWAN ⇒ HTTP/HTTPS

LoRaWANデバイスから送信されたUplinkデータを、HTTP/HTTPSでクラウドに送信します。

先ほどのTCPからの変換と似たような動作をしますが、Base64ではなくHex表記が使われるほか、経由したLoRaWANゲートウェイの情報や受信電波強度(RSSI)などの追加情報を含むJSONとして送信されます。

LoRaWANなどのLPWAでは転送できるデータ量が極めて少ない(デフォルト設定(Spreading Factor=10)では、4.4秒に1回ずつ、1回に11バイト送信できます。)ため、JSONのような富豪的なデータを来ることはできず、まさに「1ビットは血の一滴」と送らなければならないデータをビット単位で詰め込んで送ることになります。

それをどこかでクラウド側で扱いやすい形に変換しなくてはなりませんが、バイナリパーサー機能を利用することで、バイナリデータを指定した通りに分解してJSON上に展開することができます。どこかで必要になる処理なので、LPWAの利用者には非常に便利と思います。バイナリパーサーはこの後紹介するSORACOM FunnelやSORACOM Harvestにも対応しています。

SORACOM Funnel

私が一番好きなサービスがこのSORACOM Funnelです。

 SORACOM Beamが単純なアプリケーションプロキシという形態だったのとは対称的に、SORACOM Funnelは様々なクラウド固有のインターフェースに直接データを投げ込むことができる「クラウドリソースアダプター」です。

 

様々なパブリッククラウドはデータ収集用のサービスを提供していますが、IoTデバイスからそこに送信しようとすると、IoTデバイス上でクラウド接続用のSDKを組み込んだり、そこに食わせる認証情報の管理が必要となったりします。

SORACOMの世界観の通りそれらの面倒な処理全てを肩代わりしてくれるのがSORACOM Funnelです。IoTデバイスは、送りたいデータをそのままSORACOM FunnelのエントリポイントにHTTPもしくはTCP/UDPで送るだけです。直接IoTデバイス上のアプリケーションから送信しても良いし、例えばFluentdが使える環境であればout-httpプラグインが直接使えたりします。

 

例えば、SORACOM Airで接続したIoTデバイス上からこんな感じでHTTP POSTで投げます。

$ curl -X POST http://funnel.soracom.io \
    -H Content-Type:application/json \
    -d '{"foo":"bar"}'

そしてこれをSORACOM Funnelの設定でAWSのKinesis Data Streamsに送るように設定しておくと、Kinesis Data Streamsには以下のようなレコードが送信されます。 

{
  "operatorId": "OP9999999999",
  "timestamp": 1473322750825,
  "destination" : {
    "resourceUrl": "https://kinesis.us-west-2.amazonaws.com/teststream",
    "service": "kinesis",
    "provider":"aws"
  },
  "payloads": {
    "foo": "bar"
  },
  "imsi": "440000000000000"
}

payloadsの中に送信したJSONが埋め込まれているほか、SORACOMが受信したタイムスタンプ(Unixtimeミリ秒)や、送信に使われたSORACOM AirのIMSIなどが含まれて届きます。クラウド側ではこれらのデータを元に送信元を識別して様々な処理を行います。ね、簡単でしょ? 

 

送信先のサービスも、AWSであればAWS IoT、Kinesis Data Streams、Kinesis Data Firehoseと一通り、それ以外のパブリッククラウドもAzure Event HubsやGoogle Cloud Pub/Subなどイベントストリーミング系に流し込むことができます。

他にも、SORACOMの認定済みパートナー各社のサービスに接続することができるPartner Hosted Adapterが用意されています。現在はデータ分析や可視化エンジンなど国内9社のサービスに対応しています。SORACOM接続のIoTデバイスから容易に送り込めるかは各サービスで支配的な要素になることが予想できるため、今後もどんどん対応サービスが増えて行くことでしょう。

 

IoTデバイス「あるある」として、技術上の理由やビジネス上の要件によって利用するハードウェアやOS、ディストリビューションに制約がかかることが多々あります。そのような環境の上で、SDKを直接動かす手間を省き極めて軽く標準的なプロトコルだけでクラウドとの連携ができることは、その開発速度の改善に貢献します。

数多くのPoC(実証実験)をこなさなくてはならないIoTビジネスにおいて、開発速度はビジネス上の支配的な要員となります。決してSDKを利用してクラウドに直接通信することが技術的に難しいわけでは無いですが、「そこは自分達のビジネスでは無い」わけで、単純に計算機資源をオフロードするという意味だけではなく、自らの実装量そのものを減らせることがSORACOM Funnelの魅力です。

 

さらにセキュリティ上の理由としても、IoTデバイスの盗難などを考慮する場合はIoTデバイス毎にアクセスキーなどの認証情報を個別に用意するか、一時的なリスクならば受容できる場合は盗難が発覚したときに即座に認証情報を一括で交換するなどの対策が必要となります。

SORACOM Funnelではクラウド側に対する認証情報をSORACOM側で持つので、そもそもIoTデバイス上に何かを管理する必要がありません。こういった「考えることを減らす」という方向性のものが私は大好きです。

 

地味な副産物として、クラウド側の問題でデータ投入に失敗した場合なども、SORACOM上のマネジメントコンソールで直近2週間のログが見られるので、IoTデバイスを触らずにトラブルシュートできるのも嬉しいところです。

そもそもIoTデバイスなんてファイルシステムがread-onlyで書けるのはtmpfsだけとか、書き込める容量が数MBとかしかないとかザラで基本的に必要なログは外部に転送する必要があったりするわけで、とにかく自分でやることを減らすのがIoT開発の肝です。

 

ここまでの2つは、IoTデバイスとクラウドを連携させるための橋渡しのサービスでした。残りの3つは、SORACOM自身がクラウド的なサービスを提供するものです。

SORACOM Endorse

SORACOMのサービスの中でも、地味ながら面白いものの一つがSORACOM Endorseです。

繰り返し述べてきたように、SORACOM Airの3G/4Gで接続されたデバイスは3G/4GのSIMにより暗号学的に正しく認証されています。ですが、大量のデータ転送や通信の安定性を必要とする場合など、3G/4G回線経由で送受信したくないというケースがあります。そんなときSORACOM Endorseを使うことで、モバイル通信を経由して認証トークンを発行してもらうことができます。 

認証トークンは標準的なJWT(Json Web Token)フォーマットで、SORACOM Airで接続に使われているIMSIやIMEIなどのほか、任意の情報を追加することができます。またSORACOMの秘密鍵で署名されているため、そのため認証トークンを別のシステムに持っていてもSORACOMの公開鍵で検証することができます。 

これを使うと、単体で用意すると高価になりがちな耐タンパー性のあるセキュアエレメントによるデバイス認証を、モバイルデータ通信を経由するかどうかによらず様々な状況で利用することができます。COSR設定も可能なので、ブラウザ等からの直接利用もできそうです。 

自分のところではFunnel/Beamで済んでしまって試せていないのですが、システムの実現可能性を広げることができるポテンシャルを感じています。

※追記:このSORAOM Endorseの仕組みを上手く活用できる、SORACOM Kryptonが搭乗しています。

SORACOM Inventory

大量生産をするIoTデバイスにおける設定情報の管理や、稼働中のはずのIoTデバイスの状況を把握するためには、これまではBeamなどのクラウド連携機能を使って自前で設定レポジトリやテレメトリ収集システムなどを作る必要がありました。そういった部分をSORACOMが提供してくれるのがSORACOM Inventoryです。技術的には標準規格LwM2M(OMA LightweightM2M)のサーバです。

LwM2Mは恥ずかしながら作者もSORACOM Inventoryの登場まで知らなかったのですが要するに非同期に接続されるIoTデバイス等に向けて設計されたSNMPのようなものと捉えれば良いようです。具体的には、設定値の参照・変更や、非同期に通知されるデバイス側ステータスの変更監視、コマンドの送信などが行えるようです。

正直あまり詳しくないので深くは触れません。

SORACOM Harvest

最後に紹介するSORACOM Harvestは、SORACOMが提供するサービスの中でもっとも高い層にあるもので、IoTデバイスがSORACOM Funnelなどと同じようにデータを投げると、SORACOM上にデータを蓄積し、可視化できます。簡単なPoCであればもはや外部のパブリッククラウドを必要とせず、むしろSORACOM自身がパブリッククラウドとしての役割を果たしていると言えます。

投げ方とかはSORACOM Funnelと似ているので、内部的にはPartner Hosted Adapterと同じようにSORACOM Harvest Adapterのようなもので送り込んでいるような気がします。

ちょっとした可視化とAPIだけを提供するような「IoTプラットフォーム」が量産されている昨今ですし、なによりIoTデバイス側の開発に重きを置いてクラウド側はデータが見られれば良いようなプロジェクトであればSORACOM Harvestはまさにどハマリだと思います。是非使っていきましょう。ここでも、重要なことは「自分のビジネスと関係無いところは、できるかぎり自分でやらない」ということに尽きます。

 

SORACOM自身がデータを蓄積し始めたという事は、そのデータを対象とした様々な分析サービスなどを実現できる下地が揃ったと言えます。まだまだアルファベットにはZまでたくさん残っているので、例えばリアルタイムな機械学習で異常検知できるSORACOM Machine Learningだとかそんな感じの手厚い系のサービスも出てくるのかもしれません。

 

追記:このSORACOM Harvestで蓄積したデータを可視化して他の人に見せることができるSORACOM Lagoonがリリースされています。SORACOM LagoonはオープンソースBIツールのGrafanaをベースにしたもので、グラフや地図などを用いたダッシュボードを作ったり、条件を指定してSlackなどのWebhookにアラートを投げ込んだりすることができます。SORACOMの管理コンソールのログイン権限とは別に、共有URLを発行してお客さんに直接見てもらうことなども可能です。

 

SORACOMで気軽に遊んでみよう

散々述べてきたとおり、SORACOMの魅力はMVNOの回線に紐付いて提供される高レベルのクラウド連携機能です。従って、パブリッククラウドがそうであるように、実際に触ってみないとその面白さ、便利さを実感しづらいものです。

SORACOMのハンズオンもかなり広く実施されていますが、自分で勝手に遊んでみるのであれば、回線速度も不必要なので3Gで良いですし、古めのdocomo向け中古USBモデムが2000円程度で転がっていたりします。USBモデムではWindows/Macのドライバインストール用に仮想CDドライブが仕込まれている場合がほとんどなので、あらかじめユーザ(人柱)による検証報告があるものを探すと良いです。

 

また、最近LPWAのサービス圏内も拡がっているので、それを試して見るのも良いかも知れません。例えばLoRaWAN GPSトラッカーが15,800円で購入できるので、それでそのまま試すことができます。リリースされたばかりですが、Sigfox対応センサ対応デバイスも8,478円とそこそこお手軽に手が出せそうな価格帯です。

このような完結したIoTデバイスを買ってきて、SORACOM Harvestでまず可視化してみたりSORACOM Funnelでクラウドに送ってサーバーレス構成で分析してみたりすると、SORACOMが何を狙っているのか実感できると思います。

 

※追記:今ならまさにSORACOM LTE-M Buttonを使うことで、AWS IoT経由で簡単にAWS Lambdaなどを呼び出すことができます。詳しくは以下のアドベントカレンダーにたくさんの情報が出てくるはずです😇

qiita.com

 

今後のSORACOM予想

KDDIグループに参加したことで、特にSORACOMの方向性が変わるとは思いませんが、KDDI自身の世界戦略と絡んで、グローバルなサービス展開の手厚さは変わっていくでしょう。また、KDDIが買収したSORACOM以外とのシナジーというのはありそうに見えます。あとは、いつSORACOM Air for 5G/NB-IoTとかそういったものがリリースされるかだけですね。

※追記:NB-IoTではありませんでしたが、LTE-M(Cat.M1)に対応したのは皆様ご存知の通りです。

仮想ネットワークとしては、以前から要望を送っているVPG上のファイアウォールや、透過プロキシなどに使えるL4レベルのJunction、トラフィック・フローダンプ、そんな感じで既存のネットワーク機能が素直に移植されていくものと思います。

 

クラウド連携としては夢が尽きないところですが、AWSであることを活かして自分で用意したLambdaとの結合や、AWS IoTなどデバイスツイン系のサービスのSORACOM独自提供、スマートフォンのNFC/FeliCa連携によるユーザ認証、先ほど書いた収集データの分析基盤など、複数の利用者が必要としそうな機能を継続的に貪欲にSORACOM-izeしていくのではないかと思います。

Harvestのような単体で完結するサービスについても、管理者がコンソールから見るだけではなく、パートナーとの関係性もありますが、外部ID基盤と連携して一般ユーザ向けの画面を提供といったBIツールの領域に踏み出す可能性もあります。

※追記:既に書いたとおり、一般ユーザ向けの可視化画面を提供するSORACOM Lagoonがリリースされました。

 

今後もSORACOMのニューリリースから目が離せなさそうです。

 

Re: 今後のSORACOM予想

ここまでは2017年の夏に書いた内容でした。

改めて2018年末として今後のSORACOMの流れを予想すると、来年2019年にはこのあたりが来るのではないでしょうか。

エコシステムの拡充

SORACOM Funnelの接続先など引き続きエコシステムの拡充は間違いなく進んでいくでしょう。

エッジコンピューティングとの連携

つい先日に、AWSのエッジコンピューティング基盤とのセキュアエレメント連携が発表されましたが、エッジとクラウドの通信など様々な形で連携が進んでいくと予想しています。

blog.soracom.jp

Global SIMの活用

Air GlobalのSIMは、SIM内のJavaアプレット実行をはじめとした国内キャリア(ドコモ/KDDI)のSIMにはできない様々な機能があります。

日本国内においてもそれらを活用した事例が増えるのは間違いが無いですし、それを前提としたさらなるSORACOMサービスがKryptonに続いて登場していくのではないでしょうか。たとえばSIMでは認証だけを行い、他の通信路を利用してSORACOMとの間にVPNを張りVPGに接続できるようなサービスなども考えられます。

高トラフィック通信への対応

今のところ「IoT向け」として比較的低トラフィックな利用が想定されていますが、エッジだけで完結できない用途のビデオストリーミングの転送や、従業員に支給する各種端末など、より高トラフィックな通信を念頭に置いたサービス群が登場すると予想しています。

今のところ、SORACOM FunnelにおいてAmazon Kinesis Video Streamsに流し込むFunnel KVSがLimited Previewとしてひっそりと姿を見せているほか、SORACOM Junctionもトラフィック異常検知などの用途にも活用できます。

ガジェット強化

ちょうどLTE-M Buttnが出たところですが、そのままLTE-M Buttonを入力機器とした活用事例も出てくるでしょうし、LTE-M Buttonの接点入力Verであったり、Wio LTEなどをベースとした「ボイラープレート的なハードウェアとソフトウェアのテンプレートセット」が大きく拡充していきそうな気がしています。

おわりに

「お前これボタンじゃ無い方に書けよ」ってのはNGワードです。ボタンで始まってボタンで締めたので大丈夫です(ごめんなさい正直考えていた内容を落としました)。

というわけで、引き続きSORACOMアドベントカレンダーをお楽しみください。

明日はmobilebizさんの「Twilioを使ってIoTボタンで連続架電を行う」です。

 

qiita.com

qiita.com

 

*1:IoTの定義については、Internetの指す対象やCPS(Cyber-Physical System)との違いなど議論がありますが、ここでは「大量のデバイスをIPネットワークに接続して何かする」ぐらいの緩い定義とします。