137
웹 서비스 확장 전략 강대명 [email protected]

Elastic webservice

Embed Size (px)

Citation preview

Page 1: Elastic webservice

웹 서비스 확장 전략

강대명

[email protected]

Page 2: Elastic webservice

오늘의 주제

Page 3: Elastic webservice

웹 서비스 확장전략?

Page 4: Elastic webservice

왜?

Page 5: Elastic webservice

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

Page 6: Elastic webservice

그래도 됩니다.

Page 7: Elastic webservice

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

Page 8: Elastic webservice

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

Page 9: Elastic webservice

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

Page 10: Elastic webservice

웹 서비스

Page 11: Elastic webservice

웹,모바일

Page 12: Elastic webservice

간단한 서비스

Page 13: Elastic webservice

최소로 MVP만 구현

Page 14: Elastic webservice

출시 우선

Page 15: Elastic webservice

Client Buisness Logic

Storage

서비스 초창기 구조: 1대

Page 16: Elastic webservice

Client WEB DB(Mysql)

바꿔 말하면…

Page 17: Elastic webservice

장애를 대비하면…

Page 18: Elastic webservice

Client WEB#1 DB(Master)

시작은 대충 이런 모습

DB(Slave) WEB#2

WEB#3

Page 19: Elastic webservice

잘 되는 건 운…

Page 20: Elastic webservice

서비스가 잘된다면?

Page 21: Elastic webservice

확장이 필요합니다.

Page 22: Elastic webservice

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

Page 23: Elastic webservice

Client

Buisness Logic

Storage

Client?

Page 24: Elastic webservice

Client

Buisness Logic

Storage

Buisness Logic?

Page 25: Elastic webservice

Client Web

App Server

Storage

Storage?

Page 26: Elastic webservice

서비스마다 다르고

Page 27: Elastic webservice

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

Page 28: Elastic webservice

가정 #1

Page 29: Elastic webservice

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

Page 30: Elastic webservice

대부분 CPU 작업

Page 31: Elastic webservice

Client

Buisness Logic

Storage

Buisness Logic이 뻥

Page 32: Elastic webservice

Client WEB DB(Mysql)

CPU 작업이 많으면…

Page 33: Elastic webservice

Client WEB DB(Mysql)

CPU 작업이 많으면…

WEB 확장

WEB 확장

Page 34: Elastic webservice

추가로…

Page 35: Elastic webservice

Web 단이 늘어나면?

Page 36: Elastic webservice

Client는 어떻게 알까?

Page 37: Elastic webservice

DNS를 이용

Page 38: Elastic webservice

Client WEB #1

DNS Round Robin

WEB #2

WEB #3

Page 39: Elastic webservice

Client WEB #1

DNS Round Robin

WEB #2

WEB #3

DNS api.factorial.com

WEB #2

Page 40: Elastic webservice

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

Page 41: Elastic webservice

Load Balancer 를 이용

Page 42: Elastic webservice

Client WEB #1

LB

WEB #2

WEB #3

Load Balancer

Page 43: Elastic webservice

하드웨어 LB 비쌉니다.

Page 44: Elastic webservice

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

Page 45: Elastic webservice

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

Page 46: Elastic webservice

가정 #2

Page 47: Elastic webservice

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

Page 48: Elastic webservice

Client Web

App Server

Storage

Storage

Page 49: Elastic webservice

DB 작업이 많으면?

Page 50: Elastic webservice

Client WEB DB(Mysql)

이런 확장이 도움이 될까?

WEB 확장

WEB 확장

Page 51: Elastic webservice

Client WEB DB(Mysql)

도움이 안됨…

WEB 확장

WEB 확장

DB가 할수 있는 일은 동일

Page 52: Elastic webservice

그렇다면?

Page 53: Elastic webservice

Client WEB DB(Mysql)

DB 작업이 많으면…

DB 확장

Page 54: Elastic webservice

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

Page 55: Elastic webservice

잠시 확장을 위한 선택 방법

Page 56: Elastic webservice

Scale Up VS

Scale Out

Page 57: Elastic webservice

Scale Up

Page 58: Elastic webservice

Scale Up

성능이 더 좋은 장비로…

Page 59: Elastic webservice

초당 1000 TPS

Page 60: Elastic webservice

초당 3000 TPS

3배 처리 가능한 서버를 투입

Page 61: Elastic webservice

Scale Up

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

Page 62: Elastic webservice

Scale Out

Page 63: Elastic webservice

Scale Out

장비를 더 늘리자.

Page 64: Elastic webservice

초당 1000 TPS

Page 65: Elastic webservice

초당 2000 TPS

Page 66: Elastic webservice

초당 3000 TPS

Page 67: Elastic webservice

일반적으로는 Scale Up 이 더 쉽고 Scale Out 이 비

용이 적게 든다.

Page 68: Elastic webservice

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

