イベント駆動型アーキテクチャーにおけるオブザーバビリティの重要性

非同期ワークロードの世界において、マイクロサービスはイベントを処理・ルーティングし、多数のアーキテクチャーコンポーネントや他のマイクロサービスをトリガーする上で重要な役割を担っています。本記事では、このような分散型かつ非同期ワークロードにおいて、なぜオブザーバビリティが重要なのかを解説します。

イベント駆動型アーキテクチャー (Event-Driven Architecture : EDA) とは？

イベント駆動型アーキテクチャーは、システムの状態によって生じる多数のイベントを処理したり、そのイベントを処理すべき適切なマイクロサービスにルーティングするよう設計されたソフトウェアアーキテクチャーのパターンです。EDA は主に、マイクロサービス間の疎結合を実現し、イベントの柔軟性やイベント駆動によるマイクロサービスの起動を可能にするために採用されています。

Confluentではイベント駆動型アーキテクチャー (EDA) を次のように定義しています。

イベント駆動型アーキテクチャー（EDA） は、リアルタイムでイベントの発生を検知・処理・管理・反応できるようにするソフトウェア設計パターンです。EDAを活用することで、イベントが発生した瞬間に、そのイベントに関する情報がリアルタイムで対応する必要のあるすべてのアプリケーション、システム、およびユーザーに即座に送信されます。マルチプレイヤーゲーム、オンラインバンキング、ストリーミングサービスから生成AIまで、世界中の組織の72%以上がEDAを活用して、アプリケーション、システム、プロセスを強化しています。

一般的な活用例：

• Eコマースアプリケーション：「カートに追加」「決済」「注文の配送」「通知」などのアクションがイベント駆動で処理されるようなプラットフォームでは、EDA により、イベントの発生時にこれらのプロセスがリアルタイムでシームレスに実行されます。
• サーバーレスアプリケーション：一般的に、サーバーレスアーキテクチャーは大きくEDAに依存しており、APIコールや状態の変化といったイベントをトリガーとして、特定の関数やプロセスが起動されます。このようなトリガーの処理には、イベントバス、キュー、またはトピックなどが一般的に使われます。サーバーレスアーキテクチャーがEDAを活用する方法について、詳しくはこちらをご覧ください。

AWSエコシステムにおけるサーバーレスワークロードでEDAを実装する場合、開発者やアーキテクトが主に注目するのは、次の3つの主要サービスです。

• Amazon Simple Queue Service (SQS)
• Amazon Simple Notification Service (SNS)
• Amazon EventBridge

これらのAWSサービスは、イベントルーティングを実現させるように設計されており、イベントプロデューサー（イベントをトリガーするマイクロサービスまたはアクション）と、それらのイベントを処理するイベント消費者との間の橋渡しとして機能します。

アーキテクチャーパターンを微視的に見れば、それは単に1つのAWSサービスが別のAWSサービスを呼び出す、という簡単な構造に過ぎません。たとえば、SQSキューがLambda関数を呼び出したり、Lambda関数がSNS トピックにメッセージを公開したりする場合です。

一見すると、この設定は極めて簡単に見えます。うまくいかないはずがない、と思うかもしれません。しかし、実際の運用環境では、EDAはシステムに深く統合されていることが多く、複数のイベントソースとメッセージが、それぞれのトピックやキューに応じて異なる宛先にルーティングされます。ここでは、EDAを活用した従来型アーキテクチャーが、全体像としてどのようなものかを見てみましょう。

このような構成では、エラーアラートを受け取っても、その原因となったサービスやイベントを特定するのは至難の業です。だからこそ、オブザーバビリティレイヤーを導入することで、特定すべき適切なスタックやイベントにフォーカスできるようになるのです。

EDAにおける監視の課題

さまざまな接点でEDAを活用する複雑なアーキテクチャーでは、監視なしで運用することが困難です。しかし、監視を導入すれば、また新たな課題が生じます。

複雑性の増加

