MY Scribbling

AWS HERO Masanori Yamaguchi の雑なメモ

M1 Mac でビルドした コンテナイメージをArm64なAWS Fargateで起動する

この記事は AWS Advent Calendar 2021 22日目の記事です。

re:Invent 2021 直前の11月25日 に AWS Fargate の AWS Graviton2 のサポートが発表されました。

aws.amazon.com

今までAWS Fargateで起動するDockerイメージはx86_64(64ビット x86ベースシステム)用のコンテナイメージとしてビルドする必要がありましたが、Gravition2に対応したことにより、ARM64(64ビット ARMベースシステム)用にビルドしたコンテナイメージを起動することができるようになりました。

マルチアーキテクチャイメージやAmazon ECRでイメージマニフェストにARM64を含むイメージを利用し、AWS Fargateのアーキテクチャによって起動するイメージを切り替えることも可能となります。

今までテスト用途などでAWS Fargate用のコンテナイメージをローカルでビルドする場合は、Cloud9上でdocker buildしECRのプッシュするなどひと手間必要だったのですが、AWS FargeteがGravition2に対応したことにより、同じARM64アーキテクチャなM1 MacでビルドしたコンテナイメージをAWS Fargate上で動作させることできるようになったことが個人的にとても嬉しかったので記事にしてみました。

今回は Toriさんの everlasting-hey-yo を使ってM1 MacでビルドしたコンテナイメージをAWS Fargate上で動作させることができるか試してみます。

まず、Githubのeverlasting-hey-yoリポジトリから、Dockerfileとhey-yo.shを作業ディスプレイにPullしてきます。Dockerfile、hey-yo.shは何も編集せずにそのまま利用します。

Dockerfile

FROM busybox

COPY . .
RUN chmod +x ./hey-yo.sh

ENTRYPOINT [ "./hey-yo.sh" ]

hey-yo.sh

$ cat hey-yo.sh
#!/bin/sh

DEFAULT_MSG="Hey, Yo!"
ANOTHER_MSG="Check It Out! Yo!"

trap IWillNeverDie 15

Output () {
  MSG="$1"
  if [ "x${TIMESTAMP}" != "x" ]; then
    TS=$(date -Iseconds)
    MSG="${TS} ${MSG}"
  fi
  echo "${MSG}"
}

IWillNeverDie () {
  if [ "x${LET_ME_DIE}" != "x" ]; then
    Output "Hey, he..."
    sleep 3
    exit 0
  else
    Output "Hey, Hey, ${DEFAULT_MSG}!!"
  fi
}

while true
do
  MSG="${DEFAULT_MSG}"
  # GIVE_ME_PATTERNS
  if [ "x${GIVE_ME_PATTERN}" != "x" ]; then
    if [ $((${RANDOM} % 2)) = 1 ]; then
      MSG="${ANOTHER_MSG}"
    fi
  fi
  Output "$MSG"
  sleep 1
done

コンテナイメージをビルドします。

$ docker build .
[+] Building 4.5s (8/8) FINISHED
 => [internal] load build definition from Dockerfile                                          0.0s
 => => transferring dockerfile: 36B                                                           0.0s
 => [internal] load .dockerignore                                                             0.0s
 => => transferring context: 2B                                                               0.0s
 => [internal] load metadata for docker.io/library/busybox:latest                             3.4s
 => [internal] load build context                                                             0.0s
 => => transferring context: 60B                                                              0.0s
 => [1/3] FROM docker.io/library/busybox@sha256:b5cfd4befc119a590ca1a81d6bb0fa1fb19f1fbebd03  0.8s
 => => resolve docker.io/library/busybox@sha256:b5cfd4befc119a590ca1a81d6bb0fa1fb19f1fbebd03  0.0s
 => => sha256:b5cfd4befc119a590ca1a81d6bb0fa1fb19f1fbebd0397f25fae164abe1e8a 2.29kB / 2.29kB  0.0s
 => => sha256:db67d231d7de3d552b371543cf04d8f702482bc04d841997fcee2b1400d2cb83 527B / 527B    0.0s
 => => sha256:b34806a1af7a987f39848926ad7e4f8f191468473b1a97a6155ec855545bab 1.47kB / 1.47kB  0.0s
 => => sha256:092c822dea67ab2d03cf39c60d0f28925815e05899e5e780fd16b09c8d 828.49kB / 828.49kB  0.3s
 => => extracting sha256:092c822dea67ab2d03cf39c60d0f28925815e05899e5e780fd16b09c8da2756d     0.4s
 => [2/3] COPY . .                                                                            0.0s
 => [3/3] RUN chmod +x ./hey-yo.sh                                                            0.2s
 => exporting to image                                                                        0.0s
 => => exporting layers                                                                       0.0s
 => => writing image sha256:62e66d37c42a889b37137ee096e8b5969aeeaee6781a7b6f8c77ce02fa720bc5  0.0s

