SlideShare una empresa de Scribd logo
1 de 102
Descargar para leer sin conexión
⼤大規模Redisサーバ縮⼩小化の戦い
2016/02/18
株式会社アカツキ	
  	
  駒井 祐人
2
⽒氏名:駒井  祐⼈人
経歴:
・2012〜~2015    NTTデータ
  官公庁システムのインフラ設計/構築
・2015〜~2016    アカツキ
  ゲームのサーバサイド機能開発
  インフラの設計構築、運⽤用保守
趣味:
キャンプ、フェス、ドラム、でんぱ組
  感情報酬社会を⽬目標に、明るく楽し
いエンジニアリングを⽇日々⽬目指してい
ます。
⾃自⼰己紹介
  ※よく未成年年と間違えられます
使っている技術:
3
創業6年年⽬目のベンチャー企業
iOS/Androidのネイティブアプリのサービスを展開
アカツキって?
サウザンド
メモリーズ
シンデレラ
イレブン
シンデレラ
ナイン
※本⽇日はこういったアプリを
開発/運⽤用している中での
インフラのお話をします
4
直近4年年の収益成⻑⾧長率率率  2,106%  ⽇日本第1位  受賞
“働きがいのある会社ランキングベストカンパニー”  3年年連続受賞  
アカツキって?
Tips  Pitch
(毎朝)
︎マンスリーパーティ
(毎⽉月)
︎Good  And  New
(毎朝)
5
AWSのElastiCache(Redis)を64台から8台にしたノウハウ
  
  話すこと
  ・Redisのdumpのバイナリ構造
  ・Redisのdumpのマージ⽅方法
  ・マージ後に発⽣生した接続数トラブル
  話さないこと
  ・格納するデータ構造の⼯工夫
  ・Redisのチューニング⽅方法
今⽇日話すこと
6
前提
  ・Redisとは
  ・システムの問題点
  ・64台になった経緯、64台の影響
縮⼩小化の流流れ
  ・現状のRedisの構造の整理理
  ・マージ⽅方法の検討
  ・Redisのdumpのバイナリ構造
  ・縮⼩小化の流流れ
発⽣生したトラブル等
  ・困ったこと、当⽇日発⽣生したこと
  ・縮⼩小結果、縮⼩小後に発⽣生したトラブル
  ・まとめ
⽬目次
7
Redisとは
・インメモリデータベース  →  ⾼高速
・5種類のキー/バリューのデータ型  →  複数の⽤用途
・ファイル永続化オプション  →  信頼性
どういうときに使われる?
・セッション情報のキャッシュ
・クエリのキャッシュ
・弊社では冒険に⾏行行く際のフレンド情報や、
  ショップのセール情報などに
そもそもRedisって?
8
・EC2が20台運⽤用に対して
システムの問題点
EC2 20台
9
・Redis  (ElastiCache)  サーバが64台
システムの問題点
Redis 64台
10
・元々は8台運⽤用だった
・リリース当初、Redisの負荷が激増した。
・緊急対応で64台までスケールアウト
なぜ64台になったのか?
11
・調査すると、keys(“*”)を実⾏行行している箇所があった。
なぜ64台になったのか?
12
・調査すると、keys(“*”)を実⾏行行している箇所があった。
なぜ64台になったのか?
13
・全てのサーバにリクエストが⾏行行くので、
  サーバ増やしても意味が無い
・レビュー漏漏れ+負荷テストでRedisのデータ量量のチェック
が漏漏れていた
なぜ64台になったのか?
14
・当然、お⾦金金がかかる
    cache.m3.large($0.240)  *  64台  *  1ヶ⽉月  *  (1ドル→120円)
                    =  135  万円/⽉月
64台運⽤用してみて
※  RedisはAWSのElastiCacheを使⽤用している。
    Redisはシングルスレッドのため、コア数1の
ノードタイプを採⽤用したかったが、コア数が少ない
ノードタイプは、メモリ量量も少ないため、バランス
を取ってcache.m3.largeを採⽤用している。
15
・冗⻑⾧長化に腰が重くなる
    128台はさすがに…64台でも起動上限引き上げてるのに
  また起動数上限数を緩和するのか…
・YAML(設定ファイル)に記載する
  項⽬目がめちゃくちゃ増える
64台運⽤用してみて
16
・冗⻑⾧長化に腰が重くなる
    128台はさすがに…64台でも起動上限引き上げてるのに
  また起動数上限数を緩和するのか…
・YAML(設定ファイル)に記載する
  項⽬目がめちゃくちゃ増える
64台運⽤用してみて
設定ファイルの⻑⾧長さ
17
・縮⼩小化…64台のRedisサーバを減らしたい!
・冗⻑⾧長化…マルチAZ対応させたい!
対処したい
64台のRedis
18
・縮⼩小化…64台のRedisサーバを減らしたい!
・冗⻑⾧長化…マルチAZ対応させたい!
対処したい
これぐらいにしたい!
19
・縮⼩小化…64台のRedisサーバを減らしたい!
・冗⻑⾧長化…マルチAZ対応させたい!
対処したい
冗⻑⾧長化してもこれくらい
20
・現状のRedisの構造、データ件数を整理理してみる
    インスタンスクラス:
      cache.m3.large  *  64台
    
    データの中⾝身:
      冒険に⾏行行く際のフレンド情報
      ショップのセール情報
      イベントのランキング情報
