2014/2/8に行ったゲームサーバ勉強会でのスライドです。 サーバー構成図で登場するApplicationサーバーとDBについての基本的な事項と気をつける事について紹介しました。

1. サーバーのおしごと
Webサービスにおけるサーバー構成とその目的

2. 自己紹介
清水 佑吾 @yamionp
id:yamionp
株式会社 gumi 勤務
Python歴約2年
サーバーさわりはじめて約10年

3. 略歴
高校：CGIやホームページを作成して小遣い稼ぎ
卒業後：ISPでネットワーク＆サーバー構築のバイト
ちょっと前：PHPでウェブサービス開発
今：ソーシャルゲーム開発

4. サーバーの話

6. 使用言語・フレームワーク

7. 使用ミドルウェア

8. 最近のサーバー構成

9. S3
ELB
今日話す範囲
Application
EC2
MessageQueue
Job
EC2
ElasticCache
RDS
Horizontal Partitioning
Database

10. 最小限構成

11. Request
Response
DATA
Service

12. 一番シンプルな形
問題は？
サーバーが壊れるとデータが消える
サービスも止まる
書き込み途中で壊れると中途半端な書き込みが残る

13. アクセスが増えたら
今のサーバー１台では処理しきれない時

14. 負荷への対処
スケールアップ
スペックの良いサーバーに変更して処理能力UP!
スケールアウト
台数を増やして処理能力UP!
今日はこちらの話をします

15. Request
Response
DATA
Service

16. A
B
C
Service
DATA
DATA
DATA

17. 単にサーバーを増やした
特定のサーバーに負荷が集中すると対処出来ない
全データを見るには個別にアクセスする必要がある
可用性、整合性の問題は解決していない

18. データベース

19. A
B
C
Service
DATA
DATA
DATA

20. A
B
C
Application
SQL
SQL
DATA
Service

21. データの格納にRDBを使用した
データの扱い方が統一される
(リレーショナルモデル＆SQL)
どのApplicationサーバーでも同じデータを扱える
ユーザーはどれか一台にアクセスすれば良い
アクセス先はユーザーが決める

22. ロードバランサー

23. 助けて！
A
暇…
B
C
暇…
Application
DATA
Service

24. Elastic Load Balancing

25. A
B
C
Application
SQL
DATA
Service

26. Application
A
B
C
ELB
LoadBalancer
Service
DATA

27. ユーザーがアクセスする先を選ぶ必要が無くなった
特定のApplicationサーバーに負荷が集中しない
=> 台数さえ増やせば処理可能

28. レプリケーション

29. Application
ELB
DATA
Service

30. Application
書き込み
読み込み
ELB
Master
Slave
Service

31. メリット
既存のロジックに大きな変更無しに導入可能
自動でデータが更新される
再起動しても消えない

32. デメリット
分散可能なのは読み込みのみ
非同期の場合古いデータが最新のデータと限らない
同期の場合、Masterのパフォーマンスが悪化する

33. KeyValueStore (KVS)

34. KVSとは
KeyとValueのペアでデータを管理するDB
Memcache, DynamoDB, Riak, Redis…etc
それぞれ全て特徴・使い方・用途が違う
KEY
VALUE
A_AGE
21
A_AGE
21

35. Memcached

36. Application
ELB
DATA
Service

37. Application
GET
ELB
SELECT
DATA
Service

38. 特徴
オンメモリなので非常に高速 (RDBの十倍程度)
シンプル

39. 注意点
キャッシュロジックをアプリケーションに実装が必要
更新時に削除を忘れると古いデータが返る
キャッシュのデータをもとにRDBを更新してはならない
TTL以前に消える可能性
キャッシュ間のサイズが大きく違うとメモリ効率悪化
永続化は出来ない(データはメモリ上にのみ存在)

40. Redis

41. 特徴
インメモリ型KVS
永続化可能
レプリケーション可能
データ型 (LIST, SET, SORTED SET, HASH) を持つ
複雑な操作をアトミックに実行可能

42. LIST
LPOP
A
B
C
D

43. LIST
RPUSH
B
C
D
E

44. アトミックに実行とは

45. 原子性
コマンド結果が全て成功or全て失敗しかない事
操作の途中段階にならない。

46. データベース分割

47. Application
書き込み
ELB
暇…
助けて！
Master
Slave
Service

48. 書込み性能の限界

49. 垂直分割
ID
体力
やくそう
ジョブ
Player A
100
2
戦士
Player B
98
8
格闘家
Player C
20
0
魔法使い
Player D
0
10
僧侶
DB 1
DB 2
DB 3

50. Application
ELB
アイテム
カード
Service

51. メリット
分割しても集計が容易
ユニーク制約が維持される

52. デメリット
アイテムに負荷が集中したら対処できない
実際は分割をまたいだ処理が多い

53. 水平分割
体力
やくそう
ジョブ
Player A
100
2
戦士
Player B
98
8
格闘家
Player C
20
0
魔法使い
DB 2
Player D
0
10
僧侶
DB 3
DB 1

54. Application
Player1
ELB
Player2
Service

55. メリット
ほぼ均等に負荷が分散される
プレイヤーに閉じた処理はDBをまたがなくてすむ

56. デメリット
集計が難しい
技術的難易度（フレームワークがサポートしないetc
ユニーク制約をかけれない
ID1のデータが分割した数だけ存在する

57. データが壊れる時

58. DB
ユーザー1
GET A
a=3
a=a+2
set(“a”, a)
A
3
A
5
3
SET A 5

59. DB
ユーザー1
ユーザー2
GET A
a=3
a=a+2
set(“a”, a)
A
3
SET A 5
3
A
3
A
5
3+2+2=5
A
5
GET A
3
a=3
a=a+2
SET A 5
set(“a”, a)

60. ロック

61. DB
ユーザー1
GET A & LOCK
A
a=3
a=a+2
3
SET A 5
ユーザー2
3
A
3
A
5
A
7
GET A & LOCK
5
SET A 7
a=5
a=a+2

62. RDBでは標準的
SELECT FOR UPDATE
デッドロックの危険性
ロック順番を統一する

63. CAS

64. DB
ユーザー1
ユーザー2
GET A
A
3, ver02
a=3
a=a+2
SET A 5, ver02
A
ver02
ver02
A
3
3
5
3
ver03
ver02
A
ver03
5
GET A
3, ver02
a=3
a=a+2
失敗 A 5, ver02
SET

65. DB
ユーザー2
失敗したので最初からリトライ
A
ver03
5
GET A
5, ver03
a=5
a=a+2
A
ver03
ver04
5
7
SET A 7, ver03

66. Memcache, Redisなどで使用可能
ロックが無いので処理が止まらない
繰り返すロジックを自分で実装する必要が有る
永遠に失敗し続ける可能性がある
リトライ回数に上限をつける

67. まとめ
負荷対策にはスケールアップとスケールアウトがある
データ読み込みに関しては手段が多い
KVSはそれぞれのソフトで目的・使い方が違う
書き込みの分散は整合性との戦い

68. ご清聴ありがとうございました