ExtendDB のご紹介: プラガブルなストレージバックエンドを備えたオープンソースの DynamoDB 互換アダプター

本記事は 2026 年 05 月 20 日に公開された “Introducing ExtendDB: An open source DynamoDB-compatible adapter with pluggable storage backends” を翻訳したものです。

本日、Apache 2.0 ライセンスの下でリリースされた、プラガブルなストレージバックエンドを備えたオープンソースの Amazon DynamoDB 互換アダプターである ExtendDB を発表します。ExtendDB は DynamoDB のワイヤープロトコルを実装し、最初のバックエンドとして PostgreSQL に対応してリリースされます。そのため、DynamoDB で動作するすべての AWS SDK、CLI、ツールは ExtendDB でも変更なしで動作します。

本記事では、ExtendDB の紹介、利用開始の手順、アーキテクチャの説明を行います。これは開発、テスト、実験用途向けの v0.1 リリースです。

背景

Amazon DynamoDB は、あらゆる規模で 1 桁ミリ秒のパフォーマンスを発揮する、サーバーレスでフルマネージドな NoSQL データベースです。DynamoDB 上に構築するチームは、そのデータモデリングパターン、条件式、トランザクション、ストリームについて深い専門知識を培います。それを取り巻く CI パイプラインを構築し、運用ランブックを作成し、エンジニアのトレーニングを行います。これらのチームがエッジ、オンプレミス、切断された環境へと活動範囲を広げるにつれ、同じ API と開発者エクスペリエンスを持ち込みたいというニーズが生まれます。

ある大手航空会社は、ほとんどのアプリケーションを AWS 上で実行し、DynamoDB を主要なデータストアとして利用しています。しかし、ゲートおよび機内システムは、ネットワーク障害が発生しても稼働し続ける必要があり、搭乗、手荷物照合、機内販売についてはクラウドへのラウンドトリップ遅延を許容できません。これらのシステムは、同じアクセスパターン、同じ条件付き書き込み、同じトランザクション保証を必要とします。互換性のあるランタイムがないため、このチームは異なるデータアクセスレイヤー、異なる運用手順、異なる専門知識要件を持つ 2 つの別々のアプリケーションスタックを保守しています。

現在、AWS の外で DynamoDB ワークロードを実行することは、データアクセスレイヤーを書き直すことを意味します。DynamoDB Local はユニットテスト向けの単一プロセスのツールです。ExtendDB は初期段階のプロジェクトとして、より広範なローカル開発およびオンプレミスシナリオを対象としています。

ユースケース

ExtendDB はマネージド DynamoDB サービスが利用できない、または現実的でないシナリオに対応します。

ローカル開発とCI/CD

クラウドへの依存性ゼロで、ラップトップ上または継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインで DynamoDB ワークロードを実行できます。統合テストは数秒で開始でき、決定論的に実行され、クリーンに終了します。

オンプレミスおよびエアギャップ環境

クラウド接続のない開発者、オンプレミスワークロードを実行するチーム、エッジのオペレーターは、自身のインフラストラクチャ上で DynamoDB のアクセスパターンを実行できます。

マルチクラウドおよびハイブリッド

インフラストラクチャプロバイダー間でのポータビリティを試しているチームは、PostgreSQL が利用可能なあらゆる場所で DynamoDB API を利用できます。次の図は、ExtendDB から DynamoDB へのマイグレーションがエンドポイント URL の変更だけで済むことを示しています:

ExtendDB とは

ExtendDB は DynamoDB ワイヤープロトコルの実装で、Rust で書かれており AWS のエンジニアによって開発されています。アプリケーションとストレージバックエンドの間に位置するトランスレーターと考えてください。PostgreSQL リファレンスバックエンドを使用する場合、アプリケーションは DynamoDB プロトコルで通信し、ExtendDB が SQL に変換し、PostgreSQL がストレージを処理します。

ExtendDB はワイヤーレベルで DynamoDB JSON プロトコル を実装します。既存のアプリケーションコード、SDK、ツールは変更なしで接続できます。すべてのデータは PostgreSQL に保存されるため、pg_dump、レプリケーション、ポイントインタイムリカバリ、標準的な監視など、すでに知っている運用ツールを利用できます。

ストレージレイヤー は Rust の trait として定義されています。水平スケールに適した Apache Cassandra など、追加のバックエンドをコアを変更することなく実装できます。

ExtendDB は外部ランタイム依存性のない単一バイナリにコンパイルされます。TLS は必須であり、初回実行時に自己署名証明書を自動生成します。ローカル IAM ライクなクレデンシャルストアを備えた SigV4 認証 により、アプリケーションコードは DynamoDB サービスに対して使用するのと同じ署名ロジックを使用します。

サポートされるオペレーション

アカウントとクレデンシャルの管理は、コマンドラインまたは https://127.0.0.1:8000/console/ の Web 管理コンソールから行えます。

利用開始

ExtendDB は Linux と macOS で動作します。Rust 1.85+ と PostgreSQL 14+ が必要です。

git clone https://github.com/ExtendDB/extenddb.git
cd extenddb
cargo build --release

