AWS 더 많은 솔루션 아키텍쳐

Lambda, SNS, & SQS

 

SQS + Lambda

SQS대기열과 Lambda 함수를 사용하는 것으로 이벤트가 SQS 대기열에 삽입되고 Lambda 서비스가 SQS 대기열을 폴링합니다.

문제가 발생하면 해당 메시지를 다시 SQS 대기열에 입력하고 폴링을 재시도 한다. 이건 무한정 반복될 것이므로 

 

다섯번의 재시도 후에는 데드 레터 대기열로 보내도록 SQS를 설정할 수 있다.

 

SQS FIFO + Lambda

FIFO란 선입선출이다. 도착한 순서에 따라 메시지를 처리한다는 뜻이다. 여기에는 Lambda 함수가 대기열 메시지를 순서대로 처리를 시도하는데 순서대로 처리하기 때문에 한 메시지를 처리하지 못하면 차단이 발생하여 처리가 끝나지 않고 결국 전체 대기열 처리가 차단 된다.

 

이 경우에도 마찬가지로 데드 레터 대기열을 구성하여 해당 메시지를 빼내고 함수가 계속 동작하도록 할 수 있다.

 

SNS + Lambda

SNS 서비스를 사용하는 방법으로 메시지가 통과하고 메시지는 비동기식으로 Lambda에 전송된다. 이 때 Lambda 함수는 재시도 행동을 달리하여 처리하지 못하는 메시지가 발생하더라도 내부적으로만 재시도를 한다. 총 세번까지만 하며 제대로 처리되지 않으면 제거하거나 데드 레터 대기열로 보내도록 구성할 수 있지만 SQS 대기열로 보내서 나중에 다시 처리할 수도 있다.

 

Fan Out Pattern

팬 아웃 패턴은 다중 SQS 대기열에 데이터를 전송하는 방식이다.

SDK에서 3개의 대기열에 메시지를 전송하고자 한다. 메시지를 각 SQS에 전부 보내면 된다.

이 방법으로 작동은하지만 안정성이 높지는 않다. 예를들어 두번째 까지만 메시지를 전송한 다음 애플리케이션이 오류로 종료되면 세 번째 대기열은 메시지를 전달받지 못하므로 각 대기열의 콘텐츠가 달라질 것이다.

 

SQS대기열과 애플리케이션(SDK) 사이에 SNS를 두면 SQS대기열은 SNS 주제의 구독자가 되고 SNS 주제에 메시지를 전송할 때마다 메시지가 모든 SQS 대기열에 전달되므로 안정성이 높아진다. 

 

S3 Event Notifications

s3버킷이 특정 이벤트에만 반응하도록 설정ㅎㄹ 수 있어 객체 생성, 삭제, 복원, 복제본 생성 시 알림을 보내도록 할 수있고, 객체 이름별로 필터링도 가능하다. 사용 사례로는 s3에 업로드된 이미지의 섬네일을 생성하는 경우가 있다.

S3 이벤트를 SNS SQS또는 Lambda 함수로 보내는데 이 때 S3 이벤트는 원하는 만큼 생성할 수 있다.

 

S3 Event Notifications with Amazon EventBridge

S3버킷에서 일어난 모든 이벤트를 EventBridge에 전송하는 방식인데 규칙을 설정하여 18개 이상의 AWS서비스로 전달할 수 있다.

JSON 규칙에 고급 필터링 옵션을 사용하여 메타데이터, 객에 크기, 이름 등으로 필터링 할 수 있기 때문이다.

또 여러 대상에 이벤트를 한 번에 보낼 수 있고 예를 들어 단계함수, kinesis data stream, 파이어 호스 등이 대상이 될 수 있다.

 

EventBridge - Intercept API Calls

eventbridge에서 모든 api호출을 인터셉트 하려면 cloudtrail을 통합하여 사용하면 된다. 가령 사용자가 dynamodb의 테이블을 삭제하고자 deleteTable API을 호출하는 이벤트가 발생했다면 이 API호출은 CloudTrail에 로그되며 이 로그는 eventBridge의 이벤트를 트리거하므로 이를 이용해 경보를 생성하여 SNS에 전송할 수 있다. 

 

APIGateway - integration kinesis data streams example

클라이언트가 apigateway에 요청을 보내면 geteway가 kenesis data stream에 메시지를 전송한다. 해당 레코드는 kinesis data firehose로 이동하고 최종적으로는 amazon s3에 저장된다.

 

Caching Strategies

먼저 API Gateway앞에 CloudFront가 있다고 하자. EC2나 람다가  API Gateway뒤에 있으며 EC2는 데이터베이스에서 데이터를 저장하고 쓰며 Redis, memcached, 혹은DAX 등의 내부 캐시를 쓸 수도 있다.

그럼 바로 동적 콘텐츠와 동적 라우팅이 실행된다.

 

정적 콘텐츠도 라우팅할 수 있다. cloud front가 s3에서 데이터를 소싱하는 경우이다. 

클라우트 프론트는 사용자와 최대한 가까이에서 캐싱을 한다는 뜻이다. 

 

API Gateway도 캐싱이 가능하다. 이건 리전서비스라서 api gateway에서 캐시를 사용할 경우 캐시도 리전에 묶이게 된다. 그래서 클라이언트와 API Gateway 사이에 네트워크 라인이 형성되어 캐시가 히트한다.

 

DynamoDB가 있을 경우 Redis,Memcached , DAX등을 사용할 수 있는 캐시를 할 때 사용된다.

데이터 베이스는 캐싱을 하지 못한다. 자주 발생하는 쿼리나 복잡한 쿼리가 공유 캐시에 결과가 저장되어 쉽게 액세스 할 수 있도록 하는 것이다.

 

Blocking an IP address

클라이언트가 ec2에 접근하려고 할 때 맨 처음에 VPC Level인 NACL을 거쳐야한다.

여기서 차단 규칙에 걸리면 접근할 수 없다. 

그 다음은 보안그룹인데 보안 그룹은 차단 규칙을 만들 수 없고 허용 규칙만 가능하다. 그래서 EC2 인스턴스에 액세스 가능한 권한이 부여된 클라이언트들의 서브셋만 알면 허용할 수 있다.

 

firewall software in ec2라는 것을 ec2에서 실행시켜 클라이언트의 요청을 거절할 수도 있다. 

 

Direct Connect

초당 GB의 속도로 프라이빗 보안 네트워크를 통해 클라우드로 데이터를 전송하낟.

DataSync

DayaSync에이전트를 설치하여 대용량의 데이터를 전송한다. 온프레미스.NFS, SMB시스템에서 S3, EFS나 Window FSx로 전송

 

ENA를 사용하면 대역폭과 초당 패킷을 증가시키며 지연 시간을 줄여준다.