AWS Lambdaでのロギングのベストプラクティス

本日は、日常業務で非常に役立つと思われるいくつかの方法について説明します。 AWS Lambdaにおけるロギングのベストプラクティスをいくつか紹介し、なぜ、どのようにAWS Lambdaのロギングが簡素化されるのかを説明します。同様のトピックの詳細については、[本ブログの他のエントリーを参照してください](https://dashbird.io/blog/)。

それでは、基本から始めましょう（基本を理解している場合はスキップしてください）：AWS Lambdaでロギングはどのように機能するのでしょうか？ 


AWS Lambdaにおけるロギングとは
--------------------

AWS Lambdaサービスは、Lambda関数を自動的に監視し、Amazon CloudWatchに指標（メトリクス）を報告します。関数の不具合を解決するために、Lambdaログには関数のリクエストも記録されます。

また、Amazon CloudWatch Logsを介してコードによって生成されたログも保存されます。お察しの通り、コードにロギングステートメントを挿入することで、コードが正しく期待どおりに機能していることを検証できるのです。 LambdaサービスはCloudWatch Logsと自動的に統合され、コードからすべてのログをLambda関数に関連付けられたCloudWatch Logsグループに押し込みます。

これはデバッグ時に有益な機能ですが、ロギングがセキュリティリスクになる可能性もあります。何をログに記録するかについては、非常に注意する必要があります。また、本番環境で展開するときには、デバッグログのステートメントをコードから削除することを忘れないでください。そうしておかないと、機密データがCloudWatchに保存されたままになる可能性があります。

ヒント：ログステートメントを書き直し（リファクタリングすること）を忘れないでください！これは本稼働時のログとログステートメント変更の間に、シームレスなフィードバックループを設けるためです。面倒な作業かもしれませんが、これは継続的インテグレーションとデリバリーにとって非常に重要です。

Lambda関数からCloudWatchにログを記録する場合、料金は標準のCloudWatchレートのみで追加は発生しません。

AWS Lambdaでのロギングを集中管理化
----------------------

さまざまなログ集約サービスがありますが、なぜそれらが必要なのでしょうか？

新しいLambda関数を配備すると、それを使用してCloudWatchのロググループが、自動的に作成されます。 100個のLambda関数を使用すると、100個のロググループとなります。これで、何が起こっているかを追跡するのが少し面倒になる可能性があります。

ヒント：可観測性（オブザーバビリティ）サービスは、Lambda Logsを既存のCloudWatch Logsから、より集中管理化されたユーザーフレンドリーなログストレージに移動させるのに役立ちます。

ただし、AWSの出力トラフィックコストを念頭に置くことが大事です。AWSへのデータの取得は無料ですが、再度取得するには料金を支払う必要があるからです。また、AWSからログを取得するには、ログをサードパーティサービスに送信するLambda関数が必要です。このLambda関数は無料ではないため、並列呼び出しについて頭においておく必要があります。

同時に実行される100個の関数があるとしましょう。それらのすべてが、ログをCloudWatch Logsに押し込みます。これが、ログ配布関数の100個同時実行のきっかけとなる可能性があります。例えば、1つおきのLambda関数呼び出しに対して一々ログ配布関数を呼び出すとすると、そのリージョンで同時実行されている関数の数が、2倍になるかもしれません。全関数の同時実行は、リージョンごとに1000個に制限されています。

ログ配布関数のために、予約された並行性を購入することもできます。これにより、同時実行の最大数が制限されます。それでも尚、ログ配布関数が抑制されることで、ログが失われるリスクはあります。 

ストリーミングログ
---------

CloudWatchのコンソールを見ると、「アクション」タブの下に、Lambda関数毎に1つずつ、ロググループを選択するオプションが表示されます。それから、AmazonがホストするElasticsearchサービスにデータを直接ストリーミングするかどうかを決定できます。すでにElasticsearchサービスを使用している場合、これは非常に便利なのですが、まだこのオプションを利用していない場合でも、別の方法があります。

AWSからログを取得するためのより経済的な方法は、最初にCloudWatch LogsからKinesisストリームにログをストリーミングすることです。Lambda関数がログをバッチ処理し、選択したログ集約サービスに転送できるからです。

Kinesisを使用すると、ログ配布関数の同時実行性を完全に制御することができます。ログイベント率が上昇した場合は、Kinesisストリーム内のシャード数を増やして、ログ配布機能の同時実行数を増やすことができます。

Lambdaコンソールから新しい関数を作成する場合、いくつかのブループリントから選択し、CloudWatch Logsを他のログ集約サービスに押し込めます。このオプションを使用すると、CloudWatch Logsを好きなログ集約サービスに配布するLambda関数を作成できますが、注意が必要な追加事項があります。 

新しいロググループの自動サブスクリプション  
-----------------------

新しいLambda関数を作成するたびに、LambdaサービスはCloudWatch Logsに新しいロググループを自動的に形成します。是非回避したいのは、配布関数からロググループをサブスクライブする手動プロセスです。  

CloudTrailを有効にし、CloudWatch Eventsでイベントパターンを設定することで、ロググループが作成されるたびに様々なLambda関数を呼び出せます。 このようにして、作成された新しいロググループに、配布関数を自動的にサブスクライブするLambda関数を作成することができます。このセットアップは、CloudWatchコンソールから手動で行えます。 複数の異なるAWSアカウントを使用している場合は、手動で構成しないことをお勧めします。  

サーバーレス・フレームワークを使用すると、serverless.ymlファイルでこの関数のイベントソースを設定できます。無限の呼び出しループが作成されるため、ログ配布関数のロググループにサブスクライブすることは避けてください。 

コスト節約のためのログ保持のベストプラクティス
-----------------------

Lambdaが関数の新しいロググループを作成すると、保持ポリシーによってこれは永久に保持されます。しかし、ログは時間の経過とともに増加し、ログストレージが非常に高くつく可能性があるため、これは無駄です。幸いにも、保持ポリシーをより適切なものに自動更新する別のLambda関数を追加できます。

マスターした方が良い要習得トピックですから、ログ保持のベストプラクティスを掘り下げてくださいね。 

[Dashbird](https://dashbird.io/) --ロギングとモニタリングのより良い方法
----------------------------

![dashbird serverless dashboard](https://mk0dashbirdioprthk8x.kinstacdn.com/wp-content/uploads/2021/04/Screenshot-2021-04-01-at-13.03.24-2-1024x613.png)

Dashbirdを使用すると、わずかな労力で多くのことができるようになります。Dashbirdは、CloudWatch APIを介してログデータを直接収集します。つまり、DashbirdはコードレベルでLambda関数と統合する必要がなく、全てのLambda関数のCloudWatch Logsを、最初から簡単に読み取ることができます。

これは、Dashbirdを使用するときにオーバーヘッドがないことを意味します。追加のコストが発生したり、追加のリクエストによってアプリの速度が低下したりしないということですね。

![dashbird lambda logging](https://dashbird.io/wp-content/uploads/2021/04/dashbird-lambda-logging.png)

Dashbirdが提供する追加特典は、ログ検索です。これは、関数のログストリームをリアルタイム受信する設定を可能とします。Dashbirdが提供する利点のもう一つは、X-Rayです。そのシームレスな統合が、最高のトレース性をもたらします。X-Rayが有効になっている場合、X-RayトレーシングはDashbirdが提供する更なる利点です。このシームレスな統合により、呼び出しの実行内容を注意深く監視できます。 

![awsl lambda logging dashbird](https://dashbird.io/wp-content/uploads/2021/04/dashbird-lambda-logging-2.png)

AWS X-Rayは、呼び出しライフサイクル全体でデータをトレースできる強力なツールであるのと同時に、呼び出しフローの全範囲を追跡するツールとしても機能します。カスタムトレースを使用すると、X-Rayを使用してデータを手動で追跡できます。

ここで、是非言っておきたいことは、DashbirdはX-Rayオプションが有効になっているかどうかを検出する自動システムを装備することができるということです。アクティブなX-Rayモニタリングを使用してLambda関数に属する呼び出しを開始すると、X-Rayデータをオンデマンドで取得できると同時に、結果も表示されます。X-Rayの統合により、Dashbirdは、いつどのようにLambda関数が時間を浪費するかを教えてくれるので、将来的にそれを改善することができます。 

どこに導いてくれるのだろう？
--------------

必要に応じて、ログをログ集約サービスに直接配布するか、Kinesisログストリーミングを使用してストリーミングする必要があります。ログ集約サービスには、どれにも長所と短所がありますから、選択するときは注意を要します。

[良い点悪い点を知るために、ユーザーのコメントとサードパーティサービスの実例を読んでください](https://dashbird.io/customers/)。そうすれば、事前に次のことがわかります。

-   どの集約サービスにも期待できること
-   到達したくない状況を回避するための一般的方法 

AWS LambdaのDashbirdのロギングを試してみたいと思いませんか？詳細を確認してから、全プレミアム機能への14日間の無料アクセスを試してみてください。

クレジットカード、コード変更、セキュリティの問題への懸念は無用です。