오늘은 예전에 네트워크 구축 및 도메인 등등을 만들다가 알게된 Api Gateway에 대해서 공부한 내용을 정리하려고 한다.
내가 직면한 문제는 아래와 같다
- 서버(개발, 운영) 에서 추가 IP 및 도메인 변경 등등의 문제로 협업 업체와의 통신 규칙 추가
- 신규 기능 개발(API) 서버의 리소스가 부족한경우 다른 서버에 API서버를 돌려야하는데 그때 마다 통신규칙 및 방화벽 추가
- 개발과 운영 서버의 도메인 통합 ex) https://dev.jinhoserver.com/{proxy}, https://prod.jinhoserver.com/{proxy}
서비스하는 서버에서 다른 협업하는 업체와의 테스트 및 운영을위해 도메인 및 IP로 통신하는데 개발서버의 IP가 바뀐다거나, 운영하는서버가 더 늘어날때마다 방화벽 및 보안규칙을 새롭게 등록하는데에 많은 공수와 시간이 드는것을 해결하고자 한다.
신규 API기능을 추가할때 서버마다의 특성을 고려하여 route규칙으로 새롭게 blueprint하여 코드 및 소스의 특성을 정리하고자 한다.
처음엔 그냥 EC2에 Kong이라는 docker images로 된 api gateway를 사용하려고 했으나, 이거를 사용하여 또다른 서버의 리소스를 낭비하는것이 맞는가, 또한 관리나 유지보수에 대한 공수가 많이 들것으로 예상하였다.
그리고 사용하지 않는 가장 큰 이유는 , 개발과 운영 서버의 도메인 통합 ex) dev.jinho.com, prod.jinho.com 등으로 한번에 관리할수가 없었기 때문이다.
물론 GUI또한 웹페이지로 바로 보여서 간단하고 누구나 사용할 수 있지만, 추후에 docker image 버전이나,, 등등을 감당하기 어려울 것 같다.
작업 순서
1.Api Gateway 생성
2.Resource, Method 생성
3.proxy 설정 및 예제 서버 코드 작성
4.배포
5.도메인 연결
API GATEWAY 작업 시작
AWS에 들어와 검색창에 api gateway를치면 아래와 같이 나온다.
우측 상단에 보이는 create Api를 클릭하자
우리는 3번째에 있는 REST API 를 빌드한다.
1. 만약 Python Fast Api 를 사용한다면, 자동으로 swagger 가 만들어지니 그걸 import 해서 사용하면 조금더 편리하고 빠르게 만들어 낼 수 있다.
나는 flask 를 사용하여 만들예정이라 new api를 선택했다.
2. Api gateway 이름과 앤드포인트를 설정하면되는데, 여기서는 나는 Seoul region안에 있는 ec2로 정할 거라서 regional을 선택한다.
만약 private 으로 설정한다면 내가 생성한 특정 vpc id정보를 쓰면 거기로만 통신할 수 있게 만들수 있다.
- Create Method는 [delete,post,get,...] 등등등 생성할수 있다. url prefix는 현재 아무것도 없다.
- Create Resource를 클릭하면 아래와 같다.
proxt resource 를 체크 하면 https://jinhoserver.com/{proxy}로 생성되게 되는데,
이렇게 된다면 , / 뒤에오는 모든것이 동적으로 변경이 가능하게 된다. 변수를 일일히 설정할 필요가 없이, endpoint에서 받아낼수 있다.
나는 proxy는 그 뒤에서 설정하고 여기서는 운영과 개발 두가지로 나누겠다.
아래 보이는 Enable Api gateway Cors 는 웹에서 받아낼때 cors 설정 유무 이다.
cors는 웹[브라우저] 에서 백서버로 어떠한 정보를 넘기고 받을때 option method로 본요청이 전송되기 직전에 요청되는데, 이때 이걸 flask에서는 make response를 사용하여 성공으로 반환하고, 그이후에 본요청을 받게된다.[내가 사용하는 방법이다]
이걸 따로 서버쪽에서 처리하기 힘들다면 클릭하고 넘어가도록 하자.
dev로 resource를 만들고 그 하위에 proxy resource를 만든다면 아래와 같이 생성된다.
여기서 받아낼 endpoint를 정하면되는데,
1.lambda는 AWS안에 생성한 lambda로 바로 요청하여 별도의 서버없이 간단한 요청들을 처리할 수 있다.
2.HTTP Proxy는 특정한 서버의 endpoint로 요청하게된다.
3.VPC Link 는 내가 생성해놓은 VPC안에 특정 Network loadbalancer로 요청할 수 있다.[추후에 기회가 있다면 다시 설명하도록 하겠다.]
나는 2번 HTTP proxy로 설정하겠다.
endpoint url에 받아낼 서버의 url로[포트가 필요하다면 url:~~~/{proxy}] 작성하고 !!꼭 뒤에 /{proxy}를 쓰도록하자
여기 까지 다했다면 잠깐 서버쪽 코드를 작성해보도록 하자. 나는 일단 간단하게 기존에 사용하던 서버 코드를 가져와서 testapi 를 만들었다.
이제 테스트를 위해
proxy 아래 생성된 Any 메서드를 클릭하면 우측과 같은 화면이 나온다. 이후 TEST를 눌러서 진행해보자
내가 만든 api함수로 요청되는것을 확인할수있다.
만약 테스트하는데 405에러가 뜬다거나, 요청이 제대로 가지않는다면 내가 만든 EC2서버에 보안규칙을 확인하길 바란다, 내가 공부한바로는 AWS API gateway는 계속 IP가 바뀌면서 요청되는데 왜이러는지는 알수가없다, 그래서 EC2의 보안규칙을 다열어야 하는데, 만약 이러한행동이 리스크가 크다면, VPC링크와 인증키 방식을 같이 사용하는것이 훨씬 좋다.
여기서 proxy로 만든것의 장점이 적용된다, 하나의 method를 만든것만으로 많은 api함수를 생성해낼수있다.
만약 특정 method방법으로 좀더 세분화 하고 싶다면, 아래와같이 여러개를 생성할수있다.
각각 method요청방법에 따른 endpoint도 따로따로 설정 할 수 있다.
예를 들어 단순 조회같은경우는 lambda를 사용하여 연결하면 db접근해서 간단한 쿼리를 사용해 조회할수있을것이고, 여러가지로 분산시켜 API를 개발할수있다
이제 실제 서비스를 할 수 있도록 배포를 해보겠다.
스테이지를 새롭게 생성하고 test로 이름을 만들어주자
빨간박스1번은 배포를 한 API gateway의 url이다 테스트를 해보자면
위와같이 내가 예상한 결과로 리턴되는것을 알 수 있다.
Log/Tracing 은 클라우드워치를 통해 로그 추적들을 사용여부를 변경할수있다.
export는 swagger, openApi 3 등등으로 뽑아낼수있다.
Deployment History는 배포 히스토리를 봄으로써 롤백 등등이 유용하다.
이제 저 invoke url을 사용하여 서비스를 할수 있게 되었다. 완벽한 서비스 및 개발 서버 배포를 위하여 도메인을 연결해보도록하겠다.
나는 AWS Route 53에 *.#######.com 으로 ssl인증서가 있으니 그걸 통해서 사용하겠다.
custom domain names을 생성했다면 아래와 같이 detail이 생성된다.
아래 처럼 configure API mappings에 들어가도록하자
내가 생성한 API 를 선택하고 만든 배포 Stage를 선택하고 save클릭하면 거의 다왔다.
이제 도메인을 route53에 등록만 하면 끝이다.
내가 사용하는 도메인 대시보드로 들어와 record를 새롭게 생성한다.
방금전에 생성한 API GateWay domain name과 똑같은걸 선택한다.
create누르면 끝!
위처럼 나오면 끝이다!
수고하셨습니다.
2탄에서는 VPC link와 인증키 방법에 대해서 설명하겠슴다.
일단 여기까지했으면 쉬자..
추후에 또 도메인을 만들거나 추가로 할일이 있다면 도메인에 대해서도 글 쓰도록 하겠슴니다.
