反省から紐解くオブザーバビリティとして本当に必要だったテレメトリ

Slide 1

Slide 1 text

© 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.

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

© 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. テレメトリがあっても解決できるとは限らない Web Server AP Server DB Server Load Balanserにレスポンスが届く前にセッションが閉じられる • メトリクス、ログ、トレースすべて取得 • Keep-Aliveタイムアウト値、同時接続数の設定に問題なし • 再現せず、詳細ログを添付してサポートに問い合わせたが原因不明※ • 結果として根本原因が特定できないままクローズ Load Balancer ※ クラウド環境では、利⽤者が低レイヤーのテレメトリまで取得できない制約があり、インフラ基盤内部での事象については解明が困難な場合があるクライアントでタイムアウトが発⽣したケース

Slide 10

Slide 10 text

© 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 10 テレメトリ収集のジレンマテレメトリの収集が不⾜すると・分析できないテレメトリを収集しても・取りすぎると分析が複雑化・無駄になる可能性、コストの問題・取っても事象が解明するとは限らない未知の事象や障害分析を⾏うに当たってはテレメトリデータの取得が不可⽋ただし・・・

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

© 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 13 私がおすすめする”ここからはじめる” ① 4⼤シグナル [ Four Golden signals ] ② アプリケーション（フロント・バックエンド）ログ /インフラログ ③ クラウドで提供される標準的なメトリクス ④ 分散トレース＋ここから始めて（継続的な）テストで「このテレメトリは取っておかないとサービスの信頼性、およびビジネスに影響がでるな」となった場合にはそのテレメトリを都度追加していく ※準拠すべきレギュレーションがある場合やミッションクリティカルなシステムを除くこれらを1年未満の保存期間で管理・分析する（できれば数週間から数ヶ⽉）

Slide 14

Slide 14 text

Slide 15

Slide 15 text

© 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 システム

Slide 16

Slide 16 text

© 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. ゴールデンシグナルとは Latency （レイテンシ） Traffic （トラフィック） Errors （エラー） Saturation （飽和度）リクエストを処理してレスポンスを返すまでにかかる時間システムに対するリクエストの量処理に失敗したリクエストのレートシステムの使⽤率（最も制約のあるリソース）例︓レスポンス時間（平均/パーセンタイル）例︓秒間リクエスト数同時接続数例︓ エラー率アプリケーションエラー例︓ CPU・メモリ使⽤率ディスクI/O

Slide 17

Slide 17 text

© 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 17 なぜゴールデンシグナルなのかユーザー/クライアントサービスプロバイダ 1. シンプルさ: 4つの指標に集約することで、監視の複雑さを軽減 2. ユーザー中⼼: ユーザー体験に直接影響する指標に焦点サービスの真の価値は、ユーザーが「使えた」「解決できた」と感じる瞬間に⽣まれる逆に思ったような利⽤者体験がないとイメージはダウンする

Slide 18

Slide 18 text

© 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 18 「ユーザー中⼼」がプロアクティブな対応を⽣むユーザーから報告されたデータ遅延のクレームに対処積極的にデータ遅延を計測して問題を発見し対処 • クレームが来る頃には問題が大きくなる • 問題への対処が遅れる • 発見できない問題も発生するサービスレベルの低下 • 小さなうちから問題に対処できる • 早期に問題に対処できる • 報告されない問題にも対処できるサービスレベルの改善気付かぬうちに評価★1など負のスパイラルに⼊ってしまう SLI/SLO モニタリングの重要性 SLI としてゴールデンシグナルは頻出

Slide 19

Slide 19 text

Slide 20

Slide 20 text

© 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回送信各タスクが起動時に送信

Slide 21

Slide 21 text

© 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（折れ線グラフ）に重ねて表⽰することで異常ではないデプロイ中のタスク数を確認することが可能

Slide 22

Slide 22 text

© 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 （ブロックストレージ）に関する詳細なメトリクスの例こうした細かいところまで取れるものもあるため、カスタムメトリクスの前に標準メトリクスで⽬的を果たせないか確認

Slide 23

Slide 23 text

Slide 24

Slide 24 text

© 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. モバイルアプリケーションの複雑さ • モバイル側のプロセスの問題なのか、ネットワークの問題なのか、バックエンドの問題なのか、それらが相関しているのか、原因の可能性は多数存在する • 特定のユーザー、特定の時間のみ発⽣する場合もある 24 AWS Cloud バックエンドが原因? モバイル側が原因？ネットワークが原因?

Slide 25

Slide 25 text

