IoTサービスのアーキテクチャ特集　技術選定のポイントと今後の展望

株式会社ビットキー

会員限定コンテンツ無料登録してアーキテクチャを見る
会員限定コンテンツ無料登録してアーキテクチャを見る

アーキテクチャ選択の背景や意図

ビットキーの各種プロダクトはトビラを制御しています。
普段の我々の生活において、トビラが開いたり閉まったりするのはごく当たり前のことであり、サービス障害など何らかの理由によって、その当たり前が妨げられることがあってはなりません。
その特性上、高い可用性を求めたアーキテクチャを検討する必要がありました。

全体を通して高い可用性を発揮するためにマルチリージョン/AZを前提とした構成としています。
まずRoute53のGeoproximity Routingによってクライアントは常に最も近いリージョンに接続できるようにしており、Failover Routingの併用により接続中のリージョンで障害が発生しても別リージョンにてサービス継続が可能となっています。
また独自のCA機関を構築できるPrivate Certificate Authorityを組み合わせることにより、どのリージョンやクライアントであろうと問題なく信頼関係が成り立ちます。
さらにLambdaを組み合わせたL7レベルのヘルスチェックにより、IoTレイヤーの確実な死活監視も行っています。

ComputingについてはECS ベースで構築しています。
プロダクトの性質上リアルタイムかつ双方向な通信が求められる一方で、実環境のNWに左右され不安定かつ長大なNW I/O待ちの発生が懸念されます。
これを愚直に実装してしまうと、その待ちによりクラウドコストやパフォーマンスに非常に悪影響となります。
ここについては、古くから様々なI/O処理などで用いられるReactor Patternをインフラおよびソフトウェア両方のアーキテクチャとして適用し、無駄な待ちを減らした非同期処理を実現しています。
結果として、トビラを開け閉めするというお客様の当たり前を確実に支えつつも、高いパフォーマンスとクラウドコストの低減を実現させています。

現在の課題と今後の改善予定

現在IoTプロダクトからの大量のトラフィックから生成されたデータが溜め込まれています。
これらは宝の山だと考えているのですがまだ有効活用できていないため、今後はSageMakerやBedrockを組み合わせたML/AI活用にて新たな価値を創出していきたいと考えています。
また別の課題として、先述の通り高い可用性とパフォーマンスを両立させるべく構築されたアーキテクチャですが、それを高いレベルで担保し続けるためにもオブザーバビリティの向上が必要だと考えています。
ここでは強く言及していませんが、弊社はマルチクラウドな構成となっており、マネタイズの根幹のプロダクトはGoogle Cloudにて実装されています。
それらのプラットフォームおよびソフトウェアやハードウェアも横断したオブザーバビリティの向上は今後についても課題の1つです。
また、そういったビジネスの特性上、インシデント発生時の対応難易度も非常に高いため、インシデントレスポンスの簡易化や高速化のためにも中間に位置するIoTプラットフォームの細かなチューニングについても必要不可欠だと考えています。

◆執筆：IoT Platform / R&D テックリード　佐々木 了 @gzock
【サービス公式サイト】
https://www.bitlock.jp/

【株式会社ビットキーのエンジニア求人】
【NEXTユニコーン選抜/累計資金調達170億】人の暮らしを変えるスタートアップ企業でインフラエンジニア募集！　等
https://findy-code.io/companies/590/jobs

セーフィー株式会社

会員限定コンテンツ無料登録してアーキテクチャを見る

アーキテクチャ選択の背景や意図

本サービスのアーキテクチャは、急速な成長と大規模な需要に対応するために慎重に設計されました。約26万台以上のカメラが接続される規模のサービスにおいて、システムの安定性と拡張性が最重要課題でした。そこで採用されたのが、水平分割（シャーディング）という手法です。

この手法では、約13,000台のカメラごとに独立したインフラ構成（「ゾーン」と呼ばれる）を構築しています。各ゾーンには専用のネットワーク、データベース、 Redis キャッシュ、そしてサーバ群が含まれます。この方式により、サービスの成長に合わせて柔軟にゾーンを追加できる拡張性と、各ゾーン内での負荷分散による高い安定性を実現しています。

さらに、この構成はサービスの段階的な拡大を可能にし、需要に応じて効率的にリソースを追加できる利点があります。結果として、ユーザーに高品質なサービスを途切れることなく提供し続けることが可能となりました。

現在の課題と今後の改善予定

現在のアーキテクチャは高い拡張性を持つ一方で、ゾーンの数が増加するにつれて新たな課題が浮上しています。主な問題は、多数のゾーンのメンテナンスと管理の複雑さです。各ゾーンが独立した構成を持つため、システム更新やトラブルシューティングに要する時間と労力が増大し、運用効率の低下を招いています。

この課題に対処するため、今後は NewSQL データベース技術の導入を検討しています。具体的には、 TiDB や Aurora Limitless Database などの採用を予定しています。これらの技術は、大規模なデータ処理と高い拡張性を両立しつつ、より統合的な管理を可能にします。

