How to build massive internet service well.

1. 대규모 서비스를 지탱하는 기술
- 기초편
강대명(charsyam@naver.com)

2. 발표자 소개
● Data Engineer at Udemy(현)
● Software Engineer at Kakao(카카오 스토리)
● Software Engineer at Naver(네이버 메일)
● Software Engineer at Finaldata

4. 배틀그라운드

6. Facebook

8. 이런 서비스는
어떻게 만들어야 할까요?

9. 서버 한대로 가능할까요?

10. 질문
이런 서비스를 운영하기
위해서 몇 대의 서버가
필요할까요?

11. 막 시작하는 초기 스타트업의 구조
DBMS
API ServerWeb Browser
Mobile Apps

12. 용어 설명
● API Server
○ 실제적인 로직을 처리하는 서버, 회원 가입
● DBMS(DataBase Management System)
○ 실제 데이터가 저장되는 곳
○ Mysql, Postgresql, Oracle 등등

13. 처음에는 한대로!!!
● 처음에는 한대로 시작합니다.
○ 왜?
■ 돈이 없습니다.
■ 사용자도 없습니다.

14. 질문
그런데 서버가 한대인데…
서버가 고장나면?

15. 물리 서버가 장애
DBMS
API ServerWeb Browser
Mobile Apps

16. Web Server 가 장애
DBMS
API ServerWeb Browser
Mobile Apps

17. DBMS 가 장애...
DBMS
API ServerWeb Browser
Mobile Apps

18. 이럴 때는 어떻게?

19. 두 대를 둡니다.
DBMS
API Server
Web Browser
Mobile Apps
DBMS
API Server

20. 한 대가 죽더라도... 서비스가...
DBMS
API Server
Web Browser
Mobile Apps
DBMS
API Server

21. 잘 될까요?

22. 두 대일 때의 문제점!!!

23. User의 친구 목록을 가져
온다고 합시다.

24. 두 대 일때의 문제점!!!
DBMS 1
API Server 1
Web Browser
Mobile Apps
DBMS 2
API Server 2
User #1
Friends
User #2
Friends
User #3
Friends

25. User #1은 어디로 가야하나요?
DBMS 1
API Server 1
Web Browser
Mobile Apps
DBMS 2
API Server 2
User #1
User #1
Friends
User #2
Friends
User #3
Friends

26. API Server 1로 가면?
- 찾을 수 있습니다.
DBMS 1
API Server 1
Web Browser
Mobile Apps
DBMS 2
API Server 2
User #1
User #1
Friends
User #2
Friends
User #3
Friends

27. API Server 2로 가면
- 못찾습니다.
DBMS 1
API Server 1
Web Browser
Mobile Apps
DBMS 2
API Server 2
User #1
User #1
Friends
User #2
Friends
User #3
Friends

28. 데이터가 분리되어 있으면
찾기 어렵습니다.

29. 그래서 DB는 따로 분리해서
하나만 바라봅니다.

30. DB가 하나면…
어디로 가든 데이터를
찾을 수 있습니다.
Web Browser
Mobile Apps
User #1
API Server 1
API Server 2
DBMS
User #1
User #1
Friends
User #2
Friends
User #3
Friends

31. 장애가 나도 다른 서버가 서비스가 가능합니다.
Web Browser
Mobile Apps
User #1
API Server 1
API Server 2
DBMS
User #1
User #1
Friends
User #2
Friends
User #3
Friends

32. 장애가 나도 다른 서버가 서비스가 가능합니다.
Web Browser
Mobile Apps
User #1
API Server 1
API Server 2
DBMS
User #1
User #1
Friends
User #2
Friends
User #3
Friends

33. 잘 될까요?

34. 그런데 우리는 어떻게
API Server 1,2 가 있다는
것을 알고 찾을 수 있을까
요?

35. 가설 1 : 사용자가 우리 서버의 주소와 상태를 항상 알
고 있다.
Web Browser
Mobile Apps
API Server 1
1.1.1.3
API Server 2
1.1.1.4
지금 서비스 서버는 2대고 주소는
API Server 1 과 API Server 2
모두 정상이야!!!

36. 가능할까요?
서버가 추가되거나?
주소가 바뀌면?

37. 가설 2 : 사용자는 대표 주소 하나만 알고 우리가 알아
서 나눠준다.
Web Browser
Mobile Apps
API Server 1
1.1.1.3
API Server 2
1.1.1.4

38. DNS

39. DNS
● Domain Name Service
○ 실제로 인터넷 주소는 IP라는 여러 숫자의 조합으로 이루어져 있습
니다.
■ Udemy.com -> 104.18.134.108
● (이건 IPv4, 더 많은 주소를 위한 IPv6도 있습니다.)

