AWS Lambda のベストプラクティス

【51CTO.com クイック翻訳】概要

今日、サーバーレスはさまざまなクラウド アプリケーションで最も一般的なデプロイメント モデルになっています。この分野では、AWS Lambda が最も「ハードコア」なツールです。ほとんどの開発者は、Lambda を使用してクラウド関数コードをすばやく構築および実行した経験を多かれ少なかれ持っています。

ただし、AWS は、すべてのクラウドネイティブ メトリックを改善するために構成を自己学習して最適化する AI ロボットのように、スケーラビリティ、高可用性 (HA)、セキュリティ、パフォーマンスを管理および処理するわけではありません。したがって、開発者は設計時にコストとパフォーマンスのバランスをとる方法に特別な注意を払い、それを学ぶ必要があります。この記事では、Lambda の仕組みを理解して、Lambda を合理的かつ十分に使用する方法を紹介します。

高可用性

Lambda 関数を実行すると、実際にはデフォルトで外部ネットワークにアクセスできる VPC (仮想プライベートクラウド) 上で実行されます。ただし、同時に他のプライベート VPC にアクセスすることはできません。ここでの「外部ネットワークへのアクセス」とは、S3 や DynamoDB などの AWS サービスにのみアクセスできることを意味します。他の VPC で実行されている AWS リソース (RDS、Elasticsearch など) にアクセスすることはできません。

関数が Lambda によって管理される VPC 上で実行される場合、Lambda は VPC リージョン内の複数の AZ (アベイラビリティーゾーン) でのその可用性を担当します。しかし、ほとんどのエンタープライズ アプリケーション シナリオでは、RDS とその他の VPC リソースに同時にアクセスする必要があります。したがって、次の 2 つの側面を確保する必要があります。

• Lambda を設計し、異なる AZ で複数のサブネットを選択して高可用性を実現します。

• AZ に障害が発生した場合、同時実行される Lambda リクエストを処理するために、他の AZ に十分な IP アドレスを割り当てる必要があります。 (各 Lambda 実行には、リクエストを処理するためのプライベート IP アドレスが必要であることに注意してください。) したがって、HA を実現するには、サブネットに十分な IP アドレスを割り当てる必要があります。

同時実行性

AWS Lambda は独自の方法でスケーラビリティを実現しますが、限られたリソースに対しては、Lambda は次の同時実行制限に従います。

• アカウント レベル - デフォルトでは、各リージョンのすべての機能の値が 1000 に設定されます。
• 機能レベル - デフォルトでは、「予約されていないアカウントの同時実行制限」が使用されますが、これは適切な実装ではありません。すべてのアカウントレベルの同時実行制限を使い果たすことを回避するために、他の機能を制限します。したがって、何らかの理由でイベント数が急増した場合に、そのイベントがその関数にのみ影響し、その関数が隔離されるように、関数ごとに個別の同時実行数を保持する必要があります。

注意 - AWS は、特別に設定されていない関数リクエストを処理するために、少なくとも 100 の同時実行の予約されていない同時実行プールを常に保持します。つまり、最大 900 までしか割り当てることができません。

Lambda を専用 VPC で実行している場合はどうなりますか?

この場合、関数の ENI (Elastic Network Interfaces) のスケーラビリティに基づいて、十分な IP アドレスを要求する必要があります。次の式を使用して、ENI のおおよその容量を見積もることができます。

同時実行数 * (メモリ( GB) / 3 GB)

で：

• 実行数 - ワークロードの同時呼び出しの予想数 (1 秒あたりの呼び出し数 * 平均実行時間 (秒単位))。
• メモリ サイズ - Lambda 関数に設定されたメモリの量 (GB 単位) です。

Lambda の同時実行性を設計するときは、DynamoDB、RDS などの他の統合サービスの制限も常に考慮する必要があります。これらのサービスが処理できる最大接続数に基づいて、関数の同時実行性の制限を調整する必要があります。

スロットリング

