スマートロックを実現する技術: ビットキーのインフラアーキテクチャ大解剖
顔認証技術等を活用したスマートロックをはじめとしたIoTプロダクトを複数開発するビットキー社では、Google Cloud とAWSを活用したマルチクラウドでインフラを構成しており、またデータベースではFirestoreとAlloyDBを活用しています。 創業以来、適材適所でそれぞれの特徴をとらえながら技術選定をしてきたVPoTの白木さんに、ツール選定のポイントをはじめ、実際に運用段階での苦労や今後の展望について、ご寄稿いただきました。
◆執筆者
白木 孝典(しらき たかのり) @tshiraki_b
株式会社ビットキー VP of Technology
2018年にビットキーの創業メンバーとしてジョインし、ビットキーの提供するサービスの技術選定やアプリケーション開発を牽引。現在はVPoTとして、ソフトウェアからハードウェアまで多岐にわたって活動する。
ビットキーとプロダクト
株式会社ビットキーは、テクノロジーの力であらゆるものを安全で便利に気持ちよく「つなげる」をミッションに掲げ、日々の暮らしや、働く場での「体験の分断」を解消するサービスを提供しているIoTスタートアップです。累計資金調達額は170億円、従業員数は200名を超え、数年以内でのIPOを視野に入れながら、さらなる成長フェーズにあります。
ビットキーが提供するプロダクトは「homehub」「workhub」「exphub」の3事業に分かれています。
1つ目の「homehub」*1 では、暮らしの中でのキーレス化を進めています。賃貸マンションを1棟まるごとスマートアクセス化や、マンションへの置き配普及に向けた実証実験の実施など、よりスマートな暮らしの体験を提供しています。2つ目の「workhub」*2 では、”働く”空間を、スマートロック、デジタル受付、顔認証ソリューション、アクセスコントロール、カメラやIoTセンサを使った分析などの、豊富なプロダクトを用いてアップデートしています。
また「exphub」は、コンサート会場や、ホテル、テーマパークなどの非日常な場において、体験の分断を解消するコネクティングプラットフォームです。現在は構想・実証実験の段階で、今後提供を予定しています。
*1 homehub bitlockの操作・合カギのシェアなど暮らしを便利にする専用アプリ https://www.homehub.site/homehubapp
*2 workhub workhubで実現するスマートオフィス新しい働き方 https://www.workhub.site/
ビットキーが開発・提供するソフトウェア・ハードウェアの例
インフラアーキテクチャと利用技術
ビットキーのアーキテクチャは、モノの管理はAWSを中心に、人や権限などの各種サービスはGoogle Cloudを中心としていくマルチクラウド構造になっています。
ビットキーの創業当初(2018年8月)、Kubernetesで鍵のプラットフォームを構築することと、モバイルファーストで迅速に市場に価値を提供することを重視し、 Google CloudのGKEとFirebaseを選びました。
その後、IoTデバイスの開発が始まりましたが、社内外の知見や資産などの状況を考慮し、リリースのスピードを最優先に考えた結果、AWS IoTを採用しました。
結果として、Google Cloudは主にアプリケーションのフロントエンドおよびバックエンド、データ管理、認証といった全体のコアシステムを中心に、一方のAWSは、IoTデバイスの通信・制御という特化した用途中心としていく分かりやすい構造を見出すことができました。
完全に役割を分離した構造の実現にはまだ至っていませんが、少なくともそこを目指す過程においても、社内の開発チームの責務のスコープを分かりやすく分割できています。
インフラアーキテクチャの解説
以下、ユーザーの解錠操作を例に具体的な流れを解説します。
1. Webアプリからの解錠リクエスト送信
ユーザーがモバイル・タブレットアプリやブラウザで解錠操作を行うと、リクエストがGoogle Cloud 上の Firebase によって認証されます。認証が成功すると、リクエストはCloud Functions や Cloud Run に送られ、バックエンドに伝達されます。
一部Next.jsを利用して開発されたものがあり、それらをVercel上でホスティング・運用しているケースもありますが、基本的にはGoogle Cloudに寄っています。
2. バックエンドでのデバイス特定処理
バックエンドでは、Firestore または AlloyDB に保存されたデバイス情報や権限設定を参照して、ユーザーが操作可能なデバイスを特定します。この際、リクエストに基づくセキュリティチェック(例えば、該当デバイスへのアクセス権限の確認)が実行されます。
3. AWS IoT への通信とデバイス制御
解錠指示は、Google Cloud からAWSの Route 53 を経由して Lambda に渡されます。Lambdaで指令を最適化し、AWS IoT を通じて対象のIoTデバイスにMQTT通信を送信します。このプロセスにより、対象デバイスが解錠の操作を実行します。
4. IoTデバイスからのレスポンス処理
操作完了後、IoTデバイスは結果をAWS IoTに返します。このレスポンスは再び Lambdaを経由してGoogle Cloud に渡されています。
また、IoTデバイスからのレスポンスだけでなく、デバイス内部のフラッシュメモリに保存されているログを吸い出して、プッシュ通知の形でGoogle Cloud側に送信するケースもあります。この場合はAWS IoTを経由せず、直接アプリからデータを取得する構造となっています。
このアーキテクチャ図には載せていませんが、ロギングに関してはGoogle Cloud とAWSの両方からDatadogへ送信しモニタリングをしています。
中継デバイスを設け安全性と省エネを両立
もう少しアーキテクチャ図に関して補足すると、図の左下部にある「Local Device」は、鍵やカードリーダーなどの物理的なデバイスのことで、基本的にはインターネットに接続せず、スタンドアロンで動作します。これは、ネットワーク障害時でも鍵の開閉ができる安全性と、省エネを両立するためです。
また、物理的な操作(例:外側から鍵を回転させる、内側のつまみを回す等)やスマートフォンからBLE通信でモーターを回したログを内部に保存する仕組みを備えています。
一方の「IoT Device」は「Local Device」とインターネットを橋渡しする役割を果たします。「Local Device」で蓄積されたログデータをBLE通信で取得し、それをAWSに送信することで、リアルタイム通知やデバイス状態の遠隔監視といったケースに対応します。例えば、子どもが帰宅した際の通知や電池残量が少なくなった際のアラート送信など、「IoT Device」を介することで、インターネット接続がない状況でもログデータを活用することができます。
AWS IoTで安全で効率的なIoTプロダクト開発に
ビットキーでもデバイス間通信の基盤として活用している「AWS IoT」についても、もう少し詳しく解説します。
本来、IoT自体は、インターネットを介して現実のデバイスを操作する技術全般を指しますが、それを実現するには通信や制御、セキュリティを含む複雑な仕組みを自前で構築する必要があり、非常に高い技術力とコストが求められます。
AWS IoTは、この複雑さを大幅に軽減するために、クラウド側の制御機能やデバイスとの通信インターフェースを一体化した製品群を提供しています。たとえば、クラウド側でデバイスの制御を行う機能や、ファームウェアとの通信を簡素化するツールを備えているので、効率的にIoTシステムを構築できます。また、AWS IoTにはセキュリティ対策も組み込まれており、自前で構築した場合にありがちなセキュリティホールを回避できます。
弊社でも、AWS IoTの特徴を活かしながら、安全かつ効率的な製品開発ができています。
ログデータを活用して物理デバイスのメンテナンスも
ビットキー社では、ハードウェアについてもオフィスに隣接されている工房で自前で開発をしており、新しいバージョンの製品が次々生まれています。一方で古いバージョンのデバイスについても長期的なメンテナンスを行っています。
まず、制御でなんとかできる領域であれば、インターネット経由でバイナリデータを配信し、デバイスを遠隔でアップデートします。
物理的な耐久性や電力消費効率の改善など、ソフトウェアでは対応できない領域については、新しいロットへ順次適応させたり、故障時に積極的に交換対応をしています。
また、ハードウェアの故障を未然に防ぐため、物理デバイスから収集したログデータをBigQueryに蓄積し、分析を行っています。たとえば、モーターの動作状況や消耗傾向を継続的にモニタリングすることで、潜在的に問題が発生しそうなデバイスを特定し、交換が必要なデバイスについては、ユーザーに積極的に交換提案を行い、了承を得た場合に交換対応を実施しています。
Firestore選定の背景と、AlloyDB部分移行の背景
スピード優先の開発から、複雑なデータ管理が求められる環境に
前述した通り、創業当初、ビットキーでは市場投入のスピードを最優先としていました。
特にエンドユーザー向けのアプリケーションは、迅速にリリースする必要がありました。そのため、Firebaseを中心としたサーバーレスアーキテクチャを採用し、Firestoreをデータベースとして採用しました。
FirebaseやFirestoreは、モバイルファーストの開発においては非常に有用だったのですが、事業が成長し、より複雑なデータ管理が求められるようになると、Firestoreのドキュメント指向データベースとしての特性が制約となり始めました。たとえば、建物や部屋の階層的な情報を管理したり、複数の従業員に対してアクセス権限を一括付与するなどのリレーショナルデータを扱う要件が増加しました。これらの要件に対応するには、Firestoreでは非効率であり、設計の複雑さが課題となっていました。
Firestoreを活用し続けることで得られる利便性と、リレーショナルデータ管理への非適合性によるもどかしさが逆転したのが、移行の決断を下した理由です。そして、リレーショナルデータベースとしての柔軟性とパフォーマンスを求めてAlloyDBへの移行を進めることを決定しました。
この移行により、Firestore時代の効率性を維持しつつ、複雑なデータ管理要件にも対応できる基盤を構築し、さらなる成長に向けた足場を整えることができました。
AlloyDB導入から1年を振り返って
前提として、「すべてをAlloyDBに置き換える」といった極端なアプローチは取らず、適材適所のバランスを重視して導入を進めてきました。Firestoreで十分なパフォーマンスを発揮している部分はそのまま活用しつつ、Firestoreでは非効率だった領域に焦点を当て、優先的にAlloyDBへ移行するという方針です。
結果、これまでFirestoreで無理な結合を行っていたところを、AlloyDBではシンプルなクエリで取得できるようになりました。また、コスト面でのメリットもあったと思っています。Firestoreに関しては、ユーザー数やワークロードの増加でコストも増加傾向にあったので、手を打っていなかった場合と比較して、半分以下にはなっているかと思います。一方のAlloyDBは、Firestoreと比較して非常に低コストで運用できています。数十分の1程度には抑えられているのではと思います
移行スピードに関しては、もう少し速く進めたいという思いもありますが、全体の優先度を考慮してスケジュールを組んでいるので、現実的なラインで進められているのではと思います。
現在の課題と今後の展望
現在はまだIoTのためだけにAWSを利用している状態であり、その背景にある業務やそのための管理・制御の大半はGoogle Cloud上にあります。
そのため、IoTの制御に必要な情報もGoogle Cloud上に重複して持つ必要が生まれ、AWSの外から細かく制御・通信するような形となってしまっています。
システム間が密であることにより、本来丸ごと任せられるタスクを適切に移譲することができず、認知負荷の拡大や、通信・インフラの効率低下の要因となってしまっています。
現在、AWS IoT周辺の領域を、Google Cloudの制御に任せるのではなく、もっと主体的にモノを扱う独立したシステムとしていくことを考えています。
それによってGoogle Cloud上にあるシステム群が細かくモノを管理・制御する必要がなくなり、それ以外の重要な対象に集中しやすくなります。
同様にAWS上のシステムも責任範囲がより明確になり、モノの管理と制御に集中しやすくなります。
それぞれのクラウド内に閉じた情報管理とアクセスだけで適切にサービスを提供できるようにすることで、開発、通信、インフラなど多くの観点での最適化と、それによるより快適で安定したサービスの提供を見込んでいます。
お知らせ
最後に、ビットキーではインフラエンジニアを募集しています!
日本全国に数十万台という機器が設置されている中、非常に少人数でIoTデバイス領域を見ているという状況です。また既存のIoTデバイス関連のみならず、アーキテクチャの刷新や新規IoTデバイスの検証やプラットフォーム開発も必要としています。これらのサービスを安定的に、かつ大きく成長させることに一緒に挑戦して頂ける方を募集しています!
少しでも興味をお持ちいただけましたら、ぜひお気軽に求人へご応募ください。お待ちしております!
https://findy-code.io/companies/590/jobs/kXuYoN2sZ7MHP (Findy内のビットキー インフラエンジニア求人ページが開きます)