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