Scalable

1,650 views
1,523 views

Published on

Scalable, gearman, memcaced, mysql

Scalable

  1. 1. 날로 먹는Scalable 이야기! charsyam@naver.com
  2. 2. 발표자 소개! 나! 이런 사람이야~• 이름 : 강대명• 성별: 남!• 직업: 아키텍트를 꿈꾸는 프로그래머• 직장: NHN( 6개월된 잉여 서버 개발자 )• 특기: 스터디 발표 날로 먹기!
  3. 3. Topic: 이야기 거리
  4. 4. Scalable
  5. 5. Scale UP VsScale OUT
  6. 6. Scale UP
  7. 7. 초당 1000 TPS
  8. 8. 초당 3000 TPS3배 처리 가능한 서버를 투입
  9. 9. Scale OUT
  10. 10. 초당 1000 TPS
  11. 11. 초당 2000 TPS
  12. 12. 초당 3000 TPS
  13. 13. What is Better?
  14. 14. Depends on
  15. 15. 구입 가격 Depends on
  16. 16. 구입 가격 Depends on 관리/유지비
  17. 17. rchitecture
  18. 18. DistributionTransparency
  19. 19. Access : 사용자가 자원에 대한 접근 방법을 알 필요가 없다. Location: 사용자는 자원이 로컬인지, 원격인지 물리적 위치에 대해서 알 필요가 없다. Migration: 사용자는 자원의 물리적 위치가 이동하더라도, 기존 이름으로 서비스 가능해야 한다. Relocation: 사용자는 사용 중에 자원의 위치가 이동하더라도, 이에 대해 알 필요가 없다. Replication: 사용자는 사용 중인 자원이 복제된 것인지 원본인지 알 필요가 없다Concurrency: 사용자는 사용 중인 자원의 동시성에 대해서 싞경 쓸 필요가 없다. 그냥 혼자 쓰는 자원처럼 인식되어야 한다. Failure: 사용자는 사용 중인 자원이 장애가 발생하고, 이에 대한 복원이 이루어지더라도 그에 대해 알 필요가 없다.
  20. 20. Access : 사용자가 자원에 대한 접근 방법을 알 필요가 없다. Location: 사용자는 자원이 로컬인지, 원격인지 물리적 위치에 대해서 알 필요가 없다. Migration: 사용자는 자원의 물리적 위치가 이동하더라도, 기존 이름으로 서비스 가능해야 한다. Relocation: 사용자는 사용 중에 자원의 위치가 이동하더라도, 이에 대해 알 필요가 없다. Replication: 사용자는 사용 중인 자원이 복제된 것인지 원본인지 알 필요가 없다Concurrency: 사용자는 사용 중인 자원의 동시성에 대해서 싞경 쓸 필요가 없다. 그냥 혼자 쓰는 자원처럼 인식되어야 한다. Failure: 사용자는 사용 중인 자원이 장애가 발생하고, 이에 대한 복원이 이루어지더라도 그에 대해 알 필요가 없다.
  21. 21. Access : 사용자가 자원에 대한 접근 방법을 알 필요가 없다. Location: 사용자는 자원이 로컬인지, 원격인지 물리적 위치에 대해서 알 필요가 없다. Migration: 사용자는 자원의 물리적 위치가 이동하더라도, 기존 이름으로 서비스 가능해야 한다. Relocation: 사용자는 사용 중에 자원의 위치가 이동하더라도, 이에 대해 알 필요가 없다. Replication: 사용자는 사용 중인 자원이 복제된 것인지 원본인지 알 필요가 없다Concurrency: 사용자는 사용 중인 자원의 동시성에 대해서 싞경 쓸 필요가 없다. 그냥 혼자 쓰는 자원처럼 인식되어야 한다. Failure: 사용자는 사용 중인 자원이 장애가 발생하고, 이에 대한 복원이 이루어지더라도 그에 대해 알 필요가 없다.
  22. 22. Access : 사용자가 자원에 대한 접근 방법을 알 필요가 없다. Location: 사용자는 자원이 로컬인지, 원격인지 물리적 위치에 대해서 알 필요가 없다. Migration: 사용자는 자원의 물리적 위치가 이동하더라도, 기존 이름으로 서비스 가능해야 한다. Relocation: 사용자는 사용 중에 자원의 위치가 이동하더라도, 이에 대해 알 필요가 없다. Replication: 사용자는 사용 중인 자원이 복제된 것인지 원본인지 알 필요가 없다Concurrency: 사용자는 사용 중인 자원의 동시성에 대해서 싞경 쓸 필요가 없다. 그냥 혼자 쓰는 자원처럼 인식되어야 한다. Failure: 사용자는 사용 중인 자원이 장애가 발생하고, 이에 대한 복원이 이루어지더라도 그에 대해 알 필요가 없다.
  23. 23. Access : 사용자가 자원에 대한 접근 방법을 알 필요가 없다. Location: 사용자는 자원이 로컬인지, 원격인지 물리적 위치에 대해서 알 필요가 없다. Migration: 사용자는 자원의 물리적 위치가 이동하더라도, 기존 이름으로 서비스 가능해야 한다. Relocation: 사용자는 사용 중에 자원의 위치가 이동하더라도, 이에 대해 알 필요가 없다. Replication: 사용자는 사용 중인 자원이 복제된 것인지 원본인지 알 필요가 없다Concurrency: 사용자는 사용 중인 자원의 동시성에 대해서 싞경 쓸 필요가 없다. 그냥 혼자 쓰는 자원처럼 인식되어야 한다. Failure: 사용자는 사용 중인 자원이 장애가 발생하고, 이에 대한 복원이 이루어지더라도 그에 대해 알 필요가 없다.
  24. 24. Access : 사용자가 자원에 대한 접근 방법을 알 필요가 없다. Location: 사용자는 자원이 로컬인지, 원격인지 물리적 위치에 대해서 알 필요가 없다. Migration: 사용자는 자원의 물리적 위치가 이동하더라도, 기존 이름으로 서비스 가능해야 한다. Relocation: 사용자는 사용 중에 자원의 위치가 이동하더라도, 이에 대해 알 필요가 없다. Replication: 사용자는 사용 중인 자원이 복제된 것인지 원본인지 알 필요가 없다Concurrency: 사용자는 사용 중인 자원의 동시성에 대해서 싞경 쓸 필요가 없다. 그냥 혼자 쓰는 자원처럼 인식되어야 한다. Failure: 사용자는 사용 중인 자원이 장애가 발생하고, 이에 대한 복원이 이루어지더라도 그에 대해 알 필요가 없다.
  25. 25. Access : 사용자가 자원에 대한 접근 방법을 알 필요가 없다. Location: 사용자는 자원이 로컬인지, 원격인지 물리적 위치에 대해서 알 필요가 없다. Migration: 사용자는 자원의 물리적 위치가 이동하더라도, 기존 이름으로 서비스 가능해야 한다. Relocation: 사용자는 사용 중에 자원의 위치가 이동하더라도, 이에 대해 알 필요가 없다. Replication: 사용자는 사용 중인 자원이 복제된 것인지 원본인지 알 필요가 없다Concurrency: 사용자는 사용 중인 자원의 동시성에 대해서 싞경 쓸 필요가 없다. 그냥 혼자 쓰는 자원처럼 인식되어야 한다. Failure: 사용자는 사용 중인 자원이 장애가 발생하고, 이에 대한 복원이 이루어지더라도 그에 대해 알 필요가 없다.
  26. 26. Access : 사용자가 자원에 대한 접근 방법을 알 필요가 없다. Location: 사용자는 자원이 로컬인지, 원격인지 물리적 위치에 대해서 알 필요가 없다. Migration: 사용자는 자원의 물리적 위치가 이동하더라도, 기존 이름으로 서비스 가능해야 한다. Relocation: 사용자는 사용 중에 자원의 위치가 이동하더라도, 이에 대해 알 필요가 없다. Replication: 사용자는 사용 중인 자원이 복제된 것인지 원본인지 알 필요가 없다Concurrency: 사용자는 사용 중인 자원의 동시성에 대해서 싞경 쓸 필요가 없다. 그냥 혼자 쓰는 자원처럼 인식되어야 한다. Failure: 사용자는 사용 중인 자원이 장애가 발생하고, 이에 대한 복원이 이루어지더라도 그에 대해 알 필요가 없다.
  27. 27. ifficult!!!
  28. 28. UseFramework
  29. 29. 3 Things +1
  30. 30. 3 Things Gearman Memcached MySQL Scale Out
  31. 31. GEARMAN
  32. 32. Queue JobService + Server
  33. 33. Multi platformMulti Language
  34. 34. Gearman Flow
  35. 35. Gearman Cluster
  36. 36. GEARMANMANAGER
  37. 37. Gearman Cluster 한대가 오류가 나더라도 다른 서버로 접근 단, addserver 로 추가해줘야 한다.
  38. 38. Gearman DynamicGearman A,B Worker A 등록 서비스 작업처리 결과 전송 Client A 요청
  39. 39. Gearman Dynamic 2Gearman A,B Client A 요청 서비스 A 대기 작업처리 결과 전송 Worker A 등록
  40. 40. Gearman Map/Reduce Client Gearman Job Server Map/Reduce Worker Client Client Client Gearman Job Server Worker Worker Worker
  41. 41. Who Use Gearman!Digg: 45+ Server, 400K Jobs/dayYahoo: 120+ Server, 12M jobs/day
  42. 42. Apply Cache ServerPerfomance UP
  43. 43. Client Client Client Server WriteCache Layer DBMS Update
  44. 44. MEMCACHED
  45. 45. NoSQLKey-Value Store
  46. 46. AtomicOperation
  47. 47. Who use Memcached?• Facebook and Google and Many Companies• Facebook – 현재 가입자 수 6억명 – 활성 사용자 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만번
  48. 48. CACHE 이용의 2가지 모델: 1 Client CACHE SERVER
  49. 49. CACHE 이용의 2가지 모델: 2 Client SERVER CACHE
  50. 50. No, Free LunchNo, Silver Bullet
  51. 51. 1G MEM vs 4G MEM
  52. 52. Appling Scale Out OnMemcached Server
  53. 53. DistributedMemcached Server
  54. 54. Client Proxy : Key ManagementMemcached Memcached Memcached Server Server Server
  55. 55. NorthScale Project
  56. 56. MySQL Scale Out
  57. 57. DefaultArchitecture
  58. 58. ClientMaster REPLICATION/FailOverSlave
  59. 59. One Write Master +Multi Read Slave
  60. 60. Client ONLY WRITE Only READ MasterREPLICATION Slave Slave Slave
  61. 61. Partitioning
  62. 62. Why?Partitioning
  63. 63. Scalable Partitioning Client PART 1 PART 2 Web Server Web Server DBMS DBMS
  64. 64. 추가로 고민하면 좋은거?
  65. 65. Elastic!!!
  66. 66. Thank You!
  67. 67. 권장 도서

×