마이크로 서비스란?
: 마이크로서비스는 소프트웨어가 잘 정의된 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를 사용한다.