마이크로서비스는 SOA의 한 유형이고 비즈니스 도메인을 중심으로 모델링된 독립적으로 배포 가능한 서비스다. 기술 관점에서 마이크로서비스는 하나 이상의 네트워크 종단점을 통해 캡슐화되는 비즈니스 기능을 외부에 공개한다. 또한 잘 정의된 인터페이스를 통해, 데이터 저장소와 인출 기능을 캡슐화하고 데이터를 외부에 공개한다. 따라서 데이터베이스는 서비스 경계 내부에 숨겨져 있다. 그래서 마이크로서비스는 기술에 중립적이라는 장점도 있다.
독립적인 배포 가능성
독립적인 배포 가능성이란 다른 서비스를 활용하지 않고서 마이크로서비스에 변경을 가하는 방식을 서비스 환경에 배포할 수 있다는 개념이다. 실제로 시스템 내에서 배포를 관리하는 방법이라는 사실이 중요하다.
독립적인 배포를 위해서는, 서비스가 느슨하게 결합되어 있음(loosely coupled)을 보증할 필요가 있다. 즉, 다른 서비스를 변경하지 않고도 특정 서비스를 변경할 수 있는 능력을 갖출 필요가 있다. 이를 위해서 서비스 간에 명시적이고 잘 정의된 안정적인 인터페이스가 필요하다. 구현을 하다보면 이것이 어려울 때가 있는데 일례로 데이터베이스 공유가 특히 문제다. 인터페이스가 안정적인 느슨한게 결합된 서비스가 필요하다면, 서비스 경계를 제대로 알아야 한다.
비즈니스 도메인을 중심으로 하는 모델링
기능 출시나 변경을 할 때 변경해야 하는 서비스를 줄이는, 즉 교차 서비스 변경을 최소로 줄이게끔 보증하는 방법을 찾는다.
| UI 팀 | 백엔드 팀 | 데이터베이스 관리자 | ||
|---|---|---|---|---|
| 웹 UI | → | 백엔드 | → | 데이터베이스 |
위와 같이 전통적인 3계층 아키텍처로 작업하는 회사가 있다고 예를 든다. 기능을 간단하게 변경하려고 하면, UI팀에서 UI를 변경하고 백엔드 팀에서 UI에 보여줘야할 값을 변경해야 하고, 이런 변경을 수용하는 데이터베이스로 작업해야 한다. 이런 변경사항은 각 팀에서 관리하고, 올바른 순서로 배포해야 한다. 이런 3계층 아키텍처는 보편적이고 상당히 일반적인 기술이며, 모든 사람이 이해한다. 이런 아키텍처가 익숙한 이유는 우리가 팀을 조직화하는 방식에서 비롯됐기 때문이다. 데이터베이스 관리자는 데이터베이스 관리자들끼리, 자바 개발자는 자바 개발자들끼리 팀을 구성하게 하는 것처럼 말이다.
그러나 상황이 바뀌었다. 우리는 그 어느 때보다도 훨씬 더 빠르게 소프트웨어를 출시하길 원한다. 이런 변화를 통해 전통적인 3계층 아키텍처가 아니라 다른 방식으로 팀을 조직하고 시스템을 분해하는 새로운 선택을 하고 있다.
기능 변경은 주로 비즈니스 기능의 변경에 초점을 맞춘다. 비즈니스 기능은 사실상 3개 계층에 분산되어 있고, 기능 변경은 여러 계층에 걸쳐 있을 가능성이 높다. 위에서 예를 든 것을 봐도 기능을 변경하려면 UI, 백엔드, 데이터베이스에 변경 반영해야 한다. 3계층 아키텍처는 기술 관점(UI, 백엔드, 데이터베이스)에서는 응집력이 높지만, 비즈니스 기능 관점에서는 응집력이 낮다. 기능 변경이 비즈니스 기능의 변경에 초점 맞춰졌다는 것을 생각해보면 비즈니스 기능의 응집력을 선택할 필요가 있다. 3계층 아키텍처의 잠재적인 대안 아키텍처는 아래와 같다.
| 비즈니스 기능 1 | 비즈니스 기능 2 | 비즈니스 기능 3 | ||
|---|---|---|---|---|
| 웹 UI | 웹 UI | 웹 UI | ||
| 백엔드 | 백엔드 | 백엔드 | ||
| 데이터베이스 | 데이터베이스 | 데이터베이스 |
비즈니스 기능별로 단일 서비스로 만들고 각 계층을 단일 서비스 내에 캡슐화했다. 그리고 비즈니스 기능별로 팀을 구성한다. 만약 비즈니스 기능 1개를 변경하고자 할 때 다른 기능에 미치는 영향을 최소화하고 빠르게 비즈니스 기능을 변경할 수 있다.
데이터 소유권 문제
어떤 서비스에서 다른 서비스가 보유한 데이터에 접근하고 싶다면 데이터를 보유한 서비스를 찾아서 해당 데이터를 요청해야 마땅하다. 해당 서비스는 외부에 무엇을 공유하고 무엇을 숨길지를 결정할 수 있다. 또한 임의의 이유로 변경될 수 있는 내부 구현 세부사항으로부터 좀 더 안정적인 공개 계약으로 서비스를 매핑함으로써, 안정적인 서비스 인터페이스를 보장한다. 독립적인 배포 가능성을 원한다면 서비스 간에 안정적인 인터페이스가 필수다. 특정 서비스의 공개 인터페이스가 계속 변경된다면 이를 사용하는 다른 서비스도 변경해야 한다. 정말 필요한 경우가 아니라면 데이터베이스는 공유하면 안된다. 독립적인 배포 가능성을 원한다면, 데이터베이스 공유는 최악의 선택 중 하나다.
UI, 애플리케이션 로직, 데이터 저장소를 캡슐화하는 비즈니스 기능은 변경하는데 드는 노력을 줄일 수 있고, 비즈니스 기능의 응집력을 높여준다. 데이터베이스를 숨기는 방법 또한 결합도를 줄여준다.
마이크로서비스의 장점
- 배포의 독립정인 특성으로 인해 시스템의 확장성과 견고성을 개선할 수 있다.
- 시스템의 한 부분인 서비스의 병렬 개발 작업이 가능하므로, 개발자들은 서로 방해받지 않고 각자 문제 해결에 몰입할 수 있다.
- 프로세스 격리를 통해 다양한 기술 선택이 가능하므로, 여러 프로그래밍 언어, 프로그래밍 스타일, 배포 플랫폼, 데이터베이스 등을 병용해 올바른 조합을 찾을 수도 있다.
- 유연성을 제공한다. 문제를 향후 어떻게 해결할지에 대해 더 많은 선택지를 열어준다.
그러나 이런 장점 중 어떤 것도 공짜로는 얻지 못한다는 사실에 유의해야 한다.
마이크로서비스가 야기하는 문제점
네트워크를 거치는 컴퓨터 간의 통신은 즉각적이지 않다. 마이크로서비스는 서비스 간 네트워크로 통신하는데 네트워크의 특성 때문에 시스템 동작을 예측하기 어렵다. 트랜잭션 같은 단일 프로세스 모놀리스로 해결 가능한 단순한 활동도 마이크로서비스에선 매우 어려울 수 있고, 시스템이 복잡해지면 다른 종류의 기술을 도입하는 대가로 트랜잭션과 안전성을 포기해야 할 것이다. 여러 컴퓨터에 분산된 데이터의 일관성에도 노력해야 한다.
요약하자면, 서비스 간 네트워크로 통신하는 마이크로서비스는 시스템이 커질 수록 더욱 복잡해지고 심각한 문제에 직면할 가능성이 높다는 것이다.
마이크로서비스 전문가인 제임스 루이스는 "우리는 대가를 치르고 마이크로서비스 선택권을 구매한다."라고 했다. 대가를 치르고 마이크로서비스 선택권을 구매하기 때문에 대가가 선택권만큼의 가치가 있는지 판단해야 한다.
사용자 인터페이스
순수하게 서버 쪽에 마이크로서비스를 수용하는 과정에 집중하느라, UI는 단일 모놀리스 계층으로 남겨두는 안 좋은 사례가 많다. 새로운 기능을 더 신속하게 배포할 수 있는 아키엑처를 원한다면, UI를 모놀리스 덩어리로 남겨 두는 결정은 큰 실수가 될 수 있다.
기술
마이크로서비스 아키텍처와 함께 할 신기술 두 마리 토끼를 한 번에 잡고 싶을 순 있지만, 그러면 안 된다. 새로운 기술을 채택하는 데는 비용과 노력이 많이 필요하다. 그리고 마이크로서비스 아키텍처를 올바르게 발전시키고 관리하는 방법을 개발하려면 분산 시스템과 관련된 수많은 문제를 해결해야 하며, 이는 전에 한 번도 직면하지 못한 문제일 것이다. 이런 문제를 해결하려면, 먼저 익숙한 기술 스택을 활용해 문제를 이해하고 나서, 그 다음에 찾아낸 문제를 해결하기 위해 기술 변경을 고려하는 방식이 유용하다.
규모
마이크로서비스는 얼마나 커야할까라는 것에 관련된 것이다. 마이크로서비스 관점에서 '규모'에 가장 근접하다고 생각하는 정의는 마이크로서비스 전문가 크리스 리처드슨이 말한 "마이크로서비스 목표는 '가능한 작은 인터페이스를 유지'하는 것"이라는 발언이라고 한다.
궁극적으로 규모는 상대적이다. 15년 동안 한 시스템에서 작업한 사람들에게 10만 행 규모의 시스템은 매우 이해하기 쉬울 것이다. 하지만 프로젝트를 처음 접하는 사람에게는 시스템이 너무 크다고 느낄 것이다. 마찬가지로 이제 막 마이크로서비스로 전환해서 10개 남짓한 마이크로서비스를 운영하는 회사와, 몇 년 전부터 마이크로서비스를 표준으로 정해 100개 이상의 마이크로서비스를 운영하는 회사에게 규모에 관한 답변은 서로 다를 것이다.
규모에 관해 걱정하지 말고 마이크로서비스를 시작할 때는 2가지 사항에 집중해야 한다.
- 얼마나 많은 마이크로서비스를 다룰 것인가?
서비스가 많아질수록 시스템의 복잡성이 증가할 것이고 이에 대처하기 위해 새로운 기술을 배워야 할 것이다. 그래서 작가는 마이크로서비스 아키텍처로 가는 점진적인 마이그레이션을 옹호한다. - 모든 것이 끔직하게 결합된 혼돈 상황이 되지 않으면서 마이크로서비스를 초대한활용하기 위해 경계를 정의하는 방법은 무엇일까?
위 두 가지에 집중해야 한다.
소유권
전통적인 IT 조직에서 소프트웨어 개발이라는 행위는 실제 요구사항을 정의하고 고객과 연결된 비즈니스와는 완전히 분리된 부문에서 처리된다. 진정한 기술 조직이라면 비즈니스 도메인을 중심으로 팀을 구성하고 비즈니스와 소프트웨어 개발을 비즈니스 기능별로 정렬해야 한다. 그러면 배포 팀에 소유권을 명확하게 할당하는 작업은 훨씬 수월해진다. 또한 핵심은 여러 팀에서 공유되는 서비스를 축소하여 배포 경합을 최소화할 수 것이다. 즉 비즈니스 도메인 지향 마이크로서비스 아키텍처를 통해 조직적인 구조에서 이런 변화는 훨씬 더 손쉽다.
