re:Invent 2024: AWSのAurora・RDSでパフォーマンス向上とコスト削減

はじめに

海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！

📖 AWS re:Invent 2024 - Boost performance and reduce costs in Amazon Aurora and Amazon RDS (DAT315)

この動画では、Amazon RDSとAmazon Auroraのパフォーマンス向上とコスト削減について、架空の企業AnyCompanyの事例を通じて解説しています。Amazon RDSでは、AWS Compute OptimizerやRDS Performance Insightsを活用したインスタンスの適正化、Read Replicaの活用、RDS Optimized Readsの導入により、最大50%のパフォーマンス改善を実現しました。Amazon Auroraでは、I/O-Optimizedへの移行で28%のコスト削減、Optimized Read機能で読み取りパフォーマンスを最大8倍に改善、Fast Cloneでストレージコストを90%削減するなど、具体的な数値とともに最適化手法を紹介しています。さらに、Aurora Global DatabaseやPostgreSQL Limitless Databaseによるグローバル展開とスケーリングの方法まで、包括的に解説しています。
https://www.youtube.com/watch?v=YGFWbS9ZJZk
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。

re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！

本編

Amazon RDSとAuroraの概要：パフォーマンス向上とコスト削減の鍵

皆様、ようこそお越しくださいました。ご参加いただき、ありがとうございます。Amazon RDSでパフォーマンスやコストの課題に直面された方は、手を挙げていただけますでしょうか。全員が手を挙げられたようですね。それは本日のプレゼンテーションにぴったりです。今日は、Amazon AuroraとAmazon RDSのパフォーマンスを向上させ、コストを削減するためのヒントとベストプラクティスについてご紹介させていただきます。私はAWSのSenior Database Solutions ArchitectのPini Dibaskです。後ほど、同僚でAWSのSenior Principal TechnologistのTim Stoakesも加わる予定です。

多くの方がすでにAmazon RDSについてご存知かと思いますが、改めて説明させていただきますと、これは完全マネージド型のリレーショナルデータベースサービスです。Amazon RDSを使用することで、アップグレード、バックアップ、プロビジョニングなどの運用管理タスクに時間を費やすのではなく、アプリケーションの革新と最適化に集中することができます。OracleやSQL Server、DB2などの商用エンジンはもちろん、MySQL、PostgreSQL、MariaDB、そしてAmazon Auroraなどのオープンソースエンジンもホストしています。Amazon Auroraは非常にユニークで、商用エンタープライズデータベースのエンタープライズグレードのセキュリティ、可用性、信頼性を、オープンソースデータベースのシンプルさとコスト効率の良さと組み合わせて提供するように設計されたクラウドネイティブなデータベースエンジンです。Amazon Auroraのユニークな特徴により、現在では何十万ものAWSカスタマーがリレーショナルデータベースとして使用しており、AWS史上最も急速に成長しているサービスとなっています。

AnyCompanyの事例：RDSのコスト要素と課題

それでは、RDSのさまざまなコスト要素について詳しく見ていきましょう。各データベースクラスターには、コンピュートとストレージに関連するコストがあります。また、バックアップ、データ転送、IOPSなど、ほとんどのお客様のワークロードで一般的に見られる追加コストもあります。 さらに、アプリケーションのユースケースや使用するデータベース機能によって異なるコストも存在します。

本日のプレゼンテーションでは、最も一般的なコスト要素とその最適化方法について、AnyCompanyという企業の例を使ってご説明します。これは架空の事例ですが、Timと私が日々お客様と関わる中で頻繁に見かける一般的な課題を代表するものです。AnyCompanyについて少し背景をご説明しますと、この会社は生成AIを活用してeコマースの販売者を支援し、あらゆる商品をベストセラーに変えることを目指しています。主要なAWSサービスとして、アプリケーション層にAmazon EKS、運用データベース層にAmazon RDSを使用しています。AnyCompanyは急成長中のスタートアップですが、まだ初期段階にあり、スケールアップに伴うコストとパフォーマンスのバランスが課題となっています。

RDSのコンピュートリソース最適化：インスタンスタイプの選択と監視ツールの活用

本日のプレゼンテーションでは、コストに関する3つの重要な要素、すなわちコンピュート、ストレージ、バックアップに焦点を当てたいと思います。 まずはコンピュートから始めましょう。 AnyCompanyが直面した最初の課題をご紹介します。AnyCompanyは当初、R6g.xlargeインスタンスタイプを使用していました。最初のうちは問題なく動作していましたが、顧客の利用が増えるにつれ、CloudWatchのCPUUtilizationメトリクスが時折100%に達し、ソリューションの信頼性に影響を及ぼすようになりました。一部の顧客からは、レスポンスの遅さやタイムアウトについての苦情も寄せられるようになりました。

多くのお客様から「どのインスタンスタイプを使うべきか」という質問をよくいただきます。これは、利用可能なインスタンスタイプが非常に多いため、難しい質問となることがあります。私たちは、パフォーマンスとコストの両面で適切なソリューションを見つける必要があります。 AWSでは、多くの選択肢があります。Burstableインスタンスは小規模または変動の大きいワークロードに最適で、General PurposeインスタンスはCPU集約型アプリケーションに適しています。

Memory Optimizedインスタンスはメモリ集約型アプリケーションに最適です。ARM アーキテクチャをベースとしたGravitonは、x86と比較して優れた価格性能比を提供し、様々なワークロードに適しています。ちなみに、ここではGraviton3を紹介していますが、最近Amazon RDSでGraviton4のサポートを発表しました。また、Amazon RDSでRAとMAGのサポートも開始しています。

多くの選択肢がある中で、適切なインスタンスを見つける最良の方法について疑問をお持ちかもしれません。AnyCompanyがライトサイジングの決定を行う前に使用しているツールをご紹介したいと思います。まずは監視ツールから始めましょう。 監視に関して、AWSのメインの監視・可観測性サービスであるAmazon CloudWatchがあります。これにより、CPU、メモリ、ネットワーク、ディスクレベルの使用率メトリクスなど、数十のインスタンスレベルのメトリクスを監視、可視化、アラート設定することができます。 Linuxのhuge pages、スワップアクティビティ、OSプロセスリストなど、より詳細なオペレーティングシステムレベルのメトリクスが必要な場合は、RDS Enhanced Monitoringが役立ちます。SQLステートメントやwaitイベントの可視化を含む、データベースレベルの詳細な監視が必要な場合、 RDS Performance Insightsが適切なツールとなります。

