'크고 작은 모든' 서비스들
27. ‘크고 작은 모든’ 서비스들
서비스 지향 아키텍처와 마이크로서비스 아키텍처는 최근에 큰 인기을 얻고 있는 이유
- 서비스를 사용하면 상호 결합이 철저하게 분리되는 것처럼 보인다. 사실 일부만 맞는 말
- 서비스를 사용하면 개발과 배포 독립성을 지원하는 것처럼 보인다. 사실 일부만 맞는 말
서비스 아키텍처
서비스 그 자체로는 아키텍처를 정의하지 않는다.
함수들의 구성 형태도 이와 비슷하다.
결국 서비스는 프로세스나 플랫폼 경계를 가로지르는 함수 호출에 지나지 않는다.
아키텍처적으로 중요한 서비스도 있지만, 중요하지 않은 서비스도 존재한다.
서비스의 이점?
결합 분리의 오류
시스템을 서비스들로 분리함으로써 얻게 되리라 예상하는 큰 이점 중 하나는 서비스 사이의 결합이 확실히 분리된다는 점
어느 정도 일리는 있지만, 꼭 그런 것은 아님
프로세서 내의 또는 네트워크 상의 공유 자원 때문에 결합될 가능성이 여전히 존재
서비스 사이를 오가는 데이터 레코드에 새로운 필드를 추가한다면, 이 필드를 사용해 동작하는 모든 서비스는 반드시 변경되어여야 한다.
그래서 간접적으로 결합이 된다.
인터페이스가 잘 정의되어 있어야 한다는 이점은 명백히 사실
개발 및 배포 독립성의 오류
서비스를 사용함에 따라서 예측되는 또 다른 이점은 전담팀이 서비스를 소유하고 운영한다는 점
어느 정도 일리는 있지만, 극히 일부일 뿐
- 대규모 엔터프라이즈 시스템은 서비스 기반 시스템 이외에도, 모노리틱 시스템이나 컴포넌트 기반 시스템으로도 구축할 수 있다 -> 그래서 서비스는 확장 가능한 시스템을 구축하는 유일한 선택지가 아님
- 서비스라고 해서 항상 독립적으로 개발하고, 배포하며, 운영할 수 있는 것은 아님
컴포넌트 기반 서비스
서비스가 반드시 소규모 단일체여야할 이유는 없다.
서비스는 컴포넌트 구조를 갖출 수도 있다.
이를 통해 서비스 내의 기존 컴포넌트들을 변경하지 않고도 새로운 컴포넌트를 추가할 수 있다.
각 서비스의 내부는 각자의 방식대로 컴포넌트를 설계할 수 있으며, 파생 클래스를 만들어서 신규 기능을 추가할 수 있다.
횡단 관심사
아키텍처 경계가 서비스 사이에 있지 않다.
오히려 서비스를 관통하며, 서비스를 컴포넌트 단위로 분할한다.
직면하는 횡단 관심사를 처리하려면 서비스 내부는 의존성 규칙도 준수하는 컴포넌트 아키텍처로 설계해야 한다.
결론
서비스는 시스템의 확장성과 개발 가능성 측면에서 유용하지만, 그 자체로는 아키텍처적으로 그리 중요한 요소는 아니다.
시스템의 아키텍처는 시스템 내부에 그어진 경계와 경계를 넘나드는 의존성에 의해 정의된다.
참조
- 클린 아키텍처(Clean Architecture)