こんにちは、Sreake事業部の横尾です。
前回は、Datadogの概要についての記事を書かせていただきましたが、 今回は、AWSのプロジェクトではお馴染みのLambda関数を、Datadog APMを用いてトレース情報の取得をしていきたいと思います。
また、本記事で使用してるAWSの構成は、TerraformチュートリアルにあるAPIGateway,Lambdaの記事で紹介されているものを用いています。 Lambda関数で使用している言語はNode.jsのため、他言語のLambda関数に適用する場合には、読み替えが必要となりますので、ご注意ください。
Lambdaインテグレーション/Forwarderのインストール
DatadogでLambda関数を初めて監視する場合には、まず、Datadogのコンソール画面にて、Amazon Lambdaインテグレーションのインストールを行う必要があります。
その際、Datadog Forwarderと呼ばれる、各種ログをDatadogへ送信するLambda関数を作成するため、インテグレーションのインストール時の指示に従い、適宜AWSアカウントに適用してください。

Lambdaレイヤーの追加
ここからは、実際に監視対象のAWSアカウントのLambda関数に対して、セットアップを行います。
まず、Node.js用のドキュメントにもとづき、Lambda関数に対してDatadogが公開しているLambdaレイヤーを追加していきます。
トレース情報を取得するLambda関数に、レイヤーの追加
からdatadog-lambda-jsリポジトリの最新のバージョンARNを追加します。
※ドキュメントでは、RUNTIMEとして指定できるNodeのバージョンがNode10-x
、Node12-x
と記載されていますが、現在ではNode12-x
、Node14-x
となります。

Lambda関数の構成変更
Lambda関数の呼び出しを行うhandlerメソッドを、以下のLambdaレイヤーのメソッドを呼び出すように変更します。
/opt/nodejs/node_modules/datadog-lambda-js/handler.handler

次に、Lambda関数の環境変数へ以下の3つの項目を設定します。
それぞれの環境変数の用途を知りたい方や、出力情報のカスタマイズを行いたい方はこちらのドキュメントをご参照ください。

以上で、トレース情報のセットアップが完了です。
トレース情報の確認
Lambda関数に適当なアクセスを行い、Datadogコンソールからトレース情報を確認してみましょう。
APM
→Traces
から確認できます。

詳細を確認したいデータを選択することで、以下のようなフレームグラフと関連するアプリケーションログを表示する事が可能です。

また、以下2枚のキャプチャ画像は、Lambda関数に最初にアクセスした記録と、その直後にアクセスした記録となります。実行時間を見比べるとわかるように、Lambda関数のコールドスタートにより、大きく差異が生じていることを確認できます。


さいごに
ここまでお読みいただきありがとうございました。
今回はAPI GatewayとLambda関数というシンプルな構成のため、フレームグラフも2つのリソースだけとなりましたが、公式ドキュメントの分散型トレーシングの画像にもあるように、実際のプロジェクトでは、処理フローにボトルネックの発生箇所が複数存在する場合があります。
その際に困らないよう、是非こちらのような監視リソースの可視化を進め、問題解決に努めていただければと思います。
最後に、本記事の検証で私が使用したTerraformリポジトリを、稚拙なコードではありますが、こちらに公開しております。
お手元の環境で構築する際はS3の名前変更等が必要ですが、ご参考になれば幸いです。
Datadogの導入、活用ついてのご質問・ご相談などお気軽にお問い合わせください

場所や規模に関係なく、あらゆるスタック/アプリケーションの内部を監視できるDataDogの導入、構築を支援いたします。