You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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



특성및 주의점

  • SOA는 각 레이어의 통신방법을 중시하며, 재사용을 위해 공유할수 있으며 모놀리식에 가까울수 있다.
  • MSA는 배포와 업무 조직단위의 서비스(레파지토리) 자체가 분리된다. 서비스내에 동일 로직이 생길수 있으며 각 서비스가 책임진다.
  • MSA에서 서비스 오케스트레이션 영역에 목숨걸지말고,  유지보수와 배포에 포커싱해야합낟. ( 데브옵스는 반드시 해야한다.)
  • MSA에서 API 게이트 웨이를 반드시 사용해야하는 강박관점도 없애야 한다.


콘웨이 법칙

시스템을 설계하는 조직은 조직의 의사소통 구조를 본딴 설계를 생산하도록 제약된다는 것이다. 우리는 이 사실이 시스템 설계 관리에 중요한 영향을 미친다는 것을 보았다. 기본적으로, 우리는 설계 조직의 구조에 대한 기준을 발견했다: 설계 활동은 의사소통 필요에 따라 조직되어야 한다.


조직도는 콘웨이의 법칙이 말하는 것처럼 인터페이스 명세와 서로 얽혀 있다. "시스템을 설계하는 조직은, 그 조직의 의사소통 구조를 본뜬 시스템을 만들어내게 되어 있다." 이어서 콘웨이는 최초의 조직도에는 첫 설계 내용이 반영될 것이라고 지적한다. 이 설계가 제대로일 가능성은 물론 아주 낮다. 시스템 설계가 자유롭게 변경될 수 있어야 한다면 조직 역시 변화에 대비하고 있어야 한다.


역 콘웨이 법칙

애플리케이션 아키텍처는 그것을 개발하는 조직의 구조를 그대로 반영한다는 뜻입니다. 따라서 이 법칙을 역으로 이용해서 조직의 구조가 마이크로서비스 아키텍처에 고스란히 반영되도록 설계해야 합니다. 이렇게 하면 개발 팀과 서비스를 느슨하게 결합시킬 수 있습니다.

 

참고링크





  • No labels