Amazon RDS

Amazon RDS の特徴

Amazon Relational Database Service (Amazon RDS) を使用すると、クラウド内でリレーショナルデータベースを簡単に設定、運用、およびスケールできます。このサービスは、手間のかかるデータベースの管理タスクをお客様の代わりに行いながら、コスト効率がよく、サイズ変更が可能な容量を提供します。これによってお客様は自身のアプリケーション開発やビジネスに集中できます。

Amazon RDS の管理の詳細

AWS マネジメントコンソール、Amazon RDS コマンドラインインターフェイス、またはシンプルな API 呼び出しを使用して、本稼働に対応したリレーショナルデータベースの機能に数分でアクセスできます。

Amazon RDS データベースインスタンスは、選択したエンジンとクラスに適したパラメータと設定で、あらかじめ設定されています。数分のうちにデータベースインスタンスを起動し、アプリケーションを接続できます。DB パラメータグループではデータベースの厳密な管理および微調整が可能です。

モニタリングおよびメトリクス

Amazon RDS はデータベースインスタンスに Amazon CloudWatch のメトリクスを提供します。追加料金はかかりません。AWS マネジメントコンソールを使用して、コンピューティング/メモリ/ストレージキャパシティ利用率、I/O アクティビティ、 インスタンス接続など、主要オペレーションメトリクスを表示できます。RDS では、50 個を超える CPU、メモリ、ファイル システム、ディスク I/O のメトリックスへのアクセスを提供する拡張モニタリングも提供されます。

ソフトウェアの自動パッチ適用

Amazon RDS では、デプロイメントが運用されているリレーショナルデータベースソフトウェアに最新のパッチが適用され、常に最新の状態が維持されています。データベースインスタンスにパッチを適用している場合には、オプションのコントロールを使用できます。

DB イベントの通知

Amazon RDS は Amazon SNS を使用して、メールまたは SMS テキストメッセージでデータベースイベントを通知します。AWS マネジメントコンソールまたは Amazon RDS API を使用して、データベースインスタンスに関連する 40 種類以上ものデータベースイベントを登録できます。

Amazon RDS の可用性と耐久性の詳細

自動バックアップ

既定でオンになっている Amazon RDS の自動バックアップ機能により、データベースインスタンスのポイントインタイムリカバリが可能です。Amazon RDS は、お客様のデータベースとトランザクションログをバックアップし、ユーザーが指定した保持期間両者を格納します。これによって、直近で 5 分前まで、保持期間内の任意の時点にデータベースインスタンスを復元できます。自動バックアップの保持期間は、最大 35 日間まで設定できます。

データベースのスナップショット

データベースのスナップショットはお客様が開始して Amazon S3 に保存するバックアップで、お客様が明示的に削除するまで保持されます。ご希望の際にいつでも、データベーススナップショットから新しいインスタンスを作成できます。データベーススナップショットはフルバックアップとして動作しますが、ストレージ使用の増加分に対してのみ課金されます。

データベースのスナップショットのユースケースとしては、（AZ ではなく）リージョンを超えるデータベースのレプリケーションの作成、本番環境から開発環境への一時的なレプリケーションの作成などが考えられます。

自動バックアップとスナップショットの違い

自動バックアップは、Amazon RDS が 1 日 1 回自動的に、任意のバックアップウィンドウ（通常、ロードアベレージが低い時間やバッチ処理の時間など）に完全なスナップショットを作成するとともに、DB インスタンスに対する更新を作成中のトランザクションログ（Binlog：バイナリーログ：デフォルトで 5 分まで）を捕捉します。保存期間は、最大で 35 日まで指定できます。

リストアには 2 種類あり、任意のスナップショットからリストアするか、指定した時刻（Point-In-Time-Recovery）の状態にリストアします。リストアによって新しいエンドポイントが割り当てられた DB インスタンスが生成されるので、必要に応じてスナップショットから現在までのトランザクションログを適用し、エンドポイントを付け替えて、必要なくなった元の DB インスタンスは削除します。DB インスタンスを削除すると、自動バックアップが保存していた過去のスナップショットは削除されます。

スナップショットは、ユーザー手動で任意の時点のデータベースのスナップショットを保存します。スナップショットの保存期間は特に制限されておらず、ユーザーが明示的に削除しない限り Amazon S3 に保存されます。スナップショットのユースケースは、自動バックアップとは異なり、障害対策といよりは、データベースのレプリケーションの作成です。

マルチ AZ 配置

Amazon RDS マルチ AZ 配置は、データベースインスタンスの拡張された可用性と持続性を提供し、運用データベース作業負荷に自然に適合させます。Multi-AZ データベースインスタンスをプロビジョニングすると、Amazon RDS は異なるアベイラビリティーゾーン (AZ) のスタンバイインスタンスにデータを複製します。

Amazon RDS マルチ AZ 配置は、データベース（DB）インスタンスの拡張された可用性と持続性を提供し、運用データベース作業負荷に自然に適合させます。

