마이크로서비스 아키텍처 개요

아래의 링크의 원본을 요약한 내용입니다. (★★★★★)

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/

 

 

마이크로서비스 아키텍처

마이크로서비스 아키텍처는 하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처를 말합니다. 애플리케이션을 특화된 기능별로 나누게 되면 자연스럽게 애플리케이션의 추상화(abstraction)가 가능해집니다.

...

REST API의 일반화, 도커(Docker)와 같은 컨테이너 기술, 클라우드 컴퓨팅 환경의 발전 등에 힘입어 마이크로서비스는 좀 더 손쉽게 구현될 수 있게 되었습니다.

마이크로서비스 아키텍처 패턴에 대해서 고민을 시작해 보는 것도 나쁘지 않습니다.

1. 애플리케이션의 배포에 한 시간 이상 소요된다.
2. 단순한 기능 하나를 수정해도 전체 기능에 대한 QA가 필요하다.
3. 단순한 버그 수정이 더 중대한 버그를 생산하는 일이 많아졌다.
4. 현재의 애플리케이션을 기능별로 나눈다고 가정했을 때 수십개의 마이크로서비스가 가능하다.

이전 아키텍처에서는 (모놀리틱 아키텍처 (Monolithic Architecture))

서비스 복잡도가 증가하면서 모놀리틱 아키텍처가 가지는 문제점들은 배포 시간의 증가, 부분적 스케일 아웃의 어려움, 안정성의 감소 등 여러가지가 있습니다. 그 중에서도 굳이 한가지를 꼽자면 애플리케이션을 구성하는 프로그래밍 언어, 또는 프레임워크의 변경이 거의 불가능에 가까울 정도로 어렵다는 점 입니다.

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

마이크로서비스 아키텍처 패턴은 그 이름에서도 유추할 수 있듯이 모놀리틱 아키텍처로 구성된 하나의 큰 서비스를 독립적인 역할을 수행하는 작은 단위의 서비스로 분리하여 설계하는 패턴을 말합니다. 여기에서 말하는 독립적인 역할이란 주로, ‘사용자 관리’, ‘주문 관리’, ‘결제 관리’, ‘알림 관리’와 같이 기능적인 요소를 의미합니다. 각각의 마이크로서비스는 그 크기만 작을 뿐, 자세히 살펴보면 각각이 하나의 모놀리틱 아키텍처와 유사한 구조를 갖습니다. 다만, 하나의 서비스에서 처리해야 하는 기능과 규모가 작기 때문에 이를 마이크로서비스라고 부릅니다.

그림 2 마이크로서비스 아키텍처

 

 

그림 2는 마이크로서비스 아키텍처의 개략적인 모습을 몇 가지 예시로 나타낸 그림이며 이 예시는 총 4개의 마이크로 서비스로 구성되어 있습니다. 사용자 서비스는 REST API를 이용해서 주문 서비스를 활용하며 API Gateway를 통해 정보를 웹브라우저 화면에 표시하거나 모바일 클라이언트에 데이터를 제공합니다. 또한, 사용자에게 알림이 필요한 경우 실제 알림이 어떤 과정을 통해서 처리되는지 신경쓸 필요없이 알림 서비스(Notification service)를 이용하여 원하는 요청을 호출할 수 있습니다. 그림에 표시된 API Gateway는 뒷쪽에서 자세히 설명하도록 하겠습니다.

마이크로서비스 아키텍처를 나타낸 그림에서 주목할 점은 사용자를 위한 데이터베이스와, 주문을 위한 데이터베이스가 따로 표시되어 있다는 점입니다. 이 부분은 실제로 마이크로서비스 아키텍처를 구현할 때 매우 중요한 부분인데, 전통적인 모놀리틱 아키텍처에서 주로 개발을 했던 경험에 비추어 보면 데이터의 트랜잭션 관리나 정규화 등의 관점에서 매우 비효율적으로 보일 수 있습니다. 물론, 하나의 데이터베이스를 각각의 개별 서비스가 공유해서 사용하는 방식도 가능하지만 마이크로서비스 아키텍처가 가지는 근본적인 장점을 최대한 활용하기 위해서는 이렇게 서비스별로 별도의 데이터베이스를 사용하는 것이 필요합니다. 또한, 데이터베이스(DBMS)의 종류 자체도 반드시 한가지 통일할 필요 없이 데이터의 특성과 서비스가 가지는 특수성에 따라 가장 효율적인 데이터베이스를 선택하여 사용하는 것도 가능합니다. 예를 들어, 어떤 서비스에서 사용하는 데이터는 변경이 적고 주로 읽기(read) 작업만 수행되는 반면, 또 다른 서비스의 데이터는 읽기 작업보다 빠른 속도로 쓰여지는(write) 작업이 대부분이라면 각각의 서비스 특성에 맞게 데이터베이스의 종류를 결정하고 설계할 수 있습니다.

 

마이크로서비스 아키텍처의 장점

