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 の料金」を参照してください。

Amazon Aurora の信頼性

Aurora は、信頼性、耐久性の高い、および耐障害性を持つように設計されています。Aurora DB クラスターは、Aurora レプリカの追加や複数のアベイラビリティーゾーンへの配置などを行うことで可用性を向上させるように設計できます。さらに Aurora には、信頼できるデータベースソリューションとして使用できるさまざまな自動機能があります。

ストレージの自動修復

Aurora では、データの複数のコピーを 3 つのアベイラビリティーゾーンに保持するため、ディスク障害によってデータが失われる可能性が最小限に抑えられます。Aurora は、クラスターボリュームを構成するディスクボリュームの障害を自動的に検出します。ディスクボリュームのセグメントで障害が発生すると、Aurora はすぐにそのセグメントを修復します。Aurora はディスクセグメントを修復するときに、クラスターボリュームを構成する他のボリューム内のデータを使用して、修復されるセグメントのデータが最新であるようにします。その結果、Aurora ではデータ損失が回避され、ディスク障害から回復するためのポイントインタイム復元を実行する必要性が低減します。

存続できるページキャッシュ

Aurora では、各 DB インスタンスのページキャッシュはデータベースとは別のプロセスで管理されるため、ページキャッシュはデータベースとは無関係に存続できます。(ページキャッシュは Aurora MySQL では InnoDB バッファプール、Aurora PostgreSQL ではバッファキャッシュとも呼ばれます。)

まれにデータベース障害が発生した場合でも、ページキャッシュはメモリに残るため、データベースの起動時に現在のデータページがページキャッシュに「ウォームアップ」されます。これにより、ページキャッシュを「ウォームアップ」するために読み取り I/O 操作を実行するための初期クエリの必要性がバイパスされ、パフォーマンスが向上します。

Aurora MySQL では、再起動およびフェイルオーバー時のページキャッシュの動作は次のとおりです。

  • 2.10 より前のバージョン — ライター DB インスタンスが再起動すると、ライターインスタンスのページキャッシュは存続しますが、リーダー DB インスタンスのページキャッシュは失われます。

  • バージョン 2.10 以降 – リーダーインスタンスを再起動せずに、ライターインスタンスを再起動できます。

    • ライターインスタンスの再起動時にリーダーインスタンスが再起動しなくても、ページキャッシュは失われません。

    • ライターインスタンスの再起動時にリーダーインスタンスが再起動した場合、ページキャッシュが失われます。

  • リーダーインスタンスが再起動すると、ライターインスタンスとリーダーインスタンスのページキャッシュが両方とも存続します。

  • DB クラスターがフェイルオーバーした場合、その効果はライターインスタンスが再起動したときと似ています。新しいライターインスタンス（以前のリーダーインスタンス）ではページキャッシュは存続しますが、リーダーインスタンス（以前のライターインスタンス）ではページキャッシュは存続しません。

Aurora PostgreSQL の場合、クラスターキャッシュ管理を使用して、フェイルオーバー後にライターインスタンスになる指定されたリーダーインスタンスのページキャッシュを保持できます。詳細については、「Aurora PostgreSQL のクラスターキャッシュ管理によるフェイルオーバー後の高速リカバリ」を参照してください。

計画外の再起動からの復旧

Aurora は、計画外の再起動からほぼ瞬時に復旧し、バイナリログなしでアプリケーションデータを提供し続けるように設計されています。Aurora は、パラレルスレッドで非同期に復旧します。これにより、計画外の再起動の直後にデータベースを開き、使用できるようにします。

詳細については、「Aurora DB クラスターの耐障害性」および「データベースの再起動時間を短縮するための最適化」を参照してください。

以下に示しているのは、Aurora MySQL のバイナリログ記録と計画外の再起動からの復旧に関する考慮事項です。

  • Aurora でバイナリログ記録を有効にすると、計画外の再起動後の復旧時間に直接影響を与えます。これは、DB インスタンスで強制的にバイナリログ復旧が実行されるためです。

  • 使用するバイナリログ記録のタイプは、ログ記録のサイズと効率に影響を与えます。データベースアクティビティの量が同じでも、バイナリログの形式によって記録される情報の量が異なります。binlog_format パラメータの以下の設定により、ログデータの量が異なることになります。

    • ROW - ログデータの量が最も多い

    • STATEMENT - ログデータの量が最も少ない

    • MIXED - ログデータの量が中程度。通常、データ整合性とパフォーマンスのバランスが最も良くなります

    バイナリログデータの量は復旧時間に影響を与えます。バイナリログに記録されているデータが多いほど、DB インスタンスが復旧中に処理するデータが多くなり、復旧時間が長くなります。

  • バイナリログ記録を使用して計算オーバーヘッドを削減し、復元時間を短縮するために、拡張バイナリログを使用できます。拡張バイナリログにより、データベースの復元時間が最大 99% 向上します。詳細については、「拡張バイナリログ記録の設定」を参照してください。

  • Aurora では、DB クラスター内でデータをレプリケートしたり、ポイントインタイムリカバリ (PITR) を実行したりするために、バイナリログは不要です。

  • 外部レプリケーション (または外部バイナリログストリーミング) にバイナリログが不要な場合は、binlog_format パラメータを OFF に設定して、バイナリログ記録を無効にすることをお勧めします。これにより、復旧時間が短くなります。

Aurora バイナリログ記録とレプリケーションの詳細については、「Amazon Aurora でのレプリケーション」を参照してください。さまざまな MySQL レプリケーションタイプの影響の詳細については、MySQL ドキュメントの「ステートメントベースおよび行ベースレプリケーションのメリットとデメリット」を参照してください。