# Amazon Aurora ストレージ
次に、Aurora ストレージサブシステムについて説明します。Aurora の分散型の共有ストレージアーキテクチャは、Aurora クラスターのパフォーマンス、スケーラビリティ、および信頼性に重要な影響を与えます。
**Topics**
+ [Amazon Aurora ストレージの概要](#Aurora.Overview.Storage)
+ [クラスターボリュームの内容](#aurora-storage-contents)
+ [Amazon Aurora DB クラスターのストレージ設定](#aurora-storage-type)
+ [Aurora ストレージのサイズを自動的に変更する方法](#aurora-storage-growth)
+ [Aurora データストレージに対する請求方法](#aurora-storage-data-billing)
## Amazon Aurora ストレージの概要
Aurora のデータは*クラスターボリューム*に保存されます。これは、SSD (Solid State Drive) を使用する単一の仮想ボリュームです。クラスターボリュームは、単一の AWS リージョンの 3 つのアベイラビリティーゾーン間のデータのコピーで構成されます。データはアベイラビリティーゾーン間で自動的にレプリケートされるため、データ損失の可能性は低く、耐久性の高いは非常に高くなります。また、このレプリケーションにより、フェイルオーバー時のデータベースの可用性が高くなります。データのコピーは他のアベイラビリティーゾーンに既に存在するため、DB クラスター内の DB インスタンスに対するデータ要求は継続して処理されます。レプリケーションの数は、クラスター内の DB インスタンスの数とは関係ありません。
Aurora は、非永続的な一時ファイル用に、分離したローカルストレージを使用します。これには、クエリ処理中の大きなデータセットのソートや、インデックスの作成などの目的に使用するファイルが含まれます。詳細については、「[Aurora MySQL 用の一時ストレージの制限一時ストレージの制限](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.TempStorage)」および「[Aurora PostgreSQL 用の一時ストレージの制限一時ストレージの制限](AuroraPostgreSQL.Managing.md#AuroraPostgreSQL.Managing.TempStorage)」を参照してください。
## クラスターボリュームの内容
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 に切り替えることができます。非 NVMe ベースの DB インスタンスで Aurora Standard と Aurora I/O-Optimized のストレージオプションを切り替える場合、ダウンタイムはありません。ただし、NVMe ベースの DB インスタンスの場合、Aurora I/O-Optimized と Aurora Standard ストレージオプションの切り替えではデータベースエンジンの再起動が必要なため、短時間のダウンタイムが発生する可能性があります。
AWS リージョン に関する詳細とバージョンのサポートについては、「[クラスターストレージ構成でサポートされているリージョンと Aurora DB エンジン](Concepts.Aurora_Fea_Regions_DB-eng.Feature.storage-type.md)」を参照してください。
Amazon Aurora ストレージ設定の料金情報の詳細については、「[Amazon Aurora の料金](https://aws.amazon.com/rds/aurora/pricing/)」を参照してください。
DB クラスターを作成する際のストレージ構成の選択については、「[DB クラスターの作成](Aurora.CreateInstance.md#Aurora.CreateInstance.Creating)」を参照してください。DB クラスターのストレージ構成の変更については、「[Amazon Aurora の設定](Aurora.Modifying.md#Aurora.Modifying.Settings)」を参照してください。
## Aurora ストレージのサイズを自動的に変更する方法
Aurora クラスターボリュームは、データベースのデータ量が増えるにつれて自動的に増加します。Aurora クラスターボリュームの各エンジンバージョンの最大サイズについては、「[Amazon Aurora サイズ制限](CHAP_Limits.md#RDS_Limits.FileSize.Aurora)」を参照してください。この自動ストレージスケーリングは、高性能で高度に分散されたストレージサブシステムと組み合わされています。これにより、信頼性と高可用性を主目的とする重要なエンタープライズデータには Aurora が適切な選択となります。
ボリュームステータスを確認するには、[Aurora MySQL DB クラスターのボリュームステータスの表示](AuroraMySQL.Managing.VolumeStatus.md) または [Aurora PostgreSQL DB クラスターのボリュームステータスの表示](AuroraPostgreSQL.Managing.VolumeStatus.md) をご覧ください。ストレージコストと他の優先順位のバランスをとる方法について、[ストレージのスケーリング](Aurora.Managing.Performance.md#Aurora.Managing.Performance.StorageScaling) が Amazon Aurora メトリクス `AuroraVolumeBytesLeftTotal` および `VolumeBytesUsed` を CloudWatch でモニタリングする方法について説明しています。
Aurora のデータを削除すると、そのデータに割り当てられていた領域が解放されます。データの削除の例としては、テーブルの削除や切り捨てなどがあります。このストレージ使用量の自動削減により、ストレージ料金を最小限に抑えることができます。
**注記**
ここで説明するストレージ制限と動的なサイズ変更の動作は、クラスターボリュームに保存されている永続テーブルやその他のデータに適用されます。
Aurora PostgreSQL の場合、臨時テーブルデータがローカル DB インスタンスに保存されます。
Aurora MySQL バージョン 2 では、一時テーブルデータは、デフォルトで、ライターインスタンスの場合はクラスターボリュームに、リーダーインスタンスの場合はローカルストレージに保存されます。詳細については、「[オンディスク一時テーブルのストレージエンジン](AuroraMySQL.CompareMySQL57.md#AuroraMySQL.StorageEngine57)」を参照してください。
Aurora MySQL バージョン 3 では、一時テーブルデータはローカル DB インスタンスまたはクラスターボリュームに保存されます。詳細については、「[Aurora MySQL バージョン 3 での新しい一時テーブルの動作](ams3-temptable-behavior.md)」を参照してください。
ローカルストレージでの一時テーブルの最大サイズは、DB インスタンスの最大ローカルストレージサイズによって制限されます。ローカルストレージのサイズは、使用するインスタンスクラスによって異なります。詳細については、「[Aurora MySQL 用の一時ストレージの制限一時ストレージの制限](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.TempStorage)」および「[Aurora PostgreSQL 用の一時ストレージの制限一時ストレージの制限](AuroraPostgreSQL.Managing.md#AuroraPostgreSQL.Managing.TempStorage)」を参照してください。
クラスターボリュームの最大サイズやデータ削除時の自動サイズ変更など、一部のストレージ機能は、クラスターの Aurora バージョンによって異なります。詳細については、「[ストレージのスケーリング](Aurora.Managing.Performance.md#Aurora.Managing.Performance.StorageScaling)」を参照してください。また、ストレージの問題を回避する方法と、クラスター内の割り当てられたストレージと空き領域をモニタリングする方法についても確認できます。
## Aurora データストレージに対する請求方法
特定のエンジンバージョンの Aurora クラスターボリュームは 256 tebibytes (TiB) まで拡張できますが、請求対象となるのは Aurora クラスターボリュームで使用した分の領域のみです。Aurora の以前のバージョンでは、データを削除したときに解放された領域をクラスターボリュームで再利用できましたが、割り当てられたストレージ領域が縮小されることはありませんでした。現在では、テーブルやデータベースの削除などによって Aurora データが削除されると、割り当てられた領域全体が相応に減少します。したがって、不要になったテーブル、インデックス、データベースなどを削除することで、ストレージ料金を削減できます。
**ヒント**
動的サイズ変更機能のない以前のバージョンの場合、クラスターのストレージ使用量をリセットするには、論理的なダンプを実行して新しいクラスターに復元する必要がありました。このオペレーションは、データが大量にある場合、長い時間がかかることがあります。このような状況が発生した場合は、クラスターを、動的なボリュームのサイズ変更をサポートするバージョンにアップグレードすることを検討してください。
動的なサイズ変更をサポートする Aurora のバージョンと、クラスターのストレージ使用量をモニタリングしてストレージ料金を最小限に抑える方法については、「[ストレージのスケーリング](Aurora.Managing.Performance.md#Aurora.Managing.Performance.StorageScaling)」を参照してください。Aurora バックアップストレージの請求については、「[Amazon Aurora バックアップストレージの使用状況を確認する](aurora-storage-backup.md)」を参照してください。Aurora データストレージの料金情報については、「[Amazon RDS for Aurora の料金](https://aws.amazon.com/rds/aurora/pricing)」を参照してください。