10万台のIoT端末が動いているシステムを、途中から引き継いだ話

以前、IoTサービスの保守開発案件に参加したことがある。

IoT端末10万台以上を、リアルタイムで監視する大規模システムである。

ただし、ゼロから作る案件ではない。

すでに動いているシステムを、別のベンダーから引き継ぐ案件だった。

いわゆる「ベンダーチェンジ」である。

今日はその話をしたい。

ベンダーチェンジという名の考古学

ベンダーチェンジと聞くと、引っ越しのようなものを想像するかもしれない。

前の業者から鍵を受け取って、あとは住むだけ。

実際は違う。

動いている飛行機のエンジンを、飛行中に別の整備チームが引き継ぐ、に近い。

システムは止められない。

10万台の端末は、こちらの都合などお構いなしに、今日もデータを送り続けている。

その裏側で、私たちは調査を始めた。

ソースコードを読む。

AWSの設定を読む。

ログを読む。

そして一番重要な作業がこれである。

「なぜ、こうなっているのか」を推理する。

コードには「何をしているか」は書いてある。

しかし「なぜそうしたのか」は書いていない。

一見不可解な実装が、実は過去の障害対応の傷跡だったりする。

うかつに「きれいに直そう」とすると、当時の障害が再発する。

だから引き継ぎ調査は、コードリーディングというより考古学に近い。

遺跡を掘りながら、当時の人々の暮らしを想像する仕事である。

サーバレスとサーバ、両方入っていた

このシステムには、もう一つ特徴があった。

構成が2階建てだったのである。

端末からのデータを受けるのは、AWS IoT CoreとLambda、Golangによるサーバレス構成。

管理画面やAPIは、ECS上のLaravel。

つまり、サーバレスとコンテナ、GolangとPHP、両方が同居していた。

設計としては、実は理にかなっている。

大量の端末データを受ける部分は、スパイクに強いサーバレスで。

複雑な業務ロジックは、慣れたフレームワークで。

それぞれ適材適所である。

ただし、引き継ぐ側には一つ問題がある。

両方できる人が必要になる。

サーバレスだけ詳しい人でも、Laravelだけ詳しい人でも、全体像がつかめない。

私がこの案件に呼ばれたのは、たぶんそれが理由である。

専門性というより、雑食性が求められる現場だった。

10万台の「ちりつも」

この案件で一番勉強になったのは、スケールの感覚である。

端末1台の通信など、たかが知れている。

数分に1回、小さなデータを送るだけ。

しかし10万台集まると、話が変わる。

毎秒数百リクエストが、24時間365日、途切れることなく降ってくる。

人間のアクセスと違って、夜も減らない。

セールで増えることもないが、休んでもくれない。

そして怖いのは、端末は「一斉に」動くことがある、という点だ。

たとえば、ネットワーク障害からの復旧直後。

沈黙していた端末たちが、一斉に再接続してくる。

平常時の何倍ものリクエストが、同じ数分間に集中する。

この「復旧後の津波」を捌けないと、システムは復旧したのに自分が倒れる、という間抜けな事態になる。

オートスケールの設定ひとつとっても、平常時ではなく、この津波を基準に考える必要がある。

大規模IoTの負荷対策は、平均値ではなく最悪値との勝負だった。

引き継げるシステムと、引き継げないシステム

この案件を通じて、考えるようになったことがある。

システムには「引き継ぎやすさ」という品質がある、ということだ。

性能でも機能でもない。

他人が後から読んで、理解できるか。

インフラがコード化されているか。

設定が環境に手作業で入っていないか。

「なぜ」がどこかに残されているか。

動いている間、この品質は誰の目にも見えない。

見えるのは、ベンダーチェンジや担当者の退職といった「その日」が来たときだけである。

そして「その日」は、たいていのシステムに、いつか来る。

私は今でもシステムを作るとき、頭の片隅でこう考える。

このシステムをいつか引き継ぐ、まだ見ぬ誰かのために、遺跡ではなく地図を残そう、と。

30年この仕事をやっていると、作る仕事と同じくらい、引き継ぐ仕事が回ってくる。

そして引き継ぎの現場を知っている人間が作るシステムは、少しだけ優しくなる。

もしあなたの会社に、「作った人がもういないシステム」が動いているなら。

それを引き継ぐ仕事、わりと得意です。