Use 'docker scan' to run Snyk tests against images to find vulnerabilities and learn how to fix them

続いてビルドしたイメージをECRにプッシュします。(事前にECR上のリポジトリは作成しておく必要があります)

$ docker tag 62e66d37c42a 12345678912.dkr.ecr.ap-northeast-1.amazonaws.com/everlasting-hey-yo:20a133e
$ aws ecr get-login-password --region ap-northeast-1 --profile ecr-push | docker login --username AWS --password-stdin 12345678912.dkr.ecr.ap-northeast-1.amazonaws.com
Login Succeeded
$ docker push 12345678912.dkr.ecr.ap-northeast-1.amazonaws.com/everlasting-hey-yo:20a133e
The push refers to repository [12345678912.dkr.ecr.ap-northeast-1.amazonaws.com/everlasting-hey-yo]
90ee5dfb3b89: Pushed
2da41e23cf2a: Pushed
48160e1f49aa: Pushed
20a133e: digest: sha256:5efe060bd6e2b0b82c8acdaf41df7d7bb8ce6cf8f6f066e9e67a1d6d86ebd200 size: 9

ECRのリポジトリにコンテナイメージがPushされました。

f:id:kinunori:20211222191302p:plain

つづいてタスク定義を作成していきます。マネージメントコンソールの場合、新しいECSコンソールでなければ、アーキテクチャの選択(Graviton2なタスク定義を作成)できないので注意です。

f:id:kinunori:20211222191322p:plain f:id:kinunori:20211222191338p:plain

タスク定義作成後は、これまでFargateでタスクを起動する時と同じように、サービスを登録していきます。

f:id:kinunori:20211222191356p:plain

タスクが実行中になりましたので、実際に動作をみてみましょう。うまく動作しているのであればログに Hey, Yo! が1秒間隔で出力されているはずです。

f:id:kinunori:20211222191426p:plain

無事動作していることが確認できました。

f:id:kinunori:20211222191456p:plain

M1 MacでビルドしたコンテナイメージをARM64なFargate上で動作させることができました。
実際にはマルチアーキテクチャーイメージを用いるケースが多いと思いますが、テスト用にM1 MacでビルドしたコンテナイメージをAWS Fargateでサクッと動かせるのは個人的に嬉しいアップデートでした。

The Amazon Builder’s Library "Reliability, constant work, and a good cup of coffee" を読んでみた

The Amazon Builders' Library をご存知でしょうか? re:Invent 2021 においても、新しくリリースされたサービスではありませんが、キーノートで触れられています。

aws.amazon.com

今回は 「Reliability, constant work, and a good cup of coffee」 という記事について取り上げてみたいと思いますが、この記事には、アーキテクチャ図は一切ありません。読み物として書かれています。

Builder’s Library で Architecture タグがついているのに、アーキテクチャ図がないということにとても興味が湧き、読み進めてみたのですが、とても面白かったので感じたことを記録として残しておきます。

aws.amazon.com

