この記事は、mockmockアドベントカレンダー1日目の記事です。
今回はアドベントカレンダー初日ということで、mockmockの概要を書いてみようと思います。
mockmockとは
mockmockは、一言で言えば、「IoT開発者向け疑似データ送信サービス」です。
仮想デバイス"mock"が、指定したIoTバックエンドに向けて疑似データを送信します。
送信するデータの内容や送信先はコンソール画面から簡単に設定可能です。
IoTのテストデータ調達は難しい
IoTバックエンドは、データが来なければ動作しません。IoTはデータが命！
しかし、動作確認や負荷試験のためにデータを調達しようとするとなかなか難しいのです。
従来は、大きく分けて2つの方法がありました。
- 実デバイスからのデータ調達
- 自作シミュレーターからのデータ調達
実デバイスからのデータ調達
最も素直な方法ですが、物理的なモノが絡むがゆえに問題が出てきます。
使いたいときに使えない場合がある
たとえば、
- 調達中 / 開発中だったり
- 故障してしまったり
- テスト機が少なく、ほかの人が使用中で使えなかったり
テストのたびに操作が必要
デバイス側の操作だけで結構時間を取られたりします。
思い通りのデータを出すのが難しい
特に異常値やエラーデータは大変です。
たとえば温度センサーを使ったIoTシステムで、80度でアラートが来るとして、
それを確認するために実物の温度センサーを80度にするのはかなりの手間です。
エラーデータに至っては、出すためにデバイスを壊すのは非現実的ですし、
そもそも意図的に出せない場合もあります。
大量デバイスでの負荷試験が難しい
大規模なシステムになると、リリース前に負荷試験をしておきたいという需要はあると思いますが、
それを実デバイスで行うのは非現実的です。
負荷をかけられるだけのデバイスの用意がまずできませんし、
用意できたとしても1台ずつセットアップしていくのも大変です。
自作シミュレーターからのデータ調達
実デバイスと同じデータフォーマットを送るシミュレーターを作る方法です。
異常値やエラーデータのテスト、負荷試験に関してはこちらの手段を取ることが多いと思います。
しかし、こちらも問題が。
十分な開発時間が取れない
シミュレーターの開発は開発の本筋ではありません。
それゆえに、優先度が下げられてしまうケースが多々あります。
製品レベルのIoTデバイスのシミュレーターを真面目に作ろうとするとかなりの規模になるため、
しっかりとしたものを作るのは非常に難しいです。
操作が洗練されない
十分な開発期間が取られなければ、UIも洗練されませんし、ドキュメントも作られません。
場合によっては開発した人しか使えないというケースも。
仕様変更時にメンテナンスされない
仕様変更があっても、シミュレーターのメンテナンスにまで手が回らず、
久しぶりに動かすとうまく動かないということもあります。
mockmockによる新たなデータ調達
mockmockという"専用サービス"からデータを調達することで、IoTのテストデータ問題を一気に解決します。
- いつでもすぐに必要なデータが送信可能
- 数千、数万台規模のデータも生成可能
- Webコンソールでテスト内容の共有も簡単
- 仕様変更時のメンテナンスコストが低い
これにより、開発・テストの工数削減や、テストの安定運用が見込めます！
連携サービス・対応プロトコル
2019年12月現在、以下に対応しています。
独自サーバー(=独自に構築したAPIサーバー/MQTTブローカー)や、各種パブリッククラウドのIoTでよく使われるサービス、そしてSORACOMへの送信も対応しています。
SORACOMはとても便利ではあるのですが、
SORACOMのサービスは基本的にAirSIMを挿したデバイスからのデータしか受け付けてくれず、テストが大変です。
しかし、mockmockはAirSIMを挿したデバイスのようにBeam/Funnel/Funkにデータを送ることが可能です！
利用料金
基本的には従量課金です。
同時に立てられるmockの数に対して単価が決まります。詳細はこちら。
また、無料枠もあります。アカウント登録から1年間、mock1台が利用できます。
クレジットカード等の支払情報を登録せずに利用できるので、気軽にお試しできます。
まとめ
個別の機能に関しては、これからのアドベントカレンダーで紹介されていくと思います。
待ちきれない人はひとまずチュートリアルをば！
IoT開発にはもはや障壁なんて無い。キミにはmockmockがある！
明日は@withelmoです。
独自サーバー向けプロジェクトを作るときのポイント、認証まわりについてです！