[レポート] DAT380: Amazon QLDB An engineer’s deep dive -なぜこれがゲームチェンジャーなのか- #reinvent

本記事に re:Invent 2019 で開催されたセッション「DAT380: Amazon QLDB An engineer’s deep dive on why this is a game changer」のレポートです。

スピーカー

• Andrew Certain
  • Senior Principal Engineer, Amazon Web Services

セッション概要

なぜ Amazon QLDB を初めての不変で検証可能な元帳データベースとして構築したのですか？ このセッションでは、AWS のシニアプリンシパルエンジニアである Andrew Given が、Amazon QLDB のユニークなジャーナルファーストアーキテクチャとそのさまざまな革新について説明します。トピックには、暗号化ハッシュ、マークルツリー、マルチ AZ の可用性、PartiQL サポートなどが含まれます。また、ブロックチェーンのデータ整合性の利点を SQL 互換データベースにどのように導入したかに特に焦点を当てています。

レポート

最適なエンジンの選択

ご存知のように、AWS の指針となる原則の 1 つは開発者の選択です。ワークロードに適したツールを選択してください。すべてを 1 つのデータベースにまとめて支配するのではなく、手持ちのタスクに最適なエンジンを選択することでより優れた機能、パフォーマンス、および価値が得られると考えています。

IBM RAMAC

IBM RAMAC はディスクドライブを備えたはじめてのコンピュータです。RAMAC は Random Access Method of Accounting and Control の略です。名前に会計(Accounting)が含まれているため、これは台帳データベースと思うかもしれませんが、そうではありません。IBM 350 はディスクドライブであり、500 万文字を格納している大きなケースです。これらのものはそれぞれ約 ＄35,000 の費用がかかります。データの保存にコストがかかるため、アプリケーションを設計するすべての人は今とは違ったことを考えました。西暦の 2 桁のみを使用するなど。しかし、これは問題でしたね？完全なレコードを保存できなくなりました。アクション、要約、データベースのみを保存でき、人々はそれらをレコードと呼びますが、実際にはレコードではありません。

1950年代のデータベース

たとえば、あるアカウントから別のアカウントに $40 を送金したい場合、(1956 年にはまだ発明されてませんでしたが)テーブルから口座残高を読んで確認します。口座に $40 ありますか？口座に十分なお金がありますか?次に更新する必要がある口座残高を読みます。コンピュータの新しい口座残高を使用してから、新しい口座残高テーブルを更新します。これらの操作はテーブルに対して直接実行されることに注意してください。

そのため、データベースへ同時に変更する人がいないことを確認するためのロックがあります。最近では、スナップショット分離を使用するかもしれませんが、更新はテーブルに対して直接実行されます。そして、あなたはそれをコミットし完了です。

この情報はデータベースにありません。おそらく 1956 年に紙テープなどに記録がありますがデータベースにアクセスしてその情報を取得することはできません。過去 60 年で状況は変化しています。今日、ストレージはるかに安いので保存する価値のある値のしきい値は大きく変わりました。そのため、単にデータベースに要約を保存するだけでは満足していません。彼らは何が起こったのかを知りたいのです。トランザクションです。

現在のデータベース

この例をもう一度見てみましょう。残高を読んで、相手に十分なお金があることを確認し、他の口座の残高を読みます。前と同じように残高を更新します。そして、このトランザクションテーブルに新しい行を挿入します。2019年12月4日にあなたに起こったことはデータベースにあります。それは素晴らしいことです。

開発者はアプリケーションコードにこのコードを記述するか、ストアドプロシージャを用意するか、トリガーを用意する必要があります。しかし、これらのものが並行して更新されるという事実は、同期が取れなくなることを意味します。これは非常に単純な例ですが、これらの監査テーブルはかなり複雑になる可能性があり、データベースに大量のストレージを占有し、パフォーマンスに影響を与える可能性があります。そして、私たちは何か違うことをしたかったのです。

ジャーナル

