API 게이트웨이의 이해 및 구현[1]

서론

요즘 웹 서비스는 마이크로서비스 아키텍처 형태로 서비스를 제공하는 경우가 많다. 여기서 말하는 마이크로서비스 아키텍쳐는 하나의 큰 어플리케이션을 여러 개의 작은 어플리케이션으로 나누어서 개발하는 방법을 말한다. 예를 들어 기존의 한 어플리케이션이 데이터 조회와 사용자커뮤티티 서비스를 제공하는 것(모놀리틱 아키텍쳐)에서 데이터 조회 서비스와 사용자 커뮤니티 서비스를 분리해서 개발하는 것이 마이크로서비스 아키텍처이다.

이렇게 마이크로서비스 아키텍쳐로 개발을 진행하게 되면 장점은 각 모듈은 제공하는 서비스가 서로 독립적이기 때문에 해당 모듈에 가장 잘맞는 프로그래밍 언어를 선택 할 수 있으며 모듈 별 배포를 따로 할 수 있으므로 전체 서비스를 내리지 않고도 배포를 할 수 있다. 예를 들어 모놀리틱 아키텍쳐에서 데이터 조회 기능을 수정 했지만 사용자 커뮤니티와 데이터 조회 기능 서비스가 하나의 어플리케이션이기 때문에 수정 하지 않은 사용자 커뮤니티 서비스도 같이 내렸다가 배포해야하지만 마이크로서비스 아키텍쳐에서는 단지 수정이 일어난 데이터 조회 API만 재배포를 하면 되기 때문에 배포의 부담을 덜 수 있다. 

문제는 이렇게 API들이 나눠지면 사용자 로그 및 API 호출 등 API들이 공통으로 가지는 로직들이 각 각의 API들이 구현을 해야하는 문제점이 있는데 이 문제점을 API GateWay를 사용하여 해결 할 수 있다. 이번 포스팅에서는 API Gate Way의 역할에 대해서 간단히 설명하고 실제로 구현을 해볼 생각이다.

API Gate Way를 구현하기 위해 사용하는 지식은 Netty + Spring + Akka 이렇게 3가지가 되겠다.

Spring에 대해서는 따로 설명하지 않겠으며 Netty에 대한 설명은 해당 블로그의 Push Server 구현하기 포스트에서 간략하게 설명하고 있다.

Akka에 대해서는 사용하는 시점에서 소스와 함께 설명을 할 생각이다. 또한 소스는 포스팅이 끝나는 시점에 GitHub에 올려 놓을 것이며 포스팅에서는 꼭 필요한 부분들의 소스만 명시한다. 소스를 보고 많은 문제점을 지적 해주시길 바란다.

API Gate Way 주요기능

1. 인증 및 인가에 관련된 기능

API Gate Way가 가져야 하는 가장 기본적인 기능은 인증 및 인가에 대한 처리를 하는 기능이다. 모놀리틱 아키텍쳐였다면 해당 어플리케이션에서 스프링 시큐리티, 또는 자체 구현한 필터 및 인터셉터로 인증 및 인가에 대한 처리를 할 수 있지만 마이크로서비스 아키텍쳐를 기반으로 나눠진 수 많은 API 각각마다 이런 구현을 하게 되면 엄청난 소스의 중복 및 유지보수에 악영향이 발생하게 된다.

그래서 인증 및 인가에 관련된 기능이 API Gate Way에 들어가게 되는 것이다. 보통은 API Gate Way는 클라이언트 인증 정보를 인증 서버에 다시 보내어 인증 결과를 받아오는 형식 이지만 추후에 진행할 구현에서는 인증 서버는 따로 만들지 않고 API Gate Way에서 처리할 생각이다.

2. 엔드포인트별 API 호출 인증

1번에서 진행된 인증에 의해 발급된 토큰을 가진 클라이언트는 서비스를 호출 하는 요청에 토큰 정보를 담아서 보내게 되고 이것을 받은 API Gate Way는 사용자의 호출 인가를 위해서 인증서버로 토큰정보에 대한 추가 정보를 받아 오게 된다.

