SORACOM Blog

ソラコムの最新情報をお届けします

10/16 ソラコム Developers Conference#0 まとめ

こんにちは、広報のkyonです。 ソラコム初のディベロッパーイベント、リリース2週間後にも関わらず、様々な分野のエンジニアにお集まりいただき、熱い熱い夜となりました。

各界の第一線のエンジニアによるLTは怒涛の18本。個人的には、ダイヤルスイッチや、voIP、回転灯など、通信が目に見えてつながるLTが胸熱でした。IoT”モノのインターネット”って、「インターネット」を意識しなくなった時、何かを超える気がしてます。

LT資料に加え、USTREAMやtogetter、メディアによるレポートなどもまとめましたので見逃した方、復習したい方どうぞ!

ソラコム資料

当日は、「SORACOM AirにおけるカスタムDNS機能」「SORACOM BeamにおけるAWS IoT対応」の、2本の新機能を発表させていただきました。

CEO玉川、CTO安川の発表資料 モバイル通信サービス「SORACOM Air」に新機能「カスタム DNS」を追加 データ転送支援サービス「SORACOM Beam」に新機能「AWS IoT®連携」を追加

LT資料

NO 登壇者 所属 タイトルと資料リンク
1 片山 ソラコム SORACOM イベントハンドラー
2 榎並様 AWS 5分でわかるAWS IoT! - あなたも今日からIoT生活 -
3 松井様 ジャストインケース SORACOM x AWS IoT
4 竹之下様 アットマークテクノ SORACOM Airのその先に ~IoTのThingのイマとコレカラ~
5 松下様 ぷらっとホーム SIMの開封からSMS受信まで5分でやりきる! 【説明BLOG】SORACOM AirのSIM開封からSMS受信までを5分でこなすために
6 橋本様 skydisc SORACOM AirでIoTするなら3G Rayで簡単に
7 吉田様 アドベン SORACOM API活用!?ラズパイ+ダイヤルスイッチでSORACOM Airのプラン変更をやっちゃう!!
8 長田様 アレグロスマート どこでも光るよ 回転灯
9 小川様 Z-works IoTによるホームセキュリティとターミナルケア
10 mana_cat様   育児にも活用できる家庭内IoTのすすめ 【BLOG】育児にも活用できる家庭内IoTのすすめ~Raspberry Piでやってみよう!
11 mhidaka様 techbooster AndroidでもSORACOM Airを使いたい!
12 kekekekenta様 JAZUG SORACOMとAzureでIoT
13 tokida様 Bluemixユーザー会 SORACOM Beam と Bluemixで簡単IoT
14 荒木様 AWS センサネットとモバイルネットワークをくっつけるソラコムさんに作って欲しいサービス
15 椚座様 エイビット SORACOMでVoIPをやってみた
16 田中様 はてな Raspberry Pi + SORACOM で Mobile GPS logger
17 得上様 マイニングブラウニー SILK
18 大瀧様 classmethod ぼくのかんがえたさいきょうのSORACOM Beam検証環境
19 muo_jp様   C#からSORACOMを管理できるようにした話〜はやぶさにあこがれてOTA〜 【BLOG】SORACOM APIをC#から触れるようにした

当日の様子

togetter 10/16 ソラコムDevelopers Conference#0まとめ

メディアによるレポート

クラスメソッドBLOG ソラコム Developers Conference ♯0:「SORACOM」新機能発表!

THE BRIDGE 期間限定SIMも作れる!モバイル通信を解放したソラコム、開発者向けカンファレンス開催【フォトレポ付】

TECH.Ascii.jp クラウド、ネットワーク、デバイスのエンジニアがいよいよ邂逅するIoTの異才たちがLT18連発!SORACOMのフライデーナイト

今後のイベントについては、BLOGtwitterfacebookからフォロー下さい!

'ken&kenta'

'集合写真'

'Fullscale T'

SORACOM AirにカスタムDNSを追加、SORACOM BeamにAWS IoT連携を追加

10月16日に、SORACOM Developer Conference #0を開催させていただきましたが、そのカンファレンスにて、新機能を二つ発表させていただきました。プレスリリースはこちらです。

  • モバイル通信サービス「SORACOM Air」に新機能「カスタム DNS」を追加(リリース)
  • データ転送支援サービス「SORACOM Beam」に新機能「AWS IoT®連携」を追加(リリース)

カスタムDNS

新機能である「カスタム DNS」は、SORACOM Airへの追加機能であり、SORACOM AirのSIM の所属グループ毎に、お客様独自の DNS サーバを設定できます。例えば、 クエリログの取得によりデバイスの活動検知や不正利用検出を行ったり、動的に登録されるホストの名前解決にも利用できます。また、DNS フィルタリングなどでデバイスからのアクセスをコントロールしたり、DNS 設定の変更によって接続先を切り替えることができます。未認証のユーザーを認証用サイトに誘導するキャプティブポータルを実現することもできます。これらの設定変更も全て API を通して実施することができます。カスタムDNSは、SIM 1枚あたり3円/日でご利用頂けます。2015年10月はリリース記念で無料でご利用頂けますのでこの際に是非試してみてください!

カスタムDNSについての詳細はこちらを御覧ください。

AWS IoT連携

AWSから先日リリースされたIoT向けのクラウドサービスである「AWS IoT」を用いると、デバイス毎に「クライアント証明書」を発行でき、デバイスから AWS クラウドまでセキュリティを担保した形で、MQTTS や HTTPS のプロトコルにて「AWS IoT」にデータを保存することができます。

このクライアント証明書は、各デバイスが利用できるようデバイス上にコピーしておく必要がありますが、今回のSORACOM BeamのAWS IoT連携によりSORACOM Beam上で証明書を設定・変更することができ、管理と運用が容易になります。また、SORACOM Beamの「プロトコル変換」機能を利用することにより、デバイスからは MQTT や HTTP でデータ送信し、SORACOM側で MQTTS や HTTPS にプロトコルを変換することで、CPU パワーがあまりないデバイスであっても、デバイスに負荷をかけずに、AWS IoTを活用した、高度な IoT システムの構築が可能となります。AWS IoT連携を利用の際の料金は、通常のBeamの利用料金以外に特に必要ございません。

AWS IoT連携について、詳しくはこちらを御覧ください。

SORACOM Developer Conference #0での新機能発表資料

カンファレンスで用いた新機能発表資料はこちらです。

今後も、ソラコムは、お客様のご要望に従って、新しい機能を迅速に開発しリリースしていきますので、是非沢山の声をお寄せください!

玉川 憲 (Twitter: @KenTamagawa)

SORACOM AirとBeamと時々NAT越え

はじめに

ソラコムCTOの安川です。この書き出しでブログを書くのは実は今回が初めてで、ちょっと緊張しています。

9月30日に皆様にお披露目したIoT Platform SORACOMはたくさんの皆様に注目を頂き、これまで構想から開発、リリースまで力を注いできたチームの一人としてこれ以上ない喜びを感じています。核であるモバイル通信サービス、SORACOM Airの加入者数も、おかげさまで今月は純増数過去最高を記録しております(今月が初月なので当たり前 笑)。

思い起こせば、初めてAWSに触れたのはEricsson Research時代にIoT/M2M, Connected Home/Car/Thingの研究プロジェクトに携わっていた時でした。当時、たくさんのモノが繋がるシステムの絵を描きながら、その中心にあるクラウドの可能性に魅せられ、もっと深く追求したい、その力を使いこなせるようになって世の中に貢献したい、そんな思いでAWSソリューションアーキテクトとなった経緯です。玉川と出会ったのもその時で、運命的な出会いであったなと思います。