ざっくり書くと、エドワードホッパーの「ナイトホークス」という絵画をきっかけに、コーヒーポットがいかにニーズに沿ってシンプルでコスト低でかつ信頼性あるツールなのかというところから、AWSでは信頼性の高いシステムどのように実装しているのか、その設計について解説している話です。

re:Inventをはじめ、日本のカンファレンス、イベントなどの休憩時間に設置されるエンジニアとは馴染み深いコーヒーポット、YAPC::Asiaでは無限コーヒーなど呼ばれていたことを思い出します。やはりエンジニアにコーヒーは必要なのかという点もこの記事を読み始めたきかっけでした。

以下、本題。

Computers: They do exactly as you tell them

システムの信頼性を落とす要因は「不確実性」

信頼性の高いシステムを運用している場合、不確実性が最大の課題。不確実性は障害などによって引き起こされ、結果そしてシステムは高負荷や不安定な状態となり、処理停滞などを発生させる。

コーヒーショップの場合、対応が遅いことによる処理停滞は顧客の待ち行列となるが、システムの場合は物事はシンプルではない。処理停滞はクライアントやバックエンドへの再リクエストによってスパイラル的に影響を拡大する可能性がある。

再リクエスト、過負荷への対応は別の記事がある。(これらの記事も後日で読もうと思う)

Timeouts, retries, and backoff with jitter
https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/

Using load shedding to avoid overload
https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload/

「This is why many of our most reliable systems use very simple, very dumb, very reliable constant work patterns.」

信頼できるシステムはシンプルに一定の処理を提供する。re:Invent 2021のキーノートでWernerが話していたPrimitiveに繋がるのかもしれない。複雑な処理もPrimitiveの組み合わせで実現されるとうことWernerの言葉を思い出す。

信頼性の高いシンプルなシステムは3つの要素で構成される

  • 負荷によってスケールアップや処理遅延しないこと
  • どのような状態でも同じ動作をすること(モードがないと表現されていた)
  • もっとも必要な時にパフォーマンスを向上させること

キャッシュは応答時間を改善するが、キャッシュはキャッシュが存在している時と、存在していない時モードがあると説明されていた。キャッシュが存在していなかったり無効化された場合、システムに対する負荷は存在している時と一定にならないということ。

キャッシュだけを当てにするとキャッシュが効かない状態ではソースとなるシステムに負荷がかかり予期せぬ障害が発生可能性があるかもしれない、これがモードによる影響であることが説明されている。

なお、キャッシュに関する考えはこちらを参照することも記事内で触れられている。

Caching challenges and strategies
https://aws.amazon.com/builders-library/caching-challenges-and-strategies/

Amazon Route 53 health checks and healthiness

ヘルスチェックはとても重要な機能であるということが Route 53 のヘルスチェックをテーマに「モード」「一定の処理を繰り返しおこなうこと」について解説されている。

Route53がヘルチェックのノイズ影響をどのように対応しているか、ヘルスチェッカーによるチェックとその結果をアグリゲーターが条件付けして判定している。ヘルスチェッカーとアグリゲーターはまさに一定の処理を行う「Constant work」に徹している。

ヘルスチェッカーとアグリゲーターはセル設計が採用されていて、新しいヘルスチェック対象が追加されても影響がないように設計されている。各セルで処理できるヘルスチェック数の制限と現在の数を確認していて、制限が近づいたら新しいセルが追加される。

また、アグリゲーターは常に最大サイズのヘルスチェック結果を受け取るようになっている。最大サイズの至らない場合は、ダミーで埋めて常に最大サイズがヘルスチェッカーから送られ、それによって負荷が一定になるように作られている。

ヘルスチェックの対象がAZ障害などで一度に大量のヘルスチェック失敗を返してもヘルスチェックーとアグリゲーターが行う処理は変わらないということが大事な点だと思う。

続いて、ヘルスチェックに失敗した場合の、DNSレコード変更について触れられている。

