Vanguard 社は AWS X-Ray と Amazon CloudWatch を使用してどのように Amazon ECS 上のアプリケーションの可観測性を向上させたのか

この記事は、Vanguard 社 Technical Lead の Jeffrey Emberger と AWS ソリューションアーキテクトの John Formento によって投稿された How Vanguard uses AWS X-Ray and Amazon CloudWatch to improve observability for Amazon ECS cloud applications を翻訳したものです。

クラウド上で動作するアプリケーションは企業がお客様に新しい機能を提供するスピードを変えています。スピードの向上に伴い、アプリケーションの健全性をより迅速に、確実に、低コストで観測できることが求められています。より多くの企業がその存続をウェブに依存しているため、オブザーバビリティ (可観測性) を疎かにすることはできません。数分でもダウンタイムが発生すれば、収益、将来の顧客、評判を失うことになります。

オブザーバビリティは正確かつタイムリーでなければなりません。開発チームは重大な業務停止につながる前にアプリケーションのレイテンシー、障害、またはインフラストラクチャの問題に気付ける必要があります。オブザーバビリティツールは、重大な問題が発生したときにトレース情報をデバッグするためのユーザーフレンドリーなエクスペリエンスを提供し、根本原因をできるだけ早く特定できるようにする必要があります。

この記事では Vanguard 社の開発チームが Amazon Elastic Container Service (Amazon ECS) on AWS Fargate にデプロイされたアプリケーションの一部を、どのようにしてサードパーティーのオブザーバビリティツールから AWS X-Ray および Amazon CloudWatch へ移行したかについて説明します。

この記事では以下のサービスを取り上げています。

Amazon ECS

Amazon ECS はクラスター上のコンテナの実行、停止、管理を容易にする、スケーラブルで高速なマネージドのコンテナオーケストレーションサービスです。お客様のコンテナは、スタンドアロンタスクやサービス内のタスクを実行するために使用するタスク定義で定義されます。ここでいうサービスとは、クラスター内で指定された数のタスクを同時に実行、維持することができる構成のことです。タスクやサービスは AWS Fargate のようなマネージドのサーバーレスインフラストラクチャ上で実行することができます。また、インフラストラクチャをよりコントロールしたい場合は、お客様が管理する Amazon Elastic Compute Cloud (Amazon EC2) のインスタンスで構成されるクラスター上でタスクやサービスを実行することができます。

AWS Fargate

AWS Fargate は、Amazon ECS と Amazon Elastic Kubernetes Service (Amazon EKS) の両方で動作するコンテナ向けサーバーレスコンピューティングエンジンです。Fargate ではサーバーのプロビジョンと管理が不要となり、アプリケーションごとにリソースを指定してその分のみ料金を支払うことができ、設計段階からのアプリケーション分離によりセキュリティを強化します。

Fargate では、インスタンスの選択やクラスターキャパシティのスケーリングを気にすることなく、適切なコンピューティング容量が割り当てられます。コンテナの実行に必要なリソースの分のみの料金を支払うため、オーバープロビジョニングや追加のサーバー料金は一切発生しません。Fargate による各タスクおよび各 Pod の実行には、独自のカーネルとそれぞれ独立したコンピューティング環境が使用されます。これにより、お使いのアプリケーションでワークロードの分離とセキュリティの向上が実現できます。そしてこれが Vanguard、Accenture、Foursquare、Ancestry などのお客様がミッションクリティカルなアプリケーションの実行に Fargate を選ぶ理由です。

AWS X-Ray

開発者は AWS X-Ray を使用して、本番環境や分散アプリケーション (マイクロサービスアーキテクチャを使用して構築されたアプリケーションなど) を分析およびデバッグできます。X-Ray を使用すると、アプリケーションやその基盤となるサービスの実行状況を把握し、パフォーマンスの問題やエラーの根本原因を特定して、トラブルシューティングを行えます。X-Ray では、アプリケーション内で転送されるリクエストがエンドツーエンドで表示され、アプリケーションの基盤となるコンポーネントがマップ表示されます。X-Ray を使用すると、開発中か本番環境かにかかわらず、シンプルな 3 層アプリケーションから数千のサービスで構成される複雑なマイクロサービスアプリケーションまで、さまざまなアプリケーションを分析できます。

Amazon CloudWatch

Amazon CloudWatch は、DevOps エンジニア、デベロッパー、サイトリライアビリティエンジニア (SRE)、および IT マネージャーのために構築されたモニタリング/オブザーバビリティサービスです。CloudWatch では、アプリケーションを監視し、システム全体におけるパフォーマンスの変化に対応して、リソース使用率の最適化を行い、運用上の健全性を統括的に把握するためのデータと実用的なインサイトが提供されます。CloudWatch は、ログ、メトリクス、およびイベントという形式でモニタリングデータと運用データを収集し、AWS とオンプレミスのサーバーで実行される AWS のリソース、アプリケーション、およびサービスの統合されたビューをユーザーに提供します。CloudWatch を使用して、環境内における異常動作の検知、アラームの設定、ログとメトリクスのサイドバイサイドの視覚化、自動化されたアクションの実行、問題のトラブルシューティング、およびインサイトの検出を行い、アプリケーションのスムーズな実行を維持することができます。