Multi-AZ DB インスタンスをプロビジョニングすると、Amazon RDS はプライマリ DB インスタンスを自動的に作成するのと同時に、異なるアベイラビリティーゾーン (AZ) にあるスタンバイインスタンスにデータを複製します。各アベイラビリティーゾーンは、物理的にはっきりと独立したインフラストラクチャ上で稼動しています。また高い信頼性を保つように設計されています。

インフラストラクチャ障害の場合（インスタンスハードウェア障害、ストレージ障害、ネットワーク破壊など）、Amazon RDS はスタンバイに自動的にフェイルオーバーするので、フェイルオーバーするとすぐにデータベースの動作を再開できます。フェイルオーバー後も DB インスタンスのエンドポイントは変わらないため、お客様のアプリケーションは、手動で管理の介入を行うことなくデータベースオペレーションを再開できます。

• Amazon Aurora 以外のデータベースのレプリカのマルチ AZ 配置

• Amazon Aurora のデータベースのレプリカのマルチ AZ 配置

• 耐久性の向上

MySQL、MariaDB、Oracle、および PostgreSQL エンジンのマルチ AZ 配置は、同期物理レプリケーションを活用して、スタンバイしているデータをプライマリに合わせて最新の状態に維持します。SQL Server エンジンのマルチ AZ 配置は、同期論理レプリケーションを使用し、SQL Server ネイティブのミラーリングテクノロジーを採用して、同じ結果を達成しています。両方のアプローチによって、DB インスタンスの障害が発生したときや、アベイラビリティーゾーンが利用できなくなったような場合でも、データの安全が守られます。

マルチ AZ 配置でプライマリのストレージボリュームに障害が発生すると、Amazon RDS は最新のスタンバイへのフェイルオーバーを自動的に開始します。これをシングル AZ 配置と比較します。Single-AZ データベースに障害が発生すると、ユーザーが開始するポイントインタイム復元操作が必要になります。この操作が完了するには数時間かかる可能性があります。また、最新の復元可能な時刻（一般的には直近 5 分以内）後に発生したデータの更新は利用できません。

Amazon Aurora は耐久性の高い、SSD タイプの、データベースワークロード専用仮想ストレージレイヤーです。Amazon Aurora では、ボリュームを 3 つのアベイラビリティゾーンへ 6 つの方法で自動的に複製します。Amazon Aurora ストレージは耐障害性を備え、最大 2 つまでのデータのコピー損失をデータベースの書き込み能力に影響せずに透過的に処理し、最大 3 つまでのコピー損失を読み込み能力に影響せずに処理します。また、Amazon Aurora ストレージは自己修復機能を備えています。データブロックおよびディスクはエラー検出のために継続的にスキャンされ、自動的に置き換えられます。

• 可用性の向上

データベース可用性の向上も、Multi-AZ 配備を運用するときのメリットの 1 つです。アベイラビリティーゾーンまたは DB インスタンスの障害が発生した場合、可用性への影響が現れるのは、自動フェイルオーバーが完了するまでの間のみで、Amazon Aurora の場合 1 分間以内 (Maria DB Connector/J を使用する場合わずか 30 秒)、その他のデータベースエンジンでは 1～2 分間です。

マルチ AZ 配置の可用性は、計画されたメンテナンスとバックアップにも役立ちます。OS のパッチ処理または DB インスタンスの拡張のようなシステムアップグレードの場合、このような処理は、まずスタンバイに適用されてから、自動フェイルオーバーが行われます。したがって、可用性への影響が現れるのは自動フェイルオーバーを完了するのに必要な時間までとなります。

シングル AZ 配置とは異なり、MySQL、Oracle、および PostgreSQL エンジンのマルチ AZ 配置のバックアップ中は、スタンバイからバックアップが実行されるため、プライマリの I/O アクティビティは停止しません。ただし、Multi-AZ 配備のバックアップ中に、数分間、レイテンシーが増加する可能性があります。

Amazon Aurora デプロイでのインスタンスの障害に対して、Amazon RDS は RDS Multi-AZ テクノロジーを使用して、3 つのアベイラビリティーゾーンのいずれかに作成された Amazon Aurora レプリカの 1 つ（最大 15 個まで）にフェイルオーバーを自動化します。Amazon Aurora レプリカがプロビジョニングされていない場合、障害時には、Amazon RDS は新しい Amazon Aurora DB インスタンスの作成を自動的に試みます。

リードレプリカ

読み込み負荷の高いデータベースワークロードに単一 DB インスタンスの能力が対応しきれない場合にキャパシティーの制約を超えてスケーリングできるように、Amazon RDS にはリードレプリカが用意されています。AWS マネジメントコンソール、RDS API、AWS コマンドラインインターフェイスを使うと、与えられたソース DB インスタンスのリードレプリカを作成できます。リードレプリカを作成すると、データベースがソース DB インスタンスを更新して、リードレプリカにプロパゲートされます。1 つのソース DB インスタンスに対して複数のリードレプリカを作成して、アプリケーションの読み込みトラフィックをこれらのレプリカに分散させます。