現状整理理
21
・キーの件数
現状整理理
22
・キーの件数
→あれ、何か全く同じデータ件数がいっぱいある
現状整理理
23
・キーの件数                        ・設定ファイル
→設定ファイルと⽐比較してみる
現状整理理
24
・キーの件数                        ・設定ファイル
→各Redisで使っているdbは1個だけ
現状整理理
25
・なぜこんなことになったのか?
現状整理理
当時のデータ構造
↓
コピーして
ノード数を増やした
26
・なぜこんなことになったのか?
現状整理理
当時のデータ構造
↓
コピーして
ノード数を増やした
27
・なぜこんなことになったのか?
現状整理理
当時のデータ構造
↓
コピーして
ノード数を増やした
28
・なぜこんなことになったのか?
現状整理理
当時のデータ構造
↓
コピーして
ノード数を増やした
29
・なぜこんなことになったのか?
現状整理理
当時のデータ構造
↓
コピーして
ノード数を増やした
30
・なぜこんなことになったのか?
現状整理理
当時のデータ構造
↓
コピーして
ノード数を増やした
31
・キーの件数
全体だとこんな感じ
現状整理理
32
マージ⽅方法の検討
・Redisってマージできんの?
    Redisのドキュメントを調べる
    AWSのドキュメントを調べる
    Github上のそれっぽいツール
33
マージ⽅方法の検討
・Redisってマージできんの?
    Redisのドキュメントを調べる  →  のってない
    AWSのドキュメントを調べる
    Github上のそれっぽいツール
34
マージ⽅方法の検討
・Redisってマージできんの?
    Redisのドキュメントを調べる  →  のってない
    AWSのドキュメントを調べる  →  のってない
    Github上のそれっぽいツール
35
マージ⽅方法の検討
・Redisってマージできんの?
    Redisのドキュメントを調べる  →  のってない
    AWSのドキュメントを調べる  →  のってない
    Github上のそれっぽいツール  →  makeが通らない  w
36
■案1  
Key/Valueを抜き出し別dbに⼊入れていく
マージ⽅方法の検討
■案2
  dumpファイルを結合する
dump dump+ dump+
5つの
データ型
ごとに計算
37
■案1  
Key/Valueを抜き出し別dbに⼊入れていく
マージ⽅方法の検討
■案2
  dumpファイルを結合する
dump dump+ dump+
5つの
データ型
ごとに計算
  以下の理理由で案2を採⽤用
  ・計算量量が少なく
    ⾼高速にマージできそう
  ・触るのはヘッダフッタの構造部分のみで
    中⾝身のデータを触る必要がない
38
Redisはデフォルトで16個のdbを持っている
Redisのdumpの構造
Redis
・・・ db15db0 db1 db2
dump
39
Redisのdumpの中⾝身
Redisのdumpの構造
ヘッダ
DB番号
db0:FE00
終端⽂文字
FF
CRC64  
checksum
9byte
DB番号
db1:FE01
データ
データ
・
・
・
2byte
1byte
8byte
データ
40
Redisのdumpの中⾝身
Redisのdumpの構造
DB番号
db0:FE00
終端⽂文字
FF
CRC64  
checksum
9byte
DB番号
db1:FE01
データ
データ
・
・
・
2byte
1byte
8byte
データ
ヘッダ
41
Redisのdumpの中⾝身
Redisのdumpの構造
ヘッダ
終端⽂文字
FF
CRC64  
checksum
9byte
DB番号
db1:FE01
データ
データ
・
・
・
2byte
1byte
8byte
データ
DB番号
db0:FE00
42
Redisのdumpの中⾝身
Redisのdumpの構造
ヘッダ
DB番号
db0:FE00
終端⽂文字
FF
CRC64  
checksum
9byte
DB番号
db1:FE01
データ
データ
・
・
・
2byte
1byte
8byte
データ
43
Redisのdumpの中⾝身
Redisのdumpの構造
ヘッダ
DB番号
db0:FE00
CRC64  
checksum
9byte
DB番号
db1:FE01
データ
データ
・
・
・
2byte
1byte
8byte
データ
終端⽂文字
FF
44
Redisのdumpの中⾝身
Redisのdumpの構造
ヘッダ
DB番号
db0:FE00
終端⽂文字
FF
CRC64  
checksum
9byte
DB番号
db1:FE01
データ
データ
・
・
・
2byte
1byte
8byte
データ
45
ごちゃごちゃしましたが、要は、こういうわけです
Redisのdumpの構造
Redis
・・・ db15db0 db1
Redis
db
0
デ
ー
タ
ヘ
ダ
db
15
デ
ー
タ
終
端
⽂文
字
チ
ク
サ
ム
db
1
デ
ー
タ
・・・
9byte 1byte 8byte
46
・話を元に戻すと、こんなデータ構造でした
マージ⽅方法
47
・ゴミを消します
  →シンプルなシングルDBの構成に
