끄적끄적 아무기록

AWS_AWS 관리형 서비스로 서버 없는 아키텍처 구현(2)

by 현생사는갓생지망생
반응형

AWS 관리형 서비스로 서버 없는 아키텍처 구현




작업 4: 두 개의 Simple Queue Service 대기열 생성


이번 작업에서는 두 개의 Simple Queue Service(SQS) 대기열을 생성한다.

이 대기열들은 방금 생성한 Simple Notification Service(SNS) 주제를 구독한다.

이러한 설정을 팬아웃 시나리오라고 한다.

여러 명의 구독자에게 각 SNS 알림이 전송되고 해당 구독자들이 각자의 대기열에서

독립적으로 메시지를 소비할 수 있기 때문이다.

 

먼저, 고객 알림 용 대기열을 생성한다.




 

Services 메뉴에서 Simple Queue Service를 클릭 후 Get Started Now를 클릭한다.





 

Queue Name : CustomerNotify

리전이 선입선출(FIFO) 대기열을 지원하는지 아닌지에 따라 인터페이스가 달라진다.

“What type of queue do you need?” 라는 메시지가 표시되면 Standard Queue를 기본 선택으로 두고 맨 아래로 스크롤을 내린다.

나머지 설정을 기본 값으로 두고 Create QueueQuick-Create Queue를 클릭한다.

완전한 애플리케이션 환경에서는 Lambda 함수 또는 다른 애플리케이션을 사용하여 이 대기열의

메시지를 읽고 잔액이 높은 사용자를 알려줄 수 있다.




 


다음으로 채권 추심 부서 알림용 대기열을 생성한다.

Create New Queue를 클릭한다.

 





Queue Name : CreditCollection

나머지 설정을 기본 값으로 두고 Create QueueQuick-Create Queue를 클릭한다.

완전한 애플리케이션 환경에서는 Lambda 함수 또는 다른 애플리케이션을 사용하여 이 대기열의

메시지를 읽고, 해당 계정을 모니터링하도록 채권 추심 부서에 알려줄 수 있다.

 





두 대기열의 확인란을 모두 선택한다.

Queue Actions > Subscribe Queues to SNS Topic를 클릭한다.





Choose a Topic : HighBalanceAlert




 

OK를 클릭한다.

이제 두 개의 대기열이 Simple Notification Service 주제를 구독한다.

해당 주제로 전송되는 메시지를 모두 자동으로 수신한다.

 

 


작업 5: 트랜잭션 파일을 업로드하여 서버 없는 아키텍처 테스트


트랜잭션 파일을 검색하여 S3 버킷으로 업로드한다. 그런 다음 서버 없는 아키텍처를 테스트한다.

 


작업 5.1: 트랜잭션 파일 업로드


https://us-west-2-aws-staging.s3.amazonaws.com/awsu-ilt/AWS-100-ARC/v5.2/lab-4-serverless/scripts/transactions.txt

위의 링크를 클릭하여 transactions.txt 파일을 로컬 컴퓨터로 다운로드한다.

 



Services 메뉴에서 S3를 클릭하고 qls-xxxx 형식의 이름으로 된 버킷을 클릭한다.

 




Upload를 클릭한다.




 

Add files를 클릭한 다음 다운로드 받은 transactions.txt 파일을 선택한다.

 




Upload를 클릭한다.




 

Amazon S3로 이 파일을 업로드하면 실습에서 생성한 첫 번째 Lambda 함수가 즉시 트리거 되어

텍스트 파일을 읽고 데이터를 Customer Transactions DynamoDB 테이블에 저장한다.



 

작업 5.2: DynamoDB 테이블 확인


데이터가 DynamoDB 테이블에 로드 되었는지 확인하여 트랜잭션 파일이 올바르게 처리되었는지 확인한다.





Services 메뉴에서 DynamoDB를 선택 후 탐색 창에서 Tables를 클릭한다.

Customer를 클릭하고 Items 탭에서 2명의 고객에 대한 고객 ID 및 주소 항목이 있는지 확인한다.

데이터가 보이지 않는다면, Lambda 함수에 오류가 발생했거나 실행되지 않은 것이다.

 





Transactions를 클릭하고 Items 탭에서 일부 트랜잭션이 존재하는지 확인한다. 목록에 총 24개의 항목이 있을 것이다.

Transactions 테이블에 정보가 추가되면 두 번째 DynamoDB 함수가 자동으로 트리거 된다.

이 함수는 각 계정의 트랜잭션 총계를 계산하고 Transaction Total 테이블에 총계를 저장한다.

이제 프로세스가 제대로 작동했는지 확인할 수 있다.





 

TransactionTotal을 클릭하고 Items 탭에서 2명의 고객에 대한 ID 및 계정 잔액이 있는지 확인한다.

C2 고객 계정 잔액이 1,500 USD를 초과하였다.

 



작업 5.3: SQS 대기열 확인


 

HighAlert에서 C2 고객의 계정 잔액이 높다는 내용의 알림 이메일을 새로 받았을 것이다.

또한, 같은 메시지가 2개의 SQS 대기열에 전송되었으며, 다른 프로세스에 의한 처리를 준비한다.






Services 메뉴에서 Simple Queue Service를 클릭한다.

Lambda 함수가 제대로 작동했다면 양쪽 대기열 모두 Messages Available 열에 하나의 메시지를

표시해야 한다.

 





CreditCollection을 선택하고 Queue Actions > View/Delete Messages를 클릭한다.

 




Start Polling for Messages를 클릭한다.

 





표시된 메시지에 More Details를 클릭한다.

 





메시지 본문에 C2 고객에 대한 경고가 표시되는지 확인한다. 위와 같은 메시지가 표시되어야 한다.

이상이 없다면 Close를 클릭한다.




 

CustomerNotify 대기열에서도 메시지를 확인한다.

 



작업 5.4: Lambda 함수 확인


Lambda 함수는 자동으로 로그와 지표를 기록한다.

이 정보를 확인하여 함수가 제대로 실행되었는지 확인할 수 있다.



 

Services 메뉴에서 Lambda를 클릭하고 TransactionProcessor를 클릭한다.

 




Monitoring 탭을 클릭하여 Lambda 함수에 대한 CloudWatch 지표를 확인한다.

지표에서 Lambda 함수가 호출되었고 오류가 발생하지 않았다는 사실을 확인할 수 있어야 한다.




 


왼쪽 탐색 창에서 Functions를 클릭하고 TotalNotifier를 클릭한다.

Monitoring 탭을 클릭하여 Lambda 함수에 대한 CloudWatch 지표를 확인한다.

로그 파일은 Lambda 함수 디버깅에 유용하다. Amazon CloudWatch 로그에 저장된다.







View logs in CloudWatch를 클릭하여 함수 로그를 확인한다.

표시된 링크를 클릭하고 로그를 검토한다.




반응형

블로그의 정보

현생이네

현생사는갓생지망생

활동하기