ビットキーのインフラアーキテクチャ

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

全体を通して高い可用性を発揮するためにマルチリージョン/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/