AWS Lambda 関数をモニタリングしてみよう！
Author : 野邊 哲男
builders.flash 読者の皆さん！こんにちは！
AWS のシニアテクニカルトレーナー 野邊 (のべ) です。
今回は AWS Lambda 関数のモニタリングについて初学者の方向けに解説していきます !
なお、AWS Lambda の初学者の方は、この記事をご覧になる前に builders.flash の 「AWS Lambda 関数の実行の仕組みを知ろう！」 と 「AWS Lambda 関数に適切に AWS IAM のポリシーを設定しよう！」の記事を読んで頂くことをお薦めします！
また、今回の記事のタイトルの中で「AWS Lambda 関数」という言葉を使ってますが、記事の本文では用語として次のように使っていきますので、あらかじめ確認しておいて下さい！
- AWS Lambda : サーバーを意識せずにコードを実行できる AWS のサーバーレスコンピューティングサービス
- Lambda 関数 : AWS Lambda によって管理、実行されるアプリケーションのコードとその設定
ちなみに今回の記事に掲載しているスライドは、あくまで筆者のテクニカルトレーナーとしてのネタ帳の一部であり、AWS の有償トレーニングのテキストからの抜粋ではないことを念のためお伝えしておきます !
この連載記事のその他の記事はこちら
- 選択
- AWS Lambda 関数の実行の仕組みを知ろう !
- AWS Lambda 関数に適切に AWS IAM のポリシーを設定しよう！
- AWS Lambda 関数をモニタリングしてみよう！
「モニタリング」と「オブザーバビリティ」
みなさんは、オブザーバビリティ (Observability) という用語をご存じですか ?
オブザーバビリティは、一般的に「システムやアプリケーションの動作状況を把握し、運用において判断に必要な情報が取得できるか」という能力を表す用語で、日本語では「可観測性」と訳されることもあります。
システムやアプリケーションの能力の表現として「可用性 (Availability) が高い」や「拡張性 (Scalability) に優れた」といった言い方をすることもありますよね。それと同じように、例えば運用中のアプリケーションで何か問題が発生した時に、すぐに問題の原因を追究するために必要な情報を取得できる仕組み作りができていれば、そのアプリケーション環境は「オブザーバビリティが高い」または「可観測性に優れている」などと表現できます。次の図をご覧ください。
この図はイメージですが、オブザーバビリティを高める主な手段としてメトリクスや、ログ、トレースなどの収集、分析を行っていくことを表しています。もちろん、メトリクス、ログ、トレースだけを収集していればいいというわけではなく、要件やシステムの特性により収集すべきデータは異なりますのでご注意ください。
もしかすると、このオブザーバビリティという用語は、何となく意味合い的にモニタリングという言葉と似ているな、と感じる方もいるかもしれません。実はこれらの用語の使い分けについては厳密な定義はなく、人により解釈も様々です。
実は、この記事に執筆するにあたって、タイトルをどうしようか、もかなり悩みました。というのも、今回は Lambda 関数のメトリクスやログ、トレースをトピックとして扱うので、タイトルも「AWS Lambda 関数のオブザーバビリティ」にしたほうがいいのかな？と思ったからです。
ただ、私が普段、様々な AWS のトレーニングに登壇して受講者の皆さんから意見をきいている限り、「オブザーバビリティ」という用語をご存じない方も少なくないため、今回のタイトルには敢えて「モニタリング」という多くの読者に比較的馴染み深いと思われる用語を使うことにしました。(タイトルを見た読者が、オブザーバビリティって何やねん、よーわからんし読まんとこ ! となると悲しいですからね 😅) この記事を読んで下さったのを機として「オブザーバビリティ」という用語も覚えておいてもらえると嬉しいです !
ということで、今回は Lambda 関数の動作状況を把握するため重要な下記 4 点についてみていきましょう！
1. Lambda 関数のメトリクス
メトリクスとは、リソースやアプリケーションに関する測定値をもつ変数です。AWS では、Amazon CloudWatch というサービスで AWS のサービスの様々なメトリクスを自動的に収集して参照・分析することができます。もちろん、AWS Lambda に関しても様々なメトリクスが用意されており、その種類については AWS Lambda デベロッパーガイドの Lambda 関数のメトリクスの使用 - メトリクスの種類 で確認できます。AWS Lambda は、これらのメトリクスを 1 分間隔で Amazon CloudWatch へ送信しています。
さて、AWS Lambda にも多くの Amazon CloudWatch のメトリクスが使用できることはわかりましたが、これらのうち、どのメトリクスを活用していけばいいでしょうか ? もちろん要件次第ではあるのですが、もし「どのメトリクスを監視すればいいのか見当もつかない !」という場合は、ひとまず 下表のメトリクスに着目してみてはいかがでしょうか。
| Lambda 関数のメトリクス | 説明 |
| Invocations | Lambda 関数が呼び出された回数 (成功した呼び出しと Lambda 関数の実行中にエラーが発生した呼び出しを含む) |
| Errors | Lambda関数の実行中にエラーが発生した数。エラー率を計算するには、Errors の値を Invocations の値で割ります。このメトリクスのタイムスタンプは、エラーが発生した時点ではなく、関数が呼び出された時間を反映していることに注意してください。 |
| Duration | Lambda 関数の処理時間。平均値や最大値を求めることで、Lambda 関数が期待通りの速度で動作しているかを把握します。 |
これらのメトリクスは、AWS マネジメントコンソールで Amazon CloudWatch のページから参照できますが、Lambda 関数のページからも参照できます。
この図は、Lambda 関数のページからこれらのメトリクスを表示しているスクリーンショットです。Duration メトリクスは、最小値、平均値、最大値を表示してくれていますね。Errors メトリクスは成功率も表示してくれています。
クリックすると拡大します
なお、今回紹介した 3 つのメトリクスですが、呼出し回数のことを Rate という言葉で表した場合、それぞれの頭文字をとって RED メソッドと呼ぶことがあります。RED メソッドは、Lambda 関数に限らず、リクエストを受け付けて処理を行うアプリケーション全般で注目すべきメトリクスです。まずはこの 3 つのメトリクスを監視することから始め、必要に応じて他のメトリクスも追加していくという方法もありますね。
また、Amazon CloudWatch は、Lambda 関数に限らず全てのメトリクスの保存期間が 15 ヶ月であることも留意しておきましょう。それ以上の期間でメトリクスのデータを保存したい場合は、Amazon CloudWatch の API である GetMetricData や GetMetricStatistics などを使用して取得しておく必要があります。保存期間については Amazon CloudWatch の 「よくある質問」の「Q: すべてのメトリクスの保存期間はどうなっていますか?」 にも説明がありますので参照しておきましょう！
2. Lambda 関数のログ
AWS Lambda は、Lambda 関数の実行に関するログを自動的に Amazon CloudWatch に送信します。(ただし、これを許可するポリシーを付与した実行ロールを Lambda 関数に設定する必要があります。これについては「AWS Lambda 関数に適切に AWS IAM のポリシーを設定しよう！」の記事をご参照ください。)
また、Lambda 関数のコードの中で標準出力または標準エラー出力に書き込んだ内容も、Amazon CloudWatchに送信されます。ただ、Lambda 関数実行後に Amazon CloudWatch でログが表示されるまで 5 分から 10 分ほど時間がかかる場合があることは覚えておきましょう。
次の Python 言語の Lambda 関数のコードの例をみて下さい。
Lambda 関数のコードの例
import os
def lambda_handler(event, context):
print('## ENVIRONMENT VARIABLES')
print(os.environ['AWS_LAMBDA_LOG_GROUP_NAME'])
print(os.environ['AWS_LAMBDA_LOG_STREAM_NAME'])
print('## EVENT')
print(event)上記の例では、Lambda 関数のハンドラーの中から Python の print 関数を使用して文字列や環境変数の内容を標準出力へ書き込んでいますが、これらの内容は Amazon CloudWatch に送信され、ログとして参照できます。このとき、Amazon CloudWatch のロググループ名は /aws/lambda/Lambda 関数名 になります。
ログは、このロググループの中にログストリームという単位でまとめられています。ログの出力例をみてみましょう。(下記例ではログのタイムスタンプは割愛しています。)
ログ出力例
INIT_START Runtime Version: python:3.11.v9 Runtime Version ARN: arn:aws:lambda:ap-northeast-1::runtime:ca202755c87b9ec2b58856efb7374b4f7b655a0ea3deb1d5acc9aee9e297b072
START RequestId: d585f6eb-b7c7-46d3-bfc9-9318b0adb5eb Version: $LATEST
## ENVIRONMENT VARIABLES
/aws/lambda/MyLogFunction
2023/08/19/[$LATEST]1f7c2abf7f5a41fdbb95d4a36b69987a
## EVENT
{'key1': 'value1', 'key2': 'value2', 'key3': 'value3'}
END RequestId: d585f6eb-b7c7-46d3-bfc9-9318b0adb5eb
REPORT RequestId: d585f6eb-b7c7-46d3-bfc9-9318b0adb5eb Duration: 1.23 ms Billed Duration: 2 ms Memory Size: 128 MB Max Memory Used: 40 MB Init Duration: 394.62 ms上記例 の 1 行 1 行がそれぞれ Amazon CloudWatch のログとして出力されており、Lambda 関数のコードの例 で print 関数で出力されている内容を確認できます。それ以外の START や END 、 REPORT のログは下表の情報を出力しています。
| ログ | 内容 |
| INIT_START | 新しい Lambda 関数の実行環境が作成される時に出力され、ランタイムのバージョンとその Amazon Resource Name (ARN) を表示。 |
| START | Lambda 関数の実行の開始を表すログ。一意のリクエスト ID や Lambda 関数のバージョンを表示 |
| END | Lambda 関数の実行の終了を表すログ。START のログと同じリクエスト ID を表示 |
| REPORT | Lambda 関数の実行レポートを表すログ。
Lambda 関数の設定により、他にも AWS X-Ray のトレースに関する情報が出力されるケースもある。 |
上の表の INIT_START は、新しい Lambda 関数の実行環境が作成されるときに出力されるので、例えば コールドスタート時や 「プロビジョニングされた同時実行数」の設定によって実行環境が作成される時に出力されます。なお、コールドスタートや「プロビジョニングされた同時実行数」については「AWS Lambda 関数の実行の仕組みを知ろう！」の記事で説明していますので、ご参照ください！
Amazon CloudWatch でこれらのログを参照することで、個々のLambda 関数の実行に関する情報も確認できますね。これらのログは Lambda 関数のトラブルシューティング時に役に立つので、ぜひ覚えておきましょう！
ちなみに、上の ログ出力例 で Amazon CloudWatch における Lambda 関数のログストリーム名を見れましたが、なぜこのような名前 (下記) になっているのでしょうか？
2023/08/19/[$LATEST]1f7c2abf7f5a41fdbb95d4a36b69987a実は、このログストリーム名にも Lambda 関数の実行に関する情報が含まれています。上の例でいうと、2023/08/19 はログストリームが作成された年月日、[$LATEST] は Lambda 関数のバージョン、最後の 1f7c2a... のような文字列は Lambda 関数の実行環境の ID になります。
つまり、Lambda 関数の実行環境作成毎にログストリームが作成され、その実行環境で実行された Lambda 関数で出力されたログをグルーピングしています。これにより、同じ Lambda 関数に対する複数の呼び出しが、同じ実行環境で実行されたのか、異なる実行環境で実行されたのかを把握することもできます。
なお、Lambda 関数の実行環境のライフサイクルやスケーリング、Lambda 関数のバージョンについては「AWS Lambda 関数の実行の仕組みを知ろう !」の記事で解説していますので、この記事もぜひご参照ください！
また、Amazon CloudWatch にログを保存しておくには料金がかかりますので、料金表のページ も確認しておきましょう。
3. Lambda 関数のトレース
トレースは、実行したアプリケーションの一連の動作の情報をまとめたものです。AWS では、 AWS X-Ray というサービスでこのトレースを取得して分析できます。例として次の図をみてみましょう。
この図のように Lambda 関数 と他のサービスを組み合わせて一つのアプリケーションを構成した場合、Lambda 関数の実行、Lambda 関数のコードから Amazon DynamoDB や Amazon S3 など他のサービスへアクセスなどの一連の動作状況を X-Ray でトレースとして取得できます。
この X-Ray でトレースを取得する方法ですが、Lambda 関数で X-Ray のトレース取得の有効化の設定を行います。また、Lambda 関数のコードから他のサービスにアクセスしている場合で、そのアクセスに関するトレースも取得したい場合は、AWS X-Ray SDK を使用したコードの追加を行うことで実現できます。
.560bde3a5cab9c2dd2d8571a9521f95a7b98665b.PNG)
Lambda 関数への X-Ray のトレース取得の有効化は、AWS マネジメントコンソールを使用する場合、Lambda 関数のページで「設定」タブ、左側のメニューで「モニタリングおよび運用ツール」を選択、その後「編集」ボタンを選択して、「AWS X-Ray」セクションの「アクティブトレース」のトグルを ON にして、ページ下部の「保存」ボタンを選択することで設定できます。
またAWS マネジメントコンソールからこの設定を行うと、Lambda 関数の実行ロールに X-Ray にトレースを送信するために必要なポリシーが自動的に付与されます。
クリックすると拡大します
なお、Lambda 関数から他の AWS サービスへアクセスしている部分のトレースについては 前述のように AWS X-Ray SDK を使用したコードの追加が必要になりますが、このコードの書き方はプログラミング言語によって異なりますので詳細は AWS X-Ray のデベロッパーガイド でご確認ください。
下記は、Python の場合の例 (追記部分のみ抜粋) です。 この例では、aws-xray-sdk パッケージを追加して、ライブラリにパッチを適用する patch_all() を追記することで他のサービスへアクセスしている部分のトレースも取得します。
import boto3
from aws_xray_sdk.core import xray_recorder
from aws_xray_sdk.core import patch_all
patch_all()
...これで X-Ray トレースを取得する準備ができました。実際にアプリケーションを実行して取得したトレースの例を見てみましょう。
AWS マネジメントコンソールからは Amazon CloudWatch のページの 左側メニューの「X-Ray トレース」-「トレース」メニューから「トレース ID」のリンクを選択する参照できます。
トレースのページの上部に表示されるトレースマップでは、関連する AWS のリソースの関係性や、エラーの発生個所が色分け表示されています。トレースマップの中の AWS のリソースを表すアイコンをノードといいますが、このノードをクリックすると右側に発生した例外などの詳細な情報を表示できます。
クリックすると拡大します
トレースのページの下部に表示されるセグメントのタイムラインではトレース内の処理の内訳を確認できます。トレース内の処理の中で何か行われたか、どれくらいの時間がかかったか、どの処理でエラーが発生しているかなどの情報を確認できます。
クリックすると拡大します
レースの詳細を表示したり分析する機能は他にもありますが、上記のような情報を確認するだけでも動作状況の把握やトラブルシューティングに役立てることができそうですね !
なお、X-Ray の使用には料金がかかりますが、無料枠もありますので、詳細は 料金のページ でご確認ください !
少し深掘りしたい人向けのコラム：AWS X-Ray のパッシブ計測
Amazon API Gateway と Lambda 関数を統合する場合は、パッシブ計測という方法でも X-Ray のトレースを取得できます。パッシブ計測では、トレース取得を有効化していなくとも、他のサービスでトレース取得対象になっているリクエストのトレースを自動的に取得します。つまり、API Gateway 側で X-Ray トレースを有効化していれば、Lambda 関数側で有効化していなくてもトレースを取得できます。
この場合のメリットとして API Gateway 側でトレースのサンプリングレートを設定 できるという点があります。(Lambda 関数側でトレースを有効化した場合のサンプリングレートはあらかじめ決められており、変更できません。)
ただし、パッシブ計測を行えるのはあくまで Lambda 関数を呼び出す AWS サービス側で X-Ray トレースの取得を有効化できるものに限られます。例えば API Gateway の他に Amazon Simple Notification Service (Amazon SNS) などでも有効化できます。これら以外のサービスが Lambda 関数を呼び出す構成でトレースを取得するには、やはり Lambda 関数側でトレースを有効化する必要があることは注意しておきましょう。
.9ec68a63be6ff418fd09327594abb4949bf15b4c.PNG)
パッシブ計測については AWS X-Ray デベロッパーガイド の AWS X-Ray と他の AWS のサービスの統合 や AWS Black Belt Online Seminar の AWS X-Ray (動画) でも説明がありますのでそちらもご参照ください。
4. Amazon CloudWatch Lambda Insights
AWS Lambda のメトリクスについてはすでに説明しましたが、Amazon CloudWatch Lambda Insights (Lambda Insights) を使用すると Lambda 関数のシステムレベルのパフォーマンスメトリクス、例えば CPU 使用時間、メモリ使用率、ディスクやネットワークの使用量なども収集して分析できます。
Lambda Insights を AWS マネジメントコンソールから有効化するには、Lambda 関数のページで「設定」タブ、左側のメニューで「モニタリングおよび運用ツール」を選択、その後「編集」ボタンを選択して、「CloudWatch Lambda インサイト」セクションの「拡張モニタリング」のトグルを ON にしてページ下部の「保存」ボタンを選択します。
クリックすると拡大します
この設定により、Lambda 関数には Amazon CloudWatch Lambda 拡張機能の Lambda レイヤーが自動的に追加され、Amazon CloudWatch の Lambda Insights のページからシステムレベルのメトリクスを参照できるようになります。
例えばこの図のように、Lambda Insights のページ にある「関数の概要」セクションで Lambda Insights を有効化している複数の Lambda 関数のうち、CPU の消費時間が長いもの、メモリ使用率が高いものを容易に判別できます。
クリックすると拡大します
そして、その中から特定の Lambda 関数名のリンクを選択すると、その Lambda 関数の詳細情報 (最新の呼び出し一覧など) を表示できます。Lambda 関数で X-Ray のトレース取得を有効化していれば、その一覧の「トレース」列 の「表示」リンクをクリックして X-Ray のトレースを表示できます。
クリックすると拡大します
この Lambda Insights の使用には別途 料金 がかかることは留意しておく必要がありますが、Lambda 関数全体の中からパフォーマンスのメトリクスを参照し、問題がありそうな Lambda 関数を判別し、それにフォーカスしてより詳細を分析していくという流れで調査を行えるので、パフォーマンスの詳細分析という観点では非常に便利な機能といえますね。
まとめ
今回は AWS Lambda の初学者の方向けに Lambda 関数のモニタリングをテーマに、以下のトピックについて説明しました。
Lambda 関数はコードを書いてデプロイしたら終わりではなく、運用中の動作状況をモニタリングすることも重要ですよね。この記事の内容を参考に Lambda 関数のオブザーバビリティを高める取り組みに役立てて下さい！
今回の記事と、「AWS Lambda 関数の実行の仕組みを知ろう !」 や「AWS Lambda 関数に適切に AWS IAM のポリシーを設定しよう !」の記事も併せてを読むことで、AWS Lambda の基本として知っておきたいトピックを学習して頂けると思います。
みなさんがこれらの記事で、 AWS Lambda などのサーバーレスのサービスについて、より理解と関心を深めていただけると嬉しいです !
もっと、AWS のサーバーレスについて学びたい ! という方向けの学習パスとして、「 サーバーレスの始め⽅ 」という資料もありますので、ぜひご参照ください !
また、AWS では Developing on AWS や Developing on Serverless Solutions on AWS という有償トレーニングも提供しています。それぞれ ハンズオンを使用しながら AWS Lambda やサーバーレスアプリケーションの開発について 3 日間みっちりと学習できますので興味があればぜひご受講ください !
この連載記事のその他の記事はこちら
- 選択
- AWS Lambda 関数の実行の仕組みを知ろう !
- AWS Lambda 関数に適切に AWS IAM のポリシーを設定しよう！
- AWS Lambda 関数をモニタリングしてみよう！
筆者プロフィール
野邊 哲男
アマゾン ウェブ サービス ジャパン合同会社
AWS トレーニングサービス本部 シニアテクニカルトレーナー
自分が体験した「成功」と「失敗」、そこから「学んだこと」を皆さんにお伝えするべく、日々 AWS のトレーニングの登壇をしています。
最近は「仮面サーバーレス」として サーバーレスのトレーニング や デジタルトレーニング の情報を皆様にお届けしています。
AWS を無料でお試しいただけます