Scalable, gearman, memcaced, mysql

1. 날로 먹는
Scalable 이야기!
charsyam@naver.com

2. 발표자 소개!
나! 이런 사람이야~
• 이름 : 강대명
• 성별: 남!
• 직업: 아키텍트를 꿈꾸는 프로그래머
• 직장: NHN( 6개월된 잉여 서버 개발자 )
• 특기: 스터디 발표 날로 먹기!

3. Topic: 이야기 거리

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

18. Distribution
Transparency

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

33. Multi platform
Multi Language

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

44. Apply Cache Server
Perfomance UP

45. Client Client Client
Server
Write
Cache Layer DBMS
Update

46. MEMCACHED

47. NoSQL
Key-Value Store

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

57. Distributed
Memcached Server

58. Client
Proxy : Key Management
Memcached Memcached Memcached
Server Server Server

59. NorthScale
Project

60. MySQL Scale Out

61. Default
Architecture

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

67. Why?
Partitioning

70. Scalable Partitioning
Client
PART 1 PART 2
Web Server Web Server
DBMS DBMS

71. 추가로 고민하면
좋은거?

72. Elastic!!!

73. Thank You!

74. 권장 도서