Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Elastic webservice

  • Sé el primero en comentar

Elastic webservice

  1. 1. 웹 서비스 확장 전략 강대명 charsyam@naver.com
  2. 2. 오늘의 주제
  3. 3. 웹 서비스 확장전략?
  4. 4. 왜?
  5. 5. 그냥 장비 더 넣으면 되지 않나요?
  6. 6. 그래도 됩니다.
  7. 7. 그래도 됩니다. 다만 돈이 더 많이 들뿐
  8. 8. 그래도 됩니다. 다만 시간이 더 들뿐
  9. 9. 올바른(?) 확장 방법에 대해서 알아봅시다.
  10. 10. 웹 서비스
  11. 11. 웹,모바일
  12. 12. 간단한 서비스
  13. 13. 최소로 MVP만 구현
  14. 14. 출시 우선
  15. 15. Client Buisness Logic Storage 서비스 초창기 구조: 1대
  16. 16. Client WEB DB(Mysql) 바꿔 말하면…
  17. 17. 장애를 대비하면…
  18. 18. Client WEB#1 DB(Master) 시작은 대충 이런 모습 DB(Slave) WEB#2 WEB#3
  19. 19. 잘 되는 건 운…
  20. 20. 서비스가 잘된다면?
  21. 21. 확장이 필요합니다.
  22. 22. 어디가 가장 문제가 될까요?
  23. 23. Client Buisness Logic Storage Client?
  24. 24. Client Buisness Logic Storage Buisness Logic?
  25. 25. Client Web App Server Storage Storage?
  26. 26. 서비스마다 다르고
  27. 27. 같은 서비스라도 상황마다 다릅니다.
  28. 28. 가정 #1
  29. 29. 매번 천만 팩토리얼을 계산하는 서비스면?
  30. 30. 대부분 CPU 작업
  31. 31. Client Buisness Logic Storage Buisness Logic이 뻥
  32. 32. Client WEB DB(Mysql) CPU 작업이 많으면…
  33. 33. Client WEB DB(Mysql) CPU 작업이 많으면… WEB 확장 WEB 확장
  34. 34. 추가로…
  35. 35. Web 단이 늘어나면?
  36. 36. Client는 어떻게 알까?
  37. 37. DNS를 이용
  38. 38. Client WEB #1 DNS Round Robin WEB #2 WEB #3
  39. 39. Client WEB #1 DNS Round Robin WEB #2 WEB #3 DNS api.factorial.com WEB #2
  40. 40. DNS RR은 서버 장애시 전파 시간의 단점이 존재
  41. 41. Load Balancer 를 이용
  42. 42. Client WEB #1 LB WEB #2 WEB #3 Load Balancer
  43. 43. 하드웨어 LB 비쌉니다.
  44. 44. 소프트웨어 LB 이중화 등이 필요…
  45. 45. 로직 단의 확장은, 대체로 쉬운편…
  46. 46. 가정 #2
  47. 47. 매번 내 친구들의 목록을 가 져오는 서비스라면?
  48. 48. Client Web App Server Storage Storage
  49. 49. DB 작업이 많으면?
  50. 50. Client WEB DB(Mysql) 이런 확장이 도움이 될까? WEB 확장 WEB 확장
  51. 51. Client WEB DB(Mysql) 도움이 안됨… WEB 확장 WEB 확장 DB가 할수 있는 일은 동일
  52. 52. 그렇다면?
  53. 53. Client WEB DB(Mysql) DB 작업이 많으면… DB 확장
  54. 54. 그런데 DB 확장은 쉽지가 않네요.
  55. 55. 잠시 확장을 위한 선택 방법
  56. 56. Scale Up VS Scale Out
  57. 57. Scale Up
  58. 58. Scale Up 성능이 더 좋은 장비로…
  59. 59. 초당 1000 TPS
  60. 60. 초당 3000 TPS 3배 처리 가능한 서버를 투입
  61. 61. Scale Up CPU 4 -> 24 Mem 4G -> 32G
  62. 62. Scale Out
  63. 63. Scale Out 장비를 더 늘리자.
  64. 64. 초당 1000 TPS
  65. 65. 초당 2000 TPS
  66. 66. 초당 3000 TPS
  67. 67. 일반적으로는 Scale Up 이 더 쉽고 Scale Out 이 비 용이 적게 든다.
  68. 68. 그러나 가능하면 일단은 Scale Up 을 시도해보자.
  69. 69. 메모리, CPU, SSD 등의 간단히 업그레이드 가능한 것들…
  70. 70. 하드웨어 가격이 점점 싸져서, Scale Out 도 좋은 전략
  71. 71. 돌아가기 전에… 확장이 필요한건 어떻게?
  72. 72. 메모리 사용량 CPU 사용량 CPU Load (웹, DB) 서버 로그
  73. 73. 다시 돌아가서…
  74. 74. 스토리지의 확장
  75. 75. 두가지 질문…
  76. 76. 어떤 부하가 많은가? 읽기 VS 쓰기
  77. 77. 어떻게 원하는 데이터를 쉽게 찾을 것인가?
  78. 78. 어떤 부하가 많은가? 읽기, 쓰기의 비율에 다른 다른 조치가 필요.
  79. 79. 일반적인 서비스 부하 200 writes/s 800 reads/s Read > Write
  80. 80. Read 가 80% 정도면?
  81. 81. Read 가 80% 정도면? Read를 분산하자.
  82. 82. DB의 Slave 에서 읽기를 수행
  83. 83. 일반적인 DB 구성 DB(Master) DB(slave) Write Read Replication Failover 모든 요청을 Master 가 처리, Slave는 장애 대비
  84. 84. Read 분산 DB 구성 DB(Master) DB(slave) Write Read Replication Failover Master는 쓰기만 처리, 읽기는 전부 Slave에서
  85. 85. 200 writes/s 800 reads/s 200 writes/s 400 reads/s 200 writes/s 400 reads/s Read/1 Server Read/2 Server
  86. 86. Slave 만 계속 추가하면 읽기는 계속 늘어날까요?
  87. 87. Write가 늘어날 수록 성능은 떨어집니다.
  88. 88. 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
  89. 89. Write 를 분산하자.
  90. 90. Write 비율이 높거나
  91. 91. 데이터가 무지막지하게 많아서 한 서버에 안 들어간다면…
  92. 92. Write가 나눠지면 데이터를 어떻게 찾을 것 인가로 다시 귀결됨 (두번째 질문)
  93. 93. 일반적인 DB 구성 DB #1 Read #1 Write #1 Read #2 Write #2 DB별로 해당하는 Key들의 리퀘스트만 보냄. DB #2
  94. 94. 어떻게 해당 서버를 찾지?
  95. 95. 어떤 Key(속성) 이 찾기에 적당할 까?
  96. 96. 인스타그램을 생각해봅시다.
  97. 97. 특정 유저를 어떻게 찾을까?
  98. 98. 특정 사진을 어떻게 찾을까?
  99. 99. User ID
  100. 100. 사진 ID
  101. 101. 둘다 숫자라고 가정
  102. 102. User 관련 정보
  103. 103. User 관련 정보 많아도 한 서버에서 처리 가능
  104. 104. 1k * 10,000,000
  105. 105. 1k * 10,000,000 = 10G
  106. 106. 그런데 1억명이면?
  107. 107. 한 서버당 100G?
  108. 108. 그럼 10억명이면?
  109. 109. 그럼 10억명이면? 1TB?
  110. 110. User 관련 정보 60억 다 있어도 그렇 게 크지는 않음.
  111. 111. 그러나 사진은?
  112. 112. Instagram 64 bits
  113. 113. Instagram ID
  114. 114. Instagram 자신이 들어갈 서버의 주소가 Logical Shard ID로 존재
  115. 115. 서비스 별로 다양한 정책을 취함.
  116. 116. Range, Modular, Indexed
  117. 117. Range
  118. 118. Range 1~백만: 1번 백만1~2백만: 2번
  119. 119. Range Range가 너무 크면 서버별 사용 리소스가 크게 차이날 수 있다.
  120. 120. Range 서버 추가 시에 Range 조절이 없으면 데이터 이동이 없다.
  121. 121. Range User #1 User #10 User #1000000 User #1000001 User #1000100 User #2000000 User #2000001 User #2000200 User #3000000 ServerUser #1000005 2
  122. 122. Modular
  123. 123. Modular Id % 서버대수 = k
  124. 124. Modular 서버 대수에 따라서 데이터 이동이 많아짐.
  125. 125. Modular 가능하면 2배씩 증 가하는 게 유리.
  126. 126. Modular Logical Shard Physical Shard
  127. 127. Modulo User #1 User #4 User #7 User #2 User #5 User #8 User #3 User #6 User #9 ServerUser #1 1
  128. 128. Indexed
  129. 129. Indexed 해당 데이터가 어디 존 재하는지 Index 서버 가 따로 존재
  130. 130. Indexed 해당 데이터가 어디 존 재하는지 Index 서버 가 따로 존재
  131. 131. Indexed Index 변경으로 데이터 이동이 자유롭다.
  132. 132. Indexed Index 서버에 대한 관리가 추가로 필요.
  133. 133. Indexed User #1 User #2000 User #1000000 User #2 User #2001 User #10000 User #3 User #6 User #5000 ServerUser #5000 3 Index Server User 5000 is in 3
  134. 134. 결국은 서비스 확장은 데이터 확장의 이슈
  135. 135. 서비스에 적합한 방 법은 서비스별로 다름
  136. 136. 현재의 트렌드 BO: Shared Nothing DB: Sharding

×