Gateway 는 어떤 일을 하는가

서비스의 초기 단계에서는 단순하게 Cient가 Server에 직접 요청을 보내도 큰 문제가 없습니다. 하지만 점차 서비스가 성장하고 그에 따라 서버도 커지면서 문제가 발생합니다.

각 서비스에서 공통적으로 처리해야하는 로직이 있다면 어떻게 해야할까요?

예를 들어, 권한과 관련된 로직이 있다고 해봅시다.

A Server로 요청이 들어오면, A Server에서 권한이 있는지를 확인합니다. 그리고 B, C Server도 마찬가지입니다.

A,B,C 각 서버로 가는 단일 요청에 대해서는 아무 문제가 없지만, A,B,C 를 동시에 처리해야하는 요청이 들어온다면 이미 권한이 있는 사용자를 다시 확인하는 꼴이 됩니다.

이런 비효율을 Gateway를 통해서 해결할 수 있습니다.

Gateway

Client가 Server로 바로 API Call을 하는 것이 아니라 중간에 Gateway라는 서버를 두는 것입니다. Gateway가 각 요청들에 대해서 필요한 공통 로직을 수행하고, 뒤에 있는 서버들로 요청을 전달해주는 것이죠. 

위의 예시라면, 게이트웨이가 들어온 요청에 대해서 권한이 있는지 없는지를 확인하고 뒤의 서버로 요청을 전달하면 되겠네요.

Gateway는 요청이 오면 정의된 설정에 따라 요청을 라우팅하는 서버라고 보면 되는데, 라우팅 하기전에 설정된 로직들을 실행합니다. "이 API는 이 로직을 통과해야만 진행할 수 있어" 라고 명시해두는 것이죠. 

그렇게 Gateway를 구성하고 서버가 많아지면, Gateway도 서버인지라 로직이 많아지면 많아질수록 복잡해집니다. 모든 서버에 대한 의존성이 존재하게 됩니다. 각 서버에서 필요한 것들이 모두 들어있다보니 관리하기가 어렵습니다. 따라서 이를 관리하기 위한 패턴들이 존재합니다. 

하지만 이 글에서는 BFF라는 패턴만 소개하려고 합니다.

BFF (Backend For Frontend)

BFF는 클라이언트 별 관심사를 분리하고 클라이언트에 맞는 전략을 가져가도록 Gateway를 분리한 것입니다. 예를 들어, Web Gateway, Mobile Gateway로 분리하는 것이죠. Web 과 Mobile은 가져야할 정책이 다르기 때문에 굳이 같이 있을 필요도 없고, 차라리 분리하는 것이 관리에 용이합니다.

이런 식으로 Web, Gateway를 분리하거나 아니면 마이크로 프론트엔드라면 단일 웹을 위한 BFF를 구성할 수도 있을 것입니다.

Gateway가 하는 역할

Gateway는 위에서 말한 것뿐만 아니라 다양한 역할을 할 수 있습니다. 

Gateway에 요청이 들어오면 가장 먼저 해야하는 것은 Request를 올바른 값인지 확인하는 것입니다. 이 로직을 통해서 악의적인 값들을 필터링하고 서비스에서 필요한 요청을 만들 수 있습니다. 예를 들어, 모니터링을 하기 위한 아이디값을 하나 만들어서 다음 요청에 담아서 보낼 수 있습니다.

그리고 하나의 비지니스 로직에서 공통적인 중복 로직을 줄일 수도 있습니다. 위에서 말한 Auth Check 예시처럼 서버 리소스를 아끼는 방법입니다. Auth Check를 하면서 필요한 정보를 확인하고, 헤더에 넣어준다면 뒤에서 추가적인 리소스를 쓰지 않아도 됩니다. 이런 예시로는 또 사용자 정보가 있겠네요. 뒤에서 유저에 대한 정보를 구해야하는 과정이 여러개 있다면 Gateway가 먼저 구해서 헤더에 추가해주면 비효율을 줄일 수 있습니다.