그 후 추가 정보에 의해서 인가가 허용되면 API Gate Way 뒤에 있는 API들로 호출들을 흘려 보내게 된다.

3. API서버로의 로드 밸런싱

API Gate Way는 API 호출을 라우팅 할 수 있는 기능을 할 수 있다. 예를 들어 커뮤티니 서비스가 2개의 서버에서 돌아가고 있다 할 경우 비교적 작업량이 적은 서버로 호출을 흘려 보낼 수 있다. API 서버의 작업 정도의 정보는 주키퍼를 이용해서 관리 할 수 있을 것으로 보인다.

4. 공통 로직 처리

사용자 로그를 처리하는 로직과 같은 공통 로직을 API Gate Way에서 처리함으로써 공통 로직을 뒷단의 각 API마다 구현을 하지 않고도 사용 할 수 있다.

5. 프로토콜 변환

서비스 API가 웹브라우저와 직접 요청과 응답을 주고 받는 것이 아니기 때문에 http 프로토콜 이외의 프로토콜을 사용하더라고 API Gate Way에서 변환하여 호출 할 수 있다. 프로토콜 변환 관련은 Finagle을 사용할 수 있는 부분이다.

이 외에 많은 기능들을 하지만 1,2번 위주로 구현을 진행 할 것이기 때문에 여기까지만 설명을 하고 추가 정보를 얻고자 하는 분은 MSA 아키텍쳐 구현을 위한 API 게이트웨이의 이해 (API GATEWAY)를 봐주길 바란다.

API Gate Way위치는 아래의 그림과 같은 곳에서 위치하며 동작한다.

[그림1. API Gate Way의 위치]

API Gate Way 호출 Form 정의

API Gate Way는 여러개의 API를 자신이 직접 호출 하여 호출 결과를 모아 클라이언트에게 전송하게 된다. 그럼 클라이언트는 실질적으로 자신이 사용하는 데이터에 대한 정보를 제공하는 API를 호출 하는 것이 아니기 때문에 API Gate Way를 호출 할 때 어떤 형식으로 요청을 보내줘야 API Gate Way에서 해당 요청을 분석해서 뒷단의 API 서버들을 호출 할 지 결정하게 된다. 

[그림2. API Gate Way 호출을 위한 JSON Form]

위 그림과 같이 인증토큰과 관련된 내용이 JSON 구조 상 앞 단에 위치하여 API Gate Way로 들어가서 첫 요청 파싱이 토큰에 대한 유효성 판정이 이루어 질 수 있도록 한다. 다음으로 오는 내용들은 호출하고자 하는 API 유형이 무엇인지를 나타내는 apiType, api 호출 URL과 파라미터의 유무를 나타내는 값 그리고 API를 호출하는 파라미터가 있다면 그것에 대한 내용이 들어가게 된다. 

Netty를 이용한 Http Server만들기

API Gate Way는 웹브라우저 및 모바일과 직접적인 통신을 하는 서버로서 Http 통신규약을 지키는 서버가 되어야한다. 이것을 Netty를 이용해서 만들 수 있다. 먼저 스프링을 이용하기위한 Bean설정에 대한 소스를 보자.

package com.csp.gateway.config; import java.net.InetSocketAddress; import org.springframework.beans.factory.annotation.Value; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.ComponentScan; import org.springframework.context.annotation.Configuration; import org.springframework.context.annotation.PropertySource; import org.springframework.context.support.PropertySourcesPlaceholderConfigurer; @Configuration @ComponentScan("com.csp.gateway.*") @PropertySource("classpath:server.properties") public class APIGateWayConfig { @Value("${boss.thread.count}") private int bossThreadCount; @Value("${worker.thread.count}") private int workerThreadCount; @Value("${tcp.port}") private int tcpPort; public int getBossCount() { return bossThreadCount; } public int getWorkerCount() { return workerThreadCount; } public int getTcpPort() { return tcpPort; } @Bean(name="tcpSocketAddress") public InetSocketAddress tcpPort() { return new InetSocketAddress(tcpPort); } @Bean public static PropertySourcesPlaceholderConfigurer propertyPlaceholderConfigurer() { return new PropertySourcesPlaceholderConfigurer(); } }

