Amazon Web Services ブログ

AWS マイクロサービスアーキテクチャを分析し、パフォーマンス問題を特定・解決する

Amazon Payment Services (APS) は、中東・北アフリカにおける決済サービスプロバイダーです。セキュアかつシームレスな支払い体験により、企業がオンラインプレゼンスを構築できるようサポートします。
Amazon Payment Services は、Amazon Elastic Compute Cloud (Amazon EC2)、Amazon Elastic Container Service (Amazon ECS)、Amazon CloudWatch、Amazon Simple Storage Service (Amazon S3) など、複数の AWS サービスに依存する広範囲かつ複雑なマイクロサービスベースのアーキテクチャを基盤としています。
APS の機能拡大に伴い、サービスの依存関係グラフも拡大し続けています。APS チームは、特定のフローでどのマイクロサービスが利用されているかを分析する、また、マイクロサービスのパフォーマンスと正常性を分析する際に問題に直面しました。このブログ記事では、マイクロサービスアーキテクチャにおいてユーザーリクエストフロー内でパフォーマンス問題を特定するプロセスについて説明します。

APS システムアーキテクチャ

APS チームは、リダイレクトページ、カスタマイズされた決済ページ、モバイル SDK など 7 つの加盟店統合フローを扱っています。また、世界中の決済業者や第三者決済サービスプロバイダとの統合も管理しています。APS チームは、顧客のパフォーマンスやレイテンシーの報告される問題への対応を担当しています。全体的なシステムのパフォーマンス改善、ビジネスの成長、スケーラビリティも保証する責任があります。

APS のマイクロサービスアーキテクチャは、支払いシステムのコンポーネントを支払い機能に基づいた小規模で疎結合なシステムに分割するのに役立ちます。これにより、APS チームはお客様のニーズに迅速に対応でき、お客様の問題に対処できるため、システムを柔軟に運用できるようになります。さらに、APS チームは必要に応じて柔軟にスケールアップまたはダウンでき、高い可用性と信頼性を確保しながら APS のお客様に最適なパフォーマンスとメンテナンス性の高いソリューションを提供できるようになります。

マイクロサービスアーキテクチャによる APS の課題

顧客からのリクエストを実行すると、複数のマイクロサービスが呼び出される可能性があり、呼び出されるマイクロサービスの数はフローが意図する機能によって決まります。
APS では対応する複雑なユースケースが多いため、多数のフローに対して膨大な数のサービスに依存関係が生じていました。
これらの問題により、顧客のパフォーマンス問題の根本原因の特定が遅れ、新機能の提供に影響を与えていました。この遅れは、顧客満足度にも悪影響を及ぼしていました。さらに、これがシステムの全体的な安定性に影響を与え、システムの停止にもつながる可能性がありました。

彼らが直面した課題は以下のようなものでした:

  • APS チームは呼び出されたマイクロサービス間の API 呼び出しのレイテンシーメトリクスを継続的に測定して、パフォーマンスやレイテンシーの問題を検出するのが大変でした。
  • マイクロサービスレベルでのレイテンシーのトラブルシューティングと評価に体系的なアプローチがありませんでした。結果として、パフォーマンスの問題に対処するときは手動でメトリクスの出力や追加のログを加える必要があり、オーバーヘッドと運用コストの増加につながりました。
  • 各マイクロサービス内のコードブロックのパフォーマンスを分析するツールが利用できませんでした。
  • マイクロサービスをまたいでリクエストのエンドツーエンドの流れを追跡する包括的なツールがないため、APS チームはアプリケーションとインフラストラクチャのパフォーマンスを可視化できず、運用面と事業面の両方で影響がありました。

ソリューションの概要

ソリューションを検討する際、APS チームは先行コストを最小限に抑え、管理のオーバーヘッドを減らすソリューションを求めました。アプリケーションアーキテクチャの性質上、APS チームは信頼性が高く、効率的で、手頃な価格で、長い導入期間やセットアップのプロセスを必要とせずに結果が得られるマネージド サービスを希望していました。APS チームの業務をサポートし、課題を解決するための理想的なソリューションとしてAWS X-Ray が選択されました。AWS X-Ray は、API、SDK、ダッシュボード、および他の AWS 監視ツールとの統合で構成される、分散アプリケーショントレーシングサービスです。

