SORACOM Blog

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

SORACOM パートナースペース サイトをオープンしました。

本日11月9日、SORACOM パートナースペース(SPS)への参加パートナー様を対象とした SPS パートナー向けサイトをオープンしました。

SPS パートナー向け サイト https://sps.soracom.io/

SPS は、SORACOM のパートナープログラムです。 SORACOMでは、特に登録などすることなく、だれでも SORACOM プラットフォームを利用して自由にビジネスをすることが可能です。(もちろん、利用規約に準じてです!) ただし、SPS にご参加いただくことで、技術資料やマーケティング支援などのサポートの提供を受けることができます。特典や要件などは、SORACOM パートナースペース を参照してください。

当サイトの閲覧は、SPS に申請いただいた SPS 申請済みパートナーのみに限定しております。 以下のようなパートナー向けの資料が参照できます。

SPS-site

SPS の参加はどの企業様でも可能です。 SORACOM パートナースペース をご確認の上、以下より、ご登録ください。 https://sps.soracom.io/

SORACOM は、SPSを通じ、IoTデバイス、及びIoTデバイスを活用したソリューションや、システムインテグレーションを提供するパートナーと共にエコシステムを構築していきます。

江木 典之 (Twitter: @NoriyukiEgi)

SORACOM Beam の値下げを発表しました。

SORACOM Beam の料金の値下げをお知らせします。2015年11月3日 0:00(UTC、日本時間:2015年11月3日 9:00)より適用となります。

  • SORACOM Beamの料金を10%値下げします。
    • 【改定前】1 リクエスト (*) あたり 0.001 円(税別)
    • 【改定後】1 リクエスト (*) あたり 0.0009 円(税別)
    • (*) エントリーポイント (Beam) へのリクエスト、Beamから転送先へのリクエスト、それぞれを個別に 1 リクエストとカウントします。

なお、以下の無料枠については従来通り、変更なくご利用いただけます。

  • SORACOM Beam は、新規のお客様を対象として無料利用枠をご提供しています。 SORACOM アカウントを作成していただいた月から12ヶ月間(アカウントを作成した月を含む)は、1アカウントあたり月間 50,000 リクエストまで毎月無料とさせていただきます。 なお、リクエスト数が 50,000 リクエストに満たない場合でも翌月に持ち越されることはありません。

SORACOM Beamの料金体系については、SORACOM Beam のご利用料金 をご確認ください。

SORACOMは、運用の自動化および最適化を進め、時間とともにコスト削減を行っていく事にフォーカスしております。 今後ともお客様がコストを節約できるよう努めていきます。

江木 典之 (Twitter: @NoriyukiEgi)

ソラコム山とNode-RED

みなさまこんにちは。ソラコムでエンジニア(試用期間中)をやってます江木です。 ソラコムリリース記念ブログも、当初の目標であった1ヶ月を迎えました。一度も欠くことなく記事が公開されており、ありがたく思っています! かなり好評ですので、このまま延長するという話もあるとかないとか・・

試用期間中というのも、私は9月から SORACOM の一員となりました。この2ヶ月間は、前職をやめる→ソラコムに入る→ソラコムのリリース で、かなり激動でした。9月30日のリリースでは思っていた以上に注目していただき、通称 ソラコム山が出現した頃は、流れるタイムラインを追うことが、それはもう楽しくて仕方ありませんでした。

通称 ソラコム山 (Tweet の件数/日にち) SORACOM-YAMA

こんな渦中にいられたことはとても幸運でした。 IoTの分野で日本から新しいサービスがどんどん生まれて欲しいと心から思っています。どんどん SORACOM を使い倒してください!

さて、先週以下の Tweet を見かけました。@joeartseaさんがNode-REDにSORACOMのNodeを作ったと!

https://twitter.com/joeartsea/status/657054321675259904 tweet-joeartseaさん

Node-RED はちょくちょく触っていましたが、久しぶりに見てみると、Slack連携やらAWS連携やらいろいろ増えていたので、試してみました。

Node−REDとは? Nodeの追加方法は? は、以下などを見るといいと思います。

BluemixのNode-REDパレットにノードを追加する http://qiita.com/KenichiSekine/items/b2877c90f59774a27827

個人的には非機能要求をあまり考えずにプロトタイプを作って動かしてみるというのには向いていると思います。

Node-RED に SORACOM の Node を追加してみました。 Air 、Beam の使用状況の確認、速度クラスの変更、アクティベート、ディアクティベートなどができるようです。

SORACOM-Node

試しに期間を1日間にして、Air State をデバッグに出してみると、、

debug

早速、一日の使用量がでてきました。

というわけで、Slack に毎日一日の使用量を出してみます。(これがやりたかった) Slack では Incoming WebHooks を定義します。Node-RED では Slack の Node を追加します。 Slack の Node の設定は以下のようにしました。

slacknode

Cron 的に、指定した間隔で呼びだせるので、データ通信使用量を Slack で確認できます。

slack

この SORACOM Node だと、速度クラスの変更や休止もできるので、利用量に応じて速度を落としたり、休止させたり、また、毎日夜だけ速度クラスを上げるということも、Node-RED の UI と少しの javascript をつかうだけでできそうです。

