오늘은 API Gateway와 Service Discovery에 대해 고민했던 점을 기록해보자.

📘 API Gateway란?

API 게이트웨이는 API서버 앞단에서 모든 API 서버들의 엔드포인트를 단일화하여 묶어주고 API에 대한 인증과 인가 기능에서 부터 메세지에 따라서 여러 서버로 라우팅 하는 고급기능까지 많은 기능을 담당할 수 있다.

MSA에서 여러 마이크로 서비스를 호출하기 위해 하나로 묶어 요청을 보내도록 하는 것인데 많은 기업들의 사례에서 API Gateway를 사용하고 있다.
과거 많이 사용하던 Netflix의 zuul, Spring에서 제공하는 Gateway, AWS 등등 여러 방안을 살펴보았다.
우리도 API Gateway를 도입하는 방향으로 생각을 하였는데 이 때 그런 생각이 들었다.

"API Gateway를 두고 통신을 하게 되면 장애 발생 시 전면 장애가 다시 일어날 수 있는 것이 아닌가?? 전면 장애를 예방하려고 MSA를 고려하였는데 전면 장애를 위한 포인트가 하나가 더 생긴 것이 아닐까??"

라는 생각이다.
현재 우리는 WS가 nginx로 구성이 되어 있는데 웹 서버에서도 API Gateway의 기능을 충분히 할 수 있다는 것을 알았다.
라우팅, 로드 밸런싱 등등 여러 기능을 말이다. 또한 우리는 내부망에서만 사용할 목적이여서 인증/인가에서도 JWT토큰과 같은 방식을 고려하지도 않았고 크게 신경쓰고 있지 않았기에 이미 사용중인 nginx로 API Gateway의 역할을 대신하기로 하였다. 이렇게 하면 굳이 장애 포인트를 하나 더 고려하지 않아도 MSA에 있어서 크게 문제 될거 같지 않아 보였다.

API Gateway와 함께 고려했던 것은 Service Discovey였다.

📘 Service Discovery란?

MSA로 구성되어 있는 서비스들은 각자 다른 IP와 Port를 가지고 있다.
이러한 서로 다른 서비스들의 IP와 Port 정보에 대해서 저장하고 관리할 필요가 있는데 이것을 Service Discovery라고 한다.

Service Discovery도 고민을 많이 했었다. 이것도 API Gateway처럼 Netflix, AWS, Spring Service Discovery등 각각 비교하며 어떤 것이 좋을지 테스트하고 조사했었다.

하지만 우리 회사의 솔루션과 운영적인 측면을 보면 새로운 기능과 서비스를 추가할 것이 딱히 없어 보였고 다들 특별한 일이 아닌 이상 확장은 없을 것이라고 판단하고 있었기에 서비스가 계속적으로 추가되고 없어지고 이러한 유동성이 있어보이지는 않았다.
따라서 IP와 Port가 계속 변하고 생기고 없어질 것이라 생각하지 않았기에 Service Discovery도 사용을 하지 않기로 하였다.