Elasticache for Redisを使っていたらサービスが固まった件

  • 3
    いいね
  • 0
    コメント

事象

ソーシャルサービスを運用して1年くらいになるのですが、ある日突然デザイナから
「なんかサービス遅くないですか?」と言われサイトを開くとすこぶる遅い!

アプリケーションを調べているとEC2からElasticacheへのアクセスでタイムアウトが
起きていることが分かりました。

そいでCloudWatchでメトリクスを見ているとプライマリサーバが
SwapUsage の値が急激に増加していることが確認出来ました。

しかーし、とにかくそういったものはAWSに任せて突き進んできたものですから
どーしよ、どーしよとなっていたところセカンダリサーバがプライマリに昇格して
復旧となりました。この間、30分ほどです。

原因

  • reserved-memoryを設定していなかったこと

上記が原因でした。
これを設定しないとインスタンスのメモリをRedisですべて使い切ってしまう(maxmemory=reserved-memory)ようで、

ちゃんとRedis以外のメモリも確保していなかったので結果、スワップが発生する状態になっていました。

reserved-memoryの設定値

安全値としては 50% 程度(メモリ空間 maxmemory の半分程度)を設定頂くことで、BGSAVE による影響をほぼ回避できることが分かっているようです。

ちなみに私はRedisのversionが2.8.19だったのですが、2.8.22 以降のバージョンを利用している場合、目安としてメモリ空間 maxmemory の 20-30% 程度を設定頂くのが安全値だそうです。

AWSユーザガイド

まとめ

なんだかんだでも30分で自動で復旧してくれる。やっぱフルマネージドいい!って思ったと同時に
フルマネージドだからといってもしっかりユーザガイドを見て分かっておくことが重要ですね。

これは言い訳なのですが、私の会社では開発部とインフラ部が分かれており、
AWSの設定はすべてインフラ部がやることなので開発部がコンソールに触れることはあまりありません。
ですが、AWS使ってるんだからサービス側がもっとその領域に踏み込んでいくべきだと痛感しました。

私たちのように専業していてはAWSを使うメリットが消えてしまうように思うし、
かといって会社がある程度大きいと専業してしまいがちです。

ほかの会社さんがどのようにAWSを管理しているか気になりますね。