dnl 위 소스는 스프링에 대한 지식이 있으면 쉽게 알 수 있는 소스이며 네티서버가 사용 할 Boss, Worker의 스레드 수와 포트 번호에 대한 설정을 하게 되는데 해당 설정 정보는 server.properties 파일에 존재 하게 된다.

server.properties파일에는 위에서 설명한 스레드 수와 포트 번호에 대한 정보 외에도 API Gate Way 뒷단에 존재하는 API 주소에 대한 정보도 관리하게 된다.

다음으로는 Netty 실질적인 Server가 되는 부분의 소스이다. 이 소스에 대한 설명은 생략하며 Push Server 구현하기 글을 참조하기 바란다.

package com.csp.gateway.server; import java.net.InetSocketAddress; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.beans.factory.annotation.Qualifier; import org.springframework.stereotype.Component; import com.csp.gateway.server.init.HttpServerInit; import io.netty.bootstrap.ServerBootstrap; import io.netty.channel.ChannelFuture; import io.netty.channel.EventLoopGroup; import io.netty.channel.nio.NioEventLoopGroup; import io.netty.channel.socket.nio.NioServerSocketChannel; @Component public class AGWServer { private static final Logger logger = LoggerFactory.getLogger(AGWServer.class); @Autowired @Qualifier("tcpSocketAddress") private InetSocketAddress port; public void start() { logger.info("Server boot"); EventLoopGroup bossGroup = new NioEventLoopGroup(1); EventLoopGroup workerGroup = new NioEventLoopGroup(); try { ServerBootstrap b = new ServerBootstrap(); b.group(bossGroup, workerGroup) .channel(NioServerSocketChannel.class) .childHandler(new HttpServerInit()); ChannelFuture future = b.bind(port).sync(); future.channel().closeFuture().sync(); }catch(InterruptedException e) { e.printStackTrace(); }finally{ bossGroup.shutdownGracefully(); workerGroup.shutdownGracefully(); } } }

이렇게 위와 같이만 한다고 해서 Http Server가 되는 것은 아니다. 35Line에 설정된 new HttpServerInit()에 대한 클래스를 구현하고 값으로 전달해줘야지만 Http Server로서 동작하게 되며 해주지 않게 된다면 시작과 동시에 종료가 되는 서버가 된다.

Http Server를 만드는 방법에 대해서는 위의 링크를 보고 이해하기 바라며 추가적인 소스 첨부는 하지 않겠다.

HttpServer 테스트

만들어진 서버를 테스트 하기 위해서 Postman이라는 어플리케이션을 사용한다. 내가 설정한 port번호가 2425이기 때문에 호출 주소는 http://localhost:2425가 된다. 아래는 테스트 결과의 이미지이다.

다음과 같이 서버에서 클라이언트 요청의 결과로 Hello Client라는 문구를 볼 수 있다.

 

결론

현대 프로그램은 하나의 서비스로 구성되지 않고 복합적인 서비스로서 하나의 총괄적인 서비스를 구성하게 된다. 그래서 이번 포스팅에서는 마이크로서비스 아키텍쳐에 대해서 간략하게 알아보았으며 마이크로서비스 아키텍쳐를 실현하기 위해 나눠진 많은 서비스들을 효율적으로 사용하기 위해서 API Gate Way라는 것을 사용하는데 사용하기에 앞서 API Gate Way가 무엇인지에 대해서 알아보았다. 

서비스 제공을 마이크로 아키텍쳐로 한다고 해서 API Gate Way의 사용이 강요적인것은 아니지만 좀더 좋은 소프트웨어 질을 위해서 사용하는 것이 좋아 보인다. 

또한 간단하게 Netty를 이용해서 Http 서버를 만들어서 테스트를 해보았다. 이후 포스팅할 클라이언트로 부터 전달 받은 요청을 어떻게 처리하는지에 대한 내용에 대해서 포스팅 하고자 한다.