Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
초보자를 위한 웹 서비스 캐시 전략 
charsyam@naver.com
Agenda 
•왜 캐시를 사용해야 하는가? 
•확장을 위한 캐시 방법
서비스 초창기
목표?
목표? 백만, 천만?
네이버 다니시나요? 그럼 1번, 아니면 2번…
1번. 이걸 들을 필요가… 없습니다. T.T
2번. 일단 출시가 먼저죠.
Client 
Buisness Logic 
Storage 
서비스 초창기 구조: 1대
서비스가 잘된다면?
확장이 필요합니다.
어디가 가장 문제가 될까요?
Client 
Buisness 
Logic 
Storage 
Client?
Client 
Buisness 
Logic 
Storage 
Buisness Logic?
Client 
Business 
Logic 
Storage 
Storage?
선택 할 수 있는 방법?
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 이 비용이 적게 든다.
진실은…
뒤로 가면 다~~~ 어렵워요!!!
뭐든지, 달리는 열차의 바퀴를 갈아 끼우는 겁니다.
다시 캐시 얘기로…
캐시를 선택해야 하는 이유.
1. 돈이 부족한데 성능을 더 높여야 할때…
2. 돈은 있지만… 성능을 더 높여야 할때…
Use Case: Login
Use Case: Login 
DB에서 읽기 
Select * from Users where id=‘charsyam’;
유저 수가 적으면…
충분히 빠릅니다.
그런데 유저 수가 
엄청 많으면?
DB도 인덱스 걸면 충분히 빠릅니다.
단 읽기만 한다면…
또, 디스크 읽는 수 가 적을때만
Disk Page 접근 문제
Use Case: Login 
읽기에 캐시 적용
Use Case: Login 
캐시에서 읽기 
Get charsyam
적용 결과…
Select Query
CPU utility
균등한 속도!!! 
부하 감소!!!
Use Case: Log
Use Case: Log 
Apply Cache For Write
Use Case: Log 
Insert DB per one log 
Insert into clicklogs values(a,b,c);
Use Case: Log 
모아서 쓰기…1024개 단위 
Insert into clicklogs values(a1,b1,c1), 
(a2,b2,c2), (a3,b3,c3)
모아 쓰기를 위한 
버퍼로 캐시 사용
적용 결과…
10 만건 insert 
쓰기 단위 
1 
1024 
속도(초) 
16~17 
1.4~1.5
캐시를 쓰면 좋다는 건 알겠는데…
그럼 캐시 서버의 
확장은?
1대만 쓰기에는…
캐시 역시 데이터…
Client 
Business 
Logic 
Storage 
일단 어디에 캐시가?
Client 
Business 
Logic 
Storage 
Client – Logic?
Client 
Business 
Logic 
Storage 
Logic - Storage?
당연히 보통은 
후자가 올바릅니다.
General Cache Layer 
Cache 
DBMS 
Storage Layer 
Application 
Server 
READ 
WRITE 
WRITE 
UPDATE
그럼 어떤 데이터를 
캐시해야 할까요?
당연히 자주 찾을 것 같은 데이터를 캐시해야 합니다.
이런 데이터는 서비스마다 다릅니다.
페이스북이라면 어떤걸 캐시하고 있을까요?
Login을 위한 
유저 정보
첫 화면에 보여줄 
피드 몇백개
친구 관계등
이슈는 Scale
유저 로그인 관련 정보
유저 로그인 관련 정보 
많아도 대부분 메모리에 올라감.
1k * 10,000,000
1k * 10,000,000 
= 10G
그런데 1억명이면?
한 서버당 100G?
한 서버당 100G? 
물론 가능함… 
돈만 있으면…
그럼 10억명이면?
그럼 10억명이면? 
1TB?
캐시의 분배가 필요함
캐시의 분배가 필요함 
데이터
결국은 분배 전략…
그냥 한대?
그냥 한대? 
LRU등으로 자주쓰는 녀석들만… 조금…
여러대면?
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 #...
Modulo
Modulo 
Id % 서버대수 = k
Modulo 
서버 대수에 따라서 데이터 이동이 많아짐.
Modulo 
가능하면 2배씩 증가하는 게 유리.
Modulo 
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
Consistent Hash
Consistent Hash 
서버의 추가/제거 시에 1/n 정도의 데이터만 사라진다.
Consistent Hash 
다른 방식은 데이터의 서버위치가 고정적이지만, CH는 유동적
A 
Add A,B,C Server
A 
B 
Add A,B,C Server
A 
B 
C 
Add A,B,C Server
A 
B 
C 
1 
Add Item 1
A 
B 
C 
1 
2 
Add Item 2
A 
B 
C 
1 
2 
3 
4 
5 
Add Item 3,4,5
A 
B 
C 
2 
3 
4 
5 
Fail!! B Server
A 
B 
C 
1 
2 
3 
4 
5 
Add Item 1 Again -> Allocated C Server
A 
B 
C 
1 
2 
3 
4 
5 
1 
Recover B Server -> Add Item 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 ...
다양한 변종도 
있을 수 있음.
적합한 방식은 
서비스 
마다 다름.
서버의 목록은 
Zookeeper 등으로 
관리하면 좋음
정리하면…
시작할 때는 
뭐 하기 어려움.
다만 조금만 고민해도 
Technical Debt 
을 줄일 수 있음.
Thank you!
Upcoming SlideShare
Loading in …5
×

Webservice cache strategy

23,396 views

Published on

Published in: Technology

Webservice cache strategy

  1. 1. 초보자를 위한 웹 서비스 캐시 전략 charsyam@naver.com
  2. 2. Agenda •왜 캐시를 사용해야 하는가? •확장을 위한 캐시 방법
  3. 3. 서비스 초창기
  4. 4. 목표?
  5. 5. 목표? 백만, 천만?
  6. 6. 네이버 다니시나요? 그럼 1번, 아니면 2번…
  7. 7. 1번. 이걸 들을 필요가… 없습니다. T.T
  8. 8. 2번. 일단 출시가 먼저죠.
  9. 9. Client Buisness Logic Storage 서비스 초창기 구조: 1대
  10. 10. 서비스가 잘된다면?
  11. 11. 확장이 필요합니다.
  12. 12. 어디가 가장 문제가 될까요?
  13. 13. Client Buisness Logic Storage Client?
  14. 14. Client Buisness Logic Storage Buisness Logic?
  15. 15. Client Business Logic Storage Storage?
  16. 16. 선택 할 수 있는 방법?
  17. 17. Scale Up VS Scale Out
  18. 18. Scale Up
  19. 19. Scale Up 성능이 더 좋은 장비로…
  20. 20. 초당 1000 TPS
  21. 21. 초당 3000 TPS 3배 처리 가능한 서버를 투입
  22. 22. Scale Up CPU 4 -> 24 Mem 4G -> 32G
  23. 23. Scale Out
  24. 24. Scale Out 장비를 더 늘리자.
  25. 25. 초당 1000 TPS
  26. 26. 초당 2000 TPS
  27. 27. 초당 3000 TPS
  28. 28. 일반적으로는 Scale Up 이 더 쉽고 Scale Out 이 비용이 적게 든다.
  29. 29. 진실은…
  30. 30. 뒤로 가면 다~~~ 어렵워요!!!
  31. 31. 뭐든지, 달리는 열차의 바퀴를 갈아 끼우는 겁니다.
  32. 32. 다시 캐시 얘기로…
  33. 33. 캐시를 선택해야 하는 이유.
  34. 34. 1. 돈이 부족한데 성능을 더 높여야 할때…
  35. 35. 2. 돈은 있지만… 성능을 더 높여야 할때…
  36. 36. Use Case: Login
  37. 37. Use Case: Login DB에서 읽기 Select * from Users where id=‘charsyam’;
  38. 38. 유저 수가 적으면…
  39. 39. 충분히 빠릅니다.
  40. 40. 그런데 유저 수가 엄청 많으면?
  41. 41. DB도 인덱스 걸면 충분히 빠릅니다.
  42. 42. 단 읽기만 한다면…
  43. 43. 또, 디스크 읽는 수 가 적을때만
  44. 44. Disk Page 접근 문제
  45. 45. Use Case: Login 읽기에 캐시 적용
  46. 46. Use Case: Login 캐시에서 읽기 Get charsyam
  47. 47. 적용 결과…
  48. 48. Select Query
  49. 49. CPU utility
  50. 50. 균등한 속도!!! 부하 감소!!!
  51. 51. Use Case: Log
  52. 52. Use Case: Log Apply Cache For Write
  53. 53. Use Case: Log Insert DB per one log Insert into clicklogs values(a,b,c);
  54. 54. Use Case: Log 모아서 쓰기…1024개 단위 Insert into clicklogs values(a1,b1,c1), (a2,b2,c2), (a3,b3,c3)
  55. 55. 모아 쓰기를 위한 버퍼로 캐시 사용
  56. 56. 적용 결과…
  57. 57. 10 만건 insert 쓰기 단위 1 1024 속도(초) 16~17 1.4~1.5
  58. 58. 캐시를 쓰면 좋다는 건 알겠는데…
  59. 59. 그럼 캐시 서버의 확장은?
  60. 60. 1대만 쓰기에는…
  61. 61. 캐시 역시 데이터…
  62. 62. Client Business Logic Storage 일단 어디에 캐시가?
  63. 63. Client Business Logic Storage Client – Logic?
  64. 64. Client Business Logic Storage Logic - Storage?
  65. 65. 당연히 보통은 후자가 올바릅니다.
  66. 66. General Cache Layer Cache DBMS Storage Layer Application Server READ WRITE WRITE UPDATE
  67. 67. 그럼 어떤 데이터를 캐시해야 할까요?
  68. 68. 당연히 자주 찾을 것 같은 데이터를 캐시해야 합니다.
  69. 69. 이런 데이터는 서비스마다 다릅니다.
  70. 70. 페이스북이라면 어떤걸 캐시하고 있을까요?
  71. 71. Login을 위한 유저 정보
  72. 72. 첫 화면에 보여줄 피드 몇백개
  73. 73. 친구 관계등
  74. 74. 이슈는 Scale
  75. 75. 유저 로그인 관련 정보
  76. 76. 유저 로그인 관련 정보 많아도 대부분 메모리에 올라감.
  77. 77. 1k * 10,000,000
  78. 78. 1k * 10,000,000 = 10G
  79. 79. 그런데 1억명이면?
  80. 80. 한 서버당 100G?
  81. 81. 한 서버당 100G? 물론 가능함… 돈만 있으면…
  82. 82. 그럼 10억명이면?
  83. 83. 그럼 10억명이면? 1TB?
  84. 84. 캐시의 분배가 필요함
  85. 85. 캐시의 분배가 필요함 데이터
  86. 86. 결국은 분배 전략…
  87. 87. 그냥 한대?
  88. 88. 그냥 한대? LRU등으로 자주쓰는 녀석들만… 조금…
  89. 89. 여러대면?
  90. 90. Range
  91. 91. Range 1~백만: 1번 백만1~2백만: 2번
  92. 92. Range Range가 너무 크면 서버별 사용 리소스가 크게 차이날 수 있다.
  93. 93. Range 서버 추가 시에 Range 조절이 없으면 데이터 이동이 없다.
  94. 94. Range User #1 User #10 User #1000000 User #1000001 User #1000100 User #2000000 User #2000001 User #2000200 User #3000000 Server User #1000005 2
  95. 95. Modulo
  96. 96. Modulo Id % 서버대수 = k
  97. 97. Modulo 서버 대수에 따라서 데이터 이동이 많아짐.
  98. 98. Modulo 가능하면 2배씩 증가하는 게 유리.
  99. 99. Modulo Logical Shard Physical Shard
  100. 100. Modulo User #1 User #4 User #7 User #2 User #5 User #8 User #3 User #6 User #9 Server User #1 1
  101. 101. Consistent Hash
  102. 102. Consistent Hash 서버의 추가/제거 시에 1/n 정도의 데이터만 사라진다.
  103. 103. Consistent Hash 다른 방식은 데이터의 서버위치가 고정적이지만, CH는 유동적
  104. 104. A Add A,B,C Server
  105. 105. A B Add A,B,C Server
  106. 106. A B C Add A,B,C Server
  107. 107. A B C 1 Add Item 1
  108. 108. A B C 1 2 Add Item 2
  109. 109. A B C 1 2 3 4 5 Add Item 3,4,5
  110. 110. A B C 2 3 4 5 Fail!! B Server
  111. 111. A B C 1 2 3 4 5 Add Item 1 Again -> Allocated C Server
  112. 112. A B C 1 2 3 4 5 1 Recover B Server -> Add Item 1
  113. 113. Indexed
  114. 114. Indexed 해당 데이터가 어디 존재하는지 Index 서버가 따로 존재
  115. 115. Indexed 해당 데이터가 어디 존재하는지 Index 서버가 따로 존재
  116. 116. Indexed Index 변경으로 데이터 이동이 자유롭다.
  117. 117. Indexed Index 서버에 대한 관리가 추가로 필요.
  118. 118. 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
  119. 119. 다양한 변종도 있을 수 있음.
  120. 120. 적합한 방식은 서비스 마다 다름.
  121. 121. 서버의 목록은 Zookeeper 등으로 관리하면 좋음
  122. 122. 정리하면…
  123. 123. 시작할 때는 뭐 하기 어려움.
  124. 124. 다만 조금만 고민해도 Technical Debt 을 줄일 수 있음.
  125. 125. Thank you!

×