1. 웹 서비스 확장 전략
강대명
charsyam@naver.com

2. 오늘의 주제

3. 웹 서비스 확장전략?

4. 왜?

5. 그냥 장비 더 넣으면
되지 않나요?

6. 그래도 됩니다.

7. 그래도 됩니다.
다만 돈이 더 많이 들뿐

8. 그래도 됩니다.
다만 시간이 더 들뿐

9. 올바른(?) 확장 방법에
대해서 알아봅시다.

10. 웹 서비스

11. 웹,모바일

12. 간단한 서비스

13. 최소로 MVP만 구현

14. 출시 우선

15. Client
Buisness
Logic
Storage
서비스 초창기 구조: 1대

16. Client WEB DB(Mysql)
바꿔 말하면…

17. 장애를 대비하면…

18. Client WEB#1 DB(Master)
시작은 대충 이런 모습
DB(Slave)
WEB#2
WEB#3

19. 잘 되는 건 운…

20. 서비스가 잘된다면?

21. 확장이 필요합니다.

22. 어디가 가장
문제가 될까요?

23. Client
Buisness
Logic
Storage
Client?

24. Client
Buisness
Logic
Storage
Buisness Logic?

25. Client
Web
App Server
Storage
Storage?

26. 서비스마다 다르고

27. 같은 서비스라도
상황마다 다릅니다.

28. 가정 #1

29. 매번 천만 팩토리얼을
계산하는 서비스면?

30. 대부분 CPU 작업

31. Client
Buisness
Logic
Storage
Buisness Logic이 뻥

32. Client WEB DB(Mysql)
CPU 작업이 많으면…

33. Client WEB DB(Mysql)
CPU 작업이 많으면…
WEB 확장
WEB 확장

34. 추가로…

35. Web 단이 늘어나면?

36. Client는 어떻게 알까?

37. DNS를 이용

38. Client WEB #1
DNS Round Robin
WEB #2
WEB #3

39. Client WEB #1
DNS Round Robin
WEB #2
WEB #3
DNS
api.factorial.com
WEB #2

40. DNS RR은 서버 장애시
전파 시간의 단점이 존재

41. Load Balancer 를 이용

42. Client WEB #1
LB
WEB #2
WEB #3
Load
Balancer

43. 하드웨어 LB
비쌉니다.

44. 소프트웨어 LB
이중화 등이 필요…

45. 로직 단의 확장은,
대체로 쉬운편…

46. 가정 #2

47. 매번 내 친구들의 목록을 가
져오는 서비스라면?

48. Client
Web
App Server
Storage
Storage

49. DB 작업이 많으면?

50. Client WEB DB(Mysql)
이런 확장이 도움이 될까?
WEB 확장
WEB 확장

51. Client WEB DB(Mysql)
도움이 안됨…
WEB 확장
WEB 확장
DB가 할수 있는 일은 동일

52. 그렇다면?

53. Client WEB DB(Mysql)
DB 작업이 많으면…
DB 확장

54. 그런데 DB 확장은
쉽지가 않네요.

55. 잠시 확장을 위한
선택 방법

56. Scale Up
VS
Scale Out

57. Scale Up

58. Scale Up
성능이 더 좋은 장비로…

59. 초당 1000 TPS

60. 초당 3000 TPS
3배 처리 가능한 서버를 투입

61. Scale Up
CPU 4 -> 24
Mem 4G -> 32G

62. Scale Out

63. Scale Out
장비를 더 늘리자.

64. 초당 1000 TPS

65. 초당 2000 TPS

66. 초당 3000 TPS

67. 일반적으로는 Scale Up 이
더 쉽고 Scale Out 이 비
용이 적게 든다.

68. 그러나 가능하면 일단은
Scale Up 을 시도해보자.

69. 메모리, CPU, SSD 등의
간단히 업그레이드
가능한 것들…

70. 하드웨어 가격이 점점
싸져서, Scale Out 도
좋은 전략

71. 돌아가기 전에…
확장이 필요한건 어떻게?

