【ITニュース解説】AWS Shipped a DynamoDB API That Stores Everything in Postgres. Read the Tables It Writes

ソフトウェア開発の世界では、データを保存するためのさまざまなデータベースが使われている。特にクラウド環境でよく利用されるのが、Amazon Web Services (AWS) が提供する「DynamoDB」というデータベースだ。DynamoDBは「NoSQLデータベース」の一種で、大量のデータを高速に処理することに特化しており、サーバーの管理などをAWSに任せられる（マネージドサービス）という大きな利点がある。しかし、その内部でデータがどのように保存されているのか、開発者からは見えない仕組みになっているため、ブラックボックスのように感じられることもあった。

今回紹介する「ExtendDB」は、このDynamoDBの「見えない裏側」を明らかにする、非常に興味深いプロジェクトだ。ExtendDBは、AWSのDynamoDBチームのメンバーが開発し、オープンソースとして公開されたサーバーであり、その一番のポイントは「DynamoDBのAPI（アプリケーションプログラミングインターフェース）を使ってやり取りするデータを、すべてPostgreSQLという別のリレーショナルデータベースに保存する」という点にある。つまり、開発者が普段使っているDynamoDBのSDK（ソフトウェア開発キット）やAWS CLI（コマンドラインインターフェース）からは、ExtendDBがまるで本物のDynamoDBであるかのように見えるが、そのデータの保存先は、実は身近なPostgreSQLなのだ。

なぜこれが重要なのかというと、DynamoDBがどのようにデータを格納しているのか、これまで具体的に確認する手段がなかったからだ。DynamoDBは、データアクセスパターンに基づいてテーブルを設計する「シングルテーブルデザイン」という考え方が推奨されるが、その設計が実際にどのようにデータベースの内部で機能しているのかを、開発者が直接確かめることはできなかった。ExtendDBを使えば、DynamoDBのテーブルやインデックスがPostgreSQLの一般的なSQLテーブルとしてどのように表現されるのかを、具体的な構造として見ることができる。これにより、DynamoDBの内部動作や設計の意図を深く理解するための学習ツールとして活用できる。

ExtendDBは、プログラミング言語Rustで書かれており、AWSによってメンテナンスされている。現時点では「バージョン0.1」という位置づけであり、「開発、テスト、実験」を目的としたリリースであると明言されている。「ExtendDBはDynamoDBではない」という注意書きもされており、あくまで本物のDynamoDBの代替としてではなく、特定の目的のために利用されることを想定している。このプロジェクトは、DynamoDBが提供する基本的な機能、例えばテーブルの作成、データの読み書き（QueryやScan）、複数のデータをまとめて処理するバッチ処理、データの更新を追跡するストリーム、データの自動削除機能であるTTL（Time To Live）、さらには最近注目されているベクトル検索（PostgreSQLのpgvector拡張機能を利用）までをサポートしている。推奨されるバックエンドデータベースはPostgreSQL 14以降だが、将来的にはMongoDBやSQLiteもサポートの対象として挙げられている。セキュリティ面では、TLS（通信の暗号化）が必須であり、すべてのリクエストはAWS SigV4という署名メカニズムで認証される必要がある。

ExtendDBを実際に動かすのは比較的簡単だ。Docker Composeというツールを使って、PostgreSQLとExtendDBを同時に起動できる。開発環境を素早く構築し、AWS CLIを使ってDynamoDBと同じコマンドを実行することで、ExtendDB上のテーブルを操作できるのだ。ただし、ExtendDBは自己署名証明書を使うため、AWS CLIからアクセスする際には、その証明書を信頼するための設定が必要となる。設定が完了すれば、まるでDynamoDBを操作しているかのように、テーブルの作成、アイテムの追加、データのクエリといった操作が可能になる。

