AWS Lambda (node.js を使用) 上で実行されている「マイクロサービス」と呼ばれるものがあります。
基本的に、数百メガバイトのバイナリ BLOB から抽出された要約を提供します。出力の可能な範囲は多く、すべての可能性を事前に生成することは不可能であり、パラメータを迅速に変更できるインタラクティブな Web ページから (API Gateway 経由で) アクセスされるため、適度に応答性 (最悪でも 1 秒未満など) が必要です。BLOB 内のアクセス パターンは基本的にランダムですが、生成される要約は通常、データ全体の約 0.1 ～ 1% にしかアクセスしません。データとアクセス パターンは、データベースにデータを保存することとはあまり互換性がありません (ただし、以下の DynamoDB に関する説明を参照してください)。
私の現在のアプローチは、大きなバイナリ BLOB を S3 でホストし、Lambda ハンドラーが Lambda 呼び出し間で BLOB をローカルにキャッシュするようにすることです (ハンドラー関数の外側のスコープを持つ JavaScript コード内のバッファーとして、明らかに Lambda のメモリは十分に大きく構成されています)。ハンドラー インスタンスは十分に永続的であるため、サーバーが起動して実行されると、正常に動作し、応答性が非常に高くなります。ただし、少なくとも 2 つの欠点があります。
S3 からのデータの最初のフェッチは約 50 ～ 60 MByte/s のようです (私が見た S3 帯域幅に関する他のレポートと一致しているようです)。そのため、最初のアクセス時に数秒の遅延が発生する可能性があります。
前の点に関連して、クライアントが非常にアクティブであったり、ユーザー負荷が増加したりすると、より多くのサーバー インスタンスが起動され、ユーザーの要求がデータ BLOB の取得で停止しているインスタンスにルーティングされることがあり、これにより、スムーズに機能しているクライアントで厄介な不具合が発生します。
実際に大きな状態チャンク (バイナリ ブロブ) を持つ「ステートレス」サービスとして意図されているものに対して、おそらく期待しすぎているだろうと率直に認めますが、状況を改善するために何かできることはないかと考えています。データは特に圧縮可能ではないことに注意してください (1/3 を削減することは可能かもしれませんが、それは私が求めているような規模ではありません。少なくとも、せいぜいソリューションの一部にすぎません)。
Lambda にデータをより速く取り込む方法について何か提案はありますか? 私が想像しているのは次のようなことです:
Lambda の帯域幅がはるかに高い別の場所からデータを取得します... しかし、何ですか? DynamoDB (必要に応じて 400k バイナリ レコードに分割)? ElastiCache? AWS の「メニュー」で私が気付いていない他の何か。
何らかの巧妙なトリック（何？）を使用して、ラムダインスタンスを「事前ウォームアップ」します。
仕事にまったく適さないツールを使用しています。代わりに... を使用しますか? (ただし、私は Lambda モデルが本当に気に入っています。インスタンスのプロビジョニングや自動スケーリングについて心配する必要はなく、機能だけに集中できます)。
Google または Microsoft が最近発表した Lambda に似たサービス (これについてはほとんど知りません) に、このユースケースをより適切に支援する属性があれば、それも非常に興味深い情報になります。
私が検討したオプションの 1 つは、バイナリ データを「デプロイメント パッケージ」に焼き込むことですが、その 250 MByte の制限は、一部の予想されるユース ケースには低すぎます (BLOB が圧縮されている場合でも)。
答え1
バイナリ BLOB が数百メガバイトしかない場合は、それを「依存関係」として関数に含めることができます。コードと一緒にファイルとして追加し、それに応じて参照することができます。
もう 1 つのオプションは、2 つの Lambda 関数を使用することです。1 つの関数は、BLOB (上記のように関数を使用して BLOB を送信することで作成) を提供するだけで、タイマー (基本的には cron) を使用して、その関数を 1 分ごとに「くすぐり」、アクティブにすることができます。次に、2 番目の Lambda が作業を実行し、起動時に最初に行うことは、最初の Lambda を呼び出して BLOB を取得することです。Lambda から Lambda への呼び出しは帯域幅が大きいため、起動時間は問題にならないはずです。
理想的な解決策は、データを要約して DynamoDB に保存する方法を見つけることですが、その方法を試してみて、意味がなかったようです。