この移行により、現在の水平分割構造を維持しながら、ゾーン間のデータ統合や管理の簡素化が期待できます。結果として、システム全体の運用効率が向上し、さらなるサービスの成長と品質向上につながると考えています。同時に、この新技術の導入はシステムの柔軟性を高め、将来の技術革新やサービス拡張にも迅速に対応できる基盤となることを期待しています。


【サービス公式サイト】
https://safie.jp/

【セーフィー株式会社のエンジニア求人】
課金カメラ台数26万台突破！成長を続ける「Safie」のベースとなるシステムの構築を担うシニアバックエンドエンジニア・リーダー候補を募集〈フルリモートOK/裁量労働制〉 等
https://findy-code.io/companies/683/jobs

株式会社ソラコム

会員限定コンテンツ無料登録してアーキテクチャを見る

アーキテクチャ選択の背景や意図

ソラコムは、世界180以上の国や地域で使えるIoT 通信プラットフォームを提供しています。創業当初からグローバル展開を目指しており、AWS をベースに設計しています。グローバルへの展開には世界のさまざまな通信キャリアとの接続が必要ですが、世界の主要国にリージョンを持つAWS 上で稼働しているため、非常に迅速にグローバル展開を行うことができます。

SORACOM の通信インフラは、パケット転送や帯域制御などの通信を司る『Polaris』と、セッション管理や認証、課金などのバックエンド処理を行う『Dipper』で構成されています。またこれらサービス群は監視システムの『Hubble』で監視し、異常時には自動復旧を行う運用としています。
特徴的なのは、通信部分を司るPolaris をステートレスになるよう設計し、障害発生時のフェイルオーバーを容易にしている点です。またステートを管理するDipper のデータストアには Amazon DynamoDB を利用しており、高い冗長性/堅牢性と低運用コストのメリットを享受しています。 SORACOM のシステムは自社のエンジニアで設計・実装・運用を行っており、IT の新しいサービスや技術を取り込みながら、通信レイヤーとアプリケーションレイヤーにまたがったユニークなサービスの開発を、迅速に行うことを可能にしています。

現在の課題と今後の改善予定

SORACOM を大規模に利用されるお客様も増加しており、新しい機能追加やサービス開発を行いながら、安定して使っていただける取り組みを進める必要があります。向こう数年で現在の回線数が2 倍から3 倍になることを見据えて、アーキテクチャレベル/各コンポーネントレベルでの改善を進めています。2024 年7 月に SOC2 Type1 レポートを受領しましたが、Type2 レポート受領のため、開発運用の効率化や自動化をより推し進める取り組みを行っています。

また、ローコードIoT アプリケーションビルダー「 SORACOM Flux」など、生成AI を使ったいくつかのサービスをお客様向けに提供をしていますが、生成AI はプラットフォーム運用の効率化や自動化にも活用できる可能性があるため、社内での調査やPoC を行っています。

◆執筆：株式会社ソラコム　上級執行役員 Chief Engineering Officer　片山 暁雄
X:@c9katayama, GitHub : @c9katayama

【サービス公式サイト】
・公式サイト
・ソラコムのIoTストア

【株式会社ソラコムのエンジニア求人】
【Backend Engineer】世界中にある600万の IoT デバイスが利用するプラットフォームを支えませんか　等
https://findy-code.io/companies/1814/jobs

Nature株式会社

会員限定コンテンツ無料登録してアーキテクチャを見る

Natureでは、自宅にある家電のスマート操作を可能にするIoTプロダクト「Nature Remo」とエネマネHEMSプロダクト「Nature Remo E」の開発・製造・販売などを行っています。販売台数も70万台を突破し、インフラに求められる信頼性も上がってきていると感じています。

アーキテクチャ選択の背景や意図

IoTプロダクトなのでエッジデバイス(Nature Remo)が存在するというところが通常のWebサービスとは大きく違うところです。が、Nature Remoはセンサ、赤外線信号送受信、各種ローカル通信などのみを担い、ロジックはバックエンドに寄せるようにしています。これにより一般的なWebサービスと比べてバックエンドの使用技術や機能追加の頻度もそこまで変わらなかったりします。

特殊な部分として、それぞれのNature Remoはセンサデータのアップロードや赤外線コマンド送信など双方向にサーバーとの通信を頻繁に行うため、WebSocketサーバー(Stream)に常時接続しています。このStreamはAPIとは別で建ててロジックを持たないようにしておくことで、Nature Remoとの接続状況を気にすることなくAPIをデプロイできるような構成にしています。

Nature Remoには時刻などをトリガに家電を自動で操作できるオートメーションという機能がありますが、こちらはSQSと自前のJob Workerを利用して実現しています。オートメーションのトリガ判定は時刻、センサ値、ジオフェンスなどのインプットに対してさまざまなタイミングで実施し、トリガ判定が満たされた場合各プロセスはSQSにイベントをenqueueします。Workerは各イベントをdequeueし、家電操作などのアクション実行を行うという流れになっています。

