助け合いフォーラム
AWS ソリューションアーキテクト - アソシエイト(SAA-C03)
問題ID : 30535
問題を開く
Aurora Global Database(グローバルデータベース)について正しく説明しているものはどれか。
正解
プライマリリージョンで障害が発生した場合の目標復旧時点(RPO)は1秒、目標復旧時間(RTO)は1分未満と定めている
解説
Amazon Aurora Global Database(Auroraグローバルデータベース)は、Auroraデータベースを複数のリージョンにまたがって運用できるサービスです。例えば、東京リージョンで稼働しているデータベースを大阪リージョンにも配置できるということです。Auroraグローバルデータベースを使用しても、ユーザーは複数のリージョンのデータベースを管理する必要はありません。データはプライマリとして稼働しているメインのリージョンからセカンダリリージョンへレプリケートされます。
グローバルデータベースの利点の一つに、「リージョン単位で発生した大規模な障害の災害対策(ディザスタリカバリ:DR)になる」があります。
プライマリリージョンのデータベースが停止した場合、セカンダリリージョンのデータベースを自動で昇格(フェイルオーバー)させ運用を継続できます。Auroraグローバルデータベースでは、一般的にディザスタリカバリの指標として使用されるRPO(目標復旧時点)を 1秒、RTO(目標復旧時間)を1分未満と定めています。
※RPO(Recovery Point Objective:目標復旧時点) ... どの時点までのデータを復旧させるか。データベースの更新頻度が高い場合は、0秒(停止直前)のデータ復旧が求められる。
※RTO(Recovery Time Objective:目標復旧時間) ... どのくらいの時間で(いつまでに)復旧させるか。サービスやシステムを停止していられる時間。
以上より正解は
・プライマリリージョンで障害が発生した場合の目標復旧時点(RPO)は1秒、目標復旧時間(RTO)は1分未満と定めている
です。
その他の選択肢については以下の通りです。
・1つ以上のプライマリリージョンと、1つのセカンダリリージョンを指定する
1つのプライマリリージョンと、1つ以上のセカンダリリージョンを指定するので、誤りです。
・データベース管理者はデータベースをレプリケーションするリージョンの数だけ運用を行う必要がある
データベース管理者は基本的にプライマリリージョンのデータベースのみを運用するので、誤りです。
・プライマリリージョンに障害が発生した場合、データベース管理者はマネジメントコンソールからフェイルオーバーを実施する
障害発生時には、AWSが自動的にフェイルオーバーを行うので、誤りです。
なお、ユーザーが意図的に操作したい場合は、マネジメントコンソールから手動でフェイルオーバーする方法もあります。
グローバルデータベースの利点の一つに、「リージョン単位で発生した大規模な障害の災害対策(ディザスタリカバリ:DR)になる」があります。
プライマリリージョンのデータベースが停止した場合、セカンダリリージョンのデータベースを自動で昇格(フェイルオーバー)させ運用を継続できます。Auroraグローバルデータベースでは、一般的にディザスタリカバリの指標として使用されるRPO(目標復旧時点)を 1秒、RTO(目標復旧時間)を1分未満と定めています。
※RPO(Recovery Point Objective:目標復旧時点) ... どの時点までのデータを復旧させるか。データベースの更新頻度が高い場合は、0秒(停止直前)のデータ復旧が求められる。
※RTO(Recovery Time Objective:目標復旧時間) ... どのくらいの時間で(いつまでに)復旧させるか。サービスやシステムを停止していられる時間。
以上より正解は
・プライマリリージョンで障害が発生した場合の目標復旧時点(RPO)は1秒、目標復旧時間(RTO)は1分未満と定めている
です。
その他の選択肢については以下の通りです。
・1つ以上のプライマリリージョンと、1つのセカンダリリージョンを指定する
1つのプライマリリージョンと、1つ以上のセカンダリリージョンを指定するので、誤りです。
・データベース管理者はデータベースをレプリケーションするリージョンの数だけ運用を行う必要がある
データベース管理者は基本的にプライマリリージョンのデータベースのみを運用するので、誤りです。
・プライマリリージョンに障害が発生した場合、データベース管理者はマネジメントコンソールからフェイルオーバーを実施する
障害発生時には、AWSが自動的にフェイルオーバーを行うので、誤りです。
なお、ユーザーが意図的に操作したい場合は、マネジメントコンソールから手動でフェイルオーバーする方法もあります。
参考
【Amazon Aurora】
Amazon Auroraは、Amazonが設計・開発したMySQL/PostgreSQL互換のデータベースエンジンです。フルマネージド型サービスであるAmazon RDS(Relational Database Service)で利用可能なデータベースエンジンですので、データベースのスケーリング(拡張、縮小)、高可用性、バックアップ、OS/データベースソフトウェアへのパッチ、サーバーの電源やメンテナンスなどはRDS(AWS)によって管理されます。
RDSの他のデータベースエンジンと比べた時のAuroraの特徴は以下の通りです:
・データベースインスタンスとストレージが分離したアーキテクチャ
・複数のデータコピーと自動修復機能などによるストレージの高い耐障害性
・レプリカインスタンスの自動フェイルオーバーによる高可用性
・データベースのクローンを高速作成
●データベースインスタンスとストレージが分離したアーキテクチャ
以下はAuroraを利用した際の構成例です。
Auroraはデータベースインスタンスとストレージが分離しており、柔軟な構成が可能です。例では2つのデータベースインスタンスが存在しますが、手動でのデータベース管理が不要なサーバーレス構成や、最大15台のレプリカインスタンス(参照専用のインスタンス)を構成することもできます。
●複数のデータコピーと自動修復機能などによるストレージの高い耐障害性
ストレージは、デフォルトで3つのAZに2つずつ(計6つ)のデータコピーが作成されます。これらのストレージは「クラスタボリューム」というクラスタ構成で管理されます。
Auroraのクラスタボリューム内のストレージは互いに監視しあっており、データの破損が発生しても自動で検出、修復します。
●レプリカインスタンスの自動フェイルオーバーによる高可用性
データベースインスタンスは、書き込みを行うプライマリインスタンスを1台、参照専用のレプリカインスタンス(リードレプリカ)を最大で15台作成することができます。
レプリカインスタンスはデフォルトでプライマリインスタンスと異なるAZに作成され、プライマリインスタンスに障害が発生した場合は自動でフェイルオーバー(切り替え)とプライマリインスタンスへの昇格が行われます。
RDSのその他のデータベースエンジンはスタンバイ用のインスタンスとリードレプリカは別々のインスタンスですが、Auroraではリードレプリカがスタンバイインスタンスを兼ねています。
●データベースのクローンを高速作成
Auroraにはデータベースのクローン(複製)を作成する機能があります。クローンは「Copy-on-Write」という技術で作成されます。Copy-on-Writeは、データの複製時にコピーしたと見せかけて、実際は複製元のデータを参照します。
複製元または複製先のデータの更新時に対象のデータをコピーして、それ以降はコピーしたデータにアクセスします。更新したデータ以外は、複製元のデータを参照するのでストレージ容量の節約になります。また、クローンの作成時にデータのコピーが発生しないので、スナップショットの取得/復元やデータベースのエクスポート/インポートするよりも複製を高速に作成できます。
【Auroraの自動スケーリング】
Auroraには、ストレージ容量、レプリカインスタンス数、インスタンスタイプを負荷に応じて自動的にスケーリングする機能があります。
●ストレージ容量のスケーリング
ストレージ容量は、ユーザーが指定した容量(最大128TB)まで自動的に拡張されます。データの増加に伴って拡張されていくため、必要な容量を計算して事前にプロビジョニング(予約)する、といった手間は必要ありません。またデータが削除されると、その分の割り当てられていたストレージ領域が自動的に縮小されるので、コスト削減につながります。
●Aurora Auto Scalingによるレプリカインスタンス数のスケーリング
Auroraでは、データベースへの負荷に応じて動的にレプリカインスタンスを増減するAuto Scaling機能があります。平均CPUまたは平均接続数に任意の値を設定し(例:「CPU使用率 50%」など)、設定した値が維持されるようにレプリカインスタンスが調整されます。
RDSのその他のデータベースエンジンにもAuto Scaling機能はありますが、RDSのAuto Scalingはデータベース(ストレージ)容量の拡張であり、レプリカインスタンス(リードレプリカ)の増減を行う機能ではありませんので注意してください。
●Aurora Serverlessによるインスタンスタイプのスケーリング
Aurora ServerlessはDBインスタンスの負荷状況に応じて、自動的にDBインスタンスの起動、停止、スケールアップ/スケールダウンを実施する機能です。
通常のAuroraではDBインスタンス作成時にインスタンスタイプ(db.t3.mediumなど)を指定しますが、Aurora Serverlessではデータベースの負荷状況に応じた性能で稼働します。また、データベースの利用がないときはDBインスタンスを停止し、需要があれば自動的に起動します。データベースの利用率に変動のあるシステムや、利用量の予測が難しいシステムに使用すると、コスト削減の効果が期待できます。
Aurora Auto Scalingはスケールアウト/スケールイン(リソース数の増減)であるのに対し、Aurora Serverlessはスケールアップ/スケールダウン(性能の増減)であるという違いがあります。
【Auroraのエンドポイント】
Auroraでは、インスタンスへアクセスするためのエンドポイント(接続先)を用途ごとに分けています。
クラスターエンドポイントは更新も参照も行うことができますが、参照クエリが多いと更新処理を圧迫してしまいます。用途ごとにエンドポイントを使い分けることで負荷を分散し、全体的なパフォーマンス改善を図ることができます。
なお、レプリカインスタンスが複数台あった場合、読み取りエンドポイントへのリクエストは各インスタンスへ均等に割り振られます。
また、フェイルオーバーが発生してもアプリケーションはエンドポイントを切り替える必要はありません。レプリカインスタンスからプライマリインスタンスへの昇格が自動的に行われるように、クラスターエンドポイントの接続先インスタンスも自動で切り替えが行われ、運用を継続できます。
【Amazon Aurora Global Database(Aurora グローバルデータベース)】
Auroraグローバルデータベースは、Auroraデータベースを複数のリージョンにまたがって運用できるサービスです。例えば、東京リージョンで稼働しているデータベースを大阪リージョンにも配置できるということです。Auroraグローバルデータベースを使用しても、ユーザーは複数のリージョンのデータベースを管理する必要はありません。データはプライマリとして稼働しているメインのリージョンからセカンダリリージョンへレプリケートされます。
グローバルデータベースの大きな利点は以下の2点です。
・データベースアクセスを世界中から高速に行える(レイテンシの向上)
・リージョン単位で発生した大規模な障害の災害対策(ディザスタリカバリ:DR)になる
異なるリージョンからデータを読み取りたい場合はリードレプリカを異なるリージョンに配置することもできますが、Auroraグローバルデータベースは書き込みも異なるリージョンから行えます。
また、Auroraグローバルデータベースは災害復旧時に非常に高い効果を発揮します。プライマリリージョンのデータベースが停止した場合、セカンダリリージョンのデータベースを自動で昇格(フェイルオーバー)させ運用を継続できます。Auroraグローバルデータベースでは、一般的にディザスタリカバリの指標として使用されるRPO(目標復旧時点)を 1秒、RTO(目標復旧時間)を1分未満と定めています。
※RPO(Recovery Point Objective:目標復旧時点) ... どの時点までのデータを復旧させるか。データベースの更新頻度が高い場合は、0秒(停止直前)のデータ復旧が求められる。
※RTO(Recovery Time Objective:目標復旧時間) ... どのくらいの時間で(いつまでに)復旧させるか。サービスやシステムを停止していられる時間。
【Auroraのインスタンス購入オプション】
Auroraのインスタンス購入オプションは、以下の三つがあります。
・オンデマンドインスタンス
利用した分だけ料金を支払う方式です。事前のコミットメントや長期契約は不要で、使用した計算容量に対して秒単位で料金がかかります。柔軟性が高く、短期間の使用や不定期なワークロードに適しています。
・リザーブドインスタンス
一定期間(1年または3年)の事前契約を伴う割引料金のオプションです。期間を事前に定めることで、オンデマンド料金よりも大幅な割引が適用されます。長期間にわたって一定のワークロードがある場合にコスト効率が良いです。
・サーバーレス(Aurora Serverlessを選択した場合)
使用量に基づいて自動的にスケーリングするオプションです。データベースの使用量が増減する場合や一時的な使用に適しています。このオプションでは、実際に使用した計算容量とストレージの使用量に応じて料金が発生します。
これらのオプションを選ぶ際には、アプリケーションの要件、使用パターン、コストの最適化のニーズに応じて適切なものを選ぶことが重要です。
Amazon Auroraは、Amazonが設計・開発したMySQL/PostgreSQL互換のデータベースエンジンです。フルマネージド型サービスであるAmazon RDS(Relational Database Service)で利用可能なデータベースエンジンですので、データベースのスケーリング(拡張、縮小)、高可用性、バックアップ、OS/データベースソフトウェアへのパッチ、サーバーの電源やメンテナンスなどはRDS(AWS)によって管理されます。
RDSの他のデータベースエンジンと比べた時のAuroraの特徴は以下の通りです:
・データベースインスタンスとストレージが分離したアーキテクチャ
・複数のデータコピーと自動修復機能などによるストレージの高い耐障害性
・レプリカインスタンスの自動フェイルオーバーによる高可用性
・データベースのクローンを高速作成
●データベースインスタンスとストレージが分離したアーキテクチャ
以下はAuroraを利用した際の構成例です。
Auroraはデータベースインスタンスとストレージが分離しており、柔軟な構成が可能です。例では2つのデータベースインスタンスが存在しますが、手動でのデータベース管理が不要なサーバーレス構成や、最大15台のレプリカインスタンス(参照専用のインスタンス)を構成することもできます。
●複数のデータコピーと自動修復機能などによるストレージの高い耐障害性
ストレージは、デフォルトで3つのAZに2つずつ(計6つ)のデータコピーが作成されます。これらのストレージは「クラスタボリューム」というクラスタ構成で管理されます。
Auroraのクラスタボリューム内のストレージは互いに監視しあっており、データの破損が発生しても自動で検出、修復します。
●レプリカインスタンスの自動フェイルオーバーによる高可用性
データベースインスタンスは、書き込みを行うプライマリインスタンスを1台、参照専用のレプリカインスタンス(リードレプリカ)を最大で15台作成することができます。
レプリカインスタンスはデフォルトでプライマリインスタンスと異なるAZに作成され、プライマリインスタンスに障害が発生した場合は自動でフェイルオーバー(切り替え)とプライマリインスタンスへの昇格が行われます。
RDSのその他のデータベースエンジンはスタンバイ用のインスタンスとリードレプリカは別々のインスタンスですが、Auroraではリードレプリカがスタンバイインスタンスを兼ねています。
●データベースのクローンを高速作成
Auroraにはデータベースのクローン(複製)を作成する機能があります。クローンは「Copy-on-Write」という技術で作成されます。Copy-on-Writeは、データの複製時にコピーしたと見せかけて、実際は複製元のデータを参照します。
複製元または複製先のデータの更新時に対象のデータをコピーして、それ以降はコピーしたデータにアクセスします。更新したデータ以外は、複製元のデータを参照するのでストレージ容量の節約になります。また、クローンの作成時にデータのコピーが発生しないので、スナップショットの取得/復元やデータベースのエクスポート/インポートするよりも複製を高速に作成できます。
【Auroraの自動スケーリング】
Auroraには、ストレージ容量、レプリカインスタンス数、インスタンスタイプを負荷に応じて自動的にスケーリングする機能があります。
●ストレージ容量のスケーリング
ストレージ容量は、ユーザーが指定した容量(最大128TB)まで自動的に拡張されます。データの増加に伴って拡張されていくため、必要な容量を計算して事前にプロビジョニング(予約)する、といった手間は必要ありません。またデータが削除されると、その分の割り当てられていたストレージ領域が自動的に縮小されるので、コスト削減につながります。
●Aurora Auto Scalingによるレプリカインスタンス数のスケーリング
Auroraでは、データベースへの負荷に応じて動的にレプリカインスタンスを増減するAuto Scaling機能があります。平均CPUまたは平均接続数に任意の値を設定し(例:「CPU使用率 50%」など)、設定した値が維持されるようにレプリカインスタンスが調整されます。
RDSのその他のデータベースエンジンにもAuto Scaling機能はありますが、RDSのAuto Scalingはデータベース(ストレージ)容量の拡張であり、レプリカインスタンス(リードレプリカ)の増減を行う機能ではありませんので注意してください。
●Aurora Serverlessによるインスタンスタイプのスケーリング
Aurora ServerlessはDBインスタンスの負荷状況に応じて、自動的にDBインスタンスの起動、停止、スケールアップ/スケールダウンを実施する機能です。
通常のAuroraではDBインスタンス作成時にインスタンスタイプ(db.t3.mediumなど)を指定しますが、Aurora Serverlessではデータベースの負荷状況に応じた性能で稼働します。また、データベースの利用がないときはDBインスタンスを停止し、需要があれば自動的に起動します。データベースの利用率に変動のあるシステムや、利用量の予測が難しいシステムに使用すると、コスト削減の効果が期待できます。
Aurora Auto Scalingはスケールアウト/スケールイン(リソース数の増減)であるのに対し、Aurora Serverlessはスケールアップ/スケールダウン(性能の増減)であるという違いがあります。
【Auroraのエンドポイント】
Auroraでは、インスタンスへアクセスするためのエンドポイント(接続先)を用途ごとに分けています。
クラスターエンドポイントは更新も参照も行うことができますが、参照クエリが多いと更新処理を圧迫してしまいます。用途ごとにエンドポイントを使い分けることで負荷を分散し、全体的なパフォーマンス改善を図ることができます。
なお、レプリカインスタンスが複数台あった場合、読み取りエンドポイントへのリクエストは各インスタンスへ均等に割り振られます。
また、フェイルオーバーが発生してもアプリケーションはエンドポイントを切り替える必要はありません。レプリカインスタンスからプライマリインスタンスへの昇格が自動的に行われるように、クラスターエンドポイントの接続先インスタンスも自動で切り替えが行われ、運用を継続できます。
【Amazon Aurora Global Database(Aurora グローバルデータベース)】
Auroraグローバルデータベースは、Auroraデータベースを複数のリージョンにまたがって運用できるサービスです。例えば、東京リージョンで稼働しているデータベースを大阪リージョンにも配置できるということです。Auroraグローバルデータベースを使用しても、ユーザーは複数のリージョンのデータベースを管理する必要はありません。データはプライマリとして稼働しているメインのリージョンからセカンダリリージョンへレプリケートされます。
グローバルデータベースの大きな利点は以下の2点です。
・データベースアクセスを世界中から高速に行える(レイテンシの向上)
・リージョン単位で発生した大規模な障害の災害対策(ディザスタリカバリ:DR)になる
異なるリージョンからデータを読み取りたい場合はリードレプリカを異なるリージョンに配置することもできますが、Auroraグローバルデータベースは書き込みも異なるリージョンから行えます。
また、Auroraグローバルデータベースは災害復旧時に非常に高い効果を発揮します。プライマリリージョンのデータベースが停止した場合、セカンダリリージョンのデータベースを自動で昇格(フェイルオーバー)させ運用を継続できます。Auroraグローバルデータベースでは、一般的にディザスタリカバリの指標として使用されるRPO(目標復旧時点)を 1秒、RTO(目標復旧時間)を1分未満と定めています。
※RPO(Recovery Point Objective:目標復旧時点) ... どの時点までのデータを復旧させるか。データベースの更新頻度が高い場合は、0秒(停止直前)のデータ復旧が求められる。
※RTO(Recovery Time Objective:目標復旧時間) ... どのくらいの時間で(いつまでに)復旧させるか。サービスやシステムを停止していられる時間。
【Auroraのインスタンス購入オプション】
Auroraのインスタンス購入オプションは、以下の三つがあります。
・オンデマンドインスタンス
利用した分だけ料金を支払う方式です。事前のコミットメントや長期契約は不要で、使用した計算容量に対して秒単位で料金がかかります。柔軟性が高く、短期間の使用や不定期なワークロードに適しています。
・リザーブドインスタンス
一定期間(1年または3年)の事前契約を伴う割引料金のオプションです。期間を事前に定めることで、オンデマンド料金よりも大幅な割引が適用されます。長期間にわたって一定のワークロードがある場合にコスト効率が良いです。
・サーバーレス(Aurora Serverlessを選択した場合)
使用量に基づいて自動的にスケーリングするオプションです。データベースの使用量が増減する場合や一時的な使用に適しています。このオプションでは、実際に使用した計算容量とストレージの使用量に応じて料金が発生します。
これらのオプションを選ぶ際には、アプリケーションの要件、使用パターン、コストの最適化のニーズに応じて適切なものを選ぶことが重要です。
Aurora Global Databaseのセカンダリリージョンでの処理
投稿日 2024/08/04
選択肢の「プライマリリージョンからは読み込みと書き込みを、セカンダリリージョンからは読み込みのみを行える」が不正解になっており、解答には「セカンダリリージョンのデータベースに対しては書き込みを行うこともできますので誤りです。」と解説がありました。
Aurora Global Databaseでは、特定の1つのリージョンにプライマリDBクラスターが配置され、それ以外の異なるリージョンにセカンダリDBクラスターを配置することができ、レプリケートされたセカンダリDBクラスターは、読み取り処理のみ可能である認識でいたのですが違うのでしょうか。
ご回答いただけますと幸いです。
よろしくお願いします。
スタッフからの返信
この投稿に対して返信しませんか?
s staff_satomi
2024/08/05 15:42
miharumoriya様 ご指摘の点を修正いたしました。 ご報告いただきまして、誠にありがとうございます。