1. 마이크로 서비스란?

 

위키백과에서 마이크로 서비스의 정의를 살펴보면, 마이크로 서비스는 애플리케이션을 느슨하게 결합된 서비스들로 구조화하는 서비스 지향 아키텍처의 일종인 소프트웨어 개발 기법이라고 설명하고 있습니다.

다시 말해, 애플리케이션을 상호 독립적인 구성요소들로 분할하여 운영하고, 이러한 각각의 구성요소 또는 프로세스가 바로 마이크로서비스인 것입니다.

소프트웨어 개발에 대한 이러한 접근 방식은 세분화, 경량화되어 있으며 다수의 애플리케이션 간에 유사한 프로세스를 공유하고 통합하는 기능을 중시합니다. 

또한, 각 서비스에는 다른 서비스가 함부로 넘어오지 못하게 각각의 API를 제공하고, 개별 서비스는 다른 서비스에 부정적인 영향을 주지 않으면서 작동합니다.

 

우리가 많이 사용하는 배달의 민족이나, 쿠팡이츠, 요기요 등의 배달 어플을 예로 들어보겠습니다.

먹고싶은 음식을 검색하는 검색창, 주문자 리뷰, 주문 수 데이터에서 추출한 추천 식당 카테고리, 장바구니 및 결제창까지.

마이크로서비스에서는 이 세분화된 부분들이 크고 작은 개별 서비스들입니다.

 

한편, 이와 반대로 모든 요소를 하나의 애플리케이션에 구축하는 전통적인 방식을 모놀리식 접근 방식이라고 합니다. 

아래 글에선 모놀리식 접근 방식과의 차이점 마이크로 서비스 아키텍처의 특장점 등에 대해 알아볼 예정입니다!

 

2. 마이크로 서비스의 등장 배경

 

 마이크로 서비스의 등장 배경을 알기 위해선 모놀리티 아키텍처에 대해 먼저 알고 넘어가야 합니다.

모놀리틱 아키텍쳐는 앞서 언급했듯이 모든 요소(비즈니스 로직, DB, UI등 )를 하나의 애플리케이션에 구축하여 배포하는 접근방식입니다. 모든 기능을 각기 분할하여 운영하는 마이크로서비스 아키텍처의 반대 개념이죠. 

전통적인 방식인만큼 모놀리틱 아키텍처는 서비스를 쉽게 구성할 수 있어 적은 비용으로 서비스 출시 가능하다는 특징이 있습니다.

 하지만 서비스에 포함된 기능이 증가함에 따라 코드가 많아지고 복잡해지면서 모놀리틱 아키텍처의 한계점이 드러납니다.

 

[모놀리틱 아키텍쳐의 한계점]

 

-부분장애가 전체 서비스의 장애로 확대될 수 있다.

-소스코드의 수정이 어렵고, 소스코드 테스트를 위한 비용이 크다.

-여러 요소들이 하나의 서비스에 강하게 결합되어 있기 때문에 서비스 수정에 대한 영향도 빠르게 파악하기가 어려워 개발 기간이 지연될 수 있다.

-하나의 프레임워크와 언어에 종속적이이서 새로운 기술을 적용하기가 어렵다.

 

 이러한 한계점들로 모놀리틱 아키텍쳐를 대신한 새로운 아키텍처의 필요성이 대두되었습니다. 

이때, 1) 코드 구조가 독립적이고, 2)기능별로 분산된 구조를 가지고 있으며, 3)기능별로 최적화된 기술 적용이 가능하도록 한 마이크로 서비스가 등장합니다.

  

3. 마이크로 서비스의 특징


마이크로서비스 아키텍쳐는 자율성과 전문성의 특징을 보이면서, 애플레이션의 확장을 용이하게 하고 개발 속도를 앞당겨 혁신을 실현시켜 새로운 기능의 출시 시간을 단축할 수 있게 해줍니다.

또한, 마이크로서비스는 분산형 개발을 통해 팀의 역량과 일상적인 업무 능력을 향상시키며, 동시에 여러 마이크로서비스를 개발하는 것도 가능합니다.

