re:Invent 2024: Amazon Aurora PostgreSQL Limitless Database解説
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Serverless scaling with Amazon Aurora PostgreSQL Limitless Database (DAT338)
この動画では、Amazon AuroraのシニアプロダクトマネージャーであるAnum Jang Sherが、Aurora PostgreSQL Limitless Databaseについて解説しています。従来のShardingが抱える運用の複雑さやコストの問題を解決し、単一のデータベースクラスターのように扱える水平スケーリングソリューションの仕組みを詳しく説明しています。特に、3つのAvailability Zoneにまたがるシステム基盤や、Router、Data Access Shardなどのアーキテクチャ、Reference Tableの活用方法について具体的に解説しています。実際のパフォーマンステストでは、1,000億行のテーブルで1秒あたり255万のコミットを2.4ミリ秒の平均レイテンシーで処理できることが示されており、高いスケーラビリティと性能を実現しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Aurora PostgreSQL Limitless Database: 単一データベースの限界を超えるスケーラビリティ
もう一度やってみましょう。先ほどAIについて話しましたが、みなさんが興奮しすぎているので、今度はデータベースについて話す必要があります。今日のデータ集約型アプリケーションの世界では、単一のデータベースインスタンスが提供できる限界を超えて、どのようにデータベースをスケーリングすればよいのでしょうか？私はAnum Jang Sherと申します。Amazon Auroraのシニアプロダクトマネージャーを務めています。このライトニングセッションでは、最近私たちが行った最も刺激的なローンチの1つについてお話しします。単一のデータベースの運用の簡単さを保ちながら、単一のデータベースが提供できる以上のことを実現する方法をご紹介します。
通常、データベースを使用する際は、データベースをプロビジョニングし、アプリケーションを接続するだけで準備完了です。しかし、ビジネスが順調に成長していくと（これは素晴らしいことですが）、問題が発生し始めます。単一のデータベースが提供できる限界に達し始めるのです。そこで、スケールを確保するために、データベースを小さなコンポーネントに分割することになります。これでスケールの問題は解決しますが、今度は管理の問題が発生します。マネージドデータベースを使用していても、多数のデータベースを管理しなければならないからです。
これは一般的にShardingと呼ばれ、皆さんもよくご存知の手法だと思います。Shardingにはさまざまな問題があり、その一部についてお話しします。まず、クエリの問題があります。データベースを分割してデータを分散させると、アプリケーション層がどのデータベースにクエリを送るべきか知る必要があります。もう1つは一貫性の問題です。データベースは単一のコンポーネントではなく、複数のコンポーネントになっているため、一貫性を保つ必要があります。カラムの追加や削除、深夜のバックアップなどの変更を行う際、すべてのバックアップが完全に同じになるわけではありません。Shardingを始めた当初は1回データを分散させれば済むと思われがちですが、実はそれで終わりではありません。あるノードがホットになった場合、再度データを再分散させる必要があります。つまり、Shardingは継続的な取り組みとなり、その間ずっとアプリケーションを稼働させ続けなければなりません。
もう1つの問題は、キャパシティ管理です。システムのどこで負荷が高くなっているかを把握し、それに基づいてより大きなインスタンスやより小さなインスタンスにフェイルオーバーする必要があります。結局のところ、すべてをオーバープロビジョニングすることになります。そのため、運用の複雑さだけでなく、システム全体をオーバープロビジョニングしているために多額のコストがかかるという2つの問題を抱えることになります。
この問題を解決するために、AuroraはAurora PostgreSQL Limitless Databaseをローンチしました。これは、マネージド型の水平スケールアウトソリューションに対するAuroraの回答です。どのような機能を提供するのでしょうか？Shardソリューションのパワーと機能を備えながら、単一のデータベースクラスターを管理する簡単さを提供します。毎秒数百万件の書き込みトランザクションまでスケールでき、ペタバイト規模のデータを管理することができます。しかし、結局のところ、扱うのは単一のエンドポイントだけです。ユーザーの視点からは、この分散システムは単一のクラスターとして見えます。内部的には、これはサービスデプロイメントであり、ハードウェアやインフラストラクチャについて心配する必要はありません。キャパシティの範囲を指定すれば、データベースは自動的にスケールアップとダウンを行います。垂直スケーリングであれ水平スケーリングであれ、ワークロードが必要とするものに応じて、システムが自動的に対応します。そして、ユーザーの視点からは依然として単一のデータベースクラスターです。もちろん、使用した分だけが課金対象となるため、オーバープロビジョニングの問題についても心配する必要がなくなります。
AWS Consoleで始めるLimitless Database: 簡単な設定と強力な機能
それでは、どのように始めればよいのか、そして今日何ができるのかをご紹介します。このサービスは一般提供が開始されています。ここに表示されている画面はAWS Consoleです。皆さんもよくご存じかと思います。これはデータベースを作成する一般的な方法で、ConsoleでAPIなどを確認したい場合は、これから説明する内容はすべてAPIでも同様に実行できます。このサービスはPostgreSQLの互換性を備えてリリースされました。作成フローに入ると、このオプションがデフォルトで選択されているので、より簡単に操作できるよう特に何もする必要はありません。
必要な条件を指定できるフィルターがあり、高スケーラブルなLimitlessデータベースが必要な場合は、そのバージョンを選択してさらに下にスクロールします。ここが重要なポイントとなります。
通常、Auroraでは、R6gやR7iなど、EC2インスタンスに対応する特定のインスタンスタイプを選択してコンピュート要件を指定していました。その後Serverlessが登場し、特定のハードウェアを選択する代わりに、キャパシティ範囲を指定して使用した分だけ支払う方式になりました。今回は、そのコンセプトをさらに発展させています。Serverlessの垂直スケーリングに加えて、水平スケーリングも提供し、Serverlessのキャパシティ範囲という同じコンセプトを適用しています。
最小キャパシティについては、必要な開始キャパシティ、つまり常に確保しておきたいキャパシティを考えてください。最大値は基本的に予算の上限メカニズムで、これ以上支払いたくない金額を設定するポイントです。これは予期せぬ高額請求を防ぐためのシステムの安全装置として機能します。キャパシティの測定単位としては、Serverlessと同じACU（Aurora Capacity Unit）を使用しています。この範囲内で、システムが垂直方向にスケールアップまたは水平方向にスケールアウトする必要がある場合、データベースが自動的に処理します。
誰もが気にする可用性については、Auroraと同じ99.99%の可用性を提供しています。これを実現するには、単一のフェイルオーバーターゲットか2つのフェイルオーバースタンバイターゲットのいずれかを、クリック一つで選択するだけです。この分散システムを指定するのは、このように簡単なクリック操作だけです。ストレージについては、このシステムはAuroraと同じストレージレイヤーを共有しています。ストレージレイヤーを選択するだけで、予測可能な価格とパフォーマンスを提供するIO-Optimizedのみをサポートしており、これは皆さんがすでによくご存じのものです。
Limitless Databaseの内部構造と性能: 分散アーキテクチャと驚異的なスケーラビリティ
では、このプロジェクトのエンジニアリングリーダーであるDaveが、それらの数回のクリックの裏で何が起こっているのかを説明します。 クラスターの作成を開始すると、3つのAvailability Zoneにまたがってシステムの基盤を構築していきます。通常のAuroraでは、クラスターを作成してからインスタンスを作成しますが、ご覧のように、インスタンスを作成する代わりにShard Groupという概念を作成しています。このShard Groupを3つのAvailability Zoneに分散させており、その理由については後ほど説明します。
重要なポイントは、既存のAuroraの分散ストレージシステムを使用していることです。これにより、3つのAvailability Zoneにまたがる書き込みの耐久性、ボリュームの弾力的な拡大・縮小、データベースノードのネットワークサイズによってのみ制限される実質無制限のIOPS、そして何十万ものデータベースと何万もの顧客にわたって実証された10年間のイノベーションと耐久性を実現しています。
このShard Group内に、私たちが分散トランザクションルーター（略してRouterと呼んでいます）を作成します。 クライアントからのすべてのデータベース接続はここに集まります。これらのRouterは単なるプロキシではありません。クエリの解析、プランニング、実行を処理し、その名の通り、一貫性のあるシングルシステムビューを維持するトランザクションシステムを調整する高度なデータベースノードです。Routerは3つのAvailability Zoneに分散されているため、1つのAvailability Zoneがダウンしても問題ありません。
Routerは他のAvailability Zoneにすでに存在しているため、Serverlessテクノロジーを使用してその場で垂直方向にスケールアップするか、稼働中のAvailability Zoneに必要に応じて新しいRouterを作成することができます。これらのRouterには実際のデータは保持されていないため、データがどこに存在するかを考える必要があります。
データはData Access Shardに存在し、これらはAvailability Zone全体に分散されています。この例では、Serverlessテクノロジーを使用しているため、サイズの異なる3つのShardがあります。ワークロードパターンが完全に均一になることは稀で、通常はホットな領域とクールな領域が存在するため、特定のShardに負荷がかかると、システムは自動的にそれに適応し、必要に応じてノードをその場でスケールアップ・ダウンします。
また、Failoverノードも備えており、これを私たちはCompute Redundancyと呼んでいます。特にCompute Redundancyと呼ぶ理由は、ストレージはすでに3つのAvailability Zone間で耐久性が確保されているため、ストレージに関して追加の冗長性は必要ないからです。Compute Redundancy 1の設定では、各シャードが別のAvailability Zoneに1つのFailoverを持ちます。この場合、Availability Zone 1がダウンした場合、シャード1はAvailability Zone 2にFailoverします。また、Compute Redundancy 2では2つのFailoverオプションを持つことができます。
これらのData Access Shardは、データベースの一部のデータを管理し所有します。Routerからクエリを受け取り、ローカルトランザクションを管理し、実行結果をRouterを通じて返します。私たちのトランザクションシステムの興味深い点は、Routerから全てのシャードにトランザクション時間を渡すことです。これにより、単一シャードのトランザクション、マルチシャードのトランザクション、単一ステートメント、暗黙的トランザクション、複数ステートメントの明示的トランザクション、ストアドプロシージャ、関数のいずれであっても、全てのデータの一貫したスナップショット分離ビューを得ることができます。従来の単一ノードのPostgreSQLシステムと同じRepeatable ReadスナップショットアイソレーションやRead Committedアイソレーションが得られます。
私たちは異なるテーブルタイプを提供していますが、最も興味深いのはシャードテーブルです。顧客テーブルを例にとると、Create Table文のPostgreSQL構文を変更したくなかったため、Create Table文を実行する前に設定するセッション設定を用意しました。単にCreate Tableモードをシャード化に設定し、シャードキーをCustomer IDにすると指定するだけです。シャードキーは複数のカラムを持つ複合キーにすることもできます。この例は単純な顧客テーブルです。その後、Create Table Customersを実行すると、設定したオプションを取得し、Customersテーブルの各部分をシステム全体に分散します。
このシステムとアーキテクチャの重要な部分は、分散マルチシャードクエリや分散マルチシャードJoinを実行する一方で、システムを実行する本当の理由はパフォーマンスとスケーラビリティにあるということです。どのようなシステムでも最高のパフォーマンスを得るには、作業するデータを処理を行うComputeと同じ場所に配置する必要があります。一般的なスキーマでは、CustomersテーブルとOrdersテーブルを、Customer IDを介した主キー外部キー関係で頻繁にJoinすることがあります。最高のパフォーマンスを得るために、これらのテーブルを一緒にコロケーションする選択肢を提供しています。これは、特定のCustomer IDに対して、そのCustomer IDに関連する全てのOrdersが、顧客レコードと同じシャードに存在することを意味します。そのため、これらのテーブル間でJoinを行う場合、RouterはSQLをデータのある場所にプッシュし、ローカルで処理して最高のパフォーマンスを得ることができます。
ここでTax Ratesという別のテーブルがあります。注文を処理する際、注文が発生した管轄区域の税率を確認する必要があるかもしれません。これは頻繁に変更されないデータです。
毎晩更新するかもしれませんが、新しい税率を書き込むことは、特殊なビジネスでない限り、トランザクションの主要な処理経路ではありません。ほとんどの場合、新しい税率の書き込みは1秒間に何千回も行うようなものではありません。税率をReference Tableとして作成すると、そのデータは各Shardに存在することになります。すべての税率の行が実質的にすべてのShardで複製されます。これらはトランザクションの一貫性を保ち、更新や書き込みもShard間で完全なトランザクションの一貫性を持ちます。しかし、総ストレージ容量と総スループットのスケーリングを目指すなら、頻繁にアクセスされるテーブルをReference Tableとすることは適切ではありません。これをここに配置するのはJoinのためです。そうすることで、Customer、Order、税率間のJoinを実行する際、そのCustomer IDレコードが存在する場所まで完全なJoinをプッシュダウンできます。
Reference Tableについてもう少し詳しくお話ししましょう。先ほど申し上げたように、これらは強い一貫性を持っています。一度書き込んで最終的にどこかに複製されるというものではなく、強い一貫性を持つ書き込みであり、Join Pushdownを可能にします。 では次に、パフォーマンスについて、このシステムが実際にどのように動作しスケールするかについてお話ししましょう。この例は、US East OneリージョンでProduction Systemを顧客として実行した際のラボテストからのものです。大規模なスケールを実現するために一部のクォータをオーバーライドしましたので、このスケールが必要な場合は制限緩和のためにご連絡ください。
なぜこれがそれほど重要なシステムなのか説明させていただきます。これは1,000億行のテーブルでランダムなキーに対する更新を行うという、十分に検証された更新の例です。更新とコミットを含む書き込みトランザクションです。私たちは非常に高いスループットを達成し、クライアントを動かすために3台の24 Excelマシンが必要でした。これは数千のデータベースクライアントを表しており、各ドライバーマシンが1秒あたり80万以上のコミットを実行する、トランザクショナルなPostgreSQLデータベースです。システム全体で、1秒あたり255万のコミット - 1分ではなく1秒です - を実行していました。これは膨大なコミット量であり、平均レイテンシーは2.4ミリ秒でした。これはクライアントからRouter、Shardへの更新、3つのAvailability Zone間で永続化されるコミット、そしてクライアントへの結果の返却までを測定した値です。
では、この15分間で何を学んだでしょうか？ Aurora PostgreSQL Limitless Databaseについて学びました。PostgreSQL互換の水平方向にスケールアウトするソリューションをお探しの場合、これこそがお求めのものです。Shardingのパワーと単一クラスターのシンプルさを両立させる方法をご覧いただき、これらすべてを支える基盤となるスケーラブルなアーキテクチャについて説明しました。Daveが先ほど述べたように、これは1秒間に数百万の書き込みトランザクションまでスケールします。このソリューションは現在Generally Availableです。詳細についてはドキュメントをご覧ください。これらが関連セッションですので、ご興味があればぜひご参加ください。本日は木曜日なので、一部のセッションはすでに終了していますが、YouTubeで動画をご覧いただけます。アンケートへのご回答をお願いいたします。 ありがとうございました。Anna、David、ありがとうございました。アンケートへのご回答を忘れずにお願いいたします。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion