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