何万のヘルスチェックが同時に失敗した場合、何万以上のDNSレコード変更が一気に行われる可能性があるが、どのように対応しているのかという点が興味深い。

アグリゲーターは、固定サイズのヘルスチェックステータスを数秒感覚でDNSサーバに送っている。DNSサーバは受信してメモリに保存する。アグリゲーターよりも多いDNSサーバがプッシュを受けれるようにしている。

DNSサーバはクエリに対して、その名前に紐づく全てのレコードを検索して、メモリ内のヘルスチェックステータスと相互参照する。ヘルスチェックのステータスが正常どうかにかかわらず、毎回のヘルスチェックステータスを参照しているので動作が変わらないということがポイント。

モードとは何か、モードが存在しないということの重要性を丁寧に説明されている章だった。

Amazon S3 as a configuration loop

Network Load BalancerはEC2ネットワークに組み込まれているAWS Hyperplaneノード上で実行されている。Network Load Balancerの設定は、Amazon S3上に保存されている構成ファイルによって扱われ、AWS Hyperplaneノード が Amazon S3から設定ファイルをフェッチする。設定変更がされていない場合でも数秒ごとにフェッチして、AWS Hypervisorノードは設定が前回と同じであってもロードする。

これにより、モードは1つで常に最大数の構成変更のロード処理を実行している。設定変更されたロードバランサーの台数による影響は受けない。

構成ファイルも「ダミー」により、最大サイズになっている。

無駄を感じるかもしれないが、とてもにシンプルで複雑な構成を実現するよりも、エンジニアリングコストが最低限に抑えられている。(初期の実装もメンテナンスも) ロードバランサーの機能拡張による影響も受けにくいし、設定変更処理がボトルネックになる可能性が排除されているものだと感じた。

Constant work and self-healing

前述された2つの例は、何かしらの処理失敗があったとしても自己回復を備えている。Constant work Constant work には自己回復が伴う傾向があるということ。

1回目の処理でネットワーク問題などで設定情報が破損した場合、2回目の処理で正常化される。Consitent workはモードを持たないので、常にゼロベースの処理が実行されるため、回復性を備えている。

対照的にワークフローの場合、ワークフローの処理順序、一部の処理でエラーが発生した際の回復処理などをあらかじめ組み込んで置く必要がある。

回復処理がまた動かない時に結果として人が介在しなければいけないし、それはConstant work で継続的なエラーが発生している場合も同じなのだけど、準備にかけるリソースが全く異なるということも伝えているのだと感じた。

Design and manageability

big-O と Constant work の関係性、つまり入力サイズに関係なく、一定数の処理を行うということ。Route 53 、Network Load Balancer においても、ユーザの設定変更量に変わらず、一定数の処理が実行されていることが説明されている。

ただ、懸念する点は、無駄が生じるということ。(コーヒーポットに数百人分のコーヒを入れた結果、飲む人が数人の場合、残りは排水溝行きになると表現されている)

この懸念は構成変更、ヘルスチェックのようなプロパゲーションシステムでは現実にならない。1つのヘルスチェックを伝播することと、多くのヘルスチェックを伝播することによる消費エネルギーのコストはほぼ変わらないため。ピーク時に100台のWebサーバが必要とするシステムに対し、常時100台のWebサーバを用意することは同義ではない。これはサーバ1台あたりのコストと伝播するヘルスチェックとのコスト比較になる。

コスト削減、さらにSutainableであることを考えると、スケーリングを第一に考えてしまうが、スケールアップによる影響が細微な場合は、シンプルな設計を用いた方がコスト低になるということも念頭に置いてアーキテクチャを設計することが必要。

The value of a simple design

シンプルな設計とは、パーツの少なさではない。わかりやすく、使いやすく、オペレーションしやすい設計を指す。(一輪車は自転車よりもパーツが少ないが乗りにくいと例えられている)

そのデザインが、その立ち上げに全く関係ないチームにとっても意味をなすものであれば、それは良いデザインである可能性が高いということも触れられている。