RDS Performance Insightsについて言えば、 多くのお客様から、最も複雑なデータベースのボトルネックでも効果的かつ効率的に診断できると好評をいただいています。waitイベント、SQLステートメント、アプリケーションサーバーなど、様々な観点からアクティビティを可視化し、掘り下げ、分析することができます。すべてのAmazon RDSエンジンをサポートしているため、お客様に有効化をお勧めする非常に便利なツールです。 また、多くのお客様がライトサイジングの判断を行う前にPerformance Insightsを活用していることがわかりました。

このように、 インスタンスのvCPU数がデータベースの負荷よりもはるかに高いデータベース負荷チャートを見つけた場合、これは潜在的にオーバーサイズなインスタンスであり、コスト最適化の機会があると判断できます。一方、負荷チャートを見て、そのインスタンスのvCPU数が 実際のワークロードやデータベース負荷よりも低い場合、これは潜在的にアンダーサイズなインスタンスです。この場合、アプリケーション、データベース、SQLステートメントのチューニングを行うか、あるいはインスタンスのライトサイジングを検討する必要があります。

多くのお客様から、インスタンスのサイジングの判断において CloudWatch や Performance Insights が役立っているという声をいただいています。しかし同時に、より大規模な自動推奨機能が必要だという声も数多くいただいています。数十、数百、あるいは数千のインスタンスを持つお客様は、より大規模な自動推奨機能を必要としているのです。そこで数ヶ月前、お客様からのフィードバックに応えて、Amazon RDS MySQL と Amazon RDS PostgreSQL に対する AWS Compute Optimizer のサポートを発表しました。これにより、インスタンスフリート全体に対して最適なインスタンスサイズを特定するお手伝いができるようになりました。この例では、Graviton2 世代ベースの R6g から、より優れた価格性能比を提供する Graviton3 世代ベースの R7g への移行が推奨されています。

適切なツールと AWS Compute Optimizer を活用することで、 AnyCompany が直面していた最初の課題を解決することができました。新しい Graviton 世代をベースとする R7g.xlarge に移行することで、27%の価格性能比の向上を実現しました。これにより、お客様に最も安定した一貫性のあるワークロードを提供することが可能になりました。これは、最新の Graviton イノベーションを活用して、パフォーマンスを向上させながらコストを抑制するという素晴らしい例と言えます。

ノイジーネイバー問題の解決：Read Replicaとキャッシング戦略

二つ目の課題は、ノイジーネイバーの問題です。 AnyCompany の場合、社内のデータアナリストたちがレポート作成のためにデータベースへのクエリを実行し始めたときに、パフォーマンスの低下が始まりました。経営陣向けのダッシュボードを作成する必要があり、そのレポート用クエリがパフォーマンスに影響を及ぼし始めたのです。

これらのレポート用クエリは、主要な顧客アプリケーションに影響を与えました。これは、同じデータベースリソース上で競合するワークロードが発生する場合によく見られる典型的なノイジーネイバーの事例です。これらのワークロードを効果的に分離するか、より効果的に管理して互いに干渉しないようにする方法を見つける必要がありました。

従来のアプローチは、インスタンスを適切にサイジングし、より大きなインスタンスに移行する垂直スケーリングです。しかし、 リードレプリカを使用すると、最大15個のリードレプリカを異なるサイズで作成できるため、より柔軟な対応が可能です。これにより、 ノイジーネイバーの問題を解消し、アプリケーションのスループットを向上させることができます。 垂直スケーリングと水平スケーリングのコストの違いについて疑問に思われるかもしれません。これは、各ワークロードが固有のものであるため、具体的なアプリケーションのユースケースによって異なります。AnyCompany の場合、R7g.xlarge から R7g.2xlarge への垂直スケーリングは、実際にコンピューティングコストが2倍になってしまいます。

彼らは Read Replica を使用した水平スケーリングを採用することを決定し、より小規模な Read Replica である R7g.large を使用することで、 レポーティングクエリを非常に効果的かつ効率的に処理できることを発見しました。これにより、このノイジーネイバーの問題に対してよりコスト最適化されたアプローチを実現できました。なお、ここで示している価格例は North Virginia のオンデマンド価格ですが、Amazon RDS では Reserved Instance を使用するオプションもあります。定常的なワークロードに対して1年または3年の長期コミットメントができる場合、大幅な割引を受けることが可能です。

この問題に対するもう一つの解決策は、Amazon ElastiCache を使用して SQL の結果セットなどの頻繁にアクセスされるデータをキャッシュすることです。これにより、他の選択肢と比較して多くの場合、より低コストで高速なパフォーマンスを実現できます。その仕組みについて - キャッシング戦略には複数ありますが、一般的なアプローチの一つとして、データベースに書き込む際、レコードの挿入や更新を行うたびに、 同時に Amazon ElastiCache のキャッシュも更新します。データを読み取る必要がある場合は、 インメモリデータベースから直接読み取ることができ、パフォーマンスが向上します。

ただし、ElastiCache を使用して頻繁な結果セットをキャッシュする方法は、すべてのユースケースやワークロードに適しているわけではありません。非常にユニークなアドホックな動的フィルターを使用する状況では、ElastiCache を使用しても必ずしも最適な結果が得られるとは限りません。この AnyCompany の特定のユースケースでは、ほとんどのレポーティングクエリが動的でアドホックであるため、 Read Replica を使用してクエリをオフロードするという異なるアプローチを選択しました。このアプローチを採用することで、API における主要な顧客向けアプリケーションのパフォーマンスを全体で50%改善することができました。

RDSのストレージパフォーマンス改善：EBSオプションとOptimized Reads