マージ⽅方法
48
・まず2つのdumpのマージ⽅方法について考えてみる
マージ⽅方法
49
・まず2つのdumpのマージ⽅方法について考えてみる
マージ⽅方法
Redis-‐‑‒01
db
0
デ
ー
タ
ヘ
ダ
終
端
⽂文
字
チ
ク
サ
ム
Redis-‐‑‒02
db
1
デ
ー
タ
ヘ
ダ
終
端
⽂文
字
チ
ク
サ
ム
9byte 1byte 8byte
9byte 1byte 8byte
50
・まず2つのdumpのマージ⽅方法について考えてみる
マージ⽅方法
Redis-‐‑‒01
db
0
デ
ー
タ
ヘ
ダ
終
端
⽂文
字
チ
ク
サ
ム
Redis-‐‑‒02
db
1
デ
ー
タ
ヘ
ダ
終
端
⽂文
字
チ
ク
サ
ム
9byte 1byte 8byte
9byte 1byte 8byte
Redis-‐‑‒01の
後ろ9byteを削除
Redis-‐‑‒02の
前の9byteを削除
51
・まず2つのdumpのマージ⽅方法について考えてみる
マージ⽅方法
Redis-‐‑‒01
db
0
デ
ー
タ
ヘ
ダ
終
端
⽂文
字
チ
ク
サ
ム
Redis-‐‑‒02
db
1
デ
ー
タ
ヘ
ダ
終
端
⽂文
字
チ
ク
サ
ム
9byte 1byte 8byte
9byte 1byte 8byte
Redis-‐‑‒01の
後ろ9byteを削除
Redis-‐‑‒02の
前の9byteを削除
Redis  (New)
db
0
デ
ー
タ
ヘ
ダ
終
端
⽂文
字
チ
ク
サ
ム
9byte 1byte 8byte
db
1
デ
ー
タ
52
・試しにローカル環境でリストアしてみる
(ローカルのredis-‐‑‒serverを停⽌止した状態で、dumpファイルを差し替えると、次
に起動する際に、差し替えたdumpファイルを読み込んで起動してくれます)
マージ⽅方法
$ cp –p merged_dump.rdb dump.rdb
$ redis-server /usr/local/etc/redis.conf
dump
ローカルPC
redis-‐‑‒server
53
マージ⽅方法
(カチャカチャ・・・)
(ッターン!)
$ cp –p merged_dump.rdb dump.rdb
$ redis-server /usr/local/etc/redis.conf
・試しにローカル環境でリストアしてみる
(ローカルのredis-‐‑‒serverを停⽌止した状態で、dumpファイルを差し替えると、次
に起動する際に、差し替えたdumpファイルを読み込んで起動してくれます)
54
・試しにローカル環境でリストアしてみる
マージ⽅方法
_⼈人⼈人⼈人⼈人_
>  エラー!!<
 ̄Y^Y^Y^ ̄
(カチャカチャ・・・)
(ッターン!)
55
・よーく⾒見見ると・・・
マージ⽅方法
Redis-‐‑‒01
db
0
デ
ー
タ
ヘ
ダ
終
端
⽂文
字
チ
ク
サ
ム
Redis-‐‑‒02
db
1
デ
ー
タ
ヘ
ダ
終
端
⽂文
字
チ
ク
サ
ム
9byte 1byte 8byte
9byte 1byte 8byte
Redis-‐‑‒01の
後ろ9byteを削除
Redis-‐‑‒02の
前の9byteを削除
Redis  (New)
db
0
デ
ー
タ
ヘ
ダ
終
端
⽂文
字
チ
ク
サ
ム
9byte 1byte 8byte
db
1
デ
ー
タ
56
・よーく⾒見見ると・・・
マージ⽅方法
Redis-‐‑‒01
db
0
デ
ー
タ
ヘ
ダ
終
端
⽂文
字
チ
ク
サ
ム
Redis-‐‑‒02
db
1
デ
ー
タ
ヘ
ダ
終
端
⽂文
字
チ
ク
サ
ム
9byte 1byte 8byte
9byte 1byte 8byte
Redis-‐‑‒01の
後ろ9byteを削除
Redis-‐‑‒02の
前の9byteを削除
Redis  (New)
db
0
デ
ー
タ
ヘ
ダ
終
端
⽂文
字
チ
ク
サ
ム
9byte 1byte 8byte
db
1
デ
ー
タ
ここのチェックサムが
Redis02全体のチェックサムに
なっている
57
・CRC64  checksum(8byte)を付与することでおk
・checksumを無視する設定も
マージ⽅方法
rdbchecksum no
58
・CRC64  checksum(8byte)を付与することでおk
・checksumを無視する設定も
・安⼼心してください、
  dumpの構造が問題ないか
  確認するコマンドありますよ
    
