Share
Embed
Slide 1
Slide 1 text
クラウドからエッジまで
~ 1,700台を支える監視設計 ~
クラウドネイティブ会議 2026-5/14 ~ 15 (Wed ~ Fri) @ 中日ホール
株式会社Opt Fit 西 和弥
murasame 上田 昂明
Slide 2
Slide 2 text
自己紹介
Komei Ueda
SRE・基盤改善担当
Kazuya Nishi
エンジニア
Slide 3
Slide 3 text
Opt Fitは名古屋の会社です
Slide 4
Slide 4 text
IPカメラによる映像配信と AI解析サービス
Opt Fitのプロダクト
Slide 5
Slide 5 text
IPカメラによる映像配信と AI解析サービス
Opt Fitのプロダクト
Slide 6
Slide 6 text
クラウド × エッジ構成
複数の実行環境で補い合う設計
エッジデバイス
- 低コスト/低レイテンシ/限られたリソース
- 一部の処理で活用
クラウド
- スケーラブル/耐障害性
Slide 7
Slide 7 text
エッジデバイスの特徴
冷たくなっている ....
いいこと
- ローカル処理 → データドロップが少ない
- ネットワーク非依存 → 安定動作
- クラウド送信削減 → 低コスト録画
わるいこと
- CPU / メモリ逼迫 → 現場で停止
- 障害対応 → 停止すると現地交換が必要（高コスト）
- 多様な設置環境 → 停電やネットワーク不安定リスク
Slide 8
Slide 8 text
私たちのこれまでの監視と課題
Slide 9
Slide 9 text
従来の監視アーキテクチャ
Slackの知らせを見て障害対応をしていた。
Slide 10
Slide 10 text
従来の監視アーキテクチャ
Slackの知らせを見て障害対応をしていた。
Slide 11
Slide 11 text
当時の監視の実態
監視ではなく、人力調査の入口のみ
- 10分おきにSlack通知
- 問題がなくても通知 (🔇ミュート懸念🔕)
- 大雑把な異常通知
- コンポーネントにエラーあり
- 接続不良あり
結果
- ログで解決しなければSSHして原因調査
- デバイス停止してから通知ではリカバリコスト高い
Slide 12
Slide 12 text
人間プル型運用の限界
Slide 13
Slide 13 text
当時の運用の実態
- 障害にすぐ気づけない
- 担当者は常に気張る必要がある
- 対応までに時間がかかる
- 一度に大量デバイス障害に耐えられない
Slide 14
Slide 14 text
当時の運用の実態
- 通知を見て人が判断
- 休日/深夜は対応は苦しい
- 映像監視員による 24/365 オンコール
- 過去CTOは一晩3回が3週間続いた
- リリースにも及び腰
一周回ってハイになった
CTO
Slide 15
Slide 15 text
1,700台規模になると、運用は “設計問題”になる
問題が起きたら人がリカバリしに行く運用は、スケールしない
問題はさまざま
- 特定エッジデバイス固有の問題
- 設置環境固有の問題
- 全国分散
- 停電
- ネットワーク品質
結果
- 数十台 → なんとか回る
- 数百台 → 運用がつらい
- 1,700台 → 完全に破綻
Slide 16
Slide 16 text
クラウド↔エッジデバイスでの分断
共通の“状態の見方 ”がなかった
- エッジ / クラウドで開発者が異なる
- 監視方法・判断基準がバラバラ
- 同じ障害でも見え方が違う
結果
- 認識ズレ
- 調査の往復
- 対応が遅れる
- エッジ固有の問題かどうかの切り分けが困難
Slide 17
Slide 17 text
従来監視の課題まとめ
- 10分起きのSlack通知の限界
- 毎回のSSH対応の限界
- デバイス数増加で毎回の原因調査と回復作業の限界
- クラウド↔エッジでシステム状態把握の方法がバラバラ
結果
エッジデバイスの運用が安定せずをコスト削減効果が不十分だった。
Slide 18
Slide 18 text
方向性は通知ではなく “観測”
人が見に行く監視から、状態が見える監視へ
- SSHしなくても状態がわかる
- エッジ / クラウド横断で見える
- 共通の指標で判断できる
- 品質低下の兆候を検知
向かうべき方向
- 既知の問題は対応を自動化
- 対応必要な問題のみ通知
Slide 19
Slide 19 text
Slackの“監視”からシステムの “観測”へ
Slide 20
Slide 20 text
新しいエッジデバイスの監視アーキテクチャ
Slide 21
Slide 21 text
どうしてNew Relicなのか？
機能面
- カスタムイベントが集約できること
- テレメトリデータすべてが共通のI/Fを持っていたこと
- Flex Integrationなどのカスタム監視が容易に実装できること
Slide 22
Slide 22 text
どうしてNew Relicなのか？
機能面
- カスタムイベントが集約できること
- テレメトリデータすべてが共通のI/Fを持っていたこと
- Flex Integrationなどのカスタム監視が容易に実装できること
コスト面
- 機能を小さく試していくことができること
- ホストやサービスがスケールしてもコスト爆発しづらい
- 機能を制限せずにコストのコントロールができること
- 開発/運用チームが少数精鋭のためユーザ課金でも問題にならなかった。
Slide 23
Slide 23 text
新しい設計で変わったこと
SSH しなくても CPU, Memory, Disk, Networkなどの標準的な監視を実現した
- Signal Lostから通信状況やデバイスの状態の悪いテナントがわかるようになった。
まだ温かい ...南無...🙏
Slide 24
Slide 24 text
新しい設計で変わったこと
SSH しなくても CPU, Memory, Disk, Networkなどの標準的な監視を実現した
- Signal Lostから通信状況やデバイスの状態の悪いテナントがわかるようになった。
- Diskの空き容量がなくなりSSHできなくなった救えないデバイスがなくなった。
瀕死のデバイス発見ｶﾞｵ !!
(ﾏﾀﾞｲｷｶﾞｱﾙ !!!)
Slide 25
Slide 25 text
新しい設計で変わったこと
新機能リリース
します!!!!!!
SSH しなくても CPU, Memory, Disk, Networkなどの標準的な監視を実現した
- Signal Lostから通信状況やデバイスの状態の悪いテナントがわかるようになった。
- Diskの空き容量がなくなりSSHできなくなった救えないデバイスがなくなった。
- リリース前検証を安心して行えるようになった
Slide 26
Slide 26 text
新しい設計で変わったこと
新機能リリース
します!!!!!!
SSH しなくても CPU, Memory, Disk, Networkなどの標準的な監視を実現した
- SignalLostから通信状況やデバイスの状態の悪いテナントがわかるようになった。
- Diskの空き容量がなくなりSSHできなくなった救えないデバイスがなくなった。
- リリース前検証を安心して行えるようになった
Slide 27
Slide 27 text
新しい設計で変わったこと
ちょっ
と待て
い!
新機能リリース
します!!!!!!
SSH しなくても CPU, Memory, Disk, Networkなどの標準的な監視を実現した
- SignalLostから通信状況やデバイスの状態の悪いテナントがわかるようになった。
- Diskの空き容量がなくなりSSHできなくなった救えないデバイスがなくなった。
- リリース前検証を安心して行えるようになった
Slide 28
Slide 28 text
“共通言語”をメトリクスへ
ドメインに直結するイベントの観測
- 録画データの生成率
- 録画やその周辺のコンポーネントの状態
- FFmpegの終了イベント
Slide 29
Slide 29 text
“共通言語”をメトリクスへ
ドメインに直結するイベントの観測
- 録画データの生成率
- 録画やその周辺のコンポーネントの状態
- FFmpegの終了イベント
ドメインに直結するイベントの観測
- 運用担当者が容易に録画状況がわかるようになった
- 不要なセッションストリームに気づけるようになった
- 録画データという品質に直結する
- アラートで判断することができるようになった
Slide 30
Slide 30 text
夜間対応を減らすという設計へ
Slide 31
Slide 31 text
完璧な原因分析に頼らない
今まででは問題のあるデバイスに対し SSHをして原因調査を行ってから対処していた
- 何が原因なのか？
- Noisy Neighbor ? Network issue? camera issue?
- 人手の対応は 大規模障害にはつらい (スケールもしない)
- 神スクリプトを作る始末...
ログなどのテレメトリデータがNew Relicで分析できるようになった今、
原因調査や対応を自動化することにできた。
Slide 32
Slide 32 text
映像録画の自動切替
なぜ、自動化できたか？
> エッジ から クラウド へ録画を切り替える際の条件を監視できたから
Slide 33
Slide 33 text
映像録画の自動切替
なぜ、自動化できたか？
> エッジ から クラウド へ録画を切り替える際の条件を監視できたから
1. 録画データの生成率をカメラ単位で計測できている
2. 録画関連コンポーネントの死活監視ができている
3. New Relic Agentがイベントを常にプッシュしている
Slide 34
Slide 34 text
映像録画の自動切替
なぜ、自動化できたか？
> エッジ から クラウド へ録画を切り替える際の条件を監視できたから
1. 録画データの生成率をカメラ単位で計測できている
2. 録画関連コンポーネントの死活監視ができている
3. New Relic Agentがイベントを常にプッシュしている
原因の切り分けが機械的にできるようになったため、
人手の判断を挟む必要がなくなった。
Slide 35
Slide 35 text
新しいエッジでデバイスの監視アーキテクチャ
① 録画コンポーネントに異常発生
!!
② アラート発火
③ アラートの通知
④自動切換えの実行
Slide 36
Slide 36 text
自動復旧によって変わった
> 深夜 3時に特定テナントのデバイスが死亡 ...
Slide 37
Slide 37 text
自動復旧によって変わった
> 深夜 3時に特定テナントのデバイスが死亡 ...
Before :
- エンジニアが朝3時にたたき起こされる
- Slackを確認 → 死亡を発見
- AWS コンソールから調査を開始、セキュアトンネルで SSHを行って実際のデバイスの状態を確認
- 手動でクラウド録画に移行
- (クラウドでも録画できない場合は手動で顧客連絡
)
Slide 38
Slide 38 text
自動復旧によって変わった
> 深夜 3時に特定テナントのデバイスが死亡 ...
After :
- アラート 発火 → 切り替え自動実行
- (クラウドでも録画できない場合は自動で顧客連絡
)
Before :
- エンジニアが朝3時にたたき起こされる
- Slackを確認 → 死亡を発見
- AWS コンソールから調査を開始、セキュアトンネルで SSHを行って実際のデバイスの状態を確認
- 手動でクラウド録画に移行
- (クラウドでも録画できない場合は手動で顧客連絡
)
Slide 39
Slide 39 text
システム観測から開発運用が変わった
Before After
通知数 20 万件 ~ / 月 ~ 300件 / 月
MTTD (Mean Time To Detect ) ~ 12時間 ~ 5分
MTTC (Mean Time To Clue) ※ 20分 ~ 1時間 (すべて手動) ~ 10分
※ https://www.splunk.com/ja_jp/blog/devops/key-metrics-for-devops-teams-dora-and-mttx.html
Slide 40
Slide 40 text
システム観測から開発運用が変わった
- 1,700台以上のエッジデバイスを少人数で安定運用
- 夜間はぐっすり寝られるようになった。
- リリース頻度も爆上!
Before After
通知数 20 万件 ~ / 月 ~ 300件 / 月
MTTD (Mean Time To Detect ) ~ 12時間 ~ 5分
MTTC (Mean Time To Clue) ※ 20分 ~ 1時間 (すべて手動) ~ 10分
※ https://www.splunk.com/ja_jp/blog/devops/key-metrics-for-devops-teams-dora-and-mttx.html
Slide 41
Slide 41 text
まとめ
1. 不安定故に可観測性は最優先
- 静かに死んでも気づけるように
- 死ぬ前のシグナルを逃さないように
Slide 42
Slide 42 text
まとめ
1. 不安定故に可観測性は最優先
- 静かに死んでも気づけるように
- 死ぬ前のシグナルを逃さないように
2. システム間の共通言語は設計を容易にする
- 動作環境にかかわらず、同じ指標で品質を語れる
Slide 43
Slide 43 text
まとめ
1. 不安定故に可観測性は最優先
- 静かに死んでも気づけるように
- 死ぬ前のシグナルを逃さないように
2. システム間の共通言語は設計を容易にする
- 動作環境にかかわらず、同じ指標で品質を語れる
3. 自動化で安眠は保たれた
- エッジ関連のオンコールは激減
- 気持ちの良い朝を毎日迎えられるようになった。
Slide 44
Slide 44 text
宣伝!!
Slide 45
Slide 45 text
ZennやSpeaker Deckにて情報発信中 !! 興味あれば是非
Speaker Deck (過去登壇資料)
Zenn (テックブログ)
Slide 46
Slide 46 text
一緒に働く仲間を募集しています !!
元気のいい人が大好きです
- IoT開発エンジニア
- ソフトウェアエンジニア
- 機械学習エンジニア
応募ﾀﾉﾑ ~
Slide 47
Slide 47 text
👋おわり