나는 2년 정도 자바로 외도(?)를 하다 왔다보니, 자바 생태계의 패키지나 프레임 워크를 접하고 사용해보게 되었었는데, 그 중 API Gateway 및 서비스 구성 관리용 4종 세트인 Netflix Zuul, Hystrix, Ribbon, Eureka를 사용하게 됐었다.
그러던 중 다시 게임 개발을 하게 되면서, C#으로 모든 서버군을 구축하게 되었는데, 이 와중에 API Gateway를 찾아보게 되었고, 그다지 어렵지 않게 ocelot의 존재를 알아낼 수 있었다.
MS Docs/Ocelot을 사용하여 API 게이트웨이 구현
MS의 공식 문서에서 소개 될 만큼, ASP.NET CORE의 대표적 API Gateway지만, 그렇다고 공식은 아니다보니 버전 지원이 조금 늦는 아쉬움은 있더라. (.NET CORE 3.0과 ASP.NET CORE의 3.0 베타 기간에는 지원되지 않다가, 정식버전 출시 이후 한달 무렵 지나서 호환되었다)
여러 방면에서 사용해본 결과 꽤나 다른 접근과 구현을 만나볼 수 있었다.
주요한 차이점은 Filter와 Middleware의 관계다.
Zuul 사용시에는 Filter에서 LB로서의 역할 부여가 가능하다.
애초에 Custom Filter와, Routing Filter가 존재하는 것 자체가 그런 의미를 내포한다고 볼 수 있고 말이다.
반면 Ocelot은 Filter에 당하는 작업을 Middleware 레이어에서 담당하게 했는데, 이 레이어에서는 Routing에 대한 조작을 할 수 없다.
Ocelot/Middleware Injection and Overrides
- PreErrorResponderMiddleware - Already explained above.
- PreAuthenticationMiddleware - This allows the user to run pre authentication logic and then call Ocelot’s authentication middleware.
- AuthenticationMiddleware - This overrides Ocelots authentication middleware.
- PreAuthorisationMiddleware - This allows the user to run pre authorisation logic and then call Ocelot’s authorisation middleware.
- AuthorisationMiddleware - This overrides Ocelots authorisation middleware.
- PreQueryStringBuilderMiddleware - This allows the user to manipulate the query string on the http request before it is passed to Ocelots request creator.
그 어떤 Middleware도 Routing을 수정할 수 없는 역할만 가지고 있고, 실제로 불가능하다.
LB의 역할은 LoadBalancer 설정을 통해 이용할 수 있으나, Custom LoadBalancer를 구현해서 규칙에 맞게 별도의 서비스로 구성하고 연동하는 기능은 제공하지 않는다.
- LeastConnection - tracks which services are dealing with requests and sends new requests to service with least existing requests. The algorythm state is not distributed across a cluster of Ocelot’s.
- RoundRobin - loops through available services and sends requests. The algorythm state is not distributed across a cluster of Ocelot’s.
- NoLoadBalancer - takes the first available service from config or service discovery.
- CookieStickySessions - uses a cookie to stick all requests to a specific server. More info below.
NoLoadBalancer 옵션을 통해 Service Discovery에 위임만 가능하다.
무언가 방법이 있을거 같아 문서를 여러 방면으로 찾아봤으나, 원하는 내용을 못찾고, 결국 ocelot 코드를 직접 열어 방법을 검토했다.
Custom LoadBalancer를 Middleware로 구현해, 목적지를 변경하는 방식으로 처리하면 되더라.
이 Netfilx Zuul과 부분에서 많은 차이가 있었는데, Routing Filter를 직접 제공해주며 목적지를 동적 결정하게 해주는 Zuul과, 이를 제공해주지 않는 Ocelot은 이외에도 꽤나 큰 차이를 보여준다.
QoS도 ReRoute 단위로만 회로 차단 (Circuit Breaker)를 지원하는데, 이는 전반적으로 Service Provider를 잘 조합해서 사용하고 제공 되는 기능의 옵션 중에서 선택하길 바라는 접근으로 보여진다.
반면 애초에 Netflix Zuul은 직접 필요에 따라, 서비스마다 다른 요구사항을 충족 시키면서 운용하던 라이브러리이다보니, 커스터마이징에 열려있는 것이 아닐까 짐작해본다.
이외에도 쿠버네티스를 Service Discovery Provider로 지원해주는 등, .NET 진영 사용자 들의 필요에 따라 발전하고 있고 그 속도는 빠른편에 속한다.
사실 .NET CORE 기반의 API Gateway중에선 딱히 다른 대안이 없는 것은 사실이다. 하지만 API Gateway는 굳이 실 서비스들의 구현 언어와 상관없이 선택할 수도 있기 때문에 여러가지 선택지가 있다고 봐도 될 것이다. (물론 언어를 일치 시키면 여러가지 장점이 있다는 점도 외면할 수는 없다)
그럼에도 Ocelot 역시 지원되는 Features들만 봐도 대부분의 기능을 제공하고 있고, 많은 contributor들과 함께 잘 성장하고 있으며, 그 완성도와 기능, 편의성을 꼭 한번 알리고 싶었다.
C#의 언어적 우수성에 대해 감탄하고 있다면, ASP NET CORE와 함께 Ocelot을 선택해 시스템을 구축해 보는 것은 어떨까? 당연히, 나는 이미 그렇게 하고 있기 때문에 강력히 추천한다.