ExtendDB: 自分のデータベースで DynamoDB API を動かす

ある病院の記録システムが、建物の外に出せないとしましょう。患者データはオンプレミスのネットワークから決して出せず、監査人がすべての依存関係を承認し、開発用ノート PC にはインターネット接続すらありません。チームはすでにアプリケーションを DynamoDB API に対して書いていて、それを気に入っています。1 桁ミリ秒のキー検索、きれいなアイテムモデル、面倒を見る必要のないスキーママイグレーション。しかしマネージドの DynamoDB はクラウドサービスであり、ここでは「データを AWS に送る」は論外です。

ExtendDBは、まさにそのギャップのために作られています。DynamoDB のワイヤプロトコルを話しながら、データを あなたが 運用するデータベースに格納します。

ExtendDB とは？

ExtendDB は、自分で運用する PostgreSQL などのデータベースの上に DynamoDB JSON ワイヤプロトコルを実装した、AWS のオープンソースアダプター（Rust 製）です。既存の AWS SDK と AWS CLI はそのまま動き続け、変わるのはエンドポイントの URL だけです。つまり、マネージドのクラウドサービスにデータを送らずに DynamoDB API を手に入れられます。

ExtendDB は AWS のオープンソースアダプターです。AWS の DynamoDB エンジニアによって書かれ、AWS Database Blog で発表され、DynamoDB JSON ワイヤプロトコル を Rust で実装しています。マネージドサービスと同じ HTTP API に応答するため、既存の AWS SDK と AWS CLI は そのまま 動きます。動かすのはエンドポイントの URL だけで、コードの書き換えも新しいクライアントライブラリも要りません。

面白いのは、その API の背後に何がいるかです。ExtendDB には プラガブルなストレージバックエンド があります。PostgreSQL がリファレンス実装で、もう 1 つの選択肢として Cassandra が挙げられています。新しいバックエンドは コアを変更せずに実装 されるため、DynamoDB 互換レイヤーとストレージレイヤーは独立して進化します。

リクエストはこう流れます。

何をサポートし、何をサポートしないか

入門ドキュメントと発表記事によれば、ExtendDB（v0.1）は、実際のアプリケーションが呼び出す操作のほとんどをカバーしています。

• テーブル — Create、Delete、Describe、List、Update。
• アイテム — Put、Get、Delete、Update（SET / REMOVE / ADD / DELETE の更新アクションを含む）。
• Query と Scan — キー条件、フィルター式、射影、ページネーション、セカンダリインデックス。
• バッチ — BatchGetItem と BatchWriteItem。
• トランザクション — TransactGetItems と TransactWriteItems。
• ストリーム と TTL、そして インポート/エクスポート と タグ。

意図的に 実装していない のは DynamoDB 固有のマネージド機能 の一群 — とりわけ Global Tables と クロスリージョンレプリケーション です。これらはマネージドサービスのグローバルなインフラの性質であって API 表面の性質ではないため、自分でホストするアダプターには引き継がれません。

DynamoDB Local との違い

オフライン開発のために、すでに DynamoDB Localを使っているかもしれません。あちらは 1 台のマシンでのユニットテストを想定した単一の JAR（または amazon/dynamodb-local の Docker イメージ）です。ExtendDB はその単一プロセスのツールより 広い ところを狙っています。ローカル開発、オンプレミスへのデプロイ、エッジやエアギャップ環境、そして DynamoDB API は欲しいがデータは自分の管理下のインフラに置きたいハイブリッド／マルチクラウド構成です。

マネージドの DynamoDB との違い

これは AWS が明示的に引いている線であり、重要です。

ExtendDB は DynamoDB ではありません。互換実装であって、マネージドサービスの 置き換えではありません。パフォーマンス特性、スケーリングの挙動、運用上の性質は 異なります。

具体的に、ExtendDB を運用するとこうなります。

• データベースの可用性とバックアップはあなたの責任です。マネージドのマルチ AZ 耐久性や、ポイントインタイムリカバリが代わりにやってくれることはありません。あなたと、あなたの PostgreSQL 運用の担当です。
• エンドポイントでは TLS が必須 です。
• 認証情報は IAM 風だが AWS IAM とは別物です。ExtendDB は独自の認証情報モデルを持ち、あなたの AWS アカウントに対して認証するわけではありません。

これは v0.1 で、ライセンスは Apache 2.0 です。初期段階のソフトウェアとして扱ってください。上に挙げた環境には最適ですが、本番規模のマネージド DynamoDB をそのまま置き換えるものではありません。

