클라우드 마이크로 서비스 - SOA vs MSA

SOA vs MSA

SOA와 MSA와의 차이점

서비스의 공유 지향점

• SOA - 재사용을 통한 비용 절감
• MSA - 서비스 간의 결합도를 낮추어 변화에 능동적으로 대응

 

하나의 서비스와 연결되는 다른 서비스와의 관계를 줄인다는 얘기다. 만약 <회원가입>이라는 마이크로 서비스에서 저장된 회원 목록 데이터가 <결제>라는 마이크로 서비스에서 사용되기 위해서는 두 개의 서비스가 연결되거나, 결제 서비스에서 직접 회원가입 서비스에 데이터베이스에 접속해서 데이터를 사용하는 방식이 아니라, API를 통해서  결제 서비스가 회원가입 서비스에 데이터를 요청해서 사용해야 하고, 회원가입 서비스에 문제가 생길 시에도 결제 서비스에는 직접적인 영향을 주지 않고 우회화 할 수 있도록 구현된 것이 마이크로 서비스들의 관계이다.

 

 

기술 방식

• SOA - 공통의 서비스를 ESB에 모아 사업 측면에서 공통 서비스 형식으로 서비스 제공
• MSA - 각 독립된 서비스가 노출된 REST API를 사용

 

 

SOA 방식에서는 공통으로 사용할 수 있는 서비스들을 서비스 버스라는 개념을 통해 한 곳에 모아 비지니스에 필요로 하는 하나의 서비스 형태로 만든다. 그리고 나서 모여진 서비스들을  제공하는 방식을 사용하고 있다. SOA 방식에서는 웹서비스 형태로 개발되고 WSDM과 ESB등을 통해서 서비스 간의 통신이 발생하게 된다.

 

 

반면에 MSA 독립된 비지니스 서비스들이나 리소스,데이터는 각각의 마이크로 서비스가 공개하는 REST API를 이용해야지만 다른 서비스나 외부 시스템에서 사용할 수 있게 된다. 일반적으로 MSA는 REST API 방식을 사용해서 리소스를 제공하고있다.

---

 

RESTful Web Service

A way to grade your API according to the constraints of REST.

 

 

LEVEL0

• Expose soap web service in rest style
• http://server/getPosts
• http://server/deletePosts
• http://server/doThis

 

REST 방식으로 어플리케이션이 고려되었다고 생각하는 것보다는 기존의 리소스를 단순하게 웹서비스 상태로 제공하기 위해서 URL만 맵핑한 형태라고 생각하면 된다.

 

 

LEVEL 1

• Expose resources with proper uri
• http://server/accounts
• http://sever/accounts/10
• note : improper use of http methods

 

이 단계는 웹르로 공개하고자 하는 리소스에 대해서 의미있고 적절한 URL로 표현하기 시작했다. 레벨 1단계에서는 적절한 패턴을 가지고 작성되었지만 아직까지는 HTTP의 메소드별로 서비스를 구분해서 사용하고 있지는 않는다. 즉 서비스의 형태하고 작업의 종류에 맞춰서 적절한 HTTP메소드를 지정하고 있지 않다는 것이다. 

 

실제로 많은 RESTful 서비스에서 이와 유사한 형태를 볼 수 있는데, 사용자의 요청을 단순하게 get 메소드라든가 post메소드로만 처리하고, 모든 반환 값에 대해서 error코드라던가 또는 200번 성공 OK코드를 반환하는 경우를 이야기 한다. 그래도 예시의 이름을 보면 알수 있듯이 가지고 있는 URI값은 적절하게 리소스를 표현하고 있기는 하다. 

 

 

LEVEL 2

• Level1 + HTTP Methods

 

레벨 2단계는 위에서 얘기 했던 레벨 1 단계에다가 HTTP 메소드가 추가된 형태이다. 제공하려고 하는 리소스를 적절하게 용도와 상태에 따라서 HTTP가 가지고 있는 메소드에 맞게 설계하고 서비스하는 단계이다.

 

만약 리소스의 상태가 변경할 수 없는 상태 읽기 용도로 사용되는 데이터라고 하면 GET 메소드를 사용하면 도니다. GET 메소드 방식이라는 것은 서버가 가지고 있는 리소스를 요청만 하는 것이다. 새로운 리소스를 추가하는 경우에는 POST 메소드, 기존 리소스 상태를 변경하기 위해서는 PUT메소드를 마지막으로 리소스를 삭제하고자 할 때는 DELETE 메소드를 이용해서 서비스의 상태를 표현하게 되는 것이다.

 

데이터베이스에 있는 데이터를 조작하기 위해 흔히 말하는 CRUD와 매칭되는 POST, GET, PUT, DELETE 4가지의 HTTP 메소드를 이용해서 서비스하는 것을 레벨 2단계라고 하는 것이다. 이렇게 HTTP 메소드를 이용해서 리소스의 상태를 구분해서 서비스하게 되면 비슷한 이름의 URI라 하더라도 HTTP 메소드에 따라서 다른 형태의 서비스를 제공할 수 있게 된다.

 

 