40. DNS
> nslookup udemy.com
Server: 1.214.68.2
Address: 1.214.68.2#53
Non-authoritative answer:
Name: udemy.com
Address: 104.18.134.108
Name: udemy.com
Address: 104.18.133.108
Name: udemy.com
Address: 104.18.130.108
Name: udemy.com
Address: 104.18.132.108
Name: udemy.com
Address: 104.18.131.108

41. DNS를 이용하면?
Web Browser
Mobile Apps
API Server 1
1.1.1.3
API Server 2
1.1.1.4
DNS
Request
API Server 1
Response
API Server 1
is 1.1.1.3

42. DNS
● apiserver.com 이라는 주소에
○ 1.1.1.3
○ 1.1.1.4를 할당합니다.

43. DNS를 이용하면 apiserver.com 을 접속하면 두 서버
중에 하나로 접속이 가능합니다.
Web Browser
Mobile Apps
API Server 1
1.1.1.3
API Server 2
1.1.1.4
DNS
Request
apiserver.com
Response
apiserver is
1.1.1.3 and 1.1.1.4

44. 잘 될까요?

45. 친구 목록을 여러번 호출한다고 합시다. 그 때마다 DNS
를 호출한다면?
getFriends()
API Server 1
1.1.1.3
DNS
Request: apiserver.com
Response: 1.1.1.3
getFriends()
Request: apiserver.com
Response: 1.1.1.3

46. DNS 는
TTL(Time to Live) 라는
일종의 캐시를 가지고 있
습니다.

47. DNS TTL
● Facebook 을 하루에 12억명이 사용합니다. 매번 기능을 호출 할 때 마다
DNS를 호출한다면, DNS 서버는 얼마나 커야 할까요?

48. 이미 apiserver.com 은 1.1.1.3이라는 걸 알고 있으므로
30초간 그냥 1.1.1.3을 사용한다.
getFriends()
API Server 1
1.1.1.3
DNS
Request: apiserver.com
Response: 1.1.1.3 TTL: 30
getFriends()
이미 알고 있으므로 바로 1.1.1.3
으로 접속

49. 그런데 장애가 나면?

50. 장애가 나도 응답은 여전히 1.1.1.3 과 1.1.1.4 입니다.
1.1.1.4를 받으면 어떻게 될까요?
Web Browser
Mobile Apps
API Server 1
1.1.1.3
API Server 2
1.1.1.4
DNS
Request
apiserver.com
Response
apiserver is
1.1.1.3 and 1.1.1.4

51. IP 주소가 바뀌면?

52. 이미 apiserver.com 은 1.1.1.3이라는 걸 받았으므로
1.1.1.5로 바뀐걸 TTL 이내에는 알 수 없다.
getFriends()
API Server 1
1.1.1.3
DNS
Request: apiserver.com
Response: 1.1.1.3 TTL: 30
getFriends()
이미 알고 있으므로 바로 1.1.1.3
으로 접속 시도
API Server 1
1.1.1.5

53. Load Balancer

54. Load Balancer(LB) 의 동작
Request 를 연결된 서버들에게 나누어 줍니다.
Web Browser
Mobile Apps
API Server 1
1.1.1.3
API Server 2
1.1.1.4
DNS
Request
apiserver.com
Response
apiserver is
1.1.1.2
LB
1.1.1.2
REQ #1
REQ #2
REQ #3

55. Load Balancer(LB) 의 동작
Request 를 연결된 서버들에게 나누어 줍니다.
Web Browser
Mobile Apps
API Server 1
1.1.1.3
API Server 2
1.1.1.4
DNS
Request
apiserver.com
Response
apiserver is
1.1.1.2
LB
1.1.1.2
REQ #1
REQ #2
REQ #3

56. Load Balancer(LB) 의 동작
Request 를 연결된 서버들에게 나누어 줍니다.
Web Browser
Mobile Apps
API Server 1
1.1.1.3
API Server 2
1.1.1.4
DNS
Request
apiserver.com
Response
apiserver is
1.1.1.2
LB
1.1.1.2
REQ #1
REQ #2REQ #3

57. Load Balancer(LB) 의 동작
Request 를 연결된 서버들에게 나누어 줍니다.
Web Browser
Mobile Apps
API Server 1
1.1.1.3
API Server 2
1.1.1.4
DNS
Request
apiserver.com
Response
apiserver is
1.1.1.2
LB
1.1.1.2
REQ #1
REQ #2
REQ #3

58. Load Balancer가
고장나면 어떻게 되나요?

