이벤트 기반 아키텍처(EDA)란 무엇인가요?
이벤트 기반 아키텍처(EDA)는 이벤트를 게시, 소비 또는 라우팅하는 분리된 소형 서비스에서 구축된 현대적 아키텍처 패턴입니다.
이벤트란 상태 변경 또는 업데이트를 뜻합니다. 예를 들어 장바구니에 들어간 품목, 스토리지 시스템에 업로드된 파일, 배송 준비된 주문이 이에 해당합니다. 이벤트는 상태(주문 내의 품목 이름, 가격, 수량 등)를 전달할 수도 있고, 관련 정보를 조회하는 데 필요한 식별자(예: ‘주문 #8942가 배송됨’)를 포함하기만 할 수도 있습니다.
기존의 요청 기반 모델과 달리 EDA는 생산자와 소비자 서비스 간의 느슨한 결합을 촉진합니다. 이를 통해 시스템의 개별 구성 요소에 대해 확장, 업데이트, 독립적인 배포가 쉬워집니다.
분리된 아키텍처는 왜 중요한가요?
많은 조직들이 모놀리스 애플리케이션, 데이터베이스 및 기술이 사용자 경험의 혁신과 개선에 부정적인 영향을 미친다는 사실을 알게 되었습니다. 기존 애플리케이션 및 데이터베이스는 현대적 기술 프레임워크를 도입하는 데 있어 선택할 수 있는 옵션을 줄이고 경쟁력과 혁신을 제한합니다. 하지만 애플리케이션과 해당 데이터 스토어를 현대화하면 확장하기가 더 쉬워지고 개발 속도가 빨라집니다.
분리된 데이터 전략은 내결함성과 복원력을 향상시켜 새로운 애플리케이션 기능의 출시 기간(TTM)을 단축합니다.
모놀리스 애플리케이션을 현대화하는 데 따른 이점에 대한 자세한 내용은 AWS 권장 가이드에서 마이크로서비스에서 데이터 지속성 활성화를 참조하세요.
이벤트 기반 아키텍처(EDA)의 이점은 무엇인가요?
이벤트 기반 아키텍처(EDA)는 시스템 구성 요소 간의 느슨한 결합을 지원하여 민첩성을 높입니다. 마이크로서비스는 독립적으로 확장되고, 장애를 일으키더라도 다른 서비스에 영향을 주지 않으며, 워크플로의 복잡성을 줄여줍니다. 이벤트는 감사 목적으로 유연하게 라우팅, 버퍼링 및 로깅할 수 있습니다. 푸시 기반 이벤트 흐름이 실시간으로 작동하므로, 변경 사항을 지속적으로 폴링하는 코드를 작성하고 운영하는 데 따른 비용을 절감할 수 있습니다.
독립적인 확장 및 장애
서비스를 분리함으로써 이벤트 기반 아키텍처의 구성 요소가 독립적으로 확장되고 장애를 일으키도록 하여 애플리케이션의 복원력을 높일 수 있습니다. 이는 서비스 간 통합 사례가 증가함에 따라 갈수록 중요해지고 있습니다. 특정 서비스에 장애가 발생하더라도 나머지는 계속 실행될 수 있습니다.
또한 이벤트 기반 아키텍처를 통해 실시간에 가까운 시스템을 더 쉽게 설계할 수 있으므로, 조직이 배치 기반 처리에서 벗어날 수 있습니다. 애플리케이션 상태가 변경될 때 이벤트가 생성됩니다. 이벤트가 스케일 업되면 이벤트를 처리하는 계층도 확장됩니다.
이벤트는 일반적으로 마이크로서비스 간에 탄력적인 버퍼처럼 작동하고 확장을 처리하는 데 도움이 되는 메시징 서비스에 게시됩니다. 이벤트의 콘텐츠를 기준으로 메시지를 필터링하고 라우팅할 수 있는 라우터 서비스로 이벤트가 전송될 수도 있습니다. 따라서 이벤트 기반 애플리케이션은 모놀리스 애플리케이션보다 확장성이 뛰어나며 더 강화된 이중화를 제공할 수 있습니다.
민첩한 개발
이벤트 기반 아키텍처와 이벤트 라우터를 통해 개발자는 더 이상 이벤트 폴링, 필터링 및 라우팅을 위해 사용자 지정 코드를 작성할 필요가 없습니다. 이벤트 라우터는 자동으로 이벤트를 필터링하고 소비자에게 푸시합니다. 또한 라우터는 생산자 서비스와 소비자 서비스 간 과도한 조정의 필요성을 없애 개발의 민첩성을 높입니다.
이벤트 기반 아키텍처는 푸시 기반입니다. 즉, 종속 서비스에 알릴 필요 없이 이벤트가 라우터 및 다운스트림 시스템으로 전송될 때 모든 작업이 온디맨드 방식으로 수행됩니다. 따라서 인프라 및 리소스는 이벤트 볼륨에 따라 스케일 업 및 스케일 다운할 수 있으므로 워크로드 처리 비용과 배포된 애플리케이션의 운영 비용이 절감됩니다.
확장 가능한 시스템 구축
이벤트 기반 아키텍처는 확장성도 뛰어납니다. 다른 팀이 기존 마이크로서비스에 영향을 주지 않고 기능을 확장하고 추가할 수 있습니다. 이벤트를 게시함으로써 애플리케이션을 기존 시스템과 통합할 수 있으며, 향후 기존 솔루션을 변경하지 않고도 애플리케이션을 이벤트 소비자로서 손쉽게 통합할 수 있습니다.
이벤트 생산자는 이벤트 소비자에 대한 지식이 없기 때문에 시스템을 원활하게 확장할 수 있고, 새로운 기능이나 통합을 추가할 때 향후 개발 속도를 저해하는 의존성이 가중되지 않습니다.
복잡성 감소
마이크로서비스를 통해 개발자와 아키텍트는 복잡한 워크플로를 분해할 수 있습니다. 예를 들어 별도의 재고, 이행 및 회계 서비스를 사용하여 전자 상거래 모놀리스를 주문 접수 프로세스와 결제 프로세스로 분해할 수 있습니다.
모놀리스에서 관리하고 오케스트레이션하기가 복잡한 워크로드는 독립적으로 관리되고 이벤트 메시지를 통해 비동기적으로 통신하는 일련의 단순하고 분리된 서비스가 됩니다.
이벤트 기반 접근 방식을 사용하면 서로 다른 속도로 데이터를 처리하는 서비스를 조합하고 오케스트레이션할 수 있습니다. 다음 예제에서 주문 접수 마이크로서비스는 대기열을 통해 결제 처리 시스템과 상호 작용합니다.
이 예에서 주문 접수 서비스는 대기열에 있는 메시지를 버퍼링하여 대량의 수신 주문을 저장할 수 있습니다.
일반적으로 결제 처리의 복잡성으로 인해 속도가 느린 결제 처리 서비스는 대기열에서 안정적으로 메시지를 받을 수 있습니다. 결제 서비스는 재시도 및 오류 처리 로직으로 인해 다양한 시스템 상태 간에 전환됩니다. 워크플로 서비스는 시스템 상태에 따라 결제 단계를 오케스트레이션하고 관리하며, 결과적으로 재고, 이행 및 회계 서비스에 대해 더 많은 관심 이벤트를 생성합니다.
손쉬운 감사
이벤트 기반 아키텍처에서 이벤트 라우터는 애플리케이션을 감사하고 정책을 정의하는 중앙 집중식 로케이션 역할을 합니다. 이러한 정책은 라우터를 게시 및 구독할 수 있는 사용자를 제한하고 데이터에 액세스할 권한이 부여되는 사용자와 리소스를 제어할 수 있습니다. 또한 전송 중인 이벤트와 저장된 이벤트를 모두 암호화할 수 있습니다.
비용 절감
EDA는 푸시 기반이므로, 모든 작업이 이벤트가 라우터에 인식될 때 온디맨드 방식으로 이루어집니다. 이렇게 하면 이벤트를 확인하기 위해 지속적 폴링 비용을 지불할 필요가 없습니다. 즉, 네트워크 대역폭 사용량, CPU 활용률, 유휴 장치 용량 및 SSL/TLS 핸드셰이크가 줄어듭니다.
이벤트 기반 아키텍처(EDA)는 어떻게 작동하나요?
아래는 전자 상거래 사이트를 위한 이벤트 기반 아키텍처(EDA)의 예입니다.
%20for%20an%20ecommerce%20site.88b2240905b1b6addd672871b98bcb17bd44d701.jpg)
이 예제 사이트는 세 가지 주요 이벤트 생산자 구성 요소와 각각에서 생성하는 이벤트를 보여줍니다. 이 시나리오에서 이벤트 라우터는 이벤트를 수집하고 필터링한 다음 이벤트 소비자에게 하나 이상의 이벤트를 전송합니다.
이벤트 기반 아키텍처를 사용하면 애플리케이션이 중단되거나 리소스를 오버프로비저닝하는 일 없이, 피크 시간대에 사이트에서 다양한 원인으로 인한 변화에 대응할 수 있습니다.
이벤트 기반 아키텍처(EDA)에 적합한 워크로드 유형은 무엇인가요?
이벤트 기반 아키텍처(EDA)는 확장성과 가용성이 뛰어난 워크로드의 수요를 충족하는 효과적인 방법을 제공합니다. EDA는 예측 불가능하거나 ‘스파이크’ 트래픽 패턴이 있는 워크로드에도 효과적으로 적용됩니다.
이벤트 기반 아키텍처(EDA)는 애플리케이션을 어떻게 개선하나요?
이벤트 기반 아키텍처(EDA)는 구성 요소 간의 느슨한 결합을 지원하여 현대적 분산 애플리케이션을 구축하는 데 좋은 접근 방식을 제공합니다.
이벤트 생산자는 자신이 생산하는 이벤트에 대한 다운스트림 소비자의 어떠한 활동도 인지하지 않으며 무관심합니다. 이벤트 자체는 상태의 변화를 나타내며 데이터를 포함할 수도 있고 포함하지 않을 수도 있습니다. 이벤트는 그 존재에 따른 결과를 알지 못합니다. 소비자는 관심 있는 이벤트를 수신하고 처리합니다. 새 소비자를 온라인으로 전환하여 기존 워크플로를 중단하지 않고 새로운 기능을 제공할 수 있습니다.
EDA는 모놀리스 시스템을 더 작은 도메인 모델로 분해하도록 지원합니다. 개발자는 더 적은 인지 부하로 속도를 높이고 더 빨리 생산성을 높일 수 있습니다. 중요한 기능이 분리되면 업데이트 및 새 기능을 배포할 위험도 줄어듭니다.
이벤트 기반 아키텍처(EDA)의 사용 사례는 어떤 것들이 있나요?
웹 및 모바일 백엔드를 위한 마이크로서비스 통신
소매 또는 미디어 및 엔터테인먼트 웹 사이트는 예측 불가능한 트래픽을 처리하기 위해 확장해야 하는 경우가 많습니다. 고객이 전자 상거래 웹 사이트를 방문하여 주문을 합니다. 주문 이벤트가 이벤트 라우터로 전송됩니다. 모든 다운스트림 마이크로서비스는 처리를 위해 주문 이벤트를 픽업할 수 있습니다. 예를 들어 주문 제출, 결제 승인, 배송업체에 주문 세부 정보 전송 등이 있습니다.
각 마이크로서비스는 독립적으로 확장되고 장애를 일으킬 수 있으므로 단일 장애 지점 없이 주문량이 많은 기간 동안 프로세스를 확장할 수 있습니다.
비즈니스 워크플로 자동화
금융 서비스 트랜잭션과 같은 많은 비즈니스 워크플로에서는 동일한 단계를 반복해야 합니다. 이벤트 기반 아키텍처(EDA)를 사용하여 이러한 단계를 시작하고 자동화할 수 있습니다.
예를 들어 고객이 은행에 새 계좌를 신청할 때 은행은 몇 가지 데이터 확인(신분증명서, 주소 등)을 실행해야 합니다. 일부 계좌에는 수동 승인 단계도 필요합니다. 신규 계좌 신청이 수신되면 자동으로 단계를 실행하는 워크플로 서비스를 통해 이러한 모든 단계를 오케스트레이션할 수 있습니다.
또한 고객 애플리케이션 데이터를 기계 학습과 비동기식으로 처리하여 관련 데이터를 추출하는 워크플로를 추가하여 수동 데이터 수집 및 검증 시간을 절약할 수 있습니다.
SaaS 애플리케이션 통합
서비스형 소프트웨어(SaaS) 환경의 최대 과제는 사용자 활동 및 데이터에 대한 가시성 부족입니다. 이벤트 기반 아키텍처는 사일로화된 데이터를 활용하기 위해 SaaS 애플리케이션 이벤트를 수집하거나 이벤트를 해당 SaaS 애플리케이션으로 전송할 수 있습니다. 예를 들어 미들웨어를 구축하여 들어오는 파트너 주문 데이터를 수집하고 주문을 사내 주문 처리 애플리케이션으로 직접 보낼 수 있습니다.
인프라 자동화
컴퓨팅 집약적인 워크로드(예: 재무 분석, 게놈 연구 또는 미디어 트랜스코딩)를 실행할 때 병렬 처리를 위해 스케일 업한 다음 작업이 완료된 후 스케일 다운하여 컴퓨팅 리소스에 응답하도록 할 수 있습니다.
예를 들어 규제가 심한 산업에서는 EDA를 보유한 기업이 사고에 대응하여 보안 포스처 리소스를 증가시키거나 보안 정책이 경고 이벤트를 보낼 때마다 교정 조치를 취할 수 있습니다.
이벤트 기반 아키텍처(EDA)는 어떤 경우에 사용해야 하나요?
이벤트 기반 아키텍처(EDA)는 민첩성을 높이고 변화에 신속하게 대응하는 데 적합합니다. 마이크로서비스를 사용하는 현대적인 애플리케이션이나 분리된 구성 요소가 있는 애플리케이션에서 흔히 볼 수 있습니다.
이기종 시스템의 통합
시스템이 서로 다른 스택에서 실행 중인 경우 결합하지 않은 상태로 EDA를 사용하여 시스템 간에 정보를 공유할 수 있습니다. 이벤트 라우터가 시스템 간의 간접성과 상호 운용성을 설정하므로, 독립성을 유지하면서 메시지와 데이터를 교환할 수 있습니다.
리전 간, 계정 간 데이터 복제
EDA를 사용하여 여러 AWS 리전과 계정에서 운영 및 배포하는 팀 간에 시스템을 조율할 수 있습니다. 이벤트 라우터를 사용하여 시스템 간에 데이터를 전송하면 다른 팀과 독립적으로 서비스를 개발하고 크기 조정하고 배포할 수 있습니다.
리소스 상태 모니터링 및 알림
리소스를 지속적으로 확인하는 것이 아니라, EDA를 사용하여 이상 징후, 변경 사항 및 업데이트에 대한 알림을 모니터링하고 수신할 수 있습니다. 이러한 리소스에는 스토리지 버킷, 데이터베이스 테이블, 서버리스 함수, 컴퓨팅 노드 등이 포함될 수 있습니다.
팬아웃 및 병렬 처리
이벤트에 반응하여 작동해야 하는 시스템이 많은 경우 EDA를 사용하여 각 소비자에게 푸시할 사용자 지정 코드를 작성할 필요 없이 이벤트를 팬아웃할 수 있습니다. 라우터가 이벤트를 시스템에 푸시하면, 각 시스템이 각각 다른 목적으로 이벤트를 병렬로 처리할 수 있습니다.
이벤트 기반 아키텍처(EDA)의 일반적인 패턴은 무엇인가요?
많은 수의 짧은 함수
소수의 큰 함수가 아니라 많은 수의 짧은 함수를 만듭니다. 워크로드에 매우 특화된 기능으로 만들 경우, 기능이 간결해지고 일반적으로 처리 시간이 단축됩니다. 각 함수는 전체 워크플로 또는 트랜잭션 볼륨에 대한 지식이나 기대 없이 함수에 전달된 이벤트를 처리해야 합니다. 따라서 다른 서비스와의 결합을 최소화하면서 기능이 이벤트 소스에 구애받지 않습니다.
배치 처리가 아닌 온디맨드 처리
많은 기존 시스템은 주기적으로 실행되고 시간이 지남에 따라 누적되는 트랜잭션 배치를 처리하도록 설계되었습니다. 예를 들어 은행 애플리케이션은 ATM 거래를 중앙 장부로 처리하기 위해 매시간 실행될 수 있습니다.
이벤트 기반 아키텍처(EDA)에서는 사용자 지정 처리를 통해 모든 이벤트에 대응할 수 있습니다. 따라서 이 서비스는 거의 실시간으로 트랜잭션을 처리하는 데 필요한 동시성을 확장할 수 있습니다.
중단 복구
중단된 경우 서비스를 자동으로 호출하여 이벤트 처리를 다시 시도할 수 있습니다. 서비스가 동일한 이벤트를 두 번 이상 수신할 수 있으므로 설계 함수는 멱등 함수입니다. 이렇게 하면 서비스가 이벤트를 처음 수신한 후에 결과가 바뀌지 않습니다.
예를 들어 소매업체가 재시도로 인해 신용카드를 두 번 처리하려고 하면 서비스는 첫 번째 시도에서만 결제를 처리합니다. 재시도 시 서비스는 결제 상태를 확인하고 이벤트를 폐기합니다.
이벤트 기반 아키텍처(EDA)의 당면 과제는 무엇인가요?
이벤트 기반 아키텍처(EDA)를 도입할 경우 애플리케이션 설계 방식을 재고해야 할 수도 있습니다.
가변적인 지연 시간
단일 디바이스에서 동일한 메모리 공간 내에서 모든 것을 처리할 수 있는 모놀리스 애플리케이션과 달리 이벤트 기반 애플리케이션은 네트워크를 통해 통신합니다. 이 설계에서는 가변 지연 시간이 나타납니다. 모놀리스 애플리케이션은 지연 시간이 더 짧거나 덜 가변적일 수 있지만, 일반적으로 확장성과 가용성이 더 낮습니다.
서버리스 AWS 서비스는 가용성이 높으므로 AWS 리전에 있는 둘 이상의 가용 영역에서 작동합니다. 서비스가 중단될 경우 서비스는 자동으로 대체 가용 영역으로 장애 조치하고 트랜잭션을 재시도합니다. 따라서 트랜잭션이 실패하는 대신 성공적으로 완료되지만 지연 시간이 길어질 수 있습니다.
일관된 짧은 지연 시간이 요구되는 워크로드는 EDA에 적합하지 않습니다. 두 가지 예는 은행의 고빈도 거래 애플리케이션 또는 웨어하우스에서의 밀리초 미만의 로봇 자동화입니다.
최종 일관성
이벤트는 상태 변경을 나타냅니다. 특정 시점에 아키텍처의 다양한 서비스를 통해 많은 이벤트가 흐르기 때문에 이러한 워크로드는 최종 일관성을 갖는 경우가 많습니다. 따라서 트랜잭션을 처리하거나, 중복을 처리하거나, 시스템의 정확한 전체 상태를 확인하기가 더욱 복잡해집니다.
ACID 속성이 필요한 일부 워크로드는 EDA에 적합하지 않습니다. 하지만 많은 워크로드는 최종 일관성 요구 사항(예: 현재 시간 내 총 주문) 또는 고도의 일관성 요구 사항(예: 현재 재고)을 포함합니다. 강력한 데이터 일관성이 필요한 기능을 지원하는 아키텍처 패턴이 있습니다. 예:
- DynamoDB는 강력히 일관된 읽기를 제공할 수 있고, 경우에 따라 지연 시간이 더 길어질 수 있으며, 트랜잭션을 지원하여 데이터 일관성을 유지할 수 있습니다.
- 관계형 데이터베이스는 NoSQL 데이터 저장소보다 확장성이 낮지만, ACID 속성이 필요한 기능에 관계형 데이터베이스를 사용할 수 있습니다.
호출자에게 값 반환
대부분의 경우 이벤트 기반 애플리케이션은 비동기식입니다. 즉, 호출자 서비스는 다른 작업을 계속하기 전에 다른 서비스의 요청을 기다리지 않습니다. 이러한 EDA의 기본 특성은 확장성과 유연성을 제공하지만 동기 흐름에서보다 반환 값이나 워크플로 결과를 전달하기가 더 복잡해집니다.
대부분의 경우 값을 반환하는 것은 이벤트 처리의 성공 또는 실패를 보장하는 것보다 덜 중요합니다. 이벤트 처리를 보장하는 기능이 호출자에게 값을 반환하는 것보다 더 중요할 수 있습니다.
웹 및 모바일 애플리케이션과 같은 대화형 워크로드의 경우 일반 사용자는 일반적으로 반환 값 또는 트랜잭션의 현재 상태를 수신할 것으로 예상합니다. 이러한 워크로드의 경우, 호출자에게 풍부한 이벤트를 제공할 수 있는 몇 가지 설계 패턴이 있습니다. 하지만 이벤트 기반 아키텍처에서 이러한 구현 방식은 기존의 비동기식 반환 값을 사용하는 것보다 더 복잡합니다. 플랫폼은 대개 이러한 복잡성을 완화할 수 있습니다.
여러 서비스 및 기능의 디버깅
이벤트 기반 시스템을 디버깅하는 것은 단일 애플리케이션을 디버깅하는 것과는 다릅니다. 모든 마이크로서비스 기반 애플리케이션 및 다양한 시스템/서비스 전달 이벤트와 마찬가지로, 오류가 발생할 때 여러 서비스의 정확한 상태를 기록하고 재생성하기가 어려울 수 있습니다. 각 서비스 및 기능 호출에는 별도의 로그 파일이 있기 때문에 오류를 일으킨 특정 이벤트에서 무슨 일이 일어났는지 확인하기가 더 복잡할 수 있습니다.
오케스트레이션
단순한 워크플로는 일반적으로 시간이 지남에 따라 더 복잡해집니다. 일반적인 모놀리스에서, 이는 더 긴밀하게 결합된 기능 및 서비스 그룹과 라우팅 및 예외를 처리하는 복잡한 코드를 초래할 수 있습니다.
시스템 상태를 추적하기 위해 분기 로직, 다양한 유형의 장애 모델 및 재시도 로직을 포함하는 워크플로는 일반적으로 오케스트레이터를 사용합니다. 이벤트 기반 서버리스 애플리케이션을 만들 때는 적절한 오케스트레이션을 위해 이 로직을 상태 시스템으로 마이그레이션할 수 있도록 이러한 상황이 언제 발생하는지 파악하는 것이 중요합니다.
이벤트 기반 아키텍처(EDA)를 사용하는 AWS 서비스는 무엇인가요?
AWS 서비스는 일반적으로 이벤트를 생성하거나 소비하므로 이벤트 기반 아키텍처(EDA)로 솔루션을 손쉽게 구축할 수 있습니다.
또한 Amazon EventBridge, Amazon SNS, Amazon SQS, AWS Step Functions 등의 서비스에는 고객이 작성해야 하는 상용 코드를 줄이고 EDA를 보다 빠르게 구축할 수 있는 기능이 포함되어 있습니다.
Amazon EventBridge
Amazon EventBridge를 사용하면 SaaS 애플리케이션, 다른 AWS 서비스 또는 사용자 지정 애플리케이션의 이벤트를 사용하여 이벤트 기반 애플리케이션을 위한 이벤트 버스를 대규모로 구축할 수 있습니다.
EventBridge는 이벤트 소스에서 다른 대상으로 이벤트를 라우팅하는 데 규칙을 적용합니다. 대상에는 AWS Lambda, Step Functions 및 Amazon Kinesis와 같은 AWS 서비스 또는 EventBridge API 대상을 통한 HTTP 엔드포인트가 포함될 수 있습니다.
EDA 사용 사례의 인기 있는 통합 기능은 이벤트가 특정 워크플로를 트리거하는 Step Functions입니다.
AWS Step Functions
AWS Step Functions에는 구축자가 다양한 AWS 서비스를 조정하는 데 사용하는 로우 코드 시각적 워크플로 디자이너인 Workflow Studio가 포함됩니다. Workflow Studio를 사용하여 AWS 서비스를 기반으로 분산 애플리케이션을 구축하고, IT 및 비즈니스 프로세스를 자동화하며, 데이터 및 기계 학습 파이프라인을 구축할 수 있습니다.
Amazon SNS
다른 애플리케이션, 마이크로서비스 또는 AWS 서비스에서 게시하는 높은 처리량과 짧은 지연 시간에 대응하는 애플리케이션을 구축하려면 Amazon Simple Notification Service(Amazon SNS)를 사용하는 것이 좋습니다. 또한 수천 또는 수백만 개의 엔드포인트에 대한 매우 높은 팬아웃이 필요한 애플리케이션에도 Amazon SNS를 사용할 수 있습니다.
Amazon SQS
Amazon Simple Queue Service(Amazon SQS)는 분산 소프트웨어 시스템 및 구성 요소를 통합하고 분리하는 데 사용할 수 있는 안전하고 내구성이 뛰어난 사용 가능한 호스트 대기열 서비스를 제공합니다. Amazon SQS는 DLQ(Dead Letter Queue) 및 비용 할당 태그와 같은 일반적인 구조를 제공합니다.
