[AWS SAA] 애플리케이션 통합

SQS

핵심 개념

• SQS는 Simple Queue Service의 약자
• 메시지 기반 비동기 처리를 위한 완전 관리형 큐 서비스
• 생산자, 즉 Producer가 메시지를 큐에 넣고, 소비자, 즉 Consumer가 메시지를 꺼내 처리
• 애플리케이션 간 결합도를 낮추고, 장애나 트래픽 급증 시 완충 역할을 수행
• 처리 속도가 다른 시스템 사이에 메시지 버퍼를 둘 때 적합
• Lambda, EC2, ECS Worker 등 다양한 소비자와 함께 사용할 수 있음
• SQS는 메시지를 저장하고 소비자가 가져가 처리하는 큐 서비스
• Kinesis Data Streams는 여러 소비자가 같은 스트림 데이터를 독립적으로 읽고 처리하는 대량 스트리밍 서비스
• 단순 비동기 작업 큐는 SQS, 실시간 스트리밍 분석이나 여러 소비자 기반 스트림 처리는 Kinesis Data Streams를 고려

SQS 주요 수치

항목	내용
가시성 타임아웃	기본 30초, 최대 12시간
메시지 보존 기간	기본 4일, 최소 1분, 최대 14일
Delay Queue / 메시지 타이머	최대 15분까지 메시지 전달 지연
최대 메시지 크기	256KB
표준 큐 처리량	거의 무제한에 가까운 처리량
FIFO 큐 기본 처리량	초당 300 TPS 수준. 배치 사용 시 초당 3,000 메시지 수준
FIFO 고처리량 모드	설정에 따라 더 높은 처리량 지원
In-flight 메시지 한도	표준 큐는 약 120,000개, FIFO 큐도 기본적으로 120,000개 수준

• 가시성 타임아웃은 소비자가 메시지를 받은 뒤 처리하는 동안 다른 소비자가 같은 메시지를 다시 받지 못하게 숨기는 시간
• 소비자가 가시성 타임아웃 안에 메시지를 삭제하지 않으면 메시지는 다시 큐에 나타나고 다른 소비자가 다시 처리할 수 있음
• 메시지 보존 기간은 큐에 남아 있는 메시지를 얼마나 오래 보관할지 정하는 값
• 메시지 타이머는 특정 메시지를 일정 시간 뒤에 소비자가 받을 수 있도록 지연시키는 기능
• Delay Queue는 큐에 들어온 모든 메시지의 전달을 일정 시간 지연시키는 기능
• 메시지 크기가 256KB를 넘으면 S3에 큰 데이터를 저장하고 SQS에는 S3 객체 위치나 메타데이터를 전달하는 방식을 고려

SQS DLQ

• DLQ는 Dead Letter Queue의 약자
• 컨슈머가 여러 번 처리에 실패한 메시지를 별도 큐로 이동시켜 보관
• 장애 메시지 분석, 재처리, 원인 파악에 사용
• maxReceiveCount를 설정하여 몇 번 실패하면 DLQ로 보낼지 정할 수 있음
• DLQ를 사용하면 실패 메시지가 계속 재시도되며 정상 메시지 처리를 방해하는 상황을 줄일 수 있음

SQS Long Polling

• Long Polling은 메시지가 없을 때도 일정 시간 대기하여 메시지가 도착하면 응답하는 방식
• 빈 응답을 줄이고 비용과 지연 시간을 개선할 수 있음
• Short Polling은 즉시 응답하는 방식이라 메시지가 없다는 빈 응답이 많아질 수 있음
• Short Polling이 메시지 전송 자체를 실패하게 만드는 것은 아님
• SQS에서는 비용과 효율 측면에서 Long Polling 사용을 권장

SQS Access Policy

• SQS 큐에는 리소스 기반 정책인 Access Policy를 설정할 수 있음
• 다른 AWS 계정에 큐 접근을 허용할 때 사용
• 특정 AWS 계정, IAM 역할, 서비스, IP 조건 등을 기준으로 큐 접근 제어 가능
• 다른 계정에 SQS 접근을 허용해야 하면 IAM 정책뿐 아니라 큐의 Access Policy도 함께 고려
• SNS에서 SQS로 메시지를 보낼 때도 SQS 큐 정책에서 해당 SNS 토픽을 허용해야 함

FIFO Queue vs Standard Queue

