SlideShare a Scribd company logo
サーバーのおしごと
Webサービスにおけるサーバー構成とその目的
自己紹介
清水 佑吾 @yamionp
id:yamionp
株式会社 gumi 勤務
Python歴約2年
サーバーさわりはじめて約10年
略歴
高校:CGIやホームページを作成して小遣い稼ぎ
卒業後:ISPでネットワーク&サーバー構築のバイト
ちょっと前:PHPでウェブサービス開発
今:ソーシャルゲーム開発
サーバーの話
サーバーのおしごと
使用言語・フレームワーク
使用ミドルウェア
最近のサーバー構成
S3
ELB
今日話す範囲
Application
EC2

MessageQueue
Job

EC2

ElasticCache

RDS
Horizontal Partitioning

Database
最小限構成
Request
Response

DATA

Service
一番シンプルな形
問題は?
サーバーが壊れるとデータが消える
サービスも止まる
書き込み途中で壊れると中途半端な書き込みが残る
アクセスが増えたら
今のサーバー1台では処理しきれない時
負荷への対処
スケールアップ
スペックの良いサーバーに変更して処理能力UP!
スケールアウト
台数を増やして処理能力UP!
今日はこちらの話をします
Request
Response

DATA

Service
A
B
C
Service

DATA

DATA

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

DATA

DATA

DATA
A
B
C
Application

SQL
SQL
DATA

Service
データの格納にRDBを使用した
データの扱い方が統一される
(リレーショナルモデル&SQL)
どのApplicationサーバーでも同じデータを扱える
ユーザーはどれか一台にアクセスすれば良い
アクセス先はユーザーが決める
ロードバランサー
助けて!
A
暇…

B
C

暇…

Application
DATA

Service
Elastic Load Balancing
A
B
C
Application

SQL

DATA

Service
Application
A
B
C
ELB
LoadBalancer

Service

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

ELB
DATA

Service
Application

書き込み

読み込み

ELB

Master

Slave
Service
メリット

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

分散可能なのは読み込みのみ
非同期の場合古いデータが最新のデータと限らない
同期の場合、Masterのパフォーマンスが悪化する
KeyValueStore (KVS)
KVSとは
KeyとValueのペアでデータを管理するDB
Memcache, DynamoDB, Riak, Redis…etc
それぞれ全て特徴・使い方・用途が違う
KEY

VALUE

A_AGE

21

A_AGE

21
Memcached
Application

ELB
DATA

Service
Application

GET
ELB

SELECT

DATA

Service
特徴

オンメモリなので非常に高速 (RDBの十倍程度)
シンプル
注意点
キャッシュロジックをアプリケーションに実装が必要
更新時に削除を忘れると古いデータが返る
キャッシュのデータをもとにRDBを更新してはならない
TTL以前に消える可能性
キャッシュ間のサイズが大きく違うとメモリ効率悪化
永続化は出来ない(データはメモリ上にのみ存在)
Redis
特徴
インメモリ型KVS
永続化可能
レプリケーション可能
データ型 (LIST, SET, SORTED SET, HASH) を持つ
複雑な操作をアトミックに実行可能
LIST
LPOP
A

B

C

D
LIST
RPUSH
B

C

D

E
アトミックに実行とは
原子性

コマンド結果が全て成功or全て失敗しかない事
操作の途中段階にならない。
データベース分割
Application

書き込み
ELB

暇…
助けて!
Master

Slave
Service
書込み性能の限界
垂直分割
ID

体力

やくそう

ジョブ

Player A

100

2

戦士

Player B

98

8

格闘家

Player C

20

0

魔法使い

Player D

0

10

僧侶

DB 1

DB 2

DB 3
Application

ELB

アイテム

カード

Service
メリット

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

アイテムに負荷が集中したら対処できない
実際は分割をまたいだ処理が多い
水平分割
体力

やくそう

ジョブ

Player A

100

2

戦士

Player B

98

8

格闘家

Player C

20

0

魔法使い

DB 2

Player D

0

10

僧侶

DB 3

DB 1
Application

Player1

ELB

Player2

Service
メリット

ほぼ均等に負荷が分散される
プレイヤーに閉じた処理はDBをまたがなくてすむ
デメリット
集計が難しい
技術的難易度(フレームワークがサポートしないetc
ユニーク制約をかけれない
ID1のデータが分割した数だけ存在する
データが壊れる時
DB

ユーザー1
GET A
a=3
a=a+2
set(“a”, a)

A

3

A

5

3
SET A 5
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)
ロック
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
RDBでは標準的
SELECT FOR UPDATE
デッドロックの危険性
ロック順番を統一する
CAS
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
DB

