グラブル流運用術〜1700万人を満足させるためのシステム構成、PHPプログラムの考え方〜

by Cygames

Slide 1

Slide 1 text

Slide 2

Slide 2 text

2 / 120

Slide 3

Slide 3 text

3 / 120 自己紹介【自分の目指すところ】最速のシステムを作りたい

Slide 4

Slide 4 text

4 / 120 Cygamesについて

Slide 5

Slide 5 text

5 / 120 Cygamesについて【Cygamesのビジョン】最高のコンテンツを作る会社

Slide 6

Slide 6 text

6 / 120 グランブルーファンタジーとは • 1700万ユーザーを超えたRPG • ブラウザゲーム • 30人が同時に戦うマルチバトル ※ ※2017年10月8日現在

Slide 7

Slide 7 text

7 / 120 グラブルの技術的特徴大量のアクセスがある！

Slide 8

Slide 8 text

8 / 120 グラブルの技術的特徴サーバ攻撃ボタンやアビリティボタンを押下するたびにリクエスト (約3秒に1回)

Slide 9

Slide 9 text

9 / 120 グラブルの技術的特徴大量のアクセス 1日の総PV数10億PV強

Slide 10

Slide 10 text

10 / 120 グラブルの技術的特徴騎空団（ギルド）同士のバトルイベント中 PV数 :20億PV/日バトル数:1100万回/日 ※最大値

Slide 11

Slide 11 text

11 / 120 大量アクセスをさばくシステム構成 Web Server 1 twemproxy memcached 1 … Application Servers Cache Servers Database Servers Master MySQL MHA Cluster 1 Apache + mod_php Node Server 1 Layer4 Load Balancer（BIG-IP） Client N … Web(HTTP) static data access Memcached Servers Client (Apps or Web Browser) 1 Akamai CDN … Nginx 1 … Application Load Balancers WebSocket(WS) Nginx N Redis 1 … Redis Servers Redis N 10G Ethernet 10G Ethernet Node Server N Web Server N … WebSocket (WS) Web(HTTP) Access Load Balancer / Proxy Sharding (水平分割) … N Node.js twemproxy memcached N Slave 1 Slave 2 MySQL MHA Cluster 2 MySQL MHA Cluster 3 Master Slave 1 Slave 2 Master Slave 1 Slave 2 mysqli Web Server 1 twemproxy Apache + mod_php mysqli local memcached local redis

Slide 12

Slide 12 text

12 / 120 大量アクセスをさばくシステム構成データベースがたくさんある！アクセスが多いテーブルは水平分割してる大量のアクセスをさばくためにDBを細かく分ける ※DBサーバーは100セット以上

Slide 13

Slide 13 text

13 / 120 グラブルは多くのユーザーがプレイトータル1日10億オーバーのPV

Slide 14

Slide 14 text

14 / 120 1700万人を満足させるためのシステム改修 • 今回の改修の目標 • 改修するところを探す • 実際に改修してみた例

Slide 15

Slide 15 text

15 / 120 1700万人を満足させるためのシステム改修 • 今回の改修の目標 • 改修するところを探す • 実際に改修してみた例

Slide 16

Slide 16 text

16 / 120 今回の改修の目標グラブルのシステムをもっと早くする！！

Slide 17

Slide 17 text

17 / 120 今回の改修の目標 • グラブルはたくさんの人が遊んでいて、大量のアクセスがある「最高のコンテンツを作る会社」なので「サーバーサイドエンジニア」として「レスポンス改善」を目標にした

Slide 18

Slide 18 text

18 / 120 1700万人を満足させるためのシステム改修 • 今回の改修の目標 • 改修するところを探す • 実際に改修してみた例

Slide 19

Slide 19 text

19 / 120 改修するところを探す具体的にどうするのか検討するために下記の観点で調査した・APIの特定・処理の見直し・具体的な改修箇所

Slide 20

Slide 20 text

