webservice cache strategy

125
초보자를 위한 웹 서비스 캐시 전략 [email protected]

Upload: dae-myung-kang

Post on 23-Jun-2015

6.394 views

Category:

Technology


2 download

TRANSCRIPT

Page 1: Webservice cache strategy

초보자를 위한 웹 서비스 캐시 전략

[email protected]

Page 2: Webservice cache strategy

Agenda •왜 캐시를 사용해야 하는가?

•확장을 위한 캐시 방법

Page 3: Webservice cache strategy

서비스 초창기

Page 4: Webservice cache strategy

목표?

Page 5: Webservice cache strategy

목표? 백만, 천만?

Page 6: Webservice cache strategy

네이버 다니시나요? 그럼 1번, 아니면 2번…

Page 7: Webservice cache strategy

1번. 이걸 들을 필요가… 없습니다. T.T

Page 8: Webservice cache strategy

2번. 일단 출시가 먼저죠.

Page 9: Webservice cache strategy

Client Buisness Logic

Storage

서비스 초창기 구조: 1대

Page 10: Webservice cache strategy

서비스가 잘된다면?

Page 11: Webservice cache strategy

확장이 필요합니다.

Page 12: Webservice cache strategy

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

Page 13: Webservice cache strategy

Client

Buisness Logic

Storage

Client?

Page 14: Webservice cache strategy

Client

Buisness Logic

Storage

Buisness Logic?

Page 15: Webservice cache strategy

Client Business Logic

Storage

Storage?

Page 16: Webservice cache strategy

선택 할 수 있는 방법?

Page 17: Webservice cache strategy

Scale Up VS

Scale Out

Page 18: Webservice cache strategy

Scale Up

Page 19: Webservice cache strategy

Scale Up

성능이 더 좋은 장비로…

Page 20: Webservice cache strategy

초당 1000 TPS

Page 21: Webservice cache strategy

초당 3000 TPS

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

Page 22: Webservice cache strategy

Scale Up

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

Page 23: Webservice cache strategy

Scale Out

Page 24: Webservice cache strategy

Scale Out

장비를 더 늘리자.

Page 25: Webservice cache strategy

초당 1000 TPS

Page 26: Webservice cache strategy

초당 2000 TPS

Page 27: Webservice cache strategy

초당 3000 TPS

Page 28: Webservice cache strategy

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

비용이 적게 든다.

Page 29: Webservice cache strategy

진실은…

Page 30: Webservice cache strategy

뒤로 가면 다~~~

어렵워요!!!

Page 31: Webservice cache strategy

뭐든지, 달리는 열차의 바퀴를 갈아 끼우는 겁니다.

Page 32: Webservice cache strategy

다시 캐시 얘기로…

Page 33: Webservice cache strategy

캐시를 선택해야 하는 이유.

Page 34: Webservice cache strategy

1. 돈이 부족한데 성능을 더 높여야 할때…

Page 35: Webservice cache strategy

2. 돈은 있지만… 성능을 더 높여야 할때…

Page 36: Webservice cache strategy

Use Case: Login

Page 37: Webservice cache strategy

Use Case: Login

DB에서 읽기 Select * from Users where id=‘charsyam’;

Page 38: Webservice cache strategy

유저 수가 적으면…

Page 39: Webservice cache strategy

충분히 빠릅니다.

Page 40: Webservice cache strategy

그런데 유저 수가 엄청 많으면?

Page 41: Webservice cache strategy

DB도 인덱스 걸면 충분히 빠릅니다.

Page 42: Webservice cache strategy

단 읽기만 한다면…

Page 43: Webservice cache strategy

또, 디스크 읽는 수 가 적을때만

Page 44: Webservice cache strategy

Disk Page 접근 문제

Page 45: Webservice cache strategy

Use Case: Login

읽기에 캐시 적용

Page 46: Webservice cache strategy

Use Case: Login 캐시에서 읽기 Get charsyam

Page 47: Webservice cache strategy

적용 결과…

Page 48: Webservice cache strategy

Select Query

Page 49: Webservice cache strategy

CPU utility

Page 50: Webservice cache strategy

균등한 속도!!!

부하 감소!!!

Page 51: Webservice cache strategy

Use Case: Log

Page 52: Webservice cache strategy

Use Case: Log

Apply Cache For Write

Page 53: Webservice cache strategy

Use Case: Log Insert DB per one log Insert into clicklogs values(a,b,c);

Page 54: Webservice cache strategy

Use Case: Log 모아서 쓰기…1024개 단위 Insert into clicklogs values(a1,b1,c1), (a2,b2,c2), (a3,b3,c3)

Page 55: Webservice cache strategy

모아 쓰기를 위한 버퍼로 캐시 사용

Page 56: Webservice cache strategy

적용 결과…

Page 57: Webservice cache strategy

10 만건 insert

쓰기 단위 1 1024

속도(초) 16~17 1.4~1.5

Page 58: Webservice cache strategy

캐시를 쓰면 좋다는 건 알겠는데…

Page 59: Webservice cache strategy

그럼 캐시 서버의 확장은?

Page 60: Webservice cache strategy

1대만 쓰기에는…

Page 61: Webservice cache strategy

캐시 역시 데이터…