次に、Amazon RDS の2つ目の側面である、ストレージについてお話ししたいと思います。パフォーマンスのニーズに合わせて、さまざまな Amazon EBS オプションを選択できます。 GP2 では IOPS 数が割り当てられたストレージ容量に紐付けられているため、ストレージをギガバイトやテラバイト単位で増やすと、より多くの IOPS を利用できます。 一方、GP3 ではストレージサイズとは独立して IOPS とスループットを割り当てることができ、より柔軟性があります。

GP2 と GP3 は、開発やテスト環境、中規模のワークロードに最適です。一貫した低レイテンシーが必要なミッションクリティカルなアプリケーションには、IO1 と IO2 Block Express が推奨されるオプションとなり、 IO2 は耐久性、スループット、低レイテンシーが改善されているため、より推奨されます。IO2 では5ナイン（99.999%）の耐久性が得られ、これは100倍の耐久性を意味します。

IO1についてですが、サブミリ秒のI/Oレイテンシーを実現できます。これはAmazon RDSにおいて、サブミリ秒のI/Oレイテンシーを提供する唯一のEBSオプションです。IO1とIO2は同じ価格設定なので、現在IO1をお使いの場合は、追加コストなしで性能と耐久性が向上するIO2への移行をご検討いただけます。これはオンライン操作で実行可能ですが、いつもお客様にお伝えしている通り、本番環境で実施する前に、必ず事前検証環境や非本番環境でテストしていただくようお願いします。

さて、AnyCompanyの別の課題に戻りましょう。今度はEBSのI/Oレイテンシーに関する問題です。データベースが拡大するにつれて、 EBS IOPSの制限に達し、I/Oレイテンシーが2ミリ秒から500ミリ秒まで急上昇してしまい、これは深刻なパフォーマンス問題となりました。これは、高いI/O需要がI/Oのボトルネックやレイテンシーの問題を引き起こす、時々見られるスケーリングの問題です。解決策を見つける必要がありますが、インスタンスの適切なサイジングに加えて、ストレージのサイジングも必要になることがあります。AnyCompanyの開発チームからの要件は明確でした：このミッションクリティカルなアプリケーションにはサブミリ秒のI/Oレイテンシーが必要だということです。

このプレゼンテーションで説明している他の課題と同様に、適切なモニタリングツールを使用することで、ボトルネックを簡単に特定することができました。ここでRDS Performance Insightsのメトリクスダッシュボードを見ると、EBS IOPSの数とI/Oレイテンシーの両方が増加していることが明確に示されており、先ほど述べたように500ミリ秒まで上昇していることがわかります。 この場合の解決策は、ストレージの適切なサイジングでした。具体的には、gp2からio2 block expressに移行することで、お客様が必要とするサブミリ秒のI/Oレイテンシーを実現することができました。CloudWatch、Performance Insights、Compute Optimizerなどのツールを使用することで、いつどこで調整が必要かを理解することができます。

次は4番目の課題で、レポーティングクエリの遅さに関する問題です。お客様の社内データアナリストがRead Replicaでレポーティングクエリを実行していました。彼らは多くのJOINやORDER BY、GROUP BY句を含む複雑なSQLクエリを実行していましたが、それらのダッシュボードの平均ロード時間が約10秒かかっていることがわかりました。経営陣からは5秒以内であれば許容できるとの指示がありました。 このパフォーマンスの問題をより深く調査したところ、これらの複雑なSQLクエリが多くの一時オブジェクトを生成していることがわかりました。PostgreSQLのようなデータベースシステムは、最適なパフォーマンスを得るためにメモリ上で処理を実行しようとしますが、これらの処理に十分なメモリがない場合、一時オブジェクトをディスク（この場合はEBS）に書き込むことがあります。これは特に大規模なデータセットや複雑なクエリの場合、レイテンシーの増加につながる可能性があります。

この問題に対処する一つの方法として、一時オブジェクトがEBSに書き込まれるという問題に直面しているほとんどのお客様にお勧めしている優れた機能があります。それがRDS Optimized Readsで、この機能は特にこのユースケースに向けて設計されたローカルの高速NVMe SSDを提供します。ソートやグループ化クエリの中間結果を保存するために必要な一時オブジェクトを、このローカルNVMe SSDに保存することができます。これにはR6gやR6gdのような、このタイプのローカルNVMe SSDをサポートするインスタンスの使用が必要です。今回のケースでは、Optimized Readsを使用することでこの問題を解決することができました。

コストの例を見てみましょう。AnyCompanyは、Read Replicaに対して垂直スケーリングを選択してR7g.xlargeに移行することもできましたが、それではコンピュートコストが2倍になってしまいます。そこで代わりに、現在Optimized Readsをサポートする最新のGravitonジェネレーション（R6gd）を使用し、より小さなインスタンスタイプであるR6gd.largeを選択することで、必要なパフォーマンスを確保することにしました。その結果、インフラコストを大幅に増やすことなく、クエリの実行時間を2倍速くすることができました。実際、元のインスタンスタイプからOptimized Readsベースの新しいインスタンスタイプへの変更によるコスト増加は10%未満でしたが、レポーティングクエリのパフォーマンスは2倍になりました。複雑なクエリで一時オブジェクトがディスクに書き込まれる問題に直面している場合、特にソート、GROUP BY、ORDER BY操作、または結合操作の中間結果を保存する必要がある場合は、RDS Optimized Readsが優れたソリューションとなるでしょう。

RDSのバックアップ戦略：コスト削減とデータ保持の最適化

次に、最後のコスト要素であるバックアップについてお話ししたいと思います。Amazon RDSでは、自動バックアップとデータベーススナップショットという2種類のバックアップを提供しています。自動バックアップには日次のEBSスナップショットが含まれ、さらに5分ごとにトランザクションログがAmazon S3に保存されます。自動バックアップの利点は、保持期間内で細かい粒度のPoint-in-Time Recoveryが可能なことで、この保持期間は最大35日間に設定できます。一方、データベーススナップショットは任意のタイミングで取得でき、削除するまで保持できるため、有効期限がありません。これにより、長期的なバックアップ管理をより柔軟にコントロールすることができます。