20 / 120 1700万人を満足させるためのシステム改修 • 今回の改修の目標 • 改修するところを探す • APIの特定 • 処理の見直し • 具体的な改修箇所 • 実際に改修してみた例

Slide 21

Slide 21 text

21 / 120 APIの特定 • 重いAPIはどれだろう APIの重さが相対的にわかるツールが必要 New Relicで調査しました

Slide 22

Slide 22 text

22 / 120 APIの特定【New Relicからわかったこと】バトル処理全般に対して下記の現象が判明しました・レスポンスタイムが高い・throughputが高い・most time consumingが上位

Slide 23

Slide 23 text

23 / 120 New Relicとはサーバでの処理時間がリアルタイムでわかるツール

Slide 24

Slide 24 text

24 / 120 レスポンスタイムが高い Transaction項目をみると各APIごとの平均レスポンスタイムのランキングが表示されている上位にバトルのAPIが入っていた

Slide 25

Slide 25 text

25 / 120 throughputが高い throughput項目を見るとほかの処理に比べて、バトルAPIはthroughputが高いので高頻度にたたかれる

Slide 26

Slide 26 text

26 / 120 most time consumingが上位 Most time consumingの観点でバトルのAPIが上位2位であった (全体の3割強) 相対的にバトルソースが Webサーバに負荷を与えている

Slide 27

Slide 27 text

27 / 120 APIの特定・バトルの処理回数が多い・バトルの処理時間が長い以上のことがわかったので、バトル処理全般を改修することにした

Slide 28

Slide 28 text

28 / 120 1700万人を満足させるためのシステム改修 • 今回の改修の目標 • 改修するところを探す • APIの特定 • 処理の見直し • 具体的な改修箇所 • 実際に改修してみた例

Slide 29

Slide 29 text

29 / 120 処理の見直し • バトルの中の処理はどうなっているんだろう実際に自分で処理を見直した

Slide 30

Slide 30 text

30 / 120 処理の見直し特にバトル処理中のスキル計算処理の中で・多くのスキルを判定している・計算数が多い箇所がある

Slide 31

Slide 31 text

31 / 120 処理の見直し特にバトル処理中のスキル計算処理の中で・多くのスキルを判定している・計算数が多い箇所がある具体的に数値で回数を見たいプロファイラを使って処理を分析

Slide 32

Slide 32 text

32 / 120 処理の見直し今回はXHProfを使いました XHProfとは、PHPのプロファイラ処理時間や関数のcall数、メモリ使用など詳細に数値で把握できる

Slide 33

Slide 33 text

33 / 120 処理の見直し下記のことがわかりました・スキル計算処理がメモリを消費し、処理時間も長い・CSV取得処理のcall数が多く処理時間が長い

Slide 34

Slide 34 text

34 / 120 スキル計算処理の負荷が高いスキルの評価部分が処理時間が長く、メモリ消費が激しかった

Slide 35

Slide 35 text

35 / 120 CSV取得処理のcall数が多く処理時間が長い CSVを取得している処理の call回数が多い処理に時間がかかっている

Slide 36

Slide 36 text

36 / 120 処理の見直しプロファイラからわかったこと・スキル計算処理がメモリを消費し処理時間も長い・CSV取得処理のcall数が多く処理時間が長いスキル計算処理とCSV取得処理がネック

Slide 37

Slide 37 text

37 / 120 1700万人を満足させるためのシステム改修 • 今回の改修の目標 • 改修するところを探す • APIの特定 • 処理の見直し • 具体的な改修箇所 • 実際に改修してみた例

Slide 38

Slide 38 text

38 / 120 具体的な改修箇所 • スキル計算処理がメモリを消費し処理時間も長いスキル計算処理のメモリ使用量を減らし、処理時間を短くする • CSV取得処理のcall数が多く処理時間が長い CSV取得処理のcall数を減らし、処理時間を短くする

Slide 39

Slide 39 text