マージ⽅方法
rdbchecksum no
$ redis-check-dump [dumpファイル名]
59
どことどこをマージするか
59
元々のdb情報
60
どことどこをマージするか
60
ゴミデータ削除後
61
どことどこをマージするか
61
ゴミデータ削除後
62
どことどこをマージするか
62
63
どことどこをマージするか
63
64
どことどこをマージするか
64
65
どことどこをマージするか
65
Redis-‐‑‒01
(New)
66
どことどこをマージするか
66
Redis-‐‑‒01
(New)
Redis-‐‑‒02
(New)
67
どことどこをマージするか
67
Redis-‐‑‒01
(New)
Redis-‐‑‒02
(New)
68
どことどこをマージするか
68
Redis-‐‑‒01
(New)
Redis-‐‑‒02
(New)
69
どことどこをマージするか
69
Redis-‐‑‒01
(New)
Redis-‐‑‒02
(New)
Redis-‐‑‒03
(New)
70
どことどこをマージするか
70
Redis-‐‑‒01
(New)
Redis-‐‑‒02
(New)
Redis-‐‑‒03
(New)
Redis-‐‑‒04
(New)
71
縮⼩小化の流流れ
メンテナンス開始
バックアップ
ゴミデータ削除
マージ
リストア
メンテナンス終了了
72
縮⼩小化の流流れ
メンテナンス開始
バックアップ
ゴミデータ削除
マージ
リストア
メンテナンス終了了
・EC2をReadReplicaとして接続
$ redis-cli slaveof [ホスト名] 6379
Redis
EC2
redis-‐‑‒server
73
縮⼩小化の流流れ
メンテナンス開始
バックアップ
ゴミデータ削除
マージ
リストア
メンテナンス終了了
・バックアップ(dump)取得
※  AWS上でスナップショットは取得できるが、
    ファイル出⼒力力ができない
$ redis-cli save
Redis
redis-‐‑‒server
EC2
dump
dump
74
縮⼩小化の流流れ
メンテナンス開始
バックアップ
ゴミデータ削除
マージ
リストア
メンテナンス終了了
・バックアップ(dump)取得
$ redis-cli save
Redis
redis-‐‑‒server
EC2
dump
dump
AWSさん、何とかしてください!!w
75
縮⼩小化の流流れ
メンテナンス開始
バックアップ
ゴミデータ削除
マージ
リストア
メンテナンス終了了
・指定のdbをflushする ✕  64台
redis = Redis.new(host: HOSTNAME, port: 6379)
redis.select(dbnum)
redis.flushdb
Redis
redis-‐‑‒server
EC2
76
縮⼩小化の流流れ
メンテナンス開始
バックアップ
ゴミデータ削除
マージ
リストア
メンテナンス終了了
・ゴミ消去後、再度度dump取得
$ redis-cli save
Redis
redis-‐‑‒server
EC2
dump
dump
77
縮⼩小化の流流れ
メンテナンス開始
バックアップ
ゴミデータ削除
マージ
リストア
メンテナンス終了了
・dumpデータをマージする
Redis
redis-‐‑‒server
EC2
New
dump
dump
dump
78
縮⼩小化の流流れ
メンテナンス開始
バックアップ
ゴミデータ削除
マージ
リストア
メンテナンス終了了
・S3にアップロードし、権限付与する
  →aws-‐‑‒scs-‐‑‒s3-‐‑‒readonly@amazon.comに
    開く/ダウンロードの権限
Redis
S3
redis-‐‑‒server
EC2
New
dump
dump
dump
79
縮⼩小化の流流れ
メンテナンス開始
バックアップ
ゴミデータ削除
マージ
リストア
メンテナンス終了了
・S3のパスを指定して、Redisを起動
Redis
S3
Redis(New)
redis-‐‑‒server
EC2
New
dump
dump
dump
80
縮⼩小化の流流れ
メンテナンス開始
バックアップ
ゴミデータ削除
マージ
リストア
メンテナンス終了了
・設定ファイル変更更
・キーの件数⽐比較
・実機検証
Redis
S3
Redis(New)
redis-‐‑‒server
EC2
New
dump
dump
dump
81
縮⼩小化の流流れ
メンテナンス開始
バックアップ
ゴミデータ削除
マージ
リストア
メンテナンス終了了
・設定ファイル変更更
・キーの件数⽐比較
・実機検証
Redis
S3
Redis(New)
redis-‐‑‒server
EC2
New
dump
dump
dump
82
1.  バックアップ失敗
※  ReadReplicaとして接続した際に、過去のデータがflushされる前にsaveを実⾏行行
しても、正確にバックアップが取れない
失敗談
Redis
redis-‐‑‒server
EC2
dump
dump
※  log出⼒力力の設定:syslog-‐‑‒enabled  yes    →  syslog、  logfile  stdout  →  標準出⼒力力
83
1.  バックアップ失敗
※  ReadReplicaとして接続した際に、過去のデータがflushされる前にsaveを実⾏行行
しても、正確にバックアップが取れない
失敗談
Redis
redis-‐‑‒server
EC2
dump
dump
※  log出⼒力力の設定:syslog-‐‑‒enabled  yes    →  syslog、  logfile  stdout  →  標準出⼒力力
84
2.  マージ後のdumpファイルはたった8個しかないのに
    オペミスで同じdumpファイルから2台サーバを⽴立立ち上げる
    ※  くれぐれも深夜作業にはご注意を・・・
失敗談
85
・想定通り縮⼩小することができた!!冗⻑⾧長化も!!
・かかった時間はトラブルも含め約4時間
縮⼩小前
  cache.m3.large  *  64台  →  135  万円/⽉月