19 世紀のデータベースで重要なことは、最初にトランザクションをジャーナルすることであり、次に要約を更新することでした。QLDB は同じ方法で構築されます。まず、ジャーナルを更新してから、それらの変更がサマリーに反映されます。

QLDB では、最初に残高を読むときに同じことが起こるため、口座に十分なお金があることを確認し、他の残高を読み、新しい値を設定します。しかし、これらの値はテーブルに直接反映するのではなく、一時的に保存されることに気付くでしょう。次に、トランザクションを呼び出したコミッターがジャーナルに送信されると、ジャーナルはそれを受け入れるかどうかを決定します。

トランザクションが正当である場合、シリアル化できる場合、干渉するトランザクションが無い場合それを受け入れ、ジャーナルに書き込みます。その後にのみ、テーブルの残高が更新されます。QLDB　ジャーナルは、データベースで発生したすべての完全な記録です。ジャーナルを経由せずにデータを更新することはできません。量子(quantum)という言葉が出てきますが、量子コンピューティングとは関係ありません。量子は不可分な状態変化と関係しています。したがって、ジャーナルの各レコードは、トランザクションの完全なレコードです。

イベントベースのシステム

トランザクションはログの中にまみれており、さまざまな場所にあります。あなたが後にそれらをつなぎ合わせる場合 QLDB ジャーナルにはコミットされたトランザクションのみが一緒に含まれているため処理が容易です。そしてそれは外部化されています。ほとんどのデータベーストランザクションログでは、変更可能な内部 API を使用する必要があります。

イベントベースのシステムについて多くのことを聞いたことがあると思います。Jay Kreps は2013年12月に『The log』と呼ばれるこのブログを投稿しました。かなり長いサブタイトルが『What every software engineer should know about real-time data's unifying abstraction（すべてのソフトウェアエンジニアがリアルタイムデータの統合抽象化について知っておくべきこと）』です。これは素晴らしいブログです。まだ読んでいない場合は読むことを強くお勧めします。そして、これらのイベントベースのシステムでは、発生したすべてのログを取得し、事実だけをキャプチャして、それをさまざまな場所に広げることを考えています。ここにはたくさんの素晴らしいパターンがあります。ただし、左側の画像にあるように、これらのイベントの一部はデータベースによって生成されています。

最近、一部の人々は、これらの同じイベントベースのアイデアを使用して分散トランザクションを行うことについて話しました。Martin Kleppmann などは、この記事を ACM Queue で書いたばかりで、このイベント処理モデルを使用して分散スケーラブルトランザクションを実行する方法について説明しています。彼らのモデルでは、次のようなイベントを発行します。例えばお金を送金する場合、それはクレジットカードの承認のようなものです。制約が満たされていることを確認したら、実際に振替を処理します。

それはひどい考えではありません。それらのすべてにトランザクションロジックがある場合、物事を間違える機会がたくさんあります。そのため、各自がこれらの意図されたトランザクションに関する状態を構築し、誰かがタイムアウトが発生したかどうかを検出し、「このことは起こらなかった」というメッセージを送信する必要があります。この元に戻すロジックは非常に注意が必要です。そして、誰もが忠実に実装する必要があります。繰り返しになりますが、データベーストランザクションログについては、それらは同じ方法であるため、多くのことを記録します。また、中断もしくはロールバックが発生する場合があります。そして誰かがその物事を片付けなければなりません。

何のためのジャーナルか

真実の源はデータベースです。ある時点で、データベースにあるお金の真実の源は銀行のコンピューターに保存されています。このデータベースはこれらの制約をチェックする責任があります。たとえば、並行操作が正しいことをするように、残高が 0 を下回らないようにしました。そのため、QLDB は​​これらの他のシステムとは異なる決定を下しました、