ExtendDB 自身は RCU も WCU も計測しません — キャパシティはあなたの PostgreSQL の問題です。同じ API 呼び出しが us-east-1 のオンデマンドでマネージドの DynamoDB に当たると、1 KB の PutItem は 1 WCU、4 KB の GetItem は結果整合性で 0.5 RCU が課金されます。ExtendDB はレイテンシでベンチマークし、同じアクセスパターンだとクラウドの請求がどうなるかは料金計算ツールで比べてみてください。

セットアップ

ExtendDB は Linux と macOS で動作し、必要なのは Rust 1.85+ と PostgreSQL 14+ です。流れはコマンド 2 つです。

extenddb init
extenddb serve

init は PostgreSQL データベースにスキーマをプロビジョニングし、serve はワイヤプロトコルのサーバーを起動します。サーバーは https://127.0.0.1:8000 のようなエンドポイントで待ち受けます（TLS が必須なので https です）。

AWS SDK は、他のカスタムエンドポイントと同じ要領で向ければ済みます。変わるのは URL と認証情報だけです。

import {DynamoDBClient} from '@aws-sdk/client-dynamodb';

const client = new DynamoDBClient({
  endpoint: 'https://127.0.0.1:8000',
  region: 'local',
  credentials: {accessKeyId: '<extenddb-key>', secretAccessKey: '<extenddb-secret>'}
});

クライアントの設定から先 — PutItem、Query、TransactWriteItems — は、マネージド DynamoDB に対して書くコードと同一です。シングルテーブルのアイテムレイアウトも、クラウドとまったく同じように機能します。

DynoTable でやってみる

ExtendDB は DynamoDB のワイヤプロトコルを話すので、そのための専用の管理ツールは要りません。DynoTableを DynamoDB Localにつなぐのと同じ要領で ExtendDB のエンドポイントに向けてください。ExtendDB のポートと使い捨ての認証情報で オフライン（ローカル）プロファイル を作れば、DynoTable がアイテムを閲覧・クエリ・編集できます。違いは、それらが JAR のインメモリストアではなく、自分のディスク上の PostgreSQL に支えられていることだけです。

これがワイヤプロトコル互換の見返りです。SQL Workbenchも、ビジュアルなクエリビルダーも、アイテム編集も、ExtendDB に対してそのまま動くので、scan のスクリプトを書かずに自前ホストのデータの上に本物の GUI を得られます。

見込んでおくべき注意点が 1 つ。ExtendDB のエンドポイントは HTTPS 専用 ですが、DynoTable のオフラインプロファイルは（たいていの DynamoDB Local のセットアップと同様に）ループバックの host:port を対象にします。クライアントやツールが平文のループバックリスナーを必要とするなら、ExtendDB の手前で TLS を終端し（あるいはローカルのリバースプロキシを走らせ）、GUI をそちらに向けてください。いずれにせよ、ワイヤ上のプロトコルは DynamoDB JSON のままです。

落とし穴

• v0.1 を本番 DynamoDB として扱わない。スケーリング、レイテンシ、耐久性は AWS のものではなくあなたの PostgreSQL のものです。依存する前に、自分のワークロードでベンチマークを取りましょう。
• Global Tables／クロスリージョンレプリケーションはなし。設計がマルチリージョンのアクティブ・アクティブに依存しているなら、ExtendDB は道ではありません。それはマネージドサービスの機能です。
• 裏側のデータベースは自分でバックアップする。マネージドの PITR はありません。PostgreSQL のボリュームを落としたら終わりです。他の PostgreSQL と同じように pg_dump や WAL アーカイブを組んでおきましょう。
• 認証情報は ExtendDB 独自のもので、AWS IAM ではない。IAM のポリシー、ロール、条件キーがアクセスを統制してくれるとは期待しないでください。その認可モデルは引き継がれません。

次のステップ

• まずアクセスパターンをモデリングしましょう。バックエンドが DynamoDB でも PostgreSQL 経由の ExtendDB でも、同じシングルテーブル設計の作法が当てはまります。
• 読み書きを DynamoDB 式ビルダーで組み立てて確認し、DynamoDB JSON コンバータで素の JSON とワイヤ形式のあいだでフィクスチャを変換しましょう。
• 実際に動いている ExtendDB インスタンスを触る準備ができたら、DynoTableを接続して、他のテーブルと同じように閲覧してください。