15年続くIoTサービスの SREエンジニアが挑む 分散トレーシング導入

私たちPanasonicのSREチームは、長年続くサービスにおいて、安定稼働と豊富な機能追加を目指して取り組んでいます。
その一環として、可観測性の向上についても挑戦を続けており、メトリクスやログの活用で一定の成果を上げることができた一方で、分散トレーシングにおいてはプロダクションへの導入まで至ることができず、一度挫折しています。
技術的な検証はできても、プロダクションへの導入には至らない。
その原因の1つは、エンジニア自身が技術をビジネス価値に変換できていないことにあると考え、新たなアプローチで、分散トレーシングの導入に再挑戦しているところです。
本発表では、分散トレーシングの導入に向けた私たちの現在進行形の挑戦を例に、技術をビジネス価値に変換する方法をご紹介します。
新しいツールや技術の新規導入に苦戦している方々は少なくないと思います。
同様の課題に悩まれている方々のヒントとなれば幸いです。

Transcript

1. 15年続くIoTサービスの SREエンジニアが挑む 分散トレーシング導入 ～技術をビジネス価値に翻訳する試行錯誤の記録～ ROOM B｜16:05 – 16:35 パナソニック株式会社 エレクトリックワークス社 • 黒﨑 耕平 • 筧 万里
2. 1：私たちについて 2：私たちの試行錯誤の記録 　2-1：分散トレーシングの導入失敗・・・ 　2-2：失敗の要因を分析 　2-3：導入に向けて再挑戦中！ 3：まとめ 目次 2 1：私たちについて
3. 3 Kohei Kurosaki（黒﨑 耕平） • Home IoT 『AiSEG』のSREを担当 • カメラとクルマとバイクとインテリアと Kubernetesが好き • 最近おうち SREはじめました Speaker
4. 4 Banri Kakehi（筧 万里） • 家庭用燃料電池 『エネファーム』の SREを担当 • ハッカソンが大好き • Webフロントエンドとモバイルアプリの 　開発ばかりやっていました Speaker
5. エレクトリックワークス社について 5 ◎パナソニックグループの中で電気設備に関する商材を担当
6. Home IoT『AiSEG』について① 6 ◎エネルギーのみえる化、家電のコントロールができる IoTデバイス 現行機 従来機
7. 7 ※他社製品も連携可能 • 電気代データ のチェック • 家電の操作 Home IoT『AiSEG』について②
8. 突然ですが、皆さん ... 8 可観測性向上は進んでいますか？ 現場では、おざなりになっていませんか？
9. 技術をビジネス価値に翻訳する方法 本セッションでお伝えしたいこと 9 可観測性向上を目的に分散トレーシング導入に挑戦しました。 この実例をもとにお話しします。
10. 1：私たちについて 2：私たちの試行錯誤の記録 　2-1：分散トレーシング導入の実例 　2-2：失敗の要因を分析 　2-3：導入に向けて再挑戦中！ 3：まとめ 目次 10 2-1：分散トレーシングの導入失敗・・・
11. 可観測性(Observability・O11y)とは？ ◎システム内部に手を加えずに外部から状態を推論できる能力 11 オブザーバビリティ・エンジニアリング, O’Reilly Japan, https://www.oreilly.co.jp/books/9784814400126/
12. 12 ◎リクエストがサービス間をどのように流れ、どの処理に時間がかかっているかを可 視化・追跡する技術 消費電力を確認したい！ 1リクエストの処理の流れ トレース 分散トレーシングとは？ トレースデータ（スパンの集合）を集約
13. クラウド技術の発展と共にスケール 13 2012 2018 2025 2016 AiSEG販売開 始 AiSEG2販売開始 専用スマホアプリ スマートHEMSサービス開始 2015 サービスの歴史 信頼性向上の歴史 2020 スマートスピーカーサービス開始 実行基盤を K8sに移行 2022 メトリクス収集 ログ収集の開始 AiSEG3販売開始 2026 スマホアプリ刷新 2021 ログの中央集権化 2023 ネットワーク改善 分散トレーシング導入試み 無停止リリース
14. 分散トレーシング導入の経緯 14 実績：k8s基盤へ移行＆マイクロサービス化 新たな懸念： 　・サービス間の依存関係の把握が困難 　・トラブルシューティングの難易度が増加 　　（ログをみてk8sの状態をみてMeshを見て…) 分散トレーシング導入に挑戦 2020年 2022年
15. 導入は失敗に終わる 15 ◎当初想定していたよりコストが跳ねて打ち切りに 　・SaaS＆インフラコスト：想定の10倍 　・実装コスト：計装に使う工数が早い段階で想定以上の増加 チームとして続ける流れにならず、終了 ◎推進の中心にいた人物が別プロジェクトへ … 　黒崎だけが残る（具体的な進め方がわからず...) 計装（Instrumentation）：アプリケーションやサービスに追跡情報（トレースデータ）を自動的に収集させるための仕組みを組み込むこと。
16. なぜ今、再挑戦をしたいのか？ 16 ◎メンバーのレベルが上り、技術の価値がわかるように 　・「今ならもっとうまくやれるんじゃ？」を直感 　・主要メンバーの高齢化で、属人化に対する危機感の高まり 技術的挑戦だけでなく、 どうビジネス価値へ貢献するか？が重要になった
17. 1：私たちについて 2：私たちの試行錯誤の記録 　2-1：分散トレーシング導入失敗・・・ 　2-2：失敗の要因分析 　2-3：導入に向けて再挑戦中！ 3：まとめ 目次 17 2-2：失敗の要因を分析
18. 分散トレーシング導入失敗の要因 18 • 知識、経験不足 • コスト見積もりの甘さ • 価値が不明確 • 共通認識の欠如 認識面 技術面
19. 技術面の失敗要因分析 19 ◎スキルや知識、社内ノウハウの問題 ・大規模サービスにおけるインフラの制約やコスト上昇 ・SDKの使用方法や計装のノウハウ、リファレンス不足 ・何を可視化したいのか？の問がなかった そもそも技術的な難しさの特定・把握が足りてなかった
20. 当時の分散トレーシングの構成 20 SDK→ Collector（受信・バッチ） → SaaS Backend（ストレージ・検索・ UI）という流れ
21. 当時甘くみていたコストの見積もり 21 サービスが大きくなるほど、テレメトリ送受 信の負荷が増大。検索自体のリソースも無 視できない。 リソースコスト １ SaaS利用料 2 トレース取り込み量／Span数／保持期間 などに依存。サンプリングを考えておらず 膨大になった。 実装コスト 3 SDKの使い方や計装のノウハウが全くな かった。当時は成熟度が足りず、技術的な 工夫が必要だった。 インフラ負荷とコストが 想定の1.5倍 年間の利用予想額を １か月で使い切り 用意した工数を ２か月で使い切り
22. 実装コスト増加の理由 22 ◎いきなり IoTデバイスまでの E2Eトレーシングに挑戦した HTTP リクエスト 1.HTTPリクエストはスパンの設定が簡単 2. 非同期の振る舞いに対してスパンの設定が困難 3.一貫性のためコンテキストの伝搬に工夫が必要 4. 上下や他サービスも考慮するとより複雑に
23. 23 認識面について失敗要因の分析 ビジネス価値に貢献する指標の共通認識がない 長期的な価値創出が停滞してしまった
24. ビジネス価値に貢献する指標の共通認識がない 24 ◎可観測性向上がもたらす価値の様々な例 最近は障害も少ないから 機能開発だけでいい Aさん とにかく新しい技術を 取り入れたい Bさん 運用に無駄が多い 早く自動化したい Cさん リスクや不確実性に対し簡単に振り回されてしまう
25. 長期的な価値創出の停滞 25 ◎タスク優先度の設定方針が定まっていなかった Do Last Avoid Do Fast Do Second 緊急度 タスクの大きさ ・脆弱性対応 ・インシデント対応 ・EOL ・新機能開発 ・可観測性向上 ・分散トレーシング ・トイル撲滅 High Mid Low None タスク管理マトリックス 分散トレーシングは放置されがちな課題に
26. 1：私たちについて 2：私たちの試行錯誤の記録 　2-1：分散トレーシングの導入失敗・・・ 　2-2：失敗の要因を分析 　2-3：ビジネス価値を定義して再挑戦 3：まとめ 目次 26 2-3：導入に向けて再挑戦中！
27. 技術面の見直し 27 認識面 技術面 • 知識、経験不足 • コスト見積もりの甘さ • 価値が不明確 • 共通認識の欠如
28. 分散トレーシングで何を把握したいか？ 28 ◎まずは問を明確化。それをもとに導入戦略を具体化した
29. 【再掲】従来の分散トレーシングの構成 29 ◎計装/SaaS/インフラにかかるコストが許容範囲を超えていた
30. 再設計した分散トレーシングの構成 30 ◎まずはOSSを活用し、運用負荷 /OSSでの限界を探索する
31. コストの見積もり 31 ◎自動計装 ＋サンプリング戦略設定の場合 サンプリング戦略の設定により コントロール可能に。 リソースコスト １ SaaSの利用コスト 2 必要な機能を絞り込むことで、 まずはSaaSなしでの実現を狙う 実装コスト 3 自動計装を主体としてサービスへの 手動計装を最小限に抑える。 不足している部分はクリティカルパスか ら手動計装を追加する。
32. 認識面の見直し 32 認識面 技術面 • 知識、経験不足 • コスト見積もりの甘さ • 価値が不明確 • 共通認識の欠如
33. まずSREに対する理解を深めた 33 ◎社内の勉強会からスタート • すぐに始められることを探した • モニタリング • ポストモーテム • 参考にできる部分を探した • ビジネス価値に貢献する指標の定義方法 • 自動化によって生まれる価値の見積もり方 SRE サイトリライアビリティエンジニアリング, O’Reilly Japan, https://www.oreilly.co.jp/books/9784873117911/
34. 参考：Googleにおける信頼性の制御 ◎信頼性を保ちながらどうやって自動化を進めたか • SLO（サービスレベル目標） ：ユーザーが満足するために守るべきサービスの品質目標 • エラーバジェット ：SLOを守るために、どれだけのダウンタイムやエラーを許容するか 信頼性向上 自動化・ トイル削減 開発を進めすぎると 信頼性が置き去りになる 信頼性を高めぎると 開発が遅れる SLOに紐づくエラーバジェット の 消費状態で決定 34 しかし、最初の一歩として進めるにはまだハードルがあった
35. はじめの一歩として行ったこと 35 ◎「ビジネス価値に貢献できる指標」＝「価値創出の時間」と定義した • 各チームから小さく・シンプルに始められること。 • エラー予算等の計測基盤がなくても今日から始められること。 • KPIがなくても若手メンバーが始められること。 内部工数の割合 運用作業 開発 運用作業 開発 新たな価値の創造へ
36. ビジネス価値への貢献度を見積もる 36 ◎分散トレーシングの導入の貢献度は？ 得られる価値創出の時間 = 4 [時間/件] × 2 [件/月] + 10 [時間] = 18 [時間/月] 問い合わせ調査時間の減少 得られる価値創出の時間 = 3 [時間/週] × 0.5 × 4 [週間] = 6 [時間/月] 属人化の解消
37. 現状できてきたこと 37 ・知識、経験不足 ・価値が不明確 認識面 技術面 ・コスト見積もりの甘さ ・共通認識の欠如 タスク優先度の適切な設定へ・・・
38. 認識面で残っている課題 38 ◎チーム内の優先度付けに、まだまだデータを使えていない • ビジネス側との関係性はあっても、 SREとしてデータを用いた判断方針を共有できていない ◎（5~10年単位で）今の指標を使い続けることはきっと難しい • 長く続いてるサービスだと、人が変わる、指標も変わるはず • 常に考えて、自分たちでベストを求めていきたい
39. 1：私たちについて 2：私たちの試行錯誤の記録 　2-1：分散トレーシングの導入失敗・・・ 　2-2：失敗の要因を分析 　2-3：導入に向けて再挑戦中！ 3：まとめ 目次 39 3：まとめ
40. 技術をビジネス価値に翻訳する方法 【再掲】本セッションでお伝えしたいこと 40 可観測性向上を目的に分散トレーシング導入に挑戦しました。 この実例をもとにお話しします。
41. 技術をビジネス価値に翻訳する方法 41 １ ビジネス価値に貢献できる指標を定義する 2 課題とその打ち手（技術）を検討する 3 ビジネス価値への貢献度を見積もる 4 タスク優先度の設定方針に取り込む 定量な表現 ＝ビジネス価値への翻訳 信頼性も 置き去りにしない！