72. 메모리 사용량
CPU 사용량
CPU Load
(웹, DB) 서버 로그

73. 다시 돌아가서…

74. 스토리지의 확장

75. 두가지 질문…

76. 어떤 부하가 많은가?
읽기 VS 쓰기

77. 어떻게 원하는 데이터를
쉽게 찾을 것인가?

78. 어떤 부하가 많은가?
읽기, 쓰기의 비율에 다른
다른 조치가 필요.

79. 일반적인 서비스 부하
200 writes/s
800 reads/s Read > Write

80. Read 가 80% 정도면?

81. Read 가 80% 정도면?
Read를 분산하자.

82. DB의 Slave 에서
읽기를 수행

83. 일반적인 DB 구성
DB(Master)
DB(slave)
Write
Read
Replication
Failover
모든 요청을 Master 가 처리, Slave는 장애 대비

84. Read 분산 DB 구성
DB(Master)
DB(slave)
Write
Read
Replication
Failover
Master는 쓰기만 처리, 읽기는 전부 Slave에서

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. Slave 만 계속 추가하면
읽기는 계속 늘어날까요?

87. Write가 늘어날 수록
성능은 떨어집니다.

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. Write 를 분산하자.

90. Write 비율이 높거나

91. 데이터가 무지막지하게
많아서 한 서버에
안 들어간다면…

92. Write가 나눠지면
데이터를 어떻게 찾을 것
인가로 다시 귀결됨
(두번째 질문)

93. 일반적인 DB 구성
DB #1
Read #1
Write #1
Read #2
Write #2
DB별로 해당하는 Key들의 리퀘스트만 보냄.
DB #2

94. 어떻게 해당 서버를 찾지?

95. 어떤 Key(속성) 이
찾기에
적당할 까?

96. 인스타그램을
생각해봅시다.

97. 특정 유저를 어떻게 찾을까?

98. 특정 사진을 어떻게
찾을까?

99. User ID

100. 사진 ID

101. 둘다 숫자라고 가정

102. User 관련 정보

103. User 관련 정보
많아도 한 서버에서
처리 가능

104. 1k * 10,000,000

105. 1k * 10,000,000
= 10G

106. 그런데 1억명이면?

107. 한 서버당 100G?

108. 그럼 10억명이면?

109. 그럼 10억명이면?
1TB?

110. User 관련 정보
60억 다 있어도 그렇
게 크지는 않음.

111. 그러나 사진은?

112. Instagram
64 bits

113. Instagram ID

114. Instagram
자신이 들어갈 서버의 주소가
Logical Shard ID로 존재

115. 서비스 별로 다양한
정책을 취함.

116. Range,
Modular,
Indexed

117. Range

118. Range
1~백만: 1번
백만1~2백만: 2번

119. Range
Range가 너무 크면
서버별 사용 리소스가
크게 차이날 수 있다.

120. Range
서버 추가 시에
Range 조절이 없으면
데이터 이동이 없다.

121. Range
User #1
User #10
User #1000000
User #1000001
User #1000100
User #2000000
User #2000001
User #2000200
User #3000000
ServerUser #1000005
2

122. Modular

123. Modular
Id % 서버대수 = k

124. Modular
서버 대수에 따라서
데이터 이동이 많아짐.

125. Modular
가능하면 2배씩 증
가하는 게 유리.

126. Modular
Logical Shard
Physical Shard

127. Modulo
User #1
User #4
User #7
User #2
User #5
User #8
User #3
User #6
User #9
ServerUser #1
1

128. Indexed

129. Indexed
해당 데이터가 어디 존
재하는지 Index 서버
가 따로 존재

130. Indexed
해당 데이터가 어디 존
재하는지 Index 서버
가 따로 존재

131. Indexed
Index 변경으로 데이터
이동이 자유롭다.

132. Indexed
Index 서버에 대한
관리가 추가로 필요.

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. 결국은 서비스 확장은
데이터 확장의 이슈

135. 서비스에 적합한 방
법은 서비스별로 다름

136. 현재의 트렌드
BO: Shared Nothing
DB: Sharding