Amazon Aurora ストレージ - Amazon Aurora
Aurora ストレージの概要クラスターボリュームの内容Aurora クラスターストレージ設定ストレージのサイズを変更する方法データに対する請求

Amazon Aurora ストレージ

次に、Aurora ストレージサブシステムについて説明します。Aurora の分散型の共有ストレージアーキテクチャは、Aurora クラスターのパフォーマンス、スケーラビリティ、および信頼性に重要な影響を与えます。

Amazon Aurora ストレージの概要

Aurora のデータはクラスターボリュームに保存されます。これは、SSD (Solid State Drive) を使用する単一の仮想ボリュームです。クラスターボリュームは、単一の AWS リージョンの 3 つのアベイラビリティーゾーン間のデータのコピーで構成されます。データはアベイラビリティーゾーン間で自動的にレプリケートされるため、データ損失の可能性は低く、耐久性の高いは非常に高くなります。また、このレプリケーションにより、フェイルオーバー時のデータベースの可用性が高くなります。データのコピーは他のアベイラビリティーゾーンに既に存在するため、DB クラスター内の DB インスタンスに対するデータ要求は継続して処理されます。レプリケーションの数は、クラスター内の DB インスタンスの数とは関係ありません。

Aurora は、非永続的な一時ファイル用に、分離したローカルストレージを使用します。これには、クエリ処理中の大きなデータセットのソートや、インデックスの作成などの目的に使用するファイルが含まれます。詳細については、Aurora MySQL 用の一時ストレージの制限およびAurora PostgreSQL 用の一時ストレージの制限を参照してください。

クラスターボリュームの内容

Aurora クラスターボリュームには、すべてのユーザーデータ、スキーマオブジェクト、および内部メタデータ (システムテーブルやバイナリログなど) が入ります。例えば、Aurora は Aurora クラスター内のすべてのテーブル、インデックス、バイナリラージオブジェクト (BLOB)、ストアドプロシージャなどをクラスターボリュームに保存します。

Aurora の共有ストレージアーキテクチャでは、クラスター内の DB インスタンスとは別個にデータが処理されます。例えば、Aurora はテーブルデータの新しいコピーを作成しないため、DB インスタンスをすばやく追加できます。代わりに、DB インスタンスから、すべてのデータが既に含まれている共有ボリュームに接続します。クラスターから DB インスタンスを削除しても、元になるデータはクラスターから削除されません。クラスター全体を削除した場合にのみ、Aurora でデータが削除されます。

Amazon Aurora DB  クラスターのストレージ設定

Amazon Aurora には、2 つの DB クラスターストレージ設定があります:

  • Aurora I/O-Optimized— I/O 集約型のアプリケーションの価格性能と予測可能性が向上しました。お支払いいただくのは DB クラスターの使用量とストレージに対してのみで、読み取りと書き込み I/O オペレーションに追加料金はかかりません。

    Aurora I/O-Optimized は、I/O 支出が Aurora データベースの総支出の 25% 以上である場合に最適な選択肢です。

    Aurora I/O-Optimized クラスター設定をサポートする DB エンジンバージョンの DB クラスターを作成または変更する場合は、Aurora I/O-Optimized を選択できます。Aurora I/O-Optimized から Aurora Standard にはいつでも切り替えることができます。

  • Aurora Standard — I/ O使用量が中程度の多くのアプリケーション向けの費用対効果の高い価格設定。DB クラスターの使用量とストレージに加えて、I/O オペレーションの 100 万件のリクエストごとに標準料金をお支払いいただきます。

    Aurora Standard は、I/O 支出が Aurora データベースの総支出の 25% 未満である場合に最適な選択肢です。

    30 日に 1 回 Aurora Standard から Aurora I/O-Optimized に切り替えることができます。Aurora Standard から Aurora I/O-Optimized、または Aurora I/O-Optimized から Aurora Standard に切り替えてもダウンタイムはありません。

AWS リージョン に関する詳細とバージョンのサポートについては、「クラスターストレージ構成でサポートされているリージョンと Aurora DB エンジン」を参照してください。

Amazon Aurora ストレージ設定の料金情報の詳細については、「Amazon Aurora の料金」を参照してください。

DB クラスターを作成する際のストレージ構成の選択については、「DB クラスターの作成」を参照してください。DB クラスターのストレージ構成の変更については、「Amazon Aurora の設定」を参照してください。

