Monoliths - Module, Allocation, Runtime Monolith

by NeO posted Dec 13, 2017
?

단축키

Prev이전 문서

Next다음 문서

ESC닫기

크게 작게 위로 아래로 댓글로 가기 인쇄

이 문서는 다음 링크의 글을 번역했습니다.

http://www.codingthearchitecture.com/2014/11/19/what_is_a_monolith.html


모노리스와 대비하여 마이크로서비스를 이야기하는 강한 트렌드가 있습니다. 그리고 모노리스를 마이크로서비스로 나누는 방법에 대한 더 많은 조언과 두 개념에 대한 엄청난 논란도 있습니다. (Microservices_vs_Monoliths를 참고하십시오.)
Monolith라는 단어는 마치 우리가 기존에 Legacy라고 일컬었던 것과 동일시되어 사용되고 있습니다.

그렇지만 여기서 일컫는 Monolith와 실제 Monolith간에 큰 차이가 있다고 생각합니다.


Monolith는 아키텍처의 스타일이자 소프트웨어 개발 패턴의 일종(이것을 부정적으로 본다면 안티패턴)이라고 볼 수 있습니다. 스타일과 패턴은 주로 다양한 뷰타입에 따라 검토하고 통합적으로 판단해야 할 부분입니다. (뷰타입은 조합하여 조정해야 해는 서로 다른 관점의 셋 또는 카테고리를 의미함 [Clements et al., 2010]) 여기에서 살펴 볼 뷰타입은 다음과 같습니다.


Module – 컴파일 시에 서로 연관 있는 코드의 유닛
Allocation – 환경에서의 소프트웨어 매핑
Runtime – 런타임시 상호작용하는 소프트웨어 요소의 정적 구조


모노리스는 위의 기본적인 뷰타입 어느 것으로도 일컬어질 수 있습니다.


Module Monolith


Module monolith형태를 취한다는 것은 모든 코드가 단일 코드베이스, 즉 함께 컴파일되어 하나의 아티팩트가 생성되는 것을 말합니다. 코드 자체는 매우 잘 설계되어 있을 수 있지만 컴파일을 위한 모듈화되어 있지 않음을 의미합니다. 여기서 코드가 잘 설계되어 있다는 것은 뒤죽박죽 엉켜있는 진흙덩어리 같은 상태가 아닌 소스레벨에서 클래스와 패키지의 응집도와 결합도가 잘 고려된 상태를 말합니다. 반대로 모노리식 모듈이 아닌 경우, 코드를 여러 개의 모듈이나 라이브러리로 분리하여 개별 컴파일 가능하고 레파지토리에 저장하여 필요시에만 참조되는 형태로 디자인합니다. 여기에는 각각의 장단점이 있기 마련이고, 그리고 코드가 사용되는 유즈케이스의 일부에 불과합니다. 단지 개발단계에서의 사용 예라고 할 수 있겠습니다.


module.png


Allocation Monolith


Allocation monolith는 모든 코드가 배포되고 확산됩니다. 다르게 표현하면, 컴파일된 코드는 배포할 모든 노드에 릴리즈 가능 상태인 단일 버전이라고 볼 수 있습니다. 언제든 특정 시각에 동작하는 컴포넌트는 모두 같은 버전의 소프트웨어라고 말할 수도 있겠습니다. 그리고 이것은 앞서 설명한 모듈이 모노리스인 형태와는 완전히 별개의 이야기입니다. 이 경우에는 전체 코드를 한번에 컴파일할 수도 있고 혹은 여러 개의 소스와 버전에 따른 배포 아티팩트 셋을 만들 수도 있습니다. 컴파일 형태가 어떻게 되든 시스템은 한꺼번에 배포됩니다. 주로 전체 시스템을 멈추고 롤아웃 후 리스타트하는 형태입니다.
모노리식 모듈이 아닌 경우, 서로 다른 시점에 개별 노드에 서로 다른 버전을 배포할 수 있습니다. 이것 또한 서로 다른 버전의 모듈 모노리스가 각각 배포될 수 있다는 점에서 모듈 구조의 모노리스와는 완전히 별개의 이야기라고 할 수 있습니다.


allocation.png
Runtime Monolith


Runtime Monolith는 시스템을 단일 어플리케이션이나 프로세스로 수행하는 형태입니다. 여기서 시스템 자체는 여러 개이고 외부 디펜던시도 여러 개일 수 있습니다. 전통적으로 많은 시스템이 이렇게 구성되어 있기도 합니다. 특히 Payroll, Accounts Payable, CMS와 같은 기간업무시스템이 그러합니다.

런타임이 모노리스인지 여부는 시스템 코드가 모노리스인지 여부와는 관계가 없습니다. Runtime Monolith는 주로 배포할 노드나 컴포넌트가 하나인 Allocation Monolith를 의미하기도 합니다. 그렇지만 특정 유저나 지역, 기간 동안 다른 버전의 소프트웨어가 전개되는 경우는 여기에 해당하지 않습니다.
 

runtime.png



Conclusion


Microservices vs Monoliths 논쟁에서는 신중하게 접근해야 합니다. 직접적으로 비교할 수 있는 것은 Runtime 뷰타입인 경우의 특성으로만 가능할 것입니다. 그리고 Module이나 Allocation Monolith를 멀리하면 마법처럼 마이크로서비스 아키텍처를 이루게 될 것이라고 단순히 가정해서는 안될 것입니다. (물론 도움은 될 것입니다.) 마이크로 서비스 아키텍처로 전환하려는 경우 앞서 살펴 본 모든 뷰타입을 고려하여 여러분의 영역을 비교해 보아야합니다. 코드뿐만 아니라 빌드와 배포를 모노리식으로 하여 다른 노드에 시스템 서브셋을 노출하지 않도록 해야겠습니다.

 


Who's NeO

ALM, SW 모델링, SW 정적분석, Devops 특히 CI/CD, APM을 통한 Shiftleft에 관심이 많습니다. 

차세대 APM Cisco AppDynamics와 모바일 앱 모니터링 VMware Apteligent를 소개합니다.

http://www.solulink.co.kr