Api Gateway を使用し、ラムダを使用して Java でコードを実装することにより、API スイートをデプロイしようとしています。1 つの jar に多くの (もちろん関連する) ラムダを入れても問題ありませんか (私が想定していること)、デプロイするラムダごとに 1 つの jar を作成する方がよいでしょうか? (これは非常に簡単に混乱します)
2 に答える
これは本当に好みの問題ですが、考慮しなければならないことがいくつかあります。
まず、1 つの Lambda アップロードのサイズには制限があります (執筆時点では 50MB)。
次に、アップロードするすべてのコードの合計サイズにも制限があります (現在は 1.5GB)。これらの制限は、ユース ケースでは問題にならないかもしれませんが、知っておくとよいでしょう。
次に考慮しなければならないことは、どこにオーバーヘッドが必要かということです。CRUD インターフェイスを単一の Lambda にデプロイし、API Gateway から「アクション」パラメーターを渡して、Lambda 関数を実行するときに実行する操作を認識しているとします。これにより、アクションを適切な操作にルーティングする必要があるため、実行にわずかなオーバーヘッドが追加されます。これはおそらく非常に高速なルーティングですが、関数の実行に CPU サイクルが追加されます。
一方、複数の Lambda 関数に同じ jar をデプロイすると、前述の制限にすぐに近づき、数が増えるにつれて Lambda 関数を管理するための管理オーバーヘッドも追加されます。もちろん、それらは CloudFormation または cli スクリプトを介して管理できますが、それでも管理オーバーヘッドが追加されます。
これを行うのに正しい方法と間違った方法があるとは言いません。何をしようとしているのかを見て、展開を管理するために何が必要かを考え、そこから展開してください。間違えた場合は、いつでも別のアプローチからやり直すことができます。
個人的には、内部ルーティングを行い、複数の操作を処理する非常に小さなサービス Lambda が好きですが、それでも非常に小さく、データベース テーブルの CRUD や、選択された非常に密接に関連する少数の管理など、特定のタイプのタスクに焦点を当てています。オペレーション。