39 / 120 具体的な改修箇所「スキル計算の高速化」「CSVの取得処理の効率化」上記を改修箇所とした。

Slide 40

Slide 40 text

40 / 120 1700万人を満足させるためのシステム改修 • 今回の改修の目標 • 改修するところを探す • 実際に改修してみた例

Slide 41

Slide 41 text

41 / 120 実際に改修してみた例全項目より下記2点を改修箇所として定めた • スキル計算の高速化 • CSVの取得処理を効率化

Slide 42

Slide 42 text

42 / 120 1700万人を満足させるためのシステム改修 • 今回の改修の目標 • 改修するところを探す • 実際に改修してみた例 • スキル計算の高速化 • CSVの取得処理を効率化

Slide 43

Slide 43 text

43 / 120 スキル計算の高速化スキルの高速化として下記の3項目を説明します • グラブルのスキル • 現状の把握 • 改善方法

Slide 44

Slide 44 text

44 / 120 1700万人を満足させるためのシステム改修 • 実際に改修してみた例 • スキル計算の高速化 • グラブルのスキル • 現状の把握 • 改善方法 • CSVの取得処理を効率化

Slide 45

Slide 45 text

45 / 120 グラブルのスキルグラブルのスキルは種類が多く、バトル内でも大量に判定されますバトルの編成の中でスキルに関連するもの・武器・召喚石・キャラ etc...

Slide 46

Slide 46 text

46 / 120 武器 1編成に付き10本 1本あたり2種類のスキルを持つ

Slide 47

Slide 47 text

47 / 120 武器この武器には以下のスキルが付いている 1. 風属性キャラの攻撃力上昇(中) 2. 風属性キャラのHPが少ないほど攻撃力が上昇(小)

Slide 48

Slide 48 text

48 / 120 召喚石編成全体の能力に影響を与える (バトル中は自分とサポーターの2つ)

Slide 49

Slide 49 text

49 / 120 召喚石この召喚石には以下のスキルが付いているスキル「嵐竜方陣」の効果を100%UP

Slide 50

Slide 50 text

50 / 120 キャラクター 1ターンに4人攻撃する 1人3つのスキルを持っている

Slide 51

Slide 51 text

51 / 120 キャラクターこのキャラクターには以下のスキルが付いている 1.弱体耐性UP 2.バトル開始時に自動復活効果 3.被ダメージに稀にHP全回復

Slide 52

Slide 52 text

52 / 120 グラブルのスキル多彩なスキルを組み合わせて、高いダメージを得たり、戦闘中に有利になる効果を得たりする

Slide 53

Slide 53 text

53 / 120 グラブルのスキル • 判定するスキルの数は武器（10 × 2）+ 召喚石(2 × 1) + キャラクター(4 × 3) = 34 バトル中に34回判定される。

Slide 54

Slide 54 text

54 / 120 グラブルのスキル・武器スキル数は800以上・召喚石のスキルは250以上・キャラクター数は400キャラ以上組み合わせの数が膨大になる ※10/8現在

Slide 55

Slide 55 text

55 / 120 1700万人を満足させるためのシステム改修 • 実際に改修してみた例 • スキル計算の高速化 • グラブルのスキル • 現状の把握 • 改善方法 • CSVの取得処理を効率化

Slide 56

Slide 56 text

56 / 120 現状の把握 • グラブルのスキルは数が多く、組み合わせ数も膨大実際に確認したところスキルの計算処理が膨大にあった。プロファイラで詳細分析

Slide 57

Slide 57 text

57 / 120 現状の把握・スキル計算処理が処理時間も長い、メモリ使用量が高い

Slide 58

Slide 58 text

58 / 120 現状の把握・実際の処理例 foreach($character_party as $character) { foreach($weapon_skill_ids as $skill_id) { $skill_master = Master¥Skill::find($skill_id); Skill::calcurate_skill($character, $skill_master) } foreach($summon_skill_ids as $skill_id) { $skill_master = Master¥Skill::find($skill_id); Skill::calcurate_skill($character, $skill_master) } … } 様々なスキルをループ回しているたくさん計算している →処理が長い

