API Gateway+Lambda環境でのCloudWatchメトリクスとアラーム設定のはなし

こんにちは。技術1課@大阪オフィスの柏尾(小4から重度の花粉症)です。

そろそろ花粉が飛び始めているようで、一度くしゃみが出ると止まらなくなります。
というわけで、 花粉症緩和する納豆「すごい納豆 S-903」 がとても気になっています。

鼻をズルズル言わせながらではありますが、前回のAPI Gateway+Lambdaでのステージ管理やCloudWatch Logsのログ運用のはなしに続き、今回は「API Gateway+Lambda環境でのCloudWatchメトリクスとアラーム設定のはなし」について書いてみたいと思います。

API Gateway側

まずは、API Gatewayのメトリクスおよび、CloudWatchによるアラーム設定についてです。

API Gatewayのメトリクス

API Gatewayには下記のメトリクスが存在します。

メトリクス名
「4XXError」の発生回数
「5XXError」の発生回数
「API メソッドの呼び出し」の回数
「統合のレイテンシー」
「レイテンシー」
「統合のレイテンシー」は、API Gateway がバックエンドにリクエストを中継してから、バックエンドからレスポンスを受け取るまでの時間(ミリ秒)で、「レイテンシー」は、API Gateway がクライアントからリクエストを受け取ってから、クライアントにレスポンスを返すまでの時間(ミリ秒)になります。

また、API Gatewayのキャッシュ設定が有効になっている場合は下記のメトリクスも取得されます。

メトリクス名
「キャッシュのヒットカウント」
「キャッシュのミスカウント」
「キャッシュのヒットカウント」は、API キャッシュから提供されたリクエストの数、「キャッシュのミスカウント」は、API キャッシュが有効になっているときにキャッシュからではなく、バックエンド(例えばLambda)から提供されたリクエストの数になります。

これらのメトリクスを見ることで、キャッシュのサイズや期間などをチューニングする際の判断材料とすることができます。

それぞれのメトリクスについての説明は下記リンクに記載されています。

Amazon API Gateway のメトリックスおよびディメンション http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/api-gateway-metrics-dimensions.html

API Gatewayのメトリクスを有効化する

注意点としては、これらのメトリクスはCloudWatchのカスタムメトリクスとして提供されており、デフォルトでは有効になっていません。

API Gatewayの各ステージの「設定」にある、「詳細 CloudWatch メトリクス有効化」のチェックを入れることでこれらのメトリクスの収集が開始されるようになります。

一般的なカスタムメトリクスと同様、課金が発生します。2017/02現在、Amazon CloudWatch のカスタムメトリクスの料金は、$0.30 メトリクスあたり/月 (最初の 10,000 メトリクス)になっています。また、最初の10メトリクス分は無料となります。

CloudWatch - 料金
https://aws.amazon.com/jp/cloudwatch/pricing/

「詳細 CloudWatch メトリクス有効化」の設定は、APIステージごとに設定ができますので、課金を抑えるために「開発:dev」「ステージング:stg」のステージでは設定無しにしておき、「本番:prod」ステージのみ有効化するといった運用が可能です。

API Gatewayのメトリクスに対してアラームを設定する

これで、「prod」ステージに対しては、API Gatewayの各メトリクスが取得できるようになりました。

これらのうち、「通常発生すると困るもの」については、アラームを設定しSNSで通知するように設定したいと思います。

4XX系のエラーは、いわゆるRESTfulなWebAPIの実装になっている場合、普通に発生しうるエラーですので、通常はアラーム通知は設定しません。(例えば、「GETしたリソースが存在しない場合は404を返す」といった実装になっている場合。)

一方、5XX系はAPI Gateway自体のエラーや、バックエンド処理のエラー(Lambdaの処理が異常終了するなど)が含まれますので、これに対してはアラームを設定しておいた方が良いでしょう。

パフォーマンス要件によっては、「統合のレイテンシー」や「レイテンシー」などにもアラームを設定しておいても良いかもしれません。

5XX系のエラーに対してアラームを設定する方法は下記のようになります。

