AWSの運用において知っておくべきこと(その3)
前回は、SES(メール送信サービス)のバウンス率の話でしたが、今回はRDS(Relational Database Service)のお話です。
RDSのパッチリリース
RDSはAWSのマネージドサービスで、MySQLやORACLEをインスタンスを立ずとも、サービスとして機能を使うことができます。オンプレミスだと、初期設定にとても時間がかかるので（表領域の確保とか..）便利なことこの上ないです。
では、例えばMySQLに重要なセキュリティホールが見つかったとして、パッチを適用するにはどういう挙動をするのでしょうか。
メンテナンス時間の存在
RDSインスタンスを作成した際に、メンテナンス時間を設定したはずです（曜日・リリース）パッチリリースのメール通知は事前に来ますが、確認が漏れていたり、放置していると、このメンテナンス時間内で自動的に再起動がかかりアップデートされます。
メンテナンス時間という意味合いではある意味正しい挙動かもしれませんが、いつ適用されるか（再起動がかかるか）は分からないのです。
システム運用側としては、アプリからDBへの処理がどんなステータスか関係無く再起動がかかるので、非常に困りますよね。（親切なようで親切じゃない..）
DBへの通信不可の場合の例外処理をアプリのコードに組んでおかないと、場合によっては障害になり得ます。
マルチAZ構成にしておけば問題無いのでは？
では、オンプレミスのエンジニアなら冗長化されているDBサーバーのスタンバイの方からアップデートすれば良いのでは？と考えたりすると思います。AWSでいうとマルチAZでアベイラビリティーゾーンをまたぐ構成にすることで、プライマリ、セカンダリのインスタンスができているので、同じことができそうです。
しかし、DBエンジンのアップデートの場合はマルチAZの両方のAZのインスタンスが同時に再起動されます。
ダウンタイムについては、パッチの種類によるので、サポートに確認した方が確実です。パッチ以外にもSSL証明書更新があり、それもダウンタイムが発生します。
対策
DBのダウンタイムが発生するのは避けられないので、アプリ側との調整、メンテナンス時間を計画して手動でパッチを適用します。
RDSのメンテナンス時間の自動更新でOKなレベルの商用のシステムってあるのだろうか..
その他
はてなさんの「Mackerel」の監視が12/19昼間帯に停止する理由も、AWSのDBの証明書更新です。「Mackerel」便利ですが、AWSの監視にAWSに依存したシステムを使っているのもどうかなと僕は思います（SIerのクラウドサービスなら、そういうことはやらない）
システムが大きくなるなら、AWS以外の場所にNagiosやZABBIXサーバーを立てて使うのが良いかもしれません。(Nagios/ZABBIX両方経験あります)