そして、ExtendDBの最も興味深い点は、PostgreSQLのクライアントツールであるpsqlを使って、その裏側のデータベースを直接覗き見できることだ。ExtendDBは、作成されたDynamoDBの各テーブルやインデックスを、PostgreSQL内の独立したSQLテーブルとして管理する。これらのSQLテーブルは、一意のIDに基づいて命名される。例えば、DynamoDBのテーブルが持つプライマリキー（PK）やソートキー（SK）は、PostgreSQLのテーブルではそれぞれのカラムとして格納される。ソートキーに関しては、文字列、数値、バイナリという3種類の型に対応できるよう、それぞれ専用のカラムが用意されている。DynamoDBの文字列ソートがUTF-8バイト順であることを再現するため、PostgreSQLのCロケールによる照合順序（COLLATE "C"）が適用されている点も注目すべきだ。

DynamoDBのアイテムに含まれる、キー以外のすべての属性（例えば、顧客のプランや注文の合計金額など）は、PostgreSQLのJSONB型という単一のカラムにJSON形式で格納される。これは、DynamoDBがスキーマレス（事前に厳密なデータ構造を定義しない）な特性を持つことを、リレーショナルデータベースであるPostgreSQLで実現するための工夫だ。さらに、DynamoDBのGSI（グローバルセカンダリインデックス）は、PostgreSQLでは元のテーブルとは別のSQLテーブルとして作成される。GSIのキーは必ずしも一意ではないため、PostgreSQLのインデックステーブルのプライマリキーには、GSIのキーに加えて元のテーブルのプライマリキーとソートキーも含まれることで、一意性が保たれる仕組みになっている。GSIへの書き込みは、元のテーブルへの書き込みとは別に、PostgreSQLの別のテーブルへもデータが同期されるという具体的な動作も確認できる。DynamoDBではこれが自動で行われるため見えないが、ExtendDBを通じてその具体的なプロセスを目にすることができるのだ。

DynamoDBのクエリがどのようにSQLに変換されるのかも興味深い。例えば、ソートキーに対する「begins_with」（特定の文字列で始まるデータを検索する）というクエリは、PostgreSQLでは「>= 'ORDER#' AND < 'ORDER$'」というように、特定のバイト範囲を指定するSQLの範囲検索に変換される。これにより、DynamoDBのアクセスパターンが、リレーショナルデータベースのインデックスをどのように利用しているのかを具体的に理解できる。また、DynamoDBでキー以外の属性に対するフィルタリング（FilterExpression）が、実際にデータを読み込んだ後に適用されるのと同じように、ExtendDBでもPostgreSQLが対象となる行を一度すべて読み込んでから、不要な行を破棄するという動きをするため、フィルタリングによって読み込みコストが下がるわけではないことも確認できる。

ExtendDBの現在の主な用途は、ローカルでの開発、CI（継続的インテグレーション）環境でのテスト、あるいはインターネットから隔離されたオンプレミス環境やマルチクラウド環境での利用が想定されている。特に、CI環境では、普段使い慣れたPostgreSQLのバックアップ機能（pg_dumpなど）を使ってテストデータを簡単に用意できる点が魅力だ。しかし、ExtendDBはまだ「v0.1」であり、本番環境での利用にはいくつかの注意点がある。例えば、DynamoDBの「グローバルテーブル」や「PartiQL」といった高度な機能は実装されていない。また、DynamoDBが提供するマネージドサービスとしての可用性、自動スケーリング、バックアップ、メンテナンスはExtendDBでは提供されず、これらすべてをユーザー自身が管理する必要がある。パフォーマンスについても、まだ検証段階であり、本番ワークロードでの利用を検討する際には、必ず自身の環境で十分な性能テストを行うべきだ。

結論として、ExtendDBはDynamoDBの内部動作を深く学びたいシステムエンジニア初心者にとって、非常に価値のある「学習ツール」だと言える。DynamoDBがどのようにデータを格納し、クエリを処理しているのかを、身近なPostgreSQLの視点から具体的に理解できる機会を提供する。しかし、これはDynamoDBからの乗り換え先として設計されたものではない。もし本格的にPostgreSQLを使いたいのであれば、DynamoDBのAPIレイヤーを介さず、最初からPostgreSQLの特性を活かしたデータモデルを直接設計する方が、より効率的でパフォーマンスも良い結果が得られるだろう。ExtendDBは、DynamoDBとPostgreSQLの間の架け橋となり、それぞれのデータベースの理解を深めるための、ユニークな視点を提供してくれるツールなのである。