View
6.508
Download
7
Category
Preview:
Citation preview
웹 서비스 확장 전략
강대명
charsyam@naver.com
오늘의 주제
웹 서비스 확장전략?
왜?
그냥 장비 더 넣으면 되지 않나요?
그래도 됩니다.
그래도 됩니다. 다만 돈이 더 많이 들뿐
그래도 됩니다. 다만 시간이 더 들뿐
올바른(?) 확장 방법에 대해서 알아봅시다.
웹 서비스
웹,모바일
간단한 서비스
최소로 MVP만 구현
출시 우선
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?
서비스마다 다르고
같은 서비스라도 상황마다 다릅니다.
가정 #1
매번 천만 팩토리얼을 계산하는 서비스면?
대부분 CPU 작업
Client
Buisness Logic
Storage
Buisness Logic이 뻥
Client WEB DB(Mysql)
CPU 작업이 많으면…
Client WEB DB(Mysql)
CPU 작업이 많으면…
WEB 확장
WEB 확장
추가로…
Web 단이 늘어나면?
Client는 어떻게 알까?
DNS를 이용
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은 서버 장애시 전파 시간의 단점이 존재
Load Balancer 를 이용
Client WEB #1
LB
WEB #2
WEB #3
Load Balancer
하드웨어 LB 비쌉니다.
소프트웨어 LB 이중화 등이 필요…
로직 단의 확장은, 대체로 쉬운편…
가정 #2
매번 내 친구들의 목록을 가져오는 서비스라면?
Client Web
App Server
Storage
Storage
DB 작업이 많으면?
Client WEB DB(Mysql)
이런 확장이 도움이 될까?
WEB 확장
WEB 확장
Client WEB DB(Mysql)
도움이 안됨…
WEB 확장
WEB 확장
DB가 할수 있는 일은 동일
그렇다면?
Client WEB DB(Mysql)
DB 작업이 많으면…
DB 확장
그런데 DB 확장은 쉽지가 않네요.
잠시 확장을 위한 선택 방법
Scale Up VS
Scale Out
Scale Up
Scale Up
성능이 더 좋은 장비로…
초당 1000 TPS
초당 3000 TPS
3배 처리 가능한 서버를 투입
Scale Up
CPU 4 -> 24 Mem 4G -> 32G
Scale Out
Scale Out
장비를 더 늘리자.
초당 1000 TPS
초당 2000 TPS
초당 3000 TPS
일반적으로는 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 가 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 를 분산하자.
Write 비율이 높거나
데이터가 무지막지하게 많아서 한 서버에 안 들어간다면…
Write가 나눠지면 데이터를 어떻게 찾을 것인가로 다시 귀결됨
(두번째 질문)
일반적인 DB 구성
DB #1 Read #1 Write #1
Read #2 Write #2
DB별로 해당하는 Key들의 리퀘스트만 보냄.
DB #2
어떻게 해당 서버를 찾지?
어떤 Key(속성) 이 찾기에
적당할 까?
인스타그램을 생각해봅시다.
특정 유저를 어떻게 찾을까?
특정 사진을 어떻게 찾을까?
User ID
사진 ID
둘다 숫자라고 가정
User 관련 정보
User 관련 정보
많아도 한 서버에서 처리 가능
1k * 10,000,000
1k * 10,000,000
= 10G
그런데 1억명이면?
한 서버당 100G?
그럼 10억명이면?
그럼 10억명이면? 1TB?
User 관련 정보
60억 다 있어도 그렇게 크지는 않음.
그러나 사진은?
64 bits
Instagram ID
자신이 들어갈 서버의 주소가 Logical Shard ID로 존재
서비스 별로 다양한 정책을 취함.
Range, Modular, Indexed
Range
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
Server User #1000005
2
Modular
Modular
Id % 서버대수 = k
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
Server User #1
1
Indexed
Indexed
해당 데이터가 어디 존재하는지 Index 서버가 따로 존재
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
Server User #5000
3
Index Server
User 5000 is in 3
결국은 서비스 확장은 데이터 확장의 이슈
서비스에 적합한 방법은 서비스별로 다름
현재의 트렌드 BO: Shared Nothing DB: Sharding
Recommended