リードレプリカは、Amazon RDS for MySQL および PostgreSQL でサポートされています。Multi-AZ 配置とは異なり、これらのエンジンのリードレプリカは、各エンジンに組み込まれているレプリケーションテクノロジーを使いますが、これには、その長所と制限が反映されます。特に、ソース DB インスタンスに更新が発生した後にリードレプリカにも更新が適用されます（「非同期」レプリケーション）。つまり、レプリケーションに大幅な遅延が生じます。つまり、スタンダード（Multi-AZ でない）ソース DB インスタンスに対する最新のデータベース更新は、ソース DB インスタンスで計画外の停止が発生した場合に、対応するリードレプリカには存在しなくなる可能性があります。そのような場合、リードレプリカは、Multi-AZ 配備が提供するものと同じデータ耐久性を提供できません。リードレプリカによって読み取りの可用性は高まりますが、書き込みの可用性を提供するよう設計されたものではありません。

Multi-AZ 配備とリードレプリカを組み合わせると、それぞれの特長の相乗効果が得られます。与えられた Multi-AZ 配備がお客様のリードレプリカのソース DB インスタンスであることを指定するだけです。この方法により、Multi-AZ 配備のデータ耐久性と可用性、およびリードレプリカの読込み能力の拡大という両面の利点を得ることができます。

ホストの自動交換

Amazon RDS では、ハードウェア障害が発生した場合、デプロイメントが運用されているコンピューティングインスタンスが自動的に交換されます。

Amazon RDS のセキュリティーの詳細

保存中と移動中の暗号化

Amazon RDS では、AWS Key Management Service (KMS) を介して管理するキーを使って、データベースを暗号化できるようになりました。Amazon RDS 暗号化を使用して実行するデータベースインスタンスでは、基盤となるストレージに保管されるデータが、自動バックアップ、リードレプリカ、スナップショットとして暗号化されます。

Amazon RDS は、SQL Server および Oracle の Transparent Data Encryption をサポートします。Oracle の Transparent Data Encryption は、AWS CloudHSM と統合されています。これにより、AWS クラウド内のシングルテナントの Hardware Security Module (HSM) アプライアンスで安全に暗号化キーを生成、保管、管理できます。

Amazon RDS は、通信中のデータを保護する SSL の使用に対応しています。

ネットワークの隔離

• VPC 内の DB インスタンスに同じ VPC 内の EC2 インスタンスがアクセスするシナリオ

AWS では、データベースインスタンスを VPC で実行することを推奨します。VPC 内の Amazon RDS インスタンスの一般的な用途は、同じ VPC 内の EC2 インスタンスで実行されるアプリケーションサーバとデータを共有することです。これは、AWS Elastic Beanstalk を使用して同じ VPC 内で EC2 インスタンスおよび DB インスタンスを作成する場合に作成されたユーザーシナリオです。

• VPC 内の DB インスタンスに別の VPC 内の EC2 インスタンスがアクセスするシナリオ

DB インスタンスがアクセスに使用している EC2 インスタンスとは異なる VPC にある場合、その DB インスタンスにアクセスする方法はいくつかあります。DB インスタンスと EC2 インスタンスが別の VPC にあっても同じリージョンにある場合は、VPC ピア接続を使用できます。DB インスタンスと EC2 インスタンスが異なるリージョンにある場合は、アクセスしている DB インスタンスのパブリック IP を使用する必要があります。

• VPC 内の DB インスタンスに VPC 外の EC2 インスタンスがアクセスするシナリオ

ClassicLink を使用することによって、VPC 内の Amazon RDS DB インスタンスと Amazon VPC 外の EC2 インスタンスの間で通信できます。Classic Link を使用すると、EC2 インスタンスのアプリケーションは、DB インスタンスの RDS エンドポイントを使用することによって、DB インスタンスに接続できます。

• インターネット経由でクライアントアプリケーションが VPC 内の DB インスタンスにアクセスするシナリオ

クライアントアプリケーションからインターネットを通じて VPC 内の DB インスタンスにアクセスするには、1 つのパブリックサブネットを持つ VPC と、インターネットを介した通信を有効にするためのインターネットゲートウェイを構成、ファイアウォールを設定して、データベースインスタンスへのネットワークアクセスを制御できます。

リソースレベルのアクセス許可

Amazon RDS はAWS Identity and Access Management (IAM) と統合されており、データベースインスタンスからスナップショット、パラメータグループ、オプショングループに至るまで、AWS IAM ユーザーおよびグループが特定の Amazon RDS リソースで実行可能なアクションを制限できます。Amazon RDS リソースにはタグを付けることもでき、同じタグおよび関連付けられた値を持つリソースグループで IAM ユーザーおよびグループが実行可能なアクションを制限できます。たとえば、開発者は「Development」データベースインスタンスを変更できるものの、「Production」データベースインスタンスに変更を加えられるのはデータベース管理者のみにするように IAM 規則を設定できます。