init コマンドは、稼働中の PostgreSQL インスタンスに接続し、必要なデータベースとスキーマを作成し、管理者用クレデンシャルを生成し、TLS 証明書をプロビジョニングし、設定ファイルを書き出します:

./target/release/extenddb init
./target/release/extenddb serve --config extenddb.toml

次に、DynamoDB アクセス権を持つ IAM ユーザーを作成します。init コマンドは、extenddb manage で使用する管理者パスワードとデフォルトのアカウント ID を出力します:

./target/release/extenddb manage --user admin --password '<admin-password>' \
  create-user --account-id <account-id> --user-name myuser

./target/release/extenddb manage --user admin --password '<admin-password>' \
  put-user-policy --account-id <account-id> --user-name myuser \
  --policy-name full-access \
  --policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"dynamodb:*","Resource":"*"}]}'

./target/release/extenddb manage --user admin --password '<admin-password>' \
  create-access-key --account-id <account-id> --user-name myuser

これによりアクセスキー ID とシークレットが返されます。CA バンドルとともにこれらをエクスポートします:

export AWS_ACCESS_KEY_ID="AKIA..."
export AWS_SECRET_ACCESS_KEY="extenddb..."
export AWS_CA_BUNDLE=~/.extenddb/tls/cert.pem

ExtendDB は https://127.0.0.1:8000 でリッスンしています。標準的な DynamoDB コマンドを使用します:

aws dynamodb create-table \
  --table-name Orders \
  --attribute-definitions AttributeName=PK,AttributeType=S AttributeName=SK,AttributeType=S \
  --key-schema AttributeName=PK,KeyType=HASH AttributeName=SK,KeyType=RANGE \
  --billing-mode PAY_PER_REQUEST \
  --endpoint-url https://127.0.0.1:8000 \
  --region us-east-1

aws dynamodb put-item \
  --table-name Orders \
  --item '{"PK":{"S":"CUSTOMER#123"},"SK":{"S":"ORDER#2026-001"},"total":{"N":"49.99"}}' \
  --endpoint-url https://127.0.0.1:8000 \
  --region us-east-1

aws dynamodb query \
  --table-name Orders \
  --key-condition-expression "PK = :pk" \
  --expression-attribute-values '{":pk":{"S":"CUSTOMER#123"}}' \
  --endpoint-url https://127.0.0.1:8000 \
  --region us-east-1

AWS SDK はエンドポイント URL の設定をサポートしています。エンドポイント URL を変更するだけで、その他はすべて変更不要です。

アーキテクチャ

ExtendDB は責務を Rust の crate に分離しています。core crate は、純粋な同期 Rust として型、検証、式の評価を処理します。engine crate は DynamoDB API のセマンティクスを実装します。storage-postgres crate は PostgreSQL バックエンドであり、任意のバックエンドが実装すべきインターフェースを定義する storage trait に対して構築されています。server crate は HTTP サーバー、管理 API、Web コンソールを提供し、これらを統合します。

次のアーキテクチャ図は、ExtendDB の高レベルの概要を示しています:

制限事項

ExtendDB は DynamoDB ではありません。これは互換性のある実装であり、マネージドサービスの代替ではありません。パフォーマンス特性、スケーリング動作、運用上の特性は異なります。マネージドサービスの保証が必要な場合は DynamoDB を使用してください。

データベースが必要であり、その可用性、バックアップ、メンテナンスはユーザーの責任です。TLS は必須です。ExtendDB は SigV4 署名検証とポリシー評価を備えた独自の IAM ライクな実装を含みます。これはスタンドアロンのシステムです。ExtendDB で作成されたクレデンシャルとポリシーは AWS IAM とは完全に分離されており、両者の間で共有することはできません。グローバルテーブルとクロスリージョンレプリケーションは、これらが DynamoDB 固有のマネージド機能であるため実装されていません。

参加するには

本記事では、PostgreSQL をバックエンドとするオープンソースの DynamoDB 互換アダプターである ExtendDB を紹介しました。ローカル開発、CI/CD テスト、オンプレミスデプロイメント、エアギャップ環境のいずれであっても、AWS の外で DynamoDB アクセスパターンを必要とするワークロードがある場合、ExtendDB は既存のアプリケーションコードと SDK で動作する互換性のある実装を提供します。

ExtendDB は初期段階にあり、私たちはオープンに開発を進めています。GitHub リポジトリ をクローンし、Getting Started ガイド に従って、数分で DynamoDB 互換エンドポイントをローカルで実行できます。コントリビュート方法の詳細については、Contribution Guide を参照してください。ギャップを発見した場合や、ストレージバックエンドをコントリビュートしたい場合は、issue を起票するか、プルリクエストを送信してください。

著者について

	Lee Hannigan Lee はアイルランドのドニゴールを拠点とするシニア Amazon DynamoDB データベースエンジニアです。彼はビッグデータと分析技術の強固な基盤の上に、分散システムにおける豊富な専門知識を持っています。彼の役割では、DynamoDB のパフォーマンス、スケーラビリティ、信頼性の向上に注力し、お客様や社内チームがその機能を最大限に活用できるよう支援しています。
	Deepthi Mohan Deepthi は DynamoDB チームのプリンシパルプロダクトマネージャーです。