AWS Lambda（Elastic Beanstalkなど）で完全なバックエンドを実行することは可能ですか（または効率的ですか）
私はサーバーの世界には比較的慣れていないので、これが基本的なものである場合は許してください（そして、最初のテキストは、欠陥がないことを確認するためのロジックを説明することになります）。あなたの助けを簡単にするために、すべての私の質問は太字になります:)。
私はいくつかのAWSテクノロジーを調査して教えていましたが、モバイルハブで、クラウドロジックが必要な場合はLambda関数の「自動」セットアップしか許可しないことに気付きました。読んで調査した結果、「サーバーレス」アーキテクチャ（Lambdaの導入でサポートされている）を指すリソースがいくつか見つかりました。以前は、Elastic Beanstalkがサーバー管理（特にモバイル）を大幅に簡素化するために導入されたと私は理解しています。
モバイル開発の場合、2つのオプションがあります（明らかにもっと多くですが、簡単にするために同意します）。
- 24時間年中無休で実行される少なくとも1つのインスタンスを持ち、URLごとに複数のエンドポイントを持つElastic Beanstalkを設定します
- API Gatewayを使用すると、URLを特定のLambda関数に簡単にルーティングできます。これにより、すべてのリクエストを処理できます（Elastic Beanstalkアプリケーションの設定と同様）。
これにより、完全なLambdaバックエンドは完全に可能であり、サーバーを24時間年中無休で稼働させるコストの何分の1かで簡単に作成できると思います。それは正しいですか？
ここで、上記が正しいと仮定して、Lambdaを使用することがElastic Beanstalkよりも本当に有益かどうかを判断する必要があります。
単純なサーバーの場合、いくつかのLambda関数を設定して1日で呼び出すことができます（おそらく、Elastic Beanstalkを使用するよりも（少なくとも小規模なプロジェクトの場合は）はるかに単純で安価です）。
ただし、より多くのURLとデータベース接続を備えたより複雑なサーバーの場合、状況はさらに面白くなります。
これらは、上記の状況でLambdaを使用するときに見られる問題です
- 各URLには独自のAPI Gatewayと独自のLambda関数があります。コードまたはモジュールが複数の関数で使用されている場合は、それをコピーして各関数に貼り付ける必要があります。
- 複数のLambda関数（およびAPIゲートウェイ）の管理は、単一のプロジェクト/リポジトリ/ whatever-you-wanna-call-your-code-baseを管理するよりも単純です。
- DB接続を必要とする各関数は、関数内で接続する必要があります（たとえば、Node.jsアプリ内で常に接続している）。
最初の2つの問題を回避する唯一の方法（私は考えることができます）は、ディスパッチとして機能する1つの堅牢な関数を作成することです（メイン関数はAPI Gatewayからパラメーターを受け取り、Lambda関数内で実行するファイルを決定します）。
Elastic BeanstalkでLambdaを使用する価値があるかどうかを判断するために欠けている重要な点はありますか？
すでに理解しているようですね。サーバーを24時間年中無休で実行する代わりにLambdaを使用すると、大幅なコスト削減になる可能性があることは間違いありません。 この記事 が主張します：
そしてそれは、Amazonの顧客の大金を節約しており、少なくとも1人の幸せなLambda顧客が彼らのクラウド請求から80％を節約しています。
いくつかの問題点を管理する Serverless Framework を確認することをお勧めします。
AmazonがLambdaにより多くの機能を追加し、サードパーティのツールがそのために構築されているので、やがて多くの問題点はなくなると思います。私は常にLambdaの新しい使用法を発見していますが、最初は適切だと思われる使用法を常に発見していますが、少なくともまだLambdaで動作していません。たとえば、同時に実行できるLambda関数のインスタンスの数を制限して、利用可能なデータベース接続を使い果たしたり、サードパーティのAPIの使用制限に達したりしないようにする方法が本当に必要です。また、VPC内で実行するためにLambda関数も本当に必要ですが、それは間もなく登場する予定です。
他の人がすでに指摘しているように、LambdaとElastic Beanstalkを実行するか、自分で管理するEC2インスタンスを実行すると、いくつかの利点があります。
費用
AWSはElastic BeanstalkとEC2の自動スケーリングをサポートしています。フェイルオーバー動作のためには、おそらく少なくとも2つのインスタンスを実行する必要があります。フェイルオーバーの最小として2つの「ナノ」インスタンスを実行すると、各インスタンスにコストがかかります（予約済みインスタンスの割引なし）：$ = 59 = 24（30.5 = $ 4.31 VMおよび$ 0.05 * 8 GB = $ 0.40）。したがって、 1つのインスタンスは$ 4.81で、2つのインスタンスは$ 9.62です。ただし、AutoScalingが機能するには、ロードバランサーの設定に少なくとも$ 0.0225 * 24 * 30.5 = $ 16.47（LCU料金を無視）を戻す必要があります。ロードバランサーは、この計算では、人為的に10で分割し、Eleastic BeanstalkまたはEC2を使用する1つのマイクロサービスに$ 9.62 + $ 1.65 = $ 11.27がかかるという結論に達しました。
それでは、ラムダと比較してどうですか？ Lambdaを使用すると、通話ごと、ギガバイトあたり1秒あたりの料金が発生します。 100万リクエストあたり$ 0.20なので、通話コストは無視します。 100万件のリクエストは、1か月あたり1秒あたり0.4件のリクエストです。負荷が高い場合は、ロードバランサーのLCUコストも支払う必要があります。 Lambdaの価格は、GB秒あたり0.00001667ドルです。 Elastic BeanstalkとEC2はどちらも、オペレーティングシステムとコンテナのためにnanos 512 MBメモリの一部を消費します。 256 MBが実際に使用できると思います。 2つのインスタンスがある場合、これは2 * 256 MB/1024MB * 60 * 60 * 24 * 30.5 = 1317600 GB秒になります。このGB秒の量は、1317600 * 0.00001667ドル= 21.96ドルになります。これはより高価に聞こえるかもしれませんが、トラフィックはおそらく均等に分散されないので、おそらくより多くのインスタンスが必要になるため、コストが増加します。 Lambdaを使用すると、実際に使用した分だけ支払うことができます。
スケーリング
Lambdaはオンデマンドでスケーリングし、すでに述べたように、十分に活用されていないベースラインではなく、実際に必要なものだけを支払います。
予測できないパフォーマンス
ラムダの落とし穴は予測できないパフォーマンスです。コンテナは再利用されますが、新しいインスタンスごとにウォームアップが必要です。特にJavaを使用している場合、最初のリクエストは通常遅くなります。 Node.jsは、起動時には軽量になるはずですが、実行時には遅くなるはずです。たとえば、新しい128 MBの低メモリJavaインスタンスが作成され、Lambdaにライブラリが含まれている場合、最初の呼び出しには30秒以上かかることがあります。インスタンスは freezed =リクエスト間。インスタンスがしばらく使用されない場合、再度ウェイクアップするのに時間がかかります。メモリを増やすと、ウォームアップとウェイクアップの時間を短縮できます。ただし、主な問題は、外部データソースへのアクセスです。リクエスト間でインスタンスがフリーズします。適切な接続プーリングはサポートされていません。接続プーリングを実行すると、古い接続が取得される可能性があります。データベースとドライバによっては、接続の開閉にかなりのコストがかかる場合があります。
その他の制限
上記のように、接続プーリングは直接サポートされていないため、データベースアクセスや他のシステムへのアクセスで問題になる可能性があります。開発を高速化するためにフレームワークを使用している場合、それらはLambda内での使用には適さない可能性があります。
マークBが言及した制限はなくなりました。現在、LambdaはVPC内で実行できます。同時インスタンスの数を制限する公式の方法は知りませんが、VPCを使用すると、使用可能なIPのサブネットを制限でき、各LambdaにIPが必要になるため、間接的にLambdaインスタンスの数を制限できます。
良いユースケース
一貫したパフォーマンスをあまり気にしない場合、Lambdaは安価でスケーラブルです。非常に適切なのは、小さなバッチの処理です。
問題は、実際にはFAASとPAASです。 Lambda/ServerlessアーキテクチャはService as a serviceと考えることができ、BeanstalkはPlatform as a service 。
FAASとPAASの間には多くの混乱がありました。 FAASはPAASでもあると多くの人が言っています。 FAASとPAASの際立った特徴を指摘したいと思います。
たとえば、Create、Read、Update、およびDelete操作を持つCRUDアプリケーションがあるとします。通常、WebアプリはRead操作でより多くのトラフィックを受信します。
+---------------------------------------------+--------------------------------------------------------+
| FAAS | PAAS |
+---------------------------------------------+--------------------------------------------------------+
| In case of traffic, it scales that specific | But it scales the whole application, |
| function handling the read operation. | a separate auto-scaled instance in case of bean stalk. |
+---------------------------------------------+--------------------------------------------------------+
| Pay one and only when your function | Have to pay for atleast a single instance, |
| is invoked. | even though there is no traffic. |
+---------------------------------------------+--------------------------------------------------------+
私の観点からは、これらの2つの点が、いわゆる「サーバーレス」アーキテクチャであるFAASをPAASと区別しています。
ラムダ関数については、DynamoDB DAXクライアントをご覧ください。データベースへの接続速度が問題になる場合は、レイテンシがミリ秒からマイクロ秒に短縮されます。