助け合いフォーラム
AWS ソリューションアーキテクト - アソシエイト(SAA-C03)
問題ID : 30252
問題を開く
ソリューションアーキテクトは、マルチAZで運用中のAmazon RDSでフェイルオーバーが発生していることに気が付いた。
原因を調査するポイントとして正しいものはどれか。(2つ選択)
原因を調査するポイントとして正しいものはどれか。(2つ選択)
正解
元プライマリDBインスタンスに障害が発生していないか
元プライマリDBインスタンスが配置されていたAZに障害が発生していないか
解説
Amazon RDSでは、AZ(Availability Zone)を超えたデプロイメント(マルチAZ)で、自動レプリケーション+フェイルオーバーを実現できます。
![<img src="/mondai3/img/jpg/kkk58350.jpg">](https://ping-t-resouces.com/uploads/question_image/file/22842/kkk58350.jpg)
プライマリDBインスタンスに障害が発生しても、スタンバイDBインスタンスがプライマリDBインスタンスに切り替わり、運用を継続することができます。
フェイルオーバーは以下のタイミングで実行されます:
- プライマリAZの障害
- プライマリDBインスタンスへのネットワーク接続不可
- プライマリDBインスタンスの障害
以上より正解は、
・元プライマリDBインスタンスに障害が発生していないか
・元プライマリDBインスタンスが配置されていたAZに障害が発生していないか
です。
なお、バックアップ側のデータベースはスタンバイ状態で常に同期されているため、フェイルオーバーが発生しても情報の取りこぼしはありません。
またフェイルオーバーは自動的に行われ、運用は継続して行えます。データベースを利用しているアプリケーション側からはスタンバイ側へアクセスを切り替える必要もありません。
その他の選択肢については以下の通りです。
・元プライマリDBインスタンスのバックアップが破棄されていないか
データベースのバックアップを破棄するか否かと、データベースの障害は関係ないので、誤りです。
・リードレプリカの過半数に障害が発生していないか
リードレプリカは参照負荷を軽減するための機能で、リードレプリカに障害があってもプライマリDBインスタンスへは影響しないので、誤りです。
・現プライマリDBインスタンスが配置されているAZに障害が発生していないか
フェイルオーバー後は障害が発生したプライマリDBインスタンスに代わって、スタンバイDBインスタンスがプライマリDBインスタンスになっています。
現プライマリDBインスタンスはフェイルオーバーの発生原因となっていないので、誤りです。
![<img src="/mondai3/img/jpg/kkk58350.jpg">](https://ping-t-resouces.com/uploads/question_image/file/22842/kkk58350.jpg)
プライマリDBインスタンスに障害が発生しても、スタンバイDBインスタンスがプライマリDBインスタンスに切り替わり、運用を継続することができます。
フェイルオーバーは以下のタイミングで実行されます:
- プライマリAZの障害
- プライマリDBインスタンスへのネットワーク接続不可
- プライマリDBインスタンスの障害
以上より正解は、
・元プライマリDBインスタンスに障害が発生していないか
・元プライマリDBインスタンスが配置されていたAZに障害が発生していないか
です。
なお、バックアップ側のデータベースはスタンバイ状態で常に同期されているため、フェイルオーバーが発生しても情報の取りこぼしはありません。
またフェイルオーバーは自動的に行われ、運用は継続して行えます。データベースを利用しているアプリケーション側からはスタンバイ側へアクセスを切り替える必要もありません。
その他の選択肢については以下の通りです。
・元プライマリDBインスタンスのバックアップが破棄されていないか
データベースのバックアップを破棄するか否かと、データベースの障害は関係ないので、誤りです。
・リードレプリカの過半数に障害が発生していないか
リードレプリカは参照負荷を軽減するための機能で、リードレプリカに障害があってもプライマリDBインスタンスへは影響しないので、誤りです。
・現プライマリDBインスタンスが配置されているAZに障害が発生していないか
フェイルオーバー後は障害が発生したプライマリDBインスタンスに代わって、スタンバイDBインスタンスがプライマリDBインスタンスになっています。
現プライマリDBインスタンスはフェイルオーバーの発生原因となっていないので、誤りです。
参考
【AWSのデータベースサービス】
AWSには複数のデータベースサービスがあり、それぞれ異なる特徴があります。
![【図を表示】](https://ping-t-resouces.com/uploads/question_image/file/22803/k58350.jpg)
ユーザーは各サービスの特性を理解したうえで最適なものを選択する必要があります。
本項ではAmazon RDSについて解説します。
【Amazon RDS(Relational Database Service)】
RDSは、フルマネージド型のリレーショナルデータベース(関係データベース)サービスです。SQLを用いたデータベースの操作が可能です。
フルマネージド型とは、データベースのスケーリング(拡張、縮小)、ストレージの拡張、高可用性、バックアップ、OS/データベースソフトウェアへのパッチ、サーバーの電源やメンテナンスなどが管理された状態であることをいいます。AWSにおけるフルマネージド型とは、前述の管理がAWSによって行われることを意味します。
RDSを使うことでデータベース管理者はこれらの煩雑な作業から解放され、データベースを効率的に利用することに注力することができます。
ただし、RDSはデータベースが稼働するシステム全体をAWSが管理してくれる代わりに、利用できるデータベースエンジンやバージョンが限定されています。また、データベースエンジンごとに使用が制限されている機能もありますので、利用する際は注意が必要です。
●RDSの特徴
RDSには以下の特徴があります:
(1) 構築・運用負荷の軽減
(2) 高可用性
(3) パフォーマンス
(4) セキュリティ
(5) ACID特性
(1) 構築・運用負荷の軽減
以下はRDSの構築画面です(一部抜粋)。
![【図を表示2】](https://ping-t-resouces.com/uploads/question_image/file/22841/kk58350.jpg)
データベースのエンジンのほか、インスタンスクラス、ディスクサイズなどを選択するだけで利用可能になります。
運用時も、データベースのレプリケーション(複製)やバックアップ、スナップショットなど運用に関する操作も上記と同様にGUIによる画面操作が可能です。
また、運用中にデータベースの容量が枯渇した場合も、Auto Scaling(自動スケーリング)機能を有効にすることで自動的に拡張されます。ただし増えたストレージ容量は減らす(ストレージを縮小する)ことはできませんので注意してください。
・データベースの移行
現在利用しているデータベースをRDSへ移行する際も、できるだけ手間が少ないように考慮されています。
例えばMySQLを利用している場合、自社環境に保存されたバックアップデータを利用して移行が行える等の機能が提供されています。
また、スナップショットを用いてデータベースの復元や、データベースの移行(異なるDBエンジンへ移行する)を行う機能も提供されています。
![<img src="/mondai3/img/jpg/k64452.jpg">](https://ping-t-resouces.com/uploads/question_image/file/25702/k64452.jpg)
以下はRDS for MySQLのスナップショットからAmazon Auroraへ移行する場合の画面例です。
![<img src="/mondai3/img/jpg/kk64452.jpg">](https://ping-t-resouces.com/uploads/question_image/file/25703/kk64452.jpg)
・スナップショットの共有
RDSでは、データベースを所有しているAWSアカウントとは別のAWSアカウントと、データベースのスナップショットを共有できます。
例えば、AWSアカウントを別に持つ部署でデータベースのコピーが必要だったり、新たに作成するAWSアカウントへデータベースを移行したいような場合は、スナップショットを共有し、共有したAWSアカウントでスナップショットからデータベースを復元するといった運用が可能です。
なお、スナップショットが暗号化されている場合は(「(4) セキュリティ」参照)、KMSキーのキーポリシーの設定で、共有先のアカウントへKMS暗号化キーの使用を許可する必要があります。詳細は分野「KMS/CloudHSM」の「鍵の使用と鍵の共有」を参照してください。
・データベースのパラメータ変更
タイムゾーンや最大接続数、監査ログの有効化など、データベースの設定を変更したい場合、RDSでは「DBパラメータグループ(DBクラスターパラメータグループ)」または「オプショングループ」で定義します。
DBパラメータグループ、オプショングループはDBエンジンごとに作成するパラメータまたはオプションの定義グループで、作成後は複数のデータベース(またはデータベースクラスター)へアタッチできます。
(2) 高可用性
AZ(Availability Zone)を超えたデプロイメント(マルチAZ)で、自動レプリケーション+フェイルオーバーを実現することができます。
![【図を表示3】](https://ping-t-resouces.com/uploads/question_image/file/22842/kkk58350.jpg)
マルチAZでは、プライマリDBインスタンスとスタンバイDBインスタンスを2つの異なるAZに1つずつ配置することによって可用性を向上させることができます(リージョンは同一)。
バックアップ側のデータベースはスタンバイ状態で常に同期されているため、フェイルオーバーが発生しても情報の取りこぼしはありません。
またフェイルオーバーは自動的に行われ、運用は継続して行えます。データベースを利用しているアプリケーション側からはスタンバイ側へアクセスを切り替える必要もありません。
マルチAZはデータベースのメンテナンス(OSの更新やパッチの適用など)の時にも役立ちます。
RDSはフルマネージド型のサービスのため、メンテナンスはAWSが行います。メンテナンスの実施時には、まれにデータベースインスタンスの再起動を伴う更新が行われることがあります。データベースインスタンスが再起動している間はサービスが停止します。このようなメンテナンスに伴う運用停止を回避するにはマルチAZ構成を組むことが推奨されています。マルチAZ構成を取ることで、AWSが実行するメンテナンスは以下のように段階的に実行され運用停止なしにメンテナンスを完了することができます。
1. スタンバイDBインスタンスに対するメンテナンス
2. スタンバイDBインスタンスをプライマリDBインスタンスへ昇格
3. 新スタンバイDBインスタンス(旧プライマリDBインスタンス)に対するメンテナンス
マルチAZは、DBインスタンスの作成時に設定することができます。また、既にシングルAZで稼働中のDBインスタンスに対しても、最小限のダウンタイムのみで設定変更ができます。
●マルチAZ DBクラスター
Amazon RDSのマルチAZ DBクラスターは、マルチAZ構成の新しい高可用性オプションです。従来のマルチAZ構成とは異なり、3つのアベイラビリティゾーンにまたがって配置されるため、可用性がさらに強化されています。また、従来のマルチAZ構成ではスタンバイインスタンスにアクセスできませんが、マルチAZ DBクラスターでは2つのスタンバイインスタンスがリードレプリカとしても機能し、読み取りアクセスが可能です。プライマリーインスタンスへの書き込みは、残り2台のリードレプリカに準同期レプリケーションされます。さらに、フェイルオーバー時には通常35秒未満で切り替わるため、アプリケーションのダウンタイムを最小限に抑えることができます。
[マルチAZ DBクラスターのイメージ図]
![<img src="/mondai3/img/jpg/k65781.jpg">](https://ping-t-resouces.com/uploads/question_image/file/26617/k65781.jpg)
(3) パフォーマンス
RR(リードレプリカ)という、参照専用のデータベースとして動作するレプリカ(複製)を作ることができます。データベースの参照時にかかる負荷が高い場合、RRを最大15台スケールアウト(処理台数の追加)し、参照時の負荷を分散できます。
![【図を表示4】](https://ping-t-resouces.com/uploads/question_image/file/22843/kkkk58350.jpg)
マルチAZ((2)参照)を利用してRRを複数のAZに分散したり、異なるリージョンに配置することもできます。
RRは、データベースのインスタンスクラス(EC2における"インスタンスタイプ"と同等)を変更することにより、スケールアップ(拡張)、スケールダウン(縮小)も柔軟に行うことができます。
利用者の多いタイミングでデータベースを一時的に拡張し、利用者が少ないタイミングでは縮小するように運用することにより、リソース(CPU、メモリ、ディスクI/Oやネットワークなど)を無用に消費せずに済みます。
※なお、本項で言及しているスケールアップ/ダウンは、データベースそのもののサイズではなく、データベースインスタンスであることに注意してください。データベースのサイズは拡張は可能ですが、縮小することはできません。
[RDSのストレージタイプ]
RDSのストレージは、基本的には汎用SSDとプロビジョンド(予約済み)IOPSから選択します。
IOPSとはInput Output per Second、つまり1秒間にどれだけI/O(Input/Output:読み取り/書き込み)が行えるかを意味するデータベースの性能指標です。
プロビジョンドIOPSを選択すると、予約したI/O性能をAWSが保証してストレージを提供します。予約したI/O性能が保証されるので、汎用SSDではAWS側の混雑で性能がなかなか出なかったりアクセス集中が日に何度も起きたりして自動スケーリングで対応しきれない場合などでも、想定した性能が保たれるというメリットがあります。
なお、両者の性能値は以下のように示されています:
・汎用SSD: 100~10,000 IOPS
・プロビジョンドIOPS:1,000~30,000 IOPS
(4) セキュリティ
RDSは、Amazon VPC(Virtual Private Cloud:ユーザー用の仮想プライベートネットワーク空間)に対応しています。DBインスタンス作成時にインターネットからの接続をONにしない限りは、VPC内でのみ利用可能なサービスです。
EC2インスタンスからのアクセスを行うパターンでは、RDSのデータベースインスタンス用のセキュリティグループを作成し、EC2インスタンスからのアクセスを許可するルールを作成して接続します。
![【図を表示5】](https://ping-t-resouces.com/uploads/question_image/file/22844/kkkkk58350.jpg)
また、データベースインスタンスは、AWS Key Management Service(KMS)と連携して暗号化を行うこともできます。
※KMSの詳細は、分野「KMS/CloudHSM」を参照してください。
データベースインスタンスの暗号化を行うと、バックアップやスナップショット、ログ、RR(リードレプリカ:参照専用のデータベースレプリカ)へも暗号化が行われます。
暗号化を行う場合はデータベースの作成時に指定します。
![<img src="/mondai3/img/jpg/k58353.jpg">](https://ping-t-resouces.com/uploads/question_image/file/22840/k58353.jpg)
データベースの作成後に暗号化を有効にすることはできません。
暗号化されていないデータベースインスタンスを暗号化したい場合は、対象のインスタンスのスナップショットを作成し、スナップショットをコピーする際に暗号化を有効にします。暗号化されたスナップショットを基にデータベースインスタンスを復元すると、暗号化されたデータベースインスタンスが新規に構築されます。
(5) ACID特性
リレーショナルデータベースにはACID特性というものがあります。ACIDとは、原子性(Atomicity)、一貫性(Consistency)、独立性(Isolation)、耐久性(Durability)を意味する言葉で、更新処理中に中途半端なデータが書き込まれないことや、並行処理がそれぞれ独立して動作する(互いに干渉しない)ことなど、処理の信頼性を保証する性質をいいます。RDSもリレーショナルデータベースサービスですので、ACID特性を持っています。
[データベースの削除保護]
Amazon RDS データベースやAmazon Auroraデータベースクラスタに対して「削除保護」機能を有効にすると、設定されたデータベースは削除ができなくなります。これにより、ユーザの操作ミスによる意図しない削除操作からデータベースを保護することができます。
![<img src="/mondai3/img/jpg/k64121.jpg">](https://ping-t-resouces.com/uploads/question_image/file/25646/k64121.jpg)
【Amazon RDS Proxy】
Amazon RDS Proxyは、Amazon RDSおよびAmazon Auroraデータベースへの接続を効率的に管理するフルマネージドのプロキシサービスです。RDS Proxyをアプリケーションとデータベースの間に配置することで、データベース接続の管理を効率化し、アプリケーションのパフォーマンス、スケーラビリティ、および可用性を向上させることができます。特に、サーバーレスアーキテクチャやマイクロサービスアーキテクチャで使用されることが多く、頻繁なデータベース接続の確立や切断がパフォーマンスに影響を与えるケースに適しています。
[Amazon RDS Proxyの利用例]
![<img src="/mondai3/img/jpg/k65579.jpg">](https://ping-t-resouces.com/uploads/question_image/file/26434/k65579.jpg)
主な特徴は以下です:
1.接続プーリング
RDS Proxyは接続プールを使用して、複数のデータベース接続を効率的に管理します。これにより、アプリケーションがデータベースに新しい接続を頻繁に確立および切断する必要がなくなり、データベースサーバーの負荷が軽減されます。また、一度確立したデータベース接続をプール内で保持し、必要に応じて再利用するため、接続の確立にかかる時間とリソースを節約することができます。
2.フェイルオーバーサポート
RDS Proxyはデータベースのフェイルオーバー時に接続を管理し、新しいデータベースインスタンスに自動的にルーティングします。さらに、マルチAZ配置もサポートしており、アプリケーションのダウンタイムを最小限に抑えることができます。
3.セキュリティ
RDS ProxyはIAMやSecrets Managerと統合して、データベースの認証情報を安全に管理します。これにより、データベース認証情報のセキュリティが強化され、アクセス制御も容易になります。
AWSには複数のデータベースサービスがあり、それぞれ異なる特徴があります。
![【図を表示】](https://ping-t-resouces.com/uploads/question_image/file/22803/k58350.jpg)
ユーザーは各サービスの特性を理解したうえで最適なものを選択する必要があります。
本項ではAmazon RDSについて解説します。
【Amazon RDS(Relational Database Service)】
RDSは、フルマネージド型のリレーショナルデータベース(関係データベース)サービスです。SQLを用いたデータベースの操作が可能です。
フルマネージド型とは、データベースのスケーリング(拡張、縮小)、ストレージの拡張、高可用性、バックアップ、OS/データベースソフトウェアへのパッチ、サーバーの電源やメンテナンスなどが管理された状態であることをいいます。AWSにおけるフルマネージド型とは、前述の管理がAWSによって行われることを意味します。
RDSを使うことでデータベース管理者はこれらの煩雑な作業から解放され、データベースを効率的に利用することに注力することができます。
ただし、RDSはデータベースが稼働するシステム全体をAWSが管理してくれる代わりに、利用できるデータベースエンジンやバージョンが限定されています。また、データベースエンジンごとに使用が制限されている機能もありますので、利用する際は注意が必要です。
●RDSの特徴
RDSには以下の特徴があります:
(1) 構築・運用負荷の軽減
(2) 高可用性
(3) パフォーマンス
(4) セキュリティ
(5) ACID特性
(1) 構築・運用負荷の軽減
以下はRDSの構築画面です(一部抜粋)。
![【図を表示2】](https://ping-t-resouces.com/uploads/question_image/file/22841/kk58350.jpg)
データベースのエンジンのほか、インスタンスクラス、ディスクサイズなどを選択するだけで利用可能になります。
運用時も、データベースのレプリケーション(複製)やバックアップ、スナップショットなど運用に関する操作も上記と同様にGUIによる画面操作が可能です。
また、運用中にデータベースの容量が枯渇した場合も、Auto Scaling(自動スケーリング)機能を有効にすることで自動的に拡張されます。ただし増えたストレージ容量は減らす(ストレージを縮小する)ことはできませんので注意してください。
・データベースの移行
現在利用しているデータベースをRDSへ移行する際も、できるだけ手間が少ないように考慮されています。
例えばMySQLを利用している場合、自社環境に保存されたバックアップデータを利用して移行が行える等の機能が提供されています。
また、スナップショットを用いてデータベースの復元や、データベースの移行(異なるDBエンジンへ移行する)を行う機能も提供されています。
![<img src="/mondai3/img/jpg/k64452.jpg">](https://ping-t-resouces.com/uploads/question_image/file/25702/k64452.jpg)
以下はRDS for MySQLのスナップショットからAmazon Auroraへ移行する場合の画面例です。
![<img src="/mondai3/img/jpg/kk64452.jpg">](https://ping-t-resouces.com/uploads/question_image/file/25703/kk64452.jpg)
・スナップショットの共有
RDSでは、データベースを所有しているAWSアカウントとは別のAWSアカウントと、データベースのスナップショットを共有できます。
例えば、AWSアカウントを別に持つ部署でデータベースのコピーが必要だったり、新たに作成するAWSアカウントへデータベースを移行したいような場合は、スナップショットを共有し、共有したAWSアカウントでスナップショットからデータベースを復元するといった運用が可能です。
なお、スナップショットが暗号化されている場合は(「(4) セキュリティ」参照)、KMSキーのキーポリシーの設定で、共有先のアカウントへKMS暗号化キーの使用を許可する必要があります。詳細は分野「KMS/CloudHSM」の「鍵の使用と鍵の共有」を参照してください。
・データベースのパラメータ変更
タイムゾーンや最大接続数、監査ログの有効化など、データベースの設定を変更したい場合、RDSでは「DBパラメータグループ(DBクラスターパラメータグループ)」または「オプショングループ」で定義します。
DBパラメータグループ、オプショングループはDBエンジンごとに作成するパラメータまたはオプションの定義グループで、作成後は複数のデータベース(またはデータベースクラスター)へアタッチできます。
(2) 高可用性
AZ(Availability Zone)を超えたデプロイメント(マルチAZ)で、自動レプリケーション+フェイルオーバーを実現することができます。
![【図を表示3】](https://ping-t-resouces.com/uploads/question_image/file/22842/kkk58350.jpg)
マルチAZでは、プライマリDBインスタンスとスタンバイDBインスタンスを2つの異なるAZに1つずつ配置することによって可用性を向上させることができます(リージョンは同一)。
バックアップ側のデータベースはスタンバイ状態で常に同期されているため、フェイルオーバーが発生しても情報の取りこぼしはありません。
またフェイルオーバーは自動的に行われ、運用は継続して行えます。データベースを利用しているアプリケーション側からはスタンバイ側へアクセスを切り替える必要もありません。
マルチAZはデータベースのメンテナンス(OSの更新やパッチの適用など)の時にも役立ちます。
RDSはフルマネージド型のサービスのため、メンテナンスはAWSが行います。メンテナンスの実施時には、まれにデータベースインスタンスの再起動を伴う更新が行われることがあります。データベースインスタンスが再起動している間はサービスが停止します。このようなメンテナンスに伴う運用停止を回避するにはマルチAZ構成を組むことが推奨されています。マルチAZ構成を取ることで、AWSが実行するメンテナンスは以下のように段階的に実行され運用停止なしにメンテナンスを完了することができます。
1. スタンバイDBインスタンスに対するメンテナンス
2. スタンバイDBインスタンスをプライマリDBインスタンスへ昇格
3. 新スタンバイDBインスタンス(旧プライマリDBインスタンス)に対するメンテナンス
マルチAZは、DBインスタンスの作成時に設定することができます。また、既にシングルAZで稼働中のDBインスタンスに対しても、最小限のダウンタイムのみで設定変更ができます。
●マルチAZ DBクラスター
Amazon RDSのマルチAZ DBクラスターは、マルチAZ構成の新しい高可用性オプションです。従来のマルチAZ構成とは異なり、3つのアベイラビリティゾーンにまたがって配置されるため、可用性がさらに強化されています。また、従来のマルチAZ構成ではスタンバイインスタンスにアクセスできませんが、マルチAZ DBクラスターでは2つのスタンバイインスタンスがリードレプリカとしても機能し、読み取りアクセスが可能です。プライマリーインスタンスへの書き込みは、残り2台のリードレプリカに準同期レプリケーションされます。さらに、フェイルオーバー時には通常35秒未満で切り替わるため、アプリケーションのダウンタイムを最小限に抑えることができます。
[マルチAZ DBクラスターのイメージ図]
![<img src="/mondai3/img/jpg/k65781.jpg">](https://ping-t-resouces.com/uploads/question_image/file/26617/k65781.jpg)
(3) パフォーマンス
RR(リードレプリカ)という、参照専用のデータベースとして動作するレプリカ(複製)を作ることができます。データベースの参照時にかかる負荷が高い場合、RRを最大15台スケールアウト(処理台数の追加)し、参照時の負荷を分散できます。
![【図を表示4】](https://ping-t-resouces.com/uploads/question_image/file/22843/kkkk58350.jpg)
マルチAZ((2)参照)を利用してRRを複数のAZに分散したり、異なるリージョンに配置することもできます。
RRは、データベースのインスタンスクラス(EC2における"インスタンスタイプ"と同等)を変更することにより、スケールアップ(拡張)、スケールダウン(縮小)も柔軟に行うことができます。
利用者の多いタイミングでデータベースを一時的に拡張し、利用者が少ないタイミングでは縮小するように運用することにより、リソース(CPU、メモリ、ディスクI/Oやネットワークなど)を無用に消費せずに済みます。
※なお、本項で言及しているスケールアップ/ダウンは、データベースそのもののサイズではなく、データベースインスタンスであることに注意してください。データベースのサイズは拡張は可能ですが、縮小することはできません。
[RDSのストレージタイプ]
RDSのストレージは、基本的には汎用SSDとプロビジョンド(予約済み)IOPSから選択します。
IOPSとはInput Output per Second、つまり1秒間にどれだけI/O(Input/Output:読み取り/書き込み)が行えるかを意味するデータベースの性能指標です。
プロビジョンドIOPSを選択すると、予約したI/O性能をAWSが保証してストレージを提供します。予約したI/O性能が保証されるので、汎用SSDではAWS側の混雑で性能がなかなか出なかったりアクセス集中が日に何度も起きたりして自動スケーリングで対応しきれない場合などでも、想定した性能が保たれるというメリットがあります。
なお、両者の性能値は以下のように示されています:
・汎用SSD: 100~10,000 IOPS
・プロビジョンドIOPS:1,000~30,000 IOPS
(4) セキュリティ
RDSは、Amazon VPC(Virtual Private Cloud:ユーザー用の仮想プライベートネットワーク空間)に対応しています。DBインスタンス作成時にインターネットからの接続をONにしない限りは、VPC内でのみ利用可能なサービスです。
EC2インスタンスからのアクセスを行うパターンでは、RDSのデータベースインスタンス用のセキュリティグループを作成し、EC2インスタンスからのアクセスを許可するルールを作成して接続します。
![【図を表示5】](https://ping-t-resouces.com/uploads/question_image/file/22844/kkkkk58350.jpg)
また、データベースインスタンスは、AWS Key Management Service(KMS)と連携して暗号化を行うこともできます。
※KMSの詳細は、分野「KMS/CloudHSM」を参照してください。
データベースインスタンスの暗号化を行うと、バックアップやスナップショット、ログ、RR(リードレプリカ:参照専用のデータベースレプリカ)へも暗号化が行われます。
暗号化を行う場合はデータベースの作成時に指定します。
![<img src="/mondai3/img/jpg/k58353.jpg">](https://ping-t-resouces.com/uploads/question_image/file/22840/k58353.jpg)
データベースの作成後に暗号化を有効にすることはできません。
暗号化されていないデータベースインスタンスを暗号化したい場合は、対象のインスタンスのスナップショットを作成し、スナップショットをコピーする際に暗号化を有効にします。暗号化されたスナップショットを基にデータベースインスタンスを復元すると、暗号化されたデータベースインスタンスが新規に構築されます。
(5) ACID特性
リレーショナルデータベースにはACID特性というものがあります。ACIDとは、原子性(Atomicity)、一貫性(Consistency)、独立性(Isolation)、耐久性(Durability)を意味する言葉で、更新処理中に中途半端なデータが書き込まれないことや、並行処理がそれぞれ独立して動作する(互いに干渉しない)ことなど、処理の信頼性を保証する性質をいいます。RDSもリレーショナルデータベースサービスですので、ACID特性を持っています。
[データベースの削除保護]
Amazon RDS データベースやAmazon Auroraデータベースクラスタに対して「削除保護」機能を有効にすると、設定されたデータベースは削除ができなくなります。これにより、ユーザの操作ミスによる意図しない削除操作からデータベースを保護することができます。
![<img src="/mondai3/img/jpg/k64121.jpg">](https://ping-t-resouces.com/uploads/question_image/file/25646/k64121.jpg)
【Amazon RDS Proxy】
Amazon RDS Proxyは、Amazon RDSおよびAmazon Auroraデータベースへの接続を効率的に管理するフルマネージドのプロキシサービスです。RDS Proxyをアプリケーションとデータベースの間に配置することで、データベース接続の管理を効率化し、アプリケーションのパフォーマンス、スケーラビリティ、および可用性を向上させることができます。特に、サーバーレスアーキテクチャやマイクロサービスアーキテクチャで使用されることが多く、頻繁なデータベース接続の確立や切断がパフォーマンスに影響を与えるケースに適しています。
[Amazon RDS Proxyの利用例]
![<img src="/mondai3/img/jpg/k65579.jpg">](https://ping-t-resouces.com/uploads/question_image/file/26434/k65579.jpg)
主な特徴は以下です:
1.接続プーリング
RDS Proxyは接続プールを使用して、複数のデータベース接続を効率的に管理します。これにより、アプリケーションがデータベースに新しい接続を頻繁に確立および切断する必要がなくなり、データベースサーバーの負荷が軽減されます。また、一度確立したデータベース接続をプール内で保持し、必要に応じて再利用するため、接続の確立にかかる時間とリソースを節約することができます。
2.フェイルオーバーサポート
RDS Proxyはデータベースのフェイルオーバー時に接続を管理し、新しいデータベースインスタンスに自動的にルーティングします。さらに、マルチAZ配置もサポートしており、アプリケーションのダウンタイムを最小限に抑えることができます。
3.セキュリティ
RDS ProxyはIAMやSecrets Managerと統合して、データベースの認証情報を安全に管理します。これにより、データベース認証情報のセキュリティが強化され、アクセス制御も容易になります。
マルチAZにおいてフェイルオーバー後のプライマリとスタンバイについて
公開日 2024/06/22
問題内で「フェイルオーバーが発生していることに気が付いた。」と記載があります。
この場合、下記の状態になる認識でした。
1.元々スタンバイだったDBインスタンスがプライマリに昇格
2.元々プライマリだったDBインスタンスがスタンバイに変更
発生していることに気が付いた時点で、元々プライマリだったDBインスタンスはスタンバイになっているため
スタンバイ側での原因調査が必要になるのではないのでしょうか。
どなたか教えていただけると幸いです。
b
birdpixy
2024/06/23 22:28
ちょっとご質問と外れてるかもしれませんが
2.元々プライマリだったDBインスタンスがスタンバイに変更
障害の発生したDBインスタンスがスタンバイに変更されるでしょうか?
障害が発生したら利用不能になるので、スタンバイにはならないのではないのかなと思いました。
元のプライマリDBインスタンスがどのような挙動をしているかの資料が見つからなかったのですが、どこかに載っていましたか?
コメント
スタッフからの返信
この投稿に対して返信しませんか?
b birdpixy
2024/06/24 13:48
ちょっと気になったので実際にRDSでフェイルオーバーをしましたところ、たしかにセカンダリDBインスタンスがプライマリに昇格したとき、プライマリDBインスタンスがセカンダリになっていました。 手動フェイルオーバーなので実際の障害時とは挙動が違うかもしれませんが…。 それはそうとして本来の質問について、たしかにフェイルオーバー後はプライマリを降格しているので、調査時点ではセカンダリが障害の発生したDBインスタンスで調査対象ということになりますね。