Micro Service Archtecture 이해하기 2. 모놀리스 아키텍처의 이해

마이크로서비스 아키텍처의 개념

마이크로서비스, 즉 아주 작은 단위로 동작하는 서비스가 구동되도록 시스템 및 소프트웨어의 구성과 구성 요소 간의 관계를 정의한 서비스가 구동되도록 시스템 및 소프트웨어의 구성과 구성 요소 간의 관계를 정의한 아키텍처입니다.

마이크로서비스 아키텍처는 소프트웨어 아키텍처 구성을 위한 하나의 스타일로 이해할 수 있고, 그 특성이 마이크로서비스로 이루어져 있다는 것입니다.

 

모놀리스 아키텍처와의 차이점

모놀리스 아키텍처와 차이점은 하나의 애플리케이션 형태가 아닌 분할된 다수의 서비스라는 점입니다.

애플리케이션 기능뿐만 아니라 데이터까지 분리하여 격리된 독립된 환경으로 구성되는 것이 가장 큰 차이점입니다. 

이미지 출처 : Red Hat Topic - Micro Service 란 ? (https://www.redhat.com/ko/topics/microservices/what-are-microservices)

단일 애플리케이션 형태인 모놀리스 아키텍처로 구성된 시스템에서는 클라이언트 요청에 대한 처리 반응 속도가 아주 중요한 요소입니다.

데이터 조회에 대한 부하나 이를 처리하는 애플리케이션이 문제가 생긴다면 시스템이 동작하지 않는 결과를 초래합니다. 이에 대응하기 위해서 로드 밸런서, 2중화, 3중화, 백업 및 복구 방안이 아주 중요한 아키텍처 결정 사항이고, 환경 구성을 위해서 많은 시스템 리소스(resource)를 투자합니다. 온프레미스 형태의 구축형 프로젝트에서는 시스템이 받을 부하를 사전에 분석-예측하는 하드웨어 스케일업(scale-up) 과정과 애플리케이션의 빠른 대응과 데이터 조회의 성능 개선을 위한 튜닝(tuning) 활동 등이 아키텍트의 주요한 관심사입니다.

 모노리스 아키텍처 패턴은 작은 프로젝트 혹은 아직 코어 컨셉이나 시스템의 세부 사항들이 결정되지 않은 신생 프로젝트들을 다룰 때 제일 유용하다. 모놀리스의 기본 원리는 모든 코드를 한 개의 프로세스, 혹은 여러 개의 컴포넌트더라도 강하게 결합시켜 언제나 한 묶음으로 배포되도록 작성하는 것이다. 

 

예시를 한번 보겠습니다.

medium.com
Granular Application Architecture Patterns : The Monolith (https://medium.com/containers-on-aws/granular-application-architecture-patterns-28a1e114f975)

로드 밸런서 뒤에 몇 개의 머신이 있고, 이 인스턴스들은 모두 동일한 서버 스택을 가지고 있습니다. 각각의 머신은 요청을 처리할 수 있는 기능을 동일하게 가지고 있으며, 로드 밸런서는 어느 머신으로든 자유롭게 요청을 보낼 수 있습니다. 이 예제에서는 서버사이드 처리가 Node.js로 작성되어있으므로, 한 서버 코어당 하나의 워커(worker)를 생성시키는 리더 프로세스가 존재한다. 모든 워커들은 하나의 포트를 공유합니다.

 

- 장점

 1. 이 스택은 배포하는 과정이 간단한 편입니다. 이미지를 만들어 프로비저닝 혹은 업데이트를 수행합니다. 이 이미지를 템플릿으로 삼아 여러 대의 인스턴스를 시동할 수 있습니다. 

 2. 애플리케이션의 모든 기능들이 하나의 프로세스로 제어되므로, 함수 하나로 바로 호출할 수 있습니다. 이는 애플리케이션을 빠르게 해 줄 뿐만 아니라, 네트워크 연결, 결과적 일관성(eventual consistency)등 분산 시스템의 환경에서 마주할 수 있는 여러 가지 문제점들에 대해 걱정할 필요 없이 기능들을 연결할 수 있게 해 줍니다.

 

- 단점

 1. 한 가지의 기능을 수정하면 클러스터를 전체를 아우르는 스택을 모두 재배포해야 합니다. 서비스가 커지게 되면, 한 가지의 기능을 고치기 위해 몇 백, 혹은 몇 천 개의 머신을 업데이트해야 하므로 커다란 페널티가 아닐 수 없게 됩니다.

 2. 애플리케이션의 기능의 개수가 늘어나면, 모든 기능들이 하나의 프로세스에 포함되어 있으므로 스파게티식 의존성이 발생할 수 있습니다. 따라서 새로운 기능을 추가하는 것이 어려운 일이 되는 것입니다. 거대한 모놀리식 코드 베이스를 문제없이 정리하고 유지하기 위해서는 풍부한 경험을 가진 개발자들을 필요로 합니다

 3. 모든 기능들이 하나의 프로세스에서 실행되므로, 하나의 기능에 존재하는 보안 위험은 곧 시스템 전체를 위협할 수도 있습니다. 또한, 하나의 기능에서 일어난 런타임 예외가 시스템 전체에 장애를 일으키고 다른 기능들 마저 사용 불가능하게 만들 수 도 있습니다.

 4. 모든 기능들이 강하게 결합되어있으므로, 하나의 기능이 다른 모두의 기능에 영향을 줄 수 있다. 즉, 하나의 기능이 CPI를 과도하게 사용할 경우, 시스템 전체와 모든 엔드포인트를 지연(latency)시킬 수 있다.

 

꽑꽑이의 모놀리틱 지옥 경험담.

일단 SI에서 일할 때 모놀리스 아키텍처 기반의 단일 애플리케이션을 개발했다. WMS(Warehouse Management System)이라는 물류관리 시스템을 개발했는데, 비즈니스 모델이 굉장히 복잡하고, 코어 컨셉이 확실했지만, 모든 기술 스택이 전통 그 자체였다.

심지어 SSR(Server Side Rendering) 기술인 JSP과 SVN(git 같은 버전 관리 툴)를 사용하고 있었는데, 팀원이 대충 올린 소스나 정성을 쏟았더라도 다른 연결점에서 에러가 발생하는 소스를 받으면 개발팀원 전체가 커피타임을 강제로 가졌다. JSP 같은 뷰와 서버로직이 섞인 소스를 잘못 수정해서 올린 경우도 마찬가지였다. 개인적으로 작은 파트라는 판단, 다른 서비스에 영향도가 없을 것이라는 판단을 세우고 수정 작업 잘못하면 전체 서비스가 먹통이 되었다. 어떤 부분에서 로직이 꼬였는지 찾는 데에만 엄청난 시간이 들었고 전체팀이 커피타임을 갖었다. 하루에 책상 위에 커피잔만 4~8개가 있었다. 모든 팀원들은 '돌아가면 절대로 손대지 말라'가 철칙이었다. 이런 환경에서 작업을 하면서 '차라리 시니어 한 명 전체 서비스를 개발하는 게 효율적이겠다.'라는 생각이 들었다.

토론 내용

• [자바기반의 마이크로서비스 이해와 아키텍처 구축하기 - 박성훈 지음] 저자는 마이크로서비스아키텍처를 아키텍서 스타일로 이해할 수 있다고 표현하고, Natgan Peck의 세분화된 애플리케이션 아키텍처 패턴에서 마이크로서비스와 모놀리스를 아키텍처 패턴으로써 설명하고 있다. 차이점에대해 고민해보자.

 

키워드

- 프로비저닝

- 스파게티식 의존성 vs 스파게티 소스 (냠냠)

참고 자료

• [Granular Application Architecture Patterns(세분화된 애플리케이션 아키텍처 패턴)]
• 자바기반의 마이크로서비스 이해와 아키텍처 구축하기 - 박성훈 지음

자바 기반의 마이크로서비스 이해와 아키텍처 구축하기