Amazon Web Services ブログ
Amazon QLDB サポート終了と移行先ソリューションの紹介
Amazon Quantum Ledger Database(Amazon QLDB) は、2025 年 7 月 31 日にサポートが終了することがアナウンスされています。本ブログでは、Amazon QLDB のサポート終了に伴う移行先のソリューションについてご紹介します。
Amazon QLDB のサポート終了
Amazon QLDB は、フルマネージド型の台帳データベースサービスです。Amazon QLDB は、2025 年 7 月 31 日にサポートが終了することがアナウンスされています。今回の Amazon QLDB のサポート終了のアナウンスに伴い、AWS では Amazon Aurora PostgreSQL への移行に関する 2 つのブログを公開しています。
・Amazon QLDB の Amazon Aurora PostgreSQL への移行
・監査のユースケースで Amazon QLDB を Amazon Aurora PostgreSQL に置き換える
また、Amazon QLDB の移行先候補としては、AWS のパートナーのソリューションもあります。ここでは、Amazon QLDB の移行先として株式会社 Scalar のソリューションであります ScalarDL をご紹介します。
株式会社 Scalar について
株式会社 Scalar は「データマネジメントの未来を創る」というビジョンのもとに、データの完全性・真正性を保証する ScalarDL や、データベースの仮想化を実現する ScalarDB などの製品を開発している会社です。
Amazon QLDB と ScalarDL
Amazon QLDB は、追記型で不変なデータの変更履歴を提供します。この変更履歴は暗号学的な方法で保護されており、単にそれらを表示するだけでなく、各変更の完全性をさかのぼって検証することができます。
一方、ScalarDL も同様に追記型であり、暗号学的な方法に基づく不変なデータの変更履歴とその完全性検証機能を提供します。
ScalarDL は、データベースにおける改ざんなどの任意の故障(ビザンチン故障)の検知を実現するデータベースミドルウエアです。AWS Marketplace でも提供されており、Amazon DynamoDB や Amazon Aurora などと組み合わせて利用することができます。
Marketplace:ScalarDL Ledger
Marketplace:ScalarDL Auditor
以降では、Amazon QLDB と ScalarDL の違いについて具体的に触れていきたいと思います。
Amazon QLDB と ScalarDL の違い
Amazon QLDB と ScalarDL はどちらもデータの変更履歴機能と完全性検証機能を提供する点で共通していますが、そのデータモデルやアクセスインタフェース等いくつかの違いがあります。
- データ操作
Amazon QLDB は、PartiQL と呼ばれる問合せ言語を用いて台帳のデータを追加・更新したり、参照したりすることができます。PartiQLはSQL互換な問合せ言語で、SELECT、INSERT、UPDATE といったステートメントで台帳にアクセスすることが可能です。
一方、ScalarDL では、「コントラクト」と呼ばれるビジネスロジックを記述した小さなプログラムを介して台帳にアクセスします。具体的には、コントラクトは Java 言語で記述することができ、get()、scan()、put() といったインタフェースを提供しているため、これらを用いて PartiQL の SELECT、INSERT、UPDATE ステートメントによる操作を置き換えることができます。 - データモデル
Amazon QLDB と ScalarDL では異なるデータモデルを採用しているため、移行に際してはいくつかの注意が必要です。Amazon QLDB はテーブルやインデックスといったリレーショナルデータベースに似たデータモデルを採用する一方、ScalarDL は高いスケーラビリティを実現するため、Key-Value 型に似たフラットでシンプルなデータモデルを採用しています。具体的に ScalarDL の台帳は、文字列型のID (アプリケーションが利用する主キー) で特定可能なレコードの集合として表現されます。そのため、ScalarDL ではテーブルを明示的に作るかわりに、ID にテーブルを識別するプレフィックスを含めることで仮想的にテーブル相当の機能を実現します。また、インデックスが必要な場合には、このデータモデル上でインデックスキーとレコードのマッピングを作成します。
なお、ScalarDL への移行をより容易にするため、株式会社 Scalar からテーブルやインデックスの作成および PartiQL の各種ステートメントに相当する事前定義済みのコントラクトの提供が 予定されています。 - 履歴表示処理
Amazon QLDB は、テーブル内のレコードの過去のバージョンにアクセスするため、history() 関数を提供しています。history() 関数を使用すると、時間の経過とともにデータレコードがどのように変化したかを確認できます。
ScalarDL では、コントラクトにおいて scan() インタフェースを使用することで、任意の範囲の過去のレコードバージョンを取得・表示することができます。 - レコードの完全性
Amazon QLDB では、ダイジェストと呼ばれる暗号学的ハッシュを用いて台帳内のレコードの完全性を検証することができます。具体的には、ある時点における台帳のサマリーであるダイジェストを信頼できる第三者が保管しておき、そのダイジェストとレコードのバージョンを指定して検証を行います。レコードのバージョンのハッシュ値とマークルツリーと呼ばれる木構造で管理されたハッシュ値を用いてダイジェストを再計算することで、当該レコードバージョンの完全性を確認できます。
ScalarDL でもAmazon QLDB におけるダイジェストと似たように、暗号学的ハッシュを用いてレコードの完全性を検証できます。ScalarDL では、過去のレコードバージョンがハッシュチェーンでつながれています。そのため、過去の更新履歴をさかのぼって各レコードバージョンの内容を再計算し、正しくハッシュチェーンが構成されているかを検証することで、レコードの完全性を確認できます。この検証は、validate-ledger と呼ばれる CLI や API を使用して行います。また、ScalarDL では、コントラクトの実行や validate-ledger の実行の結果として、レコードのハッシュ値等を含んだ「プルーフ」を取得することができます。このプルーフを信頼できる第三者が保管しておくことで、検証の信頼性を高めることができます。さらに、Auditor と呼ばれるコンポーネントを追加で利用すれば、例えば、台帳を管理するプログラム自体の改ざんも含め、任意の故障(ビザンチン故障)を検知できるようになります。 - 更新イベントのフィード
Amazon QLDB streams は、台帳で発生したすべてのデータ更新イベントをニアリアルタイムで Amazon Kinesis Data Streams にフィードします。フィードされたストリームデータは、台帳における重要なデータの更新状況の分析や疑わしいアクティビティの検出などに活用できます。
ScalarDL では、上記に似た分析プラットフォームを実現するために、台帳で読み書きされたデータを HTAP (ハイブリッド型トランザクション/アナリティクス処理) エンジンである ScalarDB へフィードできる「ファンクション」という機能を提供しています。ファンクションは、コントラクトと同様に Java 言語のプログラムであり、分析処理向けのデータ変換ロジックなども記述することができます。フィードされたデータは、ScalarDB を利用して、用途に合った様々な分析を行うことが可能です。
まとめ
以上、ScalarDL のご紹介と Amazon QLDB との違いについてご説明しました。Amazon QLDB からの移行先として ScalarDL について詳しく知りたい場合は、ScalarDL のドキュメンテーションサイトをご参照ください。
また、Amazon QLDB からScalarDL への移行については、アプリケーションやデータの移行含め株式会社 Scalar にてサポート頂けますので、ScalarDL への移行を検討したい場合は、株式会社 Scalar か AWS の担当までお気軽にお問い合わせください。
問い合わせ先:qldb-migration@scalar-labs.com
本ブログ執筆にあたり、株式会社 Scalar の山田様、根本様にご協力頂きました。お二方、ありがとうございました。
著者について