re:Invent 2024: Aurora Serverless v2のスケーリングと運用最適化
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Build scalable and cost-optimized apps with Amazon Aurora Serverless (DAT316)
この動画では、Aurora Serverless v2の主要な機能と利点について詳しく解説しています。データベースが経験しているワークロードに基づいて自動的にスケールアップとスケールダウンを行う機能や、0.5 ACUという細かい単位でのスケーリング、ダウンタイムなしでのスケーリングなど、具体的な特徴を説明しています。また、Global Database、RDS Proxy、Multi-AZデプロイメントなどのAuroraの重要機能との統合や、最大256 ACUまでのスケーリング、0 ACUまでのスケールダウン機能など、最新の機能強化についても触れています。さらに、ACU単位での従量課金制や、Aurora Provisioned版からの移行手順、blue/greenデプロイメントを活用したアップグレード方法など、実践的な運用面での知見も共有しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Aurora Serverlessの概要と本セッションの目的
みなさん、こんにちは。アプリケーションスタックにおいて、データベースは最も重要なコンポーネントの1つです。データベースに十分なリソースを確保したいと考え、見積もりを行い、その見積もりについて心配し、結局のところ、心配できることには限界があるため、オーバープロビジョニングしてしまいます。私はAuroraのSenior Product ManagerのAnum Jang Sherです。このセッションでは、まさにこれらの問題について話し合います。Aurora Serverlessがどのようにスケーラブルでコスト最適化されたアプリケーションの構築を支援できるかについて説明します。
これから45分から1時間のアジェンダをご紹介します。まず、Serverlessについて、なぜ注目すべきなのかという概要と動機付けについて簡単に説明します。次に、Auto-scaling機能について説明し、それがどのように問題解決に役立つかを見ていきます。重要なアプリケーションを考える際、Auto-scaling機能だけでなく、Multi-AZなどの重要なAurora機能も必要です。そこで、これらの機能とServerlessによってどのように強化されるかについても説明します。その後、課金について触れ、最後に今日からどのように始められるかについてお話しします。
Auroraの特徴とServerlessの必要性
文脈を整理すると、Aurora ServerlessはAuroraの機能の1つです。Auroraとは何でしょうか？それは、クラウド向けに構築されたMySQL及びPostgreSQL互換のリレーショナルデータベースです。Auroraを使用することで、商用データベースのパフォーマンスと可用性を、わずかなコストで手に入れることができます。 今年は私たちにとって特別な年です。10周年を迎えるからです。皆様の問題解決を支援する機能を開発してきたこの旅に、皆様と共に歩んでこられたことに感謝申し上げます。
アプリケーションを構築する際、必要なデータベースリソースの量を把握する必要があります。これは、リソースを見積もってプロビジョニングする方法の非常に高レベルな概要です。ビジネスが好調になり、より多くのリソースが必要になった場合、より大きなサイズのデータベースにフェイルオーバーします。アプリケーションがライフサイクルの終わりに近づいている場合は、逆に小さなサイズのデータベースをプロビジョニングします。では、何百何千ものアプリケーションを実行していて、それぞれが1つまたは複数のデータベースによってバックアップされている場合はどうでしょうか？突然、1つのデータベースの心配から、何百何千ものデータベースの心配へと変わってしまいます。
マルチテナントアプリケーションを運用している場合、一部の顧客に対して完全な分離が必要なシナリオや、コスト削減のメリットのために顧客をバックアップしているケースがあるかもしれません。そうすると再び、単一のデータベースから何百何千ものデータベースのキャパシティ管理を心配することになります。 これらのデータベースそれぞれで、ワークロードは異なる可能性があります。ISVの場合、ワークロードが予測できないかもしれません。より多くのリソースが必要になったり、最適化を試みたりするたびに、ダウンタイムを伴うフェイルオーバーを実行しなければなりません。
このように、キャパシティ管理は非常に難しい問題です。理想的な世界では、利用可能な最大のデータベースを選んで、あとは心配しなくて済むようにできれば良いのですが、現実にはそれは現実的な解決策ではありません。そのため、いくつかのトレードオフを考える必要があります。ワークロードに密接に追従したい場合、必要なのは専門知識です。データベースについての知識、実際のドメインについての知識が必要で、さらに複雑なモニタリングシステムを用意して追跡し続けなければなりません。そして結局のところ、マシンを切り替える際のダウンタイムは避けられません。
データベースのリソースが必要な量を下回ると - この図では平均的なワークロードを示していますが - アプリケーションのパフォーマンスが低下してしまいます。 一方で、そのような状況は受け入れられないと判断してピーク時に合わせてプロビジョニングを行うと、それもまた非常にコストがかかる解決策となってしまうため、受け入れがたいものとなります。これらの問題をそれぞれ見ていくと、どれも理想的な解決策とは言えません。
ここで Aurora Serverless の出番となります。これは Aurora の中で最も急速に採用が進んでいる機能の1つで、Aurora のオンデマンドかつ自動スケーリング設定を提供します。この機能により、データベースは経験しているワークロードに基づいて自動的にスケールアップとスケールダウンを行うことができます。結果として、従量課金モデルとなり、実際のワークロード消費分のみの支払いで済みます。このように、様々なワークロードに対して、心配のないキャパシティ管理を実現できます。 これらの本質は自動スケーリング機能にあります。では、その仕組みについて説明しましょう。
Aurora Serverless v2の仕組みと自動スケーリング機能
通常の Aurora では、T2インスタンスのように、使用の有無に関わらず固定のメモリとCPUキャパシティを持つインスタンスをプロビジョニングすることを考えます。Serverless では、そのメンタルモデルが少し変わります。固定キャパシティの代わりに、最小値と最大値を持つ範囲を指定し、データベースはその特定の範囲内でスケールします。Serverless は、スケールアップとスケールダウンが可能な特別なインスタンスがクラスター内にあるようなものだと考えてください。この自動スケーリング機能以外は、すべて同じように動作します。
内部的には、通常のプロビジョニング型 Aurora と同じエンジンコードを使用し、同じセキュリティポスチャを維持しています。Serverless の追加的な利点は、これらのインスタンスの上に構築された自動スケーリング機能です。MySQL のサポートについては、MySQL 8以降のバージョンがサポートされており、PostgreSQL については、PostgreSQL 13以降がサポートされています。コードの大部分が同じになるように設計されているため、通常のプロビジョニング型と Serverless の間の切り替えは簡単で、どちらかに固定されることはありません。
キャパシティの測定には、Aurora Capacity Units（ACU）という高レベルな抽象化された単位を使用しています。1 ACUは2ギガバイトのメモリに相当し、Provisionedインスタンスと同様のCPUやネットワークリソースが提供されます。データベースのプロビジョニング時には、ACUの最小値と最大値を設定し、データベースはその範囲内でスケーリングを行います。最小値は、初期のワーキングセット要件に基づいて常に保証される容量という意味で、スタート地点として考えてください。最大値は支出の上限として機能し、予算管理のメカニズムとして働きます。実際に使用した分のみが課金対象となります。
最近リリースした興味深い機能の1つが、自動一時停止と再開です。この機能により、接続数がゼロになった時にデータベースを0 ACUまでスケールダウンすることができます。クエリの実行やメンテナンスなど、何らかのアクティビティが必要になった時には、データベースは自動的に再開します。一時停止中は実質的にデータベースが動作していない状態なので、再開にはコールドスタートが必要となり、通常15秒程度かかります（ただし、他の要因によってこの時間は長くなる可能性があります）。最も重要なポイントは、0 ACUの状態ではコンピューティングに対する課金が発生せず、ストレージの料金のみが従来通り発生するということです。
もう1つの最近の発表は、Serverlessが提供できる上限値の引き上げです。以前は128 ACUまでに制限されていましたが、現在のAurora Serverlessは256 ACUまで拡張可能になりました。1対2の比率で考えると、512ギガバイトのメモリが利用できることになります。この機能は既存および新規のデプロイメントで利用可能で、他のAuroraの機能と同様に、通常はより新しいマイナーバージョンでこれらの新機能をリリースしています。 これら2つの最近の発表により、Aurora Serverlessは現在、0 ACUから256 ACUまでスケーリングできるようになりました。
自動スケーリングの仕組みと、データベースがスケーリングを行うタイミングを判断する要因について説明します。 主要な要因は3つあります：CPUの使用率、メモリの使用率、そしてネットワークスループットです。これらは、ユーザーのクエリやワークロードだけでなく、データベースの健全性を維持するためのバックグラウンドプロセスにも適用されます。データベースはこれらすべての要因に対応してスケーリングを行います。 スケールアップについては、これらの要因のいずれか1つでもより多くのリソースが必要だと示された場合、データベースはスケールアップします。 スケールダウンについては、3つの要因すべてが追加リソースが不要であることを示す必要があります。スケールダウンに関しては非常に慎重なアプローチを取っています。なぜなら、リソースがまだ必要な状況でデータベースがスケールダウンを決定してしまうような事態は避けたいからです。
では、データベースは実際にどのようにスケーリングを行うのでしょうか？私たちはIn-placeスケーリングというプロセスを使用しています。 従来のスケーリングでは、あるデータベースインスタンスから別のインスタンスに移行するフェイルオーバーメカニズムを使用していました。Aurora Serverlessではそのような処理は一切発生しません。代わりに、実行中のデータベースプロセスに対して、ワークロードがより多くのCPUやメモリリソースを必要とする場合に、追加のリソースを割り当てます。 あるインスタンスから別のインスタンスへの移行を行わないため、スケーリングは非破壊的なプロセスとなります。何十万ものトランザクションを実行中でも、データベースは中断することなくスケーリングを行うことができます。スケーリングのために静かなポイントを待つ必要はありません。
Aurora Serverlessは細かい粒度でのスケーリングを提供します。通常、マシンの場合、必要な容量がわずかでも、キャパシティを2倍にするか、オーバープロビジョニングするかのどちらかしかありません。Serverlessでは、より細かな制御が可能です。必要に応じて0.5 ACUという小さな単位でスケールできますが、ワークロードがより多くを必要とする場合は、より大きなジャンプで素早くスケールすることもできます。例えば、データベースが16 ACUで少しの増加が必要な場合は16.5に、より大きな増加が必要な場合は16から20、あるいは必要な増加量に応じてスケールできます。
スケーリングは瞬時に行われ、データベースが利用可能なリソースはすぐに消費されます。データベースが内部構造への負荷を検知すると、すぐにスケーリングを開始します。ただし、ゼロACU機能と組み合わせた場合、データベースを再開する必要があるためコールドスタートが発生します。再開して利用可能になると、スケールアップを開始します。
スケーリングアルゴリズムとモニタリング機能
このスケーリングアルゴリズムの仕組みを詳しく見てみましょう。データベースにはACUのバケットがあり、 バケットサイズと補充レートという2つのパラメータで特徴付けられています。 これらのパラメータは可変です。 最初のグラフはバケットサイズの変化を示しています - データベースの容量が大きくなるにつれて、バケットサイズも増加します。 同様に、補充レートについても、データベースの容量が大きくなるにつれて、より速い速度で補充されます。 つまり、インスタンスが大きいほど、スケーリングが速くなるということです。データベースのスケーリングが十分な速さでない場合は、開始点となる最小データベース容量を制御できます。最小容量を増やすことで、より速いスケーリング速度が得られます。とはいえ、アプリケーションをテストして、どの最小ACUが適切か、どのスケーリング速度が十分かを判断することが重要です。
スケーリングアルゴリズムについて説明したところで、次はスケーリング中のBuffer Poolで何が起こるかについて説明しましょう。 Buffer Poolはデータベースの主要なキャッシュであり、データベース容量のスケーリング操作中にこれもスケールします。変更されるパラメータは、MySQLではinnodb_buffer_pool_size、PostgreSQLではshared_buffersです。Buffer Poolをスケールダウンする際は、最も使用頻度の低いものと最近使用されていないものを組み合わせたアルゴリズムを使用します。
これらの仕組みを理解するために、簡単なアニメーションをお見せします。Buffer Poolからページが読み取られると、それらのページはより「硬く」なり、Buffer Poolから追い出される可能性が最も低くなります。 ストレージからより多くのページが読み取られるシナリオでは、将来のアクセスパターンが現時点では不明なため、これらのページを追い出したくありません。これらが「温かい」ページとなります。グレーで表示されているページが、最も追い出される可能性が高いページです。これらの「冷たい」ページを追い出してメモリを解放し、最終的にデータベースがスケールダウンする際にBuffer Poolを縮小します。
Buffer Poolのスケーリングの仕組みについて簡単にご説明します。 データベースを見ていると、設定した最小値まで下がらないのはなぜだろうと疑問に思うかもしれません。これにはいくつかの要因が考えられます。先ほど説明したように、実行中のクエリのワークロードだけでなく、Auto Vacuumパージなどのバックグラウンドプロセスも影響します。データベースがバックグラウンドで何かを実行している場合、そのプロセスを実行するためのリソースが必要となるため、設定した最小容量まで下がらないことがあります。
例えば、最小値を0.5 ACU（1ギガバイト）という非常に小さな値に設定し、データベースで多くの機能を実行している場合を考えてみましょう。Aurora Global DatabaseやPerformance Insightsなどの機能を使用している場合、それらが追加のリソースを消費しているかもしれません。これは確認が必要なポイントです。また、大容量のストレージボリュームが接続されている場合、最小値が0.5 ACUでも、ボリュームが非常に大きければ、そのコンピュートがサポートできるかどうかを考慮する必要があります。その他にも、高可用性の優先度を0または1に設定するなど、データベースのスケールダウンを妨げる設定があります。これは、Writerの動作に常に従うことを意味し、Writerがスケールダウンしない限り、Readerの負荷に関係なくスケールダウンしません。
次に、インスタンスがスケーリング操作を実行するための十分な容量があるかどうかについて説明しましょう。考慮すべき点が2つあります。1つ目はリージョンで利用可能な容量です。Amazon RDSとAuroraの運用経験に基づいて、各リージョンの容量計画を行っています。2つ目はホスト上の容量です。スケールアップ時にホスト自体の容量が不足した場合、そのホスト上のアイドル状態のインスタンスを見つけて別のホストに移動し、インスタンスのスケールアップのためのスペースを確保します。ホスト間でインスタンスを移動する際は、バックグラウンドプロセス、Buffer Pool、接続を維持するため、ユーザーが違いを感じることはありません。
大規模な環境での熱管理の方法について、少しご紹介したいと思います。 これは、あるリージョンでの熱管理の例です。このプロットでは、青い点が各インスタンスを表し、散在する紫の点は非常に大きなインスタンスを示しています。また、各垂直線はホストを表しています。このアニメーションを再生すると、 ホスト上のインスタンス数が多くなり、より多くのリソースが必要になった場合、インスタンスを特定して移動させます。ホストにより多くの余裕を作るため、アイドル状態のインスタンスを移動させます。これは、フリート内での熱管理の一例です。
ここまでは、スケーリングとその仕組みについて説明してきました。次は、モニタリングについて話しましょう。
スケーリング操作中、データベースが自動的にすべてを処理していたため、ユーザーからの入力は必要ありませんでした。何が起きているのかを確認するために、私たちは複数の異なるモニタリング製品をサポートしています。データベースの特定の特性を監視するために、Amazon CloudWatch、Amazon RDS Enhanced Monitoring、そしてPerformance Insightsがあります。Aurora Serverlessはこれらすべてをサポートしており、さらにServerless専用の機能も追加しています。 CloudWatchでは、ServerlessDatabaseCapacityというメトリクスを提供しています。最小容量と最大容量を設定する際、このメトリクスによってデータベースの現在の状態を知ることができ、実際の使用量に基づいて課金されます。最小値や最大値ではなく、ワークロードが実際に使用している分だけが課金対象となります。
もう一つの例として、CPUUtilizationメトリクスがあります。これは利用可能な最大ACUに基づいたCPU使用率のパーセンテージを示します。このメトリクスを見ることで、ワークロードに十分なリソースがあるかどうかを判断できます。2つの選択肢があります：ワークロードをさらに最適化してリソース消費を減らすか、最大ACUを増やしてシステムにより多くのリソースを提供するかです。 FreeableMemoryについても同様で、リソースが不足している場合は対策を講じることができます。
Performance Insightsは、パフォーマンスのデバッグのためのシンプルかつパワフルなツールとして提供しているもう一つの機能です。Serverlessの場合、監視したいのは点線の黒い線で、これは推定vCPUを示します。これによって、データベースにより多くのリソースを提供するために最大ACUを増やす必要があるかどうかを判断できます。 スケーリングについて説明してきた内容をまとめると：Auroraが提供する自動的で、その場で行われる、無停止のスケーリング、スケーリングに影響を与える要因、スケーリングの速度、ヒートの管理方法について説明し、モニタリングについても簡単に触れました。
Aurora Serverless v2が強化する高可用性と分析機能
では次に、Auroraがサポートする他の機能や特徴、そしてAurora Serverlessがそれらにどのような影響を与えるかについて話しましょう。そのために、Niteshに登壇してもらいます。Anumさん、Aurora Serverless v2の詳細な説明と、その主要な利点である即時の無停止スケーリングについての説明をありがとうございました。多くの方々が、Aurora Serverless v2のコスト削減、スケーリング、パフォーマンスの利点を実現するために、アプリケーションや組織でどのように活用すればよいかについて質問されています。
主要な機能について、もう一度お話ししましょう：無停止で行われるその場でのスケーリング、0.5 ACU単位でのスケーリング、そしてAurora Serverless v2がスケーリングする際にダウンタイムがないということです。これは、プロビジョニングされたリソースが十分に活用されていない場合や、アプリケーションのアクセスパターンや消費パターンがよくわからない場合に使用できることを意味します。5 vCPUが必要なのか、100 vCPUが必要なのかを事前に知る必要はなく、Aurora Serverless v2があれば、アクセスパターンについて事前に心配することなく把握できます。
このような理由から、Aurora Serverless v2では、高可用性と災害対策、分析とビジネスインテリジェンス、アプリケーション接続、そしてスケーリングといった観点で、いくつかのユースケースが可能になっています。これらは、今回のre:Inventで皆様もお聞きになったかもしれない、現在提供している最も強力な機能の一部を支えています。 まず、高可用性について詳しく見ていきましょう。Auroraは3つのAvailability Zoneにまたがる分散ストレージアーキテクチャを採用しています。ストレージは完全に分離されており、保存するデータ量に応じて自動的にスケールします。そして、Serverlessを使用することで、アプリケーションのパターンに基づいてコンピュートも自動的にスケールできるようになりました。Aurora Serverlessクラスターでは、最大16個のリードレプリカを持つことができます。
現在、多くの場合、プライマリインスタンスとなるWriterがあり、アプリケーションはAuroraが提供するクラスターエンドポイントの仕組みを使用しています。これにより、DNSを変更する必要がなく、常に1つのエンドポイントだけと通信することができます。分析や任意のアドホックワークロードを実行する場合、1つのリードレプリカを指すReaderエンドポイントを使用することがあります。現在は、例えばR6g.largeのようなProvisioned Instanceを使用している場合、このインスタンスは常に稼働している状態ですが、実際にはこのインスタンスを必要としない時間帯もあります。
このような場合、自動的にスケールするAurora Serverless v2インスタンスを即座に追加することができ、 ワークロードに応じてインスタンスを組み合わせることができます。これにより、容量が不要でリードレプリカの使用率が低い場合でも、そのまま維持することができます。フェイルオーバーの優先順位については、Writerは当然ながらティア0で、優先順位はCriticalとなっており、これは変更されません。ティア1のReaderはWriterと全く同じ構成で、ティア2がAurora Serverless v2となります。この時点で、ティア2のAurora Serverless v2インスタンスはReaderに追従しておらず、R6g.largeでもありません。Pause/Resume機能により、接続を待機している状態で待機し、接続が到着した時のみ起動することができます。
さらに一歩進めて、クラスター全体をServerless v2にすることもできます。これにより、予測不可能でスパイクの多いワークロードに対して、 すべてをServerless v2にして、上下にスケールさせることができます。ティア0のWriterとティア1のReaderは互いに同じサイズを維持するため、フェイルオーバーターゲットとして常に同じサイズのインスタンスを準備できます。Readerは、ワークロードとトランザクションの量に応じてサービスを提供します。これにより、使用率が低い可能性のあるProvisioned Instanceを常時稼働させる必要がなくなり、柔軟性とコスト最適化が実現できます。
次にGlobal Databaseについてお話ししましょう。Aurora Global Databaseを使用すると、1つのデータベースを最大5つのリージョンにまたがって物理的にレプリケーションすることができます。 各リージョンで16個のリードレプリカを持つことができ、これは合計90個のリードレプリカを意味します。また、フェイルオーバー先として、セカンダリリージョンを1つ以上持つことができます。現在、多くのミッションクリティカルなアプリケーションがGlobal Databaseを使用しています。これは、1分というRTOで災害復旧が可能だからです。スナップショットやバックアップを使用する場合、復元時間が変動する可能性がありますが、Global Databaseを使用すれば、障害からの復旧を非常に迅速に行うことができます。
お客様の中には、Global Databaseのセカンダリリージョンや他のリージョンでAurora Serverless v2を使用されている方もいらっしゃいます。これは、アクティブ-パッシブ構成で使用されていないセカンダリリージョンや、常時使用されていないアクティブ-アクティブワークロードがあることを意味します。セカンダリリージョンでは、スケールアップとスケールダウンを行うAurora Serverless v2クラスターを配置できます。東海岸が最初に稼働し、次に西海岸が稼働し、その後東海岸の負荷が下がるという、フォロー・ザ・サンモデルを採用されている方もいらっしゃるでしょう。Serverless v2を使用したこのアーキテクチャは、自動的にスケーリングを行い、ピーク時に必要な容量を常に確保しながら、アイドル状態を回避することで、Global Databaseのフェイルオーバーと低レイテンシーのスケーラビリティを維持しつつ、大幅なコスト削減を実現します。
多くのお客様から、Auroraの運用データに対して分析を行いたいというご要望をいただいていますが、数ペタバイトものデータを保存しようとすると、単一のAuroraインスタンスでできることの限界に達してしまいます。Amazon Redshiftのようなデータウェアハウスにデータを移行する際には、ETLパイプラインを構築する必要がありました。昨年、AWS全体で私たちはゼロETLの取り組みを開始しました。これは、AuroraやAWSの全サービスが担うべき差別化されていない重労働であるETLパイプラインの管理をお客様に行っていただく必要がないようにするという取り組みです。ゼロETLでは、データパイプラインの作成や管理が不要です。これにより、現在Auroraで利用可能な統合機能の一つであるAmazon Redshiftなどの下流システムへのデータ移行が非常に簡単かつシームレスになります。分析ストアとしてAmazon Redshiftを使用することで、ほぼリアルタイムでインサイトを得ることができます。
これらのインサイトは、リアルタイムの洞察、Webサイトのパーソナライゼーション、不正監視など、ビジネスに価値をもたらすことができます。現在、方程式の一方でAuroraのプロビジョンドインスタンスを使用し、もう一方で時にはアイドル状態や使用率の低いRedshiftウェアハウスを使用している場合があるかもしれません。私たちがAuroraとAWS全体で行っているのは、ゼロETLに加えて、これをすべてのお客様の標準とすることです。つまり、方程式の両側でサーバーレスリソースを使用できるようにします。
アドホックな分析がある場合、スケールアップとスケールダウンを行うAurora Serverless v2があります。同様に、進化するトラフィックパターンや予測不可能な使用パターンに対して、Amazon Redshift Serverlessがスケールアップとスケールダウンを行う準備ができています。Redshiftでは、ゼロETL統合を使用する際に、MLベースのワークロード監視やデータ共有など、より多くの分析機能を利用できます。使用した分だけお支払いいただき、自動的にチューニングされるため、Redshiftクラスターを管理する際の差別化されていない重労働を心配する必要はありません。
Aurora Serverless v2の課金モデルと最適化
次に、アプリケーションの接続性についてお話ししましょう。多くの開発者は、アプリケーションの接続性について心配しています。ドライバーの管理、AuroraサービスやAuroraインスタンスへの接続、認証方法の把握、必要なネットワークの設定などに苦労することがあります。この差別化されていない重労働を排除するため、Data APIを立ち上げました。これはAurora Serverless v1でのみ利用可能でしたが、現在はAurora Serverless v2とプロビジョンドクラスターでも利用できます。Auroraのすべての機能で、単一のHTTPエンドポイントを通じてAuroraクラスターに直接接続できるData APIを使用できるようになりました。
ドライバーの管理やアプリケーションの接続性について心配する必要はありません - それらは私たちが代わりに対応します。Aurora Serverless v2では、単純にスケールアップとスケールダウンを行うシンプルなエンドポイントを提供します。接続を送信すると、サーバーがオンラインになり、接続がない場合はスケールダウンします。これにより、開発者の生産性が大幅に向上し、インフラストラクチャを気にする必要がないという多くのメリットが得られます。Data APIは、Serverless v2とProvisioned Clusterの両方で動作する、私たちの組み込みQuery Editorも動かしています。
私たちは、Data APIに継続的に機能を追加しています。Data APIが提供するのは、PostgreSQLのpgAdminのようなクライアントをインストールすることなく、DDLやDMLをネイティブに実行できるAWS Management Console組み込みのQuery Editorです。Aurora Serverless v2、Aurora Provisioned、またはその他のAura Clusterを使用している場合、Query Editorを使用してすべてのクエリをネイティブに実行できます。Serverless v2では、Auroraに対してクエリを実行するためにEC2インスタンスやクライアントをセットアップする必要はありません。
Limitlessについてお話ししましょう。 Limitlessについては以前から耳にしていたかもしれませんが、最近PostgreSQL向けに一般提供を開始しました。このローンチについて、私たちは非常に興奮しています。多くのお客様から、単一インスタンスを超えてスケールできる機能が欲しいという要望をいただいており、Serverlessを活用したLimitlessがそれを実現します。Limitlessはサーバーレスによって動作し、トランザクションやワークロードに基づいて完全な即時スケーリングを提供します。これは従来のシャードアーキテクチャで、クエリをどこに振り分けるべきかを判断するルーティング層と、クエリを管理しデータを保存できるシャードを提供します。
現在のシャーディングでは、シャードの管理方法、移動方法、追加のタイミングなどを心配する必要があるかもしれませんが、Limitlessではそれらを私たちが代わりに処理します。シャード管理はAuroraが行うため、お客様はデータモデルとシャーディングアーキテクチャ、シャードキーがどのようなものかを考えるだけで済みます。また、Limitlessではリファレンステーブルなどの機能も提供しており、これはすべてのシャードで複製されます。つまり、レイテンシーに影響を与える可能性のあるクロスシャードクエリを実行する必要がありません。一部のテーブルが常にすべてのシャードで複製されているため、より高いパフォーマンスのメリットが得られます。
リファレンステーブルとシングルシャードワークロードを使用する際には、アプリケーションがどのように見えるかを考える必要があります。そしてLimitlessは文字通り限界がなく、ペタバイト規模のデータと数百万のトランザクションまでスケールできます。現在、LimitlessではAura Clusterを支えるのと同じAurora分散ストレージを使用しています。ただし、Aurora Clusterで1つのストレージ層を持つのではなく、個別のストレージを取得できるため、ペタバイト規模のデータまで対応可能です。
もし無制限のスケーラビリティが必要な場合や、年々急速に成長すると予想されるアプリケーションがあり、アーキテクチャの再設計やサービス間のデータ移行について心配したくない場合、Limitlessがその解決策となります。Limitlessの初期リリースはPostgreSQLベースで、完全なPostgreSQL互換性を備えています。私たちはLimitlessをさらに改善するため、Global Database対応、より多くのゼロダウンタイム操作、パフォーマンス向上など、機能の追加を継続的に行っています。皆様からのフィードバックを基に、より良いデータベースの構築を進めていきたいと考えています。
Aurora Serverless v2によって強化される機能について、Limitless、Global Database、高可用性や災害対策などの機能を見てきました。しかし、Serverless v2の課金の考え方を理解することも非常に重要です。これにより、支出と予算を適切に計画することができます。これはリソースに対する新しい考え方です。例えば、現在オンプレミス環境や静的にプロビジョニングされたデータベースを使用していて、コアに対して支払いを行っている場合、Serverless v2では従量制のコンピュートについて考える必要があります。固定料金ではなく、変動する料金体系となるためです。
Aurora Serverless v2は、特定のメモリとコンピュートに対応するACUモデルでのみ課金されます。単位はAurora Capacity Unit（ACU）で、常に固定額を支払うわけではありません。Aurora Serverlessのポーズと再開機能をリリースしたことで、使用量がゼロの場合は料金もゼロとなります。ただし、アプリケーションの負荷が急増してワークロードが最大256 ACUまで上がった場合は、その256 ACUに対して支払いが発生します。このような増減があるため、予算について慎重に考える必要があります。
お客様から、予算の設定方法や、開発者が多くのACUを消費する非効率なクエリを書いた場合のコスト増加を防ぐ方法についてよく質問を受けます。これに対応するため、Aurora Serverless v2では容量制限を設定できるようにしています。最小値と最大値の制限を設定できるため、データベースの最小フットプリントと支出は常に設定された最小値となり、最大値はストレージ支出の上限を定めます。2 ACUに設定した場合、請求額がその最大値を超えることはないことが分かります。課金は秒単位で行われ、分や時間の最小単位はありません。料金は地域によって異なりますが、計算は簡単です。月間の消費時間に基づくACU時間と、ACU時間あたりのコストで計算されます。
その他の課金コンポーネントは変更ありません。ストレージ、I/O、Global Databaseで消費される複製I/O、バックアップストレージの課金に変更はありません。Aurora Serverless v2がゼロにスケールダウンしても、ストレージは解放されず、データベースが再開中でも休止中でも課金は継続されます。I/Oは従量制のみで消費され、これも変更ありません。読み書きが多いI/O集中型のワークロードについては、最近Aurora I/O-optimizedをリリースしました。これにより、すべてのワークロードでより予測可能な価格性能比を実現します。I/O-optimizedでは、auto-vacuumingなどの運用活動を含むすべての読み書きに対するI/O課金がなくなり、ストレージとコンピュートのみの固定料金となります。これはストレージレイヤーで利用可能な新しいクラスター構成で、Aurora StandardとI/O-optimizedの間をダウンタイムなしで切り替えることができます。この切り替えは月1回可能で、必要に応じて元に戻すこともできます。
Aurora Serverless v2の導入方法とまとめ
どのように始めればよいのでしょうか？ロックインはなく、コンピュートとストレージの使用分のみの支払いです。Aurora Serverless v2は、PostgreSQL、MySQLに対応しており、Reserved Instancesもサポートしています。I/O操作に対する支払いは必要ありません。Aurora Serverless v2には、瞬時のスケーリングやシームレスなスケーリングなど、多くのメリットについて説明してきました。また、Serverlessによって実現される機能についても説明しました。
次のスライドでは、始め方について説明します。 これは主に、現在Aurora Serverlessのプロビジョンド版を使用していてまだServerlessを使用していない方や、Auroraプロビジョンド版から移行しようとしている方向けの内容です。新規クラスターでAurora Serverlessを始める場合は、非常にシンプルなワンクリック操作です。コンソールでAurora Serverless v2オプションを選択するだけで始められます。ただし、移行の場合は、もう少し手順が必要になります。
まず、現在最も一般的なAuroraのバージョンの一つであるAuroraプロビジョンド版からの移行について説明しましょう。 多くの方がこれを使用されているかもしれません。では、Aurora Serverless v2への移行はどのように行うのでしょうか？説明したように、同じクラスター内でインスタンスを混在させることができます。Serverless v2のリーダーを追加して、そこにフェイルオーバーするだけです。この例では、AZ oneとAZ threeにプロビジョンドのライターがすでにあり、そこにServerless v2リーダーを追加しました。クラスターエンドポイントは変更されません。
特定の理由により、プライマリライターと同じvCPUとメモリのみが使用され、プライマリの動作を模倣します。 フェイルオーバーが発生したことで、現在はリーダーとなっているプロビジョンドライターに向かっていた読み取りと書き込みは、プライマリライターに昇格したServerlessライターに向かうようになります。 クラスターエンドポイントはServerless v2クラスターを指します。RDS Proxyを使用している場合、DNSの伝播遅延や接続管理も自動的に処理されます。フェイルオーバーが完了したら、そのままServerless v2を使用し続けるか、リーダーが不要な場合は削除することができます。
さて、Aurora Serverless v2は、その名の通りServerlessの2番目のイテレーションです。すでにAurora Serverless v1がありますが、これはまもなくEnd of Lifeを迎えます。Serverless v1からの移行には、先ほどのプロビジョンド版の場合よりも多くの手順が必要です。最初に必要なのは、Serverless v1インスタンスをプロビジョンドに変換することです。これは簡単なAPI呼び出しで実行できます。engine modeをprovisioned に設定し、エンジンモードをServerless v1からGravitonまたはIntelインスタンスに変更して、その変更を適用できます。これにより、Aurora Serverless v2への移行が可能になります。その理由は、フェイルオーバー先となるプロビジョンドリーダーが必要だからです。
古いバージョンをお使いの方もいらっしゃるかもしれません。アップグレードが大変なことは理解していますので、Auroraのすべてにおいてblue/greenデプロイメントを導入しました。これはServerless v2でもサポートされています。Serverless v2に移行できる対応バージョンをお使いでない場合は、blue/greenデプロイメントを使用して対応バージョンに移行できます。これは最大でも1分のダウンタイムで済み、その後Serverlessリーダーを追加して、同じフェイルオーバーのステップに従うことができます。
ここで、Serverless v2のすべてのメリットをまとめてみましょう。Aurora Serverless v2は運用の複雑さを軽減し、コストを削減するのに役立ちます。お客様は何もする必要がなく、スケーリングのメリットを得られます - すべてのスケーリングは私たちが実行します。プロビジョニング型Auroraと同じアーキテクチャを採用しているため、Auroraの機能をすべてサポートしており、128テラバイトまでのストレージに対応できます。Global Database、RDS Proxy、高可用性とMulti-AZデプロイメント、そしてインスタンスとServerless v2クラスターの両方が可能なリードレプリカを使用できます。
課金は使用量に応じた従量課金制で、コンピュートに関してはACU単位でのみ支払いが発生します。すでに従量課金制のストレージと組み合わせることで、実際に使用したストレージとコンピュートの分だけを支払うことになります。それ以外の追加料金は一切かかりません。ACUレベルで支払い、秒単位の粒度が得られ、新しいクラスターは数回のクリックで始められます。
ここで、皆様が興味を持たれるかもしれない他のセッションをご紹介します。また、Amazon Aurora PostgreSQLもローンチしました。これらのセッションにぜひご参加ください。Auroraとそのイノベーションについての詳細、Serverlessスケーリング、Auroraクラスターのコスト削減のための最適化方法などをご紹介します。多くのお客様からご要望いただいていたので、コスト最適化のために他に何ができるかを知るのに役立つでしょう。また、先ほど説明したシャードデータベースであるLimitlessでスケールを実現する方法についても学べます。
皆様、本日はご参加いただき、ありがとうございました。セッションの選択肢がある中で、Anumと私のセッションを選んでいただき、感謝申し上げます。アプリでフィードバックを残していただければ幸いです。それでは、重ねて御礼申し上げます。残りのre:Inventもお楽しみください。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion