마이크로 서비스 아키텍처를 알아보자 (SOA의 공통점과 차이점)

왜 마이크로 서비스를 배워야 하나?

• 가장 많이 사용되는 패러다임
• 검증된 패러다임
• 특정 기술에 묶여 있지 않은 아키텍처
• MSA 아키텍처를 사용하는 개발자 수요가 많음

 

MSA전의 아키텍처들

1. 모놀리딕 아키텍처(Monolith Architecture)

가장 처음에 나온 아키텍처

프로세스안에 모든 소프트웨어 컴포넌트가 들어있는 구조

각 컴포넌트 끼리 강하게 결합되 있음 (의존성↑)

장점

1. 디자인하기 쉬움
   • 네트워크 구축, 메시지 메커니즘, 큐 등 필요없음
2. 네트워킹, 직렬화 등 필요없기 때문에 퍼포먼스가 좋음

문제

1. Single Technology Platform
   • 모놀리딕은 모든 컴포넌트가 하나의 개발 플랫폼을 사용해서 개발되어야함
   • 항상 그 작업이 최선일 수 없음
   • 특정 기능을 위해 다른 플랫폼을 사용할 수 없음
   • 미래에 애플리케이션을 업그레이드해야 할 떄 전체를 업그래이드해야 함
2. Inflexible Deployment
   • 배포할 떄 모든 애플리케이션을 배포해야 함
   • 컴포넌트 하나하나 배포할 수 없음
   • 너무 긴 개발 주기
3. Inefficient Compute Resources
   • 각각 컴포넌트마다 컴퓨터 리소스를 동등하게 배분해야함
   • 특정 컴포넌트에 많은 리소스를 줄 수가 없음
4. Large and Complex
   • 단단히 결합되어 있어 하나를 수정하면 사이드 이펙트가 날 가능성이 높음
   • 유지보수가 너무 어려움



2. 서비스 지향 아키텍처(Service Oriented Architecture)

1998년도에 나온 아키텍처

 

기존의 애플리케이션들의 기능들을 비즈니스적인 의미를 가지는 기능 단위로 묶어서 표준화된 호출 인터페이스를 제공함

이 인터페이스를 서비스라는 소프트웨어 컴포넌트 단위로 재 조합한후, 이 서비스들을 서로 조합하여 업무 기능을 구현한 애플리케이션을 만들어내는 소프트웨어 아키텍처임

 

예를 들어, 자바 기술 기반으로 개발된 고객 정보 시스템과 메인프레임으로 구현된 계좌 이체 업무 등이 있다고 가정하면, 이 각각의 업무들은 각각의 목적에 따라서 따로 개발된것이고, 서로 연계가 불가능함

 

 이 각각의 시스템의 기능들을 업무를 기준으로 주요 기능들로 묶어서 플랫폼에 독립적인 인터페이스 (예를 들어 XML/HTTP, CORBA,SOAP)를 구현하여 외부로 서비스를 제공

장점

1. 데이터 및 기능을 공유
2. 서비스들 간에 일관된 프로토콜을 사용하여 다른 서비스를 사용 가능

문제

1. Complicated and Expensive ESB
   • 비용이 비싸고 유지보수하기 어려움

 

3. 마이크로 서비스 아키텍처(Microservice Architecture)

2011년에 이 아키텍처가 처음 언급

모놀리딕 아키텍처와 서비스 지향 아키텍처의 문제를 해결하기 위해 나옴 패러다임

모듈화, 단순한 API

특징

1. 서비스마다 컴포넌트화 되어 있음

모듈화된 디자인은 항상 옳은 아이디어

 

 이점

• 서비스별 독립적인 배포
• 잘 정의된 인터페이스를 사용할 수 있음

 

2. 서비스마다 조직화되어 있음

기존 프로젝트는 서비스 단위로 팀이 나뉘어 있지 않음

팀간 커뮤니케이션이 느림

MSA는 서비스 마다 ui, api, db개발자가 있음

 

 이점

• 빠른 개발이 가능
• 기존에는 하나의 팀이 많은 비지니스를 다뤄야하는 반면에 도메인 별로 잘 디자인된 비지니스를 다룰 수 있음

 

3. 서비스마다 프로젝트가 아니라 프로덕트임

예전 프로젝트의 목표는 동작되는 코드를 작성하는 것

하나의 프로덕트가 아니라 프로젝트이기 때문에 유저와의 관계가 없음

 

 이점

• 제품 단위로 움직이기 때문에 사용자 만족도가 높아짐
• 개발자들의 마인드셋을 변화시킨다.(책임감 상승)

 

