AWS Lambdaのプログラミング

第9章. 高度なサーバーレスアーキテクチャ

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

第8章では、アプリケーションのプロダクション化を考え始めたときに重要な、Lambdaのより高度な側面について見てきた。 この章では、そのテーマを継続し、Lambdaがアーキテクチャに与える影響についてより幅広く見ていく。

サーバーレスアーキテクチャの "ゴッチャ"

まず、サーバーレス・アーキテクチャの中で、考慮しなければ問題を引き起こす可能性のある領域を取り上げ、状況に応じてこれらの問題に対処するためのさまざまな解決策を提示する。

アット・リースト・ワンス・デリバリー

Lambdaプラットフォームは、上流のイベントソースがLambda関数をトリガーした場合、または他のアプリケーションが明示的にLambdainvokeAPI呼び出しを行った場合、対応するLambda関数が呼び出されることを保証している。 しかし、プラットフォームが保証していないことの1つは、関数が呼び出される回数だ：「これは "at-least-once delivery "と呼ばれ、Lambdaプラットフォームが分散システムであるために存在する。

大半の場合、Lambda関数はイベントごとに1回だけ呼び出される。 しかし、ごくたまに（1％にもはるかに満たない）、Lambda関数が複数回呼び出されることがある。 なぜこれが問題になるのか？そして、この振る舞いにどう対処するのか？見てみよう。

例Lambdaの "cron jobs"

あなたが業界で長くソフトウェアを開発しているなら、おそらく複数の「cronジョブ」（おそらく1時間ごとか毎日実行されるスケジュールされたタスク）を実行するサーバーホストに出くわしたことがあるだろう。 通常、これらのタスクは常に実行されるわけではないので、各ホストで1つだけ実行するのは非効率的である。そのため、1つのホストで複数の種類のジョブを実行するのが一般的だ。これはより効率的だが、依存性の衝突、所有権の不確実性、セキュリティの懸念など、運用上の頭痛の種を引き起こす可能性がある。

、cronジョブで実行される多くの種類のアクティビティをLambda関数として実装することができる。cronのスケジュール振る舞いを得るために、CloudWatch Scheduled Eventをトリガーとして使うことができる。SAMはこれを関数のトリガーとして指定するための簡潔な構文を提供しており、cron構文を使用してスケジュール式を指定することもできる。 Lambdaをcronプラットフォームとして使用することには様々な利点があり、前の段落で説明した演算子の頭痛の種を改善することも含まれる。

Cronタスクの実装にLambdaを使うことの主な欠点は、関数の実行に15分以上かかる場合（Lambdaの最大タイムアウト）、または3GB以上のメモリを必要とする場合だ。 これらの状況のいずれにせよ、タスクを小さなチャンクに分割できない場合は、代わりにStep Functionsや Fargateに目を向けるといいだろう。

しかし、Lambdaを使うことにはもう一つ欠点がある。ごくたまにだが、cronジョブがスケジュールされた時間やその近くに複数回実行されることがあるのだ。 多くの場合、これは考慮するに値しない問題だろう。あなたのタスクがクリーンアップジョブで、同じクリーンアップを2回実行するのは若干効率が悪いが、機能的には正しいかもしれない。 ...