두벅스 프로젝트 내에서 여러 서비스가 확장될 것을 고려하여 ‘사용자’ 와 관련된 기능은 별도의 서버로 분리하였다. 욜로가 서비스 외에 또 다른 서비스(ex. 절루가, 일루가 등) 가 확장되더라도 동일한 사용자 정보를 사용하여, 사용자는 단 한번의 회원가입으로 두벅스의 모든 서비스를 이용할 수 있다. 두벅스 내 욜로가 서비스의 서버 구조는 다음과 같다.
하지만 이는 오히려 서비스 확장의 어려움을 발생시킨다. 이후에 추가될 서비스에서 필요한 사용자 정보가 욜로가 서비스와 완전히 동일한지는 서비스가 기획이 되어야 알 수 있는 문제이다. 따라서 ‘사용자’ 서버가 아닌 초기에 기획했던 ‘인증’ 파트만을 분리하여 서비스의 확장성을 높이려고 한다. 하지만 이미 완성되어 있는 API 의 대부분을 변경해야 하는 문제가 발생한다.
Client 에서는 이미 사용자에 대한 기능 구현이 완성된 상태이다. Client 에서 사용자 기능을 이용하려면 두벅스 서버에게 API 를 요청한다. 사용자 기능에 대한 역할을 욜로가 서버에게 위임한다면 이를 이미 사용하고 있는 Client 는 사용자와 관련된 API 요청 파트의 대부분을 수정해야 한다.
이러한 문제는 왜 발생했을까? 결국은 욜로가 서비스를 이용하는 것인데 Client 에서 바라보는 서버가 여러 개로 분산되어 있기 때문이다. API 스펙이란 Client 에서 서버의 동작을 온전히 알지 않고도 서버에서 제공하는 기능을 이용할 수 있도록 최소한의 규칙을 정의하는데, Client 에서 접근할 수 있는 Endpoint 가 2개(서버가 확장된다면 그 이상)이기 때문에 확장성이 오히려 떨어진다. 따라서 Client 에서 접근하는 경로는 하나로 통일시키려고 한다.
이전 서버 구조에서 문제였던, Client 에서 관리하는 서버의 정보가 많아 변경에 취약하던 것을 해결하려면 인증 서버를 서비스 서버 뒤로 숨기면 된다.
하지만 만약 욜로가 서비스 자체가 확장된다면? 이전과 동일한 문제가 발생하게 된다.
결국 이를 해결하기 위해서 별도의 네비게이터 역할을 하는 서버가 필요하다. 즉, Client 는 API Gateway 에게 요청을 보내면 서버 내부적으로 원하는 서비스에게 요청을 보낸다.
이러한 구조는 다음과 같은 장점이 있다.
마지막으로, 인증 과정은 실제 비즈니스 로직이 수행되기 전에 거쳐가는 과정이다. 만약 ‘API Gateway → Service → 인증 서버’ 순으로 검증이 수행된다면 인증이 필요한 모든 Service 에서 인증 서버에게 API 요청을 보내는 파트가 중복된다. 따라서 다음과 같이 요청 순서도 조정한다.
설계 시에는 확장성을 고려하여 욜로가 서비스 인스턴스를 분리했지만, 실제로 수행하는 로직이 매우 간단하여 굳이 서버를 분리할 필요가 없다. 최종적으로 설계된 서버 구조는 다음과 같다.