概要
2018年後半から群馬県高崎市で稼働している雨量観測点。LTE Cat.1で1分に1回、HTTP POSTで「今の雨量」を投げるだけ・再送なし・状態を持たない素朴な構成です。この夏の花火大会当日、夕方からテレメトリがまだらに欠け始め、20:46にきっかり1分で平常復帰しました。310分中136分（43.9%）が欠測、最長連続欠測は58分。
これが端末故障でもバックエンド障害でもなく回線輻輳であることを、各層の通過数を同じ時間バケットで並べて特定した記録です。人が集まる場所の近くにセルラーIoTを置くエンジニアの参考になれば幸いです。
ポイント解説
1. 「上流から順にログを追わない」― 各層の通過数を横に並べる
「メッセージが来ない」ときに疑う層は4つ（①端末が送っていない ②回線が運べていない ③受け口=API GW/Lambdaが受けられていない ④自分の処理が落としている）。切り分けのコツは、各層の通過数を同じ時間バケットで並べること。今回はサーバ側3層（本番取込Lambda invocation / SNS publish / 並走shadow）を15分粒度で並べました。結果、3層の数字は1:1で一致、Errors/Throttlesは全時間帯0、独自メトリクスDroppedMessagesも0。層3・4は無実で、「到着そのもの」が落ちていたと即断できました。CloudWatchは値0を返さず行自体を返さない点（—=invocation 0）も読み方の勘所です。
2. 欠測の“形”で端末故障と輻輳を見分ける
残る候補は「端末が送っていない」か「回線が運べていない」か。これは欠測の形で判別できます。端末の電源断・故障ならある時刻からきれいに切れ、復旧はばらつく。バックエンド障害ならエラーメトリクスが立つ。回線輻輳は確率的に一部だけ通る＝まだら／混雑が抜けると即復帰。今回は後者に完全一致し、前日・前々日の同時刻が安定だったことから周期現象も否定できました。
3. “取り返しの山”が無い＝再送なし設計が効いた
19:00の小康時も20:46の復帰直後も、流量はちょうど1通/分＝平常値ぴったり。貯めた分の一斉再送（山）が無いことが、端末は投げ続けていて「通る確率」だけが0→100%に戻った、という読みを裏付けます。もし再送設計だったら復帰直後に136分ぶんが殺到し、二次輻輳を招いた可能性があります。「今の値」に意味がある用途では投げっぱなしが素直。逆に積算値・履歴が主役ならジッタ付き段階リトライを検討、という切り分けです。
まとめ
- まだら欠測＋瞬間復帰は輻輳の署名。きれいに切れる＝端末、エラーが立つ＝バックエンド
- 層ごとの通過数を同じ時間軸で並べると「どこで消えたか」が30秒で分かる。アラームは「止まった」しか言えない
- 劣化はイベント時間の約3倍（開演91分前〜終演26分後）に広がる。閾値は平常値の半分が実用的だが、検知は33分遅れた
詳細はTechblogで
5相の到着プロファイル、1分粒度の到達/欠測ヒートマップ、CloudWatchの層別テーブル、アラーム設計の考え方など技術的詳細は当社Techblogをご覧ください。
👉 詳細記事を読む