サーバーレスに最適なデータベースとは?選定基準とおすすめサービス徹底解説

サーバーレスは、アプリケーションを最小限の運用コストと費用でエンドツーエンドに構築したい開発者にとって理想的なアーキテクチャです。サーバーレス関数を使えば、バックエンドインフラを管理することなく自分のコードを実行できます。しかし、サーバーレス関数は設計上ステートレス(状態を持たない)であるため、外部のデータストアが必須となります。そこで次の疑問が生まれます。「どのデータベースがサーバーレスに最適なのか?」

幸いなことに、各データベースベンダーもサーバーレストレンドを認識しており、サーバーレス向けサービスの提供を開始したり、既存製品の対応を進めたりしています。本記事では、まず「サーバーレスに優れたデータベース」を左右する条件を整理し、その後、筆者が有力候補と考える具体的なデータベースを紹介します。

サーバーレスに優れたデータベースの条件とは?

• 使いやすさ: 次世代の開発者は、何日もかけて技術を習得することを望みません。長大なドキュメントを読むよりも、YouTube動画を見ながら学びたいと考えています。そのため、サーバーレス向けデータベースはシンプルで直感的であるべきです。
• サーバーレス対応の料金体系: 料金は「ゼロまでスケール」(未使用時は課金なし)すべきです。使っていないものにお金を払う必要はありません。帯域幅単位やリクエスト単位の料金モデルは実際の使用量と連動しているため、サーバーレス向きと言えます。個人的には、帯域幅よりもリクエスト単位の方が見積もりやすく好みです。
• 開発者に優しい料金設計: 料金はシンプルで、落とし穴がないことが重要です。料金ページが複雑すぎて、詳細を説明する追加記事やブログ投稿が必要になるケースもあります。複雑な料金計算ツールを用意しているベンダーさえあります。残念ながら、多くのベンダーはリスクを最小化するために複雑な料金設定を好む傾向があり、請求書を見る前に支払額を予測するのが困難になっています。
• サーバーレス接続: サーバーレス関数は数秒で数百、数千規模にスケールすることがあります。データベースが永続的な接続を要求する場合、接続上限に容易に達してしまいます。一方、HTTPベースの接続は軽量で、一般的にこうした制限がないため問題になりません。
• 低レイテンシ: 余分なレイテンシはサーバーレス関数にとってコストです。しかし本当のコストは、サイト上で待たされ続ける不満なユーザーです。
• ポータビリティ: 別のクラウドベンダーへ移行する際、データ層を書き直す必要があるでしょうか。また、リモートデータベースに接続せずにローカル環境でアプリケーションをテストできるでしょうか。
• 整合性(一貫性): 一般的に、整合性とパフォーマンスにはトレードオフの関係があります。データベースごとに、このスペクトラム上の位置は異なります。優れたデータベースは整合性の保証を明確に定義し、ユーザーが潜在的な問題やリスクを把握できるようにすべきです。
• スケーラビリティ: アプリケーションへのアクセスが急増しても、データベースがそれに追従できるべきです。理想的には、スケーリングは自動化されるかクラウドプロバイダーが管理し、開発者は意識する必要がない状態が望ましいでしょう。
• エッジフレンドリー: Cloudflare WorkersやFastly Compute@Edgeは、ユーザーに最も近いエッジでサーバーレス関数を実行できる注目の技術です。これらにはRESTベースの接続に加えて、レイテンシを最小化するためのグローバルレプリケーション対応データベースが求められます。
• グローバル性: アプリケーションが世界的に普及すると、世界中で高いパフォーマンスを発揮できるデータベースが必要になります。マルチリージョンレプリケーションがその鍵となる機能ですが、注意が必要です。この機能は高価になる場合があるため、必ず料金を確認しましょう。

サーバーレスに最適なデータベース候補

このセクションでは、筆者が実際に以下のデータベースを試した際の感想やメモを共有します。厳密な科学的分析に基づくものではありませんが、本格的な比較検討を行う前の参考情報として役立てていただければ幸いです。

MongoDB(Atlas)

