Amazon Quantum Ledger Database (QLDB) は、台帳管理専用データベースです。アプリケーションのデータに生じたすべての変更に関する、完全で暗号的に検証可能な履歴を提供します。
従来のデータベースでは、データを上書きまたは削除できるため、開発者は監査テーブルや監査証跡などの技術を使用して、データ系列を追跡する機能を実装します。このような手法は機能していますが、カスタム開発が必要とされ、スケーリングが難しい場合があります。また、適切なデータすべてを確実に記録する責任がアプリケーション開発者にのしかかります。Amazon QLDB 内のデータは、追記のみ可能なジャーナルに書き込まれるため、完全なデータ系列が開発者に提供されます。さらに、Amazon QLDB ジャーナル内のデータがイミュータブルかつ検証可能なことは、台帳内のデータを信頼できることを意味します。
Amazon QLDB の特徴は、データ整合性、完全性、検証可能性が必要不可欠な SoR アプリケーションに自然に適合します。例えば、サプライチェーンや物流の分野では、運送業者間での移動や国外配送などの変更履歴全体を Amazon QLDB 上に構築されたアプリケーションで管理し、クエリと分析に利用します。金融では、SoR アプリケーションで、債権債務取引などの重要なデータを追跡します。銀行では、自社のアプリケーション内にレコード保管用の複雑なシステムを構築する代わりに QLDB を使用して、すべての金融取引の永続的で完全なレコードを簡単に保管できます。
Amazon QLDB のテクノロジーは、ブロックチェーンや分散型台帳ではありません。ブロックチェーンと分散型台帳のテクノロジーでは、アプリケーションが単一の組織によって所有されておらず、必ずしも関係者がお互いに完全に信頼し合う必要のない、複数の関係者が関わる分散型アプリケーションの問題の解決に焦点が置かれています。一方、QLDB は、所有するアプリケーション内で完全かつ検証可能なデータ変更履歴を管理する必要のあるお客様向けの、台帳専用データベースです。Amazon QLDB では、履歴、不変性、検証可能性などの特徴を生かしながら、完全マネージド型 AWS データベースの既存知識、スケーラビリティ、使いやすさを活用できます。アプリケーションの要件に分散化や信頼されない複数の関係者が関わることが含まれる場合は、ブロックチェーンソリューションが適している可能性があります。アプリケーションで、完全かつ検証可能なアプリケーションデータ変更履歴を必要とし、信頼されない複数の関係者が関わることがない場合は、Amazon QLDB が最適です。分散型台帳またはブロックチェーンに該当するユースケースについては、「Amazon Managed Blockchain」を参照してください。
Amazon QLDB では、完全かつ検証可能なアプリケーションデータ変更履歴に加えて、ACID トランザクションセマンティクス、柔軟なドキュメントデータモデル、SQL 形式の馴染みやすい API をサポートしています。さらに、QLDB は完全マネージド型で、プロビジョニングの必要がなく、アプリケーションのニーズに合わせて自動的にスケールします。
Amazon QLDB に接続して台帳のデータを扱うには、AWS からの QLDB ドライバーを使う必要があります。こちらのリンクの手順に従い、ドライバーのダウンロードと接続の設定を行ってください。
管理するサーバーやプロビジョニングする容量がないため、Amazon QLDB を使い始めるのは簡単です。AWS マネジメントコンソール、AWS コマンドラインインターフェイス (CLI)、AWS CloudFormation テンプレートを使用するか、QLDB API に対してコールを作成すれば、新しい台帳を数分で作成できます。
Amazon QLDB は一般的なブロックチェーンフレームワークの台帳よりも 2～3 倍多くのトランザクションを実行できます。ブロックチェーンフレームワークは分散型で、トランザクションを実行するには、トランザクションの妥当性に関してネットワークの大部分のメンバーの合意を得る必要があります。一方、QLDB は集中型の設計であり、複数の関係者の合意を得なくてもトランザクションを実行できます。
Amazon QLDB では PartiQL を用いてデータにアクセスし、操作できます。PartiQL は QLDB ドキュメント指向のデータモデルへの SQL 準拠のアクセスをサポートする新しいオープン標準のクエリ言語で、このモデルには半構造化およびネストされたデータを含みながら、どのようなデータソースからも独立しています。PartiQL の詳細についてはこちらをご参照ください。
Amazon QLDB の料金については、料金ページをご覧ください。
Amazon QLDB は次の AWS リージョンで利用可能です。米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、ヨーロッパ (アイルランド、フランクフルト)、アジアパシフィック (シンガポール、シドニー、ソウル、東京)、その他のリージョンでは近日中に公開予定です。
Amazon QLDB では、キャパシティーのプロビジョニングや、読み取りと書き込みの上限の設定に悩む必要がありません。QLDB では、台帳を作成してテーブルを定義するだけで、アプリケーションの需要に対応して自動的にスケールします。
Amazon QLDB に関する制限については、AWS サービスの制限のページでご覧になれます。
Amazon QLDB は現在バックアップや復元機能はサポートしていません。現在、S3 へのエクスポート機能はお使いいただけます。この機能をお使いになると、QLDB ジャーナルの内容を S3 にエクスポートできます。
現在のところ、 Amazon QLDB では時刻指定の復元機能はサポートしていません。
Amazon QLDB の台帳は複数のアベイラビリティーゾーン (AZ) にわたって、AZ あたり複数のコピーでデプロイされています。リージョン内では冗長性を確保しており、アベイラビリティーゾーンでの障害から完全復旧できるようにしていっます。書き込みは複数の AZ での耐久性のあるストレージに書き込まれるまでは認識されず、従って QLDB は非常に耐久性があります。
Amazon QLDB は高可用性サービスです。デフォルトでは、QLDB 台帳の複数のコピーがリージョン内の複数のアベイラビリティーゾーンにわたって作成されます。そのため、1 つのゾーンで障害が発生しても、QLDB の動作は継続できます。
現在のところ、Amazon QLDB ではクロスリージョンレプリケーションはサポートされていません。QLDB の S3 へのエクスポート機能を使うと、QLDB ジャーナルの内容を S3 バケットへエクスポートできます。S3 バケットはクロスリージョンレプリケーション用に設定できます。
Amazon QLDB は AWS Private Link に統合されています。VPC エンドポイントを作成できますので、VPC と PrivateLink がサポートされた AWS サービスとの間でのプライベート接続が可能です。この際、インターネットゲートウェイ、NAT デバイス、VPN 接続、または AWS Direct Connect 接続は必要ありません。
Amazon QLDB は AWS サービスと同じ認証の仕組みを用います。この仕組みでは、リクエスト署名が HTTP リクエスト (ヘッダーまたはクエリ文字列) に添えられている必要があります。この署名は他のリクエストフィールドと AWS 認証情報 (アクセスキー ID とシークレットアクセスキー) を用いて計算されます。
デフォルトでは、転送中でも保存された後も、データはすべて暗号化されています。Amazon QLDB は、2021 年 7 月 22 日にカスタマーマネージド AWS KMS キーのサポートを開始しました。ローンチ前に作成されたすべての台帳は、デフォルトでは AWS 所有のキーで保護されていますが、現在、カスタマーマネージドキーを使用した保管時の暗号化には適していません。 台帳の作成時間は QLDB コンソールで確認できます。
1) Amazon Kinesis データストリーム (KDS) を作成する。Amazon Kinesis コンソールまたは AWS SDK を使用して KDS ストリームを作成します。既存のストリームの使用も可能です。
2) Amazon QLDB ストリームを作成する。Amazon QLDB コンソールまたは AWS SDK を使用して Amazon QLDB ストリームを作成します。ストリームを作成するためには、以下の重要な項目を設定する必要があります。
3) KDS ストリームを消費する。Kinesis Data Firehose や Kinesis Data Analytics などの Kinesis サービスを使用して Kinesis アプリケーションを作成し、ストリームを消費および処理できます。AWS Lambda を使用して Kinesis Data Stream のレコードを消費することも可能です。
Amazon QLDB ストリーミング機能では、少なくとも 1 回の配信を保証します。QLDB ストリームによってジャーナルから生成された各コントロール、ブロックサマリー、リビジョン詳細レコードは、少なくとも 1 回 Amazon Kinesis にストリーム配信されます。状況によっては重複するレコードが Kinesis ストリームに発生する可能性があるため、必要に応じてアプリケーション層に重複排除ロジックを設置する必要があります。以前のブロックやリビジョンが Kinesis ストリームに順不同でパブリッシュされる可能性があるため、順序の保証はありません。