2015년을 보내면서 - SLiPP 스터디에서 발표한 MSA 소개

1. SLiPP 스터디 - MSA
2015.12.12
강대권

2. Agenda
• 스터디 소개
• e커머스 사이트 MSA 도입사례 소개
• MSA 소개

3. 스터디 소개
스터디 자료
▸ 조대협 - 대용량 아키텍처와 성능 튜닝
▸ 정도현 - MSA를 이용해 구현하는 고가용/고확장 서비스
스터디 멤버 및 기간
▸ 강대권, 정태원, 정윤성, 정하선, 김정희
▸ 2015년 4월 ~ 2015년 9월

6. e커머스 사이트
MSA 도입사례 소개
주의:

7. 사이트

8. 인프라/아키텍쳐

9. 변화는

10. 사실과

11. 다릅니다.

15. e커머스 사이트 운영초반 아키텍쳐
월 거래액 : 2억

16. 모노리딕 - Monolithic
비즈니스 로직, 데이터 액세스 코드를
하나의 애플리케이션으로 결합하는
단일구조 애플리케이션 중 하나
…
which all the business logic and
data access code are combined
into a single application.

18. 인프라 Scale-up
월 거래액 : 60억

20. 월 거래액 : 300억
Scale-up 한계상황 도달!!

24. 인프라 Scale-out 변경

29. 아키텍쳐를 바꾸기 전에..

30. 성장의 발목을 잡는 문제가
어떤것들인지 살펴보면...

31. 하나.
길고 지루한 전체배포
(QA포함)

32. 둘.
변경에 대한 두려움

33. 셋.
경직된 구조

35. Microservice
Architecture

36. 마이크로 서비스 아키텍쳐
2012년 ThoughWorks의 James Lewis가 “Java, The Unix way”라는 제목의 발표로 처음 언급
2014년 3월 James Lewis, Martin Fowler
Microservices라는 타이틀로 MSA에 대한 개념정리

37. 마이크로서비스
• 작고(small)
• 자율적이며(autonomous)
• API로 다른 서비스와 연계하며
(communicate with us via those APIs)
• 한 가지 일을 잘하는데 초점을 맞춘 서비스
(focused on doing one thing well)
…is a software architecture style in which complex
applications are composed of small, independent
processes communicating with each other using
language-agnostic APIs. These services are small,
highly decoupled and focus on doing a small task,
facilitating a modular approach to system-
building.
wikipedia - Microservices

38. 마이크로 서비스 아키텍쳐
• 서비스 제공 기업 주도
• 이미 검증된 사례 모음
• 오픈소스 기반
• Agile 개념 결합
• Cloud 환경 활용

39. MSA는 왜 생겨난걸까?

40. 누구나

41. 아는

42. 이야기.

43. 소프트웨어가

44. 복잡해지기

45. 시작했다
사용자 눈높이 증가
사용자, 트래픽 증가
다양한 사용자 계층
복잡한 요구사항
속도와 유연함
사용자 중심
많은 프로그래머 필요
유지보수가 용이한 SW
높은 고가용성
변화 서비스 결과
MSA는

46. 왜

47. 생겨난걸까?

48. -

49. 1

50. 사용자 눈높이 증가
사용자, 트래픽 증가
다양한 사용자 계층
복잡한 요구사항
속도와 유연함
사용자 중심
많은 프로그래머 필요
유지보수가 용이한 SW
높은 고가용성
변화 서비스 결과
누구나

51. 아는

52. 이야기.

53. 소프트웨어가

54. 복잡해지기

55. 시작했다
MSA는

56. 왜

57. 생겨난걸까?

58. -

59. 1

60. 도메인별

61. 개발자

62. 분포도
프로젝트

63. 관점에서
몇명 안되는 단일 서비스
숫자는 많지만, 연관관계가 적은 서비스
ex

64. :

65. 중소기업-스타트업

66. 등의

67. 소규모

68. 프로젝트
ex

69. :

70. ㅇㅇ채팅,

71. ㅇㅇ비즈,

72. ㅇㅇ게임

73. 등

74. 분리가능한

75. 프로젝트

76.
…
숫자도 많고, 연관관계가 높은 서비스
ex

77. :

78. Netflix,

79. 트위터,

80. 그루폰,

81. 쿠팡

82. 등

83. 단일

84. 서비스

85. 개발
…

86. 도메인별

87. 개발자

88. 분포도
프로그래머

89. 관점에서
…
커뮤니케이션 복잡도 빌드시간 개발영역의 의존도
낮음 빠름
높지만
수용가능
중간 중간 팀간 의존도는 낮음
매우 높음느림매우 높음
…

90. '소프트웨어의 구조는 그 소프트웨어를 개발하는
팀의 구조와 유사해진다는 법칙’
ORGANIZATIONS WHICH DESIGN SYSTEMS ... ARE CONSTRAINED TO PRODUCE DESIGNS
WHICH ARE COPIES OF THE COMMUNICATION STRUCTURES OF THESE ORGANIZATIONS
Conway, Melvin E. (April 1968)
컨웨이 법칙 (CONWAY LAW)

91. 분할정복
(Divide and conquer)

92. 애자일

93. (Agile)
cross-functional

94. 변화를

95. 예측할

96. 수

97. 없다
사용자 눈높이 증가
사용자, 트래픽 증가
다양한 사용자 계층
복잡한 요구사항
사용자 중심
속도와 유연함
많은 프로그래머 필요
유지보수가 용이한 SW
높은 고가용성
변화 서비스 결과
MSA는

98. 왜

99. 생겨난걸까?

100. -

101. 2

102. 애자일

103. (Agile)
나선형

104. 개발

105. 방법모델

106. 독립적인 팀이 각 서비스
의 개발과 운영을 담당

107. 독립적이고 단순한 서비
스로 전체 서비스를 구성

109. Monolitic MSA

110. 모노리딕 vs MSA

111. 비지니스별 최적화 기술 적용

114. Microservice Architecture 특징
• Componentization via Services / 서비스에 의한 컴포넌트화
• Organized around Business Capabilities / 비즈니스 영역에 따른 조직화
• Products not Projects / 프로젝트가 아닌 프로덕트
• Smart endpoints and dumb pipes / 단순한 어플리케이션간 연동과 파이프처리 – 유닉
스의 철학
• Decentralized Governance / 개발의 분권화
• Decentralized Data Management / 데이터 관리의 분권화 – Polyglot Persistence
• Infrastructure Automation / 환경구축의 자동화 - DevOps
• Design for failure / 장해를 전제로한 설계
• Evolutionary Design / 변화에 대응하는 설계

115. Microservice Architecture 단점
• Complexity
• Multiple Database Transaction Management
• Complicated Test
• Require Automation for Deploy/Operation
• Hard to develop features span multiple services

116. 정리
• MSA는 만능은 아니다
• 패러다임 변화가 큰 만큼 조직 문화가 뒷받침되어야 가능
• Microservice 단위의 재사용과 자유로운 리팩토링이 가능
• 코드의 양을 줄여서 누구나 쉽게 파악하는것이 가능
• 서비스 간 연계 시 사전협의 필요

118. 감사합니다.