上記の「同時実行」で述べたように、関数イベントが急増して同時実行制限を超えると、Lambda は新しいリクエストを処理できなくなります。時間内に対処しないと、業務システムに影響が出てしまいます。

1. Lambda 呼び出しが同期的である場合、直ちに 429 エラー コードが返されます。また、スロットルが機能レベルまたはアカウント レベルで設定されている場合、追加情報を受け取ることができます。したがって、API ゲートウェイなどの呼び出しサービスは、このような再試行の問題を処理する必要があります。
2. Lambda 呼び出しが非同期モードの場合、Lambda はイベントを破棄する前に 2 回だけ試行します。したがって、関数がイベントを処理できない場合は、後でデバッグや処理をするために、SQS または SNS で定義された DLQ (Dead Letter Queue) を使用する必要があります。 DLQ を定義し忘れると、それらのメッセージは直接破棄されます。
3. Lambda 呼び出しがポーリング モードに基づいている場合は、さらに次の 2 つのケースに分けられます。

• ストリーミング (Kinesis) の場合は、タイムアウトになるまで (最大 7 日間) 再試行し続けます。
• 非ストリーミング (SQS) の場合は、メッセージをキューに戻して、可視期間が終了した後にのみ再試行を開始し、正常に処理されるか、保持期間が終了するまで実行を続けます。

メモリとコストのバランス

Lambda では、メモリと CPU は密接に関連しており、メモリを増やすと CPU の割り当ても増えるはずです。したがって、Lambda の実行時間を短縮する必要がある場合は、メモリと CPU を増やす必要があります。ただし、詳細な実験を行うと、一定の範囲内でメモリを単純に追加しても、実行時間が大幅に短縮されることなく、取得コストが増加するだけであることがわかります。

現在、最適なリソース構成を見つけるのに役立つオープンソース ツールは市場にほとんどありません。個人的には、さまざまな CloudWatch ログを使用してメモリ使用量と実行時間を監視し、対応する構成を調整することを好みます。メモリパラメータを微調整すると、AWS の全体的なコストに大きな影響を与える可能性があるため、これを使用して最適なバランスを見つけます。

パフォーマンス - コールド スタートとウォーム スタート

Lambda を初めて呼び出すと、コードとすべての依存関係が S3 からダウンロードされ、コンテナが作成され、コードを実行する前に対応するアプリケーションが起動されます。このプロセス全体にかかる時間 (コードの実行を除く) は、コールド スタート時間と呼ばれます。コンテナが起動して実行されると、Lambda は後続の呼び出しのためにすでに初期化されており、アプリケーション ロジックを実行するだけで済みます。したがって、この期間はウォーム スタート時間と呼ばれます。

そこで質問ですが、コールド スタート時間を短縮するべきか、それともホット スタート時間を短縮するべきかということです。原則として、全体の実行時間の一部として、コールド スタートがほとんどの時間を占めるため、それを短縮する方法を見つける必要があります。ただし、実際には、高品質のコードを使用することでホット スタート時間を短縮できます。

次に、Lambda の全体的なパフォーマンスを向上させる方法について説明します。

1. コールド スタート時間を短縮するには、Java や C++ ではなく、Nodejs や Python などのインタープリタ型言語を選択します。
2. 何らかの理由で Java を使用する必要がある場合は、Spring Boot Web フレームワークの代わりに Spring Cloud Functions を使用してください。
3. ENI の設定には時間がかかり、コールド スタート時間が長くなるため、プライベート IP アドレスを持つ VPC リソースが必要な場合を除き、デフォルトのネットワーク環境を使用します。私の個人的な判断: AWS Lambda の新しいバージョンが近々リリースされるので、この点は改善されるはずです。
4. 関数の実行に関係のない依存関係をすべて削除します。必要なものだけを残してください。
5. コンテナが失敗するまで存続できるさまざまなグローバル/静的変数とシングルトン オブジェクトを使用します。したがって、後続の呼び出しでは、これらの変数とオブジェクトを再初期化する必要はありません。
6. 後続の呼び出しで再利用できるように、グローバルに定義されたデータベース接続を使用してください。
7. Java を選択する場合は、Spring Framework の代わりに、Dagger や Guice などのシンプルな IoC 依存性注入を使用します。
8. 同様に、Java を選択した場合は、依存関係の .jar ファイルを関数のコードから分離して、解凍プロセスを高速化します。
9. Nodejs を選択する場合は、Function js ファイルのサイズを 600 文字未満に制御し、V8 ランタイム環境を使用してください。 V8 オプティマイザーは、本体が 600 文字未満 (さまざまなコメントを含む) の関数をインライン化できます。
10. 同様に、Nodejs を選択した場合は、コードの縮小化や醜化を使用してパッケージのサイズを縮小できるため、パッケージのダウンロードにかかる時間が大幅に短縮されます。場合によっては、バンドル サイズが 10 MB から 1 MB に削減されることもあります。

