SOA vs. MSA

SOA vs. MSA

Service Oriented Architecture 와 Microservice Architecture의 공통점과 차이점에 대해 알아보자.

공통점

SOA와 MSA 모두 “서비스를 지향”한다는 점에서 공통점을 가지고 있다.

차이점

서비스의 공유 지향점

• SOA
  - 서비스의 “재사용”을 통한 비용 절감을 주 목적으로 하고 있다. (서비스 공유 최대화)
• MSA
  - 서비스 간의 “결합도”를 최소한으로 낮추는데 그 목적이 있으며, 변화에 능동적으로 대응한다. (서비스 공유 최소화)
  - 하나의 서비스와 연결되는 다른 서비스와의 관계를 최소한으로 줄인다.

  ex. “회원가입”이라는 마이크로 서비스에서 저장된 회원 목록 데이터가 “결제”라는 마이크로 서비스에서 사용하기 위해서는…
  
  🙅 두 개의 서비스가 연결되거나 결제 서비스에서 직접 회원가입 서비스의 데이터베이스에 접속해서 데이터를 사용하는 방식이 아니라,
  🙆 API를 통해 데이터를 요청해서 사용해야하고, 회원가입 서비스에 문제가 생길 시에도 결제 서비스에는 직접적인 영향을 주지 않고 우회할 수 있는 서비스를 제공할 수 있도록 구현되어야 한다.

기술 방식

• SOA
  - 공통의 서비스를 ESB(Enterprise Service Bus)에 모아 비즈니스 측면에서 공통 서비스 형식으로 서비스 제공
  - 일반적으로 웹 서비스 형태로 개발되고 WSDL/ESB 등을 통해 서비스 간에 통신이 발생한다.
• MSA
  - 리소스 혹은 데이터는 각각의 독립된 마이크로 서비스가 공개하는 REST API를 사용해야지만 다른 서비스나 외부 시스템에서 사용할 수 있음
  - 일반적으로 MSA에서는 REST API 방식을 사용해 리소스를 제공한다.

이때, REST API란?

REST API의 특징 (리차던스의 성숙도 모델)

• LEVEL 0
  - 리소스, http method의 개념을 가지고 표현하고 있다.
  - 가장 기본적인 단계로, REST 방식으로 어플리케이션에 고려되었다고 생각하기 보다는 기존의 리소스를 단순하게 웹서비스 상태로서 제공하기 위해 url만 매핑한 형태라고 볼 수 있다.

• LEVEL 1
  - 웹으로 공개하고자 하는 리소스에 대해 의미있고 적절한 url로 표현하기 시작한 단계이다.
  - LEVEL 1에서는 적절한 패턴을 가지고 작성되었지만, 아직까지 HTTP Methods를 구분해서 사용하고 있지는 않음
  - 즉, 서비스의 형태와 작업의 종류에 맞춰 적절한 HTTP Methods를 지정하고 있지는 않다.
  - 실제로 많은 RESTful 서비스에서 이와 유사한 형태를 볼 수 있는데,
  사용자의 요청을 단순하게 GET / POST 메서드로만 처리하고 모든 반환값에 대해 에러코드 혹은 200번 성공 OK를 반환하는 경우를 이야기한다.

• LEVEL 2
  -위에서 소개한 LEVEL 1 단계에 HTTP Methods가 추가된 형태로 볼 수 있다.
  - 우리가 제공하려고 하는 리소스의 용도와 상태에 따라 적절한 HTTP Methods를 설계하고 서비스 하는 단계이다.
  - GET / POST / PUT / DELETE 에 맞게 서비스한다.
  - 같은 이름의 uri라고 하더라도 HTTP Methods에 따라 다른 형태의 서비스를 제공할 수 있다.