縮⼩小+冗⻑⾧長化後
  cache.r3.large  *  8台  *  2(マルチAZ)  →  38  万円/⽉月
→冗⻑⾧長化しつつも約100万/⽉月  コスト削減!!
  (1ドル120円換算)
結果
86
しかし、数週間後・・・
87
突然のエラーの嵐嵐!!!
88
突然のエラーの嵐嵐!!!
89
・ゲームのあるスペシャルイベントでリクエスト数が激増
・サーバ台数をかなりの⼤大規模で増やした
・Redisのconnectionが上限に達してエラー
  ※  接続数の計算例例
      100(サーバ)  ✕  50(unicornプロセス)  ✕  16(DB)  =  80000  clients
→複数DBを使ったことがアダとなり、接続数が激増した
縮⼩小後に発⽣生した事象
接続数設定 実際の接続数
$ redis-cli –h [ホスト名] –p 6379 info
# Clients
connected_clients:64086
90
縮⼩小後に発⽣生した事象
リソースは余裕ありそうだし
接続数の上限を変更更すっか
91
・Redis(ElastiCache)の接続数の上限は変更更できない。
縮⼩小後に発⽣生した事象
・今度度はDB数を減らす必要がある
92
再度度縮⼩小することに
縮⼩小後のRedis
・今度度はDB数を減らす必要がある
93
再度度縮⼩小することに
縮⼩小後のRedis
・今度度はDB数を減らす必要がある
94
再度度縮⼩小することに
縮⼩小後のRedis
最終状態
・今度度はDB数を減らす必要がある
・問題点:
  →さきほどのマージ⽅方法が使うのが難しい
95
再度度縮⼩小することに
縮⼩小後のRedis
最終状態
96
■案1  
Key/Valueを抜き出し別dbに⼊入れていく
マージ⽅方法の検討
■案2
  dumpファイルを結合する
dump dump+ dump+
5つの
データ型
ごとに計算
97
■案1  
Key/Valueを抜き出し別dbに⼊入れていく
マージ⽅方法の検討
■案2
  dumpファイルを結合する
dump dump+ dump+
5つの
データ型
ごとに計算    今度度は案1を採⽤用
    ・計算量量は多いが
      複数dbをまたいでデータを統合できる。
98
・試しに検証環境で同じ環境を構築してやってみる
検証
Redis
redis-‐‑‒server
EC2
99
・試しに検証環境で同じ環境を構築してやってみる
  
検証
Redis
redis-‐‑‒server
EC2
・応答が返ってこない…
100
・試しに検証環境で同じ環境を構築してやってみる
  
とは⾔言え、それでもマージ時間だけでめちゃくちゃ時間がかかった
      1dump  12分  *  8dump  =  96分
(※  最初のバイナリ結合の⽅方法だと、数秒で全てのマージが終わるのに対して)
検証
Redis
redis-‐‑‒server
EC2
dump
・応答が返ってこない…
・直接ElastiCache(Redis)を操作するよ
り、ローカルでリストアしたデータを操作
したほうが早かった。
101
・複数サーバで並列列に実⾏行行し、
  なんとか縮⼩小することができた!!
・想定通り接続数が半分に!
結果
接続数
$ redis-cli –h [ホスト名] –p 6379 info
# Clients
connected_clients:30125
102
・2種類の⽅方法でRedisを縮⼩小化することに成功。
・dumpの構造を知ることで、⽐比較的容易易にマージ可能。
・複数dbを使うと、connection数に気をつける必要がある。
・We  are  hiring  !!
まとめ

Más contenido relacionado

La actualidad más candente

Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24Shin Ohno
 
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Kohei Tokunaga
 
Cesiumを動かしてみよう
Cesiumを動かしてみようCesiumを動かしてみよう
Cesiumを動かしてみようKazutaka ishizaki
 
CEDEC2019 大規模モバイルゲーム運用におけるマスタデータ管理事例
CEDEC2019 大規模モバイルゲーム運用におけるマスタデータ管理事例CEDEC2019 大規模モバイルゲーム運用におけるマスタデータ管理事例
CEDEC2019 大規模モバイルゲーム運用におけるマスタデータ管理事例sairoutine
 
Linux女子部 systemd徹底入門
Linux女子部 systemd徹底入門Linux女子部 systemd徹底入門
Linux女子部 systemd徹底入門Etsuji Nakai
 
ソーシャルアプリにおけるRedisの活用事例とトラブル事例
ソーシャルアプリにおけるRedisの活用事例とトラブル事例ソーシャルアプリにおけるRedisの活用事例とトラブル事例
ソーシャルアプリにおけるRedisの活用事例とトラブル事例leverages_event
 
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!mosa siru
 
インフラエンジニアの綺麗で優しい手順書の書き方
インフラエンジニアの綺麗で優しい手順書の書き方インフラエンジニアの綺麗で優しい手順書の書き方
インフラエンジニアの綺麗で優しい手順書の書き方Shohei Koyama
 
ストリーム処理を支えるキューイングシステムの選び方
ストリーム処理を支えるキューイングシステムの選び方ストリーム処理を支えるキューイングシステムの選び方
ストリーム処理を支えるキューイングシステムの選び方Yoshiyasu SAEKI
 
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)NTT DATA Technology & Innovation
 
