RDSについて勉強

AWS 認定ソリューションアーキテクト ? アソシエイトを受けるため、改めてAmazon Web Service(AWS)の勉強をする。

今回もこの本を一読したうえで機能単位で勉強していく。

徹底攻略 AWS認定 ソリューションアーキテクト ? アソシエイト教科書

RDSについて

Amazon Relational Database Service(RDS)はマネージド型のリレーショナルデータベースサービス。
サポートしているデータベースエンジンは以下

・Amazon Aurora
・PosgreSQL
・MySQL
・MariaDB
・OracleDB
・Microsoft SQL Server

Amazon Aurora

AWSが開発したリレーショナルデータベース。
PosgreSQLやMySQLと互換性があるので、アプリケーションをほとんど変更せずデータを移行することができる。

スループットはPosgreSQLの3倍やMySQLの5倍のスループット。

データは3ヶ所のアベイラビリティゾーンに格納される。
ひとつのアベイラビリティゾーンにつき2ヶ所のディスクに書き込みに行くため、結局6ヶ所に保存されます。
そのためほとんどダウンタイムなく使うことができる。

Aurora含めDBの流れはこのポッドキャストが詳しい。
fukabori.fm

パッチをいつ適用するのか

RDSでは曜日や時間帯をメンテナンスウインドウで指定するだけで、AWSが自動的にパッチを適用する。

マルチアベイラビリティゾーンを利用している場合、まずスレーブデータベースのメンテナンスを行う。
完了後、スレーブデータベースをマスターデータベースに昇格する。
最後に、メンテナンス前マスターデータベースをメンテナンスする。この旧マスターデータベースはスレーブデータベースのままになる。

バックアップと復元

標準設定の場合、バックアップは1日1回自動で行われる。データベースとトランザクションログを取得する。
スナップショットと自動バックアップは S3 に保存される。

aws.amazon.com

データベースのバックアップはストレージボリュームのスナップショットをとりデータベース全体のバックアップを取得する。
保存期間は最大35日分。手動でバックアップを取ることも可能。

aws.amazon.com

データベースを復元するためには、バックアップからデータベースインスタンスを作成して起動する。
トランザクションログも取得しているので、バックアップ取得時点に近い復元が可能。これをポイントタイムリカバリという。

RDSはデータベースインスタンスのトランザクションログを5分ごとに取得している。

マルチアベイラビリティゾーン

RDSを複数のアベイラビリティゾーンに構築すること。

Aurora以外のRDSデータベースは、マルチアベイラビリティゾーンインスタンスを作成すると、同時に異なるアベイラビリティゾーンにスレーブのインスタンスにもデータを複製する。

この構成にすることで、耐久性と可用性があがる。
なぜならマスターのアベイラビリティゾーンが障害になっても、スレーブがアベイラビリティゾーンに昇格させることができるから。

ただし、複数のアベイラビリティゾーンにデータを複製しているのでコストがかかる。

マルチアベイラビリティゾーン構成にしない場合、障害発生時のデータ切り戻しが直近5分以内までしか戻せないので、どうしても戻せない箇所が発生する。

データの欠損がおこらない点でマルチアベイラビリティゾーン構成に利がある。

リードレプリカ

マスターデータベースと同じデータベースを複製し、複製したほうを読み取り専用とすること。

読み取りスループットを増やすことでパフォーマンスを向上できる。

リードレプリカは、MySQL、MariaDB、PosgreSQL、Auroraで利用することができる。

マルチアベイラビリティゾーンや異なるリージョン間で構築できる。
マスターデータベースと異なるインスタンスタイプやストレージで構築することも可能。

マスターデータベース側との同期は非同期で行われる。

障害発生時の挙動

シングルアベイラビリティゾーン構成時

障害発生時、自動的に再起動する機能があるのでユーザ側で再起動のオペレーションは不要。

データはトランザクションログを使用したポイントタイムリカバリでの復元等行う。その場合5分単位での取得なので、どうしても戻せない箇所ができるので注意。

マルチアベイラビリティゾーン構成時

マスターデータベースに障害が発生した場合、自動的にスレーブへフェールオーバーを行う。

具体的には、

• マスターデータベースへの通信を停止
• スレーブデータベースをマスターへ昇格
• マスターで利用していたDNSレコードをスレーブのDNSレコードへ切り替える。

そのため、RDSのエンドポイントを変えず何も考えずシームレスに切り替えられる。だが、若干のダウンタイムが存在する。
また、マスターデータベースとスレーブデータベースは同期されているので、リカバリの必要はない。

データベース内のレコードの破損

オペレーションミスなどによってデータベースが破損した場合、バックアップからのリストアになる。

1. 障害が発生したRDSのエンドポイント名を控える
2. 別のエンドポイント名に変更する
3. バックアップから変更前のエンドポイント名でリストアする
4. 別のエンドポイント名にしたRDSを削除する。

Amazon RDS データベースインスタンスに接続できない場合

こちらを参考。
aws.amazon.com

qiita.com

まだデータベース構築中

DB インスタンスのサイズに応じて、インスタンスがネットワーク接続に利用可能になるまで 20 分ほどかかる場合があります。
DB インスタンスで接続が受け入れられることを確認します。
そのためには、RDS のコンソールで DB インスタンスの正常性と RDS DB インスタンスのライフサイクルを確認します。

焦らずに作成完了するまで待とう。

セキュリティグループの設定をしていない

デフォルトでは、DB インスタンスはアクセスを許可していません。
アクセスはセキュリティグループを介して許可されます。
アクセスを許可するには、特定の Ingress ルールと Egress ルールを設定した独自のセキュリティグループを作成する必要があります。

ネットワークACLの設定がおかしい

接続に使用しているソースからの接続を許可するように、RDS DB インスタンスの VPC セキュリティグループが設定されていることを確認します。
IP アドレス、IP アドレスの範囲、または別の VPC セキュリティグループを指定できます。
DB インスタンスに接続できるが、認証エラーが発生する場合は、「接続認証のトラブルシューティング」で説明しているように、DB インスタンスのマスターユーザーパスワードをリセットできます。

RDSのボトルネックを防ぐ

以下を実施することでRDS遅い問題を解決していく。

1. リードレプリカで読み取りスループットを増やすことでパフォーマンスを向上する。
2. ElastiCacheを使用して、メモリキャッシュをすることでデータベースへの負荷を減らす。

qiita.com