デブサミ2016「大規模Redisサーバ縮小化の戦い」講演メモ #devsumi

メモメモ。泥臭い話で面白かったです。

「大規模Redisサーバ縮小化の戦い」

• 駒井 祐人 氏
• (株)アカツキ
• ゲームのサーバサイド機能開発、インフラの設計構築・保守運用

Redisとは

• インメモリDB
• 5種類のキーバリューのデータ型
• ファイル永続化オプション

システムの問題点

• EC2サーバが20台に対して、AWSのElasticCache(Redis)が64台あった
• なぜ64台あったかというと、リリース直後にRedisの負荷問題があり、8台 => 64台になった
• 調査するとkeys("")を実行している箇所があった
• 当然お金がかかる(cache.m3.large * 64台 = 約135万円/月)
• 冗長化しんどいし、設定ファイルの記載も辛い
• ので、縮小化と冗長化の対処をしたい

現状整理

• 格納されているデータ
  • フレンド情報、セール情報、ランキング情報
• キーの件数
  • 1サーバに8DB、1DBあたり7万〜40万件
  • しかし各Redisで利用されていたのは1DBのみであった...(8=>64台にしたときにコピーして増やしてゴミが残ったままだった)

マージ方法の検討

• それっぽいツールがあったけど、makeできなかったので、自力で頑張ることに
• 案1: key/valueを全部抜き出すパターン
• 案2: dumpファイルを結合するパターン
  • ヘッダとフッタをいじればなんとかなりそうだし、計算も案1より少なそうなのでこっちを採用

dumpの構造

• バイナリデータとなっている
  • ヘッダが9バイト
  • DB番号が2バイト
  • その後、key/hashのデータが続いていく
  • DB番号・・・データ・・・(繰返)
  • 終端文字が1バイト
  • checksumが8バイト

マージ方法

• まず要らないゴミを消す
• 最初のDBのヘッダをつけて、そのあとにデータをつなげていく
• 最後にchecksumを付与する
  • checksumを無視するオプションもある
• redis-check-dumpを使って構造上問題ないか確認する

縮小化の流れ

• メンテナンス開始
• バックアップ
  • EC2でRedisを動かして、リードレプリカとして設定して、dump出力する
• ゴミデータ削除
• マージ
  • S3へ
• リストア
  • S3のパスを指定して起動
• メンテナンス終了

失敗談

• バックアップ失敗
  • ReadReplicaとして接続した際に、過去データをdlushされる前にsaveしても、正確にバックアップが取れない

結果

• かかった時間はトラブル含め4時間
• 縮小＆冗長化した上に、135=>38万円/月へコスト削減

縮小後に発生した事象

• Redisのコネクション上限に達した
  • APサーバ数 * Unicornのプロセス数 * DB数
  • しかし、ElastiCacheの接続数上限は変更できない
  • よって、今度はDB数を減らす必要がでてきた

再度マージ方法を検討

• 最初に検討した案1を採用(計算量は多いけど)
  • しかし、応答が返ってこない、、、時間はかかる
  • 複数サーバで並列に実行し、縮小することができた

7つのデータベース 7つの世界