ソーシャルゲーム案件におけるDB分割のPHP実装
ソーシャルゲーム案件におけるDB分割のPHP実装ソーシャルゲーム案件におけるDB分割のPHP実装
ソーシャルゲーム案件におけるDB分割のPHP実装infinite_loop
 
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話Kumazaki Hiroki
 
ネットワーク ゲームにおけるTCPとUDPの使い分け
ネットワーク ゲームにおけるTCPとUDPの使い分けネットワーク ゲームにおけるTCPとUDPの使い分け
ネットワーク ゲームにおけるTCPとUDPの使い分けモノビット エンジン
 
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)mosa siru
 
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのかシリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのかAtsushi Nakada
 
【Unite Tokyo 2019】Unityだったら簡単!マルチプレイ用ゲームサーバ開発 ~実践編~
【Unite Tokyo 2019】Unityだったら簡単!マルチプレイ用ゲームサーバ開発 ~実践編~【Unite Tokyo 2019】Unityだったら簡単!マルチプレイ用ゲームサーバ開発 ~実践編~
【Unite Tokyo 2019】Unityだったら簡単!マルチプレイ用ゲームサーバ開発 ~実践編~UnityTechnologiesJapan002
 
MongoDBが遅いときの切り分け方法
MongoDBが遅いときの切り分け方法MongoDBが遅いときの切り分け方法
MongoDBが遅いときの切り分け方法Tetsutaro Watanabe
 
AWS Black Belt Online Seminar 2016 Amazon EC2 Container Service
AWS Black Belt Online Seminar 2016 Amazon EC2 Container ServiceAWS Black Belt Online Seminar 2016 Amazon EC2 Container Service
AWS Black Belt Online Seminar 2016 Amazon EC2 Container ServiceAmazon Web Services Japan
 

La actualidad más candente (20)

Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24
 
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
 
Cesiumを動かしてみよう
Cesiumを動かしてみようCesiumを動かしてみよう
Cesiumを動かしてみよう
 
CEDEC2019 大規模モバイルゲーム運用におけるマスタデータ管理事例
CEDEC2019 大規模モバイルゲーム運用におけるマスタデータ管理事例CEDEC2019 大規模モバイルゲーム運用におけるマスタデータ管理事例
CEDEC2019 大規模モバイルゲーム運用におけるマスタデータ管理事例
 
Linux女子部 systemd徹底入門
Linux女子部 systemd徹底入門Linux女子部 systemd徹底入門
Linux女子部 systemd徹底入門
 
ソーシャルアプリにおけるRedisの活用事例とトラブル事例
ソーシャルアプリにおけるRedisの活用事例とトラブル事例ソーシャルアプリにおけるRedisの活用事例とトラブル事例
ソーシャルアプリにおけるRedisの活用事例とトラブル事例
 
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
 
インフラエンジニアの綺麗で優しい手順書の書き方
インフラエンジニアの綺麗で優しい手順書の書き方インフラエンジニアの綺麗で優しい手順書の書き方
インフラエンジニアの綺麗で優しい手順書の書き方
 
ストリーム処理を支えるキューイングシステムの選び方
ストリーム処理を支えるキューイングシステムの選び方ストリーム処理を支えるキューイングシステムの選び方
ストリーム処理を支えるキューイングシステムの選び方
 
nginx入門
nginx入門nginx入門
nginx入門
 
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
 
ソーシャルゲーム案件におけるDB分割のPHP実装
ソーシャルゲーム案件におけるDB分割のPHP実装ソーシャルゲーム案件におけるDB分割のPHP実装
ソーシャルゲーム案件におけるDB分割のPHP実装
 
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
 
ネットワーク ゲームにおけるTCPとUDPの使い分け
ネットワーク ゲームにおけるTCPとUDPの使い分けネットワーク ゲームにおけるTCPとUDPの使い分け
ネットワーク ゲームにおけるTCPとUDPの使い分け
 
自宅k8s/vSphere入門
自宅k8s/vSphere入門自宅k8s/vSphere入門
自宅k8s/vSphere入門
 
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
 
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのかシリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
 
【Unite Tokyo 2019】Unityだったら簡単!マルチプレイ用ゲームサーバ開発 ~実践編~
【Unite Tokyo 2019】Unityだったら簡単!マルチプレイ用ゲームサーバ開発 ~実践編~【Unite Tokyo 2019】Unityだったら簡単!マルチプレイ用ゲームサーバ開発 ~実践編~
【Unite Tokyo 2019】Unityだったら簡単!マルチプレイ用ゲームサーバ開発 ~実践編~
 
MongoDBが遅いときの切り分け方法
MongoDBが遅いときの切り分け方法MongoDBが遅いときの切り分け方法
MongoDBが遅いときの切り分け方法
 
AWS Black Belt Online Seminar 2016 Amazon EC2 Container Service
AWS Black Belt Online Seminar 2016 Amazon EC2 Container ServiceAWS Black Belt Online Seminar 2016 Amazon EC2 Container Service
AWS Black Belt Online Seminar 2016 Amazon EC2 Container Service
 

Destacado