新しいバランスを計算したこのステップに進んだとしましょう。そして、他のいくつかの取引が潜入しています。それで、顧客が $50 預け入れたとしましょう。こっそりと入った新しいトランザクション($125→$175)があります。さて、テーブルが新しい値で更新されるようになりましたが、それについて知りません。したがって、ここでジャーナルに変更を単純にプッシュすると、間違った結果が得られます。そして、多くのシステムがこのようにしています。それらは物事を順序付けるためにログまたはジャーナルに依存しますが、正確さのためではありません。

そのため、Hyperledger Fabric や Microsoft Research の Tango はデータ分散データ構造の一例です。ログは、物事の順序付けを行うだけです。そして利用者は、ログに記録されているものが正当なものであるかどうかを判断する責任があります。前にも言ったように、同種の利用者基盤を持っているなら、それは素晴らしいことです。しかし、異質な利用者基盤を持っている場合、注意が必要です。

QLDB は​​異なります。この一時的なトランザクション状態を構築しますが、実行したすべての読み取りに関する情報も含まれています。次に、それをジャーナルに送信すると、「ちょっと待って、これらの読み取りに干渉するトランザクションを認めましたか？」と、顧客がこれを理解する必要がないようにそれを拒否します。ジャーナルがそれを処理します。

ブロックチェーンではなく欲しいものは検証可能な履歴

ブロックチェーンのすごいところと、完全に誤解を招くものがある。私が最も重要なことの 1 つであると思うことはインセンティブ構造と分散された信頼です。人々にブロックチェーンを使用する必要があるかどうか、およびこれらのことについてどのように考えるかを説明する NIST テクニカルレポートに含まれています。

彼らはこの完全な履歴を持っていることに興奮しており、暗号化の観点から証明できました。人々がこれについて考え始め、それを欲しがったことを素晴らしかったのですが、多くの顧客と話したとき、「私たちはブロックチェーンの使用方法を理解するのに本当に助けが必要です。この履歴が欲しい、この検証性が欲しいがブロックチェーンは本当に複雑です。何が良い案はないですか？」彼らが最も望んでいたのは、データに対する信頼、監査の変更を記録する方法でした。そして、彼らはそれを簡単に外部化したかったのです。彼らはブロックチェーンを見ていましたが、この複雑さに本当に苦労していました。そのため、すでにこのジャーナルの最初のデータベースがありました。QLDB は、完全に管理された台帳データベースです。経時変化の完全かつ検証可能な履歴を保持します。

QLDB

それはどういう意味か？入門ガイドから始めることをお勧めします。それではサンプルの vehicle-registration を選択して [Get digest] をクリックすると、この結果が得られます。

ここで最も重要な部分は、このダイジェストであり、この奇妙な文字列です。それは何ですか？これは Base64 でエンコードされた数値です。ここでは、16進32バイトです。そして、これらはすべて SHA-256 です。

ビットコインが証明するものは何か

QLDB について詳しく話す前にビットコインの例を挙げたいと思います。それでは、2 週間前に何かをお届けするためにビットコインをいくつか支払ったとしましょう。しかし私はお届けしませんでした。だからあなたは私のところに来て、「ねえ、私のものはどこにあるの？」と言う。そして、私は「あなたが何を話しているのか分からない、あなたは私にお金を払ったことはない」と言います。ビットコインはトランザクションとブロックで構成されており、これらのブロックは一緒にチェーン化されていることをご存じの方もいるかもしれませんが、ビットコインでは実際に何を証明していますか？

ここにビットコイン取引の基本的な形があります。だから、「ねえ、私はこのウォレットからこの他のウォレットにいくらかのビットコインを移しています、そして署名があります。署名は、ウォレットの所有者が実際にこの取引を提出したことを証明します。」あなたはこれらのバイトを印刷し、この紙を見せます。私は言います「うーん、それは入力しただけじゃないの？」私は信じません。それでは、あなたは本当に何を証明する必要がありますか？

私が言いたいのは、2 つのことを示す必要があるということです。

1. トランザクションが実際にビットコインブロックの一部であることを証明する必要がある
2. そのブロックがビットコインチェーンの一部であることを証明する必要がある

