キューベースの処理遅延を非技術チームのメンバーに伝える方法は？

ApproximateNumberOfMessagesVisibleCloudWatchメトリックスのスケーリングポリシーを使用した一連のSQSキュー処理ジョブを担当しています。これらのジョブは、さまざまな理由で送信されたメッセージの量に追いつくことができません。

• サービスの低下により、処理可能なメッセージの容量が減少します。
• AutoScaling キューの深さが上昇し続けている間に最大制限に達しました。
• S3の停止AutoScalingは、キュー処理ジョブが需要に対応するために使用する他の依存AWSサービス（サービス）に影響します。

技術チーム以外のチームメンバーと停止について話し合うとき、顧客から見える品質低下につながる可能性のあるキュー処理の特定の遅延を伝えたいと思います。SQSキューでこれを行うにはどうすればよいですか？

すべての停止通信と同様に、非技術的な読者は主に次のことを理解しようとしています。

• どのくらいでしたか？
• どれくらい悪かった？

Amazon CloudWatchメトリックスは、これらの質問への回答に役立つSQSキューの以下のメトリックスを提供します。

• NumberOfMessagesSent：キューに追加されたメッセージの数。
• NumberOfMessagesReceived： ReceiveMessage APIアクションの呼び出しによって返されたメッセージの数。
• 近似数のメッセージ数：キューから取得できるメッセージの数。

正しくグラフ化すると、これらのメトリックはキュー処理の遅延を説明する際の強力な視覚的補助となります。キューメッセージを処理するジョブの能力が著しく低下した、私が経験した機能停止の例を次に示します。

NumberOfMessagesSentおよびNumberOfMessagesReceived

• グラフタイプ：折れ線グラフ
• 統計：合計
• 期間： 5分

これは、送受信されたメッセージ間のコントラストをグラフ化し、遅延の原因となっている処理コンポーネントを分離するのに役立ちます。このグラフでは、送信されたメトリックが通常の傾向を継続している間、受信されたメトリックが劇的に低下するため、問題はキュー書き込みコンポーネントではなくキュー読み取りコンポーネントにあると推測できます。

これは、イベントがどれくらいの期間/どれほど悪いかを答えますか？はい; 時間の経過とともに影響を受けるプロセスを説明します。

NumberOfMessagesReceivedおよびApproximateNumberOfMessagesVisible

• グラフタイプ：積み上げ面グラフ
• 統計：合計
• 期間： 5分

これは、受信したメッセージの上にキューの深さをグラフ化するので、キューがどこまでバックアップされ、どのように回復したかを示すのに役立ちます。このグラフでは、キュー読み取りコンポーネントで問題が発生している間にキューの深さが劇的にバックアップされ、キュー読み取りコンポーネントでメッセージの読み取りが再開されると回復し始めたことがわかります。

これは、イベントがどれくらいの期間/どれほど悪いかを答えますか？はい; 時間の経過とともに影響を受けるメッセージについて説明します。

グラフ化の議論

両方のグラフで、キュー処理は通常、ラインがオーバーラップしている場合は正常であり、ラインが分岐している場合は異常であると見なされます。これは、非技術チームのメンバーに教えるのが簡単なパターンであり、これらのグラフが提示されたときに、問題がある場所と方法をすばやく明らかにするのに役立ちます。

グラフ内の特定のポイントをさらに伝えるために、単純にそれらに注釈を付けることができます。

グラフ作成のヒント：

• 単位と軸にラベルを付けます。
• 一貫した色を使用して、グラフ全体でメトリックを一致させます。NumberOfMessagesReceivedは両方のグラフでオレンジ色であることに注意してください。これにより、さまざまなグラフで同じ指標を視覚化できます。
• 似たような指標を説明するグラフを縦に並べて、時間を超えて比較しやすくします。

_{注： StackExchangeでのプレゼンテーション用にこれらのグラフをフォーマットしました。したがって、これらは必ずしも事後の停止でそれらを表示する方法とは限りません。StackExchangeからそれらをわかりにくくするために、ここで左軸から値を明示的に削除しました。事後分析でそれらを保持する必要があります。}

追加のヒント

• チームに力を与える：これらのグラフを読むためにチームメンバーをトレーニングした後、それらを隠しておく理由はありません。CloudWatchダッシュボードを設定し、非技術チームのメンバーにCloudWatchへの読み取り専用IAMアクセスを許可して、いつでもこれらのグラフを表示できるようにすることを検討してください。
• 通知の設定：合意された高い値を超える場合は、ApproximateNumberOfMessagesVisibleメトリックに基づいてCloudwatchアラームを設定することを検討し、チームメンバーにサブスクライブして潜在的な問題を通知します。Cloudwatchアラームには、通知メールとともに送信される説明フィールドがあります。非技術的なメンバーがアラームを広めるのに役立つように、人間が読める説明を必ず含めてください。
• ：他のデータを探検パーエフゲニーさんのコメントを、CloudWatchのが提供するものを超えて他のデータを探索し、あなたのチームにそのデータを伝えることができる方法を考えます。キューでメッセージの有効期間を使用してヒストグラムを作成する彼の例は、この創造的な考え方の優れた例であり、アプリケーションのメッセージ送信時間とメッセージ受信時間の両方を記録することで実現できます。ReceiveMessage API応答の各キューメッセージの SentTimeStamp属性を介して、メッセージ送信タイムスタンプを取得できます。詳細はこちら。