모놀리식 아키텍쳐 VS 마이크로서비스 아키텍쳐

나는 이전 회사 모놀리식 아키텍쳐로 개발되어있는 프로젝트에 투입되어 있었습니다.
새로운 기획안과 수정요청이 생기는데 조금한 변경에도 전체를 다시 빌드하고 배포를 해야하니 부담이되고
한 기능을 수정하였는데 잘못된 부분이 있어 전체가 오류가 생기는 경우도 빈번하였습니다.
이에 따라 다시 모든 기능을 테스트하고 빌드하고 배포를 하게 되니 시간 소요도 많이 들고 부담도 만만치 않았습니다.

이에 대응하는 아키텍쳐로 마이크로 서비스 아키텍쳐가 부상하고 있습니다. 

 

모놀리식 아키텍쳐와 이를 해결할 방안인 마이크로서비르 아키텍쳐에 대해 알아볼까요???

---

모놀리식 아키텍쳐

마이크로 서비스 아키텍쳐의 반대 되는 개념으로 전통의 아키텍쳐를 지칭하는 의미로 생겨난 단어로,
하나의 서비스 또는 애플리케이션이 하나의 거대한 아키텍쳐를 가질 때, 모놀리식(Monolithic) 하다고 합니다.

 

모놀리식 아키텍쳐를 갖는 소프르웨어의 특징은 그 자체로 강건하며 내부 요소간의 의존성이 강하다는 점입니다.
필연적으로 구조적인 결합이 강력하게 유지되는 결과를 초래하며,  또한 각 비즈니스 컴포넌트들이 하나의 강한 결합 구조를 지닙니다. 비즈니스 로직이 서비스에 최적화된 코드를 만들어내는데 좀 더 집중할 수 있지만, 복합적인 예외를 만들 수 있는 위험성을 내포합니다.

간단한 온라인 쇼핑몰 모놀리식 아키텍쳐

 

정보처리기사를 공부하면서 모듈에서의 결합도와 응집도에 대해 공부한 적이 있습니다.
결합도는 모듈 간에 상호 의존하는 정도 또는 연관 관계를 의미하는 것으로 결합도가 약할수록 품질이 높고 강할수록

품질이 낮고, 시스템 구현 및 유지보수 작업이 어렵다고 합니다.

위의 모놀리식 아키텍쳐는 결합도가 높은 편에 속합니다.

 

위의 글을 보면 모놀리식 아키텍쳐를 왜 사용하는가 의문이 듭니다. 장점과 단점을 보면 어느정도 파악이 될 수 있습니다. 

 

장점

• 어떤 기능이든지 개발되어있는 환경이 같아서 복잡하지 않다
• 쉽게 고가용성(서버, 네트워크, 프로그램 등의 정보 시스템이 오랜 기간 동안 지속적으로 정상 운영이 가능한 성질) 서버 환경을 만들 수 있다.
• End-to-End (종단 간 테스트로 사용자의 입장에서 테스트)테스트가 용이하다

단점

• 한 프로젝트의 덩치가 너무 커져서 어플리케이션 구동시간이 늘어나고 빌드, 배포 시간도 길어진다.
• 조그만한 수정사항이 있어도 전체를 다시 빌드하고 배포를 해야한다.
• 많은 양의 코드가 몰려있어 개발자가 모두를 이해 할 수 없고 유지보수도 힘들다.
• 일부분의 오류가 전체에 영향을 미친다.
• 기능별로 알맞는 기술, 언어, 프레임워크를 선택하기가 까다롭다.

 

기능한 추가된 온라인 쇼핑몰 모놀리식 아키텍쳐

 

대규모 프로젝트보단 소규모 프로젝트에 어울리는 아키텍쳐인 것 같습니다.

 

어느정도 이해가 된다면 이제 마이크로 소프트 아키텍쳐를 한번 보겠습니다.

---

마이크로 서비스 아키텍쳐(MSA) 

단일 프로그램을 각 컴포넌트 별로 나누어 작은 서비스의 조합으로 구축하는 방법입니다. 

온라인 쇼핑몰에 MSA적용 예시

각 컴포넌트는 서비스 형태로 구현되고 API를 이용하여 타 서비스와 통신을 합니다. 각 서비스는 독립된 서버로 타 컴포넌트와 의존성이 없기 때문에 독립된 배포를 하게 됩니다. 각 컴포넌트가 독립된 서비스로 개발되어있기 때문에 부분적인 확장이 가능합니다. MSA는 다음과 같은 특징을 가지고 있습니다.

 

<데이터 분리>

 

데이터 저장 시 하나의 DB에 중앙 집중화를 하지 않고 서비스 별 별도의 데이터 베이스를 사용합니다.

DB의 종류를 별도로 가져갈 수도 있고, 같은 DB를 사용하더라도 나누어서 사용하게 됩니다. 데이터가 분산되어있기

