위와 같이 (서버1)에서 다른 (서버2)에 API 요청을 했을 때, (서버2)가 모의의 사고(ex: 서버 다운)로 요청을 수행하지 못할 수 있다. 그렇다면 해당 API 요청은 소실되어 복구할 수 없을 것이다.
(서버2)가 메세지를 받지 못함으로써 발생할 수 있는 API 요청 메세지의 미처리 현상은 SQS (메세지큐) 를 통해서 대응이 가능하다.
SQS 를 사용하면 서버가 중지되더라도 메세지가 소실되지 않도록 할 수 있다.
SQS 를 적용하면 (서버 1)에서 받은 API 정보를 SQS에서 보관하고 (서버 2)가 SQS의 메세지를 읽어서 SQS 메세지를 처리한다. 만약 (서버2)에서 메세지를 정상적으로 처리하면 SQS 에 보관하고 있던 메세지를 제거한다. 그러나 (서버2)에서 처리에 실패하면 SQS는 메세지를 제거하지 않고 보관하여 메세지가 다시 사용될 수 있게 한다. 이렇게 함으로써 처리되지 않은 API 호출이 유실되지 않도록 할 수 있다.
Lambda-SQS-Lambda 흐름을 구현하여 (서버2)가 SQS를 통해서 호출되도록 한다.
초기 실습 선수 조건:
# node와 npm이 설치된 상태에서 Serverless Framework 를 글로벌 모듈로 설치하는 것을 권장함
$ npm install -g serverless
$ serverless
Creating a new serverless project
? What do you want to make? AWS - Node.js - SQS Worker
? What do you want to call this project? sqs-test
✔ Project successfully created in sqs-test folder
? Do you want to deploy now? No
$ cd sqs-test
serverless.yml
에서 타켓을 한국으로 설정한다.# serverless.yml
provider:
...
region: ap-northeast-2 // 한국
...
$ serverless deploy
Running "serverless" from node_modules
Deploying sqs-test to stage dev (ap-northeast-2)
...
Need a faster logging experience than CloudWatch? Try our Dev Mode in Console: run "serverless dev"
...
API Gateway 를 확인한다.
엔드포인트에 Path를 추가하여 호출해보고 정상적으로 (서버 1)이 호출됨을 확인. (message accepcted가 뜨면 성공)
$ curl --request POST 'https://자신의-엔드포인트/produce' --header 'Content-Type: application/json' --data-raw '{"name": "John"}'
{"message":"Message accepted!"}
참고자료 :