MSA(Microservice Architecture)란?
느슨히 결합된 서비스의 모임으로 구조화하는 "서비스 지향 아키텍쳐(SOA)"스타일의 개발 기법이다.
여러가지 일을 수행하는 어플리케이션을 한 가지 일만 수행하는 작은 어플리케이션으로 나타내는 것이 마이크로서비스이다.
작은 어플리케이션으로 분해하게 되면 쉽게 교체할 수 있고, 독립적으로 개발되고 전개 할 수있다.
MSA를 구현 하게 되면 각 서비스간 통신 방법이 필요하게 되고,
서비스를 나눠 제공하기 때문에, 데이터 중복이 발생할 수 있고 정합성을 보장하기가 어려워진다.
하지만 유지보수성이 뛰어나고, 업무를 독립적으로 분할할 수 있는 장점이 존재하기 때문에 각 기업이나 개인이 사용한다.
MSA를 구현하는 방법 중 가장 대중적인 것이 넷플릭스에서 공개한 Netflix OSS(Open Source Software)이다.
출처 : https://dzone.com/articles/microservices-journey-from-netflix-oss-to-istio-se
Eureka
각각의 분해된 서비스들의 주소 집합체이다.
예를 들어 50개의 서비스가 서로 통신하고 있다고 가정해본다.
전체 서비스를 관리하기 위해선 50개의 도메인 또는 IP와 Port를 일일히 관리해줘야한다.
그리고 서비스 줄이거나 늘릴 때 수동으로 작성 및 관리를 해야하고,
서비스 장애가 났을 경우 수동으로 제외해야한다.
Eureka는 이런 서비스 목록들을 자동으로 관리를 해주게 된다.
분해된 서비스들은 기동할때 Eureka 서버에 자기 정보를 보내고,
일정 시간 동안 주기적으로 서버에게 heartbeat를 보내 자신이 살아있음을 알린다.
API Gateway와 Zuul
MSA의 장점은 서비스를 분리함에 따라 변경에 따른 영향도를 최소화하며 개발 및 배포하는 것이다.
하지만 여러 엔드포인트를 관리해야하고,
각 서비스의 공통적인 기능을 중복으로 개발 및 유지보수를 해야하는 문제가 있다.
API Gateway를 이용하면 통합적으로 엔드포인트와 REST API를 관리를 할 수 있다.
모든 클라이언트는 API Gateway로 요청을 전달하면 API Gateway가 해당하는 엔드포인트의 API로 연결시켜준다.
즉 API Gateway는 라우터 기능을 하면서,
엔드포인트 서버에 공통으로 필요한 인증, 접근 제어 등 공통적인 부분도 구현 가능하다.
Zuul은 Netflix OSS에서 제공하는 API Gateway 구현체라고 보면 된다.
Hystrix
분산환경을 구성하다보면 서비스가 다양한 이유로 언젠가 실패할 수 있다.
Hystrix는 분산 서비스 간의 상호 작용을 제어하는 데 도움이되는 라이브러리이다.
특징
- 다른 서비스의 실패에 따른 내 서비스의 지연 또는 실패를 방지(계단식 오류 방지)
- 분산 시스템의 복잡한 연쇄 실패 방지
- 빠르게 실패하고 빠르게 복구
- Fallback과 Gracefully degrade(완벽한 마무리)
- real-time에 유사한 모니터링과 알람
출처 : https://github.com/Netflix/Hystrix/wiki
동작 방식
어떠한 특정 서비스에서의 응답이 지연되어 정의된 임계값을 넘게 된다면,
기다리는 대신 사용자가 정의한 풀백(fallback) 메서드 실행하여 응답값을 클라이언트에게 전달하게 된다.
그리고 새롭게 들어오는 다음 request는 장애가 난 서비스에 컨택하지 않고
정의된 fallback 메서드를 즉시 실행하며,
장애가 복구되면 hystrix는 모니터링 하고 있다가 정상화된 서비스에 다시 연결시켜 준다.
Ribon
Ribon은 클라이언트에 탑재하는 Load Balancer이다.
시스템 부하 분산을 위해 L4 스위치등 하드웨어 장비를 통해 부하를 분산하게 되는데,
Ribon은 클라이언트 소프트웨어로 트래픽을 분산/제어 할수 있다.
L4 스위치등 하드웨어 장비로 로 부하 분산을 하게 되면 다음 그림과 같이 나타낼 수 있다.
하드웨어 장비를 사용하면 별도의 장비가 필요하여 비용이 많이 소모되어 유연성이 떨어진다.
Ribon으로 부하 분산을 하게되면 다음 그림과 같이 나타낼 수 있다.
개인적인 생각으로 Netflix OSS로 구현한 MSA는 유연하다는 것을 많이 느꼈다.
어느 하나의 서비스가 장애가 나더라도 다른 곳에서 동일한 서비스가 돌고 있고,
또 해당 장애로 연쇄 장애가 발생하지 않으니 유지보수가 굉장히 간편했다.
그리고 작은 단위로 분해하여 독립적인 서비스로 수행하다보니 어플리케이션이 가벼워짐은 느꼈다.
다만 로그를 검색하기가 다소 불편하다는 것 외에 아직 불편한 점을 찾지 못한것 같다.
참고
'개발 이야기 > 백엔드 이야기' 카테고리의 다른 글
| 암호화 알고리즘 종류 (0) | 2022.05.09 |
|---|---|
| REST API란? (0) | 2022.01.12 |