Description
백엔드 개발자라고는 하나 미디어서버 개발이 내 주요 도메인이라 이쪽에 대해서 정석적인 방법에 대한 것은 전혀 모른다. 최근에 사이드프로젝트로 백엔드 개발을 하게 되어서 관련 작업 진행중에 배운 내용을 정리해보려고 한다.
MSA(Micro Service Architecture)가 주목받으면서 자연스럽게 API Gateway 에 대해서도 알려지게 되었다.
MSA 구조에 맞게 작은 기능단위의 Backend 서버가 만들어지게 된다고 가정해보자. RESTful API 를 제공을 통해 해당 서버의 기능을 동작시키게 될 것이다. A라는 기능을 담당하는 서버, B라는 기능을 담당하는 서버가 있고 이 기능을 가져다 쓰는 App이 있다면 App에서는 A기능을 위해 A의 endpoint 주소 (ex: example.com/api/v1/A/)와 B기능을 위해 B의 endpoint 주소 (ex: example.com/api/v1/B/)에 대한 정보가 있어야 한다. 또한 어떤 서버가 어떤 기능을 담당하는지에 대한 히스토리도 관리해야 하며 새로운 서버 C가 추가된다면 아주 더러운 상황이 발생하게 된다.
이럴때 모든 요청을 받아주는 무언가가 존재하고, 호출하는 쪽에서는 그냥 동일한 endpoint로 요청할 수 있다면 매우 편하고 구현이 간단해질 것이다.
이런 예시 상황 뿐만 아니라 인증, 모니터링, 라우팅, 속도 제한, 보안 등등을 API Gateway 에서 담당하여 동작하도록 만들 수 있다.
Prerequisite
개인적으로 진행하는 프로젝트들의 지원을 위한 Backend 서버가 필요하다. 대부분 인증과 인증을 통한 계정 관리, 인증받은 사용자의 세션 관리와 Backend service 지원이 공통적으로 필요했기 때문에 상대적으로 Minimal 한 기능을 지원하는 API Gateway 를 구현하기로 했다.
이 프로젝트에서 지원할 기능은 아래와 같다.
- 인증
- OAuth2.0 인증
- 회원가입
- 인증 사용자 세션 관리
- Routing
- Backend service 라우팅
1. Framework 선택
RESTful API 를 지원하기 위해 echo 라는 프레임워크를 사용하기로 결정했다. echo는 토이프로젝트로 몇 번 사용경험이 있어 익숙하며 star도 꽤 많고 성능도 괜찮은 golang web framework 이다.
2. OAuth
oauth2.0 지원을 위해 oauth2 를 사용할 예정이다.
3. Service Discovery
MSA 구조답게 Scale in/out 이 빈번하게 일어나는 상황을 상정해야한다. API Gateway 뒷단에 붙을 Backend service 를 알아내기 위하여 consul 을 사용할 것이다.
