지난 글에 이어서 AWS Lambda와 API Gateway를 연동하여 서비스 배포하는 과정을 소개합니다. 이 글에서는 AWS Lambda 보다는 API Gateway 사용에 포인트를 두고 있습니다. AWS Lambda가 더 궁금하신 분들은 이전 글을 봐주세요. 링크:[AWS Lambda를 이용한 API 서비스 배포 (1/2)]
API GateWay는 무엇인가?
AWS에서는 다음과 같이 설명하고 있습니다.
“Amazon API Gateway는 어떤 규모에서든 개발자가 API를 손쉽게 생성, 게시, 유지 관리, 모니터링 및 보안할 수 있게 해주는 완전관리형 서비스입니다.”
API GateWay를 사용하면 어떤 장점들이 있을까요?
AWS콘솔을 통해서 트래픽관리와 모니터링을 쉽게 할 수 있습니다.
트래픽 제어도 콘솔에서 비교적 간단하게 처리할수 있습니다. 또한 제공되는 대시보드를 통해서 API호출, 오류발생률, 응답시간등을 시각화된 UI로 쉽게 볼수 있습니다. 제 견해로는 이 부분이 사실 비용면에서도 유리하다고 생각합니다. 관리인원에 대한 비용, 시간비용을 절약할 수 있다고 봅니다.
기존 서비스를 위한 RESTful 엔드포인트 생성할 수 있습니다.
AWS콘솔에서 다뤄보면 아시겠지만 RESTFul API 서비스를 배포하기 쉽게 구성이 되어 있습니다.
개발자로서 주목할만한 점은 기존에는 웹프로그래밍으로 구현했던 GET, POST, PUT, DELETE등의 메서드들을 쉽게 콘솔조작으로 적용할 수 있다는 점이었습니다.
매우 쉽게 한개의 도메인(예: api.algopie.com)으로 엔드포인트를 만들고 실제로는 각 메서드들 혹은 각 리소스마다 다른 서버로 분산처리 할 수 있습니다.
AWS 사용 이전에 트래픽 분산처리를 위해 사용했던 시간과 기술비용등을 고려해 볼때 이 부분은 매우 큰 장점입니다.
AWS 서비스들과 쉽게 연동할 수 있습니다.
자사 제품을의 사용률을 높이기 위해 AWS에서 당연히 설계시 반영되었겠지만 그래도 쉽게 연동할 수 있다는점도 또한 장점입니다. AWS Lambda, CloudFront등 연동 작업을 매우 간결하게 할 수 있습니다.
API Gateway 시작하기
위와 같이 New API를 체크하고 API name과 Description을 쓰고 Create API 버튼을 누릅니다.
REST의 3요소
계속해서 진행하려면 먼저 Resource를 만들어야 하는데 RESTful API에 관심이 없으신 분들은 Resource 라는 단어는 갖고 있는 광범위한 의미때문에 약한 헷갈릴 수도 있는 단어입니다. REST는 HTTP 스펙 본연의 디자인에 충실하게 API를 구현하기 위하여 제안된 아키텍쳐입니다. 간단하게 REST는 Resource, Method, Message 이렇게 3가지 요소가 있습니다. API Gateway를 사용하기 위해 매우 간단하게만 다루겠습니다.
Resource
사용하고 행위(?)하고자 하는 목적이 되는 대상입니다. https://api.algopie.com/products 와 같은 형태의 URI로 표현합니다.
Method
대상 (Resource)에 대한 행동 방법입니다. 대상 Resource를 생성, 삭제, 수정, 불러오기(보기)등에 대한 행동 방법입니다. HTTP의 method를 그대로 사용합니다. GET (불러오기, 보기등), POST(생성), PUT(수정), DELETE(삭제)등의 HTTP method. 기존 구형의 레거시 스타일에서는 HTTP 요청시에 GET, POST만 주로 사용했었으며 생성, 삭제, 수정, 읽기등 모든 행동을 GET과 POST로 사용하거나 심지어 POST 하나만으로도 사용하는 경우도 있었습니다. REST 아키텍쳐에서는 똑같은 http URL 호출일지라도 method에 따라서 그 결과가 달라집니다.
https://api.algopie.com/products 라는 하나의 URI로도 GET으로 요청하면 product의 리스트를 응답하고 POST로 요청하면 새로운 product를 추가할 수 있습니다. 마찬가지로 DELETE로 요청하면 해당 product를 삭제하게 됩니다.
Message
대상에 대한 내용 입니다. 최근 트렌드는 JSON을 많이 사용합니다. XML로 통칭되는 확장된 마크업랭기지의 경우 JSON에 비하여 사용되는 패킷량도 많고 복잡도도 증가하여 요즈음에는 거의 JSON이 대세가 되었습니다. 위 예에서 https://api.algopie.com/proudcts 리소스를 GET으로 요청하면 product에 대한 아래와 같은 내용을 응답합니다.
[{\"url\": \"https://algopie.com\", \"name\": \"Algorithm Pie\", \"idx\": 1, \"description\": \"\\uc5ec\\ub7ec\\uac00\\uc9c0 \\ubb38\\uc81c\\ub97c \\ub2e4\\uc591\\ud558\\uace0 \\uc7ac\\ubc0c\\uac8c \\ud574\\uacb0\\ud558\\ub294 \\uc54c\\uace0\\ub9ac\\uc998 \\ud30c\\uc774\"}, {\"url\": \"https://biblepuzzle.algopie.com\", \"name\": \"Bible Puzzle\", \"idx\": 2, \"description\": \"\\uac00\\ub85c\\uc138\\ub85c \\uc131\\uacbd \\ud37c\\uc990!\"}]
REST에 대한 설명은 매우 부족하지면 본편을 위하여 이정도로 마무리 합니다. 이 글에서 주로 다루는 것은 Resource와 Method 입니다.
Resource 생성하기
다시 본편으로 돌아와서 아래 이미지와 같이 Resource를 생성합니다.
이 예제에서는 products 라는 리소스를 사용하겠습니다. 리소스 이름을 적어주시면 path는 자동으로 지정되는데 path는 수정 가능합니다. Create Resource 버튼을 눌러서 마무리 합니다.
Method 생성하기
Method를 아래와 같이 생성합니다.
이 글에서는 간단하게 GET 메서드만 배포하겠습니다. 메서드 생성시에 아래와 같이 GET을 선택하여 생성합니다.
우리는 API Gateway를 AWS Lambda와 연동 할 것이기 때문에 GET 메서드에 대한 셋팅을 AWS Lambda 사용을 휘한 셋팅으로 아래와 같이 합니다. 미리 만들어 놓은 lambda function을 아래와 같이 선택합니다. 참고로 저는 서울 region을 사용하기 때문에 Lambda Region은 ap-northeast-2 입니다.
먼저 AWS Lambda 에서 제대로 동작하는 function이 준비되어야 Lambda function을 사용할 수 있습니다. 이전 글에서 만든 function은 디비에 테이블을 생성하고 insert 하는 부분까지 있어서 그대로 사용하기엔 약간의 무리가 있지만 귀찮으신 분들은 그대로 사용하셔도 작동하긴 합니다. 다만 RESTful 하지 않을 뿐입니다. 되도록이면 이전 글을 보시고 응용하셔서 새로은 function을 만들어 보시는 것을 추천합니다. 링크:[AWS Lambda를 이용한 API 서비스 배포 (1/2)]
API 테스트
메서드 생성이 완료되면 아래와 같은 화면을 볼 수 있습니다. Request 부터 Response 까의 경로를 보여주고 있습니다.
가운데 TEST (번개표)를 누르시면 제대로 동작하는지 테스트 할 수 있습니다. 아래와 같이 잘 동작하는 군요. Response body 부분을 보시면 Json으로 된 body 응답을 보 실 수 있습니다. 레이턴시가 116 ms 로 나오는데 저의 경우 그때 그때 다릅니다. 이 경우는 매우 빠른 경우이고 느릴때도 있습니다. 추후 API 분산 처리를 위하여 CloudFront 연동시 보다 나은 퍼포먼스를 기대해 봅니다.
아직 끝이 아닙니다. 중요한 과정 하나가 더 남아 있습니다.
Deploy 하기
마지막 과정으로 우리가 생성한 API를 배포 하는 과정이 남았습니다. 리소스를 선택하고 메서드를 선택하고 Action 버튼을 눌러서 아래와 같이 Deploy 합니다.
Stage는 없으실 경우 New Stage로 새로 만들어 주세요. 제 기억이 가물가물해서 prod 스테이지가 위 과정중에 생성이 되었는지 제가 만들었는지 기억이 잘 나지 않네요. 필요한경우 추후에 업데이트 하겠습니다.
제대로 사용 하려면 Usage Plan, dl인증키관리 등도 함께 다뤄야겠지만 이번 글은 여기서 마치도록 하겠습니다.