ユーザー2
失敗したので最初からリトライ
A

ver03

5

GET A
5, ver03
a=5
a=a+2

A

ver03
ver04

5
7

SET A 7, ver03
Memcache, Redisなどで使用可能
ロックが無いので処理が止まらない
繰り返すロジックを自分で実装する必要が有る
永遠に失敗し続ける可能性がある
リトライ回数に上限をつける
まとめ
負荷対策にはスケールアップとスケールアウトがある
データ読み込みに関しては手段が多い
KVSはそれぞれのソフトで目的・使い方が違う
書き込みの分散は整合性との戦い
ご清聴ありがとうございました

More Related Content

What's hot (20)

PDF
インフラエンジニアの綺麗で優しい手順書の書き方
Shohei Koyama
 
PPTX
CEDEC2021 ダウンロード時間を大幅減!~大量のアセットをさばく高速な実装と運用事例の共有~
SEGADevTech
 
PDF
MRU : Monobit Reliable UDP ~5G世代のモバイルゲームに最適な通信プロトコルを目指して~
モノビット エンジン
 
PPTX
ゲームエンジニアのためのデータベース設計
sairoutine
 
PDF
【Unite Tokyo 2019】Unityだったら簡単!マルチプレイ用ゲームサーバ開発 ~実践編~
UnityTechnologiesJapan002
 
PPTX
CEDEC2019 大規模モバイルゲーム運用におけるマスタデータ管理事例
sairoutine
 
PDF
大規模ソーシャルゲームを支える技術~PHP+MySQLを使った高負荷対策~
infinite_loop
 
PPTX
え、まって。その並列分散処理、Kafkaのしくみでもできるの? Apache Kafkaの機能を利用した大規模ストリームデータの並列分散処理
NTT DATA Technology & Innovation
 
PDF
マイクロサービスバックエンドAPIのためのRESTとgRPC
disc99_
 
PDF
ネットワーク ゲームにおけるTCPとUDPの使い分け
モノビット エンジン
 
PDF
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
Amazon Web Services Japan
 
PPTX
Photonのサービス選択の勘どころ
GMO GlobalSign Holdings K.K.
 
PDF
分散トレーシング技術について(Open tracingやjaeger)
NTT Communications Technology Development
 
PDF
Fluentdのお勧めシステム構成パターン
Kentaro Yoshida
 
PPTX
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
NTT DATA Technology & Innovation
 
PDF
InnoDBのすゝめ(仮)
Takanori Sejima
 
PPTX
本当は恐ろしい分散システムの話
Kumazaki Hiroki
 
PDF
MagicOnion~C#でゲームサーバを開発しよう~
torisoup
 
ODP
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
pospome
 
PPTX
スマホゲームのチート手法とその対策 [DeNA TechCon 2019]
DeNA
 
インフラエンジニアの綺麗で優しい手順書の書き方
Shohei Koyama
 
CEDEC2021 ダウンロード時間を大幅減!~大量のアセットをさばく高速な実装と運用事例の共有~
SEGADevTech
 
MRU : Monobit Reliable UDP ~5G世代のモバイルゲームに最適な通信プロトコルを目指して~
モノビット エンジン
 
ゲームエンジニアのためのデータベース設計
sairoutine
 
【Unite Tokyo 2019】Unityだったら簡単!マルチプレイ用ゲームサーバ開発 ~実践編~
UnityTechnologiesJapan002
 
CEDEC2019 大規模モバイルゲーム運用におけるマスタデータ管理事例
sairoutine
 
大規模ソーシャルゲームを支える技術~PHP+MySQLを使った高負荷対策~
infinite_loop
 
え、まって。その並列分散処理、Kafkaのしくみでもできるの? Apache Kafkaの機能を利用した大規模ストリームデータの並列分散処理
NTT DATA Technology & Innovation
 
マイクロサービスバックエンドAPIのためのRESTとgRPC
disc99_
 
ネットワーク ゲームにおけるTCPとUDPの使い分け
モノビット エンジン
 
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
Amazon Web Services Japan
 
Photonのサービス選択の勘どころ
GMO GlobalSign Holdings K.K.
 
分散トレーシング技術について(Open tracingやjaeger)
NTT Communications Technology Development
 