Page 69: Elastic webservice

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

Page 70: Elastic webservice

하드웨어 가격이 점점 싸져서, Scale Out 도

좋은 전략

Page 71: Elastic webservice

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

Page 72: Elastic webservice

메모리 사용량 CPU 사용량 CPU Load

(웹, DB) 서버 로그

Page 73: Elastic webservice

다시 돌아가서…

Page 74: Elastic webservice

스토리지의 확장

Page 75: Elastic webservice

두가지 질문…

Page 76: Elastic webservice

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

Page 77: Elastic webservice

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

Page 78: Elastic webservice

어떤 부하가 많은가? 읽기, 쓰기의 비율에 다른

다른 조치가 필요.

Page 79: Elastic webservice

일반적인 서비스 부하

200 writes/s

800 reads/s Read > Write

Page 80: Elastic webservice

Read 가 80% 정도면?

Page 81: Elastic webservice

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

Page 82: Elastic webservice

DB의 Slave 에서 읽기를 수행

Page 83: Elastic webservice

일반적인 DB 구성

DB(Master)

DB(slave)

Write

Read Replication Failover

모든 요청을 Master 가 처리, Slave는 장애 대비

Page 84: Elastic webservice

Read 분산 DB 구성

DB(Master)

DB(slave)

Write

Read Replication Failover

Master는 쓰기만 처리, 읽기는 전부 Slave에서

Page 85: Elastic webservice

200 writes/s

800 reads/s

200 writes/s

400 reads/s

200 writes/s

400 reads/s

Read/1 Server Read/2 Server

Page 86: Elastic webservice

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

Page 87: Elastic webservice

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

Page 88: Elastic webservice

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

Page 89: Elastic webservice

Write 를 분산하자.

Page 90: Elastic webservice

Write 비율이 높거나

Page 91: Elastic webservice

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

Page 92: Elastic webservice

Write가 나눠지면 데이터를 어떻게 찾을 것인가로 다시 귀결됨

(두번째 질문)

Page 93: Elastic webservice

일반적인 DB 구성

DB #1 Read #1 Write #1

Read #2 Write #2

DB별로 해당하는 Key들의 리퀘스트만 보냄.

DB #2

Page 94: Elastic webservice

어떻게 해당 서버를 찾지?

Page 95: Elastic webservice

어떤 Key(속성) 이 찾기에

적당할 까?

Page 96: Elastic webservice

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

Page 97: Elastic webservice

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

Page 98: Elastic webservice

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

Page 99: Elastic webservice

User ID

Page 100: Elastic webservice

사진 ID

Page 101: Elastic webservice

둘다 숫자라고 가정

Page 102: Elastic webservice

User 관련 정보

Page 103: Elastic webservice

User 관련 정보

많아도 한 서버에서 처리 가능

Page 104: Elastic webservice

1k * 10,000,000

Page 105: Elastic webservice

1k * 10,000,000

= 10G

Page 106: Elastic webservice

그런데 1억명이면?

Page 107: Elastic webservice

한 서버당 100G?

Page 108: Elastic webservice

그럼 10억명이면?

Page 109: Elastic webservice

그럼 10억명이면? 1TB?

Page 110: Elastic webservice

User 관련 정보

60억 다 있어도 그렇게 크지는 않음.

Page 111: Elastic webservice

그러나 사진은?

Page 112: Elastic webservice

Instagram

64 bits

Page 113: Elastic webservice

Instagram ID

Page 114: Elastic webservice

Instagram

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

Page 115: Elastic webservice

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

Page 116: Elastic webservice

Range, Modular, Indexed

Page 117: Elastic webservice

Range

Page 118: Elastic webservice

Range

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

Page 119: Elastic webservice

Range

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

Page 120: Elastic webservice

Range

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

Page 121: Elastic webservice

Range

User #1

User #10

User #1000000

User #1000001

User #1000100

User #2000000

User #2000001

User #2000200

User #3000000

Server User #1000005

2

Page 122: Elastic webservice

Modular

Page 123: Elastic webservice

Modular

Id % 서버대수 = k

Page 124: Elastic webservice

Modular

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

Page 125: Elastic webservice

Modular

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

Page 126: Elastic webservice

Modular

Logical Shard Physical Shard

Page 127: Elastic webservice

Modulo

User #1

User #4

User #7

User #2

User #5

User #8

User #3

User #6

User #9

Server User #1

1

Page 128: Elastic webservice

Indexed

Page 129: Elastic webservice

Indexed

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

Page 130: Elastic webservice

Indexed

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

Page 131: Elastic webservice

Indexed

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

Page 132: Elastic webservice

Indexed

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

Page 133: Elastic webservice

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

Page 134: Elastic webservice

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

Page 135: Elastic webservice

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

Page 136: Elastic webservice

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

Page 137: Elastic webservice