마이크로서비스 아키텍처

Published: April 06, 2019 by 아형

Categories:
Server-side 1

마이크로서비스 아키텍처

0. 마이크로 서비스 아키텍처란?

하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처를 말한다.

1. 모놀리식 아키텍처

마이크로 서비스 아키텍처와 반대되는 개념인 모놀리식 아키텍처에 대해 먼저 살펴볼 필요가 있다.

새로운 택시 어플리케이션을 만든다고 생각해보자. 필요한 요구사항을 뽑아 낸후 다음과 같은 육각형 아키텍처를 이용하여 다이어그램으로 표현하였다. 이렇게 만들어진 어플리케이션은 하나의 결과로 패키징이 되어 배포된다. 따라서 하나의 리퀘스트는 하나의 프로세스에서 처리되어진다. 이런 형태를 모놀리스(Monolith) 또는 모놀리식(Monolithic) 어플리케이션이라고 한다. 모든 것이 하나의 프로젝트에 들어가 있는 형태이다.

장점

개발 환경과 개발 방법이 통일 되어 있다.
배포 간단
End-to-End 테스트가 쉽다.
같은 애플리케이션을 여러개 두고 로드 밸런서를 앞에 두는 방법으로 쉽게 확장할 수 있다.

단점

서비스가 지속적으로 성장하고 규모가 커질 때 한계에 부딪히게 된다. 소수의 개발자가 몇 가지 핵심 기능을 개발할 때에는 이와 같이 모놀리틱 아키텍처가 최적의 효율성을 보장하지만 개발자의 규모가 커지게 되면 아주 간단한 기능을 추가하기 위해서 많은 줄을 코드를 수정하고, 코드의 변화가 영향을 미치는 범위가 증가하기 때문에 간단한 변화 하나에 대해서도 통합 테스트가 필요하게 된다.

코드 양이 늘어나고 복잡해지면서 대부분의 개발자가 전체를 이해하지 못한다.
애플리케이션 기동 시간도 늘어나고, 빌드 시간도 오래 걸린다. 이런 상태에서 지속적인 통합과 지속적인 배포는 불가능에 가깝다.
여러 모듈이 함께 존재하기 때문에 각 모듈별 특성에 맞는 하드웨어 확장을 하기 어렵다.
전체 프로세스가 하나의 프로세스에서 돌기 때문에 안정성에도 문제가 있다. 해당 프로세스에서 메모리 누수가 일어나거나 프로세스가 죽는 경우, 모든 프로세스에서 영향을 받는다.
새로운 기술, 언어, 프레임워크를 적용하기 어렵다. 부분적으로 들어내는 것이 아니기 때문이다.

2. 마이크로서비스 아키텍처란?

이름에서도 알수 있듯이 하나이 큰 애플리케이션을 서비스 단위로 작게 나누고, 서비스들끼리 서로 통신하는 형태의 아키텍처 패턴이다.

각각의 기능들은 작은 애플리케이션으로 만들어, 새로운 기능을 추가하거나 새로운 기술을 적용할 수 있다. 또한 부분적으로 장애가 발생하더라도 복구하는 동안 해당 서비스와 연관 없는 다른 서비스는 정상 동작한다.

각각의 서비스는 API를 제공하고 이를 통하여 서로 호출한다. 각 서비스는 비동기로 동작하고 메세지 기반으로 통신한다. 사용자의 모바일 기기에서 REST API로 서비스를 호출 시 직접 서비스로 가는 거시 아닌 중간에 API 게이트웨이를 거치게 된다. API 게이트웨이는 부하를 분산시키는 로드 밸런싱, 캐싱, API 미러링, 모니터링등 다양한 기능을 수행한다.

Microservice VS SOA

표면적으로 마이크로 서비스 아키텍처는 SOA 와 유사하게 보인다. SOA 또한 어플리케이션을 서비스로 나눈다는 점에서 비슷하다. 하지만 나누어진 서비스를 어떻게 연결하느냐에 차이가 있다.

SOA는 애플리케이션을 나눈 후 ESB(Enterprise Service Bus)라는 미들웨어에서 연결하고 조립하여 만든 아키텍처이다.

마이크로서비스는 중앙집중적인 ESB 대신 Rest API 또는 경량화된 메시징을 이용하여 각 서비스를 중심으로 처리한다.

마이크로 서비스 장단점

장점
- 서비스 별로 집중하여 독립적으로 개발할 수 있다.
- 소스를 이해하고 수정 및 유지보수가 쉬워진다.
- 외부에는 API만 노출되기 때문에 내부적으로 어떻게 구성해도 상관없으며(추상화) 각 서비스별 특성에 맞게 기술 스택을 결정하고, 새로운 기술을 적용할 수 있다.
- 서비스별 독립적인 배포 및 확장이 가능하다.
- 서비스별로 특성에 맞는 리소스를 선택해 하드웨어를 구성할 수 있다.
단점
- 서비스 간 통신 방법이 필요하다.
- 서비스를 나눠 서비스간 호출이 모놀리식 방법보다 복잡하다.
- 서비스를 나눠 데이터 중복이 발생할 수 있고, 정합성을 보장하기 어렵다.
- 테스트가 어렵다.
- 서비스를 나눠서 특정 서비스가 실패하더라도 나머지 서비스는 유지되기 때문에 서비스가 실패했을 때를 고려해야 한다.

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://futurecreator.github.io/2018/09/14/what-is-microservices-architecture/

https://www.nginx.com/blog/introduction-to-microservices/