Fluentdのお勧めシステム構成パターン
Kentaro Yoshida
 
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
NTT DATA Technology & Innovation
 
InnoDBのすゝめ(仮)
Takanori Sejima
 
本当は恐ろしい分散システムの話
Kumazaki Hiroki
 
MagicOnion~C#でゲームサーバを開発しよう~
torisoup
 
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
pospome
 
スマホゲームのチート手法とその対策 [DeNA TechCon 2019]
DeNA
 

Viewers also liked (8)

PDF
負荷がたかいいんだから~♪(仮)
Yohei Hamada
 
PPTX
MMOのサーバについて 剣と魔法のログレス ~いにしえの女神~ での実装例
Satoshi Yamafuji
 
PDF
分割と整合性と戦う
Yugo Shimizu
 
PDF
Fluentd and Embulk Game Server 4
N Masahiro
 
PDF
Halo2 におけるHFSM(階層型有限状態マシン) 【ビヘイビアツリー解説】
Youichiro Miyake
 
PDF
負荷対策しておもったことまとめ~JMeterでSocket.IOもいけるでよ~
johgus johgus
 
PPTX
EmbulkとDigdagとデータ分析基盤と
Toru Takahashi
 
PDF
自宅で出来る!ゲームサーバの作り方
光晶 上原
 
負荷がたかいいんだから~♪(仮)
Yohei Hamada
 
MMOのサーバについて 剣と魔法のログレス ~いにしえの女神~ での実装例
Satoshi Yamafuji
 
分割と整合性と戦う
Yugo Shimizu
 
Fluentd and Embulk Game Server 4
N Masahiro
 
Halo2 におけるHFSM(階層型有限状態マシン) 【ビヘイビアツリー解説】
Youichiro Miyake
 
負荷対策しておもったことまとめ~JMeterでSocket.IOもいけるでよ~
johgus johgus
 
EmbulkとDigdagとデータ分析基盤と
Toru Takahashi
 
自宅で出来る!ゲームサーバの作り方
光晶 上原
 
Ad

Recently uploaded (9)

PDF
20250726_Devinで変えるエンプラシステム開発の未来
Masaki Yamakawa
 
PDF
TaketoFujikawa_ComicComputing12th_inKumamoto
Matsushita Laboratory
 
PPTX
2025_7_25_吉祥寺_設計ナイト_ADR運用におけるデータ利活用の考え方.pptx
ssuserfcafd1
 
PPTX
baserCMS『カスタムコンテンツ』徹底活用術〜あなただけの管理画面を自由自在に〜
Ryuji Egashira
 
PDF
VMUG Japan book vsan 20250515 CPU/Memory vSAN
Kazuhiro Sota
 
PDF
LoRaWAN ウェザーステーションキット v3 -WSC3-L 日本語ユーザーマニュアル
CRI Japan, Inc.
 
PDF
MahiroYoshida_セリフに着目したキャラクタロール推定に関する基礎検討_sigcc12th2025
Matsushita Laboratory
 
PDF
第三世代 ウェザーステーションキット v3 ー WSC3-L 日本語カタログ
CRI Japan, Inc.
 
PDF
【学会聴講報告】CVPR2025からみるVision最先端トレンド / CVPR2025 report
Sony - Neural Network Libraries
 
20250726_Devinで変えるエンプラシステム開発の未来
Masaki Yamakawa
 
TaketoFujikawa_ComicComputing12th_inKumamoto
Matsushita Laboratory
 
2025_7_25_吉祥寺_設計ナイト_ADR運用におけるデータ利活用の考え方.pptx
ssuserfcafd1
 
baserCMS『カスタムコンテンツ』徹底活用術〜あなただけの管理画面を自由自在に〜
Ryuji Egashira
 
VMUG Japan book vsan 20250515 CPU/Memory vSAN
Kazuhiro Sota
 
LoRaWAN ウェザーステーションキット v3 -WSC3-L 日本語ユーザーマニュアル
CRI Japan, Inc.
 
MahiroYoshida_セリフに着目したキャラクタロール推定に関する基礎検討_sigcc12th2025
Matsushita Laboratory
 
第三世代 ウェザーステーションキット v3 ー WSC3-L 日本語カタログ
CRI Japan, Inc.
 
【学会聴講報告】CVPR2025からみるVision最先端トレンド / CVPR2025 report
Sony - Neural Network Libraries
 
Ad

サーバーのおしごと