読者です 読者をやめる 読者になる 読者になる

AWSサポートへの質問と回答のメモ(データストア編)

あけましておめでとうございます。昨年もAWS上でインフラを構築・運用していく中で、AWSサポートにはずいぶんとお世話になりました。今回は年明け最初のブログということで、昨年AWSサポートに質問した内容とその回答をいくつかまとめてみたいと思います。

RDS (MySQL) のフェイルオーバーについての質問

背景と質問

あるサービスでRDS for MySQLを利用するにあたり、マルチAZ構成にしないことにしました。ここで気になったのが、ハードウェアレベルの障害が起きた時の対応です。マルチAZ構成の場合、ハードウェアレベルの障害が起きると自動でフェイルオーバーしてくれます。ではマルチAZ構成ではない場合、どうなるのでしょうか。わたし、気になります、ということで質問してみました。

回答

マルチAZ構成ではない場合、ホストの自動交換が行われるとのことでした。公式ページのこちらに書いてあったようです。よく読めよ、って話ですね!

また、ホストの自動交換は行われるものの、マルチAZ構成にして自動フェイルオーバーする場合よりDBのダウンタイムが長くなるとのことでした。どれぐらいのダウンタイムになるかは伺っていないのですが、こちらのフォーラムによれば、ホストの自動交換の場合15分、マルチAZ構成の場合3分だそうです。

ElasticCache (Redis) のエンドポイントについての質問

背景と質問

ElasticCache (Redis) のエンドポイントは、以下のようなパターンにあてはまっていると思います。

<Cache Cluster ID>.<6文字の英数字>.<Node ID>.<Region>.cache.amazonaws.com

例えば、my-queue.abcdef.0001.apne1.cache.amazonaws.comという感じです。

このとき、<6文字の英数字>はどうやって決まるのでしょうか。色々試してみるとAWSアカウントごとに一意な文字列のような気がしますが、本当にそうでしょうか。すごく地味な疑問ではあるのですが、運用中のサービスでは、これがわかるとエンドポイントの扱いがちょっと楽になるので、聞いてみました。

回答

やはり、アカウントIDごとに一意な文字列が生成されて使われるそうです。ただ、生成方法については教えられないとのことです。まあそうですよねw

RDSのメンテナンスについての質問

背景と質問

RDSのDBインスタンスにはメンテナンスウィンドウを設定できます。これを設定すると、ソフトウェアアップデート等のメンテナンスが、設定したウィンドウ内で行われるようになります。ここからは僕の思い込みなのですが、緊急でないメンテナンスは常に事前通知がある(少なくとも、コンソールやAPIから確認できる)、と考えていました。ただ実際に運用してみると、事前に知る機会なくウィンドウ内のメンテナンスが実施されている(短時間のダウンタイムが出ている)ようだったので、確認のため質問してみました。

回答

やはり、事前の通知なくウィンドウ内のメンテナンスを実施することがある、とのことでした。事前通知がないという問題は認識しているそうなので、いずれ改善されるかもしれません。現状だと、事前の通知なくウィンドウ内のメンテナンスがあった場合、メンテナンスがあったのか、それとも何か障害があったのか、すぐにわからないので、改善してもらえると嬉しいところです。

まとめ

今回は昨年AWSサポートの方に教えていただいたことを、データストア関連を中心にまとめてみました。最新のAWSでは事情が異なっている可能性はありますが、参考になれば幸いです。次回は監視関連を中心にまとめてみたいと思います。

追記:続きを書きました