事の始まり
関わっているウェブサービスの速度改善をしようということになりまして、まあそうなると大体はまず最初に思いつくのがキャッシュですよね。
EC2でサーバ動かして画像などのファイルはS3、DBはRDSと全てAWS上で動いており、キャッシュストアも例に漏れずElastiCacheを使用しておりました。
本来は最初に調べるべきだったんです、、、そうredisの余力を。
このウェブサービスはメディアだったので、画面数が多くフロントサイドのフラグメントキャッシュを使っていたためredisのメモリをかなり必要としました。
ステージングで気付けたので障害にはなりませんでしたが、なんも考えずにいたるところでキャッシュキャッシュしてたら死んでましたね。
キャッシュストアだけではなくセッション管理にも使っているため危なかったでした。
ごめん、、、こんなになるまで気づいてやれなくて。。。
ElastiCache自体のスケールアップについてはボタンをぽちぽちぽちとするだけでできちゃうので手順については書きません。
僕が知りたかったのは操作ではなく、何をしたらサービスが死ぬのか。マルチAZの構成に変更したらサービス死ぬ？バックアップとったら死ぬ？などなどなど。
これらの操作を行っている最中redis-cliでクエリを叩いてレスポンスが帰ってこない状況にならないかを調べました。
先に言っておきますと、railsアプリケーション側でキャッシュストアにアクセスできなくても落ちないように設計されていない場合に、ダウンタイムなしでスケールアップはできませんでした。
スケールアウト
できない。
スケールアウトはノードの追加ってことだと思うんですが、redis3.0から対応しているredis clusterでないと途中からのノードの追加はできないようでした。
早くelasticacheでredis3.0を使える日が来てくれることを祈るばかりです。
memcacheならできるんですけどね。
スケールアップ
スケールアップなら可能ですが、これも残念なことにスケールアップしている最中接続が切れます。
これはたとえレプリケーションやマルチAZの構成にしてあっても接続が切断されます。
理由は以下の通り。
http://qiita.com/dany1468/items/8946cd5e4c853b48bffd
説明に書いてある通り納得の理由ですね。
接続が切れる操作
スケールアップ マルチAZ+レプリケーション構成でもスケールアップ中レスポンスが帰ってこなくなる
接続が切れない操作
レプリケーションの作成
スナップショットの作成
マルチAZを使用していない状態から使用するに変更
どうしてもダウンタイムなしにしたい
- スナップショット作成
- スナップショットから新しいprimary クラスタ作成
- Webアプリケーションからキャッシュストアの向き先を新しく作成したredisのエンドポイントに設定
と、こんな感じでしょうか。。。どうしても1~3の間にこぼしてしまうデータがあるので、これ自体も完全なスケールアップ手順ではないので、完全とは言えないです。。。
間違ったことなどあればご指摘ください。
検討を祈ります。