これは、AnyCompanyが直面していた最後の課題である高額なバックアップコストにつながります。AnyCompanyは、多くの企業で一般的な1か月間のバックアップ保持期間を設定していました。しかし、顧客の要件を詳しく確認したところ、リストア可能なデータは1週間分あれば十分で、1週間以上経過したデータはコンプライアンスのためのクエリ用途でのみアクセスする必要があることがわかりました。そこで、バックアップコストを大幅に削減する必要があり、長期バックアップを処理するためのコスト効率の良い方法がいくつかあります。その一つが、Amazon S3へのスナップショットエクスポートで、これはデータベース全体または特定のスキーマやテーブルに対して実行でき、Amazon Athenaなどのツールでの保存やクエリに適したApache Parquet形式で保存されます。

もう一つの選択肢は、データベースのネイティブツールを使用した論理バックアップです。例えば、PostgreSQLではpg_dump、MySQLではMySQL Shell Dumpを使用できます。これらは、コスト効率の良い長期バックアップを実現する異なる方法です。Amazon S3へのスナップショットエクスポートでも、論理バックアップでも、データはお客様が所有するバケットに保存されるという利点があります。これにより、ストレージクラスを完全にコントロールすることができます。例えば、頻繁にアクセスされるデータに適したS3 Standardを指定したり、あるいはデータへのアクセス頻度が低いことがわかっている場合は、S3 Infrequent AccessやS3 Glacierを使用したりすることができます。これにより、データの保存方法についてより柔軟な選択が可能になります。一方、自動バックアップやデータベーススナップショットなどのRDSネイティブバックアップでは、使用するS3ストレージクラスを制御することはできません。

このアプローチを使用することで、バックアップのコストを大幅に削減することができました。ここでは、30日間の自動バックアップを使用する元のバックアップコストを見ることができます。データベースサイズが500ギガバイトで、日次のEBSブロック変更が100ギガバイトあると仮定してみましょう。初期スナップショットは500ギガバイトで、AWSがデータベースサイズの100%までを無料のバックアップストレージとして提供しているため無料となり、その後は増分スナップショットごとに課金されます。各増分スナップショットは、日次のブロック変更を表す100ギガバイトです。一方、コスト効率の良い代替案では、RDSの自動バックアップを1週間のみ使用し、残りのデータについては先ほど説明したS3スナップショットエクスポートのアプローチを使用します。これにより大幅なコスト削減が実現され、より具体的には、バックアップコストを30%削減することができました。これは、コンプライアンス、アクセス、データ保持要件を維持しながら、効率的なバックアップデータの保持がいかに大きな節約につながるかを示しています。

CloudWatch Database Insightsの導入：統合監視の新時代

ここで一旦立ち止まって、これら3つの画像に共通するものは何かお聞きしたいと思います。懐中電灯、レーダー、虫眼鏡が表示されていますが、これらはすべて可視性を提供するツールです。データベースのパフォーマンスとコストに関して言えば、見えない問題は修正できません。CloudWatch、Performance Insights、Enhanced Monitoringなどのツールについて説明しましたが、これらのツールは顧客の全体的な journey において非常に有用です。しかし、AWSが提供する従来の監視ツールについて、企業からいくつかの課題が指摘されており、皆さんの中にもこれらの課題に共感される方がいらっしゃるかもしれません。

最初の課題は、Performance Insightsがデータベースの詳細な診断に非常に役立つものの、情報が常にインスタンスレベルのビューで表示されることです。インスタンス間を切り替えることはできますが、常に1つのインスタンスしか表示されないため、全体像を把握することができません。企業の成長を考えると、初期のスタートアップとして始まったものの、規模が拡大して数十から数百のインスタンスを管理する必要が出てきた時に、この問題が非常に重要になってきました。もう1つの課題は、AWSには多くのパフォーマンスデータ、トレース、ログがCloudWatch、CloudWatch Logs、RDS Enhanced Monitoring、RDS Performance Insights、RDS Eventsなど、様々なツールに散在していることです。多くの顧客から、真の意味でのシングルペインオブグラスを実現するため、一元化されたテレメトリーの提供を求められていました。最後に、多くの顧客から、アプリケーションのコンテキスト、特にアプリケーションAPIとデータベースのパフォーマンスの相関関係をより良く理解したいという要望がありました。

私たちはお客様のフィードバックに耳を傾け、本日、CloudWatch Database Insightsの発表を大変嬉しく思います。この新しい発表により、すべてのデータベース監視がAmazon CloudWatch内の単一の統合ビューに集約されます。特定のタグや、リージョン内の特定のインスタンスによってインスタンスのフリートを定義できます。これを行うと、インスタンスサマリーを示すヒートマップが表示され、データベースの負荷、データベースのアラーム、さまざまなメトリクスなど、様々な観点からボトルネックがどこにあるかを理解することができます。このローンチでは、Amazon Aurora PostgreSQLとAmazon Aurora MySQLをサポートしており、将来的には他のRDSエンジンもサポートする予定です。

今回の発表におけるもう一つの革新は、特定のインスタンスを詳しく調べる際に、すべてのトレース、ログデータ、待機イベントを関連付けることができるようになったことです。これは、すべての監視データが標準で一元化されて提供されるようになったためです。多くのお客様は、アプリケーションのパフォーマンス監視（APM）ソリューションであるCloudWatch Application Signalsをご存知だと思います。これは、CloudWatchエージェントとAWS Distro for Open Telemetryを使用してパフォーマンスとトレースデータを収集できるAPMツールです。多くのお客様から、データベースのパフォーマンスとアプリケーションのパフォーマンスの相関関係や、データベースのボトルネックに関連するAPIコールやサービスの依存関係をより良く理解したいというご要望をいただいていました。

最後になりますが、Performance Insightsをご利用の方々は、特定のインスタンスを調べて問題のあるSQLステートメントを分析することに慣れていらっしゃると思います。実行回数、一時的な読み取りや書き込みの回数、ページの読み取りや書き込みの回数などのメトリクスや統計情報を確認する際、選択した期間での集計値を見ることができます。先週を振り返って特定のステートメントが10,000回実行されたことを知るのは有用ですが、時間の経過に伴う傾向を見ることができればさらに有用です。今回のローンチでは、各SQLメトリクスとSQL統計情報の時系列での傾向を確認できるようになりました。

