Microservices Architecture의 소개(모놀리식 아키텍처vs 마이크로서비스 아키텍처)
- 흑구의 공부내용 공유
- 2019. 12. 11. 19:02
모놀리식 아키텍처의 단점에 대해 공부하고 어떻게 이를 마이크로서비스로 해결한 것인가를 알아보자.
서론
최근에 마이크로서비스에 대한 많은 의견이 있습니다. 대부분의 IT회사에서는 마이크로 서비스에 대한 많은 이야기를 나누고 있습니다. 마이크로서비스는 기존 아키텍처인 모놀리식 아키텍처와 비교하면 쉽게 이해할 수 있을 것입니다.
대부분의 엔터프라이즈급 응용프로그램은 계층구조가 매우 유사한 구조를 띄게 됩니다.
1. Presentation : 유저 인터페이스
2. Business logic : 응용프로그램의 내부 로직
3. Database Access : SQL이나 NoSQL을 이용한 디비 접근.
4. Application integration : 종종 응용프로그램은 다른 응용프로그램과의 통합과정이 필요합니다. 이는 일반적으로 웹서비스 호출( SOAP, REST) 또는 메시징을 통해 수행할 수 있습니다.
응용프로그램이 명확하고 논리적으로 모듈식이라고해도 대부분의 응용프로그램은 모놀리식으로 패키징되고 배포됩니다. 이에 대한 장점은 다음과 같습니다.
모놀리식 아키텍처의 장점
1. 개발이 쉬이 진행된다.
2. 테스트가 간편하다. 어플리케이션을 실행하고 처음부터 끝까지 테스트하면 된다. 뿐만아니라 Selenium과 같은 프로그램으로 테스트를 자동화 할 수도 있다.
3. 배포가 간단하다. 패키지 프로젝트를 복사하고 서버에 붙여넣으면 된다.
4. 확장성이 쉽다. 로드밸런스를 이용하여 로드 부하를 나눠가지는 방식으로 진행하지만 응용프로그램이 커질수록 확장성 이슈는 점차 드러나게 된다.
* 추가 : 모놀리식 아키텍처는 지난 수십년간 성공적으로 사용되었습니다. 사실, 많은 응용프로그램들이 모놀리식으로 개발하고 배포되었습니다. 현재까지도 엔터프라이즈급 대규모 응용프로그램들이 아직까지 모놀리식 형태로 개발되어지고 있습니다. 그러나 시장이 변하고 기술의 발전에 따라, IT산업에 패러다임은 점점 변화하고 있습니다. 모놀리식 아키텍처 개발에는 분명히 심각한 이슈가 존재하므로 대부분의 기업에서는 이를 고민하여 다루어야 합니다.
모놀리식 아키텍처의 단점
1. Flexibility(유연성)
- 모놀리식 아키텍처는 유연하지 못합니다. 다른 기술을 사용할 수 없습니다. 사용할 기술 스택이 처음에 결정되는 편이고 변경되는 경우가 거의 없습니다. 한번 개발이 완료된다면 새로운 기술스택을 점진적으로 도입하는 것은 물론이고 기술스택 버전을 업그레이드하는 것조차도 어려워집니다.
2. Reliability(신뢰성)
- 신뢰성이 떨어진다. 하나의 기능이 망가지면 프로그램 전체가 망가질 가능성이 농후하다.
3. Development speed(개발속도)
- 모놀로식 개발은 개발속도가 현저히 느리다. 새로운 팀원이 모놀로식 개발코드를 이해하고 수정하기가 어렵다. 그로인해 코드 퀄리티가 떨어지게 된다. 프로젝트 코드가 커지면 커질수록 개발환경도구(IDE)가 overload되고 더욱 느려질 수 밖에 없다. 프로그램을 시작하는 시간도 오래걸리게 된다. 개발자의 생산성에 대한 이러한 영향을 미친다.
4. Building complex applications
- 기술적 측면에서 복잡한 응용프로그램을 빌드하기 어려워진다.
5. Scalability(확장성)
- 모놀리식 응용프로그램은 일단 한번 커져버리면 확장하기가 어렵습니다. 우리는 로드밸런서가 새로운 인스턴스를 분산할 수 있도록 할수 있으나, 모놀리식 아키텍쳐는 부하가 증가하는 것은 처리할 수 없습니다. 각 응용프로그램의 인스턴스들은 모든 데이터에 접근할 수 있습니다. 그로인해 캐싱효율은 떨어지며 메모리 소비와 입출력 트래픽은 증가합니다. 또한 하나의 컴포넌트가 다른 리소스를 필요로 한다면 하나는 CPU를 많이 사용하고 다른 하나는 메모리를 많이 사용하게 됩니다. 모놀리식 아키텍처를 사용하면 각 컴포넌트를 독립적으로 확장하기가 어렵습니다. (***)
6. Continuous deployment(지속가능한 배포)
- 지속가능한 개발은 정말 어렵다. 대규모 단일 응용프로그램은 자주 배포하는데에 방애가 됩니다. 하나의 컴포넌트를 업데이트하기 위해서 전체 어플리케이션을 재배포 해야 합니다.
모놀리식 어플리케이션의 이러한 단점때문에 마이크로 서비스 아키텍처가 오늘날 더욱 인기를 끌게 됩니다.
그렇다면 마이크로 서비스 기반 아키텍처란 무엇인가요?
한마디로 말하면, 마이크로서비스 아키텍처 스타일은 단일 응용프로그램을 소규모 서비스 단위로 개발하는 방법입니다. 각각은 자신만의 프로세스로 운영되고 있고, Restful 웹서비스 혹은 메시징을 통한 가벼운 메커니즘을 통해 통신합니다. 이러한 서비스는 비즈니스 기능을 중심으로 구축되며 자동화 배포 기기를 통해 독립적으로 배포할 수 있습니다. 서비스별 중앙 집중식 관리는 최소한으로 이루어지며 서비스별로 각기다른 프로그래밍 언어로 개발할 수 있고, 각기 다른 데이터 저장기술(DB 중 RDB, NoSQL 등.. 선택 가능하다는 것)을 사용할 수 있습니다. 마이크로서비스는 아주 작고 클라우드를 지원하는 독립적으로 배포 가능한 유닛입니다.
마이크로서비스 아키텍처가 모놀리식 아키텍처의 단점을 해결하는 방법.
1. Flexibility(유연성)
- 마이크로서비스 아키텍처는 유연한 편입니다. 다른 마이크로 서비스를 이용하여 또 다른 마이크로 서비스를 만들어낼 수 있습니다. 마이크로서비스는 작기 때문에 코드량이 보다 적습니다. 또한 기술스택버전을 업그레이드하는데 어렵지 않습니다. 또한, 별다른 어려움없이 새로운 기술을 점진적으로 도입할 수 있습니다.
2. Reliability(신뢰성)
- 마이크로서비스 아키텍처는 신뢰할수 있습니다. 하나의 기능이 다운되어도 전체 응용프로그램이 다운되지는 않습니다. 해당 마이크로서비스에서 문제를 해결하고 즉시 배포할 수 있습니다.
3. Development speed(개발속도)
- 개발속도가 빠릅니다. 마이크로서비스의 코드량이 보다 적기 때문에 새로운 팀원이 소스를 이해하고 수정하는데 어렵지 않는 편입니다. 시작부터 생산성이 좋아질 것 입니다. 코드퀄리티도 처음과 같이 유지될 것이고, 개발환경(IDE)의 속도도 보다 빠를 것입니다. 마이크로서비스는 프로그램을 시작하는 시간도 빠릅니다. 이러한 요소 덕분에 개발자의 생산성이 올라가게 됩니다.
4. Building complex applications
- 마이크로서비스 아키텍처에서는 복잡한 응용프로그램을 구축하기 쉽습니다. 응용프로그램의 일부 기능이 적당히 분석되었다면 독립적으로 배포할 수 있는 독립된 컴포넌트로 분류합니다. 그러고 나서 그런 다음 독립된 컴포넌트 조차도 더 작은 컴포넌트로 쪼갤 수 있고 이를 다시 마이크로 서비스로 배포할 수 있습니다. 마이크로서비스의 경계를 결정하는 것은 매우 어려운 일입니다. 아직까지도 진화하고 있는 과정이지만 일단 마이크로 서비스를 결정하면 기술에 제한이 없으므로 개발하기가 매우 용이해질 것입니다.
5. Scalability(확장성)
- 마이크로서비스 아키텍처의 가장 큰 이점입니다. 각 마이크로서비스는 개별적으로 확장될 수 있습니다. 각각의 마이크로서비스는 크기가 훨씬 작으므로 캐싱이 매우 효과적입니다.
6. Continuous deployment(지속적인 배포)
지속적인 배포가 쉬워집니다. 특정 컴포넌트를 업데이트하기 위해서는 해당 컴포넌트를 재배포해주기만 하면 됩니다. 전체 코드를 배포하던 모놀리식 아키텍처와 이러한 차이가 있습니다.
결론
앞에서 언급했듯이, 마이크로서비스 아키텍처는 모놀리식 아키텍처와 비교한다면 쉽게 이해할 수 있습니다. 그러나 마이크로 서비스 아키텍처 이전에 이미 비슷한 종류의 아키텍처가 있습니다. 바로 SOA(Service-Oriented-Architecture) 입니다. SOA는 20여년정도 사용되어 왔습니다. 만약 SOA를 토대로 개발해왔거나 이미 그 개념에 대해 익숙하다면 마이크로서비스와 SOA의 개념에 혼동을 불러일으킬지도 모릅니다. 사실 두개념은 차이점보다 공통점이 더 많습니다. 그만큼 유사합니다. 다음 글에서는 SOA와 마이크로서비스 아키텍처의 유사점, 차이점에 대해서 포스팅해보도록 하겠습니다.
'흑구의 공부내용 공유' 카테고리의 다른 글
[번역글] 스프링 vs 스프링 부트 차이 비교하기! (1) | 2020.01.09 |
---|---|
[번역글] 더 나은 자바개발자가 되기위한 10가지 팁! (3) | 2020.01.06 |
[번역글] REST API URI를 결정하는 7가지 규칙 (0) | 2019.12.12 |
[Java] 자바 Properties 파일 읽는 방법(한글 깨지는 사람 들어오세요) (2) | 2019.04.13 |
유닉스시간(unixtime)의 개념과 서버,DB,클라이언트에서 얻어오는 방법 (0) | 2019.03.09 |