• 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 는 서비스들의 독립을 추구한다.

경계식별


특성

  • 모놀리식의 오해
    • 1개의 어플리케이션으로 모두 작동되는 단점을 의미하는것이 아닙니다. 
    • 여러개로 작동해도  코드내에 어떠한 형태로든 경계가 없음을 의미합니다. 
    • 이러한 현상을 진흙공(머드볼)이라고 하며 , 찰흙같이 만들어진 제품을 고치려할때 발생하는 어플리케이션의 현상을 이야기합니다.
  • SOA는 각 레이어의 통신방법을 중시하며, 재사용을 위해 공유할수 있습니다. 
  • MSA는 배포와 업무 조직단위의 서비스(레파지토리) 자체가 분리된다. 서비스내에 동일 로직이 생길수 있으며 각 서비스가 책임진다.
  • MSA에서 서비스 오케스트레이션 영역에 목숨걸지말고,  유지보수와 배포에 포커싱해야합니다. ( 데브옵스 )
  • MSA에서 API 게이트 웨이를 반드시 사용해야하는 강박관점도 없애야 한다.


콘웨이 법칙

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

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

역 콘웨이 법칙

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


서비스 경계식별

마이크로 서비스의 가장 큰 함정은 완벽한 단일처리 모델만을 책임을 지게하여 쪼게 나가는것입니다.

즉 회원을 모두통합하여 완벽한 모델을 만들고 서비스를 만드려는 시도이며 회원 처리 서비스로 만들었다고 MSA가 되었다라고 가정하는것입니다.


서비스를 사용하는 관점에서 회원은 고객이지만 특정한 도메인 컨텍스트에서는 회원이 다음과 같이 다른의미가 될수도 있습니다.

  • 결제에서는 주문자
  • 여행에서는 여행자
  • 숙박에서는 숙박자 - 꼭 회원이 숙박할 필요는 없다. 
  • 항공에서는 탑승자
  • 배송에서는 수령자


같은 회원이라 할지라도 결제 컨텍스트와 숙박 컨텍스트에서 표현하는 의미가 다를수 있으며 이것을 한가지 모델로 정의할수없음을 의미합니다.


이렇게 경계를 갖는 구분을 만드는것을 DDD에서 BOUNDED CONTEXT라고 불립니다.

MSA에서 저장소를 분리하고 배포를 구분하는것에 너무 목숨을 걸필요가 없습니다.

이러한 경계는 꼭 배포단위만큼 쪼게어질 필요가없으며, 동일 저장소에서 리팩토링을 통해 충분히 경계를 만들수 있으며

이러한 경계가 있으면 언제든 독립 서비스로 분리해낼수도 있습니다.

배포단위는 우리가 관리할수 있는 규모이면 됩니다. 이것이 작은개발팀 규모에서도 MSA를 시도할수 있는 아이디어가 되며

Bounded Context는 배포단위를 관여하는것이 아닌~ 우리가 작성한 코드의 경계에대해서 이야기를 하며  MSA를 시도할때 먼저시작해야하는 중요한 내용입니다.



 

Next - 데브옵스 패턴

오늘날의 소프트웨어 환경에서는 모든 조직이 모놀리스를 제거하고, 파이프라인을 자동화하며, 전체적인 작업을 감소함으로써 관행을 현대화해야 한다는
압박을 지속적으로 받고 있습니다. 현대화를 위해 대부분의 조직은 데브옵스 관행으로 전환하지만, 이러한 전환 여정을 자체적으로 완료할 수 있는 역량을 보유한 경우는 그리 흔치 않습니다.

데브옵스로 원활하게 전환을 해주는 단일한 방법은 존재하지 않습니다. 서로 고립된 상태로 운영되는 조직들을 정렬하려면 문화적, 절차적,
기술적 변화가 함께 이루어져야 합니다. 비즈니스 요구와 목표에 맞는 실용적인 접근 방식을 신중하게 사용하면, 궁극적으로 성공할 수 있습니다.

MSA를 다루는 배포및 운영기술 

MSA에서는  SOA보다 더 작은단위 로 구성될수 있으며 이것을 도대체 어떻게 관리및 서버운영을 할수 있느냐가? 가장 큰 단점중에 하나였습니다.

이러한 단점을 도커가 커버하였으며 도커의 등장과 함께 MSA는 가속화가 되었으며 과거 백엔드 엔지니어는 자신의 웹서비스를 구동시켜야할 서버 OS를 다루는것이 필수 교양이였다라고 하면 

MSA를 시도하는 팀은 이제 도커는 선택이 아닌 필수가 되어가고 있습니다.


이 컨텐츠는 다음과같은 다양한 링크의 내용을 참고하였습니다.

참고링크



  • No labels
Write a comment…