• 縮小 – すべてのスペース、改行、コメントを削除します。
• 難読化 – すべての変数は難読化され、簡素化されます。

例、元のコード:

 var 組織名 = “xyz”
 var bigArray = [1,2,3,4,5,6]
 //コードを書く
( varインデックス= 0;インデックス< 6;インデックス++){
  console.log(bigArray[インデックス]);
 }

縮小後:

 var organizationname = “xyz”、bigArray = [1,2,3,4,5,6] for (var index = 0; index < 6; index ++) console.log(bigArray[ index ]);

醜化後:

 for (var o="myname",a=[1,2,3,4,5,6],e=0;e<6;e++)console.log(a[e])

インターネット上の多くの記事では、Lambda の実行環境にはすでに Nodejs および Python 用の AWS SDK が備わっていると述べられています。したがって、依存関係にそれらを追加する必要はありません。この機能はパフォーマンスの向上に役立ちますが、SDK ライブラリは定期的に新しいパッチでアップグレードされるという問題が隠れています。 Lambda のさまざまな動作に影響を与えないようにするには、独自の依存関係管理方法を採用する必要があります。

安全

1. 各機能に IAM ロールを割り当てます。複数の機能に同じ IAM ポリシーが必要な場合でも、1 つの IAM ロールは 1 つの機能にのみマップする必要があります。これにより、特定の機能のセキュリティ ポリシーを強化する必要がある場合に、最小権限のポリ​​シーを維持するのに役立ちます。
2. Lambda は共有 VPC 上で実行されるため、コード内に AWS 認証情報を保持することはお勧めできません。

• ほとんどの場合、AWS SDK を使用して AWS サービスに接続するには、IAM 実行ロールで十分です。
• 関数がアカウント間でサービスを呼び出す必要がある場合は、異なる資格情報が使用される可能性があります。そのため、AWS の Security Token Service の Assume Role API (https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html を参照) を使用して、さまざまな一時的な認証情報を取得する必要があります。
• 関数で長期的な認証情報 (DB 認証情報、アクセスキーなど) を保存する必要がある場合は、暗号化ヘルパーまたは AWS System Manager で環境変数を使用します。

テスト可能性

AWS Lambda を使用すると、ユーザーはクラウドでコードを実行できますが、ローカルでテストするにはどうすればよいでしょうか?

Lambda は直接的なテスト URL を提供しませんが、起動するイベント ソース システムに基づいてテストを実行できます。

