【レポート】AWS Summit Tokyo 2023：Amazon の事例から学ぶ Observability 活用におけるベストプラクティス #AWSSummit

こんにちはネクストモード田邉です。

AWS Summit Tokyo に初めて参加しました。

当エントリでは2023年04月20日に行われた『Amazon の事例から学ぶ Observability 活用におけるベストプラクティス』に関する内容をレポートしたいと思います。

• AWS Summit Tokyo | 2023 年 4 月 20 日, 21 日 幕張メッセで開催

セッション概要

当セッション の登壇者及び概要は以下の通りです。

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

セッションレポート

以下セッションレポートです。

Observabilityの必要性

ビジネスの需要に応じるために柔軟性・拡張性の高いシステムとして、マイクロサービスがトレンドになってきている中でObservabilityの必要性が高まっている。

• マイクロサービスでは多数のシステムが分散されている
  • ロードバランサー
  • フロントエンド
  • バックエンド
  • データベース
  • Lambda等
• パフォーマンス遅延やインシデント発生時に各システムにログインして、リクエストのログを見ることは、非現実的
• マイクロサービスではトレースでリクエストの流れを可視化することが重要になる
  • トレースの伝搬がされると、サービスマップにリクエストの流れが表示されるようになる
    • リクエストの一連の流れの把握と障害特定やパフォーマンス分析につながる情報を確認
      • 成功した呼び出し
      • 4xxエラー
      • 5xxエラー
      • スロットリングエラー

AmazonにおけるObservabilityのベストプラクティス

マイクロサービスにおいて、インシデントの原因を特定することは「山ほどある干し草の中からたった一本の針を探すこと」のように難しい。

• 調査は抽象度が高い部分から低い部分へ
  1. アラーム
  2. トレース
  3. ダッシュボード
  4. メトリクス分析
  5. ログ分析
  6. 生ログ
• インストルメンテーションは利用者側の対応も必要
  • カスタムメトリクス
  • カスタムログ
  • トレース
• 事前に目的別のダッシュボードを用意することで様々な視点で状況確認が可能になる
  • マイクロサービスダッシュボード
  • 顧客体験ダッシュボード
  • システムダッシュボード
  • 依存関係ダッシュボード
  • インフラストラクチャダッシュボード
• 高カーディナリティのメトリクスの活用により、粒度の細かい、深い洞察を得ることができる
• どのように非効率なコードを特定するか？
  • アプリ側の実装の問題でレイテンシーが高くなっているケースなど、対象コードを見つけるのが難しいケースはプロファイラでコードを解析する

• まとめ
  • 調査は抽象度を意識する
  • 運用の改善サイクルを回すことがポイント
    • インストルメンテーション
    • ログ、メトリクス
    • アラーム、ダッシュボード
    • 質問
  • 「質問」はインシデント対応後の振り返り
    • 現在のダッシュボードで迅速に対応できたかチェックする
    • ダッシュボードに不足があれば追加していく

AmazonでObservabilityを実現する方法

• AWS X-Ray
  • トレース情報の伝搬
  • 「トレース」によりリクエストからレスポンスまでの全体の流れを追跡する
• CloudWatch Dashboard
  • 目的別のダッシュボードを構築する
  • 異なるアカウント、異なるリージョンのリソースでも、ダッシュボード化が可能
• CloudWatch Embedded Metrics Format
  • 複雑なアプリケーションデータをログの形式で取り込み、実用的なメトリクスを生成
• CloudWatch Metric Insights
  • SQLベースの柔軟なクエリ機能により、リアルタイムでメトリクスの集計やグルーピングが可能
• CloudWatch Contributor Insights
  • CloudWatch Logsの構造化されたログデータを解析
  • コントリビューターデータを表示する時系列グラフを作成
  • システムのパフォーマンスに影響を与えている人や物を判断するのに有効
• CloudWatch Logs Insights
  • CloudWatch Logsでログデータをインタラクティブに検索、分析
  • 時系列データの可視化、個々のログイベントへのドリルダウン
• Amazon CodeGuru Profiler
  • 機械学習をベースとしたプロファイラによるコードの品質の改善
  • アプリケーションランタイムの挙動へのインサイトを提供し、パフォーマンス改善及びインフラストラクチャ費用の削減に寄与
  • 改善方法を含む推奨事項が得られ、非効率的なコードが継続実行されることでかかるコスト概算も掲示されるため、改善の優先順位を付けることが可能

ユーザーサイドのObservability

• ユーザー体験を測るには？
  • エンドユーザーにとって「良い体験」とは何かを確立することから始める
    • ウェブページの応答時間
    • ログインページの応答速度
    • 商品購入時のエラー率
• 問題の原因は様々
  • エンドユーザーからの問い合わせ”アプリケーションは非常に動作が遅いです。携帯とPCの両方から試しましたが、どちらも遅いです”
  • ダッシュボードを確認しても、問題無いように見える
  • ISP側を調査した結果、ファイバーの切断により、一部でパケットロスが発生していた
• Amazon CloudWatch Internet Monitor
  • AWS上のアプリケーションに対してユーザーから見た場合の可用性とパフォーマンスメトリクスをCloudWatchで可視化可能に
    • 問題がある場合はその影響や場所、プロバイダーなどを可視化し、改善アクションを起こしやすくする
    • 例えば「概ね正常だがラスベガスからアクセスしているユーザはパフォーマンスが落ちている」といった状況が検出可能
    • VPCやCloudFrontなどが対象、ログの有効化は不要
  • 2023/02/28に一般提供開始

まとめ

• Observabilityのサイクルの考え方を理解し、運用を改善して顧客体験を高めていく
• インシデント調査の過程におけるシステムの状態に関する質問や顧客影響度把握のための質問に答えられるようにトレース、メトリクス、ログを取得していく
• CloudWatchの各機能やX-Rayの活用によりObservabilityを高め、迅速な解決に繋げる

おわりに

Observabilityの重要性やAWSにおける実現方法について具体的な理解を深めることができました。

システムのモニタリングだけではインシデントの原因特定に至らないケースも経験しているため、業務でも本セッションの学びを活かしていきたいです。

初参加のため網羅性に欠ける部分もあるかと思いますので、セッションが公開されたら再度チェックして本エントリを更新できればと考えております。

また、AWS WorkshopにObservabilityに関するコンテンツを見つけたので、こちら挑戦してみようと思います！

One Observability Workshop