「すべてのメトリクス」を選択すると、API Gatewayのカスタムメトリクスも表示されます。
対象となる「ApiName」「Stage」のメトリクス「5XXError」にチェックを入れます。 アラームの定義を行います。
ここでは、対象のAPIのステージ「prod」に対して「5XXErrorが5分間に合計1回以上発生した場合にメールリストに通知する」という設定をしています。 実際にAPIで5XX系のエラーを発生させると、設定したメールアドレスにアラームメールが届きます。

Lambda側

次は、Lambdaのメトリクスや出力されるログおよび、それらのCloudWatchによる監視についてです。

Lambdaのメトリクス

Lambdaには下記のメトリクスが存在します。API Gatewayとは異なり下記のメトリクスが標準メトリクスとして取得されます。

メトリクス名 説明
Invocations 成功または失敗したfunction呼び出しが含まれます。後述の「Throttles」にカウントされるものは含みません。
Errors function内でのエラーが原因で失敗した呼び出しの回数(応答コード 4XX等) 。

下記が含まれます。
  • 処理された例外 (たとえば context.fail エラーなど)
  • コードの終了を起こす処理されない例外
  • メモリ不足例外
  • タイムアウト
  • 権限エラー

下記は含まれません。
  • 同時オペレーションの制限を超える呼び出しレートによる呼び出し失敗 (エラーコード 429)
  • 内部サービスエラー (エラー コード 500) による呼び出しの失敗
Duration関数コードが実行を開始してから関数の実行が停止されるまでの実時間(ミリ秒)
Throttles 同時オペレーションの制限を超えるために抑制されたLambda function呼び出しの回数(エラーコード429)。
それぞれのメトリクスについての説明やLambdaの同時実行制限等については、下記リンクに記載されています。

AWS Lambda のメトリックスおよびディメンション http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/lam-metricscollected.html

AWS Lambda の制限
https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/limits.html

Lambdaのメトリクスに対してアラームを設定する

ここで設定しておいた方が良さそうなものは「Throttles」ぐらいでしょうか。 同時実行数を超えた呼び出しが行われた場合、Throttlesのカウントが増えますので、「5分間の合計が1を超えた場合通知する」というような設定にしておくと良さそうです。


※設定方法はAPI Gatewayの場合と同じですので省略します。

Lambdaのログのメトリクスフィルタ設定とアラーム設定

CloudWatch Logsの「メトリクスフィルタ」という機能があり、これを使って「ログ内に特定のパターンが出現した場合に通知」というような設定ができるようになっています。

ただ、これは「ロググループ」に対する設定になりますので、Lambdaに「dev」「stg」「prod」のようなエイリアスを作成していても、その単位ではメトリクスフィルタを設定できません。

前回のエントリでも書いたように、ログ出力時に、ログ内に環境名を出力しておくことで、メトリクスフィルタのフィルタパターンで「"stage:prod" "ERROR"」のように設定しておけば、「(API Gatewayのprodステージから呼び出される)prodエイリアスのfunctionにエラー発生した時のみ通知」といったことが可能になります。

メトリクスフィルタを設定したいLambdaのロググループのメトリクスフィルタのリンクを選択します。 フィルタパターンを記入します。

「stage:prod」と「ERROR」という文字列を含むログ行が出現した際に、通知されるように設定します。「パターンのテスト」を使って、設定したフィルタパターンが機能するかをチェックすることができます。 作成したメトリクスフィルタに対して、アラームを作成します。 「5分間に合計1回以上、メトリクスフィルタで設定したパターンのログが出力された場合に指定したメールアドレスに通知」されるように設定します。 実際にLambdaのログに通知対象となる文字列を出力してみます。 アラームが通知されました。 もう少し通知内容をカスタマイズしたい、ということであれば、前回のエントリに書いた「CloudWatch Logsのサブスクリプション機能」を使い、フィルタパターンにマッチしたログをLambdaに処理させてメッセージを加工して通知、といったことも可能です。

まとめ

今回は、

API Gateway
・カスタムメトリクスの出力設定とそれに対するアラーム通知設定

Lambda
・標準メトリクスとそれに対するアラーム設定
・CloudWatch Logsのフィルター&アラーム通知設定

のお話でした。

他にも、こんな方法があるよ、というのがあれば教えていただけると幸いです。(おすすめの花粉症対策も絶賛募集中です)

AWS運用自動化サービス「Cloud Automator」無料トライアルはこちらから

COMMENT ON FACEBOOK