サーバーレス・エッジ時代のグローバルデータベース──Upstash Global Database徹底解説

近年、アプリケーションのデプロイにおいて、サーバーレスアーキテクチャとエッジコンピューティングが急速に普及しています。しかし、サーバーレス関数やエッジ関数の中でアプリケーションの状態やデータを保存するのは、まったく別の話です。データベースへの接続管理、複数拠点からの高速なデータアクセスの実現など、乗り越えるべき課題が数多くあります。

サーバーレスアクセスに対応したデータベースサービスは限られており、さらにエッジ関数にも適したものとなると、ごくわずかしか存在しません(詳細な分析はこちらの記事をご覧ください)。

Upstashでは、創業当初から低レイテンシかつリクエスト単位の従量課金モデルを採用したサーバーレスRedis互換データベースを提供してきました。さらに、データベース上に直接構築されたファーストクラスのREST APIも公開しています。REST APIによって接続管理の手間が解消されるため、サーバーレス関数での利用に便利なだけでなく、エッジロケーションやWebブラウザといった制約のある環境からでもアクセス可能になります。

そして今回、Global Databaseの提供開始をお知らせします。データベースをグローバルに展開し、クライアントやエッジロケーションの近くへ配置することで、低レイテンシの読み取りを実現する大きな一歩です。Global Databaseは無料枠でも利用できるため、コストをかけずにお試しいただけます。

どんな場面で使うべきか?

Global Databaseは、異なる大陸の複数リージョンにデプロイされ、ユーザーが世界中に分散しているケースで、クライアントのリクエストを最寄りのリージョンへルーティングすることでレイテンシを最小化します。具体的には、以下のような用途に適しています。

• エッジ関数(Cloudflare Workers、Fastly Compute):組み込みのREST APIと、全エッジロケーションからの低レイテンシアクセスにより、理想的なソリューションになります。

• マルチリージョンサーバーレスデプロイ:AWS Lambda、Vercel、Netlify Functionsは複数リージョンへデプロイ可能です。Global Databaseがあれば、サーバーレス関数がどこにあっても低レイテンシのデータアクセスが得られます。

• Web/モバイルプラットフォーム:読み取り専用REST APIを利用すれば、Web/モバイルアプリケーションからRedisデータベースへ直接アクセスできます。ユーザーはあらゆる場所からアクセスすると想定されるため、Global Databaseはより優れたレイテンシをもたらします。

もう一つの狙いは、リージョン全体障害への耐性です。あるリージョンが利用できなくなった場合でも、リクエストは最寄りの利用可能なリージョンへ自動的にルーティングされるため、データベースの可用性は維持されます。

仕組み

Global Databaseモデルでは、同一データベースの複数のレプリカがクラスタを形成します。各レプリカは他のクラスタメンバーと接続し、障害検出器(failure detector)によって相互の稼働状態を監視します。クラスタメンバーシップと障害検出は、どちらもゴシップベースの通信プロトコルで管理されています(SWIM: Scalable Weakly-consistent Infection-style Process Group Membership Protocolを参照)。

データのレプリケーション(個々の書き込み・更新・削除)には、シングルリーダーレプリケーションモデルが採用されています。キーのグループごとにリーダーレプリカが割り当てられ、メンバーシップ変更後にリーダー選出メカニズムによって選ばれます。残りのレプリカは、そのキーグループにおけるリーダーのバックアップとして動作します。障害検出器によってリーダーの故障が検知されると、残りのレプリカが新しいリーダー選出ラウンドを開始します。この選出プロセス中、データベースは短時間利用できなくなり、選出が完了するまですべてのリクエストがブロックされます。

書き込みリクエストを受け付けて処理するのはリーダーレプリカのみですが、バックアップレプリカは内部で書き込みをリーダーへ転送するため、クライアント側には通知されません。つまり、レプリカの種類(リーダーかバックアップか)に関わらず、クライアントはどのレプリカに対しても書き込みリクエストを送信できます。書き込み処理の後、リーダーレプリカはその結果をバックアップレプリカへ伝播させます。

整合性について

現時点で、Global Databaseは弱い整合性(weakly consistent)であり、強い整合性はまだサポートしていません。書き込みリクエストのレスポンスは、バックアップの過半数からのACKを待たずに、リーダーレプリカが操作を処理した時点でクライアントへ返されます。書き込み結果は非同期かつ並列に、バックアップレプリカへ複製されます。

読み取りリクエストは任意のレプリカで処理されるため、読み取りのスケーラビリティは向上します。その一方で、同じキーへの書き込み結果がバックアップレプリカに到達するまで、読み取りリクエストが古い値を返す可能性がある点には注意が必要です。

コンフリクトがなければ楽なのに!

ネットワーク分断のようなクラスタ全体に及ぶ障害が発生すると、同じキーに対して複数のリーダーが選出される可能性があります。これは、複数のレプリカが書き込みを受け付け、レプリカ間でデータが分岐(diverge)することを意味します。CalvinやSpanner(あるいはPaxos、Raft)のようなプロトコルを用いた強力なモデルなら、最初からコンフリクトを防ぐことも可能ですが、それは現時点で私たちが進みたい道ではありません。

代わりに、Global Databaseはコンフリクトの発生を許容し、LWW(Last-Write-Wins:最終書き込み優先)アルゴリズムで解決することで、最終的にすべてのレプリカを同じ状態へ収束させます。Upstashデータベースの各書き込みには、一意で単調増加するシーケンス番号が付与されています。レプリカがリーダーになるたびに、処理する最初の書き込みのシーケンスを記録します。そして、2つのリーダーレプリカが互いを再発見した際には、それぞれがリーダーになって以降の書き込みを共有し、コンフリクトを解決します。

すべてのレプリカが対等というわけではない

「一部のレプリカは、他のレプリカよりも平等である」――リーダーに選出できるのは一部のレプリカだけだからです。Global Databaseクラスタでは、レプリカをlearner(ラーナー)としてマークできます。learnerに指定されたレプリカはリーダー選出の対象外となり、常に読み取り専用として動作します。

learnerレプリカの追加はクラスタの安定性に影響せず、たとえ分断されても書き込みコンフリクトを引き起こしません。リーダーから分離された状態でも読み取りリクエストは引き続き受け付け、分断が回復すれば残りの書き込みを同期します。そのため、learnerレプリカは、さらなるエッジロケーションを拡張していくうえで非常に有用な仕組みとなっています。

より多くのリージョン、より多くのレプリカ?

初期リリースでは、5つのレプリカ・5つのリージョン構成でGlobal Databaseを提供しています。米国およびEU以外のレプリカはlearnerとしてマークされているため、リーダーに選出できるのは米国・EUリージョンのレプリカのみです。これにより、ネットワーク分断時に書き込みコンフリクトが発生する可能性を最小限に抑えています。同時に、ネットワーク分断を気にすることなく、learnerレプリカとして新たなリージョンを追加できる体制にもなっています。

まだ道のりは長い

現在のGlobal Databaseは、読み取り操作のレイテンシを最適化・最小化するために設計されています。書き込みが多いワークロードには向いていません。私たちは、より優れた設計によって書き込み操作のレイテンシも改善すべく、開発を進めています。

また、初期の5リージョン構成に加えて、ユーザーからの需要やフィードバックを受けて、今後さらに多くのリージョンや異なるリージョングループの開放も検討しています。

ご意見・アイデア・質問があれば、TwitterやDiscordコミュニティまでお気軽にお寄せください。