Pythonで始めるWebアプリケーション開発
Pythonで始めるWebアプリケーション開発Pythonで始めるWebアプリケーション開発
Pythonで始めるWebアプリケーション開発Takahiro Kubo
 
PostgreSQLの冗長化について
PostgreSQLの冗長化についてPostgreSQLの冗長化について
PostgreSQLの冗長化についてSoudai Sone
 
Redisととあるシステム
RedisととあるシステムRedisととあるシステム
RedisととあるシステムTakehiro Torigaki
 
NoSQL勉強会資料(2015/03/12@ヒカラボ )
NoSQL勉強会資料(2015/03/12@ヒカラボ )NoSQL勉強会資料(2015/03/12@ヒカラボ )
NoSQL勉強会資料(2015/03/12@ヒカラボ )Yuji Otani
 
SKYDISCのIoTを支えるテクノロジー
SKYDISCのIoTを支えるテクノロジーSKYDISCのIoTを支えるテクノロジー
SKYDISCのIoTを支えるテクノロジーYuji Otani
 

Destacado (6)

Pythonで始めるWebアプリケーション開発
Pythonで始めるWebアプリケーション開発Pythonで始めるWebアプリケーション開発
Pythonで始めるWebアプリケーション開発
 
PostgreSQLの冗長化について
PostgreSQLの冗長化についてPostgreSQLの冗長化について
PostgreSQLの冗長化について
 
MySQL
MySQLMySQL
MySQL
 
Redisととあるシステム
RedisととあるシステムRedisととあるシステム
Redisととあるシステム
 
NoSQL勉強会資料(2015/03/12@ヒカラボ )
NoSQL勉強会資料(2015/03/12@ヒカラボ )NoSQL勉強会資料(2015/03/12@ヒカラボ )
NoSQL勉強会資料(2015/03/12@ヒカラボ )
 
SKYDISCのIoTを支えるテクノロジー
SKYDISCのIoTを支えるテクノロジーSKYDISCのIoTを支えるテクノロジー
SKYDISCのIoTを支えるテクノロジー
 

Similar a 大規模Redisサーバ縮小化の戦い

複数拠点における開発効率の維持・向上
複数拠点における開発効率の維持・向上複数拠点における開発効率の維持・向上
複数拠点における開発効率の維持・向上infinite_loop
 
第2回 近JASA セミナー 「組み込みの世界に影響を与える エンタープライズiOS」
第2回 近JASA セミナー 「組み込みの世界に影響を与える エンタープライズiOS」第2回 近JASA セミナー 「組み込みの世界に影響を与える エンタープライズiOS」
第2回 近JASA セミナー 「組み込みの世界に影響を与える エンタープライズiOS」feedtailor
 
いまいる現場への愛を叫びたい
いまいる現場への愛を叫びたいいまいる現場への愛を叫びたい
いまいる現場への愛を叫びたいTakehiro Kameda
 
220203 sit2022 sap murata
220203 sit2022 sap murata220203 sit2022 sap murata
220203 sit2022 sap murataSoichiro Murata
 
It web 業界研究_1124
It web 業界研究_1124It web 業界研究_1124
It web 業界研究_1124Toshikazu Oka
 
データ活用をもっともっと円滑に! ~データ処理・分析基盤編を少しだけ~
データ活用をもっともっと円滑に!~データ処理・分析基盤編を少しだけ~データ活用をもっともっと円滑に!~データ処理・分析基盤編を少しだけ~
データ活用をもっともっと円滑に! ~データ処理・分析基盤編を少しだけ~NTT DATA OSS Professional Services
 
1ヶ月で作り切る!スタートアップのための Rails 爆速開発術 (20170306)
1ヶ月で作り切る!スタートアップのための Rails 爆速開発術 (20170306)1ヶ月で作り切る!スタートアップのための Rails 爆速開発術 (20170306)
1ヶ月で作り切る!スタートアップのための Rails 爆速開発術 (20170306)Masataka Sato
 
音声で楽しく業務効率化!TOKSOKで変わる請求業務
音声で楽しく業務効率化!TOKSOKで変わる請求業務音声で楽しく業務効率化!TOKSOKで変わる請求業務
音声で楽しく業務効率化!TOKSOKで変わる請求業務freee株式会社
 
基調講演「データのグループウェア化」
基調講演「データのグループウェア化」基調講演「データのグループウェア化」
基調講演「データのグループウェア化」Cybozucommunity
 
Android 10 dec, 2012
Android 10 dec, 2012Android 10 dec, 2012
Android 10 dec, 2012Akira Sasaki
 
kintone Cafe 松山
kintone Cafe 松山kintone Cafe 松山
kintone Cafe 松山亮 門屋
 
Financial Planner の為のITの活用
Financial Planner の為のITの活用Financial Planner の為のITの活用
Financial Planner の為のITの活用Kenichi Takeuchi
 
Android最新動向
Android最新動向Android最新動向
Android最新動向Akira Sasaki
 
デブサミ関西2011 JAZ紹介
デブサミ関西2011 JAZ紹介デブサミ関西2011 JAZ紹介
デブサミ関西2011 JAZ紹介Keiji Kamebuchi
 
