この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
いわさです。
前回、Transfer Familyのマネージドワークフローに関するスロットリングの仕様を検証し、紹介しました。
スロットルによってマネージドワークフローが実行されなかった場合は、自動で再試行されません。
よって、何らかの方法で検知したいところです。
私が検証出来た範囲では、CloudWatchの標準メトリクスにはスロットル制限による未実行は出力されません。
強いて言うと、ファイルPUT数とワークフロー実行数で差分が出るので、それを以て実行されていないと判断することは出来そうです。
また、CloudWatch Logsでは明確にスロットルによって実行されなかったログが出力されます。
このログからメトリクスフィルターを使うのが確実な感じもします。
{
"type": "ExecutionThrottled",
"details": {
"input": {
"initialFileLocation": {
"backingStore": "S3",
"bucket": "hoge0601trasnfer",
"key": "user1/hoge1.txt",
"etag": "f28339695e13a0073567e880ac43ddda"
}
}
},
"workflowId": "w-5e7112ad12dfeb5e2",
"executionId": "0c5b03fd-3da0-4386-b9d2-a1dd4b109523",
"transferDetails": {
"serverId": "s-854f6c60a42643588",
"username": "user1",
"sessionId": "4a1d7b6e4b4a0321"
}
}
この記事では、スロットル検知を行うためにメトリクスフィルターで検知でウォッチをしてみました。
また、すぐに適用出来るようにCloudFormationテンプレート化しています。
メトリクスフィルターを作成
前述のログ内容から、type
がExecutionThrottled
の数をカウントしてみます。
AWSTemplateFormatVersion: 2010-09-09
Description: ---
Parameters:
LogGroupName:
Type: String
MetricNamespace:
Type: String
Default: custom/managedworkflow/namespace
Resources:
ManagedWorkflowThrottledMetricFilter:
Type: AWS::Logs::MetricFilter
Properties:
FilterPattern: "{ $.type = \"ExecutionThrottled\" }"
LogGroupName: !Ref LogGroupName
MetricTransformations:
- MetricValue: "1"
MetricNamespace: !Ref MetricNamespace
MetricName: ExecutionThrottledCount
このテンプレートの実行にあたってCloudWatch Logsのロググループ名が必要です。
Transfer Familyのロググループ名はサーバー名と紐付いており、以下の手順で確認が出来ます。
このテンプレートからデプロイすると、対象のロググループに以下のようにメトリクスフィルターが作成されます。
メトリクスを確認
では、実際にスロットリングエラーを発生させて、メトリクスを確認してみます。
こちらも以前検証したときと同じ方法で、JMeterで一定時間で負荷をかけます。
100秒間に300スレッドで実行してみます。
1秒間に3スレッド実行される想定です。
そして、トークンバケットがたまった状態で最大100で秒間1補充されるので、50秒を過ぎたあたりからスロットリング制限によってワークフローが失敗するはずです。そして残り50秒間は2回/秒のペースで失敗する計算になるので、だいたい100前後失敗数として検知されるかなと。
実行した結果、以下のようになりました。
期待どおりエラー数が上昇しています。
合計値は105でした。いいですね概ね予想どおりです。メトリクスフィルターで検出する方法良さそうですね。
さいごに
本日はTransfer Family マネージドワークフローのスロットル制限による失敗数を検出するためにメトリクスを作成してみました。
ここからアラームを設定して再試行やらを実現出来そうです。