Amazon Aurora ストレージと信頼性 - Amazon Aurora

Amazon Aurora ストレージと信頼性

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

Aurora ストレージの概要

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

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

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

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

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

Aurora クラスターボリュームは、データベースのデータ量が増えるにつれて自動的に増加します。Aurora クラスターボリュームは、最大 128 tebibytes (TiB) のサイズまで増やすことができます。この自動ストレージスケーリングは、高性能で高度に分散されたストレージサブシステムと組み合わされています。これにより、信頼性と高可用性を主目的とする重要なエンタープライズデータには Aurora が適切な選択となります。

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

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

注記

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

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

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

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

ヒント

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

Aurora データストレージの料金情報については、「Amazon RDS for Aurora の料金」を参照してください。

クラスターのストレージ使用量をモニタリングしてストレージ料金を最小限に抑える方法については、「ストレージのスケーリング」を参照してください。Aurora データストレージの料金情報については、「Amazon RDS for Aurora の料金」を参照してください。

Amazon Aurora の信頼性

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

ストレージの自動修復

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

存続できるキャッシュのウォームアップ

Aurora では、データベースがシャットダウン後に起動したとき、または障害発生後に再起動したときに、バッファープールキャッシュを "ウォームアップ" します。つまり、Aurora では、メモリ内ページキャッシュに保存された既知の一般的なクエリのページを使用してバッファープールを事前にロードします。これにより、通常のデータベースの使用からバッファープールを "ウォームアップ" する必要性をバイパスすることでパフォーマンスが向上します。

Aurora ページキャッシュはデータベースとは別のプロセスで管理されるため、ページキャッシュはデータベースとは無関係に存続できます。データベースに障害が発生した場合でも、ページキャッシュはメモリに残るため、バッファプールはデータベースの起動時に最新の状態にウォームアップされます。

クラッシュ回復

Aurora は、クラッシュからほぼ瞬時に回復し、バイナリログなしでアプリケーションデータを提供し続けるように設計されています。Aurora は、クラッシュの直後にデータベースを開き、使用できるようにするためにクラッシュ回復を並列スレッドで非同期に実行します。

クラッシュ復旧の詳細については、「Aurora DB クラスターの耐障害性」を参照してください。

以下に示しているのは、Aurora MySQL のバイナリログ記録とクラッシュ復旧に関する考慮事項です。

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

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

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

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

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

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

  • Aurora では、DB クラスター内でデータをレプリケートしたり、特定時点への復元 (PITR) を実行したりするために、バイナリログは不要です。

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

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