항목	Standard Queue	FIFO Queue
순서 보장	최선의 노력	메시지 그룹 ID 기준 순서 보장
중복 가능성	최소 1회 전달, 중복 가능	중복 제거 기능 제공
처리량	매우 높음	Standard보다 제한적
이름 규칙	일반 큐 이름	.fifo로 끝나야 함
주요 용도	일반 비동기 처리, 대량 처리	순서가 중요한 작업 처리

• Standard Queue는 최소 1회 전달을 보장하므로 중복 처리가 발생할 수 있음
• FIFO Queue는 메시지 순서 보장과 중복 제거가 필요한 경우 사용
• FIFO Queue도 소비자 처리 로직은 멱등성 있게 설계하는 것이 안전
• FIFO Queue의 순서는 전체 큐가 아니라 Message Group ID 단위로 보장됨
• 주문 처리, 결제 순서 처리처럼 순서가 중요한 경우 FIFO Queue를 고려
• 대량 처리와 높은 처리량이 더 중요하면 Standard Queue가 적합

SQS + Lambda 패턴

• S3 업로드 이벤트 → SQS → Lambda 구조로 안정적인 비동기 처리 가능
• S3 이벤트가 직접 Lambda를 호출하는 구조보다 SQS를 사이에 두면 재처리와 완충이 쉬움
• Lambda 처리량 한계가 있으면 SQS 기반으로 작업을 분산하고 동시성을 조절할 수 있음
• Lambda 처리 실패 시 메시지는 다시 큐에 나타나 재시도 가능
• 반복 실패 메시지는 DLQ로 보내 분석 가능
• 갑작스러운 요청 증가가 발생하는 API 뒤에 SQS를 두면 백엔드 처리량을 완충할 수 있음

SNS

핵심 개념

• SNS는 Simple Notification Service의 약자
• 여러 구독자에게 메시지를 전송하는 게시/구독, 즉 Pub/Sub 서비스
• 하나의 이벤트를 여러 대상에게 동시에 전달할 때 사용
• 발행자, 즉 Publisher가 SNS Topic에 메시지를 게시하면 구독자에게 메시지가 전달됨
• 구독자로는 SQS, Lambda, HTTP/HTTPS 엔드포인트, Email, SMS 등을 사용할 수 있음
• SNS는 알림과 팬아웃에 적합
• SNS 자체가 데이터베이스를 직접 업데이트하는 서비스는 아님
• DB 업데이트가 필요하면 Lambda, SQS, 애플리케이션 등을 구독자로 연결해 처리

SNS 구독 유형

구독  유형	설명
SQS	큐에 메시지 전달
Lambda	Lambda 함수 직접 호출
HTTP/HTTPS	외부 엔드포인트 호출
Email	이메일 전송
SMS	문자 전송
Kinesis Data Firehose	메시지를 스트리밍 대상으로 전달

SNS Fan-out 패턴

• SNS Topic → 여러 SQS Queue로 메시지를 동시에 전달하는 패턴
• 하나의 이벤트를 여러 워크로드에서 각각 독립적으로 처리할 때 유용
• 예를 들어 주문 생성 이벤트를 재고 처리 큐, 알림 처리 큐, 분석 처리 큐로 동시에 전달 가능
• SNS + SQS 조합을 사용하면 각 소비자가 독립적으로 메시지를 처리할 수 있음
• 특정 구독자 장애가 다른 구독자에게 영향을 주는 것을 줄일 수 있음
• SQS를 구독자로 두면 메시지를 큐에 보관하고 소비자가 안정적으로 처리 가능

EventBridge

핵심 개념

• EventBridge는 이벤트 기반 애플리케이션을 구성하기 위한 서버리스 이벤트 버스 서비스
• AWS 서비스, 사용자 애플리케이션, SaaS 애플리케이션에서 발생한 이벤트를 대상으로 라우팅 가능
• 이벤트 패턴을 기준으로 이벤트를 필터링하고 여러 대상으로 전달
• 애플리케이션 간 결합도를 낮추고 이벤트 기반 아키텍처를 구성할 때 사용
• 이벤트 라우팅, 애플리케이션 분리, 확장, 유지관리에 적합

EventBridge 주요 기능

기능	설명
Event Bus	이벤트를 수신하고 규칙에 따라 대상으로 전달
Rule	이벤트 패턴 또는 스케줄을 기준으로 대상 호출
Scheduler	크론 표현식 또는 비율 기반으로 작업 예약
API Destinations	REST API 호출 방식으로 외부 서비스와 통합
Archive	이벤트를 저장
Replay	저장된 이벤트를 나중에 다시 이벤트 버스로 재전송
Schema Registry	이벤트 스키마를 관리하고 코드 바인딩 생성

