みなさまこんにちは。
ソラコムの小熊 (ogu) です。
本日、SORACOM Orbit のリリースを皆様にお伝えできることを大変うれしく思います。
私はこの半年間くらい SORACOM Orbit の開発に関わってきましたので、今日この日を迎えられたことが本当に感慨深いです。
SORACOM Orbit を一言で表すと、通信経路の途中でお客様自身のプログラムを動かしてデータを処理することができるサービスです。
IoT の困りごとの一つとして、デバイスとクラウドのデータフォーマットの不一致という問題が挙げられるかと思いますが、SORACOM Orbit を使うことでそのお悩みを解決することができます。
サービスの概要を紹介したプレゼン動画はこちらをご覧ください：
インライン プロセッシング サービス SORACOM Orbit 〜 IoT の通信経路でデバイスとクラウドの差分を吸収
実際に使ってみたい方はこちらをご参照ください：
データフォーマットに関して特に困っていないという方も、SORACOM プラットフォーム上で自分の書いたコードが動き、そして通信データを処理することができるというその点だけでも、特にエンジニアの皆様には楽しんでいただけるのではないかと思います。
SORACOM Orbit は SORACOM プラットフォームの “Connectivity Agnostic” および “Cloud Agnostic” のレベルを一段階高めるような、お客様にとってとても重要なサービスになると自負しておりますので、是非皆様一度お試しいただければと思います。
では、堅苦しいお話はこのくらいにして、以下は開発秘話みたいなエモい話を、ちょっと長くなりますが書いてみたいと思います。
始まりは昨年の Discovery
私は昨年（2019年）の年次イベント Discovery で植物育成システムの PoC の展示を行いました。
そのシステムでは、バイナリパーサーと SORACOM Funk を組み合わせて使ったのですが、その時の経験から「もっとすごいバイナリパーサーが欲しい」と思うようになりました。
「もっとすごいバイナリパーサー」というのはどういうものかというと、
- データの一部を読んで残りの部分の処理を変えることができる→様々な種類のデータを送りたい場合、現行のバイナリパーサーでは if 文のようなものが使えないのでちょっと複雑なデータ形式になると対応できなくなってしまいます
- 四則演算だけではなく sin() / cos() / tan() や sqrt() といった数学の関数や様々なユーティリティ関数が使える → たとえば三角関数等が使えると、2点の位置情報からその間の距離の計算をしてデータに入れ込むといったような、より複雑な演算ができるようになります
- 入力データ形式としてバイナリだけではなくて CSV などのテキスト形式でも対応できる→ GPS の位置情報をカンマ区切りの文字列で出力するようなデバイスでも容易にクラウドサービス等につなぐことができるようになります
- SIM に紐付けられているタグなどのデータを使うことができる→SIM の名称や IMSI などをデータに入れ込めば、可視化するときに便利になります
などなど、考えればキリがありませんが、とにかく何でもできて ”すごい” バイナリパーサーです。
現行のバイナリパーサー自体、すでに十分便利ですしとてもシンプルで使いやすいのですが、人間の欲望というものは尽きないものです。
じゃあこういった無限にありそうなユースケースに対応できるように現行のバイナリパーサーを拡張するには？と考えたときに、独自の DSL (Domain Specific Language) を使って変換ルールを表現してもらう今の方法だとすぐに限界に突き当たってしまうであろうことは想像に難くありませんでした。
より複雑で高機能な DSL を開発したとしても、新しい記法を覚える苦労をお客様に強いてしいますし、提供する側の我々も開発や保守が大変になりそうです。
そこで、既存の何らかのプログラミング言語で変換コードを書いてもらうような仕組みを提供すれば、処理内容の自由度はある程度担保しつつ、独自 DSL を覚えてもらう必要を回避できるのではないかと考えました。
しかしどのプログラミング言語を私達が選択したとしても、その言語に馴染みのないお客様にとってはやはり新しい言語を覚える必要が出てきてしまいます。
たとえば、Lua という言語はそういったプラグイン的な用途ではよく使われており、nginx や Wireshark などが採用しています。
しかし残念ながら多くのエンジニアにとって Lua という言語にはそれほど馴染みが無いのではないでしょうか。
Lua はとてもシンプルな言語仕様なので覚えるのはとても簡単ですが、Lua というだけで「知らない」と敬遠されてしまうのはもったいないというか、お客様にとってもソラコムにとっても機会損失になりそうです。
また、時代によって言語の流行などもありますので、5 年先、10 年先にも同じ言語をサポートし続けられるのか、お客様が使い続けてくださるのか、何らかの特定の言語にロックインしてしまうのはお客様もソラコムも不幸になるだけではないだろうか、といった悩みもありました。
かといって、複数の言語をサポートするというのも私達の負担が大きそうです。
だけど、お客様が自分自身で好きな言語で自由にデータ処理を行うコードが書けたら絶対に便利だろうなという思いは捨てきれませんでした。
Java VM のような仮想マシン上でバイトコードを実行するような仕組みにすれば、ユーザーは比較的自由に使用言語を選ぶことができ、仕組みを提供する私達としては単一のシステムを構築・運用すれば良いのでお客様も私達もハッピーになれるのではないか、と思いましたが、Java VM を始めとするリッチな VM では、セキュリティを担保することが難しそうだと感じていました。
そんなときに出会ったのが WebAssembly でした。
WebAssembly について
WebAssembly（ウェブアセンブリ、もしくは略して WASM ワズム）は、その名前に Web と入っているとおり Web ブラウザ上のアプリケーションをアセンブリで書いたかのように高速に実行するために作られた規格で、W3C がその規格を定めています。
ではなぜその WebAssembly が「すごいバイナリパーサー」と関係があるのでしょうか。
実は、WebAssembly の仕様書(V1.0) の一番最初の文章 にはこうあります。
WebAssembly (abbreviated Wasm) is a safe, portable, low-level code format designed for efficient execution and compact representation. Its main goal is to enable high performance applications on the Web, but it does not make any Web-specific assumptions or provide Web-specific features, so it can be employed in other environments as well.
日本語に訳しますと、
「WebAssembly（略して Wasm）は、安全、ポータブル、低レベルのコードフォーマットで、効率的な実行とコンパクトな表現のために設計されました。その主なゴールは Web 上でハイパフォーマンスなアプリケーションを可能にすることですが、いかなる Web 固有の仮定も置かず、Web 固有の機能も提供しないので、他の環境でも同様に採用することができます」
とあります。
WASM の出力に対応した言語は実はすでにたくさんあります。
LLVM などのツールチェーンがすでに WASM を一つのターゲットとしてサポートしているからです。
つまり、お客様には WASM 出力に対応したお好きな言語でコードを作っていただき、SORACOM のプラットフォーム上でそれを実行するようにできれば、諸々の問題が解決するのではないかと思ったのです。
私はそのアイディアが実現可能かどうか、いろいろ調べたり考えたり、実際に WASM のコードを書いてみたり、しまいには WASM の処理系まで書いてみたり して、模索を続けていました。
プレスリリースコンテスト
そして今年（2020年）の年初。社内で恒例となったプレスリリースコンテストが行われました。私は年末にアイディアを 4 つ書いて応募しましたが、そのうちの一つが WebAssembly ベースの「すごいバイナリパーサー」でした。
この「すごいバイナリパーサー」は、SORACOM プラットフォームとお客様のデバイスの境界線上に位置しているサービスであるということと、ソラコムにとってもお客様にとっても新しい地平を切り開くようなサービスになって欲しい、という思いから、コードネーム：Frontier としてコンテストに応募しました。
結果は・・・
なんと優勝！
そこから開発が始まりました。
最初は社内のメンバーに「WebAssembly とはどんなものか」ということを理解してもらうためにハンズオンセッションを行ったりしました。
しかし、私の本来の業務が多忙となってしまい、いつしか “Frontier” の優先度は下がっていってしまいました・・・
そんなある日、今年の Discovery で発表する予定だったあるサービスの開発が、様々な事情によりいったん撤回されてしまったと聞きました。
そして nori（ソラコムのグロースハッカーでありスクラムマスターでありムードメーカーでありカープファン）が言いました。
「代わりに Frontier を Discovery で発表できないですかね・・・？」
PoC
その時点で4月の下旬に差し掛かる頃だったと記憶していますが、私は正直なところスケジュール的に難しそうだなぁと思いましたが、とりあえずゴールデンウイーク明けくらいを目処に PoC（Proof of Concept、コンセプトの実証）をすることになりました。
その時点では、Discovery での発表は「新サービスリリース予定」ということにして、実際のサービスインはもうちょっと後でもいいかな、なんて考えてもいました。
私が PoC に取り掛かっている間、私の本来業務はチームメイトの moz や tadashi が率先してすべて引き受けてくれたので私は PoC に没頭することができました。彼らにはそれぞれの任務がすでにたくさんある中で、縦横無尽、神出鬼没、一騎当千な活躍を見せてくれました。彼らの存在なしには Orbit はこの世に生まれなかったと言っても過言ではありません。この場を借りて感謝します。moz+++++ tadashi+++++
さてその PoC ですが、WebAssembly の処理系はオープンソースのものがいくつかあり、それらの中から私達の用途に最も適していそうなものを選び、WASM コードでデータを変換するというサンプルを書きました。
そしてゴールデンウイーク明けには「これは行けるんじゃないか？」という手応えを掴むことができました。
何よりも、WASM のコードが動くのがちょっと不思議なような感覚で、楽しくワクワクしていました。
そして正式に Discovery での新サービス発表を目指して開発をすすめることになったのです。
Orbit という名前
Discovery での新サービス発表に向けての開発の佳境に差し掛かった6月上旬、そろそろ新サービスの名称を決める必要が出てきました。私としては思い入れのあるサービスなので、かっこいい名前になるといいなぁと思っていました。
適用できるユースケースが Funk と重複したり一部置き換えたりする部分もありますので、F で始まるサービス名の兄弟ということで Frontier がそのまま採用されるか！？とも思いましたが、同時にリリースする Peek（こちらはコードネームは Shark でした）とともに、どちらかが O、もう片方が P で始まる名前にしようということになりました。
社内での討論と投票の末、勝ち残ったいくつかのアイディアの中から最終的に私が Orbit を選ばせていただきました。
Orbit というのは、軌道という意味です。
SORACOM プラットフォームと IoT デバイスの間を「データ」という星々が姿かたちを変えながら行ったり来たりしている様子を思い浮かべていただけると良いかもしれません。
創業当初みたいなワクワク感
Orbit の開発を通して、ソラコム創業当初、ユーザーコンソールや API や Beam といった今も受け継がれて現役で使われている数々のソフトウェアを開発していたときののワクワクを思い出しました。
Orbit も当時のように少数精鋭のエンジニアでの開発でしたが、腕に覚えのあるエンジニア同士が Slack 上のちょっとした会話で意思疎通しあって数日後、早いときには数時間後には「できたよ」といって機能追加やバグフィックスが行われ、あれよあれよという間にサービスが組み上がっていくあの感覚。
頼まれてもいないのに「こんなの作ってみました」「ドキュメント書いておきました」「テストしてみました」という感じでどこからとも無く現れて貢献していってくれる仲間たち。しかも全部が高品質。みんな忙しいはずなのにすごくありがたかった・・・。
たとえば VS Code の Development container を使った開発環境、これは CRE の kaoru が作ってくれたものですが「お客様にとって WebAssembly は障壁が高い技術だと思うので、その障壁を少しでも下げたかった」というモチベーションで自発的に作ってくれたものです。お客様目線でさすが CRE という感じですね。kaoru はドキュメンテーションもほぼ一手に引き受けてくれました。kaoru がいなければ、「WASM の開発環境は各自準備してください。以上。」というドキュメントしか提供されなかった恐れがあります・・・
こういうサポーティブな仲間たちに囲まれている環境で働くことができることに、心の底から感謝するとともに、ものすごくモチベーションがあがります。（書いてて泣きそうになってきた）
あなたもこんな仲間たちと一緒にソラコムのシステムを作り上げてみませんか！（唐突）
興味のある方はぜひこちらよりご応募ください。
寿司
ひとつ、当時と違うなぁと思ったのは、「お寿司」がなかったことです。創業当初は結合テストが完了したりするとオフィスの近くのお寿司屋さんから出前をとってみんなでお祝いしていました。今はこんな状況でみんなリモートで働いていますので仕方がないですね。
今夜はお寿司の出前をとって家族で食べようかな！
まとめ
ということで、自分語りが長くなってしまいましたが Orbit 開発秘話（？）、楽しんでいただけましたでしょうか。
簡単にまとめると、
- Dog fooding 大事。バイナリパーサーと Funk を自分で実際に使ってみたところから Orbit のようなものの必要性を感じましたので、やはり自分たちの提供しているものを自分たちで実際に使ってみるというのは本当に大事だなぁと思いました。というわけで Orbit も自分でどんどん使っていく所存です。
- 好奇心大事。WebAssembly は自分とは無関係だと思っていたのですが試しに仕様書を開いてみたら Introduction の 1.1、一番最初で衝撃を受けてめちゃめちゃ興味を持ち、その仕様書を読んでいたら居ても立ってもいられなくなって実際に WebAssembly の処理系を書いちゃったりしてたおかげで PoC とかも勘所がわかった感じがするので、何でも試してみる、実際に自分で手を動かしてみるというのは本当に大事だなと思いました。
- 働く仲間大事。ソラコムの仲間たち、本当に最高すぎる！
Orbit は生まれたばかりでまだまだ未熟ですが、どうか、末永く見守ってやってください。
そしてもしよろしければ実際に使ってみて感想やフィードバックをお寄せください。
皆様とともに Orbit を成長させて行くことができたら、望外の幸せです。
日本で、いや、世界で、「WebAssembly のブラウザ外での実用例」としてまっ先に SORACOM Orbit という名前が出てくるようになる日を夢見て。
ogu