Redisへと至る、gumiデータストアの歴史

6,666 views

Published on

Redisへと至る、gumiデータストアの歴史

  1. 1. Redisへと至る、 gumiデータストアの歴史
  2. 2. 目次 • • • • 自己紹介 gumiのデータストア一覧 gumiのアーキテクチャ変遷 AWS運用Tips
  3. 3. 目次 • • • • 自己紹介 gumiのデータストア一覧 gumiのアーキテクチャ変遷 AWS運用Tips
  4. 4. 自己紹介 • 本間 知教(ほんま とものり) • TwitterID @CkReal • Systems Operations Engineer (しすおぺ) • 入社歴約2年 • 国内アプリのサーバ運用 • アプリのイベントとかは作ってないです • 好きなAWSサービス:Amazon S3
  5. 5. 目次 • • • • 自己紹介 gumiのデータストア一覧 gumiのアーキテクチャ変遷 AWS運用Tips
  6. 6. gumiのデータストア一覧 TokyoTyrant
  7. 7. 目次 • • • • 自己紹介 gumiのデータストア一覧 gumiのアーキテクチャ変遷 AWS運用Tips
  8. 8. 1st(2009/09∼) • 当時のCTOが担当。mixiのサービスにアプリ提供 するまで、負荷に悩まされることがなかった… • 当時の構成 • オンプレミス(物理) • 2台構成 • app • db 当時のCTO
  9. 9. 2nd(2010/01∼) ∼ソーシャルゲーム黎明期∼
  10. 10. 2nd(2010/01∼) Before app RDS (MySQL5.1)
  11. 11. 2nd(2010/01∼) Before RDSの性能限界 =db.m2.4xlarge app RDS (MySQL5.1)
  12. 12. 2nd(2010/01∼) After memcached app M M M S S S TokyoTyrant RDS (MySQL5.1)
  13. 13. 2nd(2010/01∼) After • memcached選定の理由 • オーソドックスな使い方 • MySQLのクエリキャッシュ、ユーザのセッション情報 • TokyoTyrant選定の理由 • MySQLのwrite負荷軽減に利用 • ユーザの経験値情報、ゲーム内仮想通貨
  14. 14. 2nd(2010/01∼) After MySQL5.1 同時実行トランザクション 1023の壁 memcached app M M M S S S TokyoTyrant RDS (MySQL5.1)
  15. 15. 2nd(2010/01∼) After TokyoCabinet 64GBの壁 _人人 人人_ > 突然の死 < memcached AWS  ̄Y^Y^Y^Y ̄ メンテナンス負荷高し app (´・ω・`)M M M S S S TokyoTyrant RDS (MySQL5.1)
  16. 16. 2nd(2010/01∼) After memcached app i-fa4cc1f9のインスタンスが、 RDS M M M (MySQL5.1) 2013/08/20 S AM12:00 S S になくなってしまう((((;゚Д゚)))) TokyoTyrant
  17. 17. 2nd世代アプリの運用 • MySQLやTokyoTyrantに関する障害や制限が あったとはいえ、まだ十分使えていた ところが・・・
  18. 18. 3rd(2011/11∼) ∼数十万ユーザとの戦い∼
  19. 19. 3rd(2011/11∼) Before memcached app M M S static M S S TokyoTyrant RDS (MySQL5.5)
  20. 20. 3rd(2011/11∼) Before writeが追いつかない memcached app M M S static M S S TokyoTyrant RDS (MySQL5.5)
  21. 21. 3rd(2011/11∼) Before connectionは張れるが、 応答までに数秒かかる memcached app M M S static M S S TokyoTyrant RDS (MySQL5.5)
  22. 22. 3rd(2011/11∼) After memcached KVS(※) player-shard app SQS static others master jobq RDS (MySQL5.5)
  23. 23. 3rd(2011/11∼) After • MySQL(KVS)選定の理由 • redis,SpiderEngineは社内にノウハウなし • 使い慣れたプロダクトを利用することに決定 • 短期間で対応する必要があった • 当時の苦労は日経Linuxにて
  24. 24. 4th(2012/01∼) ∼redisの導入∼
  25. 25. 4th(2012/01∼) Before memcached MySQLKVS player-shard app SQS static others master jobq RDS (MySQL5.5)
  26. 26. 4th(2012/01∼) Before MySQLKVS memcached player-shard app インスタンス費用高騰 SQS (あとフェイルオーバー><) static others master jobq RDS (MySQL5.5)
  27. 27. 4th(2012/01∼) After memcached app SQS static jobq M M S player-shard S redis others master RDS (MySQL5.5)
  28. 28. 4th(2012/01∼) After • Redis選定の理由 • ソート済みセット型 • 開発者が手軽に触れる環境 • Redisに関する主な設定 • • • • 追記型(aof)ファイル dumpファイル 同時接続数(2.4はデフォルト1024だった) vm.overcommit_memory
  29. 29. 4th(2012/01∼) After memcached app SQS static jobq M M S player-shard S redis others master RDS (MySQL5.5)
  30. 30. 4th(2012/01∼) After 大容量のデータには向いていない (redisの水平分割してた時期も^^;) memcached app SQS static jobq M M S player-shard S redis others master RDS (MySQL5.5)
  31. 31. 4th(2012/01∼) After オペミスのデータクリア →slaveのdumpファイルから復旧 memcached app SQS static jobq M M S player-shard S redis others master RDS (MySQL5.5)
  32. 32. 4th(2012/01∼) After aofファイルが壊れる(´・ω・`) Bad file format reading the append only file: make a backup of your AOF file, then use ./redis-check-aof --fix <filename> memcached app SQS static jobq M M S player-shard S redis others master RDS (MySQL5.5)
  33. 33. 4th(2012/01∼) After memcached app SQS static jobq M S player-shard M_人人 人人_ master others > 突然の死 < S  ̄Y^Y^Y^Y ̄ RDS redis (MySQL5.5)
  34. 34. 5th(2013/06∼) ∼リアルタイムGvG∼
  35. 35. 5th(2013/06∼) • ソーシャルゲームの仕様多様化 • ユーザの行動結果を即時反映させたい • 使用例 • イベントランキング • プレイヤーのマッチング処理 ゲーム画面
  36. 36. 5th(2013/06∼) Now memcached app mq static jobq M M S player-shard S redis others master RDS (MySQL5.5)
  37. 37. その他のデータストア利用例 • MongoDB • 一定期間のアプリデバッグ用に使用 • infiniDB/RedShift • ユーザデータ解析用 • Amazon S3 • 稼働中のアプリログ&設定ファイル保存用 • Amazon Glacier • クローズしたアプリのファイル保存用 • S3の設定画面をちょいいじるだけ。便利^^
  38. 38. 目次 • • • • 自己紹介 gumiのデータストア一覧 gumiのアーキテクチャ変遷 AWS運用Tips
  39. 39. AWSデータストア運用Tips 1. 極力フルマネージドサービスを使えば安心 • 数百台の運用を行うと、ほぼ毎月どこかでEC2インス タンス(N/W)障害が生じる 2. データを保存する領域はEBSにしておく • EC2メンテナンスなどの対応を行う際、EBSの付け替 えで済むことが多い 3. masterとslaveは別AZにしておく • 同じAZだと、ホストサーバが同一のケースが生じる
  40. 40. ご清聴 ありがとうございました

×