オブザーバビリティ向上のためのスタート地点

Vanguard 社の開発チームは監視とトレースにサードパーティのツールを使用し、Amazon ECS on AWS Fargate 上に展開されたアプリケーションのサポートを担当していました。これらのツールのうち 1 つは、本番の問題を検出するために AWS からログを受信する必要があったため、オンコール担当の開発者へのアラームが遅れていました。また別のツールでは、アプリケーションの実行後に AWS からトレース情報を受信していましたが、カスタムログやトレースには対応していませんでした。そのため開発チームは、本番環境の問題を解決するのに必要な時間を見積もることができませんでした。

分析

開発チームは、信頼性、正確性、適時性を向上させることができるクラウドネイティブなオブザーバビリティツールを探していました。開発チームはより良いツールが見つかれば、ECS 上のアプリケーションに重大な本番問題が発生した場合のビジネスへの影響を軽減できると考えました。

開発チームは AWS のソリューションアーキテクトと会い、AWS X-Rayと Amazon CloudWatch を勧められました。開発チームはこれらのサービスがオブザーバビリティのニーズを満たし、アプリケーションと簡単に統合できると判断しました。

AWS X-Ray の実装

開発チームは、ECS 上のアプリケーションに AWS X-Ray を実装することから始めることにしました。必要とされる AWS X-Ray の依存関係に加えて、開発チームはアプリケーションの入力フィールドに関わるコードに 1 つのカスタムアノテーションを追加しました。開発チームは大きな問題もなくコーディングの変更を完了し、程なくアプリケーションは AWS X-Ray で正常に動作するようになりました。

開発チームは、ECS 上のアプリケーションが本番環境に移行した数日後に AWS X-Ray を使用する機会がありました。アプリケーションの一部で、コンシューマーアプリケーションにデータが返されていませんでした。開発チームは、追加したカスタムアノテーションを使用して AWS X-Ray で入力値によるフィルタリングを行うことで、Amazon DynamoDB で見つからなかった入力値のリストを得ることができました。AWS X-Ray がなければ、開発チームはアプリケーションに表示ステートメントを追加し、問題となっている DynamoDB の入力値のリストを見つけるために ECS のログを手動で調べる必要がありました。ECS のログを手動で調査するには何時間もかかっていたでしょう。AWS X-Ray はそのリストを自動的に作成しました。

Amazon CloudWatch の実装

開発チームはメトリクスを表示するための一元化されたダッシュボードを作成するために Amazon CloudWatch を使用し、ECS 上のアプリケーションの応答時間が長くなったときに通知するアラームを作成しました。数日のうちに開発チームはアプリケーションの応答時間のメトリクスを持つ基本的なダッシュボードを手に入れました。開発チームは、HTTP ステータスコード (200、3xx、4xx、5xx) を含むログのいくつかのメトリクスフィルターを作成し、これらをカウントした情報をダッシュボード上のグラフに表示できるようにしました。そして、応答時間と HTTP ステータスコードに基づいてアラームを追加しました。開発チームはわずか数週間で、意味のあるグラフやアラームを表示し、十分に機能する CloudWatch ダッシュボードを手に入れました。

開発チームは最近、SLI/SLO メトリクスのモニタリング用に 2 つ目の CloudWatch ダッシュボードを構築することにしました。CloudWatch は ECS 上のアプリケーションのパーセンタイル (P50 と P95) を簡単に表示することができます。開発チームは、組み込み済みのパーセンタイルを使用して、SLI/SLO メトリクスを監視できるグラフをすぐに設定できました。

メリット

開発チームは Amazon CloudWatch のアラームによってほぼリアルタイムに通知されるようになり、本番環境の問題へ迅速に対応することが可能になりました。Amazon CloudWatch はより柔軟性があり、開発チーム自身がアラームを微調整することができます。また AWS X-Ray を使用しているので、例えば ECS 上のアプリケーションがデータを返さなかったり、入力の実行に時間がかかっていたりする場合にチームの誰もがレポートを調査できます。

まとめ

Vanguard 社の開発チームは、ECS 上のアプリケーションのオブザーバビリティ (可観測性) を向上させたいと考えていました。開発チームはオンコールプロセスに遅延や不確実性を出さないように AWS X-Ray と Amazon CloudWatch を選択しました。数週間のうちに、開発チームはアプリケーションに運用上の問題が発生したときに、ほぼリアルタイムでアラートを受け取ることができるようになりました。

Vanguard 社の実装について詳しく知りたい方は、2020 re:Invent session をご覧ください。

翻訳はソリューションアーキテクト加治が担当しました。原文はこちらです。

Amazon Web Services ブログ