【お知らせ】
— トゥギャッター公式@アプリ配信中😎 (@togetter_jp) 2017年8月4日
Togetterはメンテナンスのため明日8月5日（土）4:00（8月4日 28:00）より約1時間、アクセスできない状態になる予定です。
ご不便をおかけして申し訳ございませんが、何卒よろしくお願いいたします。
Ada sedikit pengumuman dari kami terkait jadwal maintenance system. Atas perhatian sahabat Chirpstory, kami ucapkan terimakasih. pic.twitter.com/2hGbjXSBqY
— chirpstory (@chirpstory) 2017年8月4日
今朝 2017/8/5 の4時から1時間を予定していた Togetter / Chirpstory のメンテナンスですが、RDS for MySQL の「5.7.11→5.7.17」 のバージョンアップがメインでした。
経緯
Amazon RDS での MySQL 5.7.11 は 2016/4/25 から提供されていますが、その後に機能追加やセキュリティおよび信頼性の向上を含む後続バージョンに置き換えられたため、 2017/10/25 にサポートの打ち切りが決まりました。
対象のバージョンで運用をしているなら、忘れないうちに対応しておく必要があります。
マイナーバージョン自動アップグレードなどRDSの変更を自動適用できる『メンテナンスウィンドウ』
通常 Amazon RDSの変更は『すぐに適用』する必要がなければ、週次の希望時間に自動適用してくれる『メンテナンスウィンドウ』を利用します。
ただし、通常DBの瞬断を運用上避けたい場合は、「メンテナンスウィンドウに頼らない手動での即時適用」、つまり「アプリケーションレベルでのメンテナンスモードへの切り替え」「適用後の動作確認」を行っておくに限ります。
また、そもそも今回の環境では『マイナーバージョン自動アップグレード』を有効にしていたにも関わらず、アップグレードが行われる気配がありませんでした。これは該当のバージョンが例外になっているのか、何かの仕様なのか不具合なのか不明でしたが（※『8/23以降に自動的に行われる』旨を最後に追記しました）、検証環境での動作を確認したところ数分間の接続断も認められたため、メンテナンスの実施を決めました。
もちろん事前に本番同等のデータ量、マシンリソースによる検証を十分に行い、想定される時間を見積もります。（こういう時はすぐに一時的なマシンリソースの調達が可能なPaaSの強みが出てきます）
ただ、その過程で既存の構成を見直していたところ、EBSストレージが旧世代ボリュームのマグネティックだったことが判明しました。
Amazon EBS ボリュームの種類 - Amazon Elastic Compute Cloud
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/EBSVolumeTypes.html
公式サイトの説明を確認する限り、マグネティックから汎用SSD（gp2）への入れ替えにより、スループット（最大 スループット/インスタンス）の性能は1.4倍程度、IOPS（最大 IOPS/インスタンス）も1.56倍程度の向上が見込めるようです。
一方で、汎用SSDにはマグネティックと比べ EBS I/O クレジット という制約があります（参考： I/O の特性とモニタリング - Amazon Elastic Compute Cloud ）。大量のディスクI/Oが見込まれる場合などでは注意が必要ですが、そもそも旧世代ボリュームの扱いになっているということもあり、わざわざ継続することもないと判断、汎用SSDへの移行を決めました。
この汎用SSDへの移行、全容量に比例するものの、当サービスが使用している数十GB程度の使用容量でも最終的に適用が完了するまで数時間ほど掛かることがわかりました（EBS I/O クレジット も大量消費して効率も落ちますし、Multi AZ構成もありうるクラスタ全てへのインポート作業ですからね…）。
ただし、最初の数十分で「インデックス作成のパフォーマンスが落ちる」「可用性が落ちる」ことを許容できるなら、正常動作は行えるようになることもわかりました。これならバッファ込みでも1時間程度でメンテナンスを解除できそうです。
メンテナンス実施とその効果
いざ本番メンテナンス。
4:05 からの『移行前のバックアップ』（Backing up DB instance）から始まり、『再起動』（DB instance restarted） → 『バージョンアップ適用』（Database instance patched） が 4:21 → 『更にSSD移行に備えてのバックアップ』（Backing up DB instance） → 『Multi AZ構成のためのフェイルオーバー開始』（Multi-AZ instance failover started） →『一部ストレージの移行完了』 （Applying modification to allocated storage） が 4:40 。この時点でそこそこのパフォーマンスで本番運用が可能になったため、メンテナンスを終了（一般開放）しました。
ここから全ての移行が完了（Finished applying modification to allocated storage）したのは 6:32 と、開始から2時間半程度かかっていますが、そこまで特にパフォーマンスに問題が起こることはありませんでした。
また、以下はELB（全サービスが運用されている本番Webサーバが接続されたもの）の平均レイテンシーのメンテナンス前後のグラフですが、約90msから約80msへ低下しており、10-20ms程度のパフォーマンス向上が認められました。
また、RDSそのものの『読み込みレイテンシー』にもメンテナンス後に明らかに安定化が認められました。
普段のユーザからのリクエストだけでなく、大量のデータを扱うバッチスクリプトの実行時間にも改善が期待できそうです。
（ドキドキしたけど、大きな事故も起こらなかったし、やってよかった…）
マイナーバージョンアップは2017/8/23以降にメンテナンスウィンドウで自動的に行われる （2017/8/18 追記）
本日書き込まれたブコメを拝見しました。
「『マイナーバージョン自動アップグレード』を有効にしていたにも関わらず、アップグレードが行われる気配がありませんでした」←うちに来たメールだと8/23以降のメンテナンスウィンドウで自動実施ってあった。 - t_yamo のコメント / はてなブックマーク
http://b.hatena.ne.jp/entry/343015763/comment/t_yamo
あれ…と思ってメールを見直してみると…
On August 23rd, 2017 we will automatically schedule upgrades for DB instances with the “Auto Minor Version Upgrade” setting set to “Yes”. These upgrades will occur during your regularly scheduled maintenance window.
本当だ。完全に見逃してました…。大変失礼しました。
本日からあと5日ほど後に控えてますが、メンテナンスウィンドウを有効にしておけば自動アップグレードが行われるようですね。
（ただ、Multi-AZであってもアップグレード時にはダウンタイムが発生してしまうため、サービスへの影響が心配される場合は手動でのメンテナンス実施を検討しましょう。）