SORACOMの構想に至るもっと前段階で、小さなきっかけとなるアイデアが生まれたのは玉川とたまたま二人で飲んでいた時だったというエピソードは以前、大谷イビサさんのインタビュー記事に書いて頂きました。「ソフトウェアで実現できることはクラウドでより良く実現できる」という実感は何年かのAWSでの経験を経てどんどん強くなっていき、Ericsson時代に見ていたIoTのバックエンドやモバイルネットワークのコア機能だってクラウドで実現できるはずと自然に考えていました。そんな考えは口にせずにいたら、あるいは他の場面でつぶやくだけだったら本来消え行くだけの考えだっただろうと思いますが、その晩目の前に玉川憲がいてその話をしたこと、その後共同創業者の船渡を始め、かけがえのない仲間たちが一人、また一人と集うに連れ、小さな灯火が確かな光になっていきました。

「アイデアとか何かが出来るってこと自体は大事じゃない。大事なのは如何にうまく実行するかだ。」これはシアトルのDynamoDB開発チームにいた時の尊敬する元上司であり、大切な友人でもあるAWSのKhawaja Shamsが、彼の運転でUS101をドライブしながら相談した時に伝えてくれた言葉です。それを思い返しながら、最初のきっかけから今に至る経緯を考えてみると、このチームで実行したからこそ今回のリリースが実現出来たこと、誰か一人欠けても今のSORACOMには辿りつけなかったことを実感して目頭が熱くなりました。「フルスケールエンジニア」というキーワードの名付け親であり、SORACOMのAPIをはじめあらゆる要所の守護神であるOguの言葉を借りると、本当に愛おしいチームです。

また、いろんな予定を変更してソラコムの起業という選択をするにあたって、相談したら真っ先に応援して背中を押してくれた妻にも感謝してます。実は二子玉川オフィスの内装を担当したのはうちの妻だという隠れ話もあります。リレーブログの先陣を切ってくださったはてなの田中さんのブログで「コアの開発はすごく難しいわけではなかったと言ってた」という部分を読んで、「さんざんフィールド試験である場所を行ったり来たりしてたくせに(・∀・)」とツッコミを受けたりもしたので、この場で素直に感謝の気持ちを表します。いつもありがとう!

と、このまま思いを語り続けると、夜のテンションの高さもあり、いつまでも振り返りと感謝感激の言葉ばかりで終わらなくなってしまいそうな気がするので、技術ブログとして読んでくださっている皆様が去ってしまう前に次の話題に移りたいと思います。

デバイスからクラウドはわかった。でもその逆は?

おかげさまでSORACOM Airだけでなく、SORACOM Beamはたくさんのお客様にご好評頂いていて、デバイス側からクラウドあるいはインターネット上のサーバへのデータの転送を、デバイス側の負担を軽減しながらセキュアrにより柔軟に実現できるということを実感していただいているように感じています。M2M/IoTの研究プロジェクトをしながらデバイスのマネージメントをどうするかで悩んだ経験を思い返すと、その部分をプラットフォームに任せて、本来実現したかったユースケースに集中して頂ければ何よりと思う次第です。

一方、最近何度か続けて、お客様から次のような質問を頂くようにもなりました。

「デバイスからクラウドにBeamでセキュアにデータ転送できるのはわかったよ。でもクラウドからデバイスにメッセージを送りたい時とか、デバイスからデバイスにデータ送りたいときはどうするの?」

これはごもっともなご質問だと思います。

実はSORACOM Air及びBeamは9/30の発表前からプライベートβという形で一部のお客様やパートナー様に提供をさせて頂き、フィードバックを頂いていました。その時も、上記のようなご質問もなかったわけではないのですが、どちらかというとデバイス側でポートを開けて待ってしまうとその部分のセキュリティ対策が必要になってしまうという懸念から、信頼するサーバにデバイスからコネクションを張る形や、MQTTでSubscribeさせてサーバからメッセージをPublishする形式の方が好まれる傾向が強いようでしたので、直接アクセスをさせるような手段は用意しませんでした。むしろファームウェアの更新や、不定期なコマンドの実行といったユースケースであれば、デバイスを一定期間眠らせて、起きた時に取りに行くような非同期なシステムの構築の方が電力消費の観点でも望ましいというお客様の声もありました。

それを受けると、先日のre:Inventで発表されたAWS IoTは正にこういったユースケースにうってつけのサービスかなと思います。MQTTでデバイスからメッセージを送りながら、その内容に応じてアクションを実行したり、デバイスがオフラインの時にもクラウド側からのメッセージを一旦受け取って保留しておいてくれるThing Shadowという仕組みがあったり、至れり尽くせりなサービス内容の発表に私自身もしびれておりました。

先日のクラスメソッドさん主催のre:Invent振り返り勉強会「re:Growth」でもAWS IoTは注目の的で、ソラコムも登壇枠を頂いたのでSORACOM BeamからAWS IoTにメッセージを投げて、Amazon SNSで通知メッセージを飛ばすデモをしまして、好評を頂きました。

Beam+AWSIoT デモの構成(re:Inventに行けなかった私はIoT Buttonがもらえず、持って帰ってきた人のを借りて押そうにも技適認証通ってないので押せないということで仕方なく私物のXperiaに擬似IoT Buttonを作ってデモったのでした)

で、今日はその内容について書こうかな、とも思ったのですが、私の後のバトンの受け取り手がMr. AWS IoTとも言うべきAWSの榎並さんなのでここはあえてスルーパスをして、別の話題にしてみます。

クラウド経由のメッセージングはいいけど、そうはいってもクラウドからデバイスの間にソケット張りたいときはあるでしょ

前述のとおり、メッセージやコマンドのやり取りであれば、AWS IoTを始め、AWSの各種サービスを使ったり、どこかにメッセージの受け渡しを行うサーバを用意すれば済むかと思います。でも、やっぱりソケット張りたいときはありますよね?例えば: 1. メンテやデバッグなどの目的でリモートのデバイスのシェルにアクセスしたい 2. カメラやマイクなどからのストリームデータの受信のためには中継点を通さずに1対1接続で行いたい

先述の通り、セキュリティ上の懸念を意識して、SORACOM Airは少なくとも現状、任意のソースからデバイスに向けてコネクションを張りに行けないようになっているため、単純には行きません。しかし、予め上記のような用途が予想される場合にはデバイス側に仕込みをしておくことで解決できる可能性があります。

1つお手軽な手段としてはデバイス側から信頼できるサーバに対してTCPソケットを張って、ポートフォワーディングでデバイスの特定のポートにマッピングしておく方法があります。

例えば、デバイスからSSHでリモートサーバのポート8022をデバイス側のSSHサーバ22にマッピングする場合、

1
$ ssh -R <remote serverの待受けIPアドレス>:8022:localhost:22 <remote server>

などとしておけば、:8022か、同サーバ上でlocalhost:8022にSSHすればデバイス側のSSHサーバにログイン出来ます。

上記はお手軽ですが、SSHの暗号化が2回かかって無駄だということであれば、デバイスからリモートサーバへの接続はPureなTCPソケットにしておくという手もあります。例: - サーバ側は下記のコマンドででデバイスからの接続を待ち受け、別途8022への外からのアクセスを待ち受け

1
2
$ mkfifo /tmp/fifo
$ nc -l 8022 < /tmp/fifo | nc -l <remote port> > /tmp/fifo
  • デバイス側はサーバのにソケットを張り、データが来たらローカルの22番に転送
1
2
$ mkfifo /tmp/fifo
$ nc <remote server> <remote port> < /tmp/fifo | nc -l 22 > /tmp/fifo

上記のコマンドを実行すると、ポートフォワーディング用のTCPソケットが張られて、SSHの場合と同様、サーバ側の指定ポートへの通信(8022)がデバイスの22番ポートにマッピングされます。前述の例と違って、SSHの暗号化処理が2重に実施されることがないので少し無駄が減ります。

また、サーバ側のプログラムを少し作り込めるようであれば、SORACOM Beamを活用して、繋いでくるクライアントの認証することも出来ます(SORACOM BeamのオプションでSIMのIDのであるIMSIを付加できる。付加されたIMSIが改ざんされてないことを検証するためのデジタル署名も付与できるので、安心してクライアントを認証可)。また、SORACOM Beamからサーバまでの間の区間だけTCP over SSL/TLSで保護するなんてことも出来ます(下図に設定例)。

