마이크로 서비스 인 액션 4장을 읽고 정리해보았습니다.
마이크로 서비스 애플리케이션에 새로운 기능을 설계하려면 신중하고 합리적인 범위를 설정해야 한다. 새로운 서비스를 개발하거나 기존 서비스를 확장할 시기와 서비스간의 경계, 그리고 어떻게 서비스들이 협업할지를 결정해야 한다.
잘 설계된 서비스에는 3가지 핵심 특징이 있다.
시장조사나 고객 인터뷰, 영향도 매핑 등의 몇가지 기법을 활용해 비즈니스 문제에 대해 조사와 분석을 할 수 있다.
어떤 기능을 구축할지, 이미 존재하는 서비스와 새로운 서비스에서 그 기능을 어떻게 지원할지 정해야 한다. 올바른 서비스의 목적을 선택하는 것이 중요하다.
서비스의 범위를 정하는 것은 3가지 전략이 있다.
비즈니스 역량이란 조직이 가치를 창출하고 비즈니스 목표를 만족하기 위해 조직이 수행하는 것이다. 이는 도메인 주도 설계(DDD)접근 방식과 밀접하게 관련이 있다. Bounded context란 도메인 내의 모든 솔루션은 여러 Bounded context로 구성될 수 있다. 각 context내의 모델은 응집도가 높고 실 세계와 동일한 뷰를 가진다. 각 context는 다른 context와 강력하고 명확한 경계를 가진다. 이 것은 서비스의 범위를 지정할 때 자연스러운 출발점이 된다. 각 context는 솔루션의 여러 영역 간 경계를 나타낸다. context는 서비스와 비즈니스 역량의 영역에 직접 매핑된다. 각 Bounded context는 내부 동작을 감추면서 다른 context에 API를 제공한다. 내부/공개의 구분은 서비스가 진화하는 데 유용한 메커니즘을 제공한다. 시스템 초기에는 고수준의 경계를 나타내는 큰 크기의 서비스를 구축하는 것을 선택할 수 있다. 시간이 지나면서 내포된 컨텍스트의 행동을 노출하는 별도의 서비스로 분리할 수 있다. 이렇게 하면 비즈니스 로직의 복잡도가 증가해도 교체하기 쉽고 높은 응집도를 유지할 수 있다.
하지만 비즈니스 역량기준으로 분리하는 것은 비즈니스와 대상 도메인에 대한 상당한 이해를 요구한다. 충분한 정보가 없거나 잘못된 가정을 올바른 설계 결정을 내렸는지 확신할 수 없다. 모든 비즈니스에서 요구사항을 이해하는 것은 복잡하고 시간이 걸리며 반복적인 과정이다. 비즈니스 역량접근법은 대규모 비즈니스 경계를 포함하는 큰 크기의 서비스 초기 개발에 치우쳐 있다. 감당할 만한 수준의 응집도와 교체성을 유지하기 위해 서비스를 쪼갤 필요가 있다.
범위를 정하는 다른 방법은 애플리케이션 내의 동사 또는 유스케이스를 식별하고 이런 책임에 해당하는 서비스를 구축하는 것이다. 다음과 같은 경우에 유용한 방법이다.
여러 고수준의 마이크로 서비스가 큰 규모의 하위 비즈니스 역량에 접근하는 패턴이 있는데 이런 팬턴은 밥 마틴의 클린 아키텍처나 앨리스테어 콕번의 육각형 아키텍처롸 유사하다. 이 아키텍처는 개념적으로 우아하지만 마이크로 서비스 시스템에 현명하게 적용해야 한다. 하위 역량을 상태 저장소로 대하는 것은 빈약하고 우둔한 서비스를 낳을 수 있다. 이런 서비스들은 다른 고수준의 서비스의 중재 없이는 아무런 동작도 할 수 없기 때문에 자율적이지 못하다. 또한 유용한 모든 동작을 수행하는데 필요한 원격 호출과 긴 서비스 연결의 수가 증가한다. 또한 이 방식은 하위 저장소가 단단히 결합할 위험이 있어 서비스를 독립적으로 배포하는 능력을 저해한다. 이런 오류를 피하려면 세분화단 동작 지향 서비스(action-oriented services)를 개발하기 전에 내부에서 외부로 설계해 큰 크기의 유용한 역량을 마이크로 서비스를 설계하는 것이 좋다.
유스케이스를 반영하는 서비스를 설계할 때 광범위한 범위의 책임 중에서 어떤 부분을 서비스가 맡을지 고려하는 것이 중요하다. 조율과 자율적 구성 기법을 균형있게 택하면 자율성이 떨어지는 서비스를 구축할 위험을 줄일 수 있다.
기능적 분해는 애플리케이션의 현재 필요성에 치우쳐 있고 어떻게 진화할지에 대해서는 명확하게 고려하지 않는다. 순수한 기능적 접근 방법은 새로운 또는 진화하는 요구사항에 대해 유연하지 못한 서비스를 만들어 시스템의 미래 성장에 제약을 줄 수 있다. 그래서 변경의 위험을 중가시킨다. 그러므로 시스템의 기능을 고려할 뿐만 아니라 애플리케이션의 어느 부분이 앞으로 변경될지도 고려해야 한다.
기술 역량은 비즈니스 역량의 크기와 복잡성을 제한해 다른 마이크로 서비스를 지원하고 단순화할 때 사용해야 한다. 이런 역량을 별도의 서비스로 분리할 때 독립적으로 변경될 것 같은 변경가능성을 포착해 서비스 재사용성을 극대화한다.
문제 도메인에 대한 이해가 불완전하거나 부정확할 수 있다. 모든 비즈니스 문제의 필요성을 이해하는 것은 복잡하고 시간 소모적이고 반복적인 과정이다. 지금 당장보다는 향후 서비스를 어떻게 사용할지 고려해야 한다. 그러나 단기간의 요구사항과 장기간의 서비스 유연성 간의 경쟁에 직면할 수 있다. 마이크로 서비스에 최적화되지 않은 서비스의 분리는 비용이 들 수 있다.
때때로 서비스 경계가 의심스러울 때는 큰 규모의 서비스를 구축하는 것이 낫다.
일반적으로 좋은 소프트웨어는 명확한 공개 API를 사용해 내부 모듈 경계를 잘 유지한다.
큰 서비스로 시작했다면 시간이 지나면서 기존 서비스에서 새로운 마이크로 서비스를 떼어내거나 제거할 필요성이 발견될 것이다. 가장 중요한 것은 이것을 사용하는 서비스가 깨지지 않도록 하고 적시에 새로운 교체 서비스로 이관해야 한다는 것이다. 새로운 서비스를 떼어내려면 확장-이관-축소 패턴(expand-migrate-contract pattern)을 적용해야 한다.
바운디드 컨텍스트 자체는 조직에서 여러 팀이 애플리케이션의 소유권을 효과적으로 나눠 갖는 방법이다. 특정 바운디드 컨텍스트의 서비스를 소유하는 팀을 구성하는 것은 콘웨이의 법칙을 반대로 이용하는 것이다.
서비스의 소유와 전달을 여러 팀에 나눈 것은 3가지 의미가 있다.
이런 서비스 오너십의 분산은 커다란 어려움을 초래하지만 몇가지 전술이 도움이 될 수 있다.
자바스크립트로 직접 만들면서 배우는 - 자료구조와 알고리즘 강의 바로 가기
기계인간 이종립, 소프트웨어 개발의 지혜 - Git 강의 바로 가기
코드숨에서 매주 스터디를 진행하고 있습니다. 메일을 등록하시면 새로운 스터디가 시작될 때 알려드릴게요!
