[MSA] 마이크로서비스의 핵심 개념

1. 독립적 배포성

독립적 배포성은 다른 마이크로서비스를 배포하지 않고도 마이크로서비스를 변경하고, 배포하고, 사용자에게 릴리스할 수 있다는 개념이다. 이러한 작업을 수행할 수 있다는 사실뿐 아니라 실제로 시스템에서 배포를 관리하는 방법이 더욱 중요하며, 기본 릴리스 방식으로 채택하는 원칙이다.

 

독립적 배포를 위해서는 마이크로서비스를 느슨하게 결합시켜야 한다. 즉, 다른 서비스를 변경하지 않고도 한 서비스를 변경할 수 있어야한다. 이는 서비스 간에 분명하고, 잘 정의되며, 안정적인 계약이 필요하다는 것을 의미한다. (몇몇 구현 방법은 이런 노력을 어렵게 만들기도 한다. 예를 들면, 데이터베이스 공유는 문제가 된다)

 

안정적인 인터페이스를 갖고 느슨하게 결합된 서비스를 위해서 마이크로서비스 경계를 찾는 방법을 가장 먼저 생각해야한다.

마이크로서비스 개념들 중 하나를 선택해야 한다면 바로 이 '독립적 배포성'이어야한다. 즉, 마이크로서비스의 독립적 배포 개념을 반드시 수용해야한다. 다른 어떤 것을 추가로 배포하지 않고도 한 마이크로서비스의 변경 사항을 운영 환경에 배포하고 릴리스하는 것은 중요하다.

 

2. 비즈니스 도메인 중심의 모델링

도메인 주도 설계와 같은 기술을 사용하면 소프트웨어가 동작하는 실제 도메인을 더 잘 표현하도록 코드를 구성할 수 있다. 마이크로서비스 아키텍처에서는 동일한 개념을 사용해 서비스 경계를 정의한다. 비즈니스 도메인을 중심으로 서비스를 모델링함으로써 새로운 기능을 좀 더 쉽게 출시하고 마이크로서비스를 다양한 방식으로 재결합해 사용자에게 새로운 기능을 제공할 수 있다.

 

둘 이상의 마이크로서비스를 변경해야하는 제품 기능을 출시하려면 비용이 많이 든다. 각 서비스(혹은 팀)와 작업을 조율해야 하고 해당 서비스들의 새 버전이 배포되는 순서를 주의 깊게 관리해야한다. 이는 단일 서비스(또는 모놀리스) 내부에서 동일한 변경을 수행하는 것보다 훨씬 더 많은 작업이 필요하다. 따라서 가능한 한 서비스 간 변경을 적게 수행할 수 있는 방법을 찾는게 좋다.

전통적 3계층 아키텍처

3계층 아키텍처로 대표되면 계층형 아키텍처를 자주 볼 수 있다. 아키텍처의 각 계층은 관련된 기술적 기능을 기반으로 하는 각 서비스 경계를 포함해 서로 다른 서비스 경계를 나타낸다. 이 예에서 프레젠테이션 계층만 변경해야 한다면 상당히 효율적일 것이다. 하지만 경험으로 이 유형의 아키텍처에서 기능 변경은 대개 여러 계층에 걸쳐 나타나 프레젠테이션, 애플리케이션, 데이터 계층의 변경이 필요하다. 이러한 문제는 아키텍처가 훨씬 더 계층화되면 심각해진다. 각 계층은 더 많은 계층으로 분할될 때가 많다.

 

서비스를 비즈니스 기능 단위로(수직적으로) 처음부터 끝까지 한 조각으로 만들면, 비즈니스 기능을 최대한 효율적으로 변경하도록 아키텍처를 배치할 수 있다. 우리는 마이크로서비스에서 기술적 기능의 높은 응집력보다 비즈니스 기능의 높은 응집력을 더 우선시해야한다.

 

3. 자기 상태 소유

마이크로서비스가 공유 데이터베이스 사용을 피해야한다는 생각은 많은 사람을 힘들게 한다. 한 마이크로서비스가 다른 마이크로서비스가 소유한 데이터에 엑세스하려면 두 번째 마이크로서비스에 데이터를 요청해야 한다. 이는 마이크로서비스에 어떤 데이터를 공유하고 감출지 결정하는 능력을 제공하므로 자유롭게 변경할 수 있는 기능(내부 구현)과 거의 변경하지 않는 기능(소비자가 사용하는 외부 계약)을 명확히 분리할 수 있게 해준다.

 

