Micro Service Pattern - API Gateway
service1,2,3가 전부 사용되는 데이터가 필요해지면 각각의 서비스를 호출해야해서 총 6번의 호출과 반환이 이루어지는데 각각의 결과 값을 기다려야한다. 여기서의 문제점은 service1,2,3 각각의 주소를 알아야하는 단점이 있다.
위의 상황은 Application과 service사이에 API gatway를 두어서, 요청을 동시에 service1,2,3에 보낸 후, 데이터를 취합하여 다시 클라이언트로 보낸다. API Gateway를 두어서 하나의 api point만 알아도 되는 이점이 있다.
- 마이크로 소프트 공식문저 중 -
API Gateway 이점
- 클라이언트와 서비스가 분리된다. 모든 클라이언트를 업데이트 하지 않고도 서비스 버전을 관리하거나 서비스를 리팩토링할 수 있다.
- 서비스가 웹 우호적이 아닌 *AMQP(Advanced Mwssage Queuing Protocol) 등의 메시징 프로토콜을 사용할 수 있다.
- API 게이트웨는 인증, 로깅 SSL 종료, 부하 분산 등의 다른 교차 기능을 수핼할 수 있다.
- 제한, 캐싱 변환 또는 유효성 검사와 같은 즉시 사용 가능한 정책이다.
*AMQP: 메시지 지향 미들 웨어를 위한 개방형 표준 응용 계층 프로토콜.
Micro Service Pattern - Service discovery
탄생배경
클라우드를 사용할 경우, auto scaling에 따라 service instance가 유동적으로 변하며 IP 주소가 계속 바뀌게 되며, 이데 대한 정보를 취득할 수 있는 방법일 필요해진다.
클라이언트나 API 게이트웨이가 호출할 서비스를 찾아주는 메커니즘이 필요하게 되었다.
이를 Client-Side/Server-Side Discovery Pattern을 적용하면 해결이 가능하다.
MSA와 같은 분산 환경은 서비스 간의 원격 호출로 구성된다. 원격 서비스 호출은 IP 주소와 포트를 이용하는 방식으로 클라우드 환경이 되면서 서비스가 오토 스케일링 등에 의해서 동적으로 생성되거나
컨테이너 기반의 배포로 인해서, 서비스의 IP가 동적으로 변경되는 일의 빈도가 늘어난다.
Service A의 인스턴스들이 생성될때, Service A에 대한 주소를 Servie registry(서비스 등록 서버)에 등록해놓는다. Service A를 호출하고자 하는 클라이언트는 Service registry에 Service A의 주소를 물어보고 등록된 주소를 받아서 그 주소로 서비스를 호출한다.
- Service discovery 기능을 구현하는 방법으로는 크게 Client discovery방식과 Server side discovery 방식이 있다. Service Client가 Service registry에서 서비스의 위치를 찾아서 호출하는 방식을 Client side dicovery이다.
- 호출이 되는 서비스 앞에 일종의 proxy서버(로드밸런서)를 넣는 방식인데, 서비스 클라이언트는 이 로드 밸런서를 호출하면 로드밸런서가 Service registry로 부터 등록된 서비스의 위치를 리턴하고, 이를 기반으로 라우팅 하는 방식이다.
Micro Service Pattern - Service Mesh
서비스 간의 전체 연결 구조를 파악하기 어려우며 이로 인해서 장애가 났을 경우, 어느 서비스에 장애가 났는지 추적에 대한 어려움이 생긴다. 또한, 특정 서비스의 장애가 다른 서비스에 영향을 주는 문제들을 겪을 수 있다.
앞의 문제와 같은 장애 전파의 예는 써킷 브레이커(Circit breaker)라는 디자인 패턴으로 해결할 수 있다.
Reference.