合計値を見るだけでは役立つかもしれませんが、それだけでは十分な情報が得られません。今では時間の経過に伴う動作を確認できるようになりました。 まとめると、見えない問題は解決できないということです。そのため、Amazon CloudWatch Database Insightsのような最新の監視イノベーションを活用して、より積極的に対応することが重要です。どの企業もこれらのツールを使用して課題に対処しています。

AnyCompanyについて言えば、Timにバトンを渡す前に、彼らの取り組みを簡単に振り返りたいと思います。まず、顧客の採用率増加によるワークロードの増加という課題から始まりました。これは、インスタンスの適正化、特に最新のGravitonイノベーションを活用することで解決し、価格性能比を改善しました。次に、ノイジーネイバーの問題が発生し、これはレポートクエリをリードレプリカにオフロードすることで解決しました。これにより、コアとなる顧客アプリケーションとレポートクエリの両方が互いに干渉することなくスムーズに実行できるようになりました。

その後、I/Oレイテンシーの問題が発生し、ストレージの適正化としてgp2からio2 Block Expressに移行することで、ミリ秒以下のI/Oレイテンシーを実現することができました。さらに、レポートクエリの遅延という問題が発生しました。これらのクエリは複雑で、多くのJOIN操作やORDER BY、GROUP BY操作を実行していることがわかりました。EBS上に多くの一時オブジェクトを作成していることを特定し、RDS Optimized Readsに移行することでパフォーマンスを2倍に改善することができました。最後に、バックアップコストが高額という問題がありましたが、これはスナップショットのAmazon S3へのエクスポートなど、コスト効率の良い長期バックアップ方法を使用することで解決しました。

Amazon Auroraの特徴とI/O最適化：コスト削減とパフォーマンス向上の両立

それでは、Timに引き継ぎたいと思います。今度は、Amazon Auroraについての似たような、しかし異なる道のりについて学んでいただきます。 みなさん、こんにちは。私はAuroraのSenior Principal TechnologistのTim Stoakesです。 Piniのおかげで、Amazon RDSについて詳しく理解していただけたと思います。今度は、同じような話ですが、少し異なる結末をAuroraでお話ししたいと思います。再び、AnyCompanyの事例から始めますが、今回は架空のスタートアップが、RDSのオープンソースではなく、最初からAuroraを選択することにした場合についてです。

Auroraは、クラウド向けに構築された、MySQLとPostgreSQLと完全な互換性を持つリレーショナルデータベース管理システムです。 標準的なMySQLの5倍、PostgreSQLの3倍のスループットを提供します。ストレージレイヤーでの回復性も備えています。これがAuroraとRDSの大きな違いであり、価格とパフォーマンスについて話す際に、異なるトレードオフが生じます。AnyCompanyが最初からこれを選んだからといって、皆さんも最初から選ぶ必要はありません。AWS Data Migration Serviceや独自のツールを使って、RDSとAuroraの間を自由に移行することができます。

RDSと同様に、ここでも3つのコスト要素について考える必要があります。 順序を変えて、ストレージの話を先にしたいと思います。より興味深い部分だからです。 まず、Auroraのストレージの仕組みを理解する必要があります。下部のAuroraストレージで、ストレージをヘッドノードから分離しています。3つのAvailability Zoneにまたがって分散されており、多数のストレージノードで構成されています。 色付きの小さなボックスは他のユーザーのデータを示しています。これらはマルチテナントのストレージノードで、マルチテナントのストレージフリートの一部です。書き込みを行うと、Auroraはこれらのストレージノード全体に6つのコピーを作成し、 お客様は1つのコピー分のみを支払います。3つのAvailability Zoneにまたがる6重の耐久性を得られます。つまり、1つのAvailability Zone全体のストレージノードと、 ボリューム内のもう1つのストレージノードが利用できなくなっても、耐久性や可用性に問題は生じません。これがAuroraに標準で備わっている機能です。これがAuroraストレージの対価として得られるものです。では、これはパフォーマンスにどのような影響を与えるのでしょうか？

この会社には異なる課題があります。 一部の顧客はバースト的なアクセスを行います。右上に通常の顧客がいて、そこにバースト的なアクセスを行う顧客が加わります。これは課題となります。 これは、特定の地域の人々が活動を始める時間帯や、Taylor Swiftのチケットが発売されるときなどに発生する可能性があります。あなたの会社でも、同じようなパターンがあるかもしれません。Auroraは、そういった状況の多くを自動的に処理してくれます。そのため、あまり細かな管理は必要ありません。

しかし、この柔軟性には潜在的な問題があります。それは、I/Oコストの予期せぬ増加につながる可能性があるということです。バックエンドで事実上無制限のI/Oが可能だからといって、それに対して支払いたいわけではありません。これが私たちの課題です。Auroraデータベースクラスターのコストをより予測しやすくしたいのです。 そして、できればI/Oコストも削減したいと考えています。

それでは、その方法についてお話ししていきましょう。Auroraはストレージやその他の面でも、使用した分だけ支払う方式です。まずストレージについて説明しましょう。これは他の多くのAWSサービスと同様に、1ギガバイト/月単位で課金されます。必要に応じてAWSが自動的にボリュームを拡張し、不要になると縮小します。CloudWatchのVolumeBytes Usedメトリクスで状況を確認できます。PostgreSQLを使用している場合は、サイズを管理するためにvacuumを実行したり、auto vacuumを設定したりすることで、ある程度制御することができます。

次にI/Oについて説明しましょう。データベースのページ読み取り操作は1回のI/Oとしてカウントされます。使用しているデータベースエンジンに関係なく、Auroraの仕組みとデータベースエンジンの仕組みにより、書き込みは4キロバイト単位でまとめられます。サイズが異なる場合はバッチ処理されます。Auroraでは、これらはどちらも100万リクエスト単位で課金されます。I/Oの数はスケーラブルで、Piniが先ほど説明したようなプロビジョニング型ではありません。インスタンスを通じてI/Oを処理できる限り、Auroraはそのままそのパフォーマンスを提供します。

