サーバーレスアプリケーションは、クラウドネイティブな顧客にとって非常に重要です。そして、その機能に関する可視性を得るには時間と労力がかかることがあります。このブログでは、AWSを使用するエンジニア向けに、New Relicでのサーバーレスの計装設定をより簡単に行うためのヒントとコード例をご紹介します。APIゲートウェイ、Lambda、Amazon Relational Database Service(RDS)という3層のアプリケーションを例に挙げます。サーバーレス機能の計装に関するヒントと、デバッグ戦略について学ぶことで、New RelicでLambdaレイヤーを使用したサーバーレスの計装、または手動での計装ができるようになります。

New Relicのサーバーレス監視が初めてでも、既存の設定の最適化を検討中でも、このブログを読めば、New Relicでのオブザーバビリティの目的を達成しやすくなります。読み終わるまでに、サーバーレスコンピューティングの理解を深められるばすです。AWS向けのサーバーレス計装をすばやく設定するための知識とツールを得られるでしょう。

サーバーレスアプリケーションの監視がなぜ重要か

サーバーレスアプリケーションの監視は、問題を特定して対応したり、リソース使用を最適化したり、パフォーマンスを改善するために、なくてはならないものです。サーバーレスアーキテクチャーでは、基盤となるインフラストラクチャに直接アクセスできないため、監視は問題の検出と修正対応のために不可欠です。リソースの利用状況を監視し、使用を最小化したりワークロードの需要に合わせて割り当てを調整することで、機能のアーキテクチャーを最適化できます。パフォーマンスメトリクスも、コードの最適化や割り当てリソースを増やすなど、ボトルネックや改善を要する箇所へのインサイトを提供します。

サーバーレス監視の設定

この手順ガイドでは、AWSでのLambdaレイヤーを使用したNew Relicのサーバーレス監視の設定と手動計装にについて、AWS RDSで実行されるPostgresを使用します。言語にはNodeJSを使用します。

前提条件は以下の通りです。

  • AWS CLIがインストール済みであることを確認してください。
  • AWSでサーバーレスフレームワークを設定する
  • New Relicにサインアップまたはログインする
  • Node.js V16.x.x
  • RDS Postgresデータベースまたは任意のデータベースがあることを確認する(こちらのGit repoに、データベースにインポートするSQLダンプファイルがあります。このブログ記事では、RDS生成とデータベースインポートの詳細は説明しません)
  • Git(任意)

要件は以下の通りです。

Metrics Streamインテグレーションの設定

まず、New RelicのAWSインテグレーションをインストールして、AWSサービスに関する有意義なインサイトを得ることをお勧めします。すべてのCloudWatchメトリクスを監視するには、Amazon CloudWatch Metric Streamインテグレーションをインストールし、すべてのAWSサービスから、カスタムのネームスペースを含めた全メトリクスを監視します。追加のインテグレーションを使用して、利用できるCloudWatchのメトリクスを超えて主要サービスの可視性を拡張することもできます。

ステップ1:AWSインテグレーションを設定する:New Relicに移動し、Infrastructure > AWS > Set up AWS Integrations through the UIを選択する。

ステップ2:Use metric streamsを選択する。

ステップ3:AWS Identity and Access Management(IAM)内にロールを作成し、New Relicの信頼性を確立する。

ステップ4:ここで、ReadOnlyAccessポリシーをロールに添付する。

ステップ5:ロール名をNewRelicInfrastructure-Integrations.に設定する。

ステップ6(オプション):Budget Policy(予算ポリシー)を設定し、New RelicがAWSで設定された予算に関し、サービスの消費と使用コストを捕捉できるようにする。

ステップ7:アカウント詳細をNew Relicに追加する。

ステップ8:AWSのMetric Stream内でMetric Streamを設定し、API KeysでNew Relic取込みライセンスキーを取得する。

備考:AWS Configからのリソースのメタデータをtrueに設定して、メトリクスを強化してください。

