[MSA] 서비스 게이트웨이(gateway) 란

 

서비스 간의 횡단 관심사

마이크로서비스를 운영하다 보면 분산되어 있는 많은 서비스들 간의 공통된 기능을 수행해야 할 수 있다

공통기능

• 보안
• 로깅
• 등등

이러한 횡단 관심사를 서로 다른 각 서비스에 구현하는 것은 쉽지 않다.
이유는 도메인을 개발하느라 이러한 기능 구현을 잊을 수 있고 또는 일관되지 않게 구현하여 혼란을 초래할 수 있다.

또한, 모든 서비스가 이러한 관심사를 구현하기 위해 공통 프레임워크를 만들어 의존하게 한다면 강한 의존이 생겨 재컴파일과 재배포 없이 공통 코드 동작 변경이나 추가는 더욱 어려워 진다.

서비스 게이트웨이란?

이 문제를 해결하기 위해 횡단 관심사를 독립적으로 배치할 수 있고 , 아키텍처의 모든 마이크로서비스 호출에 대한 필터와 라우터 역할을 할 수 있는 서비스로 추상화해야 한다.

이러한 추상화된 서비스를 게이트웨이(gateway)라고 한다.

기존 서비스 소비자의 호출 방식

기존 서비스 호출자는 디스커버리나 직접 호출이나 전부 실제 물리 url 로 호출하는 방식으로 호출한다.

서비스 게이트웨이를 적용한 서비스 소비자의 호출 방식

서비스 게이트웨이는 애플리케이션 내 마이크로서비스를 호출하기 위해 유입되는 모든 트래픽의 게이트키퍼(gatekeeper) 역할을 한다.

서비스 게이트웨이가 있으면 서비스 호출자는 직접 해당 서비스를 호출하지 않고 서비스 게이트웨이를 호출한다는 의미이다.

서비스 게이트웨이가 하는 일

위 그림처럼 서비스 게이트웨이는 서비스와 호출자 그 사이의 중개자의 위치에 있다.


따라서, 서비스 개발자들의 횡단 관심사 (공통 관심사)를 따로 구현하지 않고 서비스 게이트웨이에 구현하여 중앙 정책 시행 지점(PEP, Policy Enforcement Point) 역할을 수행하게 할 수 있다.

서비스 게이트웨이에서 구현할 수 있는 횡단 관심사의 예

• 정적 라우팅
  서비스 게이트웨이는 단일 서비스 URL 과 API 경로로 모든 서비스를 호출한다.
  모든 서비스에 대해 하나의 서비스(게이트웨이) 엔드포인트만 알면 되므로 개발이 편하다.
• 동적 라우팅
  유입되는 서비스 요청을 검사하고 요청 데이터를 기반으로 호출자를 지능적 라우팅을
  수행할 수 있다.
• 인증과 인가
• 지표 수집과 로깅
  모든 서비스의 엔드 포인트이기 때문에 공통된 지표를 수집하기 위한 로깅을 처리할 수 있다 (API 처리율 ,지연시간, 등등등)

서비스 게이트웨이가 단일 장애 지점이나 잠재적 병목 지점은 아닐까?

잘못 설계된 게이트웨이는 단일 장애 지점과 병목점이 될 수 있다.

• 로드밸런서는 서비스 앞에 있을때 유용하다.
  로드밸런서를 여러 서비스 게이트웨이 인스턴스 앞에 두는 것은 적절한 설계이다.
  하지만 모든 서비스 인스턴스 앞에 로드밸런서를 두는 것은 병목점이 될 수 있다.
• 서비스 디스커버리를 사용한다면 클라이언트 측 로드밸런싱을 쓸 수 있지만 사용하지 않는다면 로드밸런서를 앞에 두는 것은 가장 일반적인 접근법이다.
• 서비스 게이트웨이를 무상태(stateless)로 작성하라
  서비스 게이트웨이에 상태를 지니게 하는것은 확장성을 제한할 수 있다.
• 서비스 게이트웨이를 가볍게 유지하라
  서비스 게이트웨이는 서비스를 호출할 때 병목점이 될 수 있다.
  복잡한 로직을 넣는것은 지양해라