ここで示しているのは、上部に1つのAuroraインスタンスだけですが、実はこのレプリカは複数持つことができます。I/Oを実行する際、価格とパフォーマンスの観点からすべて同じように動作します。同じストレージを共有し、同じ課金方式と同じパフォーマンス方式を共有しています。

ここで先ほどと同じように具体例を見てみましょう。ボリュームの初期サイズは100ギガバイトで、1日あたり100メガバイトずつ増加しているとします。これはCloudWatchで確認できます。インスタンスのコストを見てみましょう。30日間R6g.xlargeを使用すると、約370ドルになります。一貫性のため、North Virginiaのオンデマンドインスタンスを前提としており、基本的な負荷として1秒あたり600のリードとライトがあります。

これは600に30日と24時間を掛けて計算すると、約207ドルになります。ストレージのコストは1ギガバイト/月あたり10セントで、少し複雑な計算になりますが、基本サイズと増加分を合わせると月額約300ドルになります。この顧客にとって問題となるのは、負荷のバーストが発生した場合です。1秒あたり15,000 I/Oという大きなバーストが発生します。これもVolumeWriteIOPsのCloudWatchメトリクスで確認できます。同じ計算方法でバースト時のI/Oコストを計算すると、さらに648ドルかかります。これはかなり大きな金額で、この場合、予測が難しいという問題があります。これは好ましくない状況です。

では、この問題にどう対処していくのでしょうか？ Cachingを導入していきます。 データベースの分野に携わっている方々にとっては、おなじみの手法だと思います。以前のように大量のI/Oをプロビジョニングすることを避けるのではなく、バーストに対する緩衝材としてI/Oコストを削減することを目指します。インスタンスをスケールアップすると、Cacheが大きくなるため、読み取り回数を減らすことができます。さらにスケールアップすると、より少ない読み取りで済むようになり、さらにスケールアップすると、Cacheが大きくなってより少ない読み取りで済むようになります。このように、Cacheが大きくなればなるほど、I/Oが少なくなるという相関関係が見えてきます。これによってコストを削減でき、パフォーマンスも向上する可能性があります。

Cachingは確かに有効な手法で、コスト削減とパフォーマンス向上が期待できますが、バーストI/Oと通常のI/Oのバランスによっては、必ずしもすべての企業にとってベストな解決策とは限りません。そこで、別の解決策についても見ていきましょう。例を続けるため、ここではインスタンスサイズはそのままにしておきます。

Auroraには、I/O-Optimizedという別のオプションがあります。これは、これまで説明してきたIOPSを使用するStandardとは異なる価格オプションです。 読み取りと書き込みのI/O操作に対する課金が完全にゼロになります。データベースインスタンスとストレージのギガバイト月分のみを、異なるレートで支払うだけです。この方式では、変動要素がないため、コストの予測が非常に簡単になります。

I/O料金が請求額の約25%を超える場合、最大40%のコスト削減が可能です。これが、おおよそのブレークイーブンポイントとなり、それを超えると有利になってきます。メリットがない場合に選択してほしくないので、これが大まかな目安となります。具体的な計算は、Pricing Calculatorで確認することができます。 また、これは単なる価格オプションではなく、ストレージレベルで異なる処理を行っているため、スループットが向上し、レイテンシーも削減されます。今後のパフォーマンス最適化は、まずI/O-Optimizedに適用されることが確実です。

クラスターをI/O-Optimizedに切り替えるのは、ワンクリックで完了します。月に1回でも、好きなタイミングでオン・オフを切り替えることができます。試してみて何らかの理由で上手くいかない場合は、元に戻すこともできます。ダウンタイムやフェイルオーバーなども一切必要ありません。

先ほどのコスト例を、今度はI/O-Optimizedを使用して見てみましょう。 条件は同じで、グレーで示された部分は前回と変わっていません。インスタンスは異なるレートで課金されますが、他の数値はすべて同じで、約486ドルとなります。 ストレージサイズのパラメータは同じなので、増加量も同じですが、異なるコスト乗数の675ドルが適用されます。 通常のベースロードと突発的なものの両方を含むストレージI/Oは、I/O-Optimizedを使用しているため無料で、しかも恐らくより高速に処理されます。

これらを合計すると、約28%のコスト削減になります。これは、I/O処理が多いアプリケーションでは典型的な結果で、I/O-Optimizedを使用することでコストを削減できます。 つまり、この最初の課題に対する解決策は、ConsoleやCLIでワンクリックするだけでI/O-Optimizedにシームレスに切り替えることで、予測可能性を向上させ、コストを削減し、パフォーマンスを改善することでした。

Aurora Fast CloneとServerlessの活用：テスト環境の効率化とコスト削減

課題の2つ目は、バックエンドに異なる社内顧客がいることです。月末に読み取り処理の多いレポート作成ジョブを実行することがあります - 皆さんの会社でも同様のシナリオがあるのではないでしょうか。 これらのジョブは、ノード内のBuffer Poolを圧迫し、収益源となるフロントエンドのクエリを含む他のクエリのパフォーマンスに影響を与える可能性があります。 バックエンドジョブがフロントエンドクエリに与える影響を軽減し、コスト効率を維持しながら全体的なパフォーマンスを向上させたいと考えています。

解決方法をご説明します。下部に共有ストレージレイヤーを持つAuroraインスタンスがあります。このクラスターに別のインスタンスを追加します - 同じ物理ストレージを参照するため、ストレージのコピーや移行は必要ありません。ここでは2つのRead Replicaを異なるAvailability Zoneに配置していますが、これは自由に設定できます。同じAZにまとめたり、2つ以上（実際にはAuroraでは最大15個まで）作成したり、サイズを変えたりすることも可能です。

データの耐久性はすべてストレージにあるため、影響はありません。書き込みノードは常に1つだけで、トランザクションが入ってくるたびにこれらのReplicaを最新の状態に保つことが役割の1つです。完全な同期ではありませんが、ラグはミリ秒単位なので、結果の不整合を心配する必要はほとんどありません。これらのReplicaはそれぞれがフェイルオーバーターゲットにもなるため、パフォーマンス改善策であると同時に、レジリエンシーを向上させる方法としても考えることができます。コスト、パフォーマンス、可用性を同じスケールで調整できますが、大規模なワーキングセットを持つ企業にとっては、このようなトレードオフが経済的に意味をなさない場合もあります。

