초보자를위한분산캐시활용전략 강대명 charsyam@naver.com
우리가꿈꾸는서비스
우리가꿈꾸는서비스
우리가꿈꾸는서비스
우리가꿈꾸는서비스
그러나현실은?
서비스에필요한것은?
서비스에필요한것은? 핵심적인기능
서비스에필요한것은? 핵심적인기능
서비스에필요한것은? 핵심적인기능
서비스에필요한것은? 적절한기능 서비스안정성
트위터에매일고래만보이면?
트위터에매일고래만보이면?
처음부터페이스북같은 서비스를만들수있을까요?
여기서잠깐!!! 페이스북하루로그인 5 억명!!!
여기서잠깐!!! 페이스북한달로그인 8 억명!!!
이런분만가능합니다.
기초적인 ShortUrl 서비스
Bit.ly
기본적인서비스구성 Read/Write CLIENT WEB DB
웹서버가병목이면?
웹서버의확장 CLIENT WEB WEB WEB Read/Write DB
DB 에병목이온다면?
서비스의데이터에대 한이해가필요!!!
가정 1: 일반적인서비스는? 800 reads/s Read > Write 200 writes/s
분석결론 Read 80%, Read 를분산하자!!!
일반적인 DB 구성 Master Slave REPLICATION/FailOver
일반적인 DB 구성 모든 Traffic 은 Master 가처리 Slave 는장애대비 Master REPLICATION/FailOver Slave
Read 를분산하면?
Client ONLY WRITE Master Only READ REPLICATION Slave Slave Slave
Read/1 Server Read/2 Server 800 reads/s 200 writes/s 400 reads/s 200 writes/s 400 reads/s 200 writes/s
Slave 만계속추가하 면서비스가좋아질까?
Write 가늘어날수록 성능은떨어진다.
WHY?
WHY? 장비가늘어나면성능이 늘어나야되는거아닌가?
Write 의증대로인한 I/O 상황 50 reads/s 50 reads/s 50 reads/s 50 reads/s 50 reads/s 700 writes/s 700 writes/s 700 writes/s 700 writes/s 700 writes/s
분석결론 Write 의비중이커지면 결국 Write 를분산하자!!!
파티셔닝 (Partition)
Scalable Partitioning Client PART 1 Web Server DBMS PART 2 Web Server DBMS
Partitioning 성능 관리비용
How to Divide?
ID Size Date
How to Find?
Function O(1) L4/Proxy Function(ID) => 1, 2, 3 Function(charsyam1) => 1 Function(charsyam2) => 2 Function(charsyam3) => 3
User Directory Service L4/Proxy CharSyam1 is in PART1 Where is User CharSyam1
Why is Cache?
Cache 는나중에요청올결과를 미리저장해두었다가빠르게 서비스해주는것
메모리는 HDD 보다빠르다.
캐시의목적 균등한빠른속도 부하감소
General Cache Layer Application Server READ WRITE Storage Layer Cache DBMS WRITE UPDATE
Cache or DataStore Memcache Redis
Connect to Memcache Conn = memcache.connect( server1, server2, server3 ); Client Client Client Client memcached memcached memcached
Memcache with Moxi Client Client Client Client moxi moxi memcached memcached memcached memcached
Memcache with Moxi Conn = memcache.connect( moxi_server1, moxi_server2 ); moxi -z 11811=server1:11211,server2:11211
Connect to Redis Client Memcached Master Memcached Slave Replication/Snapshot
Memcaehe Redis Data 타입 Key - Value Key Value Sorted Set, List, Hash 그외특징 LRU Max Item Size(1MB) Expire Time Replication Snapshot Atomic Atomic Operation Atomic Operation
Consistent Hashing
Origin K = 10000 N = 5 Server Server User Request Proxy Server Server Server
FAIL : Redistribution about 2000 Users K = 10000 N = 4 Server Server User Request Proxy Server Server Server
RECOVER: Redistribution about 2500 Users K = 10000 N = 5 Server Server User Request Proxy Server Server Server
Add A,B,C Server A
Add A,B,C Server A B
Add A,B,C Server A B C
Add Item 1 A 1 B C
Add Item 2 A 1 B C 2
Add Item 3,4,5 4 3 A 1 B C 2 5
Fail!! B Server 3 A 4 B C 2 5
Add Item 1 Again -> Allocated C Server 4 3 A 1 B C 2 5
Recover B Server -> Add Item 1 4 3 A 1 1 B C 2 5
Real Implementation C+2 A C+3 B+3 A+1 A+4 B B+2 C+1 A+2 B+1 C A+3
주의사항
Item Size 1~XXX KB, Item 사이즈는적을수록좋다.
변화하는데이터 변화하지않는데이터
변화하는데이터 Divide 변화하지않는데이터
간단한해결책
DB 서버 Disk는 SSD 메모리도데이터보다많이 돈돈돈!!! 최소 3~5 배이상성능향상
DB 서버 Disk 는 SSD 메모리도데이터보다많이 최소 3~5 배이상성능향상
Cache In Global Service
Memcached In Facebook Facebook and Google and Many Companies Facebook 하루 Login 5 억명 ( 한달에 8 억명 )( 최신, 밑에는작년 2010/04 자료 ) 활성사용자 7,000 만 사용자증가비율 4 일에 100 만명 Web 서버 10,000 대, Web Request 초당 2000 만번 Memcached 서버 805 대 -> 15TB, HitRate: 95% Mysq server 1,800 대 Master/Slave( 각각, 900 대 ) Mem: 25TB, SQL Query 초당 50 만번
Cache In Twitter(Old) API WEB Page Cache DB DB
Cache In Twitter(NEW) API WEB Page Cache Fragment Cache Row Cache Vector Cache DB DB DB
Redis In Wonga Using Redis for DataStore Write/Read
Redis In Instagram Using Redis for M/S Snapshot with Slave Hash For PhotoID and image Path
Q & A
Thank You!