デプロイに45時間！ 成長に伴うシステム肥大化にどう立ち向かう？
ここからはメインテーマとなる事業の成長に伴う技術負債解消や継続的改善について見ていこう。今でこそ約20万台のカメラが稼働しているものの、2015年から4〜5年間は忍耐の時代だった。森本氏は「暗黒時代」と呼び、「カメラが売れず、エンジニアはほとんどいませんでした。そこですべての開発や保守運用をしていました」と振り返る。
しかしその暗黒時代に蒔いた種が2019年ごろから開花しはじめた。根気強くプロダクトを増やし、パートナーを増やすことも続けたことにより、徐々に勢いが加速しはじめて、2021年の上場で急成長して現在に至る。
急速に成長したため、いくつかの課題にも直面した。まずエンジニア数が急速に増加したことにより、新しいエンジニアが素早くキャッチアップする仕組みや、分担して効率良く開発する仕組みが必要となった。
カメラ台数が増加し、システムが肥大化したことで、規模に合う耐久性も必要になった。現在は約20万台だが、将来を見越して100万台規模を想定したシステムを構築する必要があり、かつ運用保守と同時に新規開発も実行できる体制を整える必要がある。またパートナーや顧客層も増加・変化したことで、高いサービス品質を維持し、障害を最小限に抑え、迅速に対応できるようにする必要もあった。さらに業界ごとのソリューション提供にも取り組んでいく必要がある。
これらの広範な課題をどのように解決したのだろうか。まずカメラ台数増加・システム肥大化については、データベースが大量のアクセスに耐えられないことや、障害発生時には影響範囲が広くなることが課題になっていた。そこで「Zone」で区切る分散管理システムを導入し、数万台のカメラごとにZoneを定義。負荷分散や障害の局所化を実現した。するとZoneで切り出せるようになったため、別システムとのハイブリッド環境を構築できるという副次的な効果も生まれた。
もう1つ、システム肥大化に伴う課題として、接続品質向上のために独自の負荷分散やスケーリングを考慮する必要があった。サーバーは常に録画のための処理を行っているので、保守で止めるわけにはいかない。これについては、サーバーからカメラに再接続を指示したり、APIで手動スケールアウトさせたり、独自のデプロイ手法で乗り切ってきた。しかし台数が増えるにつれ、最終的にはデプロイに45時間もかかってしまうようになってしまった。そうなると「危ないから触るのをやめよう」と機能追加を忌避したくなるような状況に追い込まれた。
そこでデプロイは周辺システムごと作り直し、CodeDeployによるCI/CDに移行した。EC2 Auto Scalingへの移行や、CodeDeployのスクリプトから独自の負荷分散を制御するなどした。この一連の仕組みによりデプロイは2〜3時間で完了するほど劇的に改善した。デプロイ頻度も1日に2.6回に高まった。
ビジネス成長に伴い、重要な顧客やパートナーも増えてきて、サービス品質を向上させる必要も出てきた。当初はサービス提供速度やコストを優先し、オープンソースのWebRTC SFUを採用していたものの、配信サーバーとは別の専用インスタンスが必要で、まれにCPUが上限に張り付き品質に影響が出るなどの課題があった。これを配信サーバーのリファクタリングを行い、WebRTC SFUを配信サーバーに取り込むことで管理面や配信品質が向上し、専用インスタンスが不要となったためコストダウンも実現した。
