마이크로서비스 핵심 개념

마이크로서비스 6가지 핵심 개념

독립적 배포

핵심 개념 중에 한 가지만 골라야 한다면 '독립적 배포' 가 가장 중요하다.
다른 마이크로서비스를 변경/배포하지 않으면서, 마이크로서비스를 변경, 배포, 출시할 수 있어야한다. 이를 위해 마이크로서비스 간에 결합도를 낮춰야 한다. 즉 서비스 간에 명시적이고, 잘 정의되어 있고 안정적인 API 명세가 필요하다.

비즈니스 도메인을 중심으로 모델링

도메인을 기준으로 서비스 경계를 정의한다. 즉, 하나의 마이크로서비스가 특정 기능에 필요한 전체를 구현한다. 이렇게 되면 새 기능을 출시하는게 쉬워진다. 여러 마이크로서비스의 기능을 조합해서 새로운 기능을 구현하는게 쉬워진다.
한 기능이 여러 마이크로서비스에 걸쳐 있으면 기능을 출시하는 비용이 올라간다. 서비스 간에 조율, 순서 관리 등 더 많은 일을 해야한다. 여러 서비스에 걸친 변경은 가능한 덜 할 수 있는 방법을 찾아야 한다.

자신의 상태를 가짐

마이크로서비스 하나에 DB 하나를 가진다면, 마이크로서비스는 서로의 DB를 공유하지 말아야 한다. 다른 마이크로서비스가 갖고 있는 데이터에 접근해야 할 때는 직접 접근이 아닌 API 등을 통해서 접근해야 한다. 그러면 데이터를 공유하지 않기 때문에 자연스럽게 데이터로 어떻게 조작하는지 등의 구현이 감춰지고, 이렇게 되면 결합도가 낮아지게 된다.

크기

마이크로서비스가 많아진다는 것은 복잡도가 증가한다는 것이고, 마이크로서비스의 특징들을 충족하기 위해서 새로운 기술들을 습득해야할 필요가 있다. 즉 마이크로서비스가 많아지면 한정된 인원으로 다루기가 힘들어진다. 그래서 조직 혹은 본인이 얼마나 많은 마이크로서비스를 다룰 수 있는지 고민하자.
우리는 두 가지에 집중해야 한다. 하나는 마이크로서비스의 경계를 정의하는데 집중해야 한다. 마이크로서비스의 경계가 정확하게 정의되지 않으면 마이크로서비스들이 서로 복잡하게 얽히게 될 것이다. 이렇게 되면 마이크로서비스가 주는 이점(독립적인 배포 등)이 사라지게 된다.
그래서 마이크로서비스의 크기보다는 마이크로서비스를 다룰 수 있는 역량과 경계(올바르게 정의하는 것) 에 집중하자.

유연함

마이크로서비스는 비용을 들여 미래에 유연해질 수 있는 옵션을 구매하는 것이다. 기술, 확장가능성, 견고함 등에서 유연함을 구매하는 것이다. 이 말은 아직은 벌어지지 않은 미래를 위해서 너무 많은 옵션을 구매하는 것(너무 많은 마이크로서비스)은 힘들게 하는 원인이 될 수 있다. 그래서 적당하게 사용하기 위해 점진적으로 마이크로서비스로 넘어가는 것을 권장한다. 비용에 대한 부분과 조직내에 역량을 고려하면서 조금씩 넓혀가는 것이 좋다.

아키텍처와 조직을 맞춤

조직 구조는 아키텍처에 영향을 준다. 즉 아키텍처는 조직 구조를 닮는다. 조직은 소프트웨어를 더 빨리 배포하길 원한다. 이렇게 하기 위해서는 조직 간에 발생하는 업무 이관 혹은 조직간에 막혀있는 사일로를 줄여야 한다. 그렇기 위해서는 직능으로 팀을 만드는것이 아니라 여러 직능을 한 조직으로 모아서 이관이나 소통의 문제를 줄일 필요가 있다. 예를 들면 프론트팀, 백엔드팀, DB팀이 있었다면 이것을 제품에 맞게 고객팀, 구매팀 이러한 형태로 만들어야 한다는 것이다.
결국 비즈니스 도메인이 시스템 아키텍처를 주도하는 주요 원동력 이라는 것이다. 하지만 회사의 여러 사정들이 있기에 하나의 제품팀을 만들기는 쉽지 않을 것이다. 하지만 이런 비즈니스 도메인을 중심으로 시스템 아키텍처를 만들어야 더 빠른 배포가 가능하다는 것이다.

참고자료

Building Microservices