発生した事象
Aurora MySQLで、ライターインスタンスの性能をあげるために
インスタンスクラスを変更したところ、暗黙的にフェイルオーバーが発生して、意図せずリーダーインスタンスの１つが昇格してしまいました。
背景
OPENLOGIでは、今年2月にデータベースをRDS for MySQLからAurora MySQLに移行しました。
移行前の構成は
- プライマリー（ソース）インスタンス
- リードレプリカ複数台
となっていました。
ここで、プライマリーインスタンスとリードレプリカについては
弊社のアプリケーション側からのデータベース利用方法の都合で
参照系クエリでもプライマリーインスタンスに接続するものが多く
リードレプリカの利用は限定的であったため、
インスタンスサイズは、プライマリーよりも少し弱いものを使っていました。
Aurora移行プロジェクトに置いては
まず何よりも「移行を成功させること」に最重点を置いたため
RDS for MySQLのときと構成を変えないように、以下のようにしました。
- Auroraクラスター
- ライターインスタンス1台
- リーダーインスタンス複数台
Auroraインスタンスの識別子を、RDS for MySQLのときと同じものにすることで
リプレイス前後でアプリケーションから参照するときのエンドポイントが変わらないようにしました。
（ちなみにこちらは、移行後にアプリケーション側の設定を変更して、クラスタエンドポイントを利用するように変更しています）
インスタンスクラスについては、アプリケーション側からのワークロードは変わらないので
移行前と同様、リーダーインスタンスは、ライターインスタンスより少し弱いものを利用していました。
ことの発端
社内で、今度リリースする機能のパフォーマンス計測がしたいと依頼があり
そのため、ステージ環境のデータベースを、一時的に本番環境のデータベースと同じインスタンスクラスにしてほしい、とのことでした。
弊社のステージ環境も、データベースの構成は本番と同様ですが
インスタンスクラスは本番より1段弱いものを使っていました。
本番環境を想定した計測とのことなので、依頼を受けて
ステージ環境のライターインスタンスのインスタンスクラスをおもむろに変更しました。
※画像はこの記事執筆のために作成したものです。実際のインスタンスクラスとは異なります。
事象発生
しばらく、Webコンソールをちらちらみながら、ステータスみて進捗状況を確認していたのですが
ふと、目をやると、ある異変に気づきました。
ライターインスタンス「これって・・・これってもしかして！」
リーダーインスタンス「これってもしかして本当に」
ライターインスタンス・リーダーインスタンス「入れ替わってる！？」
（著作権配慮のため画像省略）
こまったこと
予期せぬフェイルオーバーが発生してしまい、こまったことになりました。
というのも、背景で触れた通り、弊社のデータベース構成では
ライターインスタンスとリーダーインスタンスのインスタンスクラスが異なっていたため
フェイルオーバーしてしまうと、本来強くしたかったライターインスタンスの方がリーダーに降格してしまい
もともと弱いインスタンスクラスだったリーダーインスタンスが昇格してしまうので
このままではパフォーマンス検証になりません。
（今回は幸い設定変更中にWebコンソールをみていて、異変に気づいたので、パフォーマンス検証前に対応でき、大事にはいたりませんでした）
対処方法
今回は、Webコンソールのメニューから「フェイルオーバー」の機能で
手動でフェイルオーバーを発生させ、もとの構成に戻しました。
フェイルオーバー後の状態
ちなみに、単にライターインスタンスを再起動させるだけでは、フェイルオーバーは発生しませんでした。
今回の気付き
Auroraには自動フェイルオーバー機能がある事自体はわかっていたのですが
まさかインスタンスクラスの変更という操作で暗黙的にフェイルオーバーが発生するのは想定外でした。
もっとも、Auroraの気持ちに立ってみると
「あれ？ライターくん、息してない？いかん、これは入れ替えなきゃ！」ってなりますよね。
そもそも元を正すと、Auroraにて、RDS for MySQLで運用していたのと同じ構成を取り続けていること自体に課題がありました。
Auroraでは自動フェイルオーバー機能があって、ライターに障害が発生した際に
リーダーが自動的に昇格するのだから
ライターとリーダーは同じインスタンスクラスにしておかないと
フェイルオーバーしました
→ フェイルオーバーで昇格したインスタンスがスペック不足
→ さらなる2次被害が・・・
という未来が十分に予測できます。
RDS for MySQLの頃は、諸事情あってマルチAZ構成はとっておらず
プライマリーの障害発生時は手動対応が必要になる、というのはそういうリスク混みで運用していたのですが
せっかくAuroraで耐障害性・可用性が向上する機能があるのだから
Aurora Wayにのっとった、最適な構成にする必要があるな、と気づきました。
こちらについては、現在社内で検討しているところです。
Discussion