Beam Config Example

その場合には予めSORACOM Beamの設定を投入した上で、デバイス側のコマンドを:

1
$ nc beam.soracom.io 8023 < /tmp/fifo | nc -l 22 > /tmp/fifo

とすれば良いでしょう。

デバイスからデバイスへのPeer to Peer通信はどうするの?

これに関しては別段SORACOM Air特有のことはなく、一般的なNAT超えをしていただくのが良いのではないかと思います。

例えばVoIPやWebRTCなどのUDPを使ったリアルタイム通信の場合には、多くの場合STUNやTURNを使ったNAT越えが組み込まれているソフトウェアが使われるかと思いますので、STUN/TURNサーバを設定しておけば、SORACOM Airと別のNATの内側のデバイスとの通信、SORACOM Air同士の通信でも問題なく実現出来ますし、実際にそういった形でお使いのお客様もいらっしゃいます。

また、TCPの場合にはSTUNは使えないという話もよく聞きますが、実は対応したサーバと対応したクライアントであればSTUNを使ったTCPのNAT越えというのものも不可能ではありません。

実際、STUNTMAN というソフトウェアをインストールして、SORACOM Airで繋がったデバイス同士で試してみました。ここではデバイス1, 2として、それぞれで下記のようなコマンドを実行すると、実行結果としてローカルのIPアドレスとポートの組がどのグローバルIPアドレスとポートにマップされたかが帰ってきます。

1
2
3
4
$ stunclient --protocol tcp <TCPに対応したSTUNサーバ>
Binding test: success
Local address: 10.224.128.252:33933
Mapped address: 52.xx.yy.zz:33933

後はこの情報を何らかの方法で交換した上で、Sourceポートを先ほどSTUNでマッピングを調べた際に使ったローカルポート(上の実行結果を得たホストの例だと33933)に指定してソケットを張ります。

1
$ nc -p 33933 <PeerのIPアドレス> <Peerのポート>

こうすると、お互いNATの内側にいても、すなわちSORACOM Airで繋がったデバイスであってもTCPソケットを張ることが出来て、上記の例の用にポートフォワーディングを設定していれば、フォワード先のポートに対して通信が可能になります。

TCP-STUN

ポイントは、各PeerでSTUNを使ってポートマッピングを確認した上で、お互いのポートをそれぞれSource/Destに指定してTCPソケットを張りに行っている点です。これによって、間に存在するNATテーブルに対応するエントリが作られて、逆方向のパケットが通るようになります(UDPの場合と同様)。TCPではSourceポートに動的に割り当てられるEphemeral Portが用いられるのが一般的なので馴染みがない形に見えますが、要はUDPのNAT越えと同じようなことをしているというわけです。ncなど、Sourceポートが指定できるプログラムだとこういったことも可能ですね。

当然、実用する上ではポートと宛先のIPアドレスを交換するための何らかのシグナリングが必要になってしまいますが、その辺をどうにかすればPeer to Peer の通信も出来るということで、応用できる場面がありましたら思い出して頂ければと思います。

おわりに

今回は最近何度か同様のお問い合わせを頂いた経緯もあり、中継サーバとポートフォワーディングを活用したクラウドからデバイスへの通信、NAT越えによるデバイスからデバイスへの通信を行う例をご紹介しました。

本当はもう一つ、SORACOM Beamがまだ名前もついておらず、私の頭の中の妄想から具体的にどういうものかをデモするのに作った仮想のサービス/アプリがあって、それが正にここで話したようにTCPで繋がったデバイスをIMSIで認証して、外からは認証付きのWebソケットで繋げばデバイスと直接通信出来るというシステムだったので、前半の終わりでご紹介した内容に近いことから、ここで例として掲載しようかと思ったのですが、ちょっとすでに長くなっちゃったので、またの機会にするか、ご興味ある方に別途お見せ出来ればと思います。

なお、今回一般的にNAT超えやポートフォワーディングなどを活用したデバイスへのアクセスをご紹介しましたが、SORACOM Airで繋がったデバイスにやはり直接アクセスする手段は欲しいよという声がありましたら、それはそれで実現したいユースケース含めてご相談頂ければと思います。 お客様の声を反映して進化していくという点もIoT Platform SORACOMの特徴の1つですので、そういった声も是非お聞かせ下さい!

SORACOMサービスリリース講演 全文書き起こし (3)

2015年9月30日に行われた、ITpro EXPO 2015 特別講演をベースとしました書き起こしの第3回(最終回)です(スピーカー:株式会社ソラコム 代表取締役社長 玉川)。

第1回第2回はこちらからご覧いただけます。

本日は、「SORACOM Beam」についてお届けします。

SORACOM Beam - 新しいデータ転送支援サービス

SORACOM Airをお客様に使って頂くと、様々なフィードバックを頂き、IoTにおける他の課題に対する理解が深まりました。特に、セキュリティの課題です。

LTE/3G回線は、SIM自体は耐タンパー性が高く、基地局と認証をしっかり行ってから暗号化して送るので、デバイスからキャリアのデータセンターまでは一般的に安全といえるでしょう。

ただし、IoTシステムだと、インターネット越しに何らかのサーバーかクラウドにデータを入れます。ここで公のインターネットを通るので、ここは安全なのかという課題があります。ここをセキュアにするために、よくありがちなのは、端末からVPN接続する。もしくは、キャリアの交換機から後ろ側で法人向けの高価な閉域網接続をするかとなります。いずれにしろ、トータルのコストは高くなり、IoTシステム導入のハードルがあがります。

SORACOM Beam (Public Beta) の発表

このセキュリティの課題をSORACOMで解決するのがSORACOM Beam (ソラコムビーム)と呼ぶ新しいサービスです。

SIMが入ったデバイスからデータセンターまで安全なのは一緒、その後も専用線でSORACOMまできて、AWSのバーチャルプライベートクラウド(VPC)という閉域網に入るのでここまでは安全です。SORACOMが良いのは、ここにクラウドのリソースがわんさかあるということで、ここで暗号化する。なにもリソースに乏しいデバイスにやらせなくても、クラウド側でやれば良いということです。

例えば、ある小型のデバイスからHTTPSでwebサービスにアクセスしようとすると、1秒に1回データが送れないかもしれない。パワーが足りないんです。でもHTTPなら送れる。なので、HTTPでここまで送ってくれたら、クラウド側でHTTPSにしてあげる、MQTTで送ってくれたら、MQTTSにしてあげる、、クラウド側で、デバイス側の処理を肩代わりしてあげる、こういう考え方です。

さらにいうと、SIMにIDが付いているので、このデバイス認証というのも必要なくて、SIMが入っているということが認証代わりになります。なので我々がデータにidをつけて送信することで、サーバー側もどのデバイスから来たデータ化がわかるようになります。なりすましが出来なくなるということです。さらに、タイムスタンプのような何時何分に送られてきましたということも、データに付与できます。

データ転送先の動的な制御もできます。初期設定で、このデバイスからは、とりあえずSORACOMに送ってもらえば、SORACOM側で、こっちに送ったり、あっちに送ったり変更できます。すべてSORACOMで設定できます。Airと同様、Beamの設定もwebコンソール、APIでできるとなると、そうなるともうデバイスを触りにいかなくてもいいんですね。デバイス一回初期設定で送ってしまえば、あとは単純に送ってきたデータを、SORACOM側でデータの送信先を変更したり、プロトコルを変えたりといったことが簡単にできるようになります。

画面でイメージ掴んでいただくと、グループみたいなものを作って、そこにSIMを所属させると、Beamのエントリポイントというものが作ることができます。たとえば、HTTPの場合だと、この標準設定を全てのデバイスに設定しておけば、このエントリーポイントにむかってデバイスがデータをなげてきます。

