我调查了关于ElastiCache的Redis扩容和横向扩展
事情的起源
为了改善与我们相关的网络服务速度，当然首先想到的就是缓存。
我们在EC2上运行服务器，图片等文件存储在S3上，数据库使用RDS，全部在AWS上运行，缓存存储也没有例外，我们使用的是ElastiCache。
本来应该首先调查的是redis的余力，我错过了这一点。
由於這個網絡服務是基於媒體的，且有很多畫面，因此使用了前端碎片緩存，結果導致相當大量的redis內存需求。
幸好在測試階段發現了這個問題，所以並未造成故障，但如果不加以考慮，到處都是重複緩存的話就會完蛋了。
由於除了緩存存儲，還用於會話管理，所以情況很危險。
對不起，不能早點發現這個問題…
ElastiCache自体のスケールアップについてはボタンをぽちぽちぽちとするだけでできちゃうので手順については書きません。
僕が知りたかったのは操作ではなく、何をしたらサービスが死ぬのか。マルチAZの構成に変更したらサービス死ぬ？バックアップとったら死ぬ？などなどなど。
これらの操作を行っている最中redis-cliでクエリを叩いてレスポンスが帰ってこない状況にならないかを調べました。
提前说明，如果Rails应用程序没有设计成即使无法访问缓存存储也不会崩溃，那么无法在不停机的情况下扩容。
スケールアウト
できない。
スケールアウトはノードの追加ってことだと思うんですが、redis3.0から対応しているredis clusterでないと途中からのノードの追加はできないようでした。
早くelasticacheでredis3.0を使える日が来てくれることを祈るばかりです。
memcacheならできるんですけどね。
扩展规模
如果要扩大规模，是可能的，但不幸的是，在扩大规模过程中，连接会失效。
即使采用了复制或多区域配置，连接也会断开。
以下是理由：
这是根据解释写下来的可以令人信服的理由。
接続が切れる操作
即使在多AZ+复制配置中，规模扩大仍可能导致响应停止返回。
操作中不会断开连接
创建副本
创建快照
从未使用多个可用区 (Multi-AZ) 改为使用
我希望能够无间断地进行。
-
- 创建快照
-
- 从快照创建新的主集群
- 将缓存存储的目标设置为新创建的Redis端点，来自Web应用程序。
と、こんな感じでしょうか。。。どうしても1~3の間にこぼしてしまうデータがあるので、これ自体も完全なスケールアップ手順ではないので、完全とは言えないです。。。
如果有任何错误，请指正。
恳请您的审议。