以前のこのブログシリーズでも、ジャストインケース 松井さんが イベントハンドラーと AWS Lambda を連携して、Slackに流し込んでいました。 好きなプラットホームを使って、APIでコントロールできることが面白さの一つだと思います。

最後になりますが、@joeartseaさん、SORACOM Nodeの作成ありがとうございました。 Node-REDのユーザーグループもあるようです。 Node-RED User Group Japan https://www.facebook.com/groups/noderedjp/

江木 典之 (Twitter: NoriyukiEgi)

スマホからSORACOM Airの通信量が見やすくなりました

ソラコムのソフトウェアエンジニアの清水です。 主にフロントエンドとSORACOM Beamの開発を担当しています。

SORACOM Airを実際に購入いただいて試してくださっている方にイベントでお会いできたりして感激しているわけなのですが、ラズパイ等のIoTデバイスに使うだけでなく、とりあえずお手持ちのスマホに入れて使っているという方もいらっしゃるのではと思います。

私も最近購入したSIMフリーのiPhone, AndroidにSORACOM Airを入れて使ったりしています。 SORACOM Airはデータ通信量を時間別・日別・月別に見るAPIが提供されていて、ユーザーコンソールでも確認できるようになっています。 それを後で見返してみると、昼休みになにげなくスマホを触ったとき、実際にどれくらい通信してるというのを知ることができます。 普段はほぼ無制限なので意識せずに使っているデータ通信量ですが、昨日は思ったより多いなとか、今日は思ったより少ないなといった気づきがありました。レコーディングダイエットみたいですね。

このようにDog foodingをしていて、正直SORACOMのユーザーコンソールはスマホに最適化されているとは言いがたいという現実を再認識したわけです。 もともと、スマホで操作することはあまり想定しておらず、諸々の事情できちんと対応できていない現状があるのですが、昼休みにデータ通信量を見てムフムフする欲求を満たしたい!

ということで、ごく簡単ではありますが、スマートフォンからでも通信量を手軽に確認いただけるような画面を用意してみました。

screenshot https://console.soracom.io/#/dashboards?coverage_type=jp

主に利用しているAPIは2つです。

SORACOM Airを使って自分のデータ通信の傾向を掴んでみると、自分にあったスマホ活用方法に気づく・・なんてこともあるかもしれません(ダイレクトマーケティング)。 なお、SORACOM Airは通信量に応じた料金体系になっています。自分で監視設定を入れないと使い過ぎによる通知や速度制限がかかりませんので、使いすぎによるパケ死(死語)にはどうかご注意ください。

リレーブログも終盤にさしかかり、大変ありがたいことに私が担当しているBeam関連のトピックはあらかた紹介していただけたので、 今回はBlog Driven Development (通称 BDD) してみました。 今後もユーザー目線で使いやすいサービスを目指して開発に取り組んでいければと思います。

「SORACOM パートナースペース」詳細発表、正式申請の受付開始

9月30日にIoT プラットフォームSORACOM を発表させて頂いた際に、ソラコムのパートナープログラムであるSORACOM パートナースペース(以下、SPS)を発表し、各企業からの事前登録を受付開始いたしました(プレスリリースはこちら)。

本日の発表は、そのSPS の詳細プログラムを発表させていただき、パートナーの申請サイトを公開しました (SPS パートナー申請サイト)。

SPS の概要

ソラコムのパートナープログラムであるSPS では、パートナー企業に対して、SORACOM に関する技術資料や専門のトレーニング、マーケティング支援を提供します。また、パートナー間の協力関係を構築する場の提供を行います。それにより、お客様に安心してSORACOM をご利用いただき、IoT 業界の活性化、さらに多くのIoT事例の創出に貢献していきます。

SPS への申請方法

SPS への参加を希望される企業はSPS のサイトより申請をお願いします。申請すると「SPS 申請済パートナー」として SPS パートナー限定のウェブサイトにアクセスでき、パートナー向けの情報や資料を得ることができます。SPSは、SPS デバイス・パートナー、SPS インテグレーション・パートナー、SPS ソリューション・パートナーの3つのカテゴリーで構成されており、カテゴリー毎に各企業の事前登録を受け付けます。

SPS 認定済みパートナーへのアップグレード

SPS申請後、定められた要件を満たせば、「SPS 認定済パートナー」になります。「SPS 認定済パートナー」は、SPS パートナーのロゴを使用できるほか、限定公開のビジネス・技術資料へのアクセスや、技術トレーニングへのご招待など、様々な特典を受けることができます。

SORACOM 認定デバイス

また、「SORACOM 認定デバイス」のデータベース公開を予定しています。「SORACOM 認定デバイス」は、データ通信サービス「SORACOM Air」 やデータ転送サービス「SORACOM Beam」 での動作検証済みのデバイスが対象になります。対象のデバイスを申請し、認定されると、ソラコムが提供する「SORACOM 認定デバイス」データベース上に情報が公開され、検索出来るようになります。 認定デバイスの申請には、SPS への登録が必要です。

パートナー向け説明会での発表資料

説明会で用いた発表資料はこちらになります。

株式会社ソラコムは、SPSを通じ、IoTデバイス、及びIoTデバイスを活用したソリューションや、システムインテグレーションを市場に提供する企業と共にエコシステムを構築していきます。是非、SPSにお申し込みください!

玉川 憲 (Twitter: KenTamagawa)

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 言語最高