後は、SORACOM Beamの上で、どのホストにデータを転送するか、デバイスに手を入れることなく設定することができるのです。BeamもAirと同様にWebやAPIでコントロールできます。

さらに、SORACOM のプラットフォーム自体はAWSの上で動いていますので、AWSのサービスをそのままBeamから呼ぶことができます。

AWSには便利なサービスがいっぱいあって、AWS API GatewayのようなAPIサービスや、Amazon S3のようなストレージや、Amazon DynamoDBといったデータベースや、AWS Lambdaなどイベントドリブンでスクリプト入れておけば処理してくれるサービスなど。例えば、データが飛んできたら、API Gateway経由で 、Lambdaを起こして、DynamoDBに書きもう、ということができます(さらに、2015年10月8日に、AWSからAWS IoTが発表されましたが、その連携も可能です)。

これは言い換えると、今まではお客様がIoTシステム作ろうとしたら、デバイス用意して、通信、バックエンドを用意しなければなりませんでしたが、SORACOM AirのSIMを買ってくれば、バックエンドはAWS側にすべて用意されていますので、そこですぐにセキュアなIoTシステムが比較的容易につくれてしまいます。もちろん、AWSのみならず、オンプレミスのサーバーに接続するのと同様に、AzureやIBM BluemixのIoT FoundationともBeamを使えばセキュアかつ利便性が高く、連携ができます。AWSの場合だと、その利便性がより際立つということです。

SORACOM Beamの特徴

さて、ここまで、デバイスの負荷をクラウドで肩代わりできる、SORACOM Beamを解説してきましたが、以下のような特徴にまとめられるでしょう。

  • デバイスの高負荷処理(暗号化)をオフロード
  • SIM の ID やタイムスタンプを自動的に付与
  • デバイス側の設定を変えずデータ転送先を動的に変更
  • IoTデバイスから直結でAWSクラウドを利用

SORACOM のビジョン

株式会社ソラコムのビジョンは、「世界中のモノと人をつなげ 共鳴する社会へ」となります。このたび日本発のIoTプラットフォームとしてSORACOMを発表させていただきました。

ソラコムのソラは宇宙の宙、コムはコミュニケーションのコムです。ソラコムのロゴは、プラットフォーマーとしてのソラコムは宇宙であり、SIMの挿されたIoTデバイスは星。お客様やパートナー様に、無数の星を浮かべていただき、思い思いの星座を描いていただく、という意味を込めています。

日本のスタートアップ、製造業はモノ作りに長けていると言われていますが、一方で、そういうモノ作りに携わる人と、インターネットテクノロジーが業界的にも人材的にも距離が有ることが課題として指摘されています。SORACOMは、IoTプラットフォームとして、モノとクラウドをつなぎ、場(プラットフォーム)を提供するだけでなく、その分野に携わる人とコミュニティをつなぎ日本の世界のIoT業界を盛り上げていきたいと考えています。我々は、日本発のグローバルIoTプラットフォームとして今後のグローバル展開を計画しています。

是非、SORACOMを使って頂き、フィードバックを頂けると嬉しく思います。

株式会社ソラコム 玉川 憲

株式会社ソラコム いますぐ始めよう ディベロッパー向けサイト SORACOM パートナースペース (パートナープログラム)

SORACOM API こぼれ話

ソラコム開発チームの小熊(おぐま)です。

この記事は SORACOM リリース記念リレーブログ の 10月9日分です。

そうそうたる顔ぶれの皆様のあとで、しかもソラコムからのトップバッターという二重の重圧の中、記事を書かせていただきます。

フルスケールエンジニア

さて、ソラコムのリリース直前、弊社 CEO 玉川を取材していただいた エンジニア Type 様の記事 が公開されました。 この記事の中で「フルスケールエンジニア」という言葉が使われていて、そのキーワードが一部で話題となっていたかと思います。

実はその「フルスケールエンジニア」という言葉を考えたのは、何を隠そう私です。

「フルスケール」は、ある時パッとひらめいた言葉ではありますが、自分の中ではこれから先の理想のエンジニアを表現する言葉としてけっこうしっくりきていて、それはいったいどんな理想像なのかということについて、ちょっとこの場を借りてご説明させていただけたらなと思います。


これまで、ハードウェアや組込みソフトウェアの世界とクラウドや Web のような世界との間には、活発な交流があったとは言いづらく、エンジニアのスキルもそれぞれの分野で全く異なるものだったのではないかと思います。

ハードウェアや組込みソフトウェアの世界は、1ビット単位のデータ、1本1本の信号線、ナノ秒単位の電圧の変化、ナノメートルオーダーの半導体、というようなものを取り扱うような世界です。 一方、クラウドというのは TB(テラバイト)もしかしたら PB(ペタバイト)というスケールのデータ、数万・数千万というクライアントからのコネクション、何年間にもわたってデータを蓄積しつづけ、日本とアメリカといったような1万キロも離れたような場所との地理的な分散を意識する、そういった規模感の世界です。

IoT が「難しい」と言われるのは、そのような何万倍も何億倍も異なるスケールの両方を、同時に取り扱う必要があるのが一因ではないかと個人的には考えています。 それだけではありません。その両極端の間には、スマホ、PC、エンタープライズ、Web などさまざまなスケールの世界があって、どれも IoT と無関係とは言えません。

このようにさまざまな「スケール」に対応しているエンジニア=「フルスケールエンジニア」こそが IoT の世界では必要になってくるのではないかと思います。

私たちソラコムのプラットフォームは IoT デバイスとクラウドをつなぐという重要な役割を担っているという自負があるのですが、私たちソラコムのエンジニア自身がまずもって IoT とクラウド、そしてその間に存在するさまざまなスケールの世界に精通している「フルスケールエンジニア」である必要があると考えています。