59. Load Balancer(LB) 의 동작
Request 를 연결된 서버들에게 나누어 줍니다.
Web Browser
Mobile Apps
API Server 1
1.1.1.3
API Server 2
1.1.1.4
DNS
Request
apiserver.com
Response
apiserver is
1.1.1.2
LB
1.1.1.10
Active
REQ #1
REQ #2
REQ #3
LB
1.1.1.11
StandBy
1.1.1.2

60. LB가 장애가 나면? 해당 LB에게 할당된 IP를 다른 LB
에게 넘겨줍니다.
Web Browser
Mobile Apps
API Server 1
1.1.1.3
API Server 2
1.1.1.4
DNS
Request
apiserver.com
Response
apiserver is
1.1.1.2
LB
1.1.1.10
Active
REQ #1
REQ #2
REQ #3
LB
1.1.1.11
Active
1.1.1.2

61. Cloud 서비스 제공자(AWS, GCP, AZURE) 등의 Load
Balancer 는 하나로 보이지만 내부적으로 장애시 위와
같이 동작합니다.
Web Browser
Mobile Apps
API Server 1
1.1.1.3
API Server 2
1.1.1.4
DNS
Request
apiserver.com
Response
apiserver is
1.1.1.2
ELB
1.1.1.2
REQ #1
REQ #2
REQ #3

62. DNS로 돌아가서
이 ip 들은
서버일까요?
LB일까요?
> nslookup udemy.com
Server: 1.214.68.2
Address: 1.214.68.2#53
Non-authoritative answer:
Name: udemy.com
Address: 104.18.134.108
Name: udemy.com
Address: 104.18.133.108
Name: udemy.com
Address: 104.18.130.108
Name: udemy.com
Address: 104.18.132.108
Name: udemy.com
Address: 104.18.131.108

63. 잘 될까요?

64. Data

65. 그런데 DBMS는 한대인데?
Web Browser
Mobile Apps
API Server 1
API Server 2
DBMS

66. 그러면 두대로?
Web Browser
Mobile Apps
API Server 1
API Server 2
DBMS
DBMS

67. 그러면 처음과 같은 문제가
다시 생깁니다.

68. Data Replication
데이터 복제

69. Data Replication
● 한 대의 서버의 내용을 지속적으로 다른 서버로 복제해주는 작업
○ Primay(서비스를 하고 있는 DB)의 내용을 자동으로 Secondary(백
업용 DB) 에 데이터를 복제해줍니다.
● 두 대가 같은 내용을 가지므로, 한 대에 문제가 생기더라도 다른 서버로
서비스가 가능합니다.

70. 데이터 복제
Web Browser
Mobile Apps
API Server 1
API Server 2
DBMS
Primary
DBMS
Secondary
Name Email Password
Name Email Password

71. DBMS 장애
Web Browser
Mobile Apps
API Server 1
API Server 2
DBMS
Primary
DBMS
Primary

72. 복구 되면!!!
Web Browser
Mobile Apps
API Server 1
API Server 2
DBMS
Secondary
DBMS
Primary
Name Email Password
Name Email Password

73. 최소한의 서비스 안전성
을 위한 모습

74. 최소한의 모습
Web Browser
Mobile Apps
API Server 1
1.1.1.3
API Server 2
1.1.1.4
ELB
1.1.1.2
DBMS
Primary
DBMS
Secondary

75. 여기까지가 서비스를 위
한 기본입니다.

76. 대규모 서비스

77. 사용자가 많다.
트래픽이 많다.
데이터가 많다.

78. Facebook
2.27 billion
MAU

79. 사용자가 많다.
트래픽이 많다.
데이터가 많다.

80. Netflix

81. 사용자가 많다.
트래픽이 많다.
데이터가 많다.

82. Data
유저 정보, 친구 목록
글, 사진, 비디오

83. Facebook

84. 하나의 이미지 사이즈는
얼마일까요?

85. 제 폰에서는 대략 4MB

86. 4MB * 1000 = 4GB
4GB * 1000 = 4TB

87. 백만 장 정도의
사진 저장에
4TB

88. 이런 구조?
Web Browser
Mobile Apps
API Server 1
API Server 2
File Server
4TB
4TB
4TB

89. 어떤 문제가 있을가요?

90. File Server 가 장애나면?
Web Browser
Mobile Apps
API Server 1
API Server 2
File Server
4TB
4TB
4TB

91. 결국 데이터 복제가
필요합니다.

92. 그러면 몇개의 복제본을 둬야 할까요?
Web Browser
Mobile Apps
API Server 1
API Server 2 File Server
4TB
4TB
4TB
File Server
4TB
4TB
4TB

93. 3개의 복제본

94. Uptime : 서비스가 기동 중인 시간
가동율 장애 시간(1년 기준)
90% 36일
99% 3.65일
99.5% 1.83일
99.9% 8.76 시간
99.99% 52.56 분
99.999% 5.25 분
99.9999% 31.5 초

