skip to Main Content
[IT트렌드] 마이크로 서비스 (Micro Service)

[IT트렌드] 마이크로 서비스 (Micro Service)

마이크로 서비스를 설명하기에 앞서 원활한 이해를 위하여 상반되는 개념인 모놀리틱 (Monolithic) 구조를 알아보겠습니다.

 

모놀리틱 구조는 하나의 서버에 서비스할 모든 애플리케이션 소스 (UI, 비즈니스 로직, DB처리 로직 등)가 존재하는 구조를 의미합니다.
이런 모놀리틱 구조는 처음에는 작은 서비스로 시작하거나 모듈화가 잘 되어 있어 큰 문제가 없을 수 있으나 오늘날과 같이 점점 많은 기능들이 요구되고 복잡한 비즈니스 서비스들이 추가되면서 모놀리틱 구조는 다양한 문제가 발생하고 있습니다.

 

모놀리틱 구조에서의 장점들은 다음과 같습니다.

  • 아키텍처 구조가 심플하여 관리자 용이하다
  • 트랜잭션 관리가 쉽다.
  • 애플리케이션 설계 및 테스트가 용이하다.  (하지만 애플리케이션의 복잡도가 증가하면 테스트의 복잡도가 크게 증가할 수 있다.)

 

하지만 위와 같은 장점이 존재하는 반면 단점들도 존재합나다.

  • 여러 서비스들이 하나의 구조에 존재하여 특정 서비스 장애 시 전체적인 장애가 발생 할 수 있다. (예: Memory segmentation fault, Out Of Memory Error 등)
  • 여러 모듈간 의존성이 복잡해져 모듈 수정 시 다른  모든 서비스에 영향을 주어 장애를 발생 시킬 수 있다.
  • 애플리케이션 구조에 따라 배포/재배포 시 시간이 오래 걸릴 수 있고, 시스템 확장 및 Auto Scaling등에 제약이 발생 할 수 있다. (예: 단일 데이터베이스 사용에 따른 확장 제한)

 

그럼 다시 본론으로 돌아가 마이크로 서비스에 대해 알아보겠습니다.

마이크로 서비스는 말 그대로 서비스를 작게 나눈 것이며, 독립적으로 실행 및 배치가 가능한 작은 단위로 나누어 서비스를 제공하는 것을 뜻합니다.
서비스와 서비스의 통신은 보통 경량 메커니즘 (HTTP, REST API, Message Queue)을 사용하고, 각 서비스들의 연계를 좀 더 유연하게 할 수 있도록 API Gateway 서버 기능을 적용하기도 합니다.

 

마이크로 서비스는 다음과 같은 장점을 가지고 있습니다.

  • 모놀리틱 구조의 복장성의 해소할 수 있다.
  • 각각의 서비스별로 배포/재배포가 자유롭다.
  •  서비스 별로 확장이 용이하다.

 

반면 마이크로 서비스의 단점은 아래와 같습니다.

  • 서비스를 분해하기 위한 설계를 잘 고려해야 한다.
  • 각 서비스 별로 분산된 시스템으로 구성되어 많은 WEB/WAS 시스템이 증가하고 모니터링 대상도 증가하게 된다.
  • 서비스가 분산되어 있고, 서비스 별로 자체 데이터 저장소를 가지고 있어 데이터베이스 트랜잭션 관리가 어렵다.
  • 모놀리틱 구조보다 애플리케이션 테스트가 어렵다.

[그림1] 모놀리틱스 구조 vs 마이크로서비스 구조

출처 : https://martinfowler.com/articles/microservices.html

그럼, 위에서 설명한 마이크로 서비스를 위한 WEB/WAS 시스템 구성 시의 필요사항에 대해 알아보겠습니다.

마이크로 서비스는 결국 수많은 서비스들을 REST API등의 통신 방법으로 데이터를 연계하기 때문에

이런 수많은 서비스들을 위한 많은 인프라 (서버/WEB/WAS/네트워크 등) 구성과 각 서비스를 쉽게 연동할 수 있는 기능들이 필수적으로 필요하게 됩니다.

또한 특정 서비스가 부하가 발생하거나 장애가 발생하는 경우 Auto Scale자동 페일 오버에 대한 고려도 필요합니다.

 

그렇다면, 서비스를 배포하기 위한 물리/가상 서버 구성은 어떠할까요?

먼저 노드에 서비스 Instance을 구성하는 방법 대해 알아보겠습니다.

[그림2] 노드에 서비스 process 배포

위 구성은 물리 또는 가상 서버에 여러 개의 서비스 Process를 실행하는 구조입니다.

각 서비스는 각각 다른 Port로 설정을 하거나 내부 가상 IP를 설정하여 IP별로 서비스를 할 수 있습니다.
이렇게 서비스 Process를 증가시키다가 서버 임계치에 도달하면 Node를 추가하는 방식으로 구성됩니다.

 

이 구성의 장점은 하드웨어를 효율적으로 사용할 수 있고 기존 서비스 노드에 추가하는 경우에는 빠르게 서비스를 배포할 수 있습니다.
하지만 이 방식은 특정 서비스가 장애 (예를 들어 CPU 자원을 100% 사용)가 발생하면 전제적인 서비스 장애를 유발할 수 있는 단점이 있습니다.
또한 서비스별로 각기 다른 OS library 버전이 필요하거나 특정 디렉토리를 같이 사용해야 하는 경우에 서비스를 분리해야 하는 경우가 발생할 수 있습니다.

[그림3] VM 이미지를 이용한 서비스 배포

그림3은 각 서비스 별로 미리 VM Image를 생성한 후 필요할 때 마다 서비스를 VM 으로 배포하는 방식입니다.
이 방식은 각 서비스 별로 간섭이 없기 때문에 장애 상황에 좀 더 유연하게 대처할 수 있습니다.
하지만 Process방식보다는 부팅 시간이 길고 VM 구성에 인한 오버헤드가 존재한다는 점이 단점입니다.
그리고 VM 자원을 최대로 사용할 수 없을 수 있는 점도 단점이라고 할 수 있습니다.

[그림4] Container를 활용한 서비스 배포

그림 4는 Process 방식의 이점과 VM 방식의 이점을 모두 가질 수 있는 Container 배포 방식입니다. Container방식은 이전에 소개해 드린
“급부상 하는 Docker Container” 내용에서 언급한 바와 같이 많은 장점을 가지고 있습니다.

하지만 아직까지 Container기술은 VM처럼 기술이 성숙되어 있지 않고, Container들을 배포하기 위한 관리 Tool이 많이 부족하다는 것입니다. 하지만 최근에 Kubernetes, Docker Swarm, Marathon 등의 Container 배포 관리 기능들의 기술력과 기능들이 많아지면서 최근 급부상하는 기술이라고 할 수 있습니다.

 

다음 6월호에서는 Container 배포관리 Tool 들에 대해서 좀 더 심도 있게 안내드리도록 하겠습니다.

마이크로 서비스에 대해 더 알고 싶다면?

아래의 귀여운 캐릭터 ‘아코’를 클릭해 주세요!

Back To Top