때문에 다른 서비스 컴포넌트에 대한 의존성이 없이 서비스를 독립적으로 개발 및 배포/운영 할 수 있지만,

다른 컴포넌트의 데이터를 API통신을 통해 가져와야 하기 때문에 성능상의 문제가 발생 할 수 있고,

트렌젝션으로 묶을 수 없는 문제가 발생하기도 합니다.

 

<API Gateway>

 

MSA의 문제점 중 하나는 각 서비스가 다른 서버에 분리 배포되어있기 때문에 서버 URL이 각기 다를 수 밖에 없습니다.

이 때 API Gateway는 API 서버 앞 단에서 모든 API 서버들의 End-Point를 단일화하여 묶어주는 역할을 합니다.

또한 거미줄처럼 복잡한 서비스간의 API호출 구조도 단순화 시켜줍니다. 그 외에 라우팅, 로드밸런싱, 인증 역할 등등 여러 역할을 수행합니다.

 

장점과 단점을 한번 보고 가면 이해가 빠르겠죠?

 

장점

• 기능별로 마이크로서비스를 개발하고, 작업 할당을 서비스 단위로 하면 개발자가 해당 부분을 온전히 이해할 수 있다.
• 새로 추가되거나 수정사항이 잇는 마이크로서비스만 빠르게 빌드, 배포가 가능하다.
• 해당 기능에 맞는 기술, 언어 등을 선택하여 사용할 수 있다.
• 일부분의 오류가 있을 경우 해당 기능에만 오류가 발생하고 그 부분만 빠르게 고쳐서 정상화가 가능하다.

단점

• 무엇보다 관리가 힘들다. 작은 여러 서비스들이 분산되어 있기 때문에 모니터링이 힘들다
• 서로를 호출하여 전체 서비스가 이루어지므로 무조건 다른 서비스를 호출하는 코드가 추가되는데 이 부분이 개발에서 까다롭다.
• 통신관련 오류가 잦을 수 있다. 마이크로 서비스들 끼리 계속 서로 통신을 하다보니 통신관련 오류가 잦다.
• 테스트가 불편하다. E2E테스트를 위해, 여러 개의 마이크로 서비스를 구동시켜야 한다.

---

정리를 해보자면

 

MSA는 복잡합 웹 시스템에 맞춰 개발된 API기반의 서비스 지향적 아키텍쳐 스타일입니다.

 

MSA가 모놀리식 아키텍쳐보다 장점도 많은 것 같지만, 서비스간의 호출이 하나의 프로세스 내에서 이루어지기 때문에

속도가 빠른 모놀리식 아키텍쳐와는 달리 MSA는 서비스간 호출을 API통신을 이용하기 때문에 속도가 느리고,

통신에 사용하기 위해 값을 데이터 모델로 변환시켜주는 오버헤드가 발생하기도 합니다.

 

MSA가 유행을 하고 있지만 꼭 정답은 아니고, 업무나 비즈니스 특징에 따라 적절한 아키텍처가 선택되어야 합니다.
근래의 아키텍쳐 모델은 시스템에 대한 설계뿐만 아니라 팀의 구조나 프로젝트 관리 방법까지 달라지기 때문에 프로젝트에 미치는 영향이 매우 크며, 때문에 거시적인 관점에서 고려해야합니다.

 

MSA가 필요하다고 해도 꼭 시작을 MSA로 해야 하는 것은 아닙니다. MSA가 서비스의 재사용성, 유연한 아키텍처구조,
대용량 웹 서비스에 적합한 구조 등 많은 장점을 가지고 있지만 개개인의 높은 숙련도가 필요한 편입니다.
MSA를 구축한 많은 기업들이 시작은 모노리틱 시스템으로 시작하여 팀원들의 숙련도를 높이고 피드백을 통해 시스템을 발전 시키는 과정에서 MSA로 전환한 사례들도 있습니다.

프로젝트의 목적이나 팀의 상황에 맞는 유연한 선택이 필요합니다.

 

---

<참고 문헌>

https://wooaoe.tistory.com/57
https://daaa0555.tistory.com/457
https://lion-king.tistory.com/entry/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C-%EC%84%9C%EB%B9%84%EC%8A%A4-vs-%EB%AA%A8%EB%86%80%EB%A6%AC%EC%8B%9D-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-MicroService-vs-Monolithic-Architecture-%EA%B0%84%EB%8B%A8-%EC%86%8C%EA%B0%9C-%EB%B0%8F-%EC%A3%BC%EA%B4%80%EC%A0%81-%EC%9D%98%EA%B2%AC
http://clipsoft.co.kr/wp/blog/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98msa-%EA%B0%9C%EB%85%90/
https://aws.amazon.com/ko/microservices/

마이크로서비스 아키텍처(MSA) 개념 소개 - CLIPSOFT