現にAWSでも"ループの中で毎回フルコンフィグレーションを適用する“というコンフィグレーションシステムは意外と多くConstant workは何度も再利用されていると説明されている。

さいごに

今まで考えたことがなかった内容が多く、アーキテクチャを考える上で読んでおいて良かったと思える記事でした。

Builder’s Library は必要になった時に参照することにも使えますが、時間がある時などに読んでみても良いヒントを得られるのでおすすめです。

日本語化されている記事もありますので、AWSがその中で培ってきたアーキテクチャをみなさんもぜひ活用してみてはいかがでしょうか。

aws.amazon.com

【AWS Lambda編】New Relic で サーバーレスアプリケーション をモニタリングする

はじめに

New Relic 初心者の私が AWS Serverless Workshop の1つ AWS Innovator Island にNew Relic を計装することまでの記録を記事として残していきます。

github.com

その初回をCalendar for New Relic | Advent Calendar 2021 - Qiita 21日目として投稿します。

New Relic に対するわたしの知識レベル

  • New Relic のトレーニング受講などの経験なし
  • New Relic のオンラインセミナーに2回ほど参加した(k8sとObservabilityがテーマのもの)
  • New Relic 本と New Relic 公式サイトの情報をもとに進める
  • この記事で New Relic のアカウントをはじめて作成しました!

1. AWS アカウントと New Relic アカウントの接続

New Relic にAWSアカウントのインベントリを作成して、Lambda 関数の CloudWatch メトリクスを収集するため必要な手順