• Lambda 関数のローカルテストには、AWS SAM (https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/what-is-sam.html を参照) を使用できます。 CLI 用のローカル Lambda のような実行環境を提供します。 API Gateway の localhost URL を取得して、Lambda 関数をローカルで呼び出すことができます。
• localstack (https://github.com/localstack/localstack を参照) オープンソース プロジェクトを使用して、多数の AWS リソース/サービスを含むローカル環境を作成できます。 Lambda を他の AWS サービスと一緒に実行できます。また、すべてのサービスを API として提供し、バックエンドで Docker コンテナとして実行できるため、AWS SAM を localstack と統合することもできます。
• ビジネス ロジックを Lambda ハンドラーの外部に配置します。ハンドラー関数は、入力を取得して他の関数/メソッドに渡すためにのみ使用する必要があります。これらの関数/メソッドは、それらをアプリケーションに関連する変数に解決し、さらに使用します。このプロセスでは、ビジネス ロジックをハンドラーから分離するだけでなく、作成したオブジェクトや関数のコンテキストでビジネス ロジックをテストすることも可能になります。

ブルー/グリーンデプロイメント

Lambda に含まれるバージョニング機能とエイリアス機能を使用すると、関数の複数のバージョンを公開できます。同時に、各バージョンを別のコンテナで並行して呼び出すことができます。デフォルトでは、バージョン機能は $LATEST で表されます。開発プロセスでは、これらのバージョンを使用して、dev/UAT などの複数の環境を作成できます。ただし、新しいコードをアップロードするたびにバージョンが増加するため、お客様には最新バージョンが提示されます。したがって、本番環境ではバージョン管理を直接使用するのではなく、エイリアスを使用する必要があります。

エイリアスは関数の特定のバージョンを指すことができます。したがって、コードが変更され、更新されたバージョンがリリースされた場合でも、イベント ソースは引き続き同じエイリアスを指します。エイリアスを新しいバージョンにポイントする必要があるタイミングを管理するだけです。これにより、ブルー/グリーン展開が可能になります。いくつかのサンプル イベントを使用して、新しいバージョンをテストできます。正常に動作することを確認した後、Alias の方向を変更することでアクセストラフィックを切り替えることができます。同時に、問題が見つかった場合は、すぐに元のバージョンにロールバックできます。

モニター

個人的には、CloudWatch は Lambda とうまく連携し、Lambda 実行のさまざまな詳細をユーザーに提供すると思います。 Lambda は、リクエストの数、各リクエストの実行時間、エラーになったリクエストの数を自動的に追跡し、関連する CloudWatch メトリクスを公開できます。同時に、これらのインジケーターを使用して、さまざまな CloudWatch アラーム機能をカスタマイズすることもできます。

さらに、X-Ray を使用して、Lambda 実行におけるさまざまな潜在的なボトルネックを特定できます。関数の実行で時間が費やされている場所を視覚化しようとするときに非常に便利です。さらに、X-Ray は、プロセス全体に接続されているすべての下流システムを追跡するのに役立ちます。

その他の提案

• 実稼働環境で直接使用されるコードを開発するために AWS Lambda コンソールを使用しないでください。

1. コードのバージョン管理は自動ではないため、誤って「保存」ボタンをクリックすると、本番環境で動作しているコードが上書きされます。
2. GitHub やその他のコード リポジトリとは統合されません。
3. AWS SDK 外部のモジュールにインポートすることはできません。そのため、特定のライブラリが必要な場合は、最初からローカルで独自の関数を開発し、.zip ファイルを作成して、AWS Lambda にアップロードする必要がありました。

• 開発には AWS SAM または Serverless Framework を使用してください。
• Lambda デプロイメントの CI/CD 計画に関しては、実際には他の成果物計画と変わりません。
• さまざまな環境変数とパラメータ ストアを使用して、コードと構成を分離できます。

要約する

この記事では、Lambda を設計およびデプロイする際に参照して使用する価値のあるさまざまなベスト プラクティスについて説明しました。実際のアプリケーションのコーディング言語やユースケースに基づいて、業務システムのパフォーマンスを継続的に向上させることができます。もちろん、他のクラウド プラットフォームや Kubernetes のサーバーレス プラットフォームでも、これらのベスト プラクティスから学ぶことができます。これらの実践概要を、皆さん自身の成熟した本番環境とアプリケーションに適用していただければ幸いです。

原題: AWS Lambda ベストプラクティス、著者: Rajesh Bhojwani

[51CTOによる翻訳。パートナーサイトに転載する場合は、元の翻訳者と出典を51CTO.comとして明記してください。