![[re:Invent 2023 レポート]Amazon Aurora Limitless Databaseの基本説明](/media/YjDGabwLtH2yro1l1S8fThA9faHdLBm7NtMsj6lv.png)
目次
BeeXの榊原です。今回は下のre:Inventのセッションを基に、Amazon Aurora Limitless Databaseについてまとめました。このサービスのすごいところはデータベース（以下DB）のシャーディング機能がマネージドサービスとして提供されたところです。DBになじみのない方はおそらくピンと来ていないと思います。これを聞いた当初の私もそうでした。そこで今回は技術的に深い部分は省いて、Amazon Aurora Limitless Databaseの基本部分の解説を行います。
基本説明
DBの拡張
どんなアプリやシステムもユーザが増えればリソースの拡張が必要です。DBを拡張する際は何を行えば良いでしょう。主に3つの手法があります。
１．Work Harder：DBの性能自体を上げるスケールアップを指します
２．Work Smarter：SQL文の修正や、アプリケーションの仕様等を変え処理速度を上げます。
３．Get Help：DBの台数を上げて、負荷を分散します。
DBの情報をただ読みとるだけ（Read）であればRDSの場合リードレプリカを用いることで簡単にDBの拡張が可能です。しかし一方、DBに対してデータの書き込み（Write）をする場合はどうでしょう。Readと異なり、DBの内容そのものが書き換わるので、複数のユーザが同時にDBに書き込むことで不整合が生じたり、何かの障害で書き込んだ情報そのものが反映されないと大変です。これに対して使われてきた技術がシャーディングです。
シャーディングとは
例えば一つのDBにやり取りするアプリケーションの全情報を詰め込むと、時間とともに格納されるデータサイズが大きくなったり、Write処理も重くなります。スケーリングする際もDBは一つしかないので、DBの性能をひたすら上げることでしかDB拡張ができません。ひたすら一つのDBの性能を上げるのには当然限度があります。
そこでアプリケーションが使う情報を複数のDBに分散させると、データアクセス・書き込みの時間が短縮されるに留まらず、DB拡張時にDBの数を増やす水平展開が可能となり、冗長性も上がります。一つだけのDBの性能をひたすら上げるよりスケーリングしやすいです。これがシャーディングです。
シャーディングの懸念点
さて、シャーディングはアプリケーションが複数のDBと通信を行うことになるので、もちろんメリットだけでなく懸念点もあります。
1. 適切なクエリ処理が必要：複数のDBに跨るクエリやトランザクションや、アプリケーション側で結合を実装している場合はどのタイミングでどのDBに接続すべきか掴む必要があります。それに伴い、必要なデータがあるDBがどれなのかも把握せねばなりません。
２．DBサーバ同士でデータの一貫性が保証されない：DBサーバ同士で異なるデータを保持するのはまずいので、そうならないための仕組みも実装せねばなりません。
３．メンテナンスが複雑になりやすい：データの一貫性が保証されない状態でアップグレードやパッチ実行、あるいはバックアップ作成をする必要があります。よってDB管理は複雑化しやすいです。
以上からシャーディングはRDBのWriteパフォーマンスを上げられる一方、解決せねばならない問題が数多くあることがわかります。自分はまだシャーディングを実装したことは無いのですが、社内の経験者曰く自前でシャーディングを実装するのは本当に大変みたいです。
以上の問題に対し、AWSはre:InventでAmazon Aurora Limitless Databaseを発表しました。
Aurora Limitless Databaseとは
DBのシャーディングを、実装の手間なく実現できるのがAurora Limitless Databaseです。マネージドサービスとして、単一のAuroraクラスター内で以下の機能が提供されています。
・サーバレス
・分散型アーキテクチャを利用して拡張
・提供されているインターフェイスは一つだけなので、単一のDBのように使用可能
・システム全体にわたってトランザクションの一貫性を提供
・1秒単位で数100万のトランザクションに拡大可能
・ペタバイト単位のデータを全て単一のAuroraクラスタ内で処理可能
Aurora Limitless Databaseの構造
従来のAuroraクラスタの構造
Auroraクラスタを作成すると、書き込み処理をするライターインスタンス（マスターインスタンス）が作られます。オプションで複数のリーダーインスタンスを作成でき、元のライターインスタンスが使用不可になった際は代わりにライターインスタンスとなることができます。
Aurora Limitless Databaseの構造
従来のAuroraクラスタに加え、Limitless Databaseでは新たにサーバーレスのシャードグループ（shard group）の概念が加わります。アプリケーショントラフィックを読み取って処理する部分です。下画像の➃ Limitless Database shared groupが該当箇所です。シャードグループはAuroraクラスタ内に含まれるので、バックアップやアップグレード等クラスタレベルの操作は自動で適用されます。よって個別に管理する必要はありません。
よく見ると、上画像でライターインスタンスとリーダーインスタンスとやり取りしていたユーザが、全てごっそりシャードグループとやり取りするようになっています。
シャードグループの構造
シャードグループはトランザクションルータ（下図オレンジ部分）と複数のシャード（下図黄緑部分）から成り立ちます。今までAuroraクラスターにはライターエンドポイントとリーダーエンドポイントがありますが、シャードグループにもアプリケーショントラフィックを処理するためのエンドポイントが新たに加わります。また、シャードグループは無限大にスケーリングされるわけではなく、あくまで自身で設定した制限の範囲内で水平・垂直に拡張します。
トランザクションルータ
特徴を箇条書きしてみました。
・全アプリケーションのトラフィックを受けとる。
・負荷に基づいて水平あるいは垂直スケーリングを行う
・データ保管場所に関するメタデータを保管。
・トランザクションに時間を割り当てる（分散DBの一貫性を担保してくれる）
・受信したSQLコマンドを解析し、そのコマンドを各シャードに送信。結果をまとめてクライアントに返す
シャード
冒頭に説明した通り、シャーディングは複数のDBに書き込みを行う技術で、それを行う部分です。今回だと複数インスタンスに対して並列に書き込み処理を行えます。ちなみにシャード間の時刻の同期にはEC2で使われているAmazon Time Sync Serviceを用いています。詳細なテクニカルな部分は本記事では割愛します。
最後に
以上、Amazon Aurora Limitless Databaseの基礎的な部分を解説しました。今回現地で知り合った方に、どのサービスが気になっているか聞いた際、このサービスを熱く語られている方がいらっしゃったので興味が沸いて急遽記事にしてみました。このような切口から、知らない技術を調べて書くのも非常に勉強になり改めてre:Inventに現地参加するメリットを認識できました。ここまでお読みいただきありがとうございました。技術的に深い部分を知りたい方、一次情報が正義の方は参考資料もぜひご覧ください。
参考資料
この記事をシェアする
