%20%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%99%E3%82%8B.png)
私は、固定サイズのレコードとシーケンス番号 0、1、... を含むファイルの大きなコレクションとして簡単に表現できるデータベースを設計しています。これは、ファイル名を主キー、レコード シーケンス番号をソート キーとして使用して DynamoDB にうまく適合する可能性がありますが、EFS ではルーズ ファイルを使用することを考えています。これはフォールト トレラント システムで既に複製されているため、レプリケーションは必要ありません。Lambda 関数では、既知のファイル内の既知のオフセットに常に存在する個々のレコードの読み取り、書き込み、または更新以外の複雑な操作は必要ありません。同時にアクティブなラムダが 100 個ある可能性がありますが、通常は異なるファイルにアクセスします。競合を同期するには、fcntl/lockf を使用できそうです。
ざっと説明すると、RAW ファイルを使用すると、少なくともコストが半分に削減され、パフォーマンスも向上すると思われます。これを実行したことを後悔する理由は何でしょうか?
答え1
いくつかの簡単な実験に基づくと、このアプローチは実現可能です。Rust を使用すると、約 20 ミリ秒の Lambda 実行時間 (繰り返し呼び出し時) でファイルを更新できました。fcntl アドバイザリ ロック (F_SETLKW) を使用すると、同じファイルに対して競合するいくつかの同時 Lambda で問題が発生することはありませんでした。競合がない場合のレイテンシは約 30 ミリ秒まで上がり、競合中は予想される待機時間でした。
これらは DynamoDB とほぼ同じ範囲のようです。ただし、多くの小さなファイルを含むワークロードでは EFS を避けるようにという推奨事項を多くの場所で見てきました。ただし、これは多くの場合 EBS に関連しており、リクエストごとに 1 つの Lambda で達成できる単純な同時実行性を無視していると思います。
DynamoDB でこのパフォーマンスを上回るには、同時実行 Lambda の数を制限するために Simple Queue Service を使用する必要があると思います。
私が予測する最大の欠点の 1 つは、アップグレード性です。ファイル形式に変更が必要になった場合、すぐに面倒なことになります。コア ワークフローを超えるあらゆる種類のクエリには、カスタム実装が必要になります。
答え2
おそらく可能だと思います。このブログ投稿には役立つ情報がいくつかあります…