95. Data Loss : 보통 3개의 복제본을 두면 99.999% 보
장
보장율 복제 개수
99.99% 2
99.999% 3

96. 4MB 사진 백만장을
저장하려면?
4TB * 3 = 12TB 가 필요.

97. 저장 공간만 있으면
충분할까요?

98. 각각의 사진 정보가
어느 서버에 있는지도
관리해야 합니다.

99. Object Storage

100. 클라우드에서는 보통
이런 서비스를 제공해줍
니다.

101. AWS S3
AZURE Blob
GCP Google Stroage

102. P2P 기반의 IPFS 라는
프로젝트도 있습니다.

103. 이런 Object 스토리지 서비스는 큰 회사는 자체적으로,
작은 곳에서는 그냥 클라우드껄 쓰는게 이득입니다.
Web Browser
Mobile Apps
API Server 1
API Server 2
Object
Storage
Service

104. 그런데 잘 동작할까요?

105. 이미지나 동영상은 외부에
저장하더라도, 그 정보는
따로 관리할 필요가 있습니다.

106. 예를 들면

107. 데이터의 종류
doc1 doc2
abcdefg1
doc1 이라는 주소를 가진 문서가
abcdefg1 이라는 이미지를 가지고
있다고 합니다.

108. doc1 이 abcdefg1 이라는
이미지를 가진다는 정보를
관리할 필요가 있습니다.

109. 이런 식으로...
Web Browser
Mobile Apps
API Server 1
API Server 2
DBMS
primary
DBMS
secondary
Object
Storage
Service
abcdefg1
abcdefg2
abcdefg3
abcdefg1
abcdefg2
abcdefg3
doc1
doc2
doc3

110. 그런데 잘 동작할까요?

111. 어느 정도 규모까지는 잘
동작할껍니다.

112. 데이터 팽창의 시
대
Giga : 1000 MB
Tera : 1000 GB
Peta : 1000 TB
Exa : 1000 PB
Zeta : 1000 Exa

113. Limitation
한계

114. DBMS 의 한계

115. DBMS 의 한계
TPS

116. TPS
Transaction Per Second
초당 몇개의 명령을 처리할 수 있는
가?

117. TPS
만약 MAX 1000TPS 라면
1초에 1000개의 명령이
처리가 가능합니다.

118. TPS
CPU 나 메모리, 디스크 속도등에
영향을 받게됩니다.

119. 너무 많은 명령을 처리해야 하
면 아주 오래걸리거나
장비가 고장날 수 있습니다.

120. Response Time

121. Facebook 글 하나 보는데
클릭 후 한시간 뒤에 보인다면?

122. Scale Up
Vs
Scale Out

124. 하드웨어 성능은 좋아지고
가격은 싸지고 있습니다.
(메모리 제외... 그래픽카드 제외)

125. 클라우드 에서는 instance type
을 바꾸는 것도 쉽습니다.

126. 그러면 Scale Up만
적용하면 될까요?

127. 하드웨어 성능에는 한계가
있습니다.

128. 그 한계보다 많은 요청이
들어오면...

129. 위에서 API 서버를 2대 이상
두는 것도 Scale Out 입니다.

130. 데이터의 Scale out

131. 다음 데이터를 두 개로 나누면 어떻게 해야 할까요?
1
2
3
4
5

132. 두 개로 나누기
1
2
3
4
5

133. 아무렇게나?
1 2
3
4
5

134. 이러면 각 숫자가 어디에
있는지 알 수가 없습니다.

135. 어디에 있는지를 모르면
전체를 찾아야 합니다.

136. 데이터를 나누는 기준
규칙이 필요합니다.

137. 한 군데로 몰기
1
2
3
4
5

138. 순서대로
1
2
3
4
5

139. 2로 나눠서 나머지가 1이면 앞에, 0이면 뒤에
1 2
3 4
5

140. 여기서 서버 수가 변하면
어떻게 될까요?

141. 2로 나누는게 아니라 3으로 나눠야 하면?
1 2
3 4
5

142. 2로 나누는게 아니라 3으로 나눠야 하면?
5
1 2 3
4

143. 많은 수의 데이터가
이동을 해야 합니다.

144. 확장에 데이터가 적게
움직이는 방법을
연구해야 합니다.

145. 정리
● 대규모 서비스는 수백만, 수천만명이 사용하는 서비스입니다.
● 대규모 데이터를 다루는 것은 상당히 재미있으면서도, 어려운 일입니다.
● 클라우드(AWS, Azure, GCP) 공부하시면 좋습니다.

146. Thank you!!!