現在の課題と今後の改善予定

Nature Remoを使うすべての操作はバックエンドを経由するため、バックエンドが障害などで使用不能になるとNature Remoによる家電操作が不可能になってしまうという課題があります。これについてはアプリとNature Remoのみで操作としては完結させ、操作履歴を別途バックエンドへ送信するといった対応で改善することを検討しています。

またオートメーションについては、特定の時刻で大量のオートメーションが同時に実行されMySQLが高負荷になってしまうという事象も発生しています。SQS x Workerの構成はシンプルで良いのですが、オートメーション1件についてWorkerのGoroutineが1つ走るため、各々のプロセスからのMySQLアクセスが同時に大量発生してしまうというのが原因です。MySQLからワークロードに適した別のデータストアに移行したり、Workerでのプロセスあたりのイベント処理数を増やしたりと言った対応をしていく予定です。

◆執筆：的場 一将 X:@bamato_t, GitHub : @goro9

【サービス公式サイト】
・公式サイト
・Nature Remoシリーズ 製品ページ

【Nature株式会社のエンジニア求人】
【再生エネルギー100%の世界を実現】ハーバードMBA出身の創業者が立ち上げたベンチャーで、IoTデバイスのファームウェアエンジニアを募集〈リモート/フレックスタイム/副業OK〉　等
https://findy-code.io/companies/368/jobs

SEQSENSE株式会社

会員限定コンテンツ無料登録してアーキテクチャを見る
SEQSENSE株式会社は自律移動ロボットを利用した警備サービスをメインに開発、運営しています。
人口減少社会を技術で支え安全で便利な生活を続けられるよう維持する「世界を変えない」というミッションのもと、人手不足、高齢化が進む警備業界をロボットによる省力化で支えようとしています。
当社ではロボットのハードウェアからロボット上で動くソフトウェア、そしてロボットを制御するためのクラウドシステムまでのすべてを自社開発しています。 今回はクラウドシステムのアーキテクチャについてご紹介します。

アーキテクチャ選択の背景や意図

ロボットを制御するクラウドシステムとはどういうものか簡単に説明します。
ロボットを操作するためには「地点Aまで移動せよ」とか「充電のために帰還せよ」といったコマンドをロボットに送信します。その際、ロボットの周囲の様子を知るためにロボットに搭載したカメラの映像もリアルタイムに視聴できます。このようなカメラ映像を見ながら操作できるWebアプリケーションを警備室にいる警備員が操作して警備業務を行います。またロボットの位置情報など各種情報が随時クラウドシステムに送られてきます。
警備ロボットサービスのクラウドシステムはこのような仕組みをAWSの各種サービスを活用して実現しています。
クラウドシステムの主な構成要素として次が挙げられます。

• コマンドを送信したりロボットからの各種情報を受け取る相互通信
  
• 映像の保存や配信の機能
  

ロボットとの相互通信には AWS IoT を利用しています。クラウドシステムは主に Go で実装していますがロボットはそうではありません。異なる言語間でもIF定義を共有して通信するためにgRPCを採用しています。AWS IoT のプロトコルは MQTTのため、実際には gRPC over MQTT (HTTP/2の代わりにトランスポートプロトコルとしてMQTTを使用する)ということになります。
一方、映像の録画には AWS Kinesis Video Stream を利用しています。ロボットから SRTP でビデオストリームを受け、録画しつつリアルタイムの配信も行っています。

現在の課題と今後の改善予定

警備ロボット事業は着実に導入件数を増やしてきており、市場として成長しつつあると感じています。 それに伴い求められるユースケースが増えてきています。しばらくはこれらに対応するための開発が続くと思います。
また、警備ロボットで培った自律走行技術を活用して屋内配送ロボットサービスの開発も進めています。例えば警備では決まった時間に決まったルートを巡回することが多いのに対し、配送では定期的な配送もあるのですが、随時に任意の場所への配送が求められるなどユースケースが異なります。開発当初は警備サービスと同じAPIでロボットを操作していましたが、配送サービスに適したAPIを開発し移行を進めています。
いずれも新しい市場を作りながらの事業であるため試行錯誤しながら開発を進めているところです。それ故、サービス分野ごとに変わる部分と共通の部分の整理などサーバのリプレースや分割などを行い、必要に応じてアーキテクチャも見直す必要が出てくると考えています。

◆執筆：クラウドチーム バックエンドエンジニア　森下 泰光　GitHub : @HeRoMo

【サービス公式サイト】
公式サイト

【SEQSENSE株式会社】
【Go/gRPC】ロボティクスで新マーケットを築き、高齢化や生産人口減などの社会問題を解決するバックエンドエンジニア募集　等
https://findy-code.io/companies/372/jobs