4. 단순한 프로토콜

기존 아키텍처는 내부 서비스간에 복잡하고 유지보수가 어려움

 

 이점

• 개발을 가속화
• 유지보수가 쉬움

 

5. 탈중앙화된 운영

예전에는 모든 서비스가 어떤 개발 플랫폼을 사용할건지, 어떤 디비를 사용할 건지 등 다 같이 사용해야 함

MSA는 각 제품마다 개발 플랫폼, 디비 등 자유롭게 정할 수 있음, 다양한 결정이 가능

 

이점

• 서비스마다 기술적 결정을 다르게 할 수 있음

 

6. 탈중앙화된 데이터 관리

예전 시스템은 하나의 디비를 사용

MSA는 각 서비스마다 디비를 가지고 있음

 

중요

• 이 특징때문에 MSA가 가장 논란이 됨
• 항상 이 특징이 가능하지 않음
• 트랙잭션이 망가지거나, 데이터 중복등 에러가 발생 가능

 

이점

• 작업에 맞는 툴을 사용 가능 → 상황에 맞는 데이터 베이스를 사용하는 것은 아주 중요

 

7. 인프라 자동화

자동화된 테스팅, 자동화된 배포로 빠른 배포 주기를 가짐

 

이점

• 짧은 배포 주기

 

8. 실패를 염두한 디자인

마이크로 서비스에서 많은 프로세스와 네트워크 트래픽이 발생함

따라서, 버그가 생길 수 있음

이때 버그가 생길 수 있다는 것을 받아들이고 잘 대처하면 됨

광범위한 로깅과 모니터링이 꼭 잘 구축되어 있어야함

 

이점

• 시스템의 신뢰성을 증가

정리

• 위의 가이드라인들은 필수는 아니며 권장사항
• 필요한 부분을 적용해라
• MSA 매커니즘 생태계는 빠르게 바뀌는 중임

 

SOA와 MSA의 공통점과 차이점은?

공통점

• 비즈니스를 구현할 때 서로 다른 서비스들이 존재하고, 이런 서비스들을 조합하여 하나의 비즈니스 요구사항을 해결
• SOA와 MSA는 기능 중심 보다 서비스 중심 재사용애 초첨이 맞춰져 있음
• SOA와 MSA의 기본적인 철학은 비슷하지만, MSA가 SOA보다 더 작은 단위의 아키택처임

이미지 출처: https://wiki.webnori.com/display/devbegin/SOA+VS+MSA

 

차이점

이 둘의 근본적인 차이점은 범위

서비스 지향 아키텍처가 전체적인 아키텍처 접근 방식이라면

마이크로서비스 아케텍처는 애플리케이션 개발 팀 내의 구현 전략

 

각각의 구성 요소와 통신하는 방법

SOA는 ESB를 사용하는 반면, 마이크로서비스끼리는 언어의 제약이 없는 API를 통해 무상태(stateless) 방식으로 통신함

마이크로서비스의 API에는 언어의 제약이 없기 때문에 개발 팀에서 사용하고 싶은 툴을 선택할 수 있음

따라서, 마이크로서비스의 내결함성과 유연성이 더 우수할 수 있음

 

데이터 공유 유무

SOA는 모듈의 의존성은 줄이는 대신 모듈 내에서 공유할 수 있는 것은 최대한 공유하도록 함

MSA는 최대한 공유하지 않고 모듈들이 독립적으로 운용될 수 있도록 아키텍처를 디자인 함

SOA는 서비스를 최대한 공유하려고 ESB 같은 것을 도입하지만 MSA는 최대한 독립적으로 구성하도록 디자인한다.

 

서비스의 흐름

SOA는 서비스의 흐름(flow)을 유지하려고 함

MSA는 최대한 모듈들이 독립적으로 운용되기 떄문에 흐름을 유지하려고 하지 않음

만약, 결제 서비스가 있다면

SOA는 결제와 관련된 루틴을 수행하여 결제를 지원함으로써, 유저에게 제공해주는 서비스 를 1차 목적으로 함

MSA는 독립된 서비스를 지향하려고 하기 떄문에 유저에게 결제와 관련된 루틴과 결제 루틴을 별도로 이용하게 함

 

지향하는 바

SOA 는 서비스들의 재사용에 중점을 두지만 MSA 는 서비스들의 독립을 지향

 

 

Refs

https://bcho.tistory.com/48

https://www.udemy.com/course/microservices-architecture-the-complete-guide/

https://www.redhat.com/ko/topics/cloud-native-apps/what-is-service-oriented-architecture

https://wiki.webnori.com/display/devbegin/SOA+VS+MSA