必要なもの

  • AWS CLI v2 がインストールされていて、aws configure などにより profile が登録されていること
  • Python 3.3 以降がインストールされていること
  • newrelic-lambda CLI がインストールされている
    pip3 install newrelic-lambda-cli でインストールできる
  • New Relic アカウントに対して、管理者の役割、またはインフラストラクチャマネージャーのadd-on role が必要(インフラストラクチャマネージャーの add-on role が何かは分からなかった
  • New Relic API ユーザーキー
  • IAM リソース、マネージドシークレット、Lambda関数 を作成するためのアクセス許可を持つIAM ユーザー(プロファイル)
    必要な権限は https://docs.newrelic.com/jp/docs/serverless-function-monitoring/aws-lambda-monitoring/enable-lambda-monitoring/account-linking/ に記載されている
1-1. newrelic-lambdaCLI をインストールする
$ pip3 install newrelic-lambda-cli
1-2. new relic cli を使って AWS アカウントと統合する
newrelic-lambda integrations install --nr-account-id <YOUR_NR_ACCOUNT_ID> \
--nr-api-key <YOUR_NEW_RELIC_USER_KEY>

任意の AWS CLI プロファイルを指定する場合は、--aws-profile オプションをつける

$ newrelic-lambda integrations install --nr-account-id 3XXXXXXX --nr-api-key NRAK-QQQQQQQQQQQQQQQQQQQQQQQQQQQ --aws-profile nr-test

下記のように実行ログが出力される。✨ Install Complete ✨ が出れば AWS アカウントと New Relic アカウントの接続は完了となる

Validating New Relic credentials
Retrieving integration license key
Creating the AWS role for the New Relic AWS Lambda Integration
Waiting for stack creation to complete... ✔️ Done
✔️ Created role [NewRelicLambdaIntegrationRole_3XXXXXXX] in AWS account.
Linking New Relic account to AWS account
✔️ Cloud integrations account [New Relic AWS Integration - 1XXXXXXXXXXXX] was created in New Relic account [3XXXXXXX] with IAM role [arn:aws:iam::1XXXXXXXXXXXX:role/NewRelicLambdaIntegrationRole_3XXXXXXX].
Enabling Lambda integration on the link between New Relic and AWS
✔️ Integration [id=1XXXXXXXX, name=Lambda] has been enabled in Cloud integrations account [New Relic AWS Integration - 1XXXXXXXXXXXX] of New Relic account [3XXXXXXX].
Creating the managed secret for the New Relic License Key
Setting up NewRelicLicenseKeySecret stack in region: ap-northeast-1
Creating change set: NewRelicLicenseKeySecret-CREATE-1XXXXXXXX
Waiting for change set creation to complete, this may take a minute... Waiting for change set to finish execution. This may take a minute... ✔️ Done
Creating newrelic-log-ingestion Lambda function in AWS account
Setting up 'newrelic-log-ingestion' function in region: ap-northeast-1
Fetching new CloudFormation template url
Creating change set: NewRelicLogIngestion-CREATE-1XXXXXXXX
Waiting for change set creation to complete, this may take a minute... Waiting for change set to finish execution. This may take a minute... ✔️ Done
✨ Install Complete ✨

実行結果として、下記の CloudFormation スタックがデプロイされる

  • NewRelicLambdaIntegrationRole
  • NewRelicLicenseKeySecret
  • NewRelicLogIngestion

2. テスト用の Lambda 関数による動作確認

公式手順: https://docs.newrelic.com/jp/docs/serverless-function-monitoring/aws-lambda-monitoring/enable-lambda-monitoring/instrument-example/

独自の Lambda 関数に計装する前にテスト用の Lambda で計装を学べるとのこと。これをスキップすると後でハマりそうなので試してみる。

Node.js、Python、Go、Java、.NET それぞれテスト用の Lambda 関数 があるが、Innovator Islands で使われる Lambda 関数は Node.js なので、今回は Node.js の Lambda 関数 を試してみる。

必要なもの

2.1 デプロイスクリプトの実行

githubリポジトリをクローンする

git clone [https://github.com/newrelic/newrelic-lambda-extension.git](https://github.com/newrelic/newrelic-lambda-extension.git)
cd newrelic-lambda-extension/examples/sam/node

AWS CLI の実行にプロファイル指定が必要な場合は下記のように deploy.sh を修正する

#!/bin/bash

accountId=$1
region=$2
profile=$3

echo "region set to ${region}"

sam build --use-container

bucket="newrelic-example-${region}-${accountId}"

aws s3 mb --region "${region}" "s3://${bucket}" --profile "${profile}"

sam package --region "${region}" --s3-bucket "${bucket}" --output-template-file packaged.yaml --profile "${profile}"

sam deploy \
    --region "${region}" \
    --template-file packaged.yaml \
    --stack-name NewrelicExampleNode \
    --capabilities CAPABILITY_IAM \
    --parameter-overrides "NRAccountId=${accountId}" \
    --profile "${profile}"

AWS CLI の実行にプロファイル指定が必要な場合は下記の引数で deploy.sh を実行する

./deploy.sh <NEWRERICID> <AWS REGION> <AWS CLIのプロファイル>

AWS CLI の実行時にプロファイル指定が必要ない場合は deploy.sh の修正は必要なく、第3引数を除外して deploy.sh を実行する

./deploy.sh <NEWRERICID> <AWS REGION> 

下記のように実行ログが出力され、newrelic-example-nodejs という Lambda 関数がデプロイされる

region set to ap-northeast-1
Starting Build inside a container
Building codeuri: /newrelic-lambda-extension/examples/sam/node/newrelic-example-node runtime: nodejs12.x metadata: {} architecture: x86_64 functions: ['NewRelicExample']

Fetching public.ecr.aws/sam/build-nodejs12.x:latest-x86_64 Docker container image......
Mounting /newrelic-lambda-extension/examples/sam/node/newrelic-example-node as /tmp/samcli/source:ro,delegated inside runtime container

Build Succeeded

Built Artifacts  : .aws-sam/build
Built Template   : .aws-sam/build/template.yaml

Commands you can use next
=========================
[*] Invoke Function: sam local invoke
[*] Test Function in the Cloud: sam sync --stack-name {stack-name} --watch
[*] Deploy: sam deploy --guided

Running NodejsNpmBuilder:NpmPack
Running NodejsNpmBuilder:CopyNpmrc
Running NodejsNpmBuilder:CopySource
Running NodejsNpmBuilder:NpmInstall
Running NodejsNpmBuilder:CleanUpNpmrc
make_bucket: newrelic-example-ap-northeast-1-3XXXXXX
Uploading to 655a6a97cb1410cc550ad7586848d5d1  128736 / 128736  (100.00%)

Successfully packaged artifacts and wrote output template to file packaged.yaml.
Execute the following command to deploy the packaged template
sam deploy --template-file /NR-Lambda/newrelic-lambda-extension/examples/sam/node/packaged.yaml --stack-name <YOUR STACK NAME>

    Deploying with following values
    ===============================
    Stack name                   : NewrelicExampleNode
    Region                       : ap-northeast-1
    Confirm changeset            : False
    Disable rollback             : False
    Deployment s3 bucket         : None
    Capabilities                 : ["CAPABILITY_IAM"]
    Parameter overrides          : {"NRAccountId": "3XXXXXX"}
    Signing Profiles             : {}

Initiating deployment
=====================

Waiting for changeset to be created..

CloudFormation stack changeset
-------------------------------------------------------------------------------------------------
Operation                LogicalResourceId        ResourceType             Replacement
-------------------------------------------------------------------------------------------------
+ Add                    Logs                     AWS::Logs::LogGroup      N/A
+ Add                    NewRelicExampleRole      AWS::IAM::Role           N/A
+ Add                    NewRelicExample          AWS::Lambda::Function    N/A
-------------------------------------------------------------------------------------------------

Changeset created successfully. arn:aws:cloudformation:ap-northeast-1:7XXXXXXXXXXX:changeSet/samcli-deploy1639833290/7b9bdabd-6dd0-45e8-b377-cc04161b0e44

2021-12-18 22:15:02 - Waiting for stack create/update to complete

CloudFormation events from stack operations
-------------------------------------------------------------------------------------------------
ResourceStatus           ResourceType             LogicalResourceId        ResourceStatusReason
-------------------------------------------------------------------------------------------------
CREATE_IN_PROGRESS       AWS::IAM::Role           NewRelicExampleRole      -
CREATE_IN_PROGRESS       AWS::IAM::Role           NewRelicExampleRole      Resource creation
                                                                           Initiated
CREATE_COMPLETE          AWS::IAM::Role           NewRelicExampleRole      -
CREATE_IN_PROGRESS       AWS::Lambda::Function    NewRelicExample          -
CREATE_IN_PROGRESS       AWS::Lambda::Function    NewRelicExample          Resource creation
                                                                           Initiated
CREATE_COMPLETE          AWS::Lambda::Function    NewRelicExample          -
CREATE_IN_PROGRESS       AWS::Logs::LogGroup      Logs                     -
CREATE_IN_PROGRESS       AWS::Logs::LogGroup      Logs                     Resource creation
                                                                           Initiated
CREATE_COMPLETE          AWS::Logs::LogGroup      Logs                     -
CREATE_COMPLETE          AWS::CloudFormation::S   NewrelicExampleNode      -
                         tack
-------------------------------------------------------------------------------------------------

Successfully created/updated stack - NewrelicExampleNode in ap-northeast-1

New Relic One のコンソールから確認すると Instrumental が Yes の Lambda 関数としてデプロイした Lambda 関数が表示されている

f:id:kinunori:20211219193553p:plain

実行時間やエラーレート、コールドスタート、さらにトレースなどの情報がとれた。Insturmental が Yes ではない Lambda 関数の場合、CloudWatch メトリクスとして記録されている情報は確認できたが、コールドスタートやトレースなどの情報は確認できないという違いがあった

手順1で作成された newrelic-log-ingestion という Lambda 関数は実行されていないようで、このLambda 関数の出番は今のところ不明

f:id:kinunori:20211219193608p:plain

次回は Innovator Island の Lambda 関数で New Relic へのテレメトリーデータ送信を計装してみる