サーバーレスの幻想
- サーバーレスはクラウド技術の主要トレンドとして定着した。
- このパラダイムでは、開発者がサーバー管理の負担なく、ビジネスロジックに集中できる。
- 課金方式: 使用した分だけ課金し、運用オーバーヘッドはほぼゼロに近い。
- 複数のサーバーレスデータベースが市場に登場しており、Elastic、Confluent、Pineconeなど既存の主要プレイヤーと、Neon、WarpStream、Upstash、Turbopufferなど新興企業が競争している。
既存のサーバーレスデータベースの問題点
- 多くのサーバーレスデータベースは真のサーバーレスではない。
- 大半のサービスはクラウドネイティブアーキテクチャを基盤としており、これはサーバープール時代のための革新的な設計である。
- サーバークラスタを運用し、複雑なソフトウェアと人的関与により負荷を予測し容量を管理する。
- このような幻想はユーザーに実際の問題を引き起こす。
非効率なアーキテクチャの影響
- アーキテクチャの不整合は単なる技術的な細部ではなく、ユーザーに実際の問題を起こす。
- ユーザーはアイドルサーバーのコストを支払わされ、サーバークラスタは常にさまざまな目的で実行される。
- スケーラビリティの問題: 新しいサーバーをクラスタに追加するのに数分かかり、突発的なトラフィック急増を即座に処理できない。
- 選択肢の制限: 各クラウドリージョンに対するインフラ管理が必要なため、ユーザーが選べるサービスリージョンが限られる。
持続不可能なモデル
- サーバープールアーキテクチャに基づく**「サーバーレス」データベース**は持続可能ではない。
- 提供者はサーバークラスタの運用のために相当額の資本を必要とし、それにより価格が変動しうる。
- 軽量ユーザーはシステムを支えるために過剰な料金を支払い、成功するユーザーは予期せぬ値上げに直面する。
サーバーレスネイティブアーキテクチャの必要性
- クラウドコンピューティングの初期段階では、ほとんどの**「クラウド」データベース**はレガシーなデータベースだった。
- サーバーレスネイティブアーキテクチャは、インフラ管理をすべてクラウドプロバイダに委ね、サーバークラスタの代わりにステートレス関数とサーバーレスサービスを利用する。
- このアプローチはクラウドインフラを単一の巨大なスーパコンピュータとして扱い、即時のスケーラビリティと真の従量課金モデルを実現する。
- リトマステスト: データベースが真にサーバーレスネイティブかを確認するには、Kubernetes クラスタや VM をプロビジョニングせずにクラウドアカウントへデプロイできるかどうかを確認することだ。
LambdaDBの紹介
- LambdaDBはサーバーレスネイティブで構築された新しい検索エンジンである。
- このシステムはサーバーレス機能とリソースの集合体として運用され、データベースロジックとインフラを完全に分離する。
- ユーザーリクエストはリージョングートウェイを通過し、リクエストの種類に応じてコントロール関数（Control Functions）またはデータ関数（Data Functions）へルーティングされる。
- エンタープライズ機能: LambdaDBはポイントインタイムリカバリやゼロコピークローンなどを提供し、インフラ管理は不要だ。
LambdaDBの動作原理
- LambdaDBアーキテクチャ: すべてのコンポーネントはサーバーレスクラウドサービスとして構築される。
- ゲートウェイはユーザーリクエストの API キーを検証し、リクエストをコントロール関数またはデータ関数にルーティングする。
- コントロール関数は CRUD 処理およびデータ管理リクエストを処理し、データ関数は実際のデータの書き込みと読み取りを実行する。
- 書き込みパス: Writer Functionはリクエストを記録し、耐久性のあるサーバーレス書き込みバッファに保存した後、クライアントへ応答する。
コスト効率の逆説
- LambdaDBはサーバープールデータベースと比較してコンピューティングコストを削減する。
- Lambdaのユニット価格はEC2インスタンスより高いが、高可用性と耐障害性を保証するために必要な冗長性によりコスト削減が可能になる。
- 固定容量の浪費: 企業の平均コンピューティング稼働率はわずか10〜20%であるため、サーバーレスコンピューティングは50〜90%のコスト削減が可能である。
パフォーマンスとスケーラビリティ
- 性能とスケーラビリティ: LambdaDBは960次元ベクトルを用い、数百万単位のベクトル追加を行う実験で性能を実証した。
- 書き込みレイテンシ: 1秒あたり10件のアップサートでは中央値レイテンシが43msで、トラフィックが100倍に増加してもレイテンシはほぼ同様に維持される。
- クエリレイテンシ: クエリレイテンシは各種負荷で安定しており、99パーセンタイルは172ms〜210msの範囲内である。
- 最適化努力: クエリ関数のレイテンシを改善するために継続的に最適化を行っており、サーバーレスインフラも改善中である。
顧客に提供されるメリット
- コスト削減: LambdaDBはアイドルサーバーが存在しないため、10倍以上安い。
- 即時かつ無限のスケーラビリティ: LambdaDBはミリ秒以内に数千個の並列関数へスケールできる。
- 簡単な開始と拡張: 強力なAIアプリケーションを構築でき、成長に応じてアーキテクチャは依然としてシンプルでコスト効率的である。
- エンタープライズ機能: ポイントインタイムリカバリやゼロコピークローンなどの機能を、複雑さやコストを追加することなく提供する。
将来計画とビジョン
- LambdaDBはすでに数億件のドキュメントに対して毎日数百万件のリクエストを処理している。
- 長期計画: リレーショナルデータ、ストリーム、キー・バリュー、グラフなど、他のデータモデルのサポートを拡大する予定である。
5件のコメント
発想自体は良いですが、クエリのレイテンシを下げるためには必然的にステートが必要になってきます。MySQL、PostgreSQL などと比べると、クエリレイテンシがほぼ100倍程度高く感じます。ほとんどファイルシステムに対して読み書きしているのと似ているようです。
貴重なご意見ありがとうございます。ご指摘の「レイテンシを下げるためには
stateが必要だ」という点は、私たちのアーキテクチャの重要なトレードオフを正確に捉えています。まず、クエリのレイテンシについて述べると、私たちのベンチマークではp99（99th percentile）は約130〜210ms程度です。おそらく「100倍差がある」とのご指摘は、本文で言及している「コールドスタート時には数秒かかる場合がある」という最悪ケースを見てのことかと思われます。ご指摘の通り、この点は明らかに当社アーキテクチャの欠点であり、記事で述べたように、プロダクション環境では0.01%未満（P99.99）で発生します。そのほか、ほとんどのクエリは各Lambdaのローカルメモリとディスクをキャッシュとして活用するよう設計され、安定したパフォーマンスを実現します。
したがって、すべてのクエリが10ms以下で保証される超低遅延の金融取引システムなどには、このアーキテクチャが適していない場合があります。
ただし、大半のAIベースの検索・レコメンデーションアプリケーションでは、P99基準で100〜200ms程度のレイテンシは十分に優れたパフォーマンスであり、インフラコストと運用負担を90%以上削減できる利点の方がはるかに大きいと考えます。
改めて、深いご意見をいただきありがとうございました。
ご指摘のとおり、汎用的なデータベースというよりは、特定の状況で「本当の」サーバーレスとして使えるソリューションになりそうです。
韓国語でのコメントが来るとは思っていませんでした！ (少し辛辣に書きすぎてしまいました...)
まずは画期的なアイデアだと思いました。実際、サーバーレスDBの一番の問題点は、表面上は見えない場所で実際のサーバーが動いていることでした。だからトラフィックが集中すると、そのサーバーが割り当てられるまでフリーズしてしまう状況が発生します（大体5分程度）。なので、現存するクラウド（AWSなど）のサーバーレスDBは本番レベルで使うのが難しいんですよね。
やってみようかとも思いましたが、心配だったのは、mysqlやpostgresqlなどで作られたインデックス作成、ソートといったバイナリロジックを実装しなければならなくなる場合、信頼できるオープンソースDBプロジェクトをLambda上で再構築するのがどれほど難しいことか、ということです。
直接作っている製品なので、今後の大きな発展を期待しています〜！
はい、良いご指摘をありがとうございます。ご指摘の通り、RDBのユースケースには適しておらず、検索エンジン（Elasticsearch）やベクトルDB（Pinecone）のポジションだとご理解いただければと思います。内部でも、インデックス作成、ソート、集計などの機能をサポートするために、長期間検証されてきたLuceneを活用しています。ありがとうございます :)