• Scheduler는 정해진 시간이나 주기에 작업을 실행할 때 사용
• EventBridge Scheduler는 기존 Scheduled Rule보다 더 유연한 예약 실행에 적합
• API Destinations를 사용하면 AWS 외부의 REST API를 대상으로 호출할 수 있음
• Archive와 Replay를 사용하면 이벤트를 저장하고 장애 복구나 기능 검증을 위해 나중에 재처리할 수 있음
• Replay는 저장된 이벤트를 원래 이벤트 버스로 다시 보내는 방식

EventBridge 사용 사례

• EC2 인스턴스 상태 변경 이벤트를 감지하여 Lambda 함수 실행
• 특정 시간 또는 주기 기반으로 Lambda, Step Functions, Batch 작업 실행
• SaaS 파트너 애플리케이션에서 이벤트 수신
• AWS 서비스 이벤트를 필터링하여 운영 자동화
• 계정 내 보안 이벤트를 EventBridge로 받아 Lambda를 통해 자동 대응
• 애플리케이션 간 이벤트 기반 통합 구성

Step Functions

핵심 개념

• Step Functions는 AWS 서비스를 워크플로로 조율하는 서버리스 오케스트레이션 서비스
• 여러 Lambda 함수, ECS 작업, Batch 작업, SNS, SQS, DynamoDB 등 AWS 서비스를 단계별로 연결 가능
• 장기 실행 프로세스, 다단계 작업 흐름, 승인 프로세스, 오류 처리, 재시도 로직 관리에 적합
• 워크플로 실행 상태를 시각적으로 확인할 수 있음
• 각 단계의 성공, 실패, 재시도, 분기, 병렬 실행을 관리할 수 있음
• 단순 이벤트 전달은 EventBridge, 복잡한 순서와 상태 관리가 필요한 프로세스는 Step Functions를 고려

Step Functions 워크플로 유형

워크플로 유형	특징	적합한 경우
Standard	장기 실행 가능, 최대 1년, 실행 이력 보존, 정확히 한 번 실행 모델	주문 처리, 승인 워크플로, 장기 프로세스
Express	단기 고성능, 최대 5분, 대량 이벤트 처리에 적합	IoT, 스트리밍 처리, 고빈도 이벤트 처리

• Standard Workflow는 장기 실행과 감사 가능한 실행 이력이 필요한 경우 적합
• Express Workflow는 대량의 짧은 워크플로를 빠르게 처리할 때 적합
• Express Workflow는 비동기 실행에서는 최소 한 번 실행 모델, 동기 실행에서는 최대 한 번 실행 모델로 이해하면 안전
• Express Workflow를 사용할 때는 작업이 멱등성을 갖도록 설계하는 것이 좋음

API Gateway

핵심 개념

• API Gateway는 백엔드 시스템을 모바일, 웹, 애플리케이션 클라이언트에 연결하는 완전 관리형 API 서비스
• REST API, HTTP API, WebSocket API를 지원
• Lambda, HTTP 백엔드, AWS 서비스, VPC Link 등을 대상으로 연결 가능
• 인증, 권한 부여, 요청 제한, 캐싱, 로깅, 모니터링, 배포 스테이지 관리 등에 사용
• 서버리스 API를 만들 때 API Gateway + Lambda 조합이 자주 사용됨
• 실시간 양방향 통신이 필요하면 WebSocket API 고려

REST API vs HTTP API

항목	REST API	HTTP API
기능	더 많은 기능 제공	더 간단하고 저렴
비용	상대적으로 높음	상대적으로 낮음
지연 시간	상대적으로 높을 수 있음	더 낮은 지연 시간 목표
Lambda Proxy	지원	지원
Cognito 연동	지원	JWT Authorizer / Cognito 연동 가능
API Key / Usage Plan	지원	제한적 또는 미지원 기능 있음
Request Validation	지원	REST API 기능이 더 풍부
WAF 연동	지원	일반적으로 REST API가 더 적합한 경우가 많음
Private API	지원	REST API 중심으로 사용

• REST API는 기능이 더 많고 세밀한 제어가 필요할 때 적합
• HTTP API는 단순하고 저렴한 HTTP API가 필요할 때 적합
• API Key, Usage Plan, Request Validation, Private API 같은 기능이 중요하면 REST API를 우선 고려
• 단순 Lambda 기반 API, JWT 인증, 낮은 비용이 중요하면 HTTP API를 고려
• API Gateway 엣지 최적화 엔드포인트는 CloudFront를 활용하여 글로벌 사용자 지연 시간을 줄일 수 있음