そのため、他のオプションを検討する必要があります。Aurora PostgreSQLのOptimized Readsについて見ていきましょう。 これはAmazon RDSのOptimized Readsと同じ名前で似たようなコンセプトですが、動作が少し異なります。例えばR6g.xlargeのように、ノードにはNVMe SSDが搭載されています。RDSと同様に、一時データの保存にAmazon EBSの代わりにこれを使用できます。 これは先ほど説明した概念と同じで、その目的には依然として非常に優れたアプローチです。

さらに、Tiered Cacheと呼ばれる機能を提供しており、これによってバッファプールをメモリからSSDにまで拡張することができます。 これにより、特に読み取りの多いクエリで最大8倍のパフォーマンス向上が得られ、よりコスト効率が高くなる可能性があります。メモリほど高速ではありませんが、インスタンスが大幅に安価なため、作業セットに基づいて経済性を計算する必要があります。これは単にインスタンスタイプを切り替えるだけで実装でき、 短時間のフェイルオーバー操作で済みます。末尾に'd'が付いているインスタンスのいずれかを選択し、I/O-Optimizedストレージを使用する必要があります。他の設定は必要ありません。

Optimized Readsのコスト例を見ていきましょう。キャッシングソリューションはワークロードのキャッシュ可能性に依存するため、作業セットのサイズ、クエリのサイズ、これらのページが再度読み取られる可能性を考慮する必要があります。これはCloudWatchメトリクスを調べることで見積もることができます。これまでの例ではR6g.xlarge を使用してきましたが、Optimized Readsを使用するためにR6gd.xlargeに切り替えます。このインスタンスは230ギガバイトのTiered Cacheをサポートしています。キャッシュで同等のメモリ量を得るには、R6g.12xlargeを使用する必要があり、これは明らかに単一のxlargeよりもはるかに大きくなります。

コストを見てみると、12xlargeを選択した場合、1ヶ月あたり約5,830ドル になります。R6gd.xlargeを選択した場合は583ドルで、10分の1です。ユースケースに対して同等のパフォーマンスが得られるのであれば、これは明らかにより経済的なオプションです。両方のケースでI/O-Optimizedを使用しているためストレージコストは含まれており、 サイズも両方で同じなので、差異として考慮する必要はありません。全体として、90%のコスト削減を実現できます。 Aurora PostgreSQLを使用していて、このモデルに適している場合は、これは大きな改善と言えます。

課題2に対して、私たちは次のことを行いました： I/O-Optimizedを使用し、コストを90%削減し、単にインスタンスタイプを切り替えるだけという簡単な方法でした。さて、開発者は テストを行う必要がありますが、本番環境では実施できません。本番環境に近いデータでテストする必要がありますが、これまではETLジョブを使用して本番環境をコピーしており、データの完全コピーが必要なため複雑で高コストでした。開発者は24時間働いているわけではないので、システムを使用していない時は遊休状態でお金の無駄になっています。ETLリフレッシュプロセスには時間がかかるため、頻繁には実行されず、その結果テストデータが古くなってしまいます。

私たちはストレージコスト、コンピュートコスト、作成時間を新しいテクニックで削減したいと考えています。具体的に何をするのでしょうか？Auroraのファストクローンを使用します。ファストクローンはコピーオンライト技術を使用して仮想コピーを作成します。実際のデータバイトをコピーする必要がないため、素早く、データを実際に複製しないのでコストもかかりません。新しいボリュームを作成すると、単に数個のポインタを作成するだけです。テスト目的でデータを匿名化した日次クローンを作成することもでき、これをゴールデンイメージと呼びます。これは新しいデータベースインスタンスと新しいボリュームを通じて参照できます。まだ何も変更していないため、ストレージに対する課金は発生せず、インスタンスを使用した時のみ課金されます。

できることは、そのインスタンスをクローンして、テスト環境を作成することです - このファミリーで最大15個までのクローンを好きなだけ作成できます。ボリュームを変更した時にのみ、その変更分がストレージコストとして課金され、I/O最適化インスタンスを使用していない場合はI/Oの使用分も課金されます。

この例では、ストレージについて説明しました。次は、ストレージの世界を離れて、次の話題であるコンピュートと、それに関する問題について説明します。彼らが作成しようとしているテスト環境を覚えていますか？テストが適切に動作するように必要な時に良好なパフォーマンスを提供しつつ、人々が非アクティブな時には大きなインスタンスに対して支払いを続ける必要がない方法を見つけなければなりません。

解決策は何でしょうか？ここではAurora Serverlessを使用できます。Aurora Serverlessは、通常のインスタンスと同じようにコンソールで選択する、必要に応じて自動的にスケーリングするオンデマンドのインスタンスサイズです。このACU（Aurora Capacity Unit）と呼ばれるメトリクスに基づいて制限を設定できます。最小サイズと最大サイズの範囲を指定すると、その範囲内で自動的に調整されます。使用したACUに対して秒単位で課金されるため、きめ細かい粒度が提供されます。これはテストワークロードに限定されず、本番環境でも完全に有効で、すでに多くの顧客が使用しています。

最近、Serverlessに関する2つの新しい変更を発表しました。最大256 ACUまでスケールアップできるようになり、これは以前の2倍の大きさです。また、完全にゼロまたはスリープモードまでスケールダウンでき、非アクティブ時には課金されません。コストの例を見てみましょう：先ほど説明したI/O最適化されていないテストのためのAurora標準では、多くのI/Oを実行していないため、I/O最適化については気にする必要がありません。この例では、10人の開発者のチームが100 GBのストレージを使用し、変更率は10%です。過去の負荷パターンから、1日の開発者シフト中、インスタンスはおよそ半分の時間がアイドル状態であることがわかっています。

これらのパラメータと8 ACUサイズのワークロードを使用して、コストを比較してみましょう。 R6g.Largeのプロビジョンドインスタンスでは約62ドルかかります。先ほど説明したパラメータを使用したServerlessの場合は38ドルで、38%の削減となります。 クローンの話に戻りますと、フルボリュームコピーを使用した場合は1000ギガバイトが必要ですが、クローンを使用すると変更率分のみの支払いで済むため、100ギガバイトしか必要ありません。これは90%の削減となり、I/O量は両方のシナリオで同じです。

