2019.12.07 2024.06.12

AWSサーバーレスシステムにおける監視のコツ

shimo

こんにちは、下條です。

私は前職でシステム監視のミドルウェアを開発してきました。そして現職ではシステムの開発だけでなく監視にも携わっており、監視と縁が切れない人生を歩んでおります。

そもそも、システムの監視とは、システムが正常稼働してサービスが提供できていることを担保する、またサービス提供ができなくなった場合に迅速にそれを検知して対応するために行うものですが、今回はAWSにおけるサーバーレスシステムにおける監視のコツについて簡単に書いてみます。

サーバーレスシステムにおいては、サーバーがあるシステムと比較して、システム開発後の監視・運用コストは大きく減少します。ただし、だからといって監視が不要になるわけではありません。

なぜサーバーレスが注目されているのか？ゼロから学ぶサーバーレスアーキテクチャ（FaaS）入門

にも書かれているとおり、従来のサーバーありきのシステムとは少々異なったモニタリングが必要となってきます。

サーバーレスシステムの監視は不要？

現時点での答えはNoです。

サーバーレスアーキテクチャにおいてはサーバやOS、さらにそのより下のレイヤーまでAWSが面倒を見てくれます。したがって、OSやインフラはAWSが責任を持ってくれているので監視は不要ですが、以下大きく3つの観点での監視が必要となります。※その他、パフォーマンス監視等も必要になりますが、今回は省略します。

アプリケーションの監視: 開発したアプリケーションについてはプログラムのバグ等でエラーが出ていないかなど監視が必要です。
リソース監視: AWSのサーバーレスの話ですが、一部サーバーレスコンポーネントにおいて各種リソース制限値が設定されており、そこの上限に達していないかの監視が必要です。
課金監視: 無限にスケールしうるというシステムの特性上、課金状況の監視も重要です。

今回は、API Gateway、Lambda、DynamoDBなどからなる一般的なAWSにおけるサーバーレスシステムを想定して具体的に監視する項目を書いてみます。

1. アプリケーションの監視

具体的に見るべきメトリクスは以下です。

API Gatewayの5xxエラー
Lambdaのエラー

これらのメトリクスでエラーが発生した場合、基本的に調査や対処が必要となります。プログラム的な原因が多いとは思いますが、後述するLambdaのメモリ不足が原因といった場合もあります。

2. リソースの監視

サーバーレスにおいてはリソース監視のコストはかなり小さくなります。例えば、サーバーありのシステムにおける

CPU使用率
ディスク使用率

などは監視する必要はなくなります。

しかし、これはAWSにおけるサーバーレスシステムにおける特徴なのですが、一部コンポーネントにおいては何らかのリソース制限がついています。制限値に達してしまうとサービス影響が発生する可能性があります。具体的に重要なリソース制限は以下の通りです。

DynamoDBのプロビジョンするキャパシティユニット
Lambdaのメモリ使用率

したがって、モニターする重要メトリクスとしては以下となります。

DynamoDBのキャパシティユニット消費率
DynamoDBのスロットリング (キャパシティユニットを消費しきったときに発生します)
Lambdaのメモリ使用率

DynamoDBのキャパシティユニット

DynamoDBにおいては、事前に使用するキャパシティユニットをプロビジョニングします。それを超えてReadやWriteをすると、スロットリングが発生し、サービス影響が発生する可能性がでてくるため、キャパシティユニットの消費率およびスロットリングの発生を監視するとよいです。
ただし、事前にプロビジョニングする設定ではなく、オートスケールやオンデマンドの設定ができますので、例えばたまにアクセスのスパイクがあるようなケースではオートスケールやオンデマンドを利用したほうが、安価かつスロットリングが発生しなくなる可能性があるためおすすめです。

Lambdaのメモリ使用率

Lambdaではメモリを事前にセットする必要があるため、メモリが枯渇してプログラムの動作が遅くなるということが実際に起きます。したがってメモリ使用率を監視することは重要です。
※Lambdaのメモリ使用率は現状ではAWSのCloudWatchにおけるメトリクスとしては提供されておらず、ログに出力されるのみであり、取得にはちょっと工夫が必要です。

また、Lambdaで設定するメモリについてはCPU観点でも重要です。

https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/resource-model.html に

Lambda では、構成されているメモリの量に比例して CPU パワーが直線的に割り当てられます。1,792 MB では、関数は 1 つのフル vCPU (1 秒あたりのクレジットの 1 vCPU 秒) に相当します。

とあります。すなわち1792MBを確保しないとEC2を利用する際のvCPU 1コアと同等性能が出ないということであり、Lambdaのメモリ最小の128MBなどではCPUは相当に制限されてしか利用できないことになります。Lambdaは起動時の時間があるため、簡単な処理では気にならないかもしれませんが、ある程度の処理を実行するLambdaではこのCPU性能がネックになる場合があることに注意が必要です。したがって、Lambdaでの処理のネック CPU/メモリ/ディスクIO を把握した上で適切なメモリをセットすることが必要です。原則としてCPUネックなのであればメモリは上げたほうがパフォーマンスがよくなります。気になるのは課金で、メモリを大きくすると時間単位の課金金額は高くなります。ただ、CPUネックの処理であれば処理が速く終わる分、実際の利用料としてはあまり変わらなくなります。逆にディスクIOネックなLambdaにおいてはメモリを抑えておくのがよいでしょう。

3. 課金の監視

最後に、課金の監視です。
以前、LambdaからLambdaを呼び出す無限ループを書いてしまったことで、予期せず非常に課金額が膨らんだケースがありました。
サーバーレスにおいては無限にスケールする性質上、課金については従来以上に気をつける必要があります。
課金アラームは必ずセットしておきましょう。また、アラームだけでなく、課金額の推移も定期的にモニターしておいたほうがベターです。