API Gateway 인증 / 인가

방식	설명
IAM 인증	AWS IAM 자격 증명을 사용해 API 호출 제어
Cognito User Pool Authorizer	Cognito 사용자 풀 기반으로 API 접근 제어
Lambda Authorizer	커스텀 인증/인가 로직 적용
JWT Authorizer	JWT 토큰 기반으로 HTTP API 접근 제어

• API Gateway + Cognito User Pool Authorizer를 사용하면 로그인한 애플리케이션 사용자만 API에 접근하도록 제어 가능
• Lambda Authorizer는 커스텀 토큰 검증, 외부 인증 시스템 연동 등 복잡한 인증 로직에 사용
• HTTP API에서는 JWT Authorizer를 통해 Cognito나 외부 OIDC IdP 토큰을 검증할 수 있음
• API Gateway 앞단 또는 백엔드 앞단에 SQS를 두면 갑작스러운 요청 증가 시 처리량을 완충할 수 있음

AppSync

핵심 개념

• AppSync는 GraphQL API를 위한 완전 관리형 서비스
• 여러 데이터 소스의 데이터를 하나의 GraphQL API로 통합 가능
• DynamoDB, Lambda, OpenSearch, RDS, HTTP 데이터 소스 등과 연동 가능
• 클라이언트는 필요한 필드만 요청할 수 있어 모바일/웹 앱에서 효율적
• 실시간 데이터 업데이트를 위한 구독 기능을 지원
• 오프라인 클라이언트 지원 시나리오에도 적합
• 여러 데이터 소스를 조합해 하나의 API로 제공해야 하면 AppSync를 고려

Amazon MQ

핵심 개념

• Amazon MQ는 오픈소스 메시지 브로커의 관리형 서비스
• Apache ActiveMQ와 RabbitMQ를 지원
• AMQP, MQTT, STOMP, OpenWire, WebSocket 등 기존 메시지 프로토콜을 지원
• 기존 메시지 브로커 기반 애플리케이션을 AWS로 이전할 때 코드 변경을 줄일 수 있음
• 새로운 애플리케이션은 SQS/SNS/EventBridge 같은 클라우드 네이티브 서비스를 우선 고려
• 기존 브로커 프로토콜 호환이 필요하면 Amazon MQ 선택

Amazon MQ 고가용성

• 고가용성이 필요하면 멀티 AZ 구성을 고려
• ActiveMQ는 active/standby 브로커 구성을 사용할 수 있음
• RabbitMQ는 클러스터 배포 구성을 사용할 수 있음
• 기존 온프레미스 메시지 브로커를 클라우드로 이전해야 하고 프로토콜 호환이 중요하면 Amazon MQ가 적합

Amazon AppFlow

• Amazon AppFlow는 SaaS 애플리케이션과 AWS 서비스 간 데이터를 코드 없이 주고받을 때 사용하는 서비스
• Salesforce, Zendesk, Slack, ServiceNow, Google Analytics 등 다양한 SaaS와 연동 가능
• S3, Redshift, EventBridge 등 AWS 서비스로 데이터를 전달할 수 있음
• 정기 동기화, 이벤트 기반 동기화, 온디맨드 전송 등을 구성 가능
• EventBridge가 이벤트 라우팅 중심이라면, AppFlow는 SaaS 데이터 연동과 전송 중심

애플리케이션 통합 서비스 선택 기준 요약

요구사항	적합한 서비스
비동기 작업 큐	SQS
순서 보장이 필요한 큐	SQS FIFO Queue
처리 실패 메시지 별도 보관	SQS DLQ
여러 구독자에게 알림 전송	SNS
하나의 이벤트를 여러 큐로 분산	SNS Fan-out + SQS
이벤트 기반 라우팅	EventBridge
예약 작업 실행	EventBridge Scheduler
외부 REST API 호출 통합	EventBridge API Destinations
이벤트 저장 후 재처리	EventBridge Archive / Replay
다단계 워크플로 오케스트레이션	Step Functions
서버리스 REST/HTTP API	API Gateway
실시간 양방향 API	API Gateway WebSocket API
GraphQL API	AppSync
기존 ActiveMQ/RabbitMQ 브로커 이전	Amazon MQ
SaaS와 AWS 간 코드 없는 데이터 연동	Amazon AppFlow