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