Slide 59

Slide 59 text

59 / 120 現状の把握スキル評価ロジックのメモリ使用量が高い

Slide 60

Slide 60 text

60 / 120 現状の把握 • スキルの組み合わせが多いので、膨大な計算処理がある計算処理を減らせれば軽くなる

Slide 61

Slide 61 text

61 / 120 1700万人を満足させるためのシステム改修 • 実際に改修してみた例 • スキル計算の高速化 • グラブルのスキル • 現状の把握 • 改善方法 • CSVの取得処理を効率化

Slide 62

Slide 62 text

62 / 120 改善方法 • スキルの組み合わせが多いので、膨大な計算処理がある計算処理を減らせれば軽くなる普段どのような負荷対策をしているか考えてみた

Slide 63

Slide 63 text

63 / 120 改善方法 PHP DB サーバーからDBに大量にアクセスがある

Slide 64

Slide 64 text

64 / 120 改善方法 KVS 一度DBから取得したら、KVSに乗せる PHP DB

Slide 65

Slide 65 text

65 / 120 改善方法一度計算した結果をKVSにのせると早くなるはず！ PHP KVS

Slide 66

Slide 66 text

66 / 120 改善方法キャラクタースキルの計算結果計算結果武器スキルの計算結果召喚石スキルの計算結果計算結果をKVSに載せると計算処理が省ける

Slide 67

Slide 67 text

67 / 120 改善方法 • 実際の処理例 foreach($character_party as $character) { foreach($weapon_skill_ids as $skill_id) { $skill_master = Master¥Skill::find($skill_id); Skill::calcurate_skill($character, $skill_master) } foreach($summon_skill_ids as $skill_id) { $skill_master = Master¥Skill::find($skill_id); Skill::calcurate_skill($character, $skill_master) } … } 処理するスキルがたくさんあるスキルのロジックにアクセス

Slide 68

Slide 68 text

