## 前提

現在、AWSで動かしているアプリケーションにエラーが発生した時に、  
あるチケット管理システムに障害チケットを起票する社内用運用監視システムの保守をしています。

アーキテクチャは次のようになっています。

監視対象のアプリケーション  
\--> AWS CloudWatch Logs  
\--> サブスクリプションフィルタ  
\--> AWS Lambda  
\--> 外部チケット管理システム

## 課題

監視対象のアプリケーションが何らかの理由で発狂した場合、  
エラーログが大量に出力し、その結果、AWS Lambdaが大量に呼ばれる事象が発生しています。

その際に外部チケット管理システムのAPIを叩きにいくため、  
API側で429 Too Many Requestsのレスポンスコードを返すことがあり、  
たまにチケットが起票されないという問題が生じています。

## 聞きたいこと

下記の要件を満たすようにアーキテクチャを改善するとしたら、どうすればいいか？

  * 一定期間内の外部APIサービスの呼び出しを緩和する方法
  * アラートが複数回続いた後、別のアラートが来たら優先度を上げて対応できるようにすること

以上、宜しくお願い致します。
CC BY-SA 4.0
2023-04-15T03:36:16.003
94525
2023-04-27T01:44:06.137
2023-04-15T12:36:50.110
4236
2904
question
aws-lambda aws-cloudwatch
APIサービスを叩きすぎてスロットリングがかかってしまったのでアーキテクチャを改善したい
連続して発生するエラーログ一件一件に対して、各々チケットを一件ずつ起票する意味はないと思います。ひとまとまりで一件の障害でしょうし、複数の問題を抱えていたとしてそれは調査するまでわからないはずです。

[CloudWatch Logs
サブスクリプションフィルター](https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/SubscriptionFilters.html)よりも

  1. [フィルターを使用したログイベントからのメトリクスを作成](https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/MonitoringLogData.html)し
  2. [CloudWatchアラームを作成](https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)し
  3. [アラームアクション](https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions)としてはSNSトピックを指定し
  4. [SNSのイベントの送信先](https://docs.aws.amazon.com/ja_jp/sns/latest/dg/sns-event-destinations.html)としてLambdaを指定する

のが無難なところじゃないでしょうか。

条件を満たすエラーログがメトリクス値に対応します。アラームの設定では、メトリクス値がどのように推移したらアラームがアラート状態に遷移するか、正常に復旧させるか指定できます。

なお、

  3. アラームがアラート状態に遷移したという[イベントに反応するAmazon EventBridgeルール](https://docs.aws.amazon.com/ja_jp/eventbridge/latest/userguide/eb-create-rule.html)を作成し
  4. [イベントのJSONを変換](https://docs.aws.amazon.com/ja_jp/eventbridge/latest/userguide/eb-transform-target-input.html)してから[HTTPリクエストを発行](https://docs.aws.amazon.com/ja_jp/eventbridge/latest/userguide/eb-api-destinations.html)する

という方法が取れる場合、SNSとLambdaを使用せずに実現できます。
CC BY-SA 4.0
2023-04-15T12:14:28.160
94530
2023-04-15T12:14:28.160
4236
94525
answer
本件について、下記のクラメソさんの記事を参考にAWS SQS+AWS BridgePipesを間に置くことで解決しました。

<https://dev.classmethod.jp/articles/send-cloudwatch-error-logs-with-
eventbridge-in-batch/>

@sayuri さんのご回答ありがとうございます。  
回答いただいた内容は下記の理由により採用しませんでした。

  * 既存構成と異なる
  * アラートが発行されても該当のログがどこから出たのか渡されたメッセージではわからない。ログ本体を障害通知時には別途検索処理を実装する必要がある
  * 定時バッチ処理のように、ログ出力のON/OFFがはっきりしている場合、欠落期間が生じるのでメトリクスを元にちゃんと発火するように調整することが難しい
CC BY-SA 4.0
2023-04-27T01:44:06.137
94657
2023-04-27T01:44:06.137
2904
94525
answer