複雑なアーキテクチャーでは、開発者やアーキテクトが取り組む計装へのアプローチ自体が複雑になります。単にLambdaレイヤーを追加するだけでは不十分で、AWS Lambda関数以外からのテレメトリーデータもオブザーバビリティや監視ツールに送信する必要があります。そのためには、CloudWatch Metric Streamsを実装し、それをNew Relicなどのオブザーバビリティプラットフォームと連携させることが必要となります。これにより、SNSトピックやSQSキューに公開されたメッセージ数などの、テレメトリーデータを追跡できるほか、SQSキューからLambda関数へのメッセージ配信における潜在的な遅延を特定することが可能になります。

テレメトリーの過多と不整合

分散型およびEDA環境では、テレメトリーデータの量が膨大になる可能性があります。計装対象となるマイクロサービスや各アーキテクチャーコンポーネントは、テレメトリーデータをNew Relicなどのプラットフォームに対して継続的に送信しているため、情報の流入が絶え間なく続きます。

しかし、多くの場合、アーキテクチャーのすべてのコンポーネントが計装されているとは限りません。つまり、あるマイクロサービスやコンポーネントからはテレメトリーデータが受信される一方で、別の部分からは何の情報も得られないという場合もありえます。このような不整合は、開発者やSRE、アーキテクトが、イベントの全体的な流れを追跡するうえで大きな複雑性を生み出します。包括的なコンテキストログやトレースがなければ、問題を特定して解決することは格段に困難になってしまいます。

悪夢となる冪等性

AWSのEventBridge、SQS、SNS などのサービスでは特に、メッセージの配信が一回限りとなることを保証しない(複数回送信される可能性がある)ため、冪等性の処理は非常に困難な課題となる可能性があります。イベントやメッセージが重複して配信されると、エラーのトレース、エラーの原因特定、イベントの発生状況の追跡が難しくなります。このように情報の明確さが欠如することは、オブザーバビリティや分散トレーシングを著しく複雑化し、大きな課題へと発展する可能性があります。

パフォーマンス監視

テレメトリーデータはさまざまなコンポーネントやマイクロサービスから生成され、EDAアプリケーションに不可欠なパフォーマンスメトリクスを提供します。このようなシステムにおける主な課題として考えられるのは、非同期アーキテクチャー特有のエンドツーエンドのレイテンシを管理することです。さらに、効率的な運用のためには、分散コンポーネント全体にわたって、リソース使用状況やパフォーマンスメトリクスを監視していくことも重要です。

カスタムダッシュボード

ここまでにご理解いただいたように、EventBridge、SQS、SNSなどのネイティブマネージドサービスの計装は非常に複雑です。このような状況でCloudWatchメトリクスのみに依存すれば、SRE、開発者、またはアーキテクトが、CloudWatchから必要なメトリクスを取得して、そこからインサイトを導き出すためだけに、カスタムダッシュボードを構築しなければならなくなります。

EDAにオブザーバビリティを導入する

EDAアプリケーションの監視に伴う課題を理解したところで、ここからはオブザーバビリティの核となる要素によってどのようにテレメトリーデータ収集を強化し、これらの複雑なシステムに対してより深いインサイトを提供できるかを見ていきましょう。

メトリクス

メトリクスは、システムの動作を定量的に把握するためのインサイトを提供し、さまざまなコンポーネントにおけるパフォーマンスの状況を明確に可視化します。たとえば、従来のLambda関数のスループット、同時実行数、エラー率などの主要なメトリクスから、受信メッセージ数、キューの健全性、遅延メッセージ数など、EDAに特化したサービス固有のメトリクスに至るまで、システム全体のパフォーマンスを可視化できます。

イベント

EDAの文脈において、イベントとは「message arrived」「 message delivered 」「 message published」などのように、状態の変化を示す個別の出来事を指します。これらのイベントは、イベントベースのアラートのトリガーとして活用でき、たとえばメッセージ配信失敗が一定数を超えた際に通知を送るといった使い方もできます。

ログ