複数のプログラミング言語に対応しており、アプリケーションのコンポーネント構成マップを表示できます。
通常、オペレーションチームは Amazon CloudWatch ServiceLens および Amazon CloudWatch Synthetics と併せて使い、AWS ホストのアプリケーションの遅延や障害原因を特定します。AWS X-Ray を使うことで、オペレーションチームはマイクロサービスアーキテクチャにわたる遅延、スロットル、エラー率、障害について秒単位でメトリクスを収集できました。これにより、内部のマイクロサービスか外部サービスプロバイダのいずれであっても、パフォーマンスの問題や動作不良コンポーネントの根本原因を特定しやすくなりました。

その 3 日後には、AWS X-Ray が導入されただけでなく、APS チームは実際のメリットを認識し、その機能を活用し始めました。セットアップは簡単で、APS チームは AWS X-Ray の AWS ドキュメントに従い、以下の手順を実行しました。

次のイメージは、AWS X-Ray の全体のセットアップアーキテクチャ図です。

AWS X-Ray による課題解決とエンドユーザー体験の改善

AWS X-Ray を使用した結果、APS チームは基盤システムについて深い洞察を得ることができ、10 の改善領域、3 つのライフサイクル中の不要なネットワーク呼び出し、4 つの誤動作フローを特定しました。
その結果、レイテンシーが 25 % 低減し、全体的な顧客体験が改善され、顧客の信頼を得ることができました。以下、その方法を説明します。

    • HTTP Request Service map: AWS X-Ray のサービスマップは、顧客からのリクエストについて詳細なエンドツーエンドの視覚的な表現を提供します。バックエンド、フロントエンド、下流のサービス間の接続関係を示します。その結果、パフォーマンスのボトルネック、API レスポンスタイム、各ノードのネットワーク呼び出し回数を特定することができます。
      リクエストサービスマップは、AWS X-Ray コンソールのトレースタブでリクエストトレース ID をクリックすると取得できます。以下は、ノード間の接続関係を示すトレーストレースリストとリクエストサービスマップの例です。レスポンスタイム、リクエスト数、サービスノード名などのテレメトリデータが含まれています。

  • コードベースのエンドツーエンドトレーシングとセグメント化されたタイムライン: AWS X-Ray は、意図したコードクラスに @XRayEnabled アノテーションを付けることで、リクエストライフサイクル中に実行されるインラインコードブロックメソッドについてリアルタイムのトレースを提供できます。AWS X-Ray SDK は Aspect Oriented Programming(AOP) を利用して、レスポンスタイムやHTTPステータスなど、コードメソッドレベルでテレメトリメトリクスを出力します。
    AWS X-Ray トレースを通じて、APS チームはレスポンスタイムの長いコードメソッドを特定し、1 リクエスト中に呼び出されるメソッド数をカウントすることができました。これらのメトリクスを定量化することで、APS チームはデータに基づいてレイテンシーとパフォーマンスの改善施策を推進できました。

    AWS X-Ray のトレースは、高レスポンスタイムを消費するコードメソッドを特定し、リクエスト中に消費されるメソッド数をカウントするのに役立ちました。これらのメトリクスを定量化できる機能により、APS チームはデータに基づいたアプローチでレイテンシーとパフォーマンスの改善施策を推進することができました。
  • API パフォーマンスメトリクスを含む Amazon CloudWatch ダッシュボード: AWS X-Ray を使えば、レスポンスタイム、APIリクエスト数、エラー/フォールト率、スロットル率など、複数の APIに跨ったパフォーマンスの評価軸で、インサイトとメトリクスを得ることができます。これらのメトリクスは Amazon CloudWatch からアクセスできるため、APS チームはその強力な可視化機能を活用することにしました。
    データ可視化のために、APS チームは統計、期間、データバケッティングなどの機能を使用しました。棒グラフ、折れ線グラフなどの Amazon CloudWatch の可視化機能を使えば、P50、P90、P99のレイテンシーメトリクスを観察することで、レイテンシーやパフォーマンスの問題がある領域に素早く焦点を当てることできます。
    これにより、潜在的なボトルネックを特定し、ユーザーエクスペリエンスを最適化し、強力な Amazon CloudWatch メトリクスアラームを活用してレイテンシーの問題を自動検出できます。

おわりに

要約すると、APS チームはレスポンスタイムが長いリクエストの根本原因を特定できました。APS チームはマイクロサービス API での API レイテンシーに対する SLA (サービス レベル アグリーメント) を設定しました。
ダウンストリームサービスからの生のセグメントデータの収集と、AWS X-Ray を通じて公開されるメトリクスを使用してアラームの構成を行った後、ダウンストリームサービスのレイテンシーダッシュボードを作成しました。
改善の余地のある領域を特定・対応したことで、顧客リクエストのレスポンスタイムを 25 % 削減できました。

この記事はソリューションアーキテクト小森谷一生が翻訳を担当しました。（オリジナルはこちら）