메뉴 건너뛰기

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

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

Atachment
첨부 '3'
?

 


  1. 3. 앱 로드타임을 2초 내로 줄여 좋은 첫인상을 주자

    3. 앱 로드타임을 2초 내로 줄여 좋은 첫인상을 주자 크래시율과 더불어 app load time은 매우 중요한 지표입니다. App load time은 고객유치에 매우 밀접한 메트릭이자 모바일 앱에 접근하는 중요한 시간정보입니다. 연구에 따르면 app load time은 50%의 ...
    Date2018.02.19 ByNeO Reply0 Views553
    Read More
  2. 2. 주요 3 Userflow의 크래시율을 0.25%미만으로 유지하자

    2. 주요 3 Userflow의 크래시율을 0.25%미만으로 유지하자 앞서 Best Practice #1의 방법으로 top 10 크래시를 수정한다면, 0.25% 이하의 크래시율을 유지하는 데에 매우 큰 도움이 될 것입니다. 전체 크래시율을 낮추는 것 외에도 주요 Userflow의 크래시...
    Date2018.02.05 ByNeO Reply0 Views421
    Read More
  3. 1. 매 스프린트에서 Top 10 크래시를 잡자

    1. 매 스프린트에서 Top 10 크래시를 잡자 모바일 앱을 모니터링할 때 가장 중요한 지표 중 하나는 전체 크래시율입니다. 크래시율이란 전체 세션 대비 크래시가 발생한 비율을 의미합니다. 앱의 품질을 평가하는 데에 크래시율은 전체 릴리즈 프로세스에...
    Date2018.01.30 ByNeO Reply0 Views490
    Read More
  4. No Image

    모바일앱 최적화를 위한 7가지 (0)

    본 문서는 다음 문서를 번역한 글입니다. http://www.apteligent.com/white_paper/7-best-practices-optimizing-mobile-app-experience/ 이 문서를 게시하기 전에 모바일앱 모니터링 툴의 종류와 특성에 대한 개요를 작성하고자 하였으나, 많은  mAPM이나 ...
    Date2018.01.29 ByNeO Reply0 Views358
    Read More
  5. Is NoOps the End of DevOps? Think Again (2) 결론

    In conclusion, DevOps is forever DevOps의 완성형이라고 일컬어짐에도 불구하고 NoOps는 DevOps의 종착역은 아닙니다. 사실 NoOps는 DevOps를 통해 달성할 수 있는 혁신의 시작이라고 볼 수 있습니다. DevOps가 이름을 갖기 훨씬 전부터 시작된 NoOps...
    Date2018.01.02 ByNeO Reply0 Views332
    Read More
  6. Is NoOps the End of DevOps? Think Again (1) DevOps가 사라지지 않는 7가지 이유

     7 Reasons DevOps Is Not Dying 이제 DevOps의 시작에 대해 알았으니 본래의 질문으로 돌아가봅시다. NoOps가 DevOps의 종착역일까요? 그렇지 않습니다!  1. DevOps is a journey 어떤 Devopsdays에 참석하더라도 “DevOps is a jo...
    Date2018.01.02 ByNeO Reply0 Views385
    Read More
  7. Is NoOps the End of DevOps? Think Again (0) IT Operation, DevOps, NoOps 의 간략한 역사

    이 문서는 다음 링크의 글을 일부 번역했습니다. https://blog.appdynamics.com/engineering/is-noops-the-end-of-devops-think-again/ 제일 앞 부분의 DevOps와 NoOps 운동에 대한 논란은 관심있으신 분은 직접 링크를 따라가며 읽어보시면 좋을 것 같습...
    Date2018.01.02 ByNeO Reply0 Views456
    Read More
  8. Monoliths - Module, Allocation, Runtime Monolith

    이 문서는 다음 링크의 글을 번역했습니다. http://www.codingthearchitecture.com/2014/11/19/what_is_a_monolith.html 모노리스와 대비하여 마이크로서비스를 이야기하는 강한 트렌드가 있습니다. 그리고 모노리스를 마이크로서비스로 나누는 방법에 대...
    Date2017.12.13 ByNeO Reply0 Views564
    Read More
  9. No Image

    Microservices, Monoliths and Self-Contained Systems (3) Self-contained system과 결론

    Self-Contained System Self contained system은 모노리스와 마이크로서비스 중간쯤에 있는 블록형 아키텍처입니다. 여러 개의 마이크로서비스를 하나의 엔티티로 나타내면서도 모노리스보다는 작은 규모를 가지는 형태입니다. 만일 매우 연관성이 높아 ...
    Date2017.12.13 ByNeO Reply0 Views448
    Read More
  10. No Image

    Microservices, Monoliths and Self-Contained Systems (2) Microservices

    Microservices 상대적으로 마이크로서비스는 많은 장점을 가져다 주는 반면 단점이 적은 편입니다. 마이크로서비스는 커다란 어플리케이션의 일부분이라고 할 수 있으며 독립적인 어플리케이션이라고 할 수 있겠습니다. 예를 들어 웹 상에 스토어를 운영...
    Date2017.12.13 ByNeO Reply0 Views244
    Read More
Board Pagination Prev 1 2 3 Next
/ 3