Massive service basic

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

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

3. 배틀그라운드

4. Facebook

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

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

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

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

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

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

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

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

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

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

15. 이럴 때는 어떻게?

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

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

18. 잘 될까요?

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

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

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

22. 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

23. 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

24. 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

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

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

27. 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

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

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

30. 잘 될까요?

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

32. 가설 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 모두 정상이야!!!

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

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

35. DNS

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

37. 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

38. 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

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

40. 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

41. 잘 될까요?

42. 친구 목록을 여러번 호출한다고 합시다. 그 때마다 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

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

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

45. 이미 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 으로 접속

46. 그런데 장애가 나면?

47. 장애가 나도 응답은 여전히 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

48. IP 주소가 바뀌면?

49. 이미 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

50. Load Balancer

51. 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

53. 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

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

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.10 Active REQ #1 REQ #2 REQ #3 LB 1.1.1.11 StandBy 1.1.1.2

57. 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

58. 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

59. 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

60. 잘 될까요?

61. Data

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

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

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

65. Data Replication 데이터 복제

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

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

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

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

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

71. 최소한의 모습 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

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

73. 대규모 서비스

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

75. Facebook 2.27 billion MAU

77. Netflix

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

80. Facebook

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

82. 제 폰에서는 대략 4MB

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

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

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

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

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

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

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

90. 3개의 복제본

91. 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 초

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

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

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

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

96. Object Storage

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

98. AWS S3 AZURE Blob GCP Google Stroage

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

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

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

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

103. 예를 들면

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

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

106. 이런 식으로... 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

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

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

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

110. Limitation 한계

111. DBMS 의 한계

112. DBMS 의 한계 TPS

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

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

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

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

117. Response Time

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

119. Scale Up Vs Scale Out

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

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

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

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

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

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

126. 데이터의 Scale out

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

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

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

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

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

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

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

134. 순서대로 1 2 3 4 5

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

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

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

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

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

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

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

142. Thank you!!!

Massive service basic

You are reading a preview.

Check these out next

Massive service basic

More Related Content

Slideshows for you (20)

Similar to Massive service basic (20)

More from DaeMyung Kang (20)

Recently uploaded (17)