다시 말해, 동일한 애플리케이션 개발에 더 많은 개발자들이 동시 참여할 수 있으므로 개발에 소요되는 시간을 단축할 수 있습니다. 

 

*마이크로서비스의 자율성과 전문성

 

- 자율성

마이크로서비스 아키텍처의 각 구성 요소 서비스는 다른 서비스의 기능에 영향을 주지 않으면서 개발, 배포, 운영하고 확장할 수 있습니다.

서비스가 해당 코드 또는 구현을 다른 서비스와 공유할 필요는 없습니다. 개별 구성 요소 간의 통신은 잘 정의된 API를 통해 이루어집니다.

 

- 전문성

각 서비스는 일련의 기능을 위해 설계되며 특정 문제를 해결하는 데 중점을 둡니다. 개발자가 시간이 지남에 따라 서비스에 더 많은 코드를 제공하여 서비스가 복잡해지면 더 작은 서비스로 분할할 수 있습니다.

 

[마이크로서비스의 특장점 정리]

 

- 개발 주기의 단축

앞서 말한 것처럼 마이크로 서비스는 개별서비스를 독립적인 소규모 팀 조직이 분산형 개발을 하게 됩니다. 

따라서, 독립적이고 신속하게 업무를 수행할 수 있으며 이 덕분에 개발 주기가 단축되고 보다 빠른 배포 및 업데이트가 가능합니다.

 

- 유연한 확장성

마이크로서비스의 경우 각 서비스가 지원하는 애플리케이션 기능의 수요증가에 따라 해당 서비스를 독립적으로 확장할 수 있습니다. 

따라서 팀은 필요한 인프라의 규모를 적절히 조절하고, 기능의 비용을 정확하게 측정하고, 서비스의 수요가 급증하는 경우에도 가용성을 유지할 수 있습니다.

 

- 뛰어난 복원성

모놀리식 아키텍처에서는 단일 구성 요소가 실패하는 경우 전체 서비스 장애를 야기할 수도 있다고 말했었습니다. 

반면 마이크로서비스에서는 독립적인 서비스들이 서로에게 영향을 주지 않도록 하여 이를 방지합니다. 

 

- 쉬운 배포

지속적인 통합과 전달을 통해 새로운 아이디어를 쉽게 시험하고 오류가 발생할 경우 쉽게 되돌아갈 수 있습니다.

이처럼 저렴한 실패 비용 덕분에 여러 번 시험을 진행할 수 있어 쉽게 기능을 추가한다는 특징이 있습니다.

 

- 편리한 액세스

새로 추가되거나 수정사항이 있는 서비스만 빠르게 빌드/테스트/배포가 가능합니다.

 

- 기술적 자유

다중 언어 지원하는 API를 사용하기 때문에 개발자들은 해당 서비스에 적합한 기술, 언어, 버전, DB 등을 자유롭게 선택하여 구현할 수 있습니다.

 

4. 마이크로서비스 개발시 주의할 점


물론 마이크로서비스는 많은 장점을 가지고 있는 아키텍처이지만 상황에 따라 한계점이 드러날 수 있습니다.

 

예를 들면 각 서비스의 테스트는 쉽지만, 여러 서비스가 연관된 상태로 테스트를 진행하고 자동화하는 것은 쉬운 일이 아닙니다. 

또한, 전체 기능을 여러 개별 구성 요소들로 적절하게 분할하는 것 또한 많은 경험이 필요하고, 여러 서비스에 걸친 기능을 배포하기 때문에 사전 조율이 필수적입니다.

 

따라서 마이크로 서비스는 사업 초기에 무조건 도입하게 되면 오히려 개발 속도를 저하시킬 수 있기 때문에, 적절한 시기에 맞춰 도입하는 것이 바람직합니다.

 

 

*참고자료

https://code-masterjung.tistory.com/87

https://www.redhat.com/ko/topics/microservices

https://brunch.co.kr/@yesjun/2(마이크로서비스 사례)

https://www.redhat.com/ko/topics/microservices/what-are-microservices

https://aws.amazon.com/ko/microservices/

https://velog.io/@cclare/%EB%AA%A8%EB%86%80%EB%A6%AC%EC%8B%9D-%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4​