Amazon QLDBハンズオンメモ
毎週土曜日恒例「AWSの基礎を学ぼう 特別編」今週は「最新サービスをみんなで触ってみる はじめての元帳データベース」でした。サービス名でいえば、Amazon QLDB。かなりの走り書きで不確かそうな内容も含んでしまいますが、メモを残しておきたいと思います。
ブロックチェーンの基礎とQLDB
ブロックチェーンのベースとしてビザンチン耐性やイミュータブルトランザクションがある。ビザンチン耐性は分散型ネットワークの乗っ取りに対する耐性で「不誠実な」ノードが全体の1/3までなら乗っ取られないという理論（合ってるかな？）。
イミュータブルトランザクション（イミュータブルデータモデル？）は履歴がすべて残され追跡可能性があるデータ保持形態。
QLDBでは操作クエリ（PartiQL）がハッシュチェーン付きで記録され、ハッシュ値により履歴の改ざんや抜けの有無を検証できる。ハッシュ値は、2番目以降の処理では「直前の記録のハッシュ値＋今回のデータ」から計算される（下図：「20200609 AWS Black Belt Online Seminar Amazon Quantum Ledger Database」スライド23）。
後からどこかのデータが変更されたり記録が落ちたりすると、直後の記録の正しいハッシュ値が変わり、それ以降の記録の正しいハッシュ値も変わっていく。逆に言えば、このハッシュ値のチェーンを検証することで、改変や抜け落ちがないと確認できる（下図：「20200609 AWS Black Belt Online Seminar Amazon Quantum Ledger Database」スライド26）。
QLDBは「イミュータブル」だけどブロックチェーンのような分散構成を持たない「中央集権型の台帳」サービス。イミュータブル（不変性）だけが求められている場合、QLDBは分散構成にまつわる処理がない分だけ、効率的に動作する（そして一般にAWS料金は処理の多寡に左右される）。
ハンズオン
実施したハンズオン内容は、ざっくりこちらの「QLDB基礎」＋レコード削除してジャーナル（＝イミュータブルトランザクション）確認。
QLDBのデータ操作は、SQLライクなPartiQLを使う。ハンズオンではselect、update、insertを行い、最後にdeleteクエリでレコードを消す。
delete from VehicleRegistration where VIN = '1N4AL11D75C109151'このあと該当テーブルで「select *」すると該当レコードは消えているのだけど、次のようなクエリでhistoryを検索すると、操作記録は残っている。
SELECT * FROM history(VehicleRegistration) AS h
WHERE h.metadata.id = '1CWSsG5NE3r5AZjsamXfw5'これがQLDBの「Journal」に記録されている「イミュータブルトランザクション」なのかな、と理解した。
「Journalが残る」から考えたこと
Journalのデータ（ヒストリー）は個別に消すことはできず、台帳を消さない限り残り続ける。
ハンズオン中に、個人情報などの格納については注意があった。初期状態で個人情報が記録されてオプトアウトが可能なシステムでは、オプトアウト時点でデータ削除が求められることになる。この時Journalまでは削除できないので、Journalが残る状態での論理削除で是とするかリーガル担当者を交えて事前に確認しておいた方がよいとのこと。
この問題、削除要請に応えられる範囲という話なので、マルチテナントサービスのバックエンドに使った場合の、利用終了に伴うデータ削除に応えられるかといった場面でも関わってきそうに思った。それからJournal（History）を閲覧できる人は限定しておいた方がよさそうだとも。これはおそらくリビジョン履歴のクエリにあたり、元帳権限モードをStandardにしたうえで、以下をIAMで適宜制御すればよさそうに見える。確信はない。
コマンド 履歴から選択 (テーブル名)
リソース arn:aws:qldb:region:account-id:ledger/ledger-name/table/table-id
アクション qldb:PartiQLHistoryFunction
あとJournalが増え続けるということは、データが増え続けるのだから、利用料金も増え続けるのかなとちょっと思った。現時点でのQLDBの料金表を見ると、「データストレージおよびIO」でジャーナルストレージについても保持データサイズに対する料金が設定されていた。やっぱり増え続けるらしい。
最後、本当にJournalを消そうと思ったら台帳を消すことになる。逆にJournalを消させないためには、台帳削除が可能な人を絞る必要がある。これは以下のどちらかのアクションを利用可能な人を限定すればよさそうに思われた。こちらも確信はない。
UpdateLedger … 台帳の「削除保護オプション」を変更するアクション。（UpdateLedgerで変更できる設定はこれしかない）。削除保護はデフォルトで有効で、これを無効化しないと台帳削除はできない。
DeleteLedger … 台帳を削除するアクション。
台帳データベースといわれると、その特徴である改ざん防止（削除保護）と、どのサービスであれ要チェックの料金が気になるのだけど、とりあえずその辺まではイメージを持てた感じ。実際に使おうということになれば、いろいろ試してみないとダメだけど、ひとまずQLDB（Ladger）の学習としては満足。よい学習機会になりました。