Gateway 없이 서비스 분리

개요

기존 운영 중인 매장 관리 서비스는 단일 서버로 운영되고 있었지만, 요구사항이 증가함에 따라 서버의 부담이 점차 커지고 있었다.

이러한 상황에서 매장 관리 외에 새로운 도메인에 대한 기획이 추가되었고, 도메인 별 서비스 분리의 필요성을 느끼게 되었다.

때문에 본격적인 개발에 앞서, 우선 매장 관리 서비스를 분리하기로 결정하였다.

 

목표

1. 메인 서버 (매장 관리 도메인) 의 부담 경감
2. 클라이언트에게 단일 진입점 제공

 

상황

매장 관리 서비스를 운영 중인 기존 서버는 여유 자원이 부족해, 새로운 서버를 추가로 구동할 수밖에 없는 상황이었다.

그러나 비용적인 제약으로 인프라 변경이 불가능한, 어플리케이션 하나만 구동할 수 있는 수준의 서버를 임시로 확보하게 되었다.

이로 인해 별도의 게이트웨이 서버를 구성할 수 없었고, 결국 메인 서버(매장 관리 도메인)에서 모든 진입점을 통합해 제공할 수밖에 없었다.

 

접근

 

1.

첫 번째 고민은 클라이언트에게 전달 받은 요청을 어떻게 라우팅할 것인지였다.

가장 먼저 고려했던 방안은, 리버스 프록시를 활용하는 방법이었다.

Nginx 와 같은 리버스 프록시를 활용하면 보안 처리, 라우팅, 로드 밸런싱 등 요청 분산에 필요한 기능 등이 기본 제공 되며, 어플리케이션보다 앞단에서 요청을 처리함으로 얻는 속도나 안정성 측면의 이점이 있었다.

다만, 리버스 프록시를 도입하면 어플리케이션 이외의 관리 포인트가 증가되고, 아직 명확한 요구사항이 없는 현재 상황에서 이러한 복잡성은 유연성을 떨어트릴 수 있다 판단하였다.

때문에 모든 처리를 어플리케이션 내부에서 해결하는 방향으로 결정하였다.

 

2.

두 번째 고민은, 어플리케이션에 전달된 요청을 어떻게 처리하면 좋을까 였다.

가장 간단한 방법으로, 클라이언트 요청을 Redirect 를 통해 다른 서버로 직접 전달해주는 것이었다.

그러나 해당 방식은 클라이언트에 서버 정보가 노출 되고, 요청 형식에 제약이 있으며, 프론트엔드에서 리다이렉트를 거부할 수 있다는 등 여러 치명적인 단점이 있었다.

이러한 문제를 개선하기 위해 OpenFeign 등을 활용해 메인 서버가 다른 서버로 HTTP 요청을 전달하고, 그 결과를 클라이언트에 제공하는 방법 또한 고려하였다.

하지만 위의 두 방법 모두 메인 서버가 다른 서버의 정보를 모두 관리해야 하며, 연결 상태 확인(Health Check..) 등의 작업으로 추가적인 부담이 발생하게 되었다.

결과, 두 방식 모두 메인 서버의 책임과 부담을 증가 시킨다 판단하였고 때문에 채택하지 않기로 하였다.

 

해결

RabbitMQ 의 Request-Reply 를 활용해, 다른 서버로 요청을 전달하고 그 결과를 메인 서버가 클라이언트에 제공하기로 하였다.

이는 RabbitMQ 가 연결 정보를 관리해주어 서버 변동에도 유연하게 대응할 수 있고, 요청 실패 시 재처리를 지원하는 등 안정성이 증가된다는 이점이 있다.

또한, HTTP 방식과는 다르게 엔드포인트를 외부에 열지 않아 내부망 없이도 높은 보안성을 확보할 수 있고, RabbitMQ 의 기본 메세지 큐를 통해 메인 서버의 배치와 같은 비동기 작업을 분산 시킬 수 있다는 점 등의 이유로 최종적으로 도입하게 되었다.