마이크로서비스를 이용한 쇼핑몰 구축하기 - 2

Section1. 마이크로서비스에 대한 기본적인 아이디어

1. 마이크로서비스란?

 

단일체 서버에서는 어플리케이션 작동에 필요한 모든 기능이 하나의 서버에 들어가있다.

그에반해, 마이크로서비스는 '하나의 기능'에 필요한 미들웨어, 라우터, 데이터베이스로 구성된 '여러개의 서비스'

로 구성되어 있다.

 

 

각각의 서비스들은 독립적으로 작동되고, 작동하기 위해서 다른 서비스에 의존하지 않는다.

 

2. 마이크로서비스의 데이터 관리

 

우선, 마이크로서비스의 데이터 관리 규칙, Database-Per-Service를 알아보자.

 

• 마이크로서비스는 각각 자신의 데이터베이스를 가진다(데이터베이스를 필요로하는 서비스일 때).
• 각각의 서비스들은 다른 서비스의 데이터베이스에 절대로 접근하지 않는다.

-> 왜 이렇게 만드는걸까?

 

• 이유1:  각각의 서비스를 '독립적으로' 운영하기 위해서. 어플리케이션이 하나의 데이터베이스만 사용할 때, 만약 그 데이터베이스에 문제가 생긴다면 전체 어플리케이션이 고장나게 된다. 각각의 데이터베이스를 공유하는 경우에도 비슷한 문제가 생긴다. 또한 데이터베이스의 크기도 매우 커서 관리하기 어려워진다.
• 이유2: 데이터베이스의 스키마,구조가 예상치못하게 변경될 수 있는데, 이것을 알아차리지 못할 수 있다.
• 이유3: 서로 다른종류의 데이터베이스를 사용하는것이 더 효율적이라서 (SQL vs noSQL)

3. 마이크로서비스에서 데이터를 다룰 때의 큰 문제점

마이크로서비스에서는 데이터를 다루는것이 복잡해진다. 이유는 아래의 그림을 참고해보자.

 

 

위의 쇼핑몰 사이트에서 서비스 A, 서비스 B, 서비스 C가 각각 마이크로서비스로, 독립적인 데이터베이스를 사용해서 운영되고 있다고 하자. 

특정 사용자의 주문 내역을 보여주는 서비스 D를 새로 만드려고 할 때, 서비스 D는 사용자 정보, 상품정보, 주문정보를 가져와야 한다. 

그러나, 다른 서비스의 DB에 접근하는것은 규칙 상 불가능하므로, 다른 방법을 찾아야 한다!

 

4. 서비스 간의 동기 커뮤니케이션

 

<서비스들 간의 커뮤니케이션 전략>

이 문제를 해결하는 방법으로, 동기와 비동기 커뮤니케이션 전략이 있다.

여기서의 동기, 비동기는 자바스크립트에서의 동기, 비동기와는 다른 의미를 가진다!

 

• 동기(Sync): 서비스들 간의 커뮤니케이션이 직접적인 요청(request)에 의해 이루어진다
• 비동기(Async): 서비스들 간의 커뮤니케이션이 이벤트(event)에 의해 이루어진다

 

<동기 커뮤니케이션 전략>

 

 

동기 커뮤니케이션 전략에서는 그림과 같이 서비스 D가 각각의 서비스들에 '요청'을 보낸다. (HTTP 리퀘스트 혹은 다른 방법을 통해서). 이 경우, 서비스 D가 다른 서비스의 DB에 '직접' 접근한 것은 아니므로, 규칙에 위배되지 않는다.

 

<동기 커뮤니케이션의 장점>

• 개념적으로 이해하기 쉽다
• 서비스D는 데이터베이스를 필요로하지 않는다

<동기 커뮤니케이션의 단점>

• 서비스 간에 의존적인 관계가 형성된다. 서비스A, B, C중 문제가 생기면 서비스 D에도 문제가 생긴다.
• 서비스 D가 보낸 요청 중 시간이 오래걸리는 처리가 있다면, 그 만큼 서비스D의 처리도 늦어지게 된다. 

5. 이벤트 기반 커뮤니케이션

비동기 커뮤니케이션 전략에는 2가지 방법이 있다.

 

<첫번째 방법>

... 생략

 

<두 번째 방법>

비동기 커뮤니케이션의 두 번째 방법이 실제로 사용할 데이터 관리 방법이다!

아래의 사진에는 회원가입 요청을 처리하고, 서비스 D의 DB까지 업테이드 하는 과정이 담겨있다.

1. 회원가입 요청이 들어오면 서비스 A는 요청을 처리하고, A의 DB에 새로운 User를 등록한다. 
2. 그와 동시에 새로운 이벤트를 생성해서 Event Bus라는 곳으로 보낸다. 
3. 서비스D가 Event Bus로부터 받은 이벤트를 바탕으로 서비스 D의 DB를 업데이트 한다.

6. 비동기 커뮤니케이션의 장단점

<장점>

• 서비스D는 다른서비스들에 전혀 의존하지 않는다. 서비스 A, B, C가 고장나더라도 서비스D는 잘 작동한다!
• 서비스D의 성능이 매우 좋아진다

<단점>

• 데이터가 중복되서 저장된다. 따라서, DB저장소비용이 더 많이든다
• 작동방식을 이해하기 어렵다

-> 사실 DB저장소 비용은 그렇게 비싸지 않기 때문에, 이 단점은 고려하지 않아도 된다.