독립적 배포성을 실현하려면 마이크로서비스에 대한 하위 호환성이 없는 변경을 제한해야 한다. 만약 업스트림 소비자와의 호환성을 깨뜨리면 소비자들에게도 변경을 강요할 것이다. 마이크로서비스에 대한 내부 구현 상세와 외부 계약을 명확하게 구분하면 하위 호환성이 없는 변경을 줄이는 데 도움이 된다.

 

마이크로서비스에서 내부 상태를 감추는 것은 객체 지향 프로그래밍의 캡슐화와 유사하다. 객체 지향 시스템에서 데이터 캡슐화는 정보 은닉의 실제 예다.

정말 필요한 경우가 아니라면 데이터베이스를 공유하지 말아야한다. 공유를 회피하기 위해 할 수 있는 모든 것을 수행하자. 데이터베이스 공유는 독립적 배포성을 달성하는데 가장 나쁜 것 중 하나다.

서비스를 적절한 경우에 사용자 인터페이스(UI), 비즈니스 로직, 데이터를 캡슐화하는 비즈니스 기능 단위 조각으로 간주하자. 이렇게 하면 비즈니스와 관련된 기능을 변경하는 노력을 줄일 수 있다. 이러한 방식으로 데이터와 동작을 캡슐화하면 비즈니스 기능에 대한 높은 응집력을 얻을 수 있다. 또한 서비스의 데이터베이스를 숨김으로써 결합도를 낮출 수 있다.

4. 크기

마이크로서비스는 쉽게 이해할 수 있는 크기로 유지되어야 한다. 마이크로서비스의 목적은 가능한 한 작은 인터페이스를 갖는 것이다.

 

결과적으로 크기의 개념은 상황에 크게 좌우되지만, 일단 크기에 대한 걱정은 접어두자. 처음 시작할 때는 두 가지 핵심 사항에 집중하는 것이 훨씬 더 중요하다.

 

첫째, 얼마나 많은 마이크로서비스를 처리할 수 있는가? 서비스가 많을수록 시스템의 복잡성이 증가하고, 이에 대처하려면 새로운 기술을 배워야한다. 마이크로서비스로의 전환은 복잡성을 유발하는 근원이 되며 이로 인해 발생할 수 있는 모든 문제를 야기한다. 이러한 이유로 마이크로서비스 아키텍처로의 전환은 점진적으로 이루어지는게 좋다.

둘째, 모든 것이 끔찍하게 결합돼 엉망인 상황을 피하면서 마이크로서비스 경계를 최대한 활용하려면 어떻게 경계를 정의해야 하는가? 이러한 주제는 마이크로서비스로의 여정에 집중해야하는 훨씬 더 중요한 것들이다.

 

5. 유연성

마이크로서비스는 비용이 들기 때문에 그 비용이 선택하려는 옵션의 가치에 견줘 적당한지 따져봐야 한다.

 

마이크로서비스 채택은 '스위치를 켜는 것'이 아니라 '다이얼을 돌리는 것'과 같다고 생각해야한다. 다이얼을 높은 쪽으로 돌리고 더 많은 마이크로서비스를 사용할수록 유연성은 높아진다. 하지만 그만큼 고충도 늘어난다. 이러한 이유로 점진적인 마이크로서비스 채택을 추구하는 것이 좋다. 다이얼을 조금씩 돌려 소리를 키우듯, 점진적으로 적용하면 수행 영향도를 더 잘 판단하고 필요한 경우 중지할 수 있다.

 

6. 아키텍처와 조직의 정렬

유명한 콘웨이의 법칙(Conways' law)은 다음과 같이 명시한다.

시스템을 설계하는 조직은··· 이러한 조직의 커뮤니케이션 구조를 본떠 설계하도록 제한된다.

 

핸드오프와 사일로(silo)를 줄이기 위해 사람들을 다양한 기술을 갖춘 팀으로 묶는다. 또한 요즘은 그 어느 때보다 훨씬 더 빨리 소프트웨어를 출시하길 원한다. 이런 변화는 팀을 구성하는 방식을 다양하게 선택할 수 있도록 했으며, 결국 시스템을 분해하는 방식으로 팀을 구성할 수 있게 됐다.

수직적인 비즈니스 라인을 따라 세분화된 조직과 아키텍처

수평적으로 계층화된 아키텍처와 조직이 아니라, 수직적 비즈니스 라인을 따라 조직과 아키텍처를 세분화한다. 여기에서 고객 프로파일 측면의 변경을 모두 책임지는 전담 팀이 있다고 하자. 따라서 이에 대한 변경 범위는 한 팀으로 제한된다.