Amazon Aurora
Aurora のユーザーガイド (API バージョン 2014-10-31)

Amazon Aurora ストレージと信頼性

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

Aurora ストレージの概要

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

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

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

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

Aurora ストレージの増大

Aurora クラスターボリュームは、データベースのデータ量が増えるにつれて自動的に増加します。Aurora クラスターボリュームは、最大 64 テビバイト (TiB) のサイズまで増やすことができます。テーブルサイズの上限はクラスターボリュームのサイズです。つまり、Aurora DB クラスター内のテーブルの最大テーブルサイズは 64 TiB です。

Aurora は、この自動的なストレージのスケーリングに加えて高パフォーマンスと高分散型ストレージサブシステムを兼ね備えているため、信頼性と高可用性が主に要求される重要なエンタープライズデータに最適な選択となります。これらの優先事項とストレージコストのバランスを取る方法については、以下のセクションを参照してください。

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

Aurora クラスターボリュームは 64 TiB まで拡大できますが、Aurora クラスターボリュームで使用する領域に対してのみ料金が請求されます。テーブルまたはパーティションの削除などによって Aurora データが削除されても、全体の割り当て領域は同じままです。空き領域は、将来のデータボリューム増加時に自動的に再利用されます。

注記

ストレージコストは「"高いウォーターマーク"」 (任意の時点で Aurora クラスター用に割り当てられた最大量) に基づいているため、大量の一時情報を作成したり、古い不要データの削除前に新規データを大量にロードする ETL 実行を避けることによってコストを管理できます。

Aurora クラスターからデータを削除したことによって大量の割り当て済み未使用領域が発生した場合に、高いウォーターマークをリセットするには、mysqldump などのツールを使用して論理データダンプを作成し、新しいクラスターに復元する必要があります。スナップショットを作成および復元しても、割り当てられたストレージは削減されません。これは、基になるストレージの物理的なレイアウトが、復元されたスナップショットでも変更されないためです。

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 のドキュメントの「ステートメントベースおよび行ベースのレプリケーションの利点と欠点」を参照してください。