LEVEL 3

• Level2 + HATEOAS
• DATA + NEXT POSSIBLE ACTIONS

 

마지막 단계는 레벨 3단계는 레벨 2단계에 해테오스라는 기능을 같이 추가해서 연계하는 것을 이야기한다. 즉 데이터를 가지고 그 다음 작업에서 어떠한 액션을 할 수 있는지 같이 상태 정보를 넘겨주는 단계를 레벨 3단계라고 생각하면 된다.

 

데이터와 리소스를 적절한 상태로 표현하는 것을 레벨 2단계에서 이미 했다. 덧붙여  그 다음 작업으로 어떤 것을 할 수 있는지, 회원가입을 한 다음에 회원정보 수정은 어떻게 해야 하는지, 회원 전체 보기는 어떻게 해야 되는지, 전체 보기를 하면서 그 다음 단계로 진행할 수 있는 또 다른 리소스에 대한 정보는 어떤 것이 있는지 이러한 모든 정보를 같이 알려줄 수 이쓴 기능을 헤테오스 기능이라고 한다.

 

이렇게 되면 클라이언트 측에서는 서버가 제공하는 서비스를 일일이 찾는 수고를 겪지 않아도 된다. 최소한의 집입점이나 엔드포인트만 가지고 있으면 서버가 제공할 수 있는 다음 그 다음 URL 값을 알 수 있는 상태가 된다.

 

---

RESTful Web Service

- Consumer first

개발자 중심의 설계 방식 보다는 해당 API를 사용할 소비자 입장에서 간단명료하고 직관적인 API를 설계해야 된다는 점이다.  소비자라고 해서 꼭 엔드 유저를 의미하는 것이 아니라 해당 API를 사용하고 있는 또 다른 시스템이나 개발자를 의미한다.

 

- Make best use of HTTP

REST API를 설계함에 있어서 HTTP의 메소드와 Request · Response 타입,  Header 값 등과 같은 HTTP 장점을 최대한 살려서 개발하는 것이 필요하다.

 

- Request methods

• GET
• POST
• PUT
• DELETE

 

- Response Status

• 200
• 404
• 400
• 201
• 401

 

- No secure info in URI

제공하게될 URI에는 사용자의 비밀번호와 같은 크리티컬한 정보를 포함해서는 안된다. 안전한 인증이 필요한 API에 대해서는 추후 게시물에 Spring Security를 이용해서 토큰을 보완하는 방법을 고려할 수 있다.

 

- Use plurals

• prefer/users to /user
• prefer/users/1 to/user/1

 

제공하려는 데이터에 대해서 복수 형태로 쓰는 것이 일반적이라는 얘기이다. 단수 형태의 URI값이 아니라 복수 형태의 URI 값을 사용해서 제공할 것이다. 복수형의 URI안에 포함되어 있는 특정한 값을 지칭하기 위해서는 별도의 추가적인 엔드 포인트 의 리소스 요청 값을 전달하면된다. 

 

- User nouns fo resources

모든 리소스는 가능하면 명사 형태로 표시하는게 좋다. 동사 형태보다는 명사 형태로 표시를 해서 사용자한테 더 직관적으로 사용할 수 있도록 지원해주는 것이 좋다. API URI만 보면 파악할 수 있도록 제공해주는 것이 좋다.

 

- For exceptions

• define a consistent approach

/search

PUT /gists/{id}/star

DELETE /gists/{id}/star

 

일괄적인 엔드포인트를 사용하는 것이 좋다. 일괄적인 엔드포인트라는 것은 진입지점을 단일화 시켜주는 것도 포함되어 있다. 보통 이런 작업을 하기 위해서는 API Gateway를 사용해서 처리할 수 있다. 

 

---

 

각각의 서비스들은 ESB라는 엔터프라이즈 서비스 버스 ESB라는 곳에 모여지게 된다. Enterprise Service Bus라는 곳에 모여지게 된다. 이렇게 모여진 서비스들이 외부에 공개가 된다. 또 이러한 부분은 웹 서비스라는 기술을 통해서 개발이 될 것이고, 데이터베이스 자료를 정리하기 위해서 공통적인 로직, 데이터베이스 처리 로직, SOAP이라든가 HTTP 또는 JMS, JDBC 같은 기술을 같이 사용할 수 있다.

 

 

 

반면에 마이크로 서비스 아키텍쳐에서는 서로 분리된 서비스들을 독립적으로 자신의 개발 프로세스를 가지고 있다. 독립적인 언어,UI,비지니스 로직과 그리고 데이터베이스를 각각 서비스에 사용할 수 있도록 지원한다. 이런 서비스는 자신의 데이터를 외부에 공개할 때 REST API를 통새서 공개하는 것을 권장하고 이벤트 스트림과 같은 메시징 서비스를 이용해서 데이터를 동기화 할 수 있다.

 

[출처 - Spring Cloud로 개발하는 마이크로 서비스 애플리케이션, 저 Dowon Lee]

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4

Spring Cloud로 개발하는 마이크로서비스 애플리케이션(MSA) - 인프런 | 강의