フルスケールエンジニアは「理想のエンジニア像」と上で書いたように、私自身はまだまだ精進が必要ではありますが、いつか胸を張って「フルスケールエンジニアです(キリッ」と言えるように、これからもいろいろな分野に挑戦していきたいなと思っています。

SORACOM API Gateway

さて、前置きが長くなりましたがここからが私の記事の本題です。

SORACOM のプラットフォームは API 経由でコントロールしていただくことができるのが大きな特徴の一つで、すでに SORACOM リレーブログやその他のブログ記事等でも API (CLI) 経由でいろいろ試してみていただいております。

SORACOM ユーザーコンソールも内部的には SORACOM API を呼び出す “シングルページ Web アプリケーション“ (SPA) となっておりますし、CLI(soracom コマンド)も API のラッパーになっています。すなわち、コンソールや CLI でできることは基本的にすべて API でできるということになります。(一部非公開の API もあります)

具体的な API の使い方については、開発者サイトにもドキュメントがありますし、さまざまなブログ等の記事で取り上げていただいているので、ここでは詳しくは触れません。

その代わりに、ちょっとしたエピソードをご紹介したいと思います。

SORACOM の API は、https://api.soracom.io/v1/ という URL をベースとして呼び出していただいておりますが、このホスト名を解決すると ELB (Elastic Load Balancer) の CNAME となっていることがわかると思います。

この ELB が入口となって AWS 上に構築されたゲートウェイを経由してバックエンドのサーバー群にリクエストが転送されます。

SORACOM のバックエンドはいわゆるマイクロサービス的な作りになっており、複数のサーバ上に散在している API を、ゲートウェイを通すことで外から見た時に一箇所にアクセスしているように見せています。

他にも、ゲートウェイで簡易的な認証(有効な API キーが付いているかどうかのチェック)、アクセスのスロットリング(不当に多くのアクセスを行っていないかのチェック)などを行って、有効なリクエストのみをバックエンドに展開するようにしています。

このゲートウェイなのですが、当初から現在の形のように SORACOM プラットフォームの内部に存在していたわけではなく、紆余曲折を経た上で現在の構成になっています。

今日は、ソラコム開発秘話のような感じでそのことについて書いてみたいと思います。

Apigee 時代

SORACOM の開発が始まった初期の頃、私たちは Apigee という外部サービスを利用して API ゲートウェイを構築しておりました。

Apigee はとても便利なサービスで、Web コンソール画面から API の定義を作成したり、転送先の設定を行ったり、API のデバッグを行ったり、JavaScript で書いたコードを Apigee 上で実行したりといったことができました。

私たちはさまざまな API ゲートウェイサービスを比較し、この Apigee が最も使いやすくて最も私たちのニーズに合っていると判断し、導入を決めました。

数ヶ月の間は順調に使えていたのですが、ある日 Apigee のメンテナンスが行われたタイミングで、私たちの API がまったく呼び出せなくなるという事態が発生しました。

Apigee のサポートに問い合わせたところ、私たちが依存していた一部機能に問題が発生し、現在復旧作業中であるとの連絡をもらいました。一応の回避策(依存していた機能を迂回する)も教えてもらいましたが、それでは Apigee を使っている理由がなくなってしまうくらい重要な機能でした。

API を呼び出すことができないとなると、SORACOM プラットフォームの大きな特徴が失われてしまいますし、なにより SORACOM をご利用いただくお客様に多大なご迷惑をお掛けすることになります。

SORACOM にとって API はプラットフォームの生命線であり、決してオマケ機能などではなく、これなしには SORACOM 自体が成り立たないような重要な存在なのだということを改めて認識しました。

そしてこのことをきっかけに、API ゲートウェイは外部で運用されているサービスを利用するのではなく、私たちのプラットフォームの内部で動かした方が良いのではないかという議論が社内で起こりました。

Apigee のオンプレミスバージョンを AWS 上で動かすという選択肢もあったのですが、私たちのような小さな企業で small start するには少しお値段が、、、ということで、私たちは SORACOM プラットフォーム内(すなわち AWS 上)で動かせそうないろいろな代替のサービスを検討しました。

まず目に止まったのは、ちょうどそのときタイミングよく発表された AWS のサービス、Amazon API Gateway でした。

Amazon API Gateway の検討

そんなわけで、喜び勇んで Amazon API Gateway を試してみたのですが、使ってみるうちに以下のようなことがわかりました。

  • API の作成は Web コンソールから行えるが、Apigee ほど簡単ではない

    • Apigee では、API の Path のパターンに応じて一括して「この Path の配下へのアクセスはすべてこのバックエンドサーバに振り向ける」というような設定ができましたので、Apigee 上で作成する必要のあった定義はせいぜい 5〜6 個程度だったのですが、Amazon API Gateway を使うと API の Path の数だけ(非公開のものを含めると 60 近く)を一つ一つ定義していく必要があります。ほとんど内容が同じものをひたすら作らないといけないので、一つ一つは単純でもメンテナンスなどを考えるとせめて自動化ができないと辛そうです。発表当初は Amazon API Gateway を制御するための API がとくにアナウンスされていないようだったのと、AWS 公式の SDK も、どの言語のものも Amazon API Gateway にはまだ対応していなさそうだったので自動化も難しそうでした。
  • リクエストヘッダーの中身をチェックしたり、バックエンドにリクエストを送る前に独自のヘッダーを付与するというような単純なことが簡単にはできなさそう

    • Apigee では、ヘッダーを操作する処理を XML で定義しないといけないという辛さはありましたが記述量自体は大したことがなく、比較的直感的にヘッダーを操作できたのですが、Amazon API Gateway ではテンプレートを定義してヘッダーの中身をボディの JSON に組み込んでそれを処理したり、逆にボディに書かれている値をヘッダーに入れたり(これもテンプレートを定義する必要がある)、しかもこれを API ごとにやらないといけなかったのでテンプレートの記述量が多くなってしまいそうだったのと、もしかしたらバックエンドのサーバ側にも変更が必要になりそうだったのと、あとは上と同様に自動化できなさそうなのがとても辛そうでした。

これらの点に関しては、私が単に調べきれなくて実は簡単にできることを見逃していて難しく考えすぎていただけかもしれませんし、現在はもうできるようになったりしているのかもしれませんが、当時の私の結論としては Apigee から Amazon API Gateway への移行は難しいという結論を下しました。

Amazon API Gateway 自体はとても良いサービスで、SORACOM Beam との相性なども抜群なのでぜひみなさん使ってみてください。たまたま私たちのやろうとしていたこととはちょっと方向性が違ったというだけのことだと思います。

StrongLoop の検討

次に、弊社 CTO 安川が「これいいかも」と言って見つけてきたのが StrongLoop でした。

StrongLoop に関しては、SORACOM のインターン 1 号、shun が熱心に調べてくれました。

StrongLoop API Gateway は当時まだベータ版でしたが、shun の調査により私たちの必要としている機能は一通り揃っていそうだということがわかりました。

StrongLoop は Node.js で実装されており、AWS 上で動作させることもできましたのでこれはイケる!!と思って喜び勇んでデプロイしかけたのですが、StrongLoop のインスタンスを単体で動作させるのはうまく行ったのですが、複数インスタンスでクラスタリングしようとするとどうにもうまく動かすことができなかったのです。shun も調査を続けてくれましたし、StrongLoop に問い合わせたりもしたのですが数日かかってもなかなかうまく行かず、、、

この問題がもし解決できても、実際にサービスを開始したあとにもしも何かエラーが起こったりしてうまく動かなくなってしまったときに、同じように何日も原因がわからないというようなことになったら、これはやっぱりまずいんじゃないか、、、という空気が社内に流れ始めました。

もちろんサービスイン前には有償プランに入って正式なサポートを StrongLoop から受けられる見込みがあるとはいえ、これは大きな不安要素です。

外部サービスを私たちのプラットフォーム上で動かすだけではダメで、コアな機能はそのサービス自体を自分たちで作らないといけないという結論に達し、StrongLoop とは契約寸前まで行っていたのですがお断りの連絡を入れました。

すると、そう決断した翌日くらいに「StrongLoop が IBM に買収された」というニュースが。天下の IBM 様が買収するようなサービスなので、StrongLoop は本当に良いサービスだと思いますのでみなさんはぜひ利用を検討してみてください。

そんなこともあろうかと・・・

そんなこともあろうかと、というわけではないのですが、ここで白羽の矢が立ったのは、自社内で管理コンソール(外部からアクセスできない、SORACOM の中の人しか見れない Web 画面)用の API ゲートウェイとして Go 言語でサクッと私が作ったプログラムでした。社内では Go Proxy とか Ogu Proxy とか呼ばれています。

この Ogu Proxy をベースに、少し足りない機能を足せば実は外部サービスを利用しなくても十分なんじゃないか?ということになり、急遽体裁を整えて運用に載せることになりました。

初期の頃は API ゲートウェイという存在そのものがよくわかってなくて自前で作るなんてまったく想像もできなかったのですが、実際に数ヶ月 Apigee などを使ってみて自分たちに本当に必要な機能が何なのかということが見えてきていた事もあって、自信を持って Ogu Proxy で十分と思えるようになっていました。

Ogu Proxy - Windows インスタンス時代

その Ogu Proxy ですが、当初は本当に社内用ということで、専用の EC2 インスタンスを割り当てるのももったいないという感じで、EC2 上で動いていた(けどめったに使われていなかった)Windows のインスタンスを間借りして動いているような状態でした。

それじゃさすがにマズいということで、いったん Linux のインスタンスへと移行しました。

移行はまったく難しくなく、というかソースコードには全く手を入れず、コンパイル時のターゲットオプションの変更だけで Linux で動作しました。Go で書いておいて本当によかった。

Ogu Proxy - Elastic Beanstalk 対応

とはいえ、素のままの EC2 インスタンスの Linux 上で動いていると、負荷が高まった時にどうするか、とか新しいバージョンをデプロイするときにどうするかといったような管理上の問題が出てきます。

そこで Ogu Proxy を Elastic Beanstalk (以下 EB) で動作させるようにしました。

当時は EB の Go サポートは Docker ベースだったので、EB の Go 環境(実態は Docker コンテナ)を作りました。 環境を 2 つ作って Blue-Green Deploy のようなこともできるようになりました。

Ogu Proxy - ELB + AS 版

しばらくは EB で動作させていましたが、デプロイにやけに時間がかかっていたのが難点でした。(Docker コンテナを毎回ビルドしてたからと思われます。現在の EB は Go を直接サポートしているので改善している可能性があります)

そんなとき、クラスメソッドさんの「Auto Scaling環境でのBlue-Green Deploymentの切替がAWS ELBでできるようになりました。」 という記事に触発され、さっそく Ogu Proxy もこの方法で Blue-Green デプロイができるようにしました。

こちらの方式をさらに推し進め、EC2 インスタンスの起動時のスクリプトで Ogu Proxy のバイナリと設定ファイルを S3 バケットから持ってきて実行するようにしました。すると、Ogu Proxy のデプロイはバイナリと設定ファイルを S3 のバケットに入れるだけ、という運用にできましたのでとても楽ですし速いです。

EC2 インスタンスは素の Amazon Linux のままでよく、追加で何かインストールする必要すらないです。

現時点で動作している Ogu Proxy はそんな構成になっています。

ちなみに Ogu Proxy は Go で書いたので非常に軽量です。

たとえばメモリのフットプリントがアイドル時で 8MB くらい、現時点までのピークでも 16MB くらいととてもコンパクトです。(/proc/${pid}/status で VmRSS などを参照しました)

簡単な負荷かけテストをしても CPU 使用率は 1% 程度までしか上がりません。(ほとんどネットワークの I/O 待ちになるためと思われます)

今後 SORACOM のユーザー数が増えてきてアクセス数が増えてもしばらくはスケールアップ・スケールアウトは必要ないかもしれません。

Go のエコシステム(標準ライブラリや Github 等で公開されているプロジェクト)のおかげで、Ogu Proxy のソースコードは空行・コメント行等含めても 1200 行程度と非常にコンパクトに収まっています。

まとめ

Go 言語最高

SORACOMサービスリリース講演 全文書き起こし (2)

2015年9月30日に行われた、ITpro EXPO 2015 特別講演をベースとしました書き起こしの第2回です(スピーカー:株式会社ソラコム 代表取締役社長 玉川)。 第1回

本日は、「SORACOM Air」についてお届けします。

SORACOM Air - プログラマブルなモバイル通信サービス

このIoTプラットフォームSORACOMのモバイル通信サービスとして提供するのが、SORACOM Air (ソラコムエアー)です。

モバイル通信サービスというと、通常は、格安SIM?となるのですが、このサービスは全く出発点が違うものです。人向けのSIMではなく、完全にIoTデバイスに向けて作ってあります。

人向けのSIMとは何が違うかというと、人向けのSIMはある意味通信の土管のようなもので、SIMをいれたら通信できるけど、それ以外の出来ることはほとんどありません。IoTデバイスというのは、それこそセンサーにしても、ものすごい数ばらまくことになるので、SIMを挿してインターネットにつながったはいいけど、運用とかメンテナンスはどうするのという話が出てきます。

そこで、SORACOM Airを使うと、このSIMを買ってモノに入れてもらうと、そのSIMの使用開始、解約、速度変更、などををwebからコントロールできるのです。それこそ1万個のSIMを一気に使用開始して、一時的に止めたり、速度を変えたり、解約したりができるようにしました。

これをみていただくと、ユーザーコンソールと呼んでいるものですが、これログインすると、ひとつひとつのSIMを一覧で見ることができます。これはソラコム社員が使っているデバイスやタブレット、センサーに入れて実際に使っているSIMの一覧です。これを個別に回線を使用開始したり、休止したり、それこそ社員全員分を解約することもできます。

おもしろい点として、我々はパケット交換機能もクラウド上で実装しているので、通信スピードもリアルタイムで変えられるようにしました。これはどういう意味があるかというと、IoTのデバイスで、センサーからデータをあげたいようなお客さんの大半は回線速度はいらない。遅くてもいいし、たまにしかあげないので安いほうがいいというお客様が多い。また、監視カメラからデータを送るから、その時だけ程度スピードが必要というお客様もおられます。我々はどちらもサポートできるように、いつでも速度は好きな様に変えられるようにしています。ただし、遅いスピードだと安くしますし、早いスピードの場合はちょっと高くします。それから、アップロードのほうが安くしますし、夜間のほうが安くなります。なぜなら、我々にとってモバイル通信におけるコストの大半は基地局との帯域になりますので、それを多くの人がうまく使うシェアドエコノミーとして使い回せば、皆が安くなります。なのであまり使われていない夜間などを安くするようなインセンティブをつくって、そっちを使える人はそっちを使ってもらえるようにしています。

例えば、SIMの通信料履歴などもすべてみれるようにしています。なのでデバイスに挿してだすと、障害が起こった時など、デバイスがわるいのか、通信がわるいのかも切り分けることができます。

それから、監視機能もあります。各1個のSIMの1日の通信量がこれを超えたらメールで連絡するとか、超えたら通信の速度を止めて、データを流せなくするといった管理機能もつけました。

課金情報もほぼリアルタイムで見ることができます。当社の場合、20数個のSIMをつかっても実際に使った総データ量です。我々の場合は、この金額ですので、相当安く使えるといえますね。請求予定詳細をcsvでダウンロード可能です。SIMを買うときは、この発注画面から注文してもらって、手元に届いたらものに挿してもらう、という仕組みです。

APIでコントロールできる

こうなってくると、IoTデバイスの回線管理、速度変更、監視をWebでできるようになってすごく便利になります。一般的なコンシューマ向けのSIMではなく、IoT向けのSIMだと話した理由がわかっていただけたでしょうか?

しかしながら、IoTデバイスの今後の規模を考えていくと、例えば、1万個のSIMをすべて、Webでぽちぽち操作するのかという問題があります(笑)。

なので、開発者だと当然のように、プログラムからAPIでコントロールしてもらおうということで、SORACOMのプラットフォーム自体にAPIを備えています。通信という非常に強大で硬くて融通の聞かないインフラを、プログラムで非常に柔らかくしたということです。

これを使うと、例えば、在庫に入れていたIoTデバイスを売れたときに使用開始に自動的にする、とか、学校の理科の教材でタブレット配るような場合も、授業時間だけオンにしておけば、生徒がいたずらできない。また、監視カメラにいれて普段はローカルに保存しているけど、なにか動体検知したときだけ、速度を早めてリモートから動画を見る、といったことも考えられます。

SORACOM Airのまとめ

さて、ここまで、いつでも必要なだけIoT通信が使える、SORACOM Airを解説してきましたが、下記のような特徴があるといえるでしょう。

  • LTE/3Gだから、高い接続性、セキュアな通信
  • フェアでリーズナブルな従量課金(1日10円〜)
  • Webコンソール、APIから複数SIMを一括操作(通信の開始/休止/再開/解約、速度変更、監視)
  • 1枚からでも、1000枚以上でも、すぐに調達可能
  • 自在に値付けをしてビジネスができる

ソラコムチームは、これまでSORACOM Airの構築に多大な時間と労力をかけてきました。逆にいうと、IoTのスタートアップや事業をやりたい方々が、通信もやりたいとおもったら、我々と同じ苦労をすることになります。それは大変勿体無いですので、ソラコムがプラットフォーマーとしてその泥臭いところをやり、お客様は今すぐ通信事業者になれます。デバイスをやっている人も通信事業者になれるし、クラウドのサービスやっている会社も通信事業者になれるし、システムインテグレイーターも通信事業者になれます。

SORACOM Airは従量課金で提供していますので、ほとんど初期費用がない形で通信を含めたビジネスを開始できます。例えば、SIMを一枚だけ使ったプロトタイプを作り、必要に応じて規模を拡大していけますので、スモールスタートできます。また、もし万が一、そのプロトタイプが上手くいかなければすぐ辞めて、失敗のコストを最小化出来るので、新しいことにどんどんチャレンジできます。

これまで、我々は、SORACOM Airをプライベートβとして限定顧客に提供させて頂き、実際に利用や検証頂き良いフィードバックを頂きました。例えば、リクルートライフスタイル様のAirレジ、フォトシンス様のAkerunにおいてご利用頂いています。

SORACOMの利用方法、料金

SORACOM Airの利用料金は、以下のとおりです。ほとんどデータ使用のないシステムの場合、1日10円ですので月300円からIoTシステムを構築できます。

  • 契約事務手数料 : 580円 / 回線(SIM)+送料 (Amazon.co.jpからの購入の場合、別料金)
  • 1回線毎の基本料金:使用開始前 5円/1日、使用開始後 10円/1日
  • データ通信料金: 利用した総量の従量課金(1MBあたり0.2円〜)
  • SMS機能:1SIMあたり5円/1日、3円/1通

料金に関する詳細はこちらをご覧下さい。 https://soracom.jp/services/air/price/ https://soracom.jp/services/beam/price/

SORACOM AirのSIM購入方法としては、通販サイトのAmazon.co.jpから購入(1枚から購入可能)するか、SORACOMのユーザーコンソールから購入(10枚単位)できます。 購入に関する詳細はこちらをご覧下さい。 https://soracom.jp/start/

販売するSIMの種類は、サイズとして、ナノ、マイクロ、標準SIM、それぞれ、データ通信のみ/SMS機能ありの2種類があり、合計6種類となります。

第3回につづく

株式会社ソラコム いますぐ始めよう ディベロッパー向けサイト SORACOM パートナースペース (パートナープログラム)

SORACOM AirのSIMが直販サイトで10枚から購入可能に

IoT向けのモバイル通信サービスであるSORACOM AirのSIMを購入するには、下記の2つの方法があります。

  1. Amazon.co.jpから1枚単位で買う
  2. SORACOM User Consoleから20枚単位で買う

Amazon.co.jpから購入する場合は、1枚から好きな枚数をご購入いただけるというメリットがあります (10月7日時点で1枚あたり888円(税別))。 一方で、SORACOM User Consoleから購入する場合は20枚単位でしか買えないものの、1枚あたりの単価が安く(580円/枚 + 送料)、購入したSIMをワンクリックでまとめて登録でき、SIM登録の手間が省けて利便性が高いというメリットがあります。

今回、最初に試すには20枚は多いけれども10枚は欲しいというお客様の声にお応えし、SORACOM User Consoleから10枚単位で買えるようになりました。

order form

アカウント登録後「発注」タブから注文を行うことができます。 ぜひ、Amazon.co.jpのみならず、SORACOM User Consoleからもお買い求めください!

玉川

SORACOMサービスリリース講演 全文書き起こし (1)

本日より全3回にわたり、2015年9月30日に行われた、ITpro EXPO 2015 特別講演をベースとしました書き起こしをお届けします(スピーカー:株式会社ソラコム 代表取締役社長 玉川)。

当日会場に来られなかった方も、ぜひダイレクトな言葉でソラコムを感じていただけると幸いです。

IoTの課題とIoTプラットフォームSORACOM

ソラコムは、創業以来、「IoTプラットフォームを創っている」とだけ公開させていただいておりました。我々のチームは、開発に集中するため、チーム一丸となってステルスで取り組んできました。いよいよ、本日2015年9月30日、IoTプラットフォーム「SORACOM」 (以下、SORACOM) をリリース致します! SORACOMは、本日から、すぐに使っていただくことができます( https://soracom.jp/start/ )。

さて、SORACOMとは何なのか、を説明する前に、まずIoT(Internet of Things、”モノのインターネット”)が盛り上がっている背景を振り返りたいと思います。

IoTの可能性

こちらIoTの文脈が語られるときによく目にする図ではないでしょうか?

右側のクラウド。私もAWSの日本事業立ち上げに過去5年ほど携わっていましたが、クラウドの近年の進化はすさまじいものがありました。例えば、Amazon S3でデータをクラウドに保管すると1GB(ギガバイト)あたり一ヶ月保管して3円くらい。少し前からすると隔世の感が有り、データは捨てずにとりあえず入れておくということが可能になりました。とりあえず保管しておいて、Amazon EC2などのコンピューティングパワーを使って計算すれば、例えば、人工知能などによる解析やデータの可視化のようなことも出来ます。

左側のモノ。スマホ・タブレットも普及してきていますし、アップルウォッチのような時計やドローンのような面白いデバイスも出てきました。さらに、Raspberry PiやIntel Edisonなどを使ったラピッドプロトタイピングも広がってきて、Makersムーブメント(デジタル製造の潮流を指すトレンド)のようなものも起こっています。

当然のように、右のクラウドと左のモノをインターネットで繋げばいろいろおもしろいことができます。これはもう必然の流れで、IoTは可能性に満ちあふれています。ワクワクしませんか?

IoTの課題

一方で、IoTはまだまだ実証実験段階であり、実用化には時間がかかるという見方もあります。確かに、実際にモノからインターネットに接続しクラウドで解析する、といったごく典型的なIoTシステムを構築する際にも、様々な課題が浮かび上がります。

まず電力供給。ある容量の中に押し込められるバッテリー量は10年かかっても2倍にもなっていないと聞きます (一方、CPUは10年で100倍のオーダーにもなっています)。

それから「インターネット接続をどうやってやるの?」という話があります。最近は近距離無線にごまかされている感じがあるんですが、IoTデバイスが最終的にはインターネットに繋がらないと、”Internet” of Thingsにならない。BLEだけじゃIoTにならないですよね。スマホテザリングで繋げばいい、という話がありますが、スマホテザリング系の製品は、利用者があきたら面倒くさくなって繋がなくなる。インターネット接続も解決されていないですね。

モノがインターネットに繋がって、データを上げるとなるとセキュリティってどうなるのという課題があります。エンド・トゥー・エンドで、モノからクラウドもしくはサーバーまで、一貫したセキュリティを保つにはどうすればいいかという問題について良い解がありません。

一方で、セキュリティを保つために、モノ側に高価なCPUをいれたり、デバイス認証のような仕組みを入れると、全然小型化できなくて、コストも高くなり、沢山のデバイスを置けず、という堂々めぐりになります。

こういう課題にたいして、私達はプラットフォームで解決したいと思っています。

IoTの通信の課題

まず非常に厄介な「インターネット接続」のところをみてみましょう。

IoTシステムの図とかで、あって当たり前、的に書かれている(もしくは省かれて書かれていない)のが通信ですね。しかし、実際にIoTシステム構築しようとするとすごく難しいことがわかります。有線LANがあれば最高ですが、ある場所は限られている。無線LANはかなり普及していますが、セキュリティに懸念があり、設定自体も簡単なわけではない。例えば、おばあちゃんにデバイスをおくって、「無線LAN設定して」といっても普通できないので、そういうIoTデバイスは、人を派遣せねばならずインストレーションコストがかかる。

普通に考えると、インターネットに繋げる部分はモバイル通信が最高です。移動できるし、すぐつながる、どこでもつながる。ただし、モバイル通信は、これまでは、人向け、つまり人が見るスマホに対して作られてきたものなので、当たり前なのですが単価が高い。大手携帯キャリアのSIMだと月5000円。最近の格安SIMでデータ通信のみだと1000円を切りますが契約事務手数料が高かったり固定期間契約だったりする。また、どちらかというと通信をすれば良い、という形式で、多数のモノの通信回線そのものを管理したり、セキュリティを考えたり、という側面がない。

いろいろなIoTデバイスのスタートアップや新規事業の人と話しましたが、IoTデバイス込のIoTシステムを作っていると、結果的にランニングコストの大半が通信費用になってしまうという話も聞きます。また固定契約期間や最低契約枚数など調達方法に柔軟性がないことも課題でした。多数のIoTデバイスの通信SIMを管理するのは非常に大変です。

このインターネット接続の部分をテクノロジーで解決するとIoT業界が盛り上がるのは間違いないと感じ、自分たちで通信事業を始めようと決心しました。

通信事業をやるには

では、我々のようなベンチャー企業がどうやって、IoT向けの通信事業をはじめればよいでしょうか?そもそも通信事業はどうやれば良いのでしょうか?

少し業界構造の話になりますが、大手携帯キャリア様は、基地局やデータセンターを持っています。ここでパケット交換したり、帯域制御したり、顧客管理したり課金しています。さらにISP (インターネットサービスプロバイダー)をやっていて、ざっくりというとこの3つ全部やっているんですね。

私達が通信やりますといったときに、一番は簡単な方法は、キャリアからSIMを買って売る。2000円で仕入れて2500円で売ると言う形ですね。例えば、いわゆるMVNO (仮想移動体サービス事業者、Mobile Virtual Network Operator)、楽天様やイオン様がやられていると思いますが、基本的にはこのスタイルです。ブランドとか販売網の強みで売っていく戦略です。しかし、我々のようなスタートアップにはブランドもないですし、このモデルは適していません。また、このモデルには技術的なイノベーションを起こす隙間もありません。

逆側の、一番突っ込んだやり方をすると、基地局、データセンター、ISPの全部はできないけど、キャリアの基地局部分を借りて、そこに専用線をひくというアグレッシブなやり方があります。業界用語ではL2卸契約というのですが(レイヤー2で繋ぐのでL2卸契約)、キャリアさんと契約をしてMVNOになるというやり方があります。この場合、自分たちでデータセンターをもってパケット交換器、テレコムインフラベンダーから数億円のものを買ってきて、ISPをやるという、基地局以外を全部やるというやり方です。 これは、初期費用が10億円以上かかるので、これもベンチャーには適していないと考えています。

SORACOMのユニークなアプローチ

ただし、ソラコムにはブランドや販売チャネルや10億円のお金はありませんが、我々にはアイディアと技術力があります。これらを買ってこなくても、AWSの上でつくれるんじゃないかと。

そこで、キャリアの交換機から専用線を引いて、これらのシステムをAWSクラウド上で作ったのがSORACOMです。よりテクニカルに言うと、LTE/3Gのコアネットワーク(パケット交換、回線管理、帯域制御)とサポートシステム(顧客管理、課金)をクラウド上に実装し、そのパケット交換機能がキャリアのコアネットワークと L2卸接続をしています。

ある意味、開発費以外とL2卸接続の接続費用以外は、初期投資もかかっていませんし、全部AWS上でクラウドネイティブ設計で作ってしまったので、非常にスケーラブルで高可能性であるように設計しています。しかも、今までのパケット交換機は、人向けに作られているので、一人あたり1セッションから数セッションで、高速につながる通信ということに特化しているのですが、我々、IoT向けなので、それこそ10万、100万、数十億みたいなモノが、あまりデータは流れていないけどつながっている、そういうものに最適化したような仕組みを作ったということです。

NTTドコモ様の基地局を借り、専用線でつないだAWSのクラウドの上で実装する。我々はAWSとドコモの両巨人の方にのったバーチャルキャリアのようなものです。初期投資をあまりかけず、お客様が増えたら増えた分だけインフラを拡張することができるのでムダがない。その分、料金を値下げして幅広い層に使っていただけるプラットフォームを提供することができます。

第2回につづく

株式会社ソラコム いますぐ始めよう ディベロッパー向けサイト SORACOM パートナースペース (パートナープログラム)

ソラコム掲載記事のご紹介

広報のkyonです。 9月30日にサービスリリースしたソラコムについて、様々なサイトで言及いただきましたのでご紹介させていただきます。

ソラコム、IoT対応通信サービス 格安スマホより8割安く http://mw.nikkei.com/sp/#!/article/DGXLASDZ24ILO_V20C15A9TJE000/

日経ITpro IoTに格安通信、ソラコムが機器用SIMをクラウド活用で8割安に http://itpro.nikkeibp.co.jp/atcl/column/14/346926/092800348/?n30=

TechCrunch 【詳報】ソラコムがベールを脱いだ、月額300円からのIoT向けMVNOサービスの狙いとは? http://jp.techcrunch.com/2015/09/30/soracom-launches-mvno-service-for-iot/

Publickey 格安SIMによるドコモ回線をAmazonクラウド上でプログラマブルに制御。ソラコムがネットデバイス向けの新通信サービスを提供開始 http://www.publickey1.jp/blog/15/simamazon.html

ソラコムのビジネスモデルは? 開発期間は? キャリアの大資本参入にどう対抗する? 玉川憲社長に聞く http://www.publickey1.jp/blog/15/post_260.html

atmarkIT IoTエコシステムのハブを目指す:SORACOMの、IoTプラットフォームサービスとしてのインパクト http://www.atmarkit.co.jp/ait/articles/1509/30/news044.html

ASCII.jp “ブームとしてのIoT”を終焉させる国産IoTプラットフォームの正体 星の数あるIoTデバイスをつなぐSORACOMの全貌 http://ascii.jp/elem/000/001/057/1057112/

THE BRIDGE SORACOMの凄さは第三者が「SIM」を自由に発行・運用できることーーIoT向けモバイル通信PF、ソラコムが提供開始 http://thebridge.jp/2015/09/soracom

インプレス クラウドWatch ソラコム、モノの通信に特化したIoTプラットフォーム「SORACOM」をリリース、API指向の関連サービスも同時に提供開始 http://m.cloud.watch.impress.co.jp/docs/news/20150930_723412.html

gihyo.jp IoTプラットフォームを目に見える形で身近に ─元AWS玉川憲氏が率いる企業ソラコムが始動 http://gihyo.jp/news/nr/2015/09/3001

zdnet ソラコム、AWSで稼働するIoT基盤–モバイル通信とデータ転送を提供 http://japan.zdnet.com/article/35071214/

WirelessWire News ソラコム、AWSに直結可能なIoTプラットフォーム「SORACOM」を発表 https://wirelesswire.jp/2015/09/46494/

fabcross ソラコム、IoT向けネットワークプラットフォーム「SORACOM」と関連サービスを提供開始 https://fabcross.jp/news/2015/09/20150930_soracom.html

SORACOM Air が ITpro EXPO AWARD 2015 大賞受賞

広報のkyonです。皆様にビッグニュースです。 昨日から出展しているITpro EXPO 2015で、「SORACOM Air」が、「ITpro EXPO AWARD 2015」の大賞を受賞しました!

授賞式の様子

昨年は、超小型コンピューター「Edison」(米インテル)が受賞した映えある賞。 ブースにお越しいただいた皆様、注目いただいた皆様、ありがとうございました。

特別講演のレポートならびに、スライドが公開されています。 昨日、来られなかった方はぜひこちらをご覧ください。

特別講演のレポート http://itpro.nikkeibp.co.jp/atcl/news/15/093003133/

特別講演のスライド

ITpro EXPO 2015は明日10月2日までの開催です。 東京ビッグサイト ソラコムブースで皆様のお越しをお待ちしています!

「ITpro EXPO AWARD 2015」とは

ITpro EXPO 2015に出展されるすべての製品/サービスを対象として、日経BP社が発行するIT/ネットワーク誌、Webメディアの編集部が取材・審査し、製品/サービスとして優れていると同時に、来場者に対しわかりやすくインパクトのあるプレゼンテーションをしたものを表彰するものです。(下記URLより引用)

http://itpro.nikkeibp.co.jp/expo/2015/award.html