【速報】Amazon RDS:メンテナンスへの柔軟な対応が可能に(pending-maintenance)
こんばんは、三井田です
仕事始めの最初の週末は、お客様からのこんなサポート問合せで劇的に幕を開けました。
RDSのMaintenanceの項目にAvailableが表示されました
本件について、2015/1/10 0:40 JST時点で、AWSからのリリースノートは発表されてません。
本稿の情報源は、現時点ではRDSのマネジメントコンソールとそのリンクから辿れる公式ドキュメントとなります。
- Amazon RDS User Guide: Upgrading and DB Instance Maintenance
- 注)現時点では「Operating System Upgrades for a DB Instance」の説明の画像がリンク切れとなってます
- Amazon RDS API Reference:
調査開始
えっ、何のことですか!?、と思いましてお客様のマネジメントコンソールや、社内のいくつかのアカウントを確認してみました。
わかったこと
画面の表示や、画面からリンクをたどって確認できるドキュメントより、以下のことが分かりました。
- 従来、アカウントルート宛のメールで告知されていた、AWS側理由によるRDSインスタンスのリブートなどのメンテナンスが、マネジメントコンソールやAPIで確認できるようになった(らしい)
- メンテナンス期間のリブートなどのうち、必須でないものは「お客様判断で見送る」ことが出来るようになった
- 今回は「Available」と表示されたが、必須の場合は「Required」と表示されるらしい
- ソース:Amazon RDS User Guide: Upgrading and DB Instance Maintenance
- メンテナンス期間を待たずに、希望の時に「即時にメンテナンスを実行する(Opt in)」ことが出来るようになった
まだわからないこと
逆に、以下の点は、まだちょっと把握できてません:
- メンテナンスの種類によって、表示や採り得る対応がどのように異なるのか?RDSのメンテナンスには次のような種類があるといわれています。
- 仮想ホストサーバ自体のアップデート(2014年9月末のXenのセキュリティ問題への対処など)
- RDSインスタンスのOSアップグレードやパッチ当て
- DBエンジンのマイナーバージョンアップグレード
RDSマネジメントコンソール
注)画像は、弊社社内アカウントで観測した同様の表示です。
注)確認の際に使う権限は、こちらで紹介したチューニングしたRead Only権限です。
RDSインスタンスの一覧画面
- 一覧に「Maintenance」という列が増えていました
- メイン画面の上部に、Maintenanceに関する注記バナーが表示されていました
一覧画面でタブをクリックして詳細を開いた画面
- 「Maintenance Details」という欄が増え、説明の文書へのリンクがありました
Instance Actionsプルダウンメニュー
- 「Upgrade Now」・「Upgrade at Next Window」という選択肢が増えました
- User Guideに説明のある「Delay Upgrade」という選択肢は今回は見当たりませんでした。「Available」ではなく「Required」の場合に表示されるのかもしれません。次項のCLIの結果とAPI Referenceに定義されている戻り値のTypeを照らし合わせると、今回は一部の項目のみ表示されており、「Available」ではなく「Required」の違いは改めて調査してまとめる必要があるかと思います
- 上記は、Maintenanceが「None」のインスタンスでは表示されません
AWS-CLI
AWS-CLI 1.7.0のリリースノートでは特に言及されてませんが、rdsコマンドに2つのサブコマンドdescribe-pending-maintenance-actionsとapply-pending-maintenance-actionが追加されてました。
- aws-cliのリファレンス:
ひとまず、表示系であるdescribe-pending-maintenance-actionsを実行してみます。
今回は、"Action": "os-upgrade"という戻り値より、DB Engineに関するアップグレードではないらしいことが分かります。
1つしかメンテナンスがないインスタンスの場合:
$ aws rds describe-pending-maintenance-actions { "PendingMaintenanceActions": [ { "PendingMaintenanceActionDetails": [ { "Action": "os-upgrade" } ], "ResourceIdentifier": "arn:aws:rds:ap-northeast-1:xxxxxxxxxxxx:db:db_instance_id" } ] }
メンテナンス対象が複数ある場合:
$ aws rds describe-pending-maintenance-actions { "PendingMaintenanceActions": [ { "PendingMaintenanceActionDetails": [ { "Action": "os-upgrade" } ], "ResourceIdentifier": "arn:aws:rds:ap-northeast-1:xxxxxxxxxxxx:db:db_instance_id_1" }, { "PendingMaintenanceActionDetails": [ { "Action": "os-upgrade" } ], "ResourceIdentifier": "arn:aws:rds:ap-northeast-1:xxxxxxxxxxxx:db:db_instance_id_2" } ] }
戻り値では、ARN形式で対象のインスタンスが戻ってますが、コマンド実行時に「db-instance-id」フィルタで確認したいインスタンスのみに絞ることが出来るようです。ARNで絞るという苦行よりは取っ付きやすいですね。
$ aws rds describe-pending-maintenance-actions --filters Name=db-instance-id,Values=db_instance_id { "PendingMaintenanceActions": [ { "PendingMaintenanceActionDetails": [ { "Action": "os-upgrade" } ], "ResourceIdentifier": "arn:aws:rds:ap-northeast-1:xxxxxxxxxxxx:db:db_instance_id" } ] }
「即時にメンテナンスを実行する(Opt in)」を捕捉しました!
この記事を書き始めたときに、表示されていた「available」というメンテナンス表示が、0時を回ったあと、消えてしまいました!
RDSのEvents画面を確認したところ、社内アカウントを管理しているどなたかが、「即時にメンテナンスを実行する(Opt in)」を実行した模様です。(神対応!)
せっかくなので、どのようなEventが記録されるのか紹介したいと思います。
RDSマネジメントコンソール
AWS-CLI
$ aws --output text rds describe-events EVENTS 2015-01-09T14:51:41.094Z Applying off-line patches to DB instance db_instance_id db-instance EVENTCATEGORIES maintenance EVENTS 2015-01-09T14:54:52.978Z DB instance shutdown db_instance_id db-instance EVENTCATEGORIES availability EVENTS 2015-01-09T14:59:49.421Z DB instance restarted db_instance_id db-instance EVENTCATEGORIES availability EVENTS 2015-01-09T15:00:27.043Z Finished applying off-line patches to DB instance db_instance_id db-instance EVENTCATEGORIES maintenance EVENTS 2015-01-09T15:00:47.228Z DB instance shutdown db_instance_id db-instance EVENTCATEGORIES availability EVENTS 2015-01-09T15:01:00.110Z DB instance restarted db_instance_id db-instance EVENTCATEGORIES availability
まとめ
- マネジメントコンソールという目に見える場にメンテナンス情報が表示され、分かりやすくなりました
- メンテナンスに対する対応を、即時に適用や適用せずにやり過ごすなど、選択できるようになった模様(追加調査や情報待ちです)
- 何より、APIが用意されたことで、監視システムでポーリングすることでも検知することが出来るようになったことが、運用屋さんとしてはうれしい限りです
- 一方課題:
- APIやマネジメントコンソールで出来る操作、その時の挙動はまだまだ詳細が見えてません
- APIの戻り値に「AutoAppliedAfterDate」「CurrentApplyDate」「ForcedApplyDate」と3種類のDateがありますがそれらの違いは要追加調査です
- 同じく、「Action」「ApplyAction」も、今回は「os-upgrade」でしたが、他に何があるかは要調査です