Aurora ストレージのサイズを自動的に変更する方法

Aurora クラスターボリュームは、データベースのデータ量が増えるにつれて自動的に増加します。Aurora クラスターボリュームの最大サイズは、DB エンジンのバージョンに応じて、128 テビバイト (TiB) または 64 TiB のどちらかです。特定のバージョンの最大サイズは、「Amazon Aurora サイズ制限」でご確認ください。この自動ストレージスケーリングは、高性能で高度に分散されたストレージサブシステムと組み合わされています。これにより、信頼性と高可用性を主目的とする重要なエンタープライズデータには Aurora が適切な選択となります。

ボリュームステータスを確認するには、Aurora MySQL DB クラスターのボリュームステータスの表示 または Aurora PostgreSQL DB クラスターのボリュームステータスの表示 をご覧ください。ストレージコストと他の優先順位のバランスをとる方法について、ストレージのスケーリング が Amazon Aurora メトリクス AuroraVolumeBytesLeftTotal および VolumeBytesUsed を CloudWatch でモニタリングする方法について説明しています。

Aurora のデータを削除すると、そのデータに割り当てられていた領域が解放されます。データの削除の例としては、テーブルの削除や切り捨てなどがあります。このストレージ使用量の自動削減により、ストレージ料金を最小限に抑えることができます。

注記

ここで説明するストレージ制限と動的なサイズ変更の動作は、クラスターボリュームに保存されている永続テーブルやその他のデータに適用されます。

Aurora PostgreSQL の場合、臨時テーブルデータがローカル DB インスタンスに保存されます。

Aurora MySQL バージョン 2 では、一時テーブルデータは、デフォルトで、ライターインスタンスの場合はクラスターボリュームに、リーダーインスタンスの場合はローカルストレージに保存されます。詳細については、「オンディスク一時テーブルのストレージエンジン」を参照してください。

Aurora MySQL バージョン 3 では、一時テーブルデータはローカル DB インスタンスまたはクラスターボリュームに保存されます。詳細については、「Aurora MySQL バージョン 3 での新しい一時テーブルの動作」を参照してください。

ローカルストレージでの一時テーブルの最大サイズは、DB インスタンスの最大ローカルストレージサイズによって制限されます。ローカルストレージのサイズは、使用するインスタンスクラスによって異なります。詳細については、Aurora MySQL 用の一時ストレージの制限およびAurora PostgreSQL 用の一時ストレージの制限を参照してください。

クラスターボリュームの最大サイズやデータ削除時の自動サイズ変更など、一部のストレージ機能は、クラスターの Aurora バージョンによって異なります。詳細については、「ストレージのスケーリング」を参照してください。また、ストレージの問題を回避する方法と、クラスター内の割り当てられたストレージと空き領域をモニタリングする方法についても確認できます。

Aurora データストレージに対する請求方法

Aurora クラスターボリュームは 128 tebibytes (TiB) まで拡張できますが、請求対象となるのは Aurora クラスターボリュームで使用した分の領域のみです。Aurora の以前のバージョンでは、データを削除したときに解放された領域をクラスターボリュームで再利用できましたが、割り当てられたストレージ領域が縮小されることはありませんでした。現在では、テーブルやデータベースの削除などによって Aurora データが削除されると、割り当てられた領域全体が相応に減少します。したがって、不要になったテーブル、インデックス、データベースなどを削除することで、ストレージ料金を削減できます。

ヒント

動的サイズ変更機能のない以前のバージョンの場合、クラスターのストレージ使用量をリセットするには、論理的なダンプを実行して新しいクラスターに復元する必要がありました。このオペレーションは、データが大量にある場合、長い時間がかかることがあります。このような状況が発生した場合は、クラスターを、動的なボリュームのサイズ変更をサポートするバージョンにアップグレードすることを検討してください。

動的なサイズ変更をサポートする Aurora のバージョンと、クラスターのストレージ使用量をモニタリングしてストレージ料金を最小限に抑える方法については、「ストレージのスケーリング」を参照してください。Aurora バックアップストレージの請求については、「Amazon Aurora バックアップストレージの使用状況を確認する」を参照してください。Aurora データストレージの料金情報については、「Amazon RDS for Aurora の料金」を参照してください。