ログは、イベントとそれに関連する実行時のコンテキストに関する詳細な記録を提供します。たとえば、「トピックに公開されたメッセージ」などの情報がログに記録されていれば、ビジネスロジックから、そのメッセージが指定されたトピックに正しく公開されたことがわかります。ログにメタデータを追加することで、実行された正確な場所を特定しやすくなり、効率的なトラブルシューティングにも役立ちます。

トレース

EDAのような分散型マイクロサービスアーキテクチャーでは、最初の呼び出しから他のマイクロサービスやアーキテクチャーコンポーネントをトリガーするイベントまで、実行経路全体をトレースすることが重要です。これらのトレースを一連のスパンとして可視化することで、特定の処理におけるパフォーマンスやレイテンシに関する貴重なインサイトが得られます。

オブザーバビリティの柱であるMELT（メトリクス、イベント、ログ、トレース）は、システムの動作に対する包括的な可視性を提供します。これらを組み合わせることで、迅速な問題の特定、根本原因の分析、プロアクティブな監視、効果的なアラートが可能となり、より回復力があり効率的なシステム運用が実現できます。

SQS・SNSとNew Relicのインテグレーション

オブザーバビリティは、EDAにとって極めて重要です。New Relicでは、Amazon SQSおよびAmazon SNS向けのインテグレーションを標準提供することで、このプロセスを簡素化しています。これらのインテグレーションにより、開発者やアーキテクトは、事前に設定されたダッシュボードを利用して、CloudWatchメトリクスおよびNew Relicとシームレスに連携できるようになります。

まず、ダッシュボードを設定する前に、Amazon CloudWatch Metric Streamsのインテグレーションを行いましょう。

CloudWatch Metric Streamsを設定する

SQSおよびSNSのメトリクスは、Amazon CloudWatchメトリクスから取得されます。インテグレーションを完了させるには、次の手順に従ってください。

1. New Relicアカウントにサインインし、「Integrations & Agents（インテグレーションとエージェント）」に移動します。

2. ここから「 Integrate your AWS Account（AWS アカウントの統合）」に進み、ログとメトリクスの両方を選択して続行します。

3. 「Choose a setup method（セットアップ方法の選択）」で、CloudFormationによる設定 "Automate AWS with CloudFormation (Recommended)" を選択し、画面の指示に従ってセットアップを完了します。

インテグレーションが完了すると、Amazon SQSやAmazon SNSのダッシュボードを設定する前に、CloudWatchメトリクスが New Relicアカウントに流れ込むのを確認できるはずです。

Amazon SQSダッシュボード

New Relicでは、Amazon SQSインテグレーションを提供しており、approximateAgeOfOldestMessage 、approximateNumberOfMessagesDelayed、numberOfMessagesSent、numberOfMessagesReceivedなど、CloudWatch から取得される主要なメトリクスを監視するための包括的なダッシュボードを利用できます。

さらに、NRQLを使用すると、簡単なクエリでニーズに合わせたカスタムベースボードを構築することも可能です。たとえば、次のクエリを使用すれば、SQS経由で送信されたメッセージの数を追跡することができます。
SELECT sum(`aws.sqs.NumberOfMessagesSent`) FROM Metric since 1 month ago until now

NRQL query for SQS Number of Messages sent

さらに、既存のダッシュボードにクエリを追加し、それに応じてアラートを設定することもできます。

Amazon SNSのダッシュボード

New Relicでは、numberOfMessagesPublished 、numberOfNotificationsDelivered、トピックのSubscriptionsConfirmed 、トピックのSubscriptionsDeletedなど、CloudWatchメトリクスから取得した各種メトリクスためのダッシュボードが作成される、Amazon SNSインテグレーションを提供しています。

メトリクスはNRDBで利用可能なため、 SELECT sum(`aws.sns.NumberOfMessagesPublished`) FROM Metric since 1 month ago until nowなどのクエリを実行して、公開されたメッセージ数を確認することもできます。

さらに、SQSインテグレーションや事前構築されたダッシュボードと同様に、ダッシュボードにクエリを追加したり、それに応じてアラートを設定したりすることも可能です。詳しくは当社ガイドを参照の上、Amazon SNSの監視インテグレーションを設定してください。