これら 2 つは非常に絡み合っています。そして、ビットコインについて多くのことを知っている人にとっては、ビットコインを別々に考えようとするのは少しばかげているように思われます。ただし、2 つのことに注意してください。トランザクションが実際に承認されたかどうかについては説明していません。それが署名の目的です。それは公開鍵暗号化についてです。それについて話していない。また、このトランザクションが有効になるために、実際にウォレットに十分なビットコインがあったかどうかも関係ありません。それが、ビットコインノードが行っていることです。これは、ビットコインの分散信頼の一部です。私が話しているのは、あなたが私に見せているバイトが実際にブロックチェーンに記録されたという整合性についてです。

SHA-256

最初のステップでは、トランザクションをビットコインブロックの一部として証明します。さて、トランザクションのハッシュ値は次のとおりです。さて、これらのハッシュ値の意味は何ですか？これはビットコインのトランザクションではありません。したがって、このドキュメントを受け取り、SHA-256 を介して実行すると、この値が得られます。それはどういう意味ですか？SHA-256 は暗号化ハッシュ関数です。これらの関数で最も重要なものの1つは単に値を指定することです。その値にハッシュするドキュメントを見つけることは計算上実行不可能です。だから、あなたがその値を思いつくための唯一の方法は、実際にドキュメントを持っていたということです。同じハッシュ値で別のドキュメントを見つけるためのドキュメントがある場合も非常に困難です。そして、このようにドキュメントに小さな変更（90.25→90.24）を加えてもハッシュ値に大きな変更をもたらします。

マークルツリー

トランザクションがあり、ハッシュ値があります。 その後、ビットコインはマークルツリーを構築します。 マークルツリーは、ハッシュ値の単なるバイナリツリーです。 そのため、ハッシュ値を取得し、それらを結合します。 基本的には、最初のハッシュ値を取得し、それらのバイトを取得し、2番目のハッシュ値のバイトの隣にそれらを詰め込み、その結果のハッシュを取得します。

これを最後まで行ったツリーがあります。最上部はマークルツリールートと呼ばれます。たとえば、トランザクション 3 の一部を変更すると、ハッシュ値は完全に変更されます。親ハッシュが完全に変更されますのでルートも完全に変更されます。

トランザクションはデータです。マークルツリーはデータの整合性を検証するのに役立っています。これらの 2 つのことは別個であることを理解してください。たとえば、ビットコインではトランザクションとマークルツリーのルートと各ブロックを保存するだけです。したがって、1 つのトランザクションの整合性を検証するには、すべてのトランザクションが必要です。これが暗号の証明です。

マークルツリーのルートがその数字を見つける唯一の方法は、すべて同じ入力と同じ操作を持つことです。ほとんどのマークルツリーアプリケーションでは、ツリーノードを保存します。これにより、すべての入力から開始するのではなく、異なる種類の整合性証明を作成できます。

トランザクション2がルート 9F を持つこのマークルツリーの一部であることを証明したいのであれば、最初に行うことは兄弟ハッシュを一緒にしてこの中間結果 H1 を取得することです。中間結果 H1 を取得し、兄弟でハッシュして解決された H2 を取得します。H2 が同じであることを確認します。これらを行うことでマークルツリールートが生成されてからビットとトランザクションが変更されていないことを証明しました。

ブロックが実際にチェーンの一部であることを証明

すべてのビットコインブロックにはブロックハッシュがあります。ブロックハッシュの計算方法は、前のブロックのブロックハッシュとマークルツリールートを取得し、それらを一緒にハッシュして結果を取得することです。ここでは、マークルツリールートの 9F を取得し、前のブロックハッシュ 43 を連結してすべてが等しいことを確認します。(図中の R はマークルツリールートの 9F を指します)

このトランザクションがチェーンの一部であることの完全な証拠は、82 のハッシュから始めて、これらすべての他のハッシュと繰り返し組み合わせ、正しい結果が得られたら最後にチェックすることです。これらのハッシュ関数はプロパティのため、計算が機能する唯一の方法は、ビットが変更されていない場合のみであると考えています。これがブロックチェーンの整合性です。