68 / 120 【改修後処理】 $identifier = $raid_id . $user_id; $skill = Memcache::instance()->get(raid_id); If (empty($skill)) { foreach($character_party as $character) { $array[キャラクター番号] = a foreach($weapon_skill_ids as $skill_id) { $skill_master = Master¥Skill::find($skill_id); $skill[‘weapon_skill’][]=Skill::calcurate_skill($character,$skill_master); } foreach($summon_skill_ids as $skill_id) { $skill_master = Master¥Skill::find($skill_id); $skill[‘summon_skill’][] = Skill::instance()->calcurate_skill($character, $skill_master); } foreach($support_skill_ids as $skill_id) … Memcache ::instance()->set_key($ identifier )->set($skill); } 計算してあるスキル値を memcachedから取得計算結果が入っている配列を memcachedに詰める計算した値を配列に詰めておく

Slide 69

Slide 69 text

69 / 120 実装上で気をつけたこと・キーの持ち方・データが取れないの挙動

Slide 70

Slide 70 text

70 / 120 キーの持ち方正しい一意のキーで取得しないと別のデータがとれてしまい、障害原因となる。「バトルのID」と「ユーザーのID」を結合して一意のキーを保証した。

Slide 71

Slide 71 text

71 / 120 データが取れないの挙動データが取れないときは、再度計算しmemcachedに載せる有効期限が切れた場合や、memcachedに異常が発生した場合でも、データが取れないので正しく計算されるよって安全性が担保される

Slide 72

Slide 72 text

72 / 120 1700万人を満足させるためのシステム改修 • 今回の改修の目標 • 改修するところを探す • 実際に改修してみた例 • スキル計算の高速化 • CSVの取得処理を効率化

Slide 73

Slide 73 text

73 / 120 1700万人を満足させるためのシステム改修 • 実際に改修してみた例 • スキル計算の高速化 • CSVの取得処理を効率化 • グラブルのマスタデータ • 改善ポイント • 改善方法

Slide 74

Slide 74 text

74 / 120 1700万人を満足させるためのシステム改修 • 実際に改修してみた例 • スキル計算の高速化 • CSVの取得処理を効率化 • グラブルのマスタデータ • マスタデータとは • 現状のマスタデータの扱い方 • グラブルのマスタデータの特徴 • 改善ポイント • 改善方法

Slide 75

Slide 75 text

75 / 120 1700万人を満足させるためのシステム改修 • 実際に改修してみた例 • スキル計算の高速化 • CSVの取得処理を効率化 • グラブルのマスタデータ • マスタデータとは • 現状のマスタデータの扱い方 • グラブルのマスタデータの特徴 • 改善ポイント • 改善方法

Slide 76

Slide 76 text

76 / 120 マスタデータとはキャラクターや武器などのパラメータ情報マスタデータはCSVファイル

Slide 77

Slide 77 text

77 / 120 マスタデータとは • 例【キャラの情報】性別身長体重【パラメータ】攻撃力 HP 防御力【アビリティ】スキルのデータスキル文言追加効果の情報【図鑑】キャラ紹介の文言

Slide 78

Slide 78 text

78 / 120 マスタデータとはパラメータの情報を CSVで保持【キャラの情報】性別身長体重【キャラの情報】性別,身長,体重男,178,50

Slide 79

Slide 79 text

79 / 120 1700万人を満足させるためのシステム改修 • 実際に改修してみた例 • スキル計算の高速化 • CSVの取得処理を効率化 • グラブルのマスタデータ • マスタデータとは • 現状のマスタデータの扱い方 • グラブルのマスタデータの特徴 • 改善ポイント • 改善方法

Slide 80

Slide 80 text

80 / 120 現状のマスタデータの扱い方現状のマスタデータの保存方法はWebサーバ内のlocal redisを使用サーバ local redis

Slide 81

Slide 81 text

81 / 120 現状のマスタデータの扱い方実際に運用しながら試してみた順に紹介・KVSの場所について・local memcachedに保存・local redisに保存

Slide 82

Slide 82 text

82 / 120 1700万人を満足させるためのシステム改修 • 実際に改修してみた例 • CSVの取得処理を効率化 • グラブルのマスタデータ • マスタデータとは • 現状のマスタデータの扱い方・KVSの場所について・local memcachedに保存・local redisに保存 • グラブルのマスタデータの特徴

Slide 83

Slide 83 text

83 / 120 KVSの場所について・マスタデータは全てのユーザに対して同じデータ globalサーバにKVSを立ててデータを置くと全ユーザーがデータを取得するため、トラフィックが多い PHP PHP KVS

Slide 84

Slide 84 text

84 / 120 KVSの場所について • 各Webサーバ内にKVSを立てて、アクセスするようにするとWebサーバの数だけアクセスが分散できるサーバ local KVS サーバ local KVS サーバ local KVS

Slide 85

Slide 85 text

85 / 120 システム構成図から見るglobal KVSとlocal KVS Web Server 1 twemproxy memcached 1 … Application Servers Cache Servers Database Servers Master MySQL MHA Cluster 1 Apache + mod_php Node Server 1 Layer4 Load Balancer（BIG-IP） Client N … Web(HTTP) static data access Memcached Servers Client (Apps or Web Browser) 1 Akamai CDN … Nginx 1 … Application Load Balancers WebSocket(WS) Nginx N Redis 1 … Redis Servers Redis N 10G Ethernet 10G Ethernet Node Server N Web Server N … WebSocket (WS) Web(HTTP) Access Load Balancer / Proxy Sharding (水平分割) … N Node.js twemproxy memcached N Slave 1 Slave 2 MySQL MHA Cluster 2 MySQL MHA Cluster 3 Master Slave 1 Slave 2 Master Slave 1 Slave 2 mysqli local memcached local redis Webサーバにある local redis local memcached globalにある redis memcahced

Slide 86

Slide 86 text

86 / 120 1700万人を満足させるためのシステム改修 • 実際に改修してみた例 • CSVの取得処理を効率化 • グラブルのマスタデータ • マスタデータとは • 現状のマスタデータの扱い方・KVSの場所について・local memcachedに保存・local redisに保存 • グラブルのマスタデータの特徴

Slide 87

Slide 87 text

87 / 120 local memcachedに保存 PHPからCSVファイルにアクセスしたとき、一番最初のアクセスで全行をlocal memcachedに保存 local memcached PHP CSVファイル

Slide 88

Slide 88 text

88 / 120 local memcachedの問題点 CSVファイルのレコード数が増えたため、 CSVファイルのデータをlocal memcachedに保存する際に Webサーバに負荷がかかるようになった。

Slide 89

Slide 89 text

89 / 120 1700万人を満足させるためのシステム改修 • 実際に改修してみた例 • CSVの取得処理を効率化 • グラブルのマスタデータ • マスタデータとは • 現状のマスタデータの扱い方・KVSの場所について・local memcachedに保存・local redisに保存 • グラブルのマスタデータの特徴

Slide 90

Slide 90 text

90 / 120 local redisに保存 local redisだとlocal memcachedで起きていた問題点が起きないため Webサーバにlocal redisをたてて、マスタデータをlocal redisに移行した PHP local redis

Slide 91

Slide 91 text

91 / 120 1700万人を満足させるためのシステム改修 • 実際に改修してみた例 • スキル計算の高速化 • CSVの取得処理を効率化 • グラブルのマスタデータ • マスタデータとは • 現状のマスタデータの扱い方 • マスタデータの特徴 • 改善ポイント • 改善方法

Slide 92

Slide 92 text

92 / 120 1700万人を満足させるためのシステム改修 • 実際に改修してみた例 • スキル計算の高速化 • CSVの取得処理を効率化 • グラブルのマスタデータ • マスタデータとは • 現状のマスタデータの扱い方 • マスタデータの特徴・マスタデータの構成について・更新頻度について・問題点

Slide 93

Slide 93 text

93 / 120 マスタデータの構成について • キャラクターの例【キャラの情報】性別身長体重【パラメータ】攻撃力 HP 防御力【アビリティ】スキルのデータスキル文言追加効果の情報【図鑑】キャラ紹介の文言

Slide 94

Slide 94 text

94 / 120 マスタデータの構成について基本情報バトルパラメータアビリティ図鑑キャラクターのデータ

Slide 95

Slide 95 text

95 / 120 マスタデータの構成について ID スキルのID 演出データID 奥義ID etc 1 2 21 33 Etc… ID 効果値スキル演出ID ダメージ補正ID Etc.. 2 2 9 43 Etc… ダメージ補正スキル基本情報 ID 基礎値ダメージの伸び方ID 固定値 Etc… 43 23 22 2000 Etc…

Slide 96

Slide 96 text

96 / 120 マスタデータの構成についてマスタデータは多くのCSVファイルから構成されている多くのCSVファイルとリレーション関係がある

Slide 97

Slide 97 text

97 / 120 1700万人を満足させるためのシステム改修 • 実際に改修してみた例 • スキル計算の高速化 • CSVの取得処理を効率化 • グラブルのマスタデータ • マスタデータとは • 現状のマスタデータの扱い方 • マスタデータの特徴・マスタデータの構成について・更新頻度について・問題点

Slide 98

Slide 98 text

98 / 120 更新頻度についてマスタデータがリリースされたら基本変わらないマスタデータが変わる例: 1.不具合修正 2.バランス調整

Slide 99

Slide 99 text

99 / 120 1700万人を満足させるためのシステム改修 • 実際に改修してみた例 • スキル計算の高速化 • CSVの取得処理を効率化 • グラブルのマスタデータ • マスタデータとは • 現状のマスタデータの扱い方 • マスタデータの特徴・マスタデータの構成について・更新頻度について・問題点

Slide 100

Slide 100 text

100 / 120 問題点マスタデータの構成上CSVファイルが大量に関連しているため、検索コスト、データを保持するコストがかかる

Slide 101

Slide 101 text

101 / 120 1700万人を満足させるためのシステム改修 • 今回の改修の目標 • 改修するところを探す • 実際に改修してみた例 • スキル計算の高速化 • CSVの取得処理を効率化 • グラブルのマスタデータ • 改善ポイント • 改善方法

Slide 102

Slide 102 text

102 / 120 マスタデータの構成について基本情報バトルパラメータアビリティ図鑑キャラクターのデータ

Slide 103

Slide 103 text

103 / 120 改善ポイント • 通信ごとにキャラクターのデータを作り直している

Slide 104

Slide 104 text

104 / 120 改善ポイント • キャラクターのデータを作るときに多くのマスタデータを取得している • 通信ごとにキャラクターのデータを作り直している CSVをとる頻度が高い

Slide 105

Slide 105 text

105 / 120 改善ポイント CSVを取得する頻度を低くすれば効率が良い

Slide 106

Slide 106 text

106 / 120 1700万人を満足させるためのシステム改修 • 今回の改修の目標 • 改修するところを探す • 実際に改修してみた例 • スキル計算の高速化 • CSVの取得処理を効率化 • グラブルのマスタデータ • 改善ポイント • 改善方法

Slide 107

Slide 107 text

107 / 120 改善方法必要な個所に対して中間データをキャッシュしたら効率が良い！

Slide 108

Slide 108 text

108 / 120 改善方法基本情報バトルパラメータアビリティ図鑑キャラクターのデータ • 改修前のイメージ

Slide 109

Slide 109 text

109 / 120 改善方法基本情報バトルパラメータアビリティキャラクターのデータ • 改修後のイメージ memcached 必要なデータに絞る一度取得したら memcachedに保存

Slide 110

Slide 110 text

110 / 120 改善方法【実装時に気を付けたこと】・中間データのキャッシュの置き場共通のデータを参照するため local memcachedに格納・マスタデータが更新された時について

Slide 111

Slide 111 text

111 / 120 マスタデータが更新された時についてマスタデータが更新されたときに、同時に中間データも更新されなければならないそのためリリースバッチでマスタデータが保存されているredisと中間データが保存されているmemcachedを削除している Webサーバ local memcached 中間データ local redis マスターデータサーバ内で flush_all

Slide 112

Slide 112 text

112 / 120 改善結果中間データをキャッシュ化したことによって全体のCSV取得回数が減った CSVファイルを検索する機会が減ったマスタデータをサーバメモリに展開する必要がなくなったのでメモリの節約になった

Slide 113

Slide 113 text

113 / 120 まとめ • スキル計算の高速化 • CSV取得処理の効率化上記の処理を行いましたそれによる効果をグラフ化します

Slide 114

Slide 114 text

114 / 120 まとめバトルAPIの平均速度は42.5%減 0 50 100 150 200 250 300 350 400 450 改修前改修後 APIの速度 400ms 230ms

Slide 115

Slide 115 text

115 / 120 まとめバトルAPIのメモリ使用量は40%減 0 20 40 60 80 100 120 改修前改修後メモリ使用量 100MB 60MB

Slide 116

Slide 116 text

116 / 120 まとめ • CALL関数の数は50%減 0 50000 100000 150000 200000 250000 300000 350000 400000 450000 改修前改修後 CALL関数の数 400,000 関数 200,000 関数

Slide 117

Slide 117 text

117 / 120 改修を通して感じたこと • 常に改善の意識をもつ必要性 • プログラムを書く上での当たり前の大切さデータは最小限にまとめて再利用同じデータを何度も取得しないで再利用

Slide 118

Slide 118 text

118 / 120 ■まとめキャッシュは神使用用途は正しく守ってください