• LEVEL 3
  - 위에서 소개한 LEVEL 2 단계에 HATEOAS 라는 걸 추가한 것을 이야기한다.
  - 즉, “데이터”와 함께 “그 다음 작업에서 어떠한 액션”을 할 수 있는지 상태 정보를 같이 넘겨준다.
  - ex. 회원가입 후에 회원 정보 수정을 어떻게 하는지, 회원 전체 보기는 어떻게 하는지, 회원 전체 보기 후에 진행할 수 있는 또 다른 리소스에 대한 정보는 어떤게 있는지 등…
  - 클라이언트 측에서는 서버가 제공하는 서비스를 일일이 찾는 수고를 겪지 않아도 된다. (엔드포인트만 알고 있다면 서버가 제공하는 다음, 그 다음 uri 값을 알 수 있는 상태가 됨)

RESTful 서비스에서 HATEOAS 기능을 추가하는 방법은 따로 알아보기!

RESTful API를 설계할 때 고려해야 할 사항

1. Consumer first
   - 개발자 중심의 설계방식 보다는, 해당 api를 사용할 소비자 입장에서의 설계방식을 지향해야한다. (이때 소비자란, end user 뿐만 아니라 해당 api를 사용하는 또 다른 시스템 혹은 개발자도 포함)
2. Make best use of HTTP
   - http 메서드와 request / response의 타입, 헤더 값과 같은 http의 장점을 최대한 살려서 개발해야 한다.
3. Request methods
   - 최소한, 위에서 알아본 LEVLE 2 모델이 가지고 있는 특징을 살려서 개발해야 한다.
4. Response Status
   - 각각의 api 요청에 따라 적절한 http 상태 코드가 전달되어야 한다.
   - 200, 404, 400, 201, 401
5. No secure info in URI
   - uri에는 사용자의 비밀번호와 같은 critical 한 정보를 포함해서는 안된다.
6. User plurals
   - 제공하려는 데이터에 대해 “복수” 형태로 사용하는게 일반적이다.
   - ex. /users, /users/1
7. User nouns for resources
   - 모든 리소스는 가능한 동사 보다는 “명사” 형태로 표시하는게 좋다.
8. For exceptions
   - 일괄적인 엔드포인트를 사용하는 것이 좋다. (진입점을 단일화)

정리

가장 큰 차이점은 아래와 같다.

• 서비스의 공유를 최대화(SOA) 하는지, 최소화(MSA) 하는지
• 개발하는 방식에 있어서 REST 방식(MSA)을 주로 사용하는지, 웹 서비스 방식(SOA)을 사용하는지

SOA

• 사용자 UI가 있음
• 각각의 서비스들은 ESB(Enterprise Service Bus)라는 곳에 모이게 됨 -> 이렇게 모여진 서비스들이 외부에 공개가 되는 것
• 이러한 부분은 “웹 서비스” 기술을 통해 개발됨
• 서비스들 간의 통신 외에 데이터베이스에 자로를 저장하기 위해 공통적인 데이터베이스 처리 로직(SOAP / JMS / JDBC) 기술을 함께 사용할 수 있음

MSA

• 서로 독립된 마이크로 서비스들은 독립적인 개발 프로세스를 가지고 있음 (독립적인 언어, 독립적인 UI, 독립적인 비즈니스 로직, 독립적인 데이터베이스)
• 이러한 서비스들은 자신의 데이터를 외부에 공개할 때 “REST API”를 통해 공개하는 것을 권장함
• 이벤트 스트림과 같은 “메시징 서비스”(ex. kafka)를 이용해 데이터베이스의 데이터를 “동기화” 할 수 있음

  🤔 데이터 동기화 과정
  어떤 마이크로 서비스가 사용 중인 데이터베이스에 데이터(A)가 변경되었다면…
  
  변경된 데이터를 kafka에 전달 ➡️ kafka는 A라는 데이터를 관심 데이터로 등록(subscribe)해둔 객체들에게 변경된 데이터를 전달 ➡️ 변경된 데이터를 받은 마이크로 서비스들은 자신의 데이터베이스의 값을 업데이트

---

💛 개인 공부 기록용 블로그입니다. 👻

맨 위로 이동하기