© 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. フロントエンドテレメトリの重要性の⾼まり 25 スマホアプリに加えSPA(Single Page Application)も広く利⽤されている現代フロントエンドのレンダリングや巨⼤jsのフェッチで時間かかるといったケースは多い必要になるテレメトリ • JavaScriptやFWのログ • CoreWebVitals※ • ページロード時間などユーザー体験に直結するため重要であるが必須ではない取得⽅法 • クラウドサービスやSaaSの機能（APM/RUM）標準メトリクスやアプリケーションログとして参照できることが多い

Slide 26

Slide 26 text

Slide 27

Slide 27 text

© 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 27 「⾜りないんじゃないか」と思われたらまずは取得しているデータの⾒⽅を変える実際の例︓レスポンス時間が課題初⼿としてHTTP レスポンスコードをダッシュボードにて可視化 300 系のレスポンスが想定より多数あることを確認特定のユーザーパターンで何度もリダイレクトが起きていることが判明 404 のレスポンスが想定より発⽣していること確認必要ないコネクション⽣成に⼤きな負荷がかかっていたアプリケーション改修により改善ステータスコードを可視化するだけでも回収にむけた⽷⼝となった

Slide 28

Slide 28 text

© 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 28 追加で取得する可能性があるものビジネスメトリクス系ユーザー⾏動指標: コンバージョン率、離脱率、セッション時間収益関連: 取引成功率、決済完了率、売上への影響機能利⽤状況: 新機能の採⽤率、API呼び出し頻度セキュリティ・コンプライアンス系認証関連: ログイン失敗率、異常なアクセスパターンデータ保護: 個⼈情報アクセスログ、データ暗号化状況監査ログ: 管理者操作、設定変更履歴パフォーマンス詳細化フロントエンド︓ Core Web Vital データベース: クエリ実⾏時間、コネプ使⽤率、デッドロックキャッシュ: ヒット率、エビクション率、メモリ使⽤量外部API: サードパーティサービスの応答時間、失敗率運⽤効率化デプロイメント: リリース成功率、ロールバック頻度アラート品質: 誤検知率、平均解決時間（MTTR）容量計画: リソース使⽤傾向、成⻑予測データ

Slide 29

Slide 29 text

© 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 29 追加で取得する可能性があるものビジネスメトリクス系ユーザー⾏動指標: コンバージョン率、離脱率、セッション時間収益関連: 取引成功率、決済完了率、売上への影響機能利⽤状況: 新機能の採⽤率、API呼び出し頻度セキュリティ・コンプライアンス系認証関連: ログイン失敗率、異常なアクセスパターンデータ保護: 個⼈情報アクセスログ、データ暗号化状況監査ログ: 管理者操作、設定変更履歴パフォーマンス詳細化データベース: クエリ実⾏時間、コネプ使⽤率、デッドロックキャッシュ: ヒット率、エビクション率、メモリ使⽤量外部API: サードパーティサービスの応答時間、失敗率運⽤効率化デプロイメント: リリース成功率、ロールバック頻度アラート品質: 誤検知率、平均解決時間（MTTR）容量計画: リソース使⽤傾向、成⻑予測データポイント短期間・⼀度に多くを追加しない追加 → 分析 → 必要性の再確認を繰り返す（≒育てる）

Slide 30

Slide 30 text

Slide 31

Slide 31 text

© 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％ここまで説明してきた”何を取得するか”に加えて”データの保存”で調整する

Slide 32

Slide 32 text

Slide 33

Slide 33 text

© 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 33 私がおすすめする”ここからはじめる” ① 4⼤シグナル [ Four Golden signals ] ② アプリケーション（フロント・バックエンド）ログ /インフラログ ③ クラウドで提供される標準的なメトリクス ④ 分散トレース＋ここから始めて（継続的な）テストで「このテレメトリは取っておかないとサービスの信頼性、およびビジネスに影響がでるな」となった場合にはそのテレメトリを都度追加していく ※準拠すべきレギュレーションがある場合やミッションクリティカルなシステムを除くこれらを1年未満の保存期間で管理・分析する（できれば数週間から数ヶ⽉）

Slide 34

Slide 34 text

Slide 35

Slide 35 text

© 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 35 本セッションのまとめ • 未知の事象に対応するためにテレメトリデータを取得し分析する活動は正しい • ただし設計なく取り組むと想定していた分析ができず、加えてコストが問題に • 必要なテレメトリをある程度⾒⽴て、設計する必要がある • ゴールデンシグナル、⼀般的なログ、クラウドメトリクス、分散トレースから始める • テレメトリデータを追加する前に観点を変えて既存のデータの分析を

Slide 36

Slide 36 text

© 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. Customer experience Collect Improve Act Business stakeholders Customer needs KPIs 36 完璧なオブザーバビリティは存在しない⼤切なのはいきなり完璧を⽬指さず、段階的に改善すること終わりなき旅を仲間と共に楽しみましょう︕