ビットキーのインフラアーキテクチャ
riddle_tec
ビットキーの各種プロダクトはトビラを制御しています。
普段の我々の生活において、トビラが開いたり閉まったりするのはごく当たり前のことであり、サービス障害など何らかの理由によって、その当たり前が妨げられることがあってはなりません。
その特性上、高い可用性を求めたアーキテクチャを検討する必要がありました。
全体を通して高い可用性を発揮するためにマルチリージョン/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プラットフォームの細かなチューニングについても必要不可欠だと考えています。
riddle_tec予備知識
いろんなことをやっているので短い言葉で語るのは難しいが、ハードウェアやIoTを活用しながら、リアルとデジタルの分断を解消しているとのことd。
気になったこと
1. IoT Core は 複数リージョン構成
Route53 によるバランシング
でも書き込みは片方のリージョンに寄せてる（Global Table)
普段の我々の生活において、トビラが開いたり閉まったりするのはごく当たり前のことであり、サービス障害など何らかの理由によって、その当たり前が妨げられることがあってはなりません。
その特性上、高い可用性を求めたアーキテクチャを検討する必要がありました。
2. 独自TLS証明書の管理
IoT デバイス用の証明書かな？ でも IoT Core 側にもあったような気もするけど。
また独自のCA機関を構築できるPrivate Certificate Authorityを組み合わせることにより、どのリージョンやクライアントであろうと問題なく信頼関係が成り立ちます。
3. Lambda が IoT Core にヘルスチェックしてる
さらにLambdaを組み合わせたL7レベルのヘルスチェックにより、IoTレイヤーの確実な死活監視も行っています。
4. Active case と Passive case とはなに？
あーこれもしかして IoT からのセンサーデータ駆動なのか、それともクラウドから IoT デバイスに命令飛ばすかの違いってことか。
この辺はわからないけどそういう ECS があるのかな？
そしてそれをなげると
riddle_tec古くから様々なI/O処理などで用いられるReactor Patternをインフラおよびソフトウェア両方のアーキテクチャとして適用し、無駄な待ちを減らした非同期処理を実現しています。
ノンブロックIO的な話だ。
riddle_tec
ビットキーのアーキテクチャは、モノの管理はAWSを中心に、人や権限などの各種サービスはGoogle Cloudを中心としていくマルチクラウド構造になっています。
Google の IoT 消えたもんね・・
riddle_tec以下引用
-
Webアプリからの解錠リクエスト送信
ユーザーがモバイル・タブレットアプリやブラウザで解錠操作を行うと、リクエストがGoogle Cloud 上の Firebase によって認証されます。認証が成功すると、リクエストはCloud Functions や Cloud Run に送られ、バックエンドに伝達されます。
一部Next.jsを利用して開発されたものがあり、それらをVercel上でホスティング・運用しているケースもありますが、基本的にはGoogle Cloudに寄っています。 -
バックエンドでのデバイス特定処理
バックエンドでは、Firestore または AlloyDB に保存されたデバイス情報や権限設定を参照して、ユーザーが操作可能なデバイスを特定します。この際、リクエストに基づくセキュリティチェック（例えば、該当デバイスへのアクセス権限の確認）が実行されます。 -
AWS IoT への通信とデバイス制御
解錠指示は、Google Cloud からAWSの Route 53 を経由して Lambda に渡されます。Lambdaで指令を最適化し、AWS IoT を通じて対象のIoTデバイスにMQTT通信を送信します。このプロセスにより、対象デバイスが解錠の操作を実行します。
４. IoTデバイスからのレスポンス処理
操作完了後、IoTデバイスは結果をAWS IoTに返します。このレスポンスは再び Lambdaを経由してGoogle Cloud に渡されています。
また、IoTデバイスからのレスポンスだけでなく、デバイス内部のフラッシュメモリに保存されているログを吸い出して、プッシュ通知の形でGoogle Cloud側に送信するケースもあります。この場合はAWS IoTを経由せず、直接アプリからデータを取得する構造となっています。
ここまで引用
おー。めっちゃ複雑。
認証が Firebase でそのあと Google Cloud 経由で認可して AWS IoT Core からの MQTT で解錠か。レイテンシーめっちゃかかりそうだけど、解錠までどれぐらいかかるんだろう？
肌感覚では数秒はかかりそうだけど。
riddle_tec
動画見た限り結構早い。
riddle_tec
60~70名ぐらいのエンジニアか。
とはいえ、ハードとソフトでそれぞれいるだろうからWeb領域はもっと少ない。
ただテックブログが3つあって更新もされているので情報発信力が強い。