QLDB のブロック構造

QLDB のブロック構造について簡単に説明します。ビットコインのブロック構造に非常に似ています。ブロック内のすべてのデータをカバーするマークルツリーがあります。マークルツリールートと前のブロックハッシュが現在のブロックハッシュを形成します。最初のブロックのハッシュ値は両方とも同じであることに注意してください。(後ほど説明)

QLDB でドキュメントを検証するか、実際にドキュメントのリビジョンを検証したいと思います。識別子付きのドキュメントがあり、更新のたびに更新します。リビジョンはジャーナルに記録されます。そのため、このブロックアドレスのリビジョンが改ざんされていないことを証明したいと思います。

また、ダイジェスト値が必要です。これは、目標番号です。ダイジェストチップアドレスと呼ばれるものがあります。

ブロックアドレスは QLDB のブロックを識別します。ブロックがどのチェーンにあるか示す識別子です。すべての QLDB レジャーには単一のストランドがありますが、将来は複数のストランドを持つと予想されます。そして、ストランドのどこにあるかを示すシーケンス番号があります。なぜドキュメントを検証したいとき、ドキュメントがある場所のブロックアドレスを提供しなければならないのですか？あるブロック内のドキュメントの証明は、別のブロック内のドキュメントの証明とは異なります。ダイジェストチップアドレスはダイジェストを取得したときのチェーンの終わりを示しています。したがって、このチェーンを使用してダイジェストを生成し、さらにいくつかのブロックを追加して別のダイジェストを生成した場合、これらの 2 つのダイジェストは異なるものになります。そのため、証明は異なっていなければなりません。

すべてのフィールドをロードしたら、検証をプッシュします。

証明ハッシュ

その仕組みを説明するために、この証明ハッシュについて説明しましょう。最初に、このように見えるリビジョンのハッシュ（青枠）がありました。次に、これらすべての証明ハッシュ、SHA-256 出力値の束（黄枠）があります。そして最後に、それらに一致するものをダイジェスト（赤枠）します。

