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

MSA(Micro Service Architecture)

마이크로 서비스는 복잡한 시스템을 여러 개의 서비스로 분할 하여 대규모의 비지니스 서비스를 처리하는 아키텍처 스타일이나 패턴이다.

즉, 비지니스 요건에 대응하여 진화된 아키텍쳐 패턴인 것이다.

(비지니스는 일반적으로 도메인 비지니스에 해당하고 해당 내용에 대한 자세한 설명은 http://swiftymind.tistory.com/87?category=707534 참조)

소프트웨어 기술이 발전해오고 비지니스적 요구가 점점 증가 됨에 따라 마이크로서비스 아키텍처로 발전하게 되는 근원이 되었다.

참조:https://spri.kr/posts/view/21785?code=industry_trend

마이크로 서비스는 자신만의 데이터베이스, 비지니스, 표현 계층을 갖는데 이전의 주를 이루었던 SOA(Service Oriented Architecture)에서 와의 가장 큰 차이점은 경계의 구분이다.

예를 들어, 이전의 구조에선 상품 프로세스, 검색프로세스, 주문 프로세스 등 비지니스 계층이 한 데 묶은 채 서비스를 구축했을 것이다. 하지만 마이크로 서비스 아키텍쳐에서는 독립적으로 각각의 서비스가 분리되어 있기 때문에 , 다른 서비스의 비지니스에 영향을 미치지 않는다. 

이러한 측면에서 DevOps와 Cloud는 마이크로 서비스에서 나타나는 2가지 양상이다.

[*devOps : http://dev2ops.org/2010/02/what-is-devops/]

또한 대부분의 마이크로 서비스는 개발 과정에서 운영에 이르기 까지 전 과정을 최대한 자동화한다.

특징 및 장점

- 독립적인

- 느슨하게 결합된

- 소용비용과 전환시간이 낮다.

- 변환이 빠르다.

- 가볍다. (하나의 서비스는 하나의 기능만을 담당)

- 다양한 언어로 구상 가능하다.

- 실험 가능(서비스의 기능이 작기에, 비용이 monolothic에 비해 비용이 크게 들지 않고 기능간의 문제에서 자유롭다)

- 확장 가능(ex - With Hazelcast)

- 여러 버전으로 공존 가능

단점

- 서비스간의 의존성이 생기면 API를 호출하고 통신을 한다. 즉 , 단일 프로세스에 비해 속도에서 차이가 날 수 있다.

- 큰 규모의 프로젝트에서 서비스간의 디버깅이 어렵고 중앙관리 로그 모니터링 등이  없기에 관리가 어렵다.

- 대부분 모놀로틱 아키텍쳐에서는 하나의 데이터베이스를 사용하기에 데이터 트랜잭션에 대한 처리가 어렵지 않다. 하지만, 마이크로서비스에서는 데이터 뿐만 아니라 DB의 종류까지 달라질 수 있기 때문에 대부분의 개발 과정에서 고려해야 할 점이다.

참고

http://guruble.com/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4microservice-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-%EA%B7%B8%EA%B2%83%EC%9D%B4-%EB%AD%A3%EC%9D%B4-%EC%A4%91%ED%97%8C%EB%94%94/

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