サーバーレスとMongoDBのスケーリングの問題をどのように克服できますか？
私はサーバーレスとMongoDBに精通しており、2つの世界を接続するスケーラブルな方法があるかどうかを知りたいと思います。私の知る限り、RESTfulな方法でMongoDBと対話することはできません。代わりに、再利用されることになっている接続を開きます。
サーバーレスAPIの一部としてAWSLambdaを使用しているとしましょう。ラムダがコールドの場合、MongoDBへの新しい接続を開く必要があり、ラムダがまだホットの間、接続は開いたままになります。このソリューションは問題ありませんが、APIでトラフィックが急増すると、MongoDBによって課せられる接続制限に達します。
ラムダのようなステートレスな世界でこの接続制限を克服する方法はありますか？
回答
Lambda関数はステートレスで非同期であり、データベース接続プールを使用することで、状態を追加し、目的を達成できなくなります。
接続プーリングが必要な場合は、EC2を介してサーバーを実行することがAWSでの最適なオプションです。
ただし、ラムダを使用した接続プーリングが必要な場合は、通常はを使用してプールMongoClient.connect(uri, { poolSize: 10 })を作成し、ダミートリガーを作成することでクラウドウォッチイベントを使用してラムダをウォームに保つことができます。
確かにパフォーマンスが向上します。
考えられるアイデア：Kinesisを使用してLambdaをトリガーできます。これにより、同時実行の数がシャード数に制限されます。たとえば、8つのシャードが同時に8つになります。
このようにして、接続を開いたままにし、開いている接続の制限を獲得して、スケーリングの問題を回避できます。
このタイプのもの（接続が新規か再利用かを問わず、1回の呼び出しで）は、時間の経過とともにスケーリングステータスを維持するのに役立ついくつかの監視ツールで監視でき、MongoDBとKinesisイテレーターの経過時間を管理するのに役立ちます。といった：
- AWS X-Ray
- AWSCloudwatchメトリクス
- Datadog
- ルミゴ
私はLumigoという会社で働いている開示として、生産スケーリングの問題を追跡するのに役立つ分散監視ツールを用意しています。