反省から紐解くオブザーバビリティとして本当に必要だったテレメトリ

Observability Conference Tokyo 2025登壇資料
オブザーバビリティに取り組む中での難しさと、それを踏まえ何を取得すべきなのか過去のの反省を踏まえて整理しました。

Transcript

1. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 反省から紐解く オブザーバビリティとして 本当に必要だったテレメトリ Mitsuaki Tsugo O B S E R V A B I L I T Y C O N F E R E N C E 2 0 2 5 Sr. Solutions Architect Amazon Web Service Japan G.K.
2. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. ⾃⼰紹介 津郷 光明 Mitsuaki Tsugo アマゾンウェブサービスジャパン ソリューションアーキテクト Tags: Observability, IaC, CloudOps, SRE
3. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. “オブザーバビリティツールでは、 チーム内の最⾼のデバッガーは、 通常、最も好奇⼼の強いエンジニアです” • システムに関する多くの情報を積極的に収集 • 発⽣した障害の原因や潜在的な問題を ⾃由に探求
4. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. ⼀⽅で現実には難しさもある・・・
5. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 「たくさんのデータをもとに多⾓的に分析」となりがち 課題①︓膨⼤なデータと複雑化 • 様々なデータがあって複雑化 • 思っていたような分析が実現できない • 本当に必要なデータが埋もれる 1つめの難しさ
6. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. システム運⽤が安定してくると誰も使わない・消せないものが出てくる 課題②︓コスト（費⽤対効果） 2つめの難しさ
7. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 7 未だ体験したことのない障害/問題を検出し 解決する ”はずだった” テレメトリデータ 課題①︓ • 思っていたような分析が実現できない • 本当に必要なデータが埋もれる 課題②︓ • コスト（費⽤対効果）
8. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 8 さらに・・・ テレメトリデータをとっていたからといって 全ての事象を分析、原因究明できるわけではない
9. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. テレメトリがあっても解決できるとは限らない Web Server AP Server DB Server Load Balanserにレスポンスが 届く前にセッションが閉じられる • メトリクス、ログ、トレースすべて取得 • Keep-Aliveタイムアウト値、同時接続数の設定に問題なし • 再現せず、詳細ログを添付してサポートに問い合わせたが原因不明※ • 結果として根本原因が特定できないままクローズ Load Balancer ※ クラウド環境では、利⽤者が低レイヤーのテレメトリまで取得できない制約があり、 インフラ基盤内部での事象については解明が困難な場合がある クライアントでタイムアウトが発⽣したケース
10. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 10 テレメトリ収集のジレンマ テレメトリの収集が不⾜すると ・分析できない テレメトリを収集しても ・取りすぎると分析が複雑化 ・無駄になる可能性、コストの問題 ・取っても事象が解明するとは限らない 未知の事象や障害分析を⾏うに当たってはテレメトリデータの取得が不可⽋ ただし・・・
11. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 11 ではどうするのか・・・ どこから始めれば良いのか・・・
12. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. ポイント︓ これだけ採っておけば良いと⾔うものはない ただしある程度の⾒⽴てを持って取り組み、 コストとのバランスを取る そして継続的に⾒直し、育てていく
13. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 13 私がおすすめする”ここからはじめる” ① 4⼤シグナル [ Four Golden signals ] ② アプリケーション（フロント・バックエンド）ログ /インフラ ログ ③ クラウドで提供される標準的なメトリクス ④ 分散トレース ＋ ここから始めて（継続的な）テストで 「このテレメトリは取っておかないとサービスの信頼性、およびビジネスに影響がでるな」と なった場合にはそのテレメトリを都度追加していく ※準拠すべきレギュレーションがある場合やミッションクリティカルなシステムを除く これらを1年未満の保存期間で管理・分析する（できれば数週間から数ヶ⽉）
14. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 反省1︓ユーザー⽬線の⽋落 14
15. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 15 過去の失敗例 CPU, メモリなどは正常 • よくデータ遅延が起きる • 更新に時間がかかる → 不満が蓄積 1. CPU, メモリなどメトリクス監視のみ行っていた 2. ユーザーからクレームが来てから問題に対処しておりユーザーの不満が高まる 3. 結果使ってもらえ無くなった 拠点 1 拠点 2 Cloud API Web App User データ 基盤 拠点からのデータを収集、分析する IoT システム
16. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. ゴールデンシグナルとは Latency （レイテンシ） Traffic （トラフィック） Errors （エラー） Saturation （飽和度） リクエストを処理して レスポンスを返すまで にかかる時間 システムに対する リクエストの量 処理に失敗した リクエストのレート システムの使⽤率 （最も制約のあるリソース） 例︓レスポンス時間 （平均/パーセンタイル） 例︓秒間リクエスト数 同時接続数 例︓ エラー率 アプリケーションエラー 例︓ CPU・メモリ使⽤率 ディスクI/O
17. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 17 なぜゴールデンシグナルなのか ユーザー/クライアント サービスプロバイダ 1. シンプルさ: 4つの指標に集約することで、監視の複雑さを軽減 2. ユーザー中⼼: ユーザー体験に直接影響する指標に焦点 サービスの真の価値は、 ユーザーが「使えた」「解決できた」と感じる瞬間に⽣まれる 逆に思ったような利⽤者体験がないとイメージはダウンする
18. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 18 「ユーザー中⼼」がプロアクティブな対応を⽣む ユーザーから報告された データ遅延のクレームに対処 積極的にデータ遅延を計測して 問題を発見し対処 • クレームが来る頃には問題が大きくなる • 問題への対処が遅れる • 発見できない問題も発生する サービスレベルの低下 • 小さなうちから問題に対処できる • 早期に問題に対処できる • 報告されない問題にも対処できる サービスレベルの改善 気付かぬうちに評価★1など 負のスパイラルに⼊ってしまう SLI/SLO モニタリングの重要性 SLI としてゴールデンシグナルは頻出
19. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 反省2︓ モダナイゼーションによるコスト肥⼤化 19
20. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. カスタムメトリクスのコストが肥⼤化 従来の環境 （仮想サーバー） マイクロサービス （コンテナ） ⽉に1度デプロイ インスタンス ︓3 サービス ︓1 カスタムメトリクスの発⾏数︓3 ⽉4回デプロイ 全タスク数︓50 サービス ︓10 カスタムメトリクスの発⾏数︓200 $0.9/月 （年間約2千円） $60/月 (年間約11万円) コンテナ化 モダナイゼーションを⾏った結果コストが肥⼤化した例︓デプロイフラグメトリクス マイクロ サービス デプロイスクリプトから1回送信 各タスクが起動時に送信
21. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 21 クラウドで取得できる標準メトリクスの例 1. RunningTaskCount - 名前空間︓ECS - 現在、RUNNING 状態にあるタスクの数 2. DesiredTaskCount - 名前空間︓ECS - Amazon ECS サービスに必要なタスクの数 3. UnHealthyHostCount - 名前空間︓ALB - 異常とみなされるターゲットの数 Amazon ECS （コンテナオーケストレーションサービス）に関するメトリクスの例 標準的なメトリクスで多くのケースは対処できる可能性がある これらを CloudWatch ダッシュボードの同じWidget（折れ線グラフ）に重ねて表⽰することで 異常ではないデプロイ中のタスク数を確認することが可能
22. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 22 参考︓標準メトリクスも細かく⾒れる https://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/ebs-io-characteristics.html#ebs-io-metrics 1. VolumeStalledIOCheck - 名前空間：EBS - 過去 1 分間にボリュームの IO チェックに合格したか失敗したかを 0 (合格) または 1 (不合格)で返す - 値が1である場合、ボリュームのI/O操作に問題が発⽣している可能性が⾼い 2. StatusCheckFailed_AttachedEBS - 名前空間：EC2 - 直近 1 分間でインスタンスがアタッチ済みの EBS ステータスチェックに成功したか どうかを 0 (合格) または 1 (失敗) で返す - 値が1である場合、インスタンスとボリューム間の接続に問題がある可能性が⾼い Amazon EBS （ブロックストレージ）に関する詳細なメトリクスの例 こうした細かいところまで取れるものもあるため、 カスタムメトリクスの前に標準メトリクスで⽬的を果たせないか確認
23. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 反省3︓ フロントエンドの軽視 23
24. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. モバイルアプリケーションの複雑さ • モバイル側のプロセスの問題なのか、ネットワークの問題なのか、バックエンドの問題 なのか、それらが相関しているのか、原因の可能性は多数存在する • 特定のユーザー、特定の時間のみ発⽣する場合もある 24 AWS Cloud バックエンドが原因? モバイル側が原因？ ネットワークが原因?
25. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. フロントエンドテレメトリの重要性の⾼まり 25 スマホアプリに加えSPA(Single Page Application)も広く利⽤されている現代 フロントエンドのレンダリングや巨⼤jsのフェッチで時間かかるといったケースは多い 必要になるテレメトリ • JavaScriptやFWのログ • CoreWebVitals※ • ページロード時間 など ユーザー体験に直結するため重要であるが必須ではない 取得⽅法 • クラウドサービスやSaaSの機能 （APM/RUM） 標準メトリクスやアプリケーションログと して参照できることが多い
26. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 反省4︓ 既存データの分析観点変更 26
27. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 27 「⾜りないんじゃないか」と思われたら まずは取得しているデータの⾒⽅を変える 実際の例︓レスポンス時間が課題 初⼿としてHTTP レスポンスコードをダッシュボードにて可視化 300 系のレスポンスが 想定より多数あることを確認 特定のユーザーパターンで何度も リダイレクトが起きていることが判明 404 のレスポンスが 想定より発⽣していること確認 必要ないコネクション⽣成に ⼤きな負荷がかかっていた アプリケーション改修により改善 ステータスコードを可視化するだけでも回収にむけた⽷⼝となった
28. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 28 追加で取得する可能性があるもの ビジネスメトリクス系 ユーザー⾏動指標: コンバージョン率、離脱率、セッション時間 収益関連: 取引成功率、決済完了率、売上への影響 機能利⽤状況: 新機能の採⽤率、API呼び出し頻度 セキュリティ・コンプライアンス系 認証関連: ログイン失敗率、異常なアクセスパターン データ保護: 個⼈情報アクセスログ、データ暗号化状況 監査ログ: 管理者操作、設定変更履歴 パフォーマンス詳細化 フロントエンド︓ Core Web Vital データベース: クエリ実⾏時間、コネプ使⽤率、デッドロック キャッシュ: ヒット率、エビクション率、メモリ使⽤量 外部API: サードパーティサービスの応答時間、失敗率 運⽤効率化 デプロイメント: リリース成功率、ロールバック頻度 アラート品質: 誤検知率、平均解決時間（MTTR） 容量計画: リソース使⽤傾向、成⻑予測データ
29. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 29 追加で取得する可能性があるもの ビジネスメトリクス系 ユーザー⾏動指標: コンバージョン率、離脱率、セッション時間 収益関連: 取引成功率、決済完了率、売上への影響 機能利⽤状況: 新機能の採⽤率、API呼び出し頻度 セキュリティ・コンプライアンス系 認証関連: ログイン失敗率、異常なアクセスパターン データ保護: 個⼈情報アクセスログ、データ暗号化状況 監査ログ: 管理者操作、設定変更履歴 パフォーマンス詳細化 データベース: クエリ実⾏時間、コネプ使⽤率、デッドロック キャッシュ: ヒット率、エビクション率、メモリ使⽤量 外部API: サードパーティサービスの応答時間、失敗率 運⽤効率化 デプロイメント: リリース成功率、ロールバック頻度 アラート品質: 誤検知率、平均解決時間（MTTR） 容量計画: リソース使⽤傾向、成⻑予測データ ポイント 短期間・⼀度に多くを追加しない 追加 → 分析 → 必要性の再確認 を繰り返す（≒育てる）
30. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 30 それでもテレメトリが増えてしまったら
31. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 31 コストバランスは調整できる ストレージ保管期間 サンプリングレート • すぐに取り出すテレメトリは標準のTier • すぐに取り出さないものは安いTierへ • ⼀定期間で削除 1週間、1ヶ⽉、1年で使い分けることから始める （1⽇、1週間、1ヶ⽉でも良い可能性あり） 標準Tier 中間Tier ⻑期保管 安価Tier • 状況を⾒ながら変動させる ※最初から低くしすぎない • 時系列データは丸めるなど ⾃動調整のサービスも出始めている トレースは10〜30％くらいから調整を始める 平常時 20％ イベント時 70％ 平常時 20％ ここまで説明してきた”何を取得するか”に加えて”データの保存”で調整する
32. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 32 ということで
33. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 33 私がおすすめする”ここからはじめる” ① 4⼤シグナル [ Four Golden signals ] ② アプリケーション（フロント・バックエンド）ログ /インフラ ログ ③ クラウドで提供される標準的なメトリクス ④ 分散トレース ＋ ここから始めて（継続的な）テストで 「このテレメトリは取っておかないとサービスの信頼性、およびビジネスに影響がでるな」と なった場合にはそのテレメトリを都度追加していく ※準拠すべきレギュレーションがある場合やミッションクリティカルなシステムを除く これらを1年未満の保存期間で管理・分析する（できれば数週間から数ヶ⽉）
34. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. まとめ 34
35. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 35 本セッションのまとめ • 未知の事象に対応するためにテレメトリデータを取得し分析する活動は正しい • ただし設計なく取り組むと想定していた分析ができず、加えてコストが問題に • 必要なテレメトリをある程度⾒⽴て、設計する必要がある • ゴールデンシグナル、⼀般的なログ、クラウドメトリクス、分散トレースから 始める • テレメトリデータを追加する前に観点を変えて既存のデータの分析を
36. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. Customer experience Collect Improve Act Business stakeholders Customer needs KPIs 36 完璧なオブザーバビリティは存在しない ⼤切なのはいきなり完璧を⽬指さず、 段階的に改善すること 終わりなき旅を仲間と共に楽しみましょう︕
37. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. Thank you! © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. Mitsuaki Tsugo 37