마이크로서비스 아키텍처는 서비스의 규모가 커지고 복잡도가 증가할 수록 여러가지 장점을 갖습니다. 우선 서비스가 개별적으로 독립적인 단위의 애플리케이션이기 때문에 변경이 용이하고 그 변경이 다른 서비스에 미치는 영향이 적습니다. 또한, 개별 서비스 단위의 배포가 가능하기 때문에 하루에도 필요에 따라 여러 번 배포를 하는 것이 가능합니다. 비용적인 측면에서 보자면 마이크로서비스 아키텍처는 부하가 집중되는 특정 서비스를 위해 전체 애플리케이션을 스케일 아웃할 필요가 없기 때문에 불필요한 자원의 낭비를 줄일 수 있습니다. 특히, 서비스의 특성에 따라서 메모리 사용이 많은 서비스도 있을 수 있고, 계산 과정이 많아서 CPU 사용량이 많은 서비스가 있을 경우 서비스의 특성에 맞게 자원을 할당하여 스케일 아웃할 수 있기 때문에 효율적인 자원사용이 가능하게 됩니다.

이 외에도 마이크로서비스 아키텍처는 다양한 장점을 가지고 있지만, 여기에서 가장 강조하고 싶은 장점 중 하나는 시스템의 아키텍처가 개발 조직과 나아가서 회사의 조직 문화에 큰 영향을 미친다는 점입니다. 웹 서비스를 기반으로 하는 대부분의 회사들은 애자일의 사상을 도입하고 여러가지 방법론들을 채택하여 빠르고 유연한 개발 문화를 만들고자 노력합니다. 하지만 서비스의 규모가 커지고 시스템이 복잡해지면 사소한 변경 하나가 발생시킬 수 있는 문제(side effect)가 많아지고, 이 때문에 조직은 복잡한 시스템에 맞는 복잡한 프로세스를 필연적으로 가지게 됩니다. 마이크로서비스 아키텍처의 가장 큰 장점은 특정 서비스의 변경이 다른 서비스에 영향을 미칠 가능성이 적다는 점과 서비스 단위로 독립적인 배포가 가능하다는 점 입니다. 다시 말해, 인증과 관련된 서비스가 독립적으로 분리되어 있다면 해당 서비스의 개선과 수정 작업이 다른 서비스의 이해 당사자들과 독립적으로 진행될 수 있기 때문에 의사결정이 빠르고, 독립적인 테스트의 구축이 용이하기 때문에 품질이 증가하게 됩니다 (다른 서비스와 연계된 통합 테스트는 서비스가 분리될 수록 오히려 복잡도가 높아지게 됩니다). 이것은 다시 말해, 조직의 의사결정 프로세스와 테스트 및 배포 프로세스 등 많은 부분에 영향을 미친다는 것을 의미합니다.

마이크로서비스 아키텍처의 단점

반면, 마이크로서비스 아키텍처가 모든 면에서 장점만을 갖는 것은 아닙니다. 마이크로서비스 아키텍처가 가지는 대표적인 단점으로는 모놀리틱 아키텍처에 비해 서비스 간의 통신에 대한 처리가 추가적으로 필요하다는 점입니다. 이것은 단순히 개발해야 하는 코드의 양이 늘어난다는 점 뿐만 아니라, 사용자의 요청을 처리하기 위한 응답속도의 증가에도 영향을 미칩니다. 뿐만 아니라, 분산된 데이터베이스는 트랜잭션 관리가 용이하지 않기 때문에 데이터의 정합성을 맞추기 위한 노력이 추가적으로 필요합니다. 대부분의 모놀리틱 아키텍처에서는 하나의 데이터베이스를 사용하기 때문에 트랜잭션에 대한 처리가 크게 어렵지 않습니다. 하지만 서로다른 데이터베이스, 심지어 종류도 서로 다른 데이터베이스 내의 데이터의 정합성을 유지하기 위한 트랜잭션 처리는 대부분의 데이터베이스가 자체적으로 지원하지 않기 때문에 애플리케이션의 개발과정에서 항상 고려해야 한다는 어려움이 있습니다.

앞서 설명한 바와 같이 마이크로서비스 아키텍처는 서비스의 특성에 따라 효율적인 자원 사용이 가능하도록 스케일 아웃이 가능한 장점이 있는데 반해, 수 많은 서비스를 배포하고 관리하는 데에 어려움이 있습니다. 넷플릭스(Netflix)와 같은 대규모 서비스들은 보통 수백개 이상의 마이크로서비스로 이루어지는데 이렇게 많은 서비스들은 각각 서로 분산되어 있기 때문에 관리 포인트가 증가하고 통합해서 모니터링하고 운영하는 것이 모놀리틱 아키텍처에 비해 매우 어려워집니다. 이것은 필연적으로 매우 정교한 배포 자동화를 필요로 하며 많은 PaaS(Platform as a Service) 서비스, 또는 도커(Docker)와 같은 컨테이너 기술을 활용하여 도움을 받을 수 있습니다.