【セッションレポート】AWS-06 Amazon の事例から学ぶ Observability ... #AWSSummitTokyo2023

はじめに

AWS Summit Tokyo 2023 Day1 (4/20 (金)) に参加してきました！

「Amazon の事例から学ぶ Observability 活用におけるベストプラクティス(AWS-06)」のセッションレポートを投稿します。

以下の記事で Observability を活用したインシデント対応全体のセッションのレポートもありますので合わせてご覧ください。
https://zenn.dev/paiza/articles/5726a1ef81d74f

アーカイブ

以下にアーカイブがありますので、自由に視聴可能です。
https://aws.amazon.com/jp/summits/tokyo-2023/agenda/?aws-summit-japan-2023-cards.sort-by=item.additionalFields.sortOrder&aws-summit-japan-2023-cards.sort-order=asc&awsf.session-category=*all&awsf.use-case=*all&awsf.company-category=*all&awsf.industry=*all

セッション概要

システムの健全性やユーザの満足度をどのように把握していますか？システムの Observability （可観測性）を高めるには、単にサーバのモニタリングを行うだけでは不十分です。エンドユーザの体験を含めたログやメトリクス、トレースといった情報を収集、関連付け、可視化、分析することで、システムの問題を迅速に発見して解決に繋げられる、そんなメカニズムが必要です。本セッションでは、Amazonで実際に行われている運用を例に、大規模かつ複雑なシステムでどのように高い Observability を実現しているのかをご紹介します。さらに、CloudWatch をはじめとしたAWSのサービスを活用して、同様の仕組みを実現する具体的な方法についても解説します。

レポート

セッションゴール

システムのインシデントやパフォーマンス低下の際に、迅速な検知を
してどのように解決まで導くかについて Amazon の運⽤例から学び、
AWS で実現する⽅法を理解する

インシデント対応でのアプローチ

• 分析できる対象の全体像
  

• インシデントの根本原因の特定への Journey

  • トレースから⼿がかりを辿る
  • ダッシュボードから傾向を調査する
  • 複数の視点からメトリクスを調査する
  • ログ調査から根本原因を⾒つける

• Observability のベストプラクティス

  • トレース情報を伝搬させる
  • ⽬的別のダッシュボードを構築する
  • 複数の Dimension でメトリクスを取得する
  • ⾼カーディナリティのメトリクスを使⽤する
  • ログ解析で深く掘り下げ、⽣のログから問題を特定する
  • プロファイラによる解析を活⽤する

• Observability のベストプラクティスに対応する AWS サービス

  • トレース情報の伝搬
    • AWS X-Ray
  • ⽬的別のダッシュボードを構築する
    • CloudWatch Dashboard
  • 複数の Dimension でメトリクスを取得
    • CloudWatch Embedded Metrics Format (EMF)
      • 複雑なアプリケーションデータをログの形式で取り込み、実⽤的なメトリクスを⽣成
    • CloudWatch Metric Insights
  • ⾼カーディナリティのメトリクスを活⽤
    • CloudWatch EMF
      • 低カーディナリティのものはメトリクスにしておく
      • 高カーディナリティのものはログに残しておく
  • ログを効率よく分析
    • CloudWatch Contributor Insights
      • 「エラーを最も多く⽣成する Product Id」であったり、「レスポンスタイムが⼤きいユーザー」といったものを分析できる
    • CloudWatch Logs Insights
  • プロファイラによるコード解析
    • Amazon CodeGuru Profiler
      • 機械学習をベースとしたプロファイラによるコードの品質の改善

ユーザー体験の Observability

• エンドユーザーにとっての良い体験とは？例えば、、、
  • ウェブページの応答時間
  • ログインページの応答速度
  • 商品購⼊時のエラー率
  • JavaScript のエラー率
• 「ある ISP のファイバーの切断により、⼀部でパケットロスが発⽣していた」みたいな状況はサービス側の情報を見ても原因を特定できない
  • Amazon CloudWatch Internet Monitor
    • AWS 上のアプリケーションに対してユーザーから⾒た場合の可⽤性とパフォーマンス メトリクスを CloudWatch で可視化可能に
    • 問題がある場合はその影響や場所、プロバイダーなどを可視化し、改善アクションを起こしやすくする
    • 例えば「概ね正常だがラスベガスからアクセスしているユーザはパフォーマンスが落ちている」といった状況が検出可能
    • VPC や CloudFront などが対象、ログの有効化は不要

感想

現在の運用ではメトリクスによる傾向分析かエラー通知からログや DB データ解析などを行うような流れが多いが、もっと切り分けを早くしたり予防監視できるものが多くあることに可能性を感じました。
特にトレース情報は最近のモダンなサービス構成においては取れていた方が初動の切り分け速度に効いてくると考えているので、今後取り入れてみたいところです。とはいえ、実装しているプログラム言語によって採用可否が決まってくるのかは少し気になるところです。
プロファイラによるコード解析もまだ利用したことがありませんが、プログラムコードレベルでの実行時間や呼び出しの流れなどが可視化されるのは非常に有用に感じているので、今後採用してみたい技術だと感じました。
可観測性についてはまだまだやれることが多そうでワクワクする領域ですね。