ビットコインの例でも同じことです。検証したい値(青字）があります。SHA-256 ハッシュの束（黄字）があります。そして、以前に保存されたものと一致するかどうかを確認する必要がある出力（赤字）があります。リビジョンハッシュは検証したいものです。証明ハッシュを反復処理します。そして、答えが一致することを確認します。

コードはブラウザで実行されています。これがすべての作業を行っている行です。非常に簡単です。リビジョンのハッシュであるバイナリドキュメントハッシュを受け取り、それをすべての証明ハッシュを持つ関数に渡し、各ハッシュを繰り返し呼び出して、結合ハッシュで結果を返します。

結合ハッシュメソッドは次のとおりです。3つのセクションがあります。ハッシュの1つが空の場合は、結果はもう1つのハッシュを返します。（後ほど説明します）

次に、ハッシュを連結する必要があります。また、ビットコインの証明を思い出してください。ハッシュは繰り返し処理します。左側で連結することもあれば右側に連結することもあります。

QLDB では若干異なります。ハッシュを最初にソートする連結演算子を定義することにしました。ですから、左か右かは関係ありません。それらは証明がハッシュの単なるリストであることを意味します。

そして、SHA、連結されたハッシュを取得し、結果を返します。

ごれが実際に起こっていることです。これはブラウザで実行されます。任意の言語で実行できます。分散信頼のブロックチェーンの問題を解決しようとするのではなく、検証可能な整合性のデータベースの問題を解決しようとするのでもありません。整合性とは、データが変更されていないことを意味します。

不均衡なツリー

マークルツリーを Google で検索すると、検出されたすべての例には正確に 8 つのノードがあります。どうしてでしょう？4 つは面白くない。16 は描くのが難しい。では、6 つのノードがある場合はどうしますか？たとえば、ビットコインの場合ですが、ツリーを構築しているとき、ノードの数が奇数であればどのレベルでも最後のハッシュを複製するだけだと言います。つまり、動作します。ただし、1 つの小さな欠点があります。それはノードの数が奇数のブロックとの違いがわからないことがあります。最後の 2 つのトランザクションのノード数が偶数のブロックは、同じハッシュを持ちます。有効なビットコインブロックで同じトランザクションを 2 つ持つことはできません。最後の 2 つのトランザクションが同じものをハッシュしないことを確認するためのチェックがあります。静的ですが、一度だけ計算されます。

QLDB に非常に類似した Google の Certificate Transparency（証明書の透明性）プロジェクトもあります。一貫性の証明とマークルツリーの証明に関する興味深い Web ページがいくつかありますので、興味があればぜひご覧ください。静的ではありませんが、バッチ更新を行います。そのため、一度にノードを追加しようとはしていませんが、バッチでノードを追加します。彼らがすることは不均衡なバイナリツリーを持っている場合、並べ替えるだけです。

しかし、QLDB はノードを継続的に追加したいと思っています。そして、マークルツリールートは、1つのノードを追加するたびに有効である必要があり、できるだけ少ない状態を維持し、できるだけ少ないものを再計算する必要があります。この JavaScript コードを覚えていますか？

どちらかのハッシュが空の場合、結果はもう一方のハッシュになると言いました。他のハッシュのハッシュではありません。それはもう 1 つのハッシュです。これは ID 演算子です。したがって、実際にマークルツリーを常に無限に高く、無限に広くなるように定義しています。また、末尾を超えるハッシュは空です。これにより、マークルツリーの更新用のログインストレージを保持し、平均して計算にログを記録し、常に更新されたダイジェストを保持できます。また、効率的に過去に戻ることができるため、現在のチェーンに多くのブロックが含まれているかどうかがわかっているが、かなり前からダイジェストがある場合は、そのダイジェストを作成するためにダイジェストを再作成する必要があります。それが非常に効率的である証拠です。空は、最初の 2 つの値が同じである理由でもあります。最初のブロックの前のハッシュには暗黙的な空があります。

Ion

データベースに対してクエリを実行しコミットされると、メタデータを取得できます。[View as Ion] をクリックして取得します。

JSON のように見えます。これは完全な JSON ではなく、高い機能を備えています。そして、これが QLDB を使用した一部の人々にとって混乱とフラストレーションの原因となっていることを知っています。

私たちは話したい理由がいくつかあります。1 つは豊富なデータ型で、タイムスタンプが必要です。タイムスタンプなしでデータベースを操作することはできません。ハッシュについてはもっと説明する必要があります。1 ビットを変更するとハッシュがどのように変わったのかを思い出してください。これは本当に重要です

なぜなら、ドキュメントがあり、ジャーナルに何があり、何か違うことがあるとしたら、それが違うということを知りたいからです。しかし、先頭に 0 を追加した場合はどうなりますか？末尾の 0 はどうですか？フィールドの順序はどうですか？タイムゾーンなしのタイムスタンプと UTC はどうですか？JSON だけを使用することに決めた場合、2 つのものが同じ値にハッシュすることの意味を定義する必要がありました。ルールを定義する必要があり、このコードを記述する必要があります。

Ion は仕様で既に記述されています。多くの言語のライブラリがあります。それはオープンソースであり、あなたの貢献を歓迎します。Ion を選んだのはそれが本当に理由です。Ion が使用される Amazon 製品がますます多くなると思います。

PartiQL

Ion は PartiQL と密接に関係しています。リレーショナルデータモデルの素晴らしい点の1つは、開発者がこのデータがどのデータに従属するかどうかを判断したり、アクセスパターンを事前に把握したりする必要がなくなったことです。すべてがトップレベルのオブジェクトです。

残念ながら、これらの豊富なデータ構造を持つ最新のプログラミング言語との不一致があります。多くの場合、柔軟なスキーマが必要であり、ネストされたオブジェクトが必要です。そのため、ドキュメントデータベースがあり、これは非常に貴重です。そして、ドキュメントを QLDB に保存したいのです。 しかし、別のAPIを発明したくありませんでした。

幸いなことに、PartiQL と呼ばれるこの言語がありました。また、長年にわたって開発が続けられており、オープンコンテンツやネストされたコンテンツ向けの SQL の最小限の拡張セットとして設計されました。PartiQL は、Couchbase でサポートされている SQL++ から来ました。ますます一般的になることを本当に望んでいます。

なぜ PartiQL に興奮しているのですか？このドキュメントがありますので、いくつかのフィールドを引き出します。CustomerID があるとします。そして、この OrderItem の配列がありますね？したがって、これはネストされた配列であり、多数のアイテムがあります。通常、リレーショナルデータベースがある場合、これらは2つのテーブルになります。Order テーブルと OrderItem テーブルがあり、各 OrderItem には Order テーブルとの外部キー参照があります。そして、それらで何かをしたいなら Join をします。

PartiQL はそのギャップを埋めます。o.Items AS oi が言うように、このアイテムフィールドは実際にはネストされた構造であり、テーブルのように扱います。とても興奮しました。

マルチ AZ

トランザクションの状態を一時的に収集したと言ったことを思い出してください。そこで、QLDB がどのように見えるかをプロが描いたのがこれです。(雑w)

AWS サービスと同様にアプリケーションがあり、それらがロードバランサーと通信している場合、ロードバランサーはいくつかのサーバーにアクセスします。これは、トランザクションの状態をすべて蓄積しているためです。そして、その状態は同時実行制御を担当します。大量の読み取りを行い、その状態を失った後、書き込みを行い、そのトランザクションをジャーナルにコミットすると、問題が発生します。そのため、サーバーのフロントセットの背後では、トランザクションは背後の特定のサーバーに固定されています。これが意味するのは、サーバーが失われた場合、そのトランザクションは失われますが、それ以外のものは失われないということです。

私たちが構築しているジャーナルは、5年以上にわたって Amazon で本番利用されています。それは Kinesis の中核であったり、Dynamo Stream の中心だったり、S3 キーマップの中核です。可用性と耐久性に優れたマルチ AZ です。

そして、あなたが持つかもしれない 1 つの質問は、その状態を維持し、大量の読み取りを送信し、その後何か奇妙なことが起こり、何らかの理由で私の次の操作がのサーバーに行く場合、問題を抱えているのでしょうか？何も失っていないことをどのように確認しますか？これは QLDB API の別の部分であり、生の API を使用している場合は少し難しい場合があります。したがって、高レベルの API を使用することを強くお勧めします。

しかし、あなたがこれを試してみたい場合、それがどのように機能するかは、実際にすべての状態を一緒にハッシュすることです。したがって、トランザクション ID から始め、次にすべてのステートメントを取得し、それを一緒にハッシュし、繰り返しハッシュして、トランザクション全体のダイジェストを取得します。そして、クライアントが送信されると、ダイジェストが送信されます。一方、サーバーはまったく同じことを並行して実行しており、別のダイジェストを求めて競合しています。そのため、サーバーがいくつかの操作を逃した場合、順番どおりに実行されなかったり、2 回実行されたりすると、ダイジェストは一致せず、トランザクションはコミットされます。これは、整合性を確保するもう 1 つの方法です。

さいごに

アニメーションによる説明が多くレポートというよりも半分文字起こしのようになってしまいましたが、QLDB のジャーナルアーキテクチャや、どのようにして整合性を証明するのかがよく分かるセッションでした。暗号ハッシュやマークルツリーについては、ビットコインの考え方とほぼ同じであることが理解できました。

また、セッション内で紹介された『The Log』,NIST レポート,『Online Event Processing』についても冬休みの課題として目を通してみたいと思います。

以上！大阪オフィスの丸毛（@marumo1981）でした！

セッション動画

スライド

(執筆時点では未だスライド公開されていないようです)