ステップ9:スタックが作成を始めたら、New Relicに戻り、Doneボタンをクリックする。アカウントステータスのダッシュボードを選択し、Metric Stream Statusを確認する。

ステップ10:New Relicでは、メニューでAll Entitiesを選択する。エンティティとして使用できるAWSサービスが確認できる。

備考:すべてのAWSデータが表示されるまでに、数分かかります。

ステップ11:すでにLambdaを使用していた場合、インストール後にLambdaのエンティティが作成されているかもしれません。これは、サーバーレス機能を取得したためです。Lambdaの情報は捕捉しているものの、それらの計装はまだしていないことに注意してください。次のセクションでは、サーバーレスフレームワーク(SLS)で生成されたシンプルなLambda関数を使用して、AWSのデータベースのクエリを行います。New Relicのトレーシングのデータベース呼び出しを見ていきましょう。

Lambdaの計装

ステップ1:リポジトリを複製するか、任意のLambdaを使用する。

以下のコマンドを実行してリポジトリを複製します。他の方法を使用したい場合は、Githubリポジトリを確認してください。

git@github.com:Tirslo/serverless-nodejs-101.git

ステップ2:認証情報を暗号化する。

Lambdaを計装する前に、AWSシステムマネージャーを使用して、APIキー/認証情報をAWSパラメーターストアにアップロードしたことを確認します。ダミー機能でテストしている場合、このステップは省略可能です。ただし、認証情報の暗号化は必ず行うことが推奨されます。

AWSシステムマネージャーを使用し、以下のコマンドを実行して、CLIで簡単に認証情報を暗号化できます。

aws ssm put-parameter --name "pgPortDevRel" --type "String" --value 5432

データベースの認証情報とNew Relicの認証情報について、これらのステップを繰り返します。New Relic取込みライセンスキーはAPIキーにあります。

ステップ3:サーバーレス計装を設定する。

  • 計装を開始するには、任意のコードエディターを開いてリポジトリに移動します(Visual Studio Codeの使用がお勧めです)。使用可能なファイルのうち、serverless.ymlファイルのみを扱います。開いて作業を進めます。
service: blog-serverless
frameworkVersion: '3'

provider:
  name: aws
  runtime: nodejs16.x
  region: ap-southeast-2

functions:
  blog-function:
    handler: index.handler
    environment:
      PG_PASS: ${ssm:pgPassDevRel}
      PG_USER: ${ssm:pgUserDevRel}
      PG_HOST: ${ssm:pgHostDevRel}
      PG_PORT: ${ssm:pgPortDevRel}
    events:
      - http:
          path: /games
          method: GET
      - http:
          path: /addGames
          method: POST

この構成の設定はシンプルです。

  • サービスを作成し、クラウドプロバイダー、Lambdaランタイム、リージョンを特定して開始します
  • 機能セクションで、「blog-function」を作成し、必要な環境変数をデータベースの認証情報、ホスト、ポートにパスします

備考:これはシステムマネージャーからのAWS認証情報を参照します。

  • この例では、誰かがAPIゲートウェイ経由でこの機能にアクセスした際に起こる2つのイベントを指定します。GETリクエストでは、データベースに保管されるゲームリストが表示され、POSTリクエストはゲームを追加します。

備考:APIゲートウェイはイベントを指定するとデプロイされます。

では、ここからコードをどうやって計装するのでしょうか?ライブラリにコードを追加しなければならないのか、それともLambdaレイヤーなら魔法のように自動実行できるのでしょうか?Node、Python、Java8.al2、Java11を使用している場合、Lambdaを計装するのにコード変更は不要です!その他の言語やランタイムでは、こちらの手動計装方法に従う必要があります。

指定された言語については、Lambdaレイヤーは以下の通りです。

  • New Relicではいかなるコード変更も不要
  • New Relic APMエージェントが機能的に単一レイヤーを使用できるようになる
  • New Relic Lambda Extensionを設定すると、New Relicライセンスキーが自動で機密管理される
  • エクステンションが無効な場合、このプラグインがCloudWatchログサブスクリプションとサブスクリプションのフィルタリングを自動で設定する