では、どのような成果が得られたでしょうか？ストレージで90%のコスト削減を達成し、テストインスタンスにServerlessを使用することで、コンピューティングでも38%の削減を実現しました。 さらに、新機能によってゼロまでスケールダウンでき、必要に応じて256 ACUまでスケールアップできるため、テスターはより大きなワークロードにも対応できるようになりました。

Auroraのグローバル展開とLimitless Database：スケーラビリティの新たな地平

バックアップについて簡単に説明しましょう。Auroraには継続的バックアップが組み込まれています。 下部のストレージレイヤーからAmazon S3に継続的に書き込みを行っています。バックアップはデータベースインスタンスではなくストレージシステムによって処理されるため、パフォーマンスの計算に考慮する必要はありません。スケジュールされたメンテナンスウィンドウは不要で、 継続的に行われ、通常はアクティブなデータベースの数分以内の最新状態を維持します。

バックアップは増分方式で、 任意の時点でのリストアに必要なスペース量に基づいて課金されます。バックアップ保持期間内での完全なポイントインタイムリカバリを提供しており、保持期間は1日から35日まで設定できます。バックアップ保持期間を超えてデータを保持したい場合は、 Amazon RDSと同様にスナップショットを使用できます。バックアップ機能はRDSと非常によく似ているため、詳しい説明は省略させていただきます。

バックアップコストは様々な方法で管理できます。スナップショットエクスポートを使用してAmazon S3にデータを移動したり、論理ダンプを使用したり、 保持期間を調整したり、Vacuum操作によってボリュームサイズを削減したりできます。これらの方法はすべてAmazon RDSで提供されているものと同様で、 使用した分だけの支払いとなります。では、すべての側面における課題について考えてみましょう。

4番目の課題はグローバル展開に関するものです。左側には以前からあったRegion Aがあり、グローバルな耐障害性を実現するために、同じセットアップをRegion Bに複製しています。これを自分で構築することは可能ですが、すべてのソフトウェアを自分で書いて保守する必要があります。彼らはリージョン間のRead遅延を削減し、すべてのソフトウェアを自分で書くことなく、可能な限り一貫性を維持したいと考えています。要件は、低遅延のReadと複数リージョンに対する非線形のコストで、グローバルな耐障害性を実現することです。

私たちには、低RPOの災害復旧を提供するAurora Global Databaseがあります。適切に設定すれば、リージョン内での高速なローカルReadが可能で、Follow-the-sunの機能も実現できます。SydneyからUSを経由してEuropeへと移動するワークロードがある場合、Writerをそちらに切り替えることで、Read遅延を低く保つことができます。ここでは、Global Databaseがどのように高速なローカルReadを実現するかに焦点を当ててみましょう。開始時点では、左側に以前と同じクラスターがあります。もう一方にも複製することはできますが、マルチWriterの複雑さを避けるため、この側ではReadのみ可能です。

プライマリリージョンのストレージからReadし、セカンダリリージョンのストレージにWriteするAurora Global Databaseを設定し、Global Databaseがそれらの同期を保ちます。ここではRegion Bのグローバルセカンダリは1つだけですが、最大5つまで持つことができ、それぞれが複数のReplicaを内部に持つことができます。コストについては、Compute、ストレージ、複製するWrite I/O操作に対して支払い、その他のコスト要素は以前説明したものと同じですが、2つのリージョンにまたがることになります。

このセットアップにより、数百ミリ秒ではなく、一桁ミリ秒のローカルReadが可能になります。非線形コストのバランスを取るため、プライマリをセカンダリより大きくするなど、非対称なクラスターを作成することもできます。さらに、グローバルな災害復旧機能も備わっています。最後の課題として、当社は著しく成長しており、システムの限界に近づいています。128テラバイトのボリュームサイズ制限と、最大のR8g.48xlargeインスタンスがありますが、これらは大きいとはいえ無限ではありません。

彼らは128テラバイトを超えるストレージへのスケーリングと、過度なコストをかけることなく、単一のWriterを超えてWrite処理のスループットを効率的にスケーリングする必要があります。最近一般提供が開始されたPostgreSQL Limitless Databaseは、Shardingによる自動水平スケーリングでこれに対応します。Shard Keyを指定すると、システムはデータベースを複数の部分に分割し、データベースの負荷変動に応じてそのサイズと数を調整し、Aurora Capacity Unitsを使用したServerlessテクノロジーでコストをコントロールします。

私たちは、シンプルな単一データベースエンドポイントを維持しながら、書き込みのスケーリングを備えた分散型のServerlessデプロイメントを実現しました。使用した分だけ料金を支払えばよいのです。これまでの取り組みを振り返りますと、 Aurora I/O-Optimizedを使用することで28%のコスト削減を達成し、予測可能性も向上させました。 Optimized Read機能を活用して読み取りパフォーマンスを最大8倍に改善し、クローンを使用してストレージコストを90%削減し、テスト環境のコストの課題も解決しました。 さらに、ローカルでの低レイテンシー読み取りとグローバルな災害復旧のためにAurora Global Databaseを実装し、ペタバイト規模のボリュームと毎秒数百万の書き込みにスケールするPostgreSQL Limitless Databaseを導入しました。

今回の事例企業だけでなく、すべての企業に当てはまることですが、コストとパフォーマンスの最適化は相互に補完し合う取り組みであることをお示ししました。 AuroraとRDSは、Performance Insightsをはじめとする多くの共通ツールを備えており、用途に応じて最適なツールを選択できます。CloudWatch Database Insightsは、ボトルネックを特定する際の指針となります。Piniとわたしからのアドバイスですが、本日学んだことを活かして、コストとパフォーマンスの最適化に取り組んでください - 両方を同時に達成することは十分可能です。 本日はお時間をいただき、ありがとうございました。私たちはデータ駆動型の企業ですので、アンケートにぜひご回答ください。皆様からのフィードバックを今後のコンテンツ改善に活用させていただきます。

---

※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。