[MSA] 마이크로서비스 아키텍처, 모노리틱 아키텍처 이해하기

소프트웨어 아키텍처 중에서 크게 두가지 분류가 있습니다.

- 모노리틱 아키텍처(Monolithic Architecture)

하나의 어플리케이션 안에 모든 소스가 들어있는 구조입니다.(뷰, 컨트롤러, db접근, 핵심로직 등)
어플리케이션을 실행파일로 말아서 내보내면, 독립적으로 바로 실행 가능한 어플리케이션이 됩니다.
다른 어플리케이션과 연동 없이 단독적으로 수행도 가능합니다.

특징 및 장점

• 간편한 개발 : 전체 애플리케이션을 하나로 처리하기 때문에, 개발툴 등에서 하나의 프로젝트로 개발하면 됩니다.
• 간편한 배포 : 테스트 및 배포도 단일 어플리케이션 하나로 수행합니다. 상대적으로 단순합니다.
• 운영 측면에서 다운 되더라도 큰 영향이 없거나 다른 서비스에 영향이 가도 문제가 덜한 프로그램 이라면 유리할 수 있습니다.

단점

• 긴 빌드 및 배포 시간, 서버 기동 시간 : 규모가 커질 수록 애플리케이션 용량도 커지며, 이로 인해 배포 시간이 길어질 수 있습니다.(API만 몇백개 띄우는 거라면 이부분도 시간이 걸립니다.)
  서버 재시작 이라도 하게되면 더 길어집니다.
• 개발 협업의 어려움 : 형상관리를 할 때 하나의 repository로 관리될 확률이 높으며, 이로 인해 branch 전략이 복잡해지고 충돌이 자주 발생할 수 있습니다.(충돌 해결에 대한 대비책을 마련 해 두지 않으면 대환장 파티가 펼쳐집니다.)
• 운영시 내결함성의 부족 : 프로젝트를 운영할 때, 배포 실수가 어플리케이션 모든 곳에 영향을 미칩니다.
  또한 규모가 클 수록 문제점을 찾기 어려워 집니다.(로깅 정책 수립, 여러 로그가 한곳에 쌓여 구분의 어려움이 있습니다.)
• 구조 및 특성 이해의 어려움 : 시스템의 구조가 커질수록, 개인이 전체 시스템의 구조와 특성을 이해하는 것이 어려워집니다.
• 잦은 배포가 있는 시스템에서의 불편함 : 특정 기능만 수정 후 배포하려 해도, 전체 재시작이 필요하게 됩니다.
  이로 인해 불필요한 오버헤드가 많아질 수 있습니다.

모노리틱 아키텍처를 그림으로 간단히 표현

적어보면 단점이 더 많긴 하지만, 이를 커버할 만큼의 장점이 존재합니다.
단순하고 쉽다는 점 입니다.
단순하거나 적당한 서비스라면 모노리틱으로 아키텍처를 짜는게 효율적 입니다.

- 마이크로 서비스 아키텍처(Micro Service Architecture)

대용량 웹 서비스가 많아짐에 따라 정의된 아키텍처 입니다.
SOA(Service Oriented Architecture:서비스 지향 아키텍처)에 근간을 두고 있다고 합니다.

서비스란 독립적인 소프트웨어 기능 단위 또는 기능 모음을 가리킵니다. 서비스는 지정된 정보를 검색하거나 작업을 실행하는 등 구체적인 태스크를 완료하도록 설계되어 있습니다. 서비스에는 완전한 개별 비즈니스 기능을 수행하는 데 필요한 코드와 통합 데이터가 들어 있으며, 원격으로 서비스에 액세스할 수 있고 독립적으로 상호작용하거나 업데이트할 수 있습니다.

마이크로 서비스 아키텍처 MSA는 대용량 웹 서비스 개발에 맞는 구조로 사상이 경량화 되고, 대규모 개발팀의 조직 구조에 맞도록 변형된 아키텍처입니다.

더 상세하게 이야기하자면, 대용량 웹 서비스는 만큼 각 서비스마다 요청되는 트래픽과, 처리하는 용량이 큰 편 입니다.
그러니 서비스마다 책임과 관리의 중요성이 늘어가며, 별도로 분리하여 서비스 단위의 어플리케이션으로 관리되고 배포가 필요한 수준까지 오게 되었습니다.
이를 위해 필요한 서비스를 기준으로 데이터에서부터 비지니스 로직까지 독립적으로
상호 컴포넌트간의 의존성 없이 개발하는 컴포넌트 단위로 어플리케이션을 만드는 방식이 MSA입니다.
이 덕분에 특정 서비스가 다운 되더라도 다른 서비스에 영향을 미치지 않게 할 수 있습니다.

특징

