Aurora DSQL: Scalable, Multi-Region OLTP
Aurora DSQLは、コンピューティング、ストレージ、およびトランザクション・コーディネーションを分離し、コミット時の裁定によってリージョン間のレイテンシを最小限に抑えることで、弾力的なスケーラビリティと強力な一貫性を実現する、サーバーレスでマルチリージョン・アクティブアクティブなSQLデータベースです。
原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む
あなたは、何百万人もの人々が、全く同時に本を借りたり、読んだり、書き換えたりしようとしている、巨大で混沌とした図書館を整理しようとしているところだと想像してください。コンピュータサイエンスの世界において、これはデータベースという課題です。データベースとは、アプリケーションが瞬時に情報を検索し、変更できるように情報を保存するシステムのことです。数十年の間、大きな問いは、インターネット全体を扱うために、どのようにしてこれらの図書館を崩壊させることなく成長させるかでした。従来の方法は、一人の司書がすべての本にスタンプを押さなければならず、そのために長い行列ができ、進行を遅らせるようなものでした。新しい「結果整合性」という方法は、人々が本の記述を推測して、後で間違いを修正するというものでした。これは高速ですが、今すぐ真実が必要な場合にはリスクがあります。現代のデータベースエンジニアリングの目標は、推測する方法のように速く、かつスタンプを押す方法のように信頼できるシステムを構築することであり、誰も手動で棚を管理する必要なく、毎秒数百万件のトランザクションを処理できるシステムを作ることです。
この論文は、Amazon Web Servicesによって設計された、まさにこの問題を解決するために作られた新しい種類のデータベースであるAurora DSQLを紹介しています。これは、訪問者の数に応じて瞬時に拡張または縮小できる、超スマートで自動運転の図書館と考えてください。著者たちは、「思考（SQLコードの実行）」、「ストレージ（本の保管）」、「ルール（二人が同時に同じページを変更しないようにすること）」を分離したシステムを構築しました。変更が行われるたびに作成される、永続的で変更不可能な日記のような特別な「ジャーナル（日誌）」を使用することで、DSQLはシステムの異なる部分が独立して動作することを可能にします。この設計により、DSQLはゼロのユーザーから毎秒数百万件のトランザクションまでスケールアップでき、速度を落とすことなく異なる大陸間で動作し、データを完全に一貫した状態に保つことができるため、誰かが本を書き換えている最中にその本を読む心配をする必要がありません。
切り離された図書館のマジック
Aurora DSQLの仕組みを理解するために、司書、本棚、そしてルール管理者がすべて異なる建物にあり、超高速の電報でつながっている巨大な図書館を想像してみてください。古いシステムでは、これらの部分は互いに固着していました。もし棚がいっぱいになると、図書館全体が停止して再編成しなければなりませんでした。DSQLはこれらを切り離します。
まず、クエリプロセッサがあります。これらはあなたと対話する司書です。あなたが本を求めるとき、彼らは重い本を自分で運びません。代わりに、彼らはFirecracker MicroVMと呼ばれる、小さく安全な仮想ルームの中で動作します。これらのルームは非常に効率的で、瞬時に作成または破棄できます。訪問者が急増すれば、システムは即座にさらなるルームを構築します。訪問者が減れば、空きスペースに対して料金を支払わなくて済むよう、それらを解体します。これが「サーバーレス」の部分です。あなたは司書を管理するのではなく、必要なときに彼らが現れるのです。
次に、ストレージノードがあります。これらは本棚です。彼らは図書館全体を保持しているわけではなく、「シャードキー」（著者の名前の最初の文字で本を分類するようなもの）に基づいて、特定のセクションの本のみを保持しています。司書と棚が分離されているため、司書は棚の準備が整うのを待つことなく、独自の業務を行うことができます。彼らは自分の近隣の可用性ゾーン（Availability Zone）にある最も近い棚から読み取るため、読み取りが非常に高速になります。
最後に、アジュディケーター（判定器）とジャーナルがあります。アジュディケーターは、変更が許可されるかどうかを決定するルール管理者です。ジャーナルはマスター日記です。本を変更したいとき（「ライト（書き込み）」）、司書は変更内容を紙に書き留めますが、まだ棚には置きません。彼らはそれをルール管理者に送ります。ルール管理者は、他の誰かが同時にその同じ本を変更しようとしていないかを確認します。問題がなければ、ルール管理者はその変更をジャーナルに書き込みます。このジャーナルは最も重要な部分です。それは、これまでに行われたあらゆる変更の、永続的で順序立てられたリストです。一度ジャーナルに記録されれば、たとえ棚や司書が消滅したとしても、その情報は永遠に安全です。
「待ち時間なし」の読み取りトリック
この論文における最も素晴らしいトリックの一つは、読み取りをどのように処理するかという点です。多くのデータベースでは、本を読みたい場合、司書が誰かが現在その本に書き込みを行っていないかを確認するのを待たなければなりません。これが列や遅延の原因となります。DSQLは、**マルチバージョン並行性制御（MVCC）**と呼ばれる巧妙なタイムトラベルのトリックを使用しています。
本が変更されるたびに、図書館は古いバージョンを消去するのではなく、タイムスタンプ付きの新しいコピーを作成すると想像してください。あなたが本を求めるとき、「その本」を求めるのではなく、「午後2時時点でのその本」を求めます。システムは、その時刻に有効であったバージョンを見つけ出します。システムはマイクロ秒単位で正確な時計を使用しているため、どのバージョンを表示すべきかを正確に把握しています。これにより、誰かが新しいものを書いている間に別の人が本を読むことができ、相手の乱雑で未完成の変更を目にすることはありません。あなたは完璧に凍結された過去のスナップショットを見ることになります。これにより、数百万の人々が互いにブロックされることなく、同時に読み取ることが可能になります。
マルチリージョンのスーパーパワー
この論文は、距離の問題にも取り組んでいます。通常、ニューヨークに図書館があり、ロンドンにもある場合、それらを同期させるには光の速度の関係で時間がかかります。両方の場所で同時に本を更新しようとすると、メッセージが海を渡るのを待たなければならず、それがすべてを遅らせます。
DSQLは、これをアクティブ・アクティブであることで解決しています。これは、ニューヨークに図書館があり、ロンドンにも図書館があり、両方が同時にフル稼働できることを意味します。ニューヨークで変更を行うと、システムはその変更をジャーナルに書き込みます。その後、ジャーナルはロンドンにコピーを送信します。魔法のような点は、メッセージが移動している間も、読み取りや書き込みを制限しないことです。このプロセスは、あなたが「コミット（トランザクションの完了）」を押した瞬間に一度だけ行われます。システムは、メッセージが移動している間に、読み取りや書き込みを停止させません。システムは「クォーラム（定足数）」方式を使用しており、3つのリージョンのうち2つのリージョンで変更が確認されれば、それを安全であると判断します。
論文ではこれを測定し、バージニアとオレゴン間の距離（往復約62ミリ秒）がある場合でも、システムはトランザクションごとに一度だけこの「距離による税金」を支払うだけで済むことを明らかにしました。読み取りについては、ローカルの図書館から読み取るため、さらに高速です。著者らは、この設計により、災害によってリージョン全体（都市全体など）がオフラインになっても、データベースの高速性と一貫性が維持されることを示しています。
ゲームのルール
著者たちは、自分たちが約束することについて非常に慎重でした。彼らは、トランザクションがどのように振る舞うかについての特定のルールセットである**スナップショット分離（Snapshot Isolation）**を選択しました。これは、「読み取りを開始した時点での本を読み取ることができ、読み取りが終わったときに変更することもできるが、もしその間に他の誰かが変更していた場合は、やり直さなければならない」というルールのようなものです。これは、ロックを強制して速度を低下させる、より厳格なルールとは異なります。
論文では、すべてを管理する単一の「リーダー」が必要であるという考えを明確に否定しています。多くのシステムでは、一つのコンピュータがボスであり、それが壊れるとすべてが止まります。しかし、DSQLには単一のボスはいません。すべての部分はスケールアップまたはスケールダウンでき、一部が故障しても、他の部分は動き続けます。また、ハードウェア自体を管理する必要があるという考えも否定しています。システムは「熱（どの部分が忙しくなっているか）」を自動的に処理します。もし図書館の一部のセクションが混雑してきたら、コントロールプレーン（図書館マネージャー）が自動的にそれを2つの小さなセクションに分割し、新しい棚に本を移動させます。これらはすべて、あなたが行うことなく自動的に行われます。
理論のテスト
著者たちは、これがうまくいくと単に推測しただけではありません。彼らは**決定論的シミュレーション（deterministic simulation）**と呼ばれる手法を用いて、システムを徹底的にテストしました。これは、コンピュータープログラム内で、数百万の誤差、ネットワーク遅延、およびクラッシュを瞬時にシミュレートできる環境を実行するものです。彼らは、システムがデータを失ったり混乱したりすることなく、これらのエラーに対処できることを発見しました。
また、実世界のスタイルに近いテスト（忙しい店舗をシミュレートするTPC-Cベンチマークなど）も実施しました。結果は、DSCLがコールドスタート（リソースがほとんどない状態）から、毎分数百万件の操作を処理できるレベルまでスケールアップできることを示しました。完全に空の状態からフルスピードに達するまでには約25分かかりましたが、一度温まれば、驚異的な速さを発揮しました。論文では、これらの結果に非常に自信を持っているものの、外部キー（テーブル同士をリンクするもの）やストアドプロシージャなどの機能をさらに追加するために現在も取り組んでいることが記されています。
結論
Aurora DSQLは、最高の両方を手に入れられるという証明です。つまり、シンプルなサービスのように扱いやすく（管理する必要がなく）、かつ大規模なグローバルシステムのように強力なデータベースです。思考、ストレージ、そしてルールを分離し、時間を追跡するための永続的なジャーナルを使用することで、アプリケーションは問題なくゼロから数百万のトランザクションへと成長することができます。これは、物事が速く変化し、災害が発生し、そして今読んでいる情報が絶対的な真実であることを必要とする世界のために設計されたシステムなのです。
自分の分野の論文に埋もれていませんか？
研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。