Elastic webservice

웹 서비스 확장 전략
강대명
charsyam@naver.com

그냥 장비 더 넣으면
되지 않나요?

그래도 됩니다.
다만 돈이 더 많이 들뿐

그래도 됩니다.
다만 시간이 더 들뿐

올바른(?) 확장 방법에
대해서 알아봅시다.

Client
Buisness
Logic
Storage
서비스 초창기 구조: 1대

Client WEB DB(Mysql)
바꿔 말하면…

Client WEB#1 DB(Master)
시작은 대충 이런 모습
DB(Slave)
WEB#2
WEB#3

어디가 가장
문제가 될까요?

Client
Buisness
Logic
Storage
Client?

Client
Buisness
Logic
Storage
Buisness Logic?

Client
Web
App Server
Storage
Storage?

같은 서비스라도
상황마다 다릅니다.

매번 천만 팩토리얼을
계산하는 서비스면?

Client
Buisness
Logic
Storage
Buisness Logic이 뻥

CPU 작업이 많으면…

CPU 작업이 많으면…
WEB 확장
WEB 확장

Client WEB #1
DNS Round Robin
WEB #2
WEB #3

Client WEB #1
DNS Round Robin
WEB #2
WEB #3
DNS
api.factorial.com
WEB #2

DNS RR은 서버 장애시
전파 시간의 단점이 존재

Client WEB #1
LB
WEB #2
WEB #3
Load
Balancer

소프트웨어 LB
이중화 등이 필요…

로직 단의 확장은,
대체로 쉬운편…

매번 내 친구들의 목록을 가
져오는 서비스라면?

Client
Web
App Server
Storage
Storage

이런 확장이 도움이 될까?
WEB 확장
WEB 확장

도움이 안됨…
WEB 확장
WEB 확장
DB가 할수 있는 일은 동일

DB 작업이 많으면…
DB 확장

그런데 DB 확장은
쉽지가 않네요.

잠시 확장을 위한
선택 방법

Scale Up
성능이 더 좋은 장비로…

초당 3000 TPS
3배 처리 가능한 서버를 투입

Scale Up
CPU 4 -> 24
Mem 4G -> 32G

Scale Out
장비를 더 늘리자.

일반적으로는 Scale Up 이
더 쉽고 Scale Out 이 비
용이 적게 든다.

그러나 가능하면 일단은
Scale Up 을 시도해보자.

메모리, CPU, SSD 등의
간단히 업그레이드
가능한 것들…

하드웨어 가격이 점점
싸져서, Scale Out 도
좋은 전략

돌아가기 전에…
확장이 필요한건 어떻게?

메모리 사용량
CPU 사용량
CPU Load
(웹, DB) 서버 로그

어떤 부하가 많은가?
읽기 VS 쓰기

어떻게 원하는 데이터를
쉽게 찾을 것인가?

어떤 부하가 많은가?
읽기, 쓰기의 비율에 다른
다른 조치가 필요.

일반적인 서비스 부하
200 writes/s
800 reads/s Read > Write

Read 가 80% 정도면?
Read를 분산하자.

DB의 Slave 에서
읽기를 수행

일반적인 DB 구성
DB(Master)
DB(slave)
Write
Read
Replication
Failover
모든 요청을 Master 가 처리, Slave는 장애 대비

Read 분산 DB 구성
DB(Master)
DB(slave)
Write
Read
Replication
Failover
Master는 쓰기만 처리, 읽기는 전부 Slave에서

200
writes/s
800
reads/s
200
writes/s
400
reads/s
200
writes/s
400
reads/s
Read/1 Server Read/2 Server

Slave 만 계속 추가하면
읽기는 계속 늘어날까요?

Write가 늘어날 수록
성능은 떨어집니다.

Write의 증대로 인한 I/O 상황
700
writes/s
50
reads/s
700
writes/s
50
reads/s
700
writes/s
50
reads/s
700
writes/s
50
reads/s
700
writes/s
50
reads/s

데이터가 무지막지하게
많아서 한 서버에
안 들어간다면…

Write가 나눠지면
데이터를 어떻게 찾을 것
인가로 다시 귀결됨
(두번째 질문)

일반적인 DB 구성
DB #1
Read #1
Write #1
Read #2
Write #2
DB별로 해당하는 Key들의 리퀘스트만 보냄.
DB #2

어떻게 해당 서버를 찾지?

어떤 Key(속성) 이
찾기에
적당할 까?

인스타그램을
생각해봅시다.

특정 유저를 어떻게 찾을까?

특정 사진을 어떻게
찾을까?

User 관련 정보
많아도 한 서버에서
처리 가능

User 관련 정보
60억 다 있어도 그렇
게 크지는 않음.

Instagram
자신이 들어갈 서버의 주소가
Logical Shard ID로 존재

서비스 별로 다양한
정책을 취함.

Range
1~백만: 1번
백만1~2백만: 2번

Range
Range가 너무 크면
서버별 사용 리소스가
크게 차이날 수 있다.

Range
서버 추가 시에
Range 조절이 없으면
데이터 이동이 없다.

Range
User #1
User #10
User #1000000
User #1000001
User #1000100
User #2000000
User #2000001
User #2000200
User #3000000
ServerUser #1000005
2

Modular
서버 대수에 따라서
데이터 이동이 많아짐.

Modular
가능하면 2배씩 증
가하는 게 유리.

Modular
Logical Shard
Physical Shard

Modulo
User #1
User #4
User #7
User #2
User #5
User #8
User #3
User #6
User #9
ServerUser #1
1

Indexed
해당 데이터가 어디 존
재하는지 Index 서버
가 따로 존재

Indexed
Index 변경으로 데이터
이동이 자유롭다.

Indexed
Index 서버에 대한
관리가 추가로 필요.

Indexed
User #1
User #2000
User #1000000
User #2
User #2001
User #10000
User #3
User #6
User #5000
ServerUser #5000
3
Index Server
User 5000 is in 3

결국은 서비스 확장은
데이터 확장의 이슈

서비스에 적합한 방
법은 서비스별로 다름

현재의 트렌드
BO: Shared Nothing
DB: Sharding

Elastic webservice

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Elastic webservice (20)

More from DaeMyung Kang (20)

Elastic webservice