デブサミ関西 2017| IoTビジネスが もっと発展するために必要なものとは?
デブサミ関西 2017| IoTビジネスが もっと発展するために必要なものとは?デブサミ関西 2017| IoTビジネスが もっと発展するために必要なものとは?
デブサミ関西 2017| IoTビジネスが もっと発展するために必要なものとは?SORACOM,INC
 
iOSアプリケーションの継続的デリバリー
iOSアプリケーションの継続的デリバリーiOSアプリケーションの継続的デリバリー
iOSアプリケーションの継続的デリバリーNaoki Umehara
 
クラッシュフィーバー開発の裏側
クラッシュフィーバー開発の裏側クラッシュフィーバー開発の裏側
クラッシュフィーバー開発の裏側Tomotsune Murata
 
まだまだ戦えるweb!mithril.js最初の1歩
まだまだ戦えるweb!mithril.js最初の1歩 まだまだ戦えるweb!mithril.js最初の1歩
まだまだ戦えるweb!mithril.js最初の1歩 Keisuke Mori
 
f4samurai会社説明資料.pdf
f4samurai会社説明資料.pdff4samurai会社説明資料.pdf
f4samurai会社説明資料.pdfssuser035e96
 

Similar a 大規模Redisサーバ縮小化の戦い (20)

複数拠点における開発効率の維持・向上
複数拠点における開発効率の維持・向上複数拠点における開発効率の維持・向上
複数拠点における開発効率の維持・向上
 
第2回 近JASA セミナー 「組み込みの世界に影響を与える エンタープライズiOS」
第2回 近JASA セミナー 「組み込みの世界に影響を与える エンタープライズiOS」第2回 近JASA セミナー 「組み込みの世界に影響を与える エンタープライズiOS」
第2回 近JASA セミナー 「組み込みの世界に影響を与える エンタープライズiOS」
 
いまいる現場への愛を叫びたい
いまいる現場への愛を叫びたいいまいる現場への愛を叫びたい
いまいる現場への愛を叫びたい
 
220203 sit2022 sap murata
220203 sit2022 sap murata220203 sit2022 sap murata
220203 sit2022 sap murata
 
It web 業界研究_1124
It web 業界研究_1124It web 業界研究_1124
It web 業界研究_1124
 
データ活用をもっともっと円滑に! ~データ処理・分析基盤編を少しだけ~
データ活用をもっともっと円滑に!~データ処理・分析基盤編を少しだけ~データ活用をもっともっと円滑に!~データ処理・分析基盤編を少しだけ~
データ活用をもっともっと円滑に! ~データ処理・分析基盤編を少しだけ~
 
1ヶ月で作り切る!スタートアップのための Rails 爆速開発術 (20170306)
1ヶ月で作り切る!スタートアップのための Rails 爆速開発術 (20170306)1ヶ月で作り切る!スタートアップのための Rails 爆速開発術 (20170306)
1ヶ月で作り切る!スタートアップのための Rails 爆速開発術 (20170306)
 
音声で楽しく業務効率化!TOKSOKで変わる請求業務
音声で楽しく業務効率化!TOKSOKで変わる請求業務音声で楽しく業務効率化!TOKSOKで変わる請求業務
音声で楽しく業務効率化!TOKSOKで変わる請求業務
 
基調講演「データのグループウェア化」
基調講演「データのグループウェア化」基調講演「データのグループウェア化」
基調講演「データのグループウェア化」
 
Android 10 dec, 2012
Android 10 dec, 2012Android 10 dec, 2012
Android 10 dec, 2012
 
kintone Cafe 松山
kintone Cafe 松山kintone Cafe 松山
kintone Cafe 松山
 
Financial Planner の為のITの活用
Financial Planner の為のITの活用Financial Planner の為のITの活用
Financial Planner の為のITの活用
 
Android最新動向
Android最新動向Android最新動向
Android最新動向
 
デブサミ関西2011 JAZ紹介
デブサミ関西2011 JAZ紹介デブサミ関西2011 JAZ紹介
デブサミ関西2011 JAZ紹介
 
デブサミ関西 2017| IoTビジネスが もっと発展するために必要なものとは?
デブサミ関西 2017| IoTビジネスが もっと発展するために必要なものとは?デブサミ関西 2017| IoTビジネスが もっと発展するために必要なものとは?
デブサミ関西 2017| IoTビジネスが もっと発展するために必要なものとは?
 
iOSアプリケーションの継続的デリバリー
iOSアプリケーションの継続的デリバリーiOSアプリケーションの継続的デリバリー
iOSアプリケーションの継続的デリバリー
 
scrum_fest_osaka_2020
scrum_fest_osaka_2020scrum_fest_osaka_2020
scrum_fest_osaka_2020
 
クラッシュフィーバー開発の裏側
クラッシュフィーバー開発の裏側クラッシュフィーバー開発の裏側
クラッシュフィーバー開発の裏側
 
まだまだ戦えるweb!mithril.js最初の1歩
まだまだ戦えるweb!mithril.js最初の1歩 まだまだ戦えるweb!mithril.js最初の1歩
まだまだ戦えるweb!mithril.js最初の1歩
 
f4samurai会社説明資料.pdf
f4samurai会社説明資料.pdff4samurai会社説明資料.pdf
f4samurai会社説明資料.pdf
 

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