この例ではNode 16.xを使用します。サーバーレスプラグインを追加します。Lambdasを計装するのに必要なことは、newrelic-serverlessプラグインのインストールのみです。

NPMでは以下の通りです。

npm install --save-dev serverless-newrelic-lambda-layers

YARNでは以下の通りです。

yarn add --dev serverless-newrelic-lambda-layers

  • インストール後、自身のserverless.ymlを変更します。以下のコードを使用します
plugins: 
  - serverless-newrelic-lambda-layers 

custom:
  newRelic:
    accountId: ${ssm:nrDevRelAccId}
    apiKey: ${ssm:nrDevRelKey}
    enableFunctionLogs: true
  • sls deployを使用してLambdaをデプロイします

サーバーレスフレームワークでのLambdaの計装は、このように簡単です。

ステップ4:計装されたLambdaを表示する。

  • 何らかのデータを作成します
  • New Relicへ移動し、all entitiesを選択します。Lambda functionsのセクションに、計装された列が YES となっているLambda関数があります
  • Lambdaのトレーシングを確認していくと、バックエンドのデータベースへのクエリが特定できます。エンティティマップが依存関係を特定します。New Relicで計装されていなくても「外部サービス」への依存関係を確認できます。適切な画面でクエリ分析に注目してみてください。クエリの実行と期間を確認し、以下のスパンでリクエストの各ステップと期間を表示して、さらに詳細を見ることができます
  • 左上には、Logsのタブがあります。New Relicは、調査されたトレースのLogs in Contextを自動的に相関させます。これにより、潜在的な問題をよりすばやく特定、調査できます。関連ログにアクセスするために、複数のUIを行き来するする必要はありません。Logs in Contextは、特定のサービスに限らず、利用できるすべての関連する依存関係について、コンテキストに沿ったログを提供します

Lambdaの計装がすべて順調に完了すると、New Relicでは以下のように表示されます。

よくあるトラブルシューティングのヒント

計装が正しく設定されていないと、計装された列は空欄になるか、LambdaがNew Relicで表示されません。

「New Relic上にLambda関数が表示されません(Function not in New Relic)」

  • Metric Streamsインテグレーションが正しく設定されていることを確認します。アカウントステータスのダッシュボード New Relic > Infrastructure > AWS > Account Status Dashboardで、エラーがないかを確認します
  • New Relic取り込みライセンスキーを使用していることを確認します(→ API Keys
  • Lambda実行ログでエラーがないかを確認します。成功の場合、以下のようなアウトプットが表示されます

「Lambdaランタイムがサポートされていません(Lambda runtime not supported)」

  • Lambdaレイヤーで、ランタイムがサポートされていることを確認します
  • ランタイムがサポートされていたら、New Relicのログで詳細を確認します。New Relicの機能からLambdaログに直接アクセスできます

計装されたLambdaを試す

Lambda関数を適切に計装することは、サーバーレス機能においてよりよい可視性を得る上で不可欠のステップです。正しい計装により、サーバーレス機能への重要なインサイトを提供され、幅広い可視性が得られるようになります。Lambda関数のパフォーマンスと動作を監視して、異常を検知できるようになります。

Lambdaレイヤーをオンにすると、コードレベルの計装をまったく必要とせずに、ロギング、トレーシング、Lambdaメトリクスにアクセスできることに気づくでしょう。これらのツールは、Lambda関数の監視と問題が深刻化する前の早期発見に欠かせないものです。

これらのツールを活用して、パフォーマンスの問題をすばやく発見し、エラーソースを特定して機能のパフォーマンスを最適化できます。このレベルの可視性は、サーバーレスアプリケーションの信頼性と規模拡張を確実に行うために、きわめて重要です。