• 使いやすさ: MongoDBは最も人気のあるNoSQLデータベース兼ドキュメントストアです。JSONベースのデータモデルのおかげで、APIは非常にシンプルで直感的です。
• ポータビリティ: ほぼすべてのクラウドプロバイダーがMongoDB API互換のデータベース製品を提供しており、オンプレミスで自前実行することも可能です。ポータビリティの懸念はありません。
• サーバーレス対応: MongoDB Atlasは近年、Serverlessデータベースタイプを発表しました。筆者の印象としては、サーバーレス価格モデルを適用したホスト型MongoDBインスタンスという色合いが強いものでした。公式ドキュメントによると、Node.js SDKを含む多くの機能がServerlessデータベースではサポートされていない点に注意が必要です。
• サーバーレス接続: MongoDB AtlasはHTTPベース(RESTなど)のAPIを標準では提供していません。そのため接続上限に達しやすく、AWS Lambdaからの接続に関するベストプラクティス記事を公開するほどです。
  (更新)MongoDB Atlasはその後、HTTPベースのData APIを発表しました。

Cassandra(DataStax Astra)

• DataStax Astraは、ネイティブのCassandraドライバーに加えて、RESTおよびGraphQL APIを提供しています。
• 使いやすさ: 個人的には、CassandraはMongoDBやRedisに比べて学習難易度が高いと感じました。ただし、DataStaxチームによる管理コンソールはよく作り込まれており、非常に直感的でした。それでも、REST APIのバージョン違いのドキュメント間で迷子になった記憶があります。
• 開発者に優しい料金設計: DataStax Astraの料金は決してシンプルではありません。読み取り・書き込み・帯域幅のすべてのユニットが個別に計算され、クラウドプロバイダーやリージョンによって価格が異なります。さらにDataStax独自の読み取り/書き込みユニット(RRU・WRU)の概念を理解する必要があります。

DynamoDB(AWS)

• 使いやすさ: AWSユーザーであれば、DynamoDBの導入と運用は容易です。ただし、クエリAPIの直感性についてはMongoDBの方が優れていると筆者は感じています。
• サーバーレス接続: DynamoDBの接続はHTTPベースのため、接続上限の問題は発生しません。
• ポータビリティ: 最大の弱点はここです。DynamoDBはAWS以外の環境では利用できません。

FaunaDB

• 整合性: おそらくFaunaDBはこのリストの中で整合性の面で最も優れています。グローバルレプリケーションとともに強い整合性を保証します。ただし、それには追加のパフォーマンスコストが伴う点に注意してください。本当にそこまで強い整合性が必要かどうかを検討しましょう。
• パフォーマンス: 強い整合性を実現しているため、他のサービスと比べてレイテンシは高めです。
• 使いやすさ: 正直なところ、独自クエリ言語のFQLは筆者にとって最も学習と使用が難しいものでした。ただしFaunaDBはGraphQL APIもサポートしているため、こちらを利用すればハードルは下がるかもしれません。
• サーバーレス接続: HTTPベースの接続を採用しているため、FaunaDBに接続上限の問題はありません。

Upstash

• 使いやすさ: Redisはおそらくこのリストの中で最も学習しやすいAPIです。Upstashは直感的でシンプルなインターフェースにより、クラウドでのRedis利用を容易にします。
• 開発者に優しい料金設計: Upstashの料金はリクエスト単位制です。さらに価格上限(cap)も設定されており、事前に決めた金額以上を請求されないことが保証されます。
• パフォーマンス: インメモリストレージの恩恵により、Upstashはこの中で最も優れたレイテンシ数値を誇ります。
• 一方で、結合(JOIN)などの複雑なクエリが必要な場合、Redisのデータ構造は実用的ではないかもしれません。そのようなケースでは、SQLサポートが充実したデータベースを検討する必要があるでしょう。

Firestore

• 使いやすさ: この観点では、Firestoreはこのリストの中でもトップクラスです。UIとAPIはかなり直感的に設計されています。
• ポータビリティ: DynamoDBと同様に、Firestoreにもベンダーロックインの問題があります。Google Cloud上で完結する限りは問題ありません。
• パフォーマンス: パフォーマンスについては以前から不満の声を耳にします。筆者自身の経験でも、FaunaDBと並んでレイテンシが他より劣ると感じました。この点には疑問符が付きます。

まとめ

サーバーレスは開発の未来であり、現在もその移行は着実に進んでいると筆者は信じています。サーバーレスは、開発者や小規模な企業が限られた予算でスケーラブルな製品を作り上げることを可能にします。データベースもまた、サーバーレスの原則に沿ったサービスを提供することで、この大きな移行の一翼を担っていくべきです。