Page 62: Webservice cache strategy

Client Business Logic

Storage

일단 어디에 캐시가?

Page 63: Webservice cache strategy

Client Business Logic

Storage

Client – Logic?

Page 64: Webservice cache strategy

Client Business Logic

Storage

Logic - Storage?

Page 65: Webservice cache strategy

당연히 보통은 후자가 올바릅니다.

Page 66: Webservice cache strategy

General Cache Layer

Cache

DBMS

Storage Layer

Application Server

READ

WRITE

WRITE UPDATE

Page 67: Webservice cache strategy

그럼 어떤 데이터를 캐시해야 할까요?

Page 68: Webservice cache strategy

당연히 자주 찾을 것 같은 데이터를 캐시해야 합니다.

Page 69: Webservice cache strategy

이런 데이터는 서비스마다 다릅니다.

Page 70: Webservice cache strategy

페이스북이라면 어떤걸 캐시하고 있을까요?

Page 71: Webservice cache strategy

Login을 위한 유저 정보

Page 72: Webservice cache strategy

첫 화면에 보여줄 피드 몇백개

Page 73: Webservice cache strategy

친구 관계등

Page 74: Webservice cache strategy

이슈는 Scale

Page 75: Webservice cache strategy

유저 로그인 관련 정보

Page 76: Webservice cache strategy

유저 로그인 관련 정보

많아도 대부분 메모리에 올라감.

Page 77: Webservice cache strategy

1k * 10,000,000

Page 78: Webservice cache strategy

1k * 10,000,000

= 10G

Page 79: Webservice cache strategy

그런데 1억명이면?

Page 80: Webservice cache strategy

한 서버당 100G?

Page 81: Webservice cache strategy

한 서버당 100G? 물론 가능함… 돈만 있으면…

Page 82: Webservice cache strategy

그럼 10억명이면?

Page 83: Webservice cache strategy

그럼 10억명이면? 1TB?

Page 84: Webservice cache strategy

캐시의 분배가 필요함

Page 85: Webservice cache strategy

캐시의 분배가 필요함 데이터

Page 86: Webservice cache strategy

결국은 분배 전략…

Page 87: Webservice cache strategy

그냥 한대?

Page 88: Webservice cache strategy

그냥 한대?

LRU등으로 자주쓰는 녀석들만… 조금…

Page 89: Webservice cache strategy

여러대면?

Page 90: Webservice cache strategy

Range

Page 91: Webservice cache strategy

Range

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

Page 92: Webservice cache strategy

Range

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

Page 93: Webservice cache strategy

Range

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

Page 94: Webservice cache strategy

Range

User #1

User #10

User #1000000

User #1000001

User #1000100

User #2000000

User #2000001

User #2000200

User #3000000

Server User #1000005

2

Page 95: Webservice cache strategy

Modulo

Page 96: Webservice cache strategy

Modulo

Id % 서버대수 = k

Page 97: Webservice cache strategy

Modulo

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

Page 98: Webservice cache strategy

Modulo

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

Page 99: Webservice cache strategy

Modulo

Logical Shard Physical Shard

Page 100: Webservice cache strategy

Modulo

User #1

User #4

User #7

User #2

User #5

User #8

User #3

User #6

User #9

Server User #1

1

Page 101: Webservice cache strategy

Consistent Hash

Page 102: Webservice cache strategy

Consistent Hash 서버의 추가/제거 시에 1/n 정도의 데이터만 사라진다.

Page 103: Webservice cache strategy

Consistent Hash 다른 방식은 데이터의 서버위치가 고정적이지만, CH는 유동적

Page 104: Webservice cache strategy

A

Add A,B,C Server

Page 105: Webservice cache strategy

A

B

Add A,B,C Server

Page 106: Webservice cache strategy

A

B

C

Add A,B,C Server

Page 107: Webservice cache strategy

A

B

C

1

Add Item 1

Page 108: Webservice cache strategy

A

B

C

1

2

Add Item 2

Page 109: Webservice cache strategy

A

B

C

1

2

3

4

5

Add Item 3,4,5

Page 110: Webservice cache strategy

A

B

C 2

3

4

5

Fail!! B Server

Page 111: Webservice cache strategy

A

B

C

1

2

3

4

5

Add Item 1 Again -> Allocated C Server

Page 112: Webservice cache strategy

A

B

C

1

2

3

4

5

1

Recover B Server -> Add Item 1

Page 113: Webservice cache strategy

Indexed

Page 114: Webservice cache strategy

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

Page 115: Webservice cache strategy

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

Page 116: Webservice cache strategy

Indexed

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

Page 117: Webservice cache strategy

Indexed

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

Page 118: Webservice cache strategy

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 119: Webservice cache strategy

다양한 변종도 있을 수 있음.

Page 120: Webservice cache strategy

적합한 방식은 서비스

마다 다름.

Page 121: Webservice cache strategy

서버의 목록은 Zookeeper 등으로 관리하면 좋음

Page 122: Webservice cache strategy

정리하면…

Page 123: Webservice cache strategy

시작할 때는 뭐 하기 어려움.

Page 124: Webservice cache strategy

다만 조금만 고민해도 Technical Debt 을 줄일 수 있음.

Page 125: Webservice cache strategy

Thank you!