서비스 단위로 나눈 어플리케이션 프로젝트는 개별 적으로 배포가 가능합니다.
때문에 MSA기반으로 나눈 서비스를 컴포넌트 라고 부르기도 합니다.
예전에 채용공고에 컴포넌트단위로 만들어 본 적이 있냐고 질문을 받은 적이 있는데, 이 내용 이었습니다.
정리해보면 서비스를 컴포넌트 단위로 나눈 것입니다.
API를 이용하여 다른 컴포넌트의 서비스를 통신을 통해 호출할 수 있고, 다른 컴포넌트에 서비스를 제공할 수도 있습니다.
배포 관점에서도 각 서비스는 독립된 서버(WAS)로 타 컴포넌트와의 의존성 없이 독립적으로 배포됩니다.
서비스 입장에서 여러 컴포넌트를 거치는 서비스는 배포로 영향을 받을 수 도 있는데, 이를 대비위한 전략이 필요합니다.(MSA 가 복잡한 이유 중 하나)

마이크로 서비스 아키텍처 간략 정리

아주 단순한 예시를 보면, 프론트 서버와 백엔드 서버가 분리된 것도 마이크로 서비스 아키텍처 구조를 따른 것이라고 합니다.
프론트 서버에서 정보를 출력하려면, 모노리틱에선 콜 바이 레퍼런스 같이 메서드를 호출해서 사용하는 식이었으나,
나뉘게 되면서 백엔드에서 제공하는 API를 호출해 사용하는 식이 됩니다.
이렇게 분리하면 장점이 뭐가 있을까요?

장점

유연한 배포 모델 : 변경이 있는 서비스 부분만 배포하면 되기 때문에, 전체 배포와 비교하면 빠르며, 새로운 서비스를 확장 하더라도 다른 서비스에 영향을 주지 않게끔 하기 좋습니다.
유연한 확장성 : 부하가 많은 특정 서비스 컴포넌트만 확장하여 부하를 분산할 수도 있고, 특정 컴포넌트 사양만 늘려 처리 효율을 늘릴 수 있습니다.
고가용성 증가 : 장애 발생 시 해당 서비스만 재 배포 하거나 스케일링을 적용하여, 다시 서비스를 띄우는데 더 효율적이고 빠르게 띄울 수 있습니다. 

단점

성능 문제 : 서로 다른 컴포넌트간 서비스 호출은 API 통신을 이용하기 때문에 marsharing 오버헤드가 발생하고, 호출을 위한 네트워크 전송 시간이 추가로 소요됩니다. (마샬링, 직렬화를 의미하며 API통신을 위해 객체에서 특정 타입의 데이터로 변환하는 것을 말합니다.)
메모리 문제 : 각 서비스를 독립된 서버에 분할 배치하기 때문에, 중복되는 모듈에 대해서 그만큼 메모리 사용량이 늘어난다.(공통 모듈의 사용은 어쩔 수 없습니다.)
테스팅의 어려움 : 서비스들이 각각 분리가 되어있고, 다른 서비스에 대한 종속성을 가지고 있기 때문에, 비즈니스 서비스를 테스트 할 때 에도 어느 컴포넌트를 거치는지 다 이해하고 호출하는 식의 테스트 케이스를 짜야 하는데, 이는 복잡도가 증가하기 쉬운 요소입니다.
운영 관점의 문제 : 서비스 별로 다른 기술을 사용할 수 있으므로 운영을 해야할 대상 시스템의 수가 늘어나고, 그에 따른 기술의 수도 늘어나므로 요구되는 기술 스택이 늘어날 수 있습니다.
비용의 문제 : 힘들고 복잡하게 마이크로 서비스 아키텍처로 개발을 해 둔 만큼 유지해야 할 서버 수와 트래픽 자원, 데이터 저장 비용이 증가합니다.

닭 잡는데 소잡는 칼 쓸 필요 있을 까요??

최근 마이크로 서비스 아키텍처 기반 기술을 많이 도입하려는 추세라 생각합니다.
그만큼 서비스가 처리해야 할 데이터가 커지고 다양해지며, 병합으로 한곳에서 관리되고 제공되는 서비스가 늘어나면서 이를 감당하기 위한 방법으로 MSA를 선택하고 다룰 줄 아는 개발자를 우대하는 것이라 생각합니다.

그러나 비즈니스 적으로도 MSA기반을 따르는게 더 효율적인지, 아니면 모노리틱하게 가는게 효율적인지 판단해야 할 것이라 생각됩니다.
이렇게 정리하니 개인적으로 MSA를 따르는 것은 더 장점이 많기에 많이 사용되고 있는 것으로 생각됩니다.
그러나 개발자나 운영자 입장에선 신경써야 할 부분들이 많아지고, 개선해 나가는 것도 더 깊이 있는 기술이 필요할 것이라 생각됩니다.
한마디로, MSA기반 개발을 하려면 더 공부해야되고 더 복잡한 내용을 감당해야 합니다.
어쩌겠습니까... 내가 힘들어야 남이 편한 것을 ㅠㅠ 
그런 의미에서 다음 글로는

MSA 를 설계하는 전략에 대해 정리해 보려 합니다.

참고한 블로그

https://bcho.tistory.com/948

대용량 웹서비스를 위한 마이크로 서비스 아키텍쳐의 이해