본문 바로가기

개발자는 알아야될 지식

마이크로 서비스란?

마이크로 서비스란?

: 마이크로서비스는 소프트웨어가 잘 정의된 API를 통해 통신하는 소규모의 독립적인 서비스로 구성되어 있는 경우의 소프트웨어 개발을 위한 아키텍처 및 조직적 접근 방식입니다. 참고 : https://aws.amazon.com/ko/microservices/

 

  모놀로식 아키텍처 마이크로서비스 아키텍처
 

장점 - End-to-End 테스트가 용이 (MSA 경우 테스트에 필요한 서비스들을 모두 동작시켜야함)
- 빠르게 간단한 서비스를 만들 수 있다 (환경이 같아서)
- 쉽게 고가용성 서버 환경을 만들 수 있다 (같은 어플리케이션으로 하나 더 만들면 된다)
- 유지보수 용이(일부분의 오류만 수정 가능)
- 거대한 서비스도 빠르게 수정 가능하다
- 각 기능에 따라 다른 언어를 선택할 수 있음
- 새롭게 추가되거나 수정사항이 있는 마이크로서비스만 빠르게 빌드, 배포가 가능하다
단점 - 작은 수정사항이 있어도 전체 빌드, 배포
- 유지보수 어려움
- 사이즈가 커지면 구동 시간이 늘어남
- 일부분의 오류로 전체 영향
- 각 기능에 따라 다른 언어 선택 불가능
- 작은 서비스가 분산되어있어 모니터링이 힘듦
- 서로를 호출하여 전체 서비스가 이루어지므로 무조건 다른 서비스를 호출하는 코드가 필요하여 까다롭다
- 통신관련 오류가 잦을 수 있다
- 테스트가 불편하다. End-to-End 테스트를 위해 UI, Gateway 등등 여러개의 마이크로 서비스를 구동시켜야 한다

 

마이크로서비스 통신 패턴

Synchronous Solution Asychronous Messaging

- 동기적
- Rest API 를 사용
- 서비스 A 에서 서비스 B로 직접 요청
- 동기적이여서 응답을 기다림
- 비동기적
- RabbitMQ 와 Apache Kafka를 사용
- 서비스 A 에서 서비스 B로 Message Broker 를 사용하여 메세지를 보냄 
- 비동기여서 서비스 A는 응답을 기다리지 않음
- 서비스 B는 일반적으로 동일한 메세징 시스템을 통해 결과를 사용할 수 있을 때(결과가 예상되는 경우) 결과를 보냄

* Synchronous Solution 문제점 

- A, B 서비스 중 하나가 오프라인 상태라면 데이터는 사라진다.

  • 요청, 응답이 끊어지면 어딘가에 저장을하고 나중에 다시 시도해야 되는 거 아닌가?
  • 만약 다시 시도한다면 언제 다시 시도를 해주지?
  • 얼마나 자주 시도해야 되지?

- A의 요청 후 응답을 기다리는 동안 시간이 오래 걸린다면? 그리고 실패한다면?

 

이러한 문제점 때문에 보통 Asychronous Messaging를 사용한다.