AWS Lambdaでプロダクション対応のサーバーレス.NETアプリを構築する

Pulisher : Cloud Technology Center キム・ビョンジュ
Description : サーバーレスベースの.NETサービスのトレッキング、ロギング、指標収集をより簡単にするために、AWSが提供するAWS Lambda Powertoolsの紹介セッション

はじめに

LambdaはAWSで代表的によく使われるサービスの一つです。ただ、実際にアプリケーション、ウェブサービスをLambdaでサービスする顧客は非常に珍しいケースです。私の場合、小さなデータ処理や分析で使用し、APIと連動してたくさん使うのが一般的なケースです。

しかし、Lambdaを使ってアプリケーションを配布してテストするというテーマは、より多くのお客様をサーバーレスに導くことができると思い、申し込みをしました。

セッションの概略紹介

このセッションはAWS Lambdaで.Net(ドットネット)ベースのC#アプリケーションをどのように最適化するかについてのガイドを提供してくれるセッションです。LambdaのCold Startに対する深い悩みを一緒にしながら、どのような部分がユーザーが最適化が可能か教えてくれます。

Lambda handlerをネイティブに実装すると次のように実装することができます。

ASP.NET環境を利用して実装する場合、ソースはこのように変わります。

実際このようにコードを変えた時、Warm Startでは大きな差がないですが、cold startでは大きな変化があることが確認できます。

このようにstartup codeがラムダのcold startに影響を与えることが確認できます。

バンキングアプリケーションを考えてみましょう。性能が改善されましたね！しかし、このようなサーバーレスのラムダを改善してサービスに適用したとしても、サーバーレスの難しい点はモノリシックサービスに比べて問題がどこで発生したかを探すのが難しい点があります。

もちろん、直接的にcloudwatchにログを生成して使うこともできます。しかし、これは非常に不便で、コードに多くの変更を要求することもあります。

そこで、サーバーレスベースの.NETサービスのトレッキング、ロギング、指標収集をより簡単にするために、AWS Lambda PowertoolsをAWSで提供しています。

このようなpowertoolsを導入することで、コードは少なくしながらLambda Functionの詳細なモニタリングが可能になります。Initalからinvokeの新しい関数の実行時間まで確認することができます。

一般的にcloudwatchにロギングを残す時、定型化されないロギングを残すことになります。

従って、後日分析に活用するには多少の困難があるのも事実です。

しかし、Powertoolsを使って定型化された(JSON)形のロギングを残すことで、後々の分析にも活用することができ、既存のコードに比べてより少ないコードが入ります。

この全てを合わせて変えてみると、約半分近くのコードが消えてモニタリングが楽になったことが確認できます。

次の内容はAOTに関する内容でした。 Native AOTはコンパイル時にAOTコンパイルを行い、バイトコード(IL)ではなくネイティブコードでコンパイルする技術で.NET 7から使用可能な技術です。

起動実行時、JIT(Just-In-Time)コンパイル過程がないので、早くプログラムを開始することができます。

実際にAOTとAOT以外の.NETを比較してみると、ほぼ60パーセントに相当する性能の差が開いていることが確認できます。

AOTは1行追加するだけで、簡単かつ迅速に適用することができます。ただし、すべての.NETアプリケーションにすぐにAOTを使用することはできません。 一部のオープンソースライブラリはAOTをサポートしていない場合もあるので、使用には注意が必要です。

追加でLambdaをチューニングする場合、どんな方法でアプローチできるでしょうか？Lambdaの実行構造は次のようになります。実行環境を構築してコードをダウンロードしてランタイムを起動してfunctionコードを登録します。このような全ての過程が完了しないとLambdaが開始されます。ここでユーザーはコードのサイズがfunction codeのサイズを小さくしてラムダのコールドスタートを減らすこともできます。

セッションを終えて

このセッションをC#を利用した.NETアプリケーションの最適化方式も.NETアプリケーションがLambdaに入った時、どのような方法で最適化をすればいいのか詳しくガイドした良い事例の一つだと思います。

ただ、韓国の顧客が大半のJavaベースのアプリケーションやJSPベースのアプリケーションを動作させるため、適用には多少の困難があるかと思います。