AWS RDS＠AWSリソース¶
はじめに¶
本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。
01. AWS RDSとは¶
記入中...
02. セットアップ¶
コンソール画面の場合¶
他のDBエンジンの比較¶
▼ DBMSに対応するRDB¶
| DBMS | RDB | 互換性 |
|---|---|---|
| AWS Aurora MySQL | AWS RDS | MySQL/PostgreSQL |
| MariaDB | AWS RDS | MariaDB |
| MySQL | AWS RDS | MySQL |
| PostgreSQL | AWS RDS | PostgreSQL |
▼ 機能の違い¶
RDBがAWS AuroraかAWS RDSかで機能に差があり、AWS Auroraの方が耐障害性や可用性が高い。
ただし、その分費用が高いことに注意する。
OSの隠蔽¶
▼ OSの隠蔽とは¶
AWS RDSは、EC2内にDBMSが稼働したものであるが、このほとんどが隠蔽されている。
そのためDBサーバーのようには操作できず、OSのバージョン確認やSSH公開鍵認証を行えない。
▼ 確認方法¶
Linux x86_64 (AMD64) が使用されているところまでは確認できるが、Linuxのバージョンは隠蔽されている。
AWS Auroraでも確認方法は同じである。
-- AWS RDSの場合
SHOW variables LIKE '%version%';
+-------------------------+------------------------------+
| Variable_name | Value |
+-------------------------+------------------------------+
| innodb_version | 5.7.0 |
| protocol_version | 10 |
| slave_type_conversions | |
| tls_version | TLSv1,TLSv1.1,TLSv1.2 |
| version | 5.7.0-log |
| version_comment | Source distribution |
| version_compile_machine | x86_64 |
| version_compile_os | Linux |
+-------------------------+------------------------------+
04. メンテナンスウインドウ¶
メンテナンスウインドウ¶
DBクラスター/DBインスタンスの設定の変更をスケジューリングさせる。
メンテナンスの適切な曜日/時間帯¶
AWS CloudWatch MetricsのDatabaseConnectionsメトリクスから、DBの接続数が低くなる時間帯を調査し、その時間帯にメンテナンスウィンドウを設定する。
また、メンテナンスウィンドウの実施曜日が週末であると、サイトが停止したまま休日を迎える可能性があるため、週末以外になるように設定する (メンテナンスウィンドウがUTCであることに注意) 。
『保留中の変更』『保留中のメンテナンス』¶
ユーザーが予定した設定変更は『保留中の変更』として表示される一方で、AWSによって定期的に行われるハードウェア/OS/DBエンジンのバージョンを強制アップグレードは『保留中のメンテナンス』として表示される。
『次のメンテナンスウィンドウ』を選択すれば実行タイミングをメンテナンスウィンドウの間設定できるが、これを行わない場合は『日付の適用』に表示された時間帯に強制実行される。
補足として保留中のメンテナンスは、アクションの『今すぐアップグレード』と『次のウィンドウでアップグレード』からも操作できる。
保留中のメンテナンスの状態¶
| 状態 | 説明 |
|---|---|
| 必須 | アクションは実行可能かつ必須である。実行タイミングは未定であるが、適用期限日には必ず実行され、これは延期できない。 |
| 利用可能 | アクションは実行できるが、推奨である。実行タイミングは未定である。 |
| 次のウィンドウ | アクションの実行タイミングは、次回のメンテナンスウィンドウである。後でアップグレードを選択することにより、『利用可能』の状態に戻すことも可能。 |
| 進行中 | 現在時刻がメンテナンスウィンドウに含まれており、アクションを実行中である。 |
『次のウィンドウ』状態の取り消し¶
設定の変更が『次のウィンドウ』状態にある場合、画面上からは『必須』や『利用可能』といった実行タイミングが未定の状態に戻せない。
しかし、CLIを使用すると戻せる。
$ aws rds describe-pending-maintenance-actions --output=table
-----------------------------------------------------------------------------------
| DescribePendingMaintenanceActions |
+---------------------------------------------------------------------------------+
|| PendingMaintenanceActions ||
|+---------------------+---------------------------------------------------------+|
|| ResourceIdentifier | arn:aws:rds:ap-northeast-1:<AWSアカウントID>:db:prd-foo-instance ||
|+---------------------+---------------------------------------------------------+|
||| PendingMaintenanceActionDetails |||
||+--------------------------+--------------------------------------------------+||
||| Action | system-update # 予定されたアクション |||
||| AutoAppliedAfterDate | 2022-01-31T00:00:00+00:00 |||
||| CurrentApplyDate | 2022-01-31T00:00:00+00:00 |||
||| Description | New Operating System update is available |||
||| ForcedApplyDate | 2022-03-30T00:00:00+00:00 |||
||+--------------------------+--------------------------------------------------+||
|| PendingMaintenanceActions ||
|+---------------------+---------------------------------------------------------+|
|| ResourceIdentifier | arn:aws:rds:ap-northeast-1:<AWSアカウントID>:db:prd-bar-instance ||
|+---------------------+---------------------------------------------------------+|
||| PendingMaintenanceActionDetails |||
||+--------------------------+--------------------------------------------------+||
||| Action | system-update |||
||| AutoAppliedAfterDate | 2022-01-31T00:00:00+00:00 |||
||| CurrentApplyDate | 2022-01-31T00:00:00+00:00 |||
||| Description | New Operating System update is available |||
||| ForcedApplyDate | 2022-03-30T00:00:00+00:00 |||
||+--------------------------+--------------------------------------------------+||
$ aws rds apply-pending-maintenance-action \
--resource-identifier arn:aws:rds:ap-northeast-1:<AWSアカウントID>:db:prd-foo-instance \
--opt-in-type undo-opt-in \
--apply-action <取り消したいアクション名>
『保留中の変更』の取り消し¶
保留中の変更を画面上からは取り消せない。
しかし、CLIを使用すると戻せる。
$ aws rds modify-db-instance \
--db-instance-identifier prd-foo-instance \
<変更前の設定項目> <変更前の設定値> \
--apply-immediately
05. ダウンタイム¶
ダウンタイムの発生条件¶
| 変更する項目 | ダウンタイムの有無 | 補足 |
|---|---|---|
| インスタンスクラス | あり | ・2個のインスタンスで同時にインスタンスクラスを変更すると、次のようなイベントを確認できる。インスタンスが複数回再起動することからわかる通り、長いダウンタイム (約6～8分) が発生する。そのため、フェイルオーバーを利用したダウンタイムの最小化を行う。・https://dev.classmethod.jp/articles/rds-scaleup-instancetype/ ・プライマリーインスタンスのイベント  ・リードレプリカのイベント  |
| サブネットグループ | あり | |
| メンテナンスウィンドウ | 条件付きでなし | ダウンタイムが発生する操作が保留中になっている状態で、メンテナンス時間を現在が含まれるように変更すると、保留中の操作がすぐに適用される。そのため、ダウンタイムが発生する。 |
| パフォーマンスインサイト | 条件付きでなし | パフォーマンスインサイトの有効化ではダウンタイムが発生しない。ただし、有効化のためにパラメーターグループのperformance_schemaを有効化する必要がある。パラメーターグループの変更をDBインスタンスに反映させる上で再起動が必要なため、ここでダウンタイムが発生する。 |
| バックアップウインドウ | 条件付きでなし | 0から0以外の値、0以外の値から0に変更した場合、ダウンタイムが発生する。 |
| パラメーターグループ | なし | パラメーターグループ自体の変更ではダウンタイムは発生しない。また、静的パラメーターはパラメーターグループの変更に合わせて適用される。ただし、動的パラメーターを変更した場合は、これをDBインスタンスに反映させるために再起動が必要であり、ここでダウンタイムが発生する。 https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithParamGroups.html |
| セキュリティグループ | なし | |
| マイナーバージョン自動アップグレード | なし | エンジンバージョンの変更にはダウンタイムが発生するが、自動アップグレードの設定にはダウンタイムが発生しない。 |
| ストレージのAutoScaling | なし |
06. フェイルオーバー¶
AWS RDSのフェイルオーバーとは¶
スタンバイレプリカがプライマリーインスタンスに昇格する。
フェイルオーバーによるダウンタイムの最小化¶
DBインスタンスがマルチAZ構成の場合、以下の手順を使用してダウンタイムを最小化できる。
(1)-
アプリケーションの接続先をプライマリーインスタンスにする。
(2)-
特定の条件下のみで、フェイルオーバーが自動的に実行される。
(3) AWS RDSのAWS RDSでは条件に当てはまらない場合、リードレプリカを手動でフェイルオーバーさせる。
(4) フェイルオーバー時に約1～2分のダウンタイムが発生する。
フェイルオーバーを使用しない場合、DBインスタンスの再起動でダウンタイムが発生するが、これよりは時間が短いため、相対的にダウンタイムを短縮できる。
07. イベント¶
コンソール画面ではイベントが英語で表示されているため、リファレンスも英語でイベントを探した方が良い。
08. AWS RDSプロキシ¶
AWS RDSプロキシとは¶
クラウドDBプロキシとして働く。
コネクションプールの管理¶
アプリからAWS RDSにクエリが送信された時、コネクションを新しく作成せずに、コネクションプール内の非アクティブなコネクションを再利用し、AWS RDSに転送する。
アプリからDBのインスタンスに直接的にクエリを送信する場合、アプリはAWS RDSの同時接続の上限数 (インスタンスタイプで決まる) を考慮しない。
そのため、接続数が多くなりやすいアプリ (例：AWS Lambda、マルチスレッド) を使用していると、アプリが無制限にコネクションを新しく作成することになる。
その結果、アプリのコネクションがAWS RDSの同時接続の上限数を超えて接続してしまい、AWS RDSがエラーを返却してしまう。
AWS RDSプロキシは、AWS RDSの同時接続の上限数を考慮しつつ、コネクションプールから非アクティブなコネクションを再利用するため、アプリがAWS RDSの同時接続の上限数を超えて接続することがない。
