APIサービスを叩きすぎてスロットリングがかかってしまったのでアーキテクチャを改善したい


## 前提

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

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

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

## 課題

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

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

## 聞きたいこと

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

  * 一定期間内の外部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を使用せずに実現できます。

