SOA( Service Oriented Architecture)
MSA ( MicroService Architecture)
공통 철학
- 비즈니스를 구현할 때 서로다른 서비스들이 존재하고, 이런 서비스들을 조합하여 하나의 비즈니스 요구사항을 해결한다
- SOA와 MSA는 기능 중심의 모듈 재사용보다 상위 수준의 서비스 수준의 재 사용성에 초점 맞추다는 공통점이 있다.
- 소프트웨어는 코드라는 형체가 있지만 보이지 않기 때문에, 더 정확하고 명확하게 설계되어야 한다.
- SOA와 MSA의 기본 철학은 비슷하나, SOA > MSA MSA가 더 작은단위로 아키텍쳐 형태에 차이가 있다.
차이점
공유관점
SOA 는 모듈의 의존성은 줄이되 모듈 내에서 공유할 수 있는건 최대한 공유하는 정책을 사용한다.
반면, MSA 는 가능한 공유하지 않고 모듈들이 독립적으로 운용될 수 있도록 아키텍처를 디자인 한다.
서비스 재사용성 강조하는 한 가지 작은 서비스에 집중한다. 그리고 SOA는 서비스를 최대한 공유하려고 ESB 같은 걸 도입하지만 MSA는 최대한 독립적으로 구성하도록 디자인한다.
Flow 관점
SOA 는 서비스의 Flow 를 유지하려하지만, MSA 는 Flow 의 구별을 요구한다.
가령, 서비스 내에서 결제를 하고자 할때, SOA 는 관련된 루틴을 수행하여 결제를 지원함으로써, 유저에게 제공해주는 "서비스" 를 1차 목적으로 한다.
반면, MSA 는 유저에게 관련된 루틴과 결제 루틴을 별도로 이용하게끔 한다. 즉 서비스 내의 독립이 아닌 독립된 서비스를 지향한다.
그렇다보니 SOA 아키텍처는 대게 어느정도 업격한 Protocol 과 Message 체계를 운용하게 되고, MSA 의 경우 별도의 체계가 없이 경량화된 프로토콜을 통해 운용되게 된다.
지향점
SOA 는 서비스들의 재사용에 중점을 두지만 MSA 는 서비스들의 독립을 추구한다.
경계식별
특성
- SOA는 각 레이어의 통신방법을 중시하며, 재사용을 위해 공유할수 있습니다.
- MSA는 배포와 업무 조직단위의 서비스(레파지토리) 자체가 분리된다. 서비스내에 동일 로직이 생길수 있으며 각 서비스가 책임진다.
- MSA에서 서비스 오케스트레이션 영역에 목숨걸지말고, 유지보수와 배포에 포커싱해야합니다. ( 데브옵스 )
- MSA에서 API 게이트 웨이를 반드시 사용해야하는 강박관점도 없애야 한다.
콘웨이 법칙
시스템을 설계하는 조직은 조직의 의사소통 구조를 본딴 설계를 생산하도록 제약된다는 것이다. 우리는 이 사실이 시스템 설계 관리에 중요한 영향을 미친다는 것을 보았다. 기본적으로, 우리는 설계 조직의 구조에 대한 기준을 발견했다: 설계 활동은 의사소통 필요에 따라 조직되어야 한다.
조직도는 콘웨이의 법칙이 말하는 것처럼 인터페이스 명세와 서로 얽혀 있다. "시스템을 설계하는 조직은, 그 조직의 의사소통 구조를 본뜬 시스템을 만들어내게 되어 있다." 이어서 콘웨이는 최초의 조직도에는 첫 설계 내용이 반영될 것이라고 지적한다. 이 설계가 제대로일 가능성은 물론 아주 낮다. 시스템 설계가 자유롭게 변경될 수 있어야 한다면 조직 역시 변화에 대비하고 있어야 한다.
역 콘웨이 법칙
애플리케이션 아키텍처는 그것을 개발하는 조직의 구조를 그대로 반영한다는 뜻입니다. 따라서 이 법칙을 역으로 이용해서 조직의 구조가 마이크로서비스 아키텍처에 고스란히 반영되도록 설계해야 합니다. 이렇게 하면 개발 팀과 서비스를 느슨하게 결합시킬 수 있습니다.
서비스 경계식별
마이크로 서비스가 무조건 작은 단위로 쪼게어, 우리가 운영을 하기 힘든케이스가 되어선 안됩니다.
중요한것은 "너무 크지도 작지도 않은것" 이며 사실은 우리에게 적절한 신중하게 디자인한 도메인모델을 사용하는것입니다.
무조건 작게 만드는것이 아닌, 어떻게 구분을 할것인가? 이며 DDD의 Bounded Conxtext 는 이러한 점에서 도움을 줄수 있습니다.
DDD가 마치 MSA를 위한것인것처럼 보일수 있는데, SOA/모놀리식 등에서도 활용될수 있습니다.
경계가 꼭 배포단위가 될필요가 없으며, 리팩토링을 통해서도 경계를 만들수 있기때문이며 필요하면 독립될수 있기때문입니다.
소프트웨어의 관심사를 도메인을 바탕으로 분명하게 분리시켜야 한다.
상호 의존성을 갖기 때문에, 서브도메인으로 나누지 않는다면 변화가 계속됨에 따라 훨씬 큰 부담을 지게 된다.
Next - 데브옵스 패턴
오늘날의 소프트웨어 환경에서는 모든 조직이 모놀리스를 제거하고, 파이프라인을 자동화하며, 전체적인 작업을 감소함으로써 관행을 현대화해야 한다는
압박을 지속적으로 받고 있습니다. 현대화를 위해 대부분의 조직은 데브옵스 관행으로 전환하지만,
이러한 전환 여정을 자체적으로 완료할 수 있는 역량을 보유한 경우는 그리 흔치 않습니다.
데브옵스로 원활하게 전환을 해주는 단일한 방법은 존재하지 않습니다. 서로 고립된 상태로 운영되는 조직들을 정렬하려면 문화적, 절차적,
기술적 변화가 함께 이루어져야 합니다. 비즈니스 요구와 목표에 맞는 실용적인 접근 방식을 신중하게 사용하면, 궁극적으로 성공할 수 있습니다.
참고링크
- 콘웨이 법칙 : https://johngrib.github.io/wiki/Conway-s-law/
- MSA VS SOA : http://blog.naver.com/PostView.nhn?blogId=stmshra&logNo=221446919085&parentCategoryNo=&categoryNo=73&viewDate=&isShowPopularPosts=true&from=search
- DDD 바운디드 컨텍스트 : http://redutan.github.io/2018/04/28/IDDD-chapter02
- 마이크로 서비스 경계 식별 : https://docs.microsoft.com/ko-kr/azure/architecture/microservices/model/microservice-boundaries
- 데브옵스 패턴 : https://newrelic.com/kr/resources/ebooks/devops-maturity-phases
- 개발자 추천도서 : http://www.yes24.com/Product/Goods/77283734 - 클린아키텍처