무료로 AWS 시작하기

무료 계정 생성
또는 콘솔에 로그인

AWS 프리 티어에는 Amazon ElastiCache와 함께 750시간의 마이크로 캐시 노드가 포함되어 있습니다.

AWS 프리 티어 세부 정보 보기 »

Q: Amazon SQS란 무엇입니까?

Amazon Simple Queue Service(Amazon SQS)는 처리되길 기다리는 메시지를 저장하는 메시지 대기열에 대한 액세스를 제공하는 웹 서비스입니다. Amazon SQS에서는 어느 컴퓨터에서나 실행할 수 있는 메시지 대기열 애플리케이션을 신속하게 구축할 수 있습니다.

Amazon SQS는 컴퓨터 간에 전송 중인 메시지를 저장할 수 있는 안정적이고 고도로 확장 가능하며 호스팅된 대기열을 제공합니다. Amazon SQS에서는 메시지를 손실하거나 각 구성 요소를 항상 가용 상태로 유지하지 않고도 다양한 분산 애플리케이션 구성 요소 간에 데이터를 이동할 수 있습니다.

Amazon SQS를 사용하면 비결합된 구성 요소로 분산 애플리케이션을 구축하고 Amazon Elastic Compute Cloud(EC2) 및 다른 AWS 인프라 웹 서비스와 긴밀하게 연동할 수 있습니다.

Q: Amazon SQS로 어떤 작업을 수행할 수 있습니까?

Amazon SQS는 확장성이 뛰어나므로 사용량에 대해서만 요금을 지불하면 됩니다. 작은 규모로 시작하여 비즈니스의 필요에 따라 성능 또는 안정성의 희생 없이 애플리케이션을 확장할 수 있습니다. Amazon SQS를 사용하면 메시지가 어떻게 저장되고 관리되는지 신경 쓸 필요가 없으므로 강력하고 정교한 메시지 기반 애플리케이션을 구축하는 데 집중할 수 있습니다.

몇 가지 아이디어:

  • Amazon SQS를 다른 AWS 서비스와 통합해 애플리케이션의 유연성과 안정성을 향상할 수 있습니다.
  • Amazon SQS를 사용하여 작업 대기열을 생성할 수 있으며 이때 각 메시지는 프로세스가 완료해야 할 작업입니다. 하나 이상의 컴퓨터가 이 메시지 대기열에서 작업을 읽은 후 처리할 수 있습니다.
  • 마이크로 서비스 아키텍처를 구축하고 메시지 대기열을 사용하여 마이크로 서비스를 연결할 수 있습니다.
  • Amazon SQS 메시지 대기열에 중요한 비즈니스 이벤트 알림을 유지할 수 있습니다. 각 이벤트는 해당 메시지를 메시지 대기열에 올릴 수 있고, 그러면 이벤트를 인식해야 하는 애플리케이션이 메시지를 읽고 처리할 수 있습니다.

Q: Amazon SQS를 시작하려면 어떻게 해야 합니까?

Amazon SNS 대기열을 생성하고 Send Messages Between Distributed Applications 10분 자습서를 완료하여 몇 단계만에 메시지를 게시할 수 있습니다.

자세한 내용은 Amazon SQS Developer Guide리소스 센터의 샘플 코드를 참조하십시오.

Q: 자체 개발 또는 패키지 메시지 대기열 시스템과 비교하여 Amazon SQS의 이점은 무엇입니까?

Amazon SQS는 자체 소프트웨어를 구축하여 메시지 대기열을 관리하거나 개발과 구성에 상당한 사전 시간 투자가 필요한 상용 또는 오픈 소스 메시지 대기열 시스템을 사용하는 것에 비해 몇 가지 이점을 제공합니다.

이러한 대안에는 지속적인 하드웨어 유지 관리 및 시스템 관리 리소스가 필요합니다. 하드웨어에 장애가 발생했을 때 메시지 손실을 막기 위해서는 메시지의 중복 스토리지가 필요하므로 이러한 시스템을 구성 및 관리하는 복잡성은 더 커집니다.

하지만 Amazon SQS는 이런 관리 부담이 없고 최소한의 구성으로 바로 사용할 수 있습니다. Amazon SQS는 방대한 규모를 지원하므로 하루에 수십억 건의 메시지를 처리할 수 있습니다. 별도의 구성 없이 Amazon SQS로 전송하는 트래픽 양을 확장하거나 축소할 수 있습니다. 또한, Amazon SQS에서는 매우 뛰어난 메시지 안정성을 제공하므로 고객과 이해관계자는 안심하고 사용할 수 있습니다.

Q: Amazon SQS는 Amazon SNS와 어떻게 다릅니까?

Amazon SQS와 Amazon SNS는 둘 다 AWS 내 메시징 서비스로, 개발자들에게 서로 다른 이점을 제공합니다. Amazon SNS를 사용하면 애플리케이션에서 정기적으로 업데이트를 확인하거나 "폴링"할 필요 없이 "푸시" 메커니즘을 통해 다수의 구독자에게 시간이 관건인 메시지를 보낼 수 있습니다. Amazon SQS는 분산 애플리케이션에서 폴링 모델을 통해 메시지를 교환하는 데 사용되는 메시지 대기열 서비스입니다. 이 서비스를 통해 송신 구성 요소와 수신 구성 요소를 분리할 수 있습니다. Amazon SQS는 유연하기 때문에 모든 구성 요소를 동시에 사용할 수 없는 경우에도 애플리케이션의 분산 구성 요소가 메시지를 보내고 받을 수 있습니다.

SNS를 사용하는 일반적인 패턴은 메시지를 Amazon SQS 대기열로 게시하여 비동기식으로 하나 이상의 시스템 구성 요소로 안정적으로 전송하는 것입니다. 자세한 내용은 Pub/Sub 메시징은 무엇인가?를 참조하십시오.

Q: Amazon SQS는 Amazon MQ와 어떻게 다릅니까?

Amazon MQ, Amazon SQS 및 Amazon SNS는 신생 기업부터 중견 기업까지 모든 기업에 적합한 메시징 서비스입니다. 쉽고 빠르게 기존에 사용 중인 메시징 애플리케이션에서 클라우드로 이동하고 싶다면, Amazon MQ를 추천합니다. Amazon MQ는 업계 표준 API와 프로토콜을 지원하므로 애플리케이션의 메시징 코드를 다시 작성하지 않고 어떤 표준 메시지 브로커라도 Amazon MQ로 전환할 수 있습니다. 클라우드에 새로운 애플리케이션을 구축한다면 Amazon SQS 및 Amazon SNS를 고려해 보십시오. Amazon SQS 및 SNS는 가벼운 완전 관리형 메시지 대기열 및 주제 서비스로, 간단하고 사용이 쉬운 API를 제공하며 거의 무한히 확장됩니다. Amazon SQS 및 SNS를 사용하여 마이크로 서비스와 분산 시스템, 서버리스 애플리케이션을 분리 및 확장하고 안정성을 개선할 수 있습니다.

Q: Amazon SQS는 메시지 순서화를 제공합니까?

예. FIFO(first-in-first-out) 대기열은 메시지가 전송되고 수신되는 정확한 순서를 보존합니다. FIFO 대기열을 사용하면 메시지에 시퀀싱 정보를 배치할 필요가 없습니다. 자세한 내용은 Amazon SQS Developer GuideFIFO Queue Logic을 참조하십시오.

표준 대기열은 메시지 순서를 보존하려고 시도하는 느슨한 FIFO 기능을 제공합니다. 다만 표준 대기열은 고도의 분산형 아키텍처를 사용한 엄청난 확장이 가능하도록 설계되었기 때문에 전송된 정확한 순서대로 메시지가 수신된다고 보장할 수 없습니다.

Q: Amazon SQS는 메시지 전달을 보장합니까?

표준 대기열은 최소 1회 전달, 즉 각각의 메시지가 최소한 한 번 전달되도록 하는 기능을 제공합니다.

FIFO 대기열은 정확한 1회 처리, 즉 각각의 메시지가 한 번 전달되고 소비자가 이를 처리하고 삭제할 때까지 사용 가능한 상태로 남아 있도록 하는 기능을 제공합니다. 대기열에 중복 메시지가 유입되지 않습니다.

 

Q: Amazon SQS와 Amazon Kinesis Streams는 어떤 차이가 있습니까?

Amazon SQS는 메시지가 애플리케이션 또는 마이크로서비스 간을 이동할 때 메시지를 저장할 수 있는 안정적이고 확장성이 뛰어난 호스팅된 대기열을 제공합니다. 이를 통해 분산된 애플리케이션 구성 요소 간 데이터 이동이 가능하며, 이들 구성 요소를 분리할 수 있습니다. Amazon SQS는 배달 못한 편지 대기열과 포이즌 필(poison-pill) 관리 같은 일반적 미들웨어 구성체를 제공합니다. 또 일반 웹 서비스 API도 제공하며, AWS SDK가 지원하는 프로그래밍 언어를 사용하여 액세스할 수 있습니다. Amazon SQS는 표준 대기열과 FIFO 대기열을 모두 지원합니다.

다음 경우처럼 각각의 고유한 메시지가 한 번만 소비되도록 해야 하는 경우, Amazon SQS를 사용하십시오.

  • 애플리케이션의 구성 요소 분리: 작업 항목 대기열이 있고 각 항목의 성공적 완료를 독립적으로 추적하고자 하는 경우. Amazon SQS는 ACK/FAIL 결과를 추적하므로 애플리케이션은 지속적인 체크포인트/커서를 유지할 필요가 없습니다. 제한 시간 초과를 구성한 후 Amazon SQS는 확인된 메시지를 삭제하고 실패한 메시지를 다시 전달합니다.
  • 개별 메시지 지연 구성: 작업 대기열이 있고 개별 작업들을 지연 시간을 포함해 예약해야 하는 경우. Amazon SQS를 사용하면 최대 15분간의 지연 시간을 갖도록 개별 메시지를 구성할 수 있습니다.
  • 읽기 시간에 동시성 또는 처리량을 동적으로 증대: 작업 대기열이 있고 백로그가 지워질 때까지 더 많은 리더를 추가하려 하는 경우. Amazon Kinesis Streams를 사용하면 샤드의 수를 충분히 늘릴 수 있습니다. 다만 먼저 충분한 수의 샤드를 프로비저닝해야 합니다. Amazon SQS는 사전 프로비저닝이 필요 없습니다.
  • 투명한 확장: 이따금 발생하는 로드 스파이크 또는 비즈니스의 자연스러운 성장으로 인한 요청과 로드 변경 사항을 버퍼링하려는 경우가 이에 속합니다. Amazon SQS는 버퍼링된 요청을 독립적으로 처리할 수 있으므로 사용자의 프로비저닝 명령 없이 로드를 처리하도록 투명하게 확장할 수 있습니다.

Amazon Kinesis Streams는 빅 데이터 스트리밍을 실시간으로 처리하고 여러 Amazon Kinesis Application의 레코드를 읽고 응답할 수 있습니다. Amazon Kinesis Client Library(KCL)는 주어진 파티션 키에 대한 모든 레코드를 동일한 레코드 프로세서에 제공하므로 동일한 Amazon Kinesis 스트림의 데이터를 읽는 여러 개의 애플리케이션을 보다 손쉽게 구축할 수 있습니다(예: 계산, 집계 및 필터링 수행).

여러 소비자가 각각의 레코드를 처리할 수 있도록 해야 하는 경우와 다음과 같은 사용 사례에서는 Amazon Kinesis Streams를 사용하십시오.

  • 관련 레코드를 동일한 레코드 프로세서로 라우팅: MapReduce를 스트리밍. 주어진 키에 대한 모든 레코드가 동일한 레코드 프로세서로 라우팅되면 계산 및 집계가 훨씬 간단합니다.
  • 여러 애플리케이션이 동일한 스트림을 동시에 소비 가능: 실시간 대시보드를 업데이트하는 애플리케이션 하나와 데이터를 Amazon Redshift에 저장하는 또 다른 애플리케이션이 있는 경우. 이 2개의 애플리케이션이 동일한 스트림의 데이터를 동시에 독립적으로 소비하길 원하는 경우가 이에 속합니다.

Q: Amazon은 자체 애플리케이션에 Amazon SQS를 사용하고 있습니까?

예. Amazon의 개발자는 매일 대량의 메시지를 처리하는 다양한 애플리케이션에 Amazon SQS를 사용합니다. Amazon.com과 Amazon Web Services 모두 핵심 비즈니스 프로세스에 Amazon SQS를 사용합니다.


Q: Amazon SQS의 사용료는 얼마입니까?

요금은 사용량에 따라 지불하고 최소 요금이 없습니다.

Amazon SQS의 요금은 요청당 계산되며, Amazon SQS 밖으로 전송되는 데이터에 대해 데이터 전송 요금이 추가됩니다(데이터가 같은 리전 내 Amazon EC2 인스턴스 또는 AWS Lambda 함수로 전송되는 경우는 무료). 대기열 유형과 리전에 따른 자세한 가격 체계는 Amazon SQS Pricing을 참조하십시오.

Q: Amazon SQS 프리 티어의 혜택은 무엇입니까?

Amazon SQS 프리 티어는 매월 1백만 건의 요청을 무료로 제공합니다.

규모가 작은 애플리케이션 대부분은 프리 티어 한도 내에서 모두 운영할 수 있습니다. 하지만 데이터 전송 요금은 그대로 부과될 수 있습니다. 자세한 내용은 Amazon SQS 요금을 참조하십시오.

프리 티어는 월별로 제공되며 무료 사용량은 다음 달로 이월되지 않습니다.

Q: 모든 Amazon SQS 요청에 요금이 부과됩니까?

예, 프리 티어를 초과하는 모든 요청에 요금이 부과됩니다. 모든 Amazon SQS 요청에 요금이 부과되며, 모든 요청은 같은 요율로 청구됩니다.

Q: Amazon SQS 배치 작업은 다른 요청보다 비용이 비쌉니까?

아니요. 배치 작업(SendMessageBatch, DeleteMessageBatch 및 ChangeMessageVisibilityBatch)의 모든 요금도 다른 Amazon SQS 요청과 동일합니다. 메시지를 배치로 그룹화함으로써 Amazon SQS 비용을 줄일 수 있습니다.

Q: Amazon SQS의 사용료는 어떻게 과금 및 청구됩니까?

Amazon SQS 사용을 시작하는 데는 초기 비용이 들지 않습니다. 월말에 사용자의 신용 카드에서 월 사용액이 자동으로 결제됩니다.

언제든지 AWS 웹 사이트에서 현재 청구 기간에 대한 요금을 확인할 수 있습니다.

  1. AWS 계정으로 로그인합니다.
  2. Your Web Services Account 아래에서 Account Activity를 선택합니다.

Q: 내 Amazon SQS 대기열과 관련된 비용을 추적하고 관리하려면 어떻게 해야 합니까?

비용 할당 태그를 사용하여 대기열에 태그를 지정하고 추적하여 리소스 및 비용을 관리할 수 있습니다. 태그는 키 값 페어로 구성된 메타데이터 레이블입니다. 예를 들어 대기열에 비용 센터별 태그를 지정하고 이러한 비용 센터를 기준으로 비용을 분류 및 추적할 수 있습니다.

자세한 내용은 Amazon SQS Developer Guide에서 Tagging Your Amazon SQS Queues를 참조하십시오. AWS 리소스의 비용 할당 태깅에 대한 자세한 내용은 AWS Billing and Cost Management User Guide에서 Using Cost Allocation Tags를 참조하십시오.

Q: 요금에 세금이 포함되어 있습니까?

달리 명시하지 않는 한 요금에는 VAT 또는 해당 판매세를 비롯한 관련 조세 공가가 포함되지 않습니다.

청구지 주소가 일본으로 되어 있는 고객의 경우, 리전과 관계없이 AWS 사용 시 일본 소비세가 적용됩니다. 자세한 내용은 Amazon Web Services 소비세 FAQ를 참조하십시오.


Q: Amazon SQS를 다른 AWS 서비스와 함께 사용할 수 있습니까?

예. Amazon SQS를 Amazon EC2, Amazon EC2 Container Service(ECS) 및 AWS Lambda와 같은 컴퓨팅 서비스뿐만 아니라 Amazon Simple Storage Service(S3), Amazon DynamoDB 등과 같은 스토리지 및 데이터베이스 서비스와 함께 사용하여 애플리케이션의 유연성과 확장성을 높일 수 있습니다.

일반 사용 사례 중 하나는 비결합된 분산 애플리케이션입니다. 이 경우 여러 구성 요소와 모듈이 서로 통신해야 하지만 같은 양의 작업을 동시에 처리할 수는 없습니다. 이 경우 Amazon SQS 메시지 대기열은 Amazon EC2 인스턴스에서 실행되는 애플리케이션에 의해 처리되도록 메시지를 전달합니다.

그러면 Amazon EC2 인스턴스가 대기열을 읽고, 작업을 처리한 다음 다른 Amazon SQS 메시지 대기열에 그 결과를 메시지로 게시할 수 있습니다(예를 들어 이후에 다른 애플리케이션이 추가로 처리할 수 있도록). Amazon EC2를 사용하면 애플리케이션을 동적으로 확장 및 축소할 수 있습니다. 따라서 애플리케이션 개발자는 Auto Scaling을 사용하여 Amazon SQS 대기열의 메시지 양에 따라 컴퓨팅 인스턴스의 수를 변경하여 작업이 적시에 실행되도록 할 수 있습니다.

Q: Amazon SQS 사용 사례의 예를 들어줄 수 있습니까?

동영상 트랜스코딩 웹 사이트에서 Amazon EC2, Amazon SQS, Amazon S3, Amazon DynamoDB를 함께 사용하는 방법을 예로 들어 보겠습니다.

  1. 최종 사용자가 트랜스코딩할 동영상을 웹 사이트에 제출합니다.
  2. 동영상은 Amazon S3에 저장되며 요청 메시지는 수신되는 Amazon SQS 대기열에 배치됩니다. 이때 동영상에 대한 포인터 및 대상 동영상 형식에 대한 포인터가 메시지 내에 포함됩니다.
  3. 그러면 Amazon EC2 인스턴스 세트에서 실행되는 트랜스코딩 엔진이 수신 대기열에서 요청 메시지를 읽고, 포인터를 사용하여 Amazon S3에서 해당 동영상을 검색한 후, 이를 대상 형식으로 트랜스코딩합니다.
  4. 변환된 동영상은 Amazon S3로 반환되고 다른 응답 메시지가 변환된 동영상에 대한 포인터와 함께 다른 발신 Amazon SQS 대기열에 배치됩니다.
  5. 그와 동시에 해당 동영상에 대한 메타데이터(형식, 생성 날짜, 길이 등)가 쿼리를 위해 Amazon DynamoDB로 인덱싱됩니다.

이 워크플로가 진행되는 동안, 전용 Auto Scaling 인스턴스가 수신 대기열을 계속해서 모니터링합니다. Auto Scaling 인스턴스는 웹 사이트 고객의 응답 시간 요구 사항에 맞출 수 있도록 수신 대기열에 있는 메시지 수에 따라 트랜스코딩 Amazon EC2 인스턴스의 수를 동적으로 조정합니다.

Q: Amazon SQS와 상호 작용하려면 어떻게 해야 합니까?

Amazon SQS를 쉽게 생성해 메시지를 보내도록 도와주는 AWS Management Console을 사용하여 Amazon SQS에 액세스할 수 있습니다.

Amazon SQS는 웹 서비스 API도 제공합니다. 이것 역시 AWS SDK와 통합되어 선택한 프로그래밍 언어로 작업이 가능합니다.

Q: 메시지 대기열에 대해 어떤 작업을 수행할 수 있습니까?

메시지 대기열 작업에 대한 자세한 내용은 Amazon SQS 제품 상세 정보를 참조하십시오.

Q: 메시지 대기열에 대한 작업은 누가 수행할 수 있습니까?

AWS 계정 소유자만(또는 계정 소유자가 권한을 위임한 AWS 계정) Amazon SQS 메시지 대기열에 대한 작업을 수행할 수 있습니다.

Q: Java Message Service(JMS)를 Amazon SQS와 함께 사용할 수 있습니까?

예. 자체 JMS 클러스터를 실행하는 부담과 오버헤드 비용 없이 Amazon SQS의 규모, 저렴한 비용 및 높은 가용성을 활용할 수 있습니다.

Amazon에서는 JMS 1.1 사양을 구현하고 Amazon SQS를 JMS 공급자로서 사용하는 Amazon SQS Java 메시징 라이브러리를 제공합니다. 자세한 내용은 Amazon SQS Developer GuideUsing JMS with Amazon SQS를 참조하십시오.

Q: Amazon SQS는 어떻게 메시지를 식별합니까?

모든 메시지에는 메시지가 메시지 대기열로 전송될 때 Amazon SQS가 반환하는 전 세계적으로 고유한 ID가 있습니다. 이 ID는 메시지에 추가 작업을 수행할 때는 필요 없지만, 메시지 대기열에서 특정 메시지의 수신을 추적할 때는 유용합니다.

메시지 대기열에서 메시지를 수신할 때 응답에는 메시지 삭제 시 꼭 필요한 수신 핸들이 포함됩니다.

Q: Amazon SQS는 성공적으로 처리되지 않은 메시지를 어떻게 다룹니까?

Amazon SQS에서는 API 또는 콘솔을 사용하여 배달 못한 편지 대기열을 구성할 수 있습니다. 배달 못한 편지 대기열은 다른 소스 대기열에서 메시지를 수신하는 대기열을 말합니다.

대기열을 배달 못한 편지 대기열로 만드는 경우, 배달 못한 편지 대기열은 최대 처리 시도 횟수를 완료할 수 없게 된 후에 메시지를 수신합니다. 이후 분석을 위해 배달 못한 편지 대기열을 사용하여 처리되지 못한 메시지를 격리할 수 있습니다.

자세한 내용은 이 페이지의 "FIFO 대기열과 함께 배달 못한 편지 대기열을 사용할 수 있습니까?"와 Amazon SQS Developer GuideUsing Amazon SQS Dead Letter Queues를 참조하십시오.

Q: 제한 시간 초과란 무엇입니까?

제한 시간 초과는 Amazon SQS가 메시지를 소비하는 다른 구성 요소에서 메시지를 수신 및 처리하지 못하도록 하는 기간입니다. 자세한 내용은 Amazon SQS Developer GuideVisibility Timeout을 참조하십시오.

Q: Amazon SQS는 여러 리더가 동일한 메시지 대기열에 액세스하는 경우 어떻게 메시지 손실이나 중복 처리를 방지합니까?

모든 Amazon SQS 대기열에 제한 시간 초과를 구성할 수 있습니다. 메시지 대기열의 메시지를 읽을 때는 지정된 시간 동안 다른 리더에게는 해당 메시지가 보이지 않습니다. 제한 시간 초과 내에 메시지를 처리하는 한, 모든 메시지가 처리되고 삭제됩니다.

그리고 해당 메시지를 처리하는 구성 요소에 오류가 발생하거나 이 구성 요소를 사용할 수 없게 되는 경우, 제한 시간 초과가 종료되면 메시지가 다시 표시되어 어떤 구성 요소든 대기열에서 이를 읽을 수 있습니다. 이를 통해 여러 구성 요소가 같은 메시지 대기열에서 메시지를 읽고 각각 서로 다른 메시지를 처리할 수 있습니다.

Q: 메시지 가시성 최대 제한 시간은 어떻게 됩니까?

Amazon SQS 메시지의 최대 제한 시간 초과는 12시간입니다.

Q: Amazon SQS는 메시지 메타데이터를 지원합니까?

예. Amazon SQS는 메시지는 최대 10개의 메타데이터 속성을 포함할 수 있습니다. 메시지 속성을 사용하여 메시지를 설명하는 메타데이터에서 메시지의 본문을 분리할 수 있습니다. 이렇게 하면 애플리케이션이 메시지를 어떻게 처리할지 파악하기 전에 전체 메시지를 검사할 필요가 없으므로 정보를 더욱 빠르고 효율적으로 처리하고 저장할 수 있습니다.

Amazon SQS 메시지 속성은 이름-유형-값이라는 3개 부분으로 이루어진 형식을 갖추고 있습니다. 지원되는 유형에는 문자열, 바이너리 및 숫자(정수, 부동 소수점 및 실수 포함)가 포함됩니다. 자세한 내용은 Amazon SQS Developer GuideUsing Amazon SQS Message Attributes를 참조하십시오.

Q: 대기열 체류 시간 값을 결정하려면 어떻게 해야 합니까?

대기열 체류 시간 값을 결정하려면 메시지를 수신할 때 SentTimestamp 속성을 요청하면 됩니다. 현재 시간에서 해당 값을 빼면 대기열 체류 시간 값이 됩니다.

Q: Amazon SQS의 일반적인 지연 시간은 어떻게 됩니까?

SendMessage, ReceiveMessage 및 DeleteMessage API 요청의 일반적인 지연 시간은 수십 밀리초이거나 백여 밀리초입니다.

Q: 익명 액세스의 경우 메시지의 SenderId 속성 값은 무엇입니까?

AWS 계정 ID를 사용할 수 없을 때(예를 들어 익명의 사용자가 메시지를 전송할 때) Amazon SQS에서는 IP 주소를 제공합니다.

Q: Amazon SQS 긴 폴링이란 무엇입니까?

Amazon SQS 긴 폴링은 Amazon SQS 대기열에서 메시지를 검색하는 방법입니다. 일반 짧은 폴링은 폴링되는 메시지 대기열이 비어 있는 경우에도 즉각 응답을 반환하는 반면, 긴 폴링은 메시지가 메시지 대기열에 도달하거나 긴 폴링 제한 시간이 초과할 때까지 응답을 반환하지 않습니다.

긴 폴링을 사용하면 Amazon SQS 대기열에서 메시지가 사용 가능해지는 즉시 간편하고 경제적인 방법으로 메시지를 검색할 수 있습니다. 긴 폴링을 사용하면 빈 응답을 수신하는 횟수를 줄일 수 있으므로 SQS 사용 비용을 절감할 수 있습니다. 자세한 내용은 Amazon SQS Developer GuideAmazon SQS Long Polling을 참조하십시오.

Q: Amazon SQS 긴 폴링 사용에 대한 추가 요금이 있습니까?

아니요. 긴 폴링 ReceiveMessage 호출에는 짧은 폴링 ReceiveMessage 호출과 정확히 동일한 요금이 부과됩니다.

Q: 언제 Amazon SQS 긴 폴링을 사용하고 언제 Amazon SQS 짧은 폴링을 사용해야 합니까?

거의 모든 경우 Amazon SQS 짧은 폴링보다 긴 폴링을 사용하는 것이 좋습니다. 긴 폴링 요청을 사용하면 대기열 소비자가 대기열에 메시지가 도착하는 대로 이를 수신할 수 있으므로 빈 ReceiveMessageResponse 인스턴스가 반환되는 횟수가 줄어듭니다.

Amazon SQS 긴 폴링은 대부분의 사용 사례에서 비용은 감소하고 성능은 향상되는 결과를 보입니다. 하지만 애플리케이션이 ReceiveMessage 호출에서 즉각적인 응답을 요구하는 경우, 긴 폴링의 이점을 활용하려면 애플리케이션을 일부 수정해야 할 수도 있습니다.

예를 들어 애플리케이션에서 단일 스레드를 사용하여 여러 대기열을 폴링하는 경우, 단일 스레드는 빈 대기열에 대한 긴 폴링의 제한 시간이 끝나기를 기다리게 됩니다. 이로 인해 짧은 폴링에서 긴 폴링으로의 전환이 제대로 수행되지 않아 실제로 메시지가 들어 있는 대기열의 처리가 지연될 수 있습니다.

이러한 애플리케이션에서는 단일 스레드로 하나의 대기열만 처리하여 애플리케이션이 Amazon SQS 긴 폴링이 제공하는 이점을 활용하도록 하는 것이 좋습니다.

Q: 긴 폴링 제한 시간에 어떤 값을 사용해야 합니까?

일반적으로 최대 20초의 긴 폴링 제한 시간을 사용해야 합니다. 긴 폴링 제한 시간 값이 클수록 빈 ReceiveMessageResponse 인스턴스가 반환되는 빈도가 감소하므로 긴 폴링 제한 시간을 가능한 한 길게 설정하는 것이 좋습니다.

최댓값인 20초가 사용자의 애플리케이션에 적합하지 않은 경우(이전 질문의 예제 참조), 긴 폴링 제한 시간을 더 짧게 설정하십시오(최하 1초).

모든 AWS SDK는 기본적으로 20초의 긴 폴링으로 작동됩니다. Amazon SQS에 액세스하는 데 AWS SDK를 사용하지 않거나 AWS SDK의 제한 시간을 특별히 더 짧게 구성한 경우, 더 긴 요청을 허용하도록 Amazon SQS 클라이언트를 수정하거나 더 짧은 긴 폴링 제한 시간을 사용해야 할 수도 있습니다.

Q: Java용 AmazonSQSBufferedAsyncClient란 무엇입니까?

Java용 AmazonSQSBufferedAsyncClient는 AmazonSQSAsyncClient 인터페이스의 구현을 제공하고 몇 가지 중요한 기능을 추가로 제공합니다.

  • 애플리케이션을 변경할 필요 없이 여러 개의 SendMessage, DeleteMessage 또는 ChangeMessageVisibility 요청을 자동 배치
  • 애플리케이션이 Amazon SQS에서 메시지가 검색될 때까지 기다리지 않고 메시지를 즉시 처리할 수 있도록 로컬 버퍼로 메시지를 프리페치

자동 배치와 프리페치를 함께 사용하면 Amazon SQS 요청 빈도를 줄여 비용을 절감하면서 애플리케이션의 처리량을 높이고 지연 시간은 줄일 수 있습니다. 자세한 내용은 Amazon SQS Developer GuideClient-Side Buffering and Request Batching을 참조하십시오.

현재 Amazon SQS Buffered Asynchronous Client에서는 FIFO 대기열을 지원하지 않습니다.

Q: Java용 AmazonSQSBufferedAsyncClient는 어디에서 다운로드할 수 있습니까?

AmazonSQSBufferedAsyncClient는 Java용 AWS SDK의 일부로서 다운로드할 수 있습니다.

Q: Java용 AmazonSQSBufferedAsync 클라이언트를 사용하려면 애플리케이션을 다시 작성해야 합니까?

아니요. Java용 AmazonSQSBufferedAsyncClient는 기존 AmazonSQSAsyncClient를 즉시 대체할 수 있도록 구현되었습니다.

최신 AWS SDK를 사용하도록 애플리케이션을 업데이트하고 AmazonSQSAsyncClient 클라이언트 대신 Java용 AmazonSQSBufferedAsync 클라이언트를 사용하도록 클라이언트를 변경하면, 애플리케이션에서 자동 배치 및 프리페치라는 추가적인 혜택을 받게 됩니다.

Q: Amazon SQS 메시지 대기열을 구독하여 Amazon SNS 주제 알림을 수신하려면 어떻게 해야 합니까?

  1. Amazon SQS 콘솔에서 Amazon SQS standard queue를 선택합니다.
  2. Queue Actions 아래에 있는 드롭다운 목록에서 Subscribe Queue to SNS Topic을 선택합니다.
  3. 대화 상자의 Choose a Topic 드롭다운 목록에서 주제를 선택한 후 Subscribe를 클릭합니다.

자세한 내용은 Amazon SQS Developer GuideSubscribing a Queue to an Amazon SNS Topic을 참조하십시오.

Q: 동일한 메시지를 여러 Amazon SQS 대기열로 팬아웃하려면 어떻게 해야 합니까?

  1. Amazon SNS를 사용하여 주제를 생성합니다.
  2. 여러 Amazon SQS 표준 대기열을 생성하고 Amazon SNS 주제를 구독합니다.
  3. 메시지가 Amazon SNS 주제로 전송될 때마다 Amazon SQS 메시지 대기열로 메시지가 팬아웃됩니다.

Amazon SNS는 주제를 구독한 모든 Amazon SQS 메시지 대기열로 메시지를 전송합니다.

Q: Amazon SNS는 Amazon SQS 대기열에 대한 최소 1회 메시지 전달을 제공합니까?

Amazon SNS는 각 메시지가 Amazon SQS 표준 대기열에 최소한 한 번은 전달되도록 설계되었습니다.

Q: 메시지 대기열 자체를 삭제하지 않고 메시지 대기열의 모든 메시지를 삭제할 수 있습니까?

예. PurgeQueue 작업을 사용하여 Amazon SQS 메시지 대기열에 있는 모든 메시지를 삭제할 수 있습니다.

메시지 대기열을 비우면 이전에 메시지 대기열로 전송된 모든 메시지가 삭제됩니다. 메시지 대기열과 해당 속성은 그대로 유지되므로 메시지 대기열을 다시 구성할 필요 없이 계속 사용할 수 있습니다.

특정 메시지만 삭제하려면 DeleteMessage 또는 DeleteMessageBatch 작업을 사용합니다.


Q: 표준 대기열FIFO 대기열의 차이점은 무엇입니까?

표준 대기열

Amazon SQS가 제공하는 기본 대기열 유형은 표준 대기열입니다. 표준 대기열은 거의 무제한의 초당 트랜잭션 수를 제공합니다. 표준 대기열은 메시지가 최소 1회 전달되는 것을 보장합니다. 하지만 때때로(높은 처리량을 가능케 하는 고도로 분산된 아키텍처로 인해) 하나 이상의 메시지 사본이 잘못된 순서로 전달될 수 있습니다. 표준 대기열은 메시지가 송신된 순서와 전반적으로 동일하게 전달되는 최선 노력(best-effort) 순서화를 제공합니다.

sqs-what-is-sqs-standard-queue-diagram

한 번 이상 잘못된 순서로 도착하는 메시지를 애플리케이션에서 다음과 같이 처리할 수 있다면 여러 시나리오에서 표준 메시지 대기열을 사용할 수 있습니다.

  • 실시간 사용자 요청을 집중적 백그라운드 작업과 분리: 사용자들이 미디어 크기를 조정하거나 인코딩하면서 미디어를 업로드할 수 있게 합니다.
  • 작업을 여러 작업자 노드에 할당: 많은 수의 신용 카드 인증 요청을 처리합니다.
  • 장래 처리를 위한 메시지 배치: 데이터베이스에 여러 항목이 추가되도록 예약합니다.

FIFO 대기열

이 대기열 유형의 가장 중요한 특징은 FIFO(선입 선출) 전달 정확히 한 번 처리입니다. 메시지 송신 및 수신 순서가 엄격히 보존되며, 메시지는 한 번 전달되어 소비자가 이를 처리하고 삭제할 때까지 계속 사용 가능합니다. 대기열에 중복 메시지가 유입되지 않습니다. 또한, FIFO 대기열은 단일 대기열 내에 순서화된 여러 메시지 그룹을 허용합니다. FIFO 대기열은 API 작업별로 초당 300회의 트랜잭션(TPS)으로 제한되지만 표준 대기열이 지원하는 모든 기능을 가지고 있습니다.

sqs-what-is-sqs-fifo-queue-diagram



FIFO 대기열은 다음과 같이 작업 및 이벤트 순서가 중요하거나 중복이 허용되지 않는 경우, 애플리케이션 간 메시징을 향상시키도록 설계되었습니다.

  • 사용자가 입력한 명령이 올바른 순서로 실행되도록 해야 하는 경우.
  • 가격 수정을 올바른 순서로 전송하여 제품 가격을 정확히 표시해야 하는 경우.
  • 계정에 등록하기 전에 학생이 과정에 등록되는 것을 방지해야 하는 경우.

Q: FIFO 대기열을 지원하는 리전은 어디입니까?

FIFO 대기열은 현재 미국 서부(오레곤), 미국 동부(오하이오), 미국 동부(버지니아 북부) 및 EU(아일랜드) 리전에서 사용할 수 있습니다. 이 기능은 앞으로 몇 달에 걸쳐 더 많은 리전에서 지원할 예정입니다.

Q: 메시지 사본을 몇 개 수신하게 됩니까?

FIFO 대기열은 중복 메시지가 절대 유입되지 않도록 설계되었습니다. 다만 일부 시나리오에서는 메시지 생산자가 중복 메시지를 유입할 수도 있습니다. 가령 생산자가 메시지를 보내고 응답을 받지 못하는 경우에 동일한 메시지를 다시 보내는 경우가 그렇습니다. Amazon SQS API는 메시지 생산자가 중복 메시지를 보내는 것을 방지하는 중복 제거 기능을 제공합니다. 메시지 생산자에 의해 유입되는 중복 메시지는 5분 간격의 중복 제거 기간 내에 제거됩니다.

표준 대기열의 경우, 메시지의 중복 사본을 수신할 수 있습니다(최소 1회 전달). 표준 대기열을 사용하는 경우, 애플리케이션을 idempotent(즉, 같은 메시지를 여러 번 처리하더라도 부정적인 영향을 미쳐서는 안 됨) 방식으로 설계해야 합니다.

Q: 전에 사용하던 Amazon SQS 대기열이 FIFO 대기열로 바뀌었나요?

아니요. Amazon SQS 표준 대기열(기존 대기열의 새 이름)은 바뀌지 않았고 여전히 표준 대기열을 생성할 수 있습니다. 이 대기열은 최고의 확장성과 처리량을 계속 제공합니다. 다만 순서화는 보장할 수 없고 중복이 발생할 수 있습니다.

표준 대기열은 여러 idempotent 소비자에 대한 작업 배포 같은 여러 시나리오에 적합합니다.

Q: 기존 표준 대기열을 FIFO 대기열로 변환할 수 있습니까?

아니요. 대기열을 만들 때 대기열 유형을 선택해야 합니다. 단, FIFO 대기열로 이동하는 것은 가능합니다. 자세한 내용은 Amazon SQS Developer GuideMoving From a Standard Queue to a FIFO Queue를 참조하십시오.

Q: Amazon SQS FIFO 대기열은 이전 버전과 호환됩니까?

FIFO 대기열 기능을 활용하려면 최신 AWS SDK를 사용해야 합니다.

FIFO 대기열은 표준 대기열과 동일한 API 동작을 사용하며, 메시지 수신 및 삭제와 제한 시간 초과 변경 메커니즘은 동일합니다. 다만 메시지를 보낼 때는 메시지 그룹 ID를 지정해야 합니다. 자세한 내용은 Amazon SQS Developer GuideFIFO Queue Logic을 참조하십시오.

중요: 기존 표준 대기열은 FIFO 대기열로 변환할 수 없습니다. FIFO 대기열로 이동하려면 애플리케이션의 새 FIFO 대기열을 만들거나 기존의 표준 대기열을 삭제하고 FIFO 대기열로 다시 만들어야 합니다. 자세한 내용은 Amazon SQS Developer GuideMoving from a Standard Queue to a FIFO Queue를 참조하십시오.

Q: Amazon SQS FIFO 대기열과 호환되는 AWS 또는 외부 서비스는 무엇입니까?

Amazon SQS에 알림을 전송하는 일부 AWS 또는 외부 서비스가 FIFO 대기열을 대상으로 설정하도록 허용하더라도 FIFO 대기열과 호환되지 않을 수 있습니다.

현재 AWS 서비스의 다음 기능은 FIFO 대기열과 호환되지 않습니다.

다른 서비스의 FIFO 대기열과의 호환성에 대한 정보는 서비스 설명서를 참조하십시오.

Q: Amazon SQS FIFO 대기열이 Amazon SQS Buffered Asynchronous Client, Amazon SQS Extended Client Library for Java 또는 Amazon SQS Java Message Service(JMS) Client와 호환됩니까?

FIFO 대기열은 현재 Amazon SQS Buffered Asynchronous Client와 호환되지 않습니다.

FIFO 대기열은 Amazon SQS Extended Client Library for Java 및 Amazon SQS Java Message Service(JMS) Client와 호환됩니다.

Q: AWS CloudWatch 측정치 중 Amazon SQS FIFO 대기열이 지원하는 것은 무엇입니까?

FIFO 대기열은 표준 대기열이 지원하는 모든 측정치를 지원합니다. FIFO 대기열의 경우, 모든 근사 측정치가 정확한 카운트를 반환합니다. 예를 들어 다음 AWS CloudWatch 측정치가 지원됩니다.

  • ApproximateNumberOfMessagesDelayed – 대기열 중 지연되고 즉시 읽기가 불가능한 메시지 수.
  • ApproximateNumberOfMessagesVisible – 대기열로부터 검색이 가능한 메시지 수.
  • ApproximateNumberOfMessagesNotVisible – inflight(클라이언트에게 전송되었지만 아직 삭제되지 않았거나 가시성 기간의 끝에 도달하지 않은) 메시지 수.

Q: 메시지 그룹이란 무엇입니까?

FIFO 대기열 내에서 메시지들은 서로 구별되고 순서가 지정된 "번들"로 그룹화됩니다. 각각의 메시지 그룹 ID의 경우, 모든 메시지가 엄격한 순서로 전송되고 수신됩니다. 하지만 메시지 그룹 ID 값이 다른 메시지들은 잘못된 순서로 전송, 수신될 수 있습니다. 메시지 그룹 ID와 메시지를 연결해야 합니다. 메시지 그룹 ID를 제공하지 않으면 동작이 실패합니다.

여러 호스트(또는 동일 호스트의 서로 다른 스레드)가 동일한 메시지 그룹 ID를 가진 메시지들을 FIFO 대기열로 전송하면 Amazon SQS는 이 메시지들이 처리를 위해 도착하는 순서대로 메시지를 전달합니다. Amazon SQS가 메시지들이 전송 및 수신되는 순서를 보존하려면 여러 송신자가 각각의 메시지를 고유한 메시지 그룹 ID로 전송해야 합니다.  

Q: Amazon SQS FIFO 대기열은 다중 생산자를 지원합니까?

예. 한 명 이상의 생산자가 하나의 FIFO 대기열에 메시지를 전송할 수 있습니다. 메시지는 Amazon SQS에 의해 성공적으로 수신된 순서대로 저장됩니다.

복수의 생산자가 SendMessage 또는 SendMessageBatch 동작의 성공 응답을 기다리지 않고 병렬로 메시지를 전송하는 경우, 생산자 간 순서가 보존되지 않을 수 있습니다. SendMessage 또는 SendMessageBatch 동작의 응답에는 FIFO 대기열이 메시지를 대기열에 배치하는 데 사용하는 최종 순서화 시퀀스가 포함되어 있으므로, 다중 병렬 생산자 코드는 대기열 내 메시지의 순서를 결정할 수 있습니다.

Q: Amazon SQS FIFO 대기열은 다중 소비자를 지원합니까?

Amazon SQS FIFO 대기열은 동일한 메시지 그룹의 메시지를 한 번에 두 명 이상의 소비자에게 제공하지 않도록 설계되었습니다. 단, FIFO 대기열에 여러 메시지 그룹이 있는 경우, 병렬 고객을 활용하여 Amazon SQS가 서로 다른 메시지 그룹의 메시지를 서로 다른 고객에게 제공하도록 할 수 있습니다.

Q: FIFO 대기열과 함께 배달 못한 편지 대기열을 사용할 수 있습니까?

예. 단, 하나의 FIFO 대기열과 함께 하나의 FIFO 배달 못한 편지 대기열을 사용해야 합니다. (마찬가지로 하나의 표준 대기열과 함께 하나의 표준 배달 못한 편지 대기열만 사용할 수 있습니다.)

Q: Amazon SQS FIFO 대기열의 처리량 한계는 얼마입니까?

일괄 처리 없이도 FIFO 대기열은 최대 초당 300번의 메시지(초당 300번 SendMessage, ReceiveMessage 또는 DeleteMessage 작업)를 지원할 수 있습니다. 작업당 최대 10개 메시지를 처리할 수 있는 최대 일괄 처리의 이점을 사용할 경우, FIFO 대기열은 최대 초당 3000번의 메시지를 지원할 수 있습니다. Amazon SQS 표준 대기열은 처리량에 제한이 없습니다.

Q: FIFO 대기열 속성에만 적용되는 제한 사항이 있습니까?

FIFO 대기열의 이름은 .fifo 접미사로 끝나야 합니다. 접미사는 80자의 대기열 이름 제한에 포함됩니다. 대기열이 FIFO인지 알아보려면 대기열 이름이 접미사로 끝나는지 확인하면 됩니다.


Q: Amazon SQS에 저장되는 내 데이터의 안정성은 어느 정도입니까?

Amazon SQS는 모든 메시지 대기열과 메시지를 가용성이 뛰어난 단일 AWS 리전 내 여러 중복 가용 영역(AZ)에 저장하므로 하나의 컴퓨터, 네트워크 또는 AZ에 장애가 발생하더라도 메시지에 액세스할 수 있습니다. 자세한 내용은 Amazon Relational Database Service User GuideRegions and Availability Zones를 참조하십시오.

Q: 메시지 대기열의 메시지를 보호하려면 어떻게 해야 합니까?

인증 메커니즘이 갖추어져 있어 Amazon SQS 메시지 대기열에 저장된 메시지가 무단 액세스로부터 확실하게 보호됩니다. 메시지 대기열에 메시지를 전송할 수 있는 사용자와 메시지 대기열에서 메시지를 수신할 수 있는 사용자를 제어할 수 있습니다. 보안 강화를 위해 애플리케이션이 메시지를 대기열에 올리기 전에 암호화하도록 구성할 수도 있습니다.

Amazon SQS는 자체 리소스 기반 권한 시스템을 갖추고 있으며 이 시스템은 AWS Identity and Access Management(IAM) 정책에서와 같은 언어로 작성된 정책을 사용합니다. 즉, 예를 들어 IAM 정책에서 사용하는 것처럼 변수를 사용할 수 있습니다. 자세한 내용은 Amazon SQS Developer GuideAmazon SQS Policy Examples를 참조하십시오.

Amazon SQS는 HTTPS(HTTP over SSL)와 TLS(전송 계층 보안)를 지원합니다. 대부분 클라이언트는 코드 또는 구성 변경 없이 최신 버전의 TLS를 사용하도록 자동으로 조정할 수 있습니다. Amazon SQS는 모든 리전에서 TLS(전송 계층 보안) 프로토콜 버전 1.0, 1.1 및 1.2를 지원합니다.

Q: ReceiveMessage 및 DeleteMessage 작업이 별도로 있는 이유는 무엇입니까?

Amazon SQS는 메시지를 반환할 때 사용자가 실제로 이 메시지를 수신했는지에 상관없이 해당 메시지를 메시지 대기열에 그대로 보관합니다. 메시지 삭제는 사용자의 책임입니다. 삭제 요청이 있으면 사용자가 메시지를 처리한 것으로 간주됩니다.

메시지를 삭제하지 않으면 다른 수신 요청을 받을 때 Amazon SQS가 해당 메시지를 다시 전송합니다. 자세한 내용은 Amazon SQS Developer GuideVisibility Timeout을 참조하십시오.

Q: 삭제한 메시지를 다시 수신하는 경우가 있습니까?

아니요. FIFO 대기열에는 중복 메시지가 절대 유입되지 않습니다.

표준 대기열의 경우, 드문 경우지만 이전에 삭제한 메시지를 한 번 더 수신할 수도 있습니다. 삭제 당시 분산 Amazon SQS 시스템 서버 중 하나에 장애가 발생하여 DeleteMessage 작업이 모든 메시지 사본을 삭제하지는 못하는 경우가 간혹 있습니다. 그러면 삭제되지 않은 메시지 사본이 다시 전송될 수 있습니다. 표준 대기열을 사용하는 경우, 애플리케이션을 idempotent(즉, 삭제한 메시지를 한 번 더 수신하더라도 오류 또는 불일치가 발생하지 않음) 방식으로 설계해야 합니다.

Q: 이전에 삭제한 메시지에 대해 DeleteMessage 요청을 발행하면 어떻게 됩니까?

이전에 삭제한 메시지에 대해 DeleteMessage 요청을 발행하면 Amazon SQS에서 성공 응답을 반환합니다.


Q: Amazon SQS에서 제공하는 서버 측 암호화(SSE)의 이점은 무엇입니까?

서버 측 암호화(SSE)를 사용하면 암호화된 대기열에서 민감한 데이터를 전송할 수 있습니다. SSE는 AWS Key Management Service(KMS)에서 관리하는 키를 사용하여 Amazon SQS 대기열의 메시지 콘텐츠를 보호합니다. SSE는 Amazon SQS가 메시지를 수신하자마자 이를 암호화합니다. 메시지는 암호화된 형태로 저장되며 Amazon SQS 는 권한이 있는 사용자에게 전송할 때만 메시지를 복호화합니다.

AWS KMS는 클라우드에 맞게 확장된 키 관리 시스템을 제공하기 위해 안전하고 가용성이 뛰어난 하드웨어 및 소프트웨어를 결합합니다.

다음은 AWS KMS를 사용할 때의 이점입니다.

  • 고객 마스터 키(CMK)를 직접 생성하고 관리할 수 있습니다.
  • 또한, 계정과 리전별로 고유한 AWS 관리형 CMK를 Amazon SQS에 사용할 수 있습니다. 
  • AWS KMS 보안 표준은 암호화 관련 규정 준수 요구 사항을 충족하는 데 도움이 될 수 있습니다.

자세한 내용은 다음 리소스를 참조하십시오.

Q: SSE가 적용된 대기열은 어느 리전에서 사용할 수 있습니까?

Amazon SQS용 SSE는 미국 동부(버지니아 북부 및 오하이오)와 미국 서부(오레곤) 리전에서 사용할 수 있습니다. 이 기능은 앞으로 몇 달에 걸쳐 더 많은 리전에서 지원할 예정입니다.

Q: 새로운 또는 기존 Amazon SQS 대기열에 SSE를 활성화하려면 어떻게 해야 합니까?

Amazon SQS API를 사용하여 새로운 또는 기존 Amazon SQS 대기열에 SSE를 활성화하려면, CreateQueue 또는 SetQueueAttributes 작업의 KmsMasterKeyId 속성을 설정하여 고객 마스터 키(CMK) ID, 즉 별칭, 별칭 ARN, 키 ID 또는 AWS 관리형 CMK 또는 사용자 지정 CMK의 키 ARN을 지정합니다.

세부 지침은 Amazon SQS Developer Guide에서 Creating an Amazon SQS Queue with Server-Side Encryption 섹션과 Configuring Server-Side Encryption (SSE) for an Existing Amazon SQS Queue 섹션을 참조하십시오.

Q: SSE를 사용할 수 있는 Amazon SQS 대기열 유형은 무엇입니까?

표준 대기열과 FIFO 대기열 모두 SSE를 지원합니다.

Q: Amazon SQS에서 SSE를 사용하려면 어떤 권한을 가지고 있어야 합니까?

SSE를 사용할 수 있으려면, 대기열 암호화와 메시지 암호화 및 복호화를 허용하도록 AWS KMS 키 정책을 구성해야 합니다.

대기열에 대한 SSE를 활성화하려면 Amazon SQS용 AWS 관리형 고객 마스터 키(CMK) 또는 사용자 지정 CMK를 사용하면 됩니다. 자세한 내용은 AWS KMS Developer Guide에서 Customer Master Keys 섹션을 참조하십시오.

암호화된 대기열로 메시지를 전송하려면, 생산자가 CMK에 대한 kms:GenerateDataKey 및 kms:Decrypt 권한을 가지고 있어야 합니다.

암호화된 대기열에서 메시지를 수신하려면, 소비자가 지정된 대기열의 메시지를 암호화하는 데 사용된 CMK에 대한 kms:Decrypt 권한을 가지고 있어야 합니다. 대기열이 데드레터큐의 역할을 하면, 소비자가 소스 대기열의 메시지를 암호화하는 데 사용된 CMK에 대한 kms:Decrypt 권한도 가지고 있어야 합니다.

자세한 내용은 What Permissions Do I Need to Use SSE? 섹션(Amazon SQS Developer Guide)을 참조하십시오.

Q: Amazon SQS에서 SSE를 사용하는 데 비용이 듭니까?

Amazon SQS에 대한 추가 비용은 없습니다. 하지만 Amazon SQS에서 AWS KMS를 호출하는 비용이 부과됩니다. 자세한 내용은 AWS Key Management Service 요금을 참조하십시오.

AWS KMS 사용 요금은 대기열에 구성된 데이터 키 재사용 기간에 따라 다릅니다. 자세한 내용은 How Do I Estimate My AWS KMS Usage Costs? 섹션(Amazon SQS Developer Guide)을 참조하십시오.

Q: Amazon SQS용 SSE는 무엇을 어떻게 암호화합니까?

SSE는 Amazon SQS 대기열에 있는 메시지 본문을 암호화합니다.

SSE는 다음 구성 요소는 암호화하지 않습니다.

  • 대기열 메타데이터(대기열 이름과 속성)
  • 메시지 메타데이터(메시지 ID, 타임스탬프, 속성)
  • 대기열별 지표

Amazon SQS는 Amazon SQS용 AWS 관리형 고객 마스터 키(CMK) 또는 사용자 지정 CMK를 기반으로 데이터 키를 생성하여 구성 가능한 시간 기간(1분에서 24시간) 동안 메시지의 엔벨로프 암호화 및 복호화를 제공합니다.

Q: Amazon SQS용 SSE는 어떤 알고리즘을 사용하여 메시지를 암호화합니까?

SSE는 AES-GCM 256 알고리즘을 사용합니다.

Q: SSE는 Amazon SQS의 기능에 영향을 줍니까?

메시지를 암호화하면 권한이 없는 사용자나 익명의 사용자가 콘텐츠를 사용할 수 없습니다. 메시지 암호화는 Amazon SQS의 정상적인 기능에 영향을 주지 않습니다.

  • 대기열에 대한 암호화가 활성된 후에 메시지를 전송하는 경우에만 메시지가 암호화됩니다. Amazon SQS는 백로그된 메시지는 암호화하지 않습니다.
  • 암호화된 메시지는 대기열에 대한 암호화가 비활성화되더라도 계속 암호화된 상태로 유지됩니다.

Q: 암호화된 Amazon SQS 대기열은 암호화되지 않은 대기열 및 데드레터큐와 어떻게 공존합니까?

데드레터큐로 메시지를 이동해도 암호화에 영향을 주지 않습니다.

  • 암호화된 소스 대기열에서 암호화되지 않은 데드레터큐로 메시지를 이동하는 경우, 해당 메시지는 암호화된 상태로 유지됩니다.
  • 암호화되지 않은 소스 대기열에서 암호화된 않은 데드레터큐로 메시지를 이동하는 경우, 해당 메시지는 암호화되지 않은 상태로 유지됩니다.

Q: SSE는 Amazon SQS에서 생성할 수 있는 대기열의 수 또는 TPS(초당 트랜잭션)를 제한합니까?

SSE는 Amazon SQS의 처리량(TPS)을 제한하지 않습니다. 생성할 수 있는 SSE 대기열의 수는 다음 조건에 따라 제한됩니다.

  • 데이터 키 재사용 기간(1분에서 24시간).
  • 계정당 AWS KMS 한도(기본값은 100TPS).
  • 대기열에 액세스하는 IAM 사용자 또는 계정 수.
  • 대규모 백로그가 존재(백로그가 크면 AWS KMS 호출 수가 증가함).

예를 들어 한도를 다음과 같이 가정해보겠습니다.

  • 데이터 키 재사용 기간을 5분(300초)으로 설정합니다.
  • KMS 계정의 AWS KMS TPS 한도가 기본값인 100TPS로 설정되어 있습니다.
  • Amazon SQS 대기열을 사용하되 백로그 없이 1명의 IAM 사용자가 모든 대기열에 SendMessage 또는 ReceiveMessage 작업을 수행합니다.

이 경우, SSE가 적용된 Amazon SQS 대기열의 이론적 최대 크기를 다음과 같이 계산할 수 있습니다.

300초 × 100TPS / IAM 사용자 1명 = 30,000 대기열

Q: 내 AWS KMS 사용 요금을 추정하려면 어떻게 해야 합니까?

비용을 예측하고 AWS 청구서를 이해하려면 Amazon SQS가 CMK를 사용하는 빈도를 알아야 합니다.

참고: 아래 공식으로 예상되는 비용을 추측할 수 있지만, Amazon SQS의 분산 특성으로 인해 실제 비용은 이보다 높을 수 있습니다.

대기열당 API 요청 수를 계산하려면(R), 다음 공식을 사용합니다.

R = B / D * (2 * P + C)

B는 청구 기간(초 단위)

D데이터 키 재사용 기간(초 단위)

P는 Amazon SQS 대기열로 전송하는 생산 보안 주체 수.

C는 Amazon SQS 대기열로부터 수신하는 소비 보안 주체 수.

중요 사항: 일반적으로 생산 보안 주체는 소비 보안 주체보다 비용이 두 배로 발생합니다. 자세한 내용은 How Does the Data Key Reuse Period Work? 섹션(Amazon SQS Developer Guide)을 참조하십시오.

생산자와 소비자의 IAM 사용자가 서로 다른 경우, 비용이 증가합니다.

계산 예제는 How Do I Estimate My Customer Master Key(CMK) Usage Costs? 섹션(Amazon SQS Developer Guide)을 참조하십시오. 정확한 요금 정보는 AWS KMS 서비스 요금을 참조하십시오.


Q: Amazon SQS는 PCI DSS 인증을 받았습니까?

예. Amazon SQS는 PCI DSS 레벨 1 인증을 받았습니다. 자세한 내용은 PCI 규정 준수를 참조하십시오.

Q: Amazon SQS는 HIPAA 적격입니까?

예. AWS는 Amazon SQS를 HIPAA 적격 서비스로 포함하도록 HIPAA 컴플라이언스 프로그램을 확장했습니다. AWS와 Business Associate Agreement(BAA)를 체결한 경우 Amazon SQS를 사용하여 HIPAA 규정 준수 애플리케이션을 빌드하고, 전송 중인 메시지를 저장하고, 메시지를 전송할 수 있습니다(개인 건강 정보(PHI)가 담긴 메시지 포함).

AWS와 이미 BAA를 체결한 경우 Amazon SQS를 즉시 사용할 수 있습니다. BAA가 없거나 HIPAA 규정 준수 애플리케이션에 AWS를 사용하는 방법에 대해 질문이 있는 경우 Amazon에 문의하여 자세히 알아보시기 바랍니다.

참고: Amazon SQS를 통해 PHI를 전송하고 싶지 않은 경우(또는 256KB보다 큰 메시지가 있는 경우), Amazon SQS Extended Client Library for Java를 사용하여 Amazon S3을 통해 Amazon SQS 메시지 페이로드를 전송할 수도 있습니다(Amazon S3는 Amazon S3 Transfer Acceleration 사용을 제외한 HIPAA 적격 서비스입니다). 자세한 내용은 Amazon SQS Developer GuideUsing the Amazon SQS Extended Client Library for Java를 참조하십시오.


Q: Amazon SQS 메시지 대기열에 얼마나 오래 메시지를 보관할 수 있습니까?

메시지 보존 기간이 더 길면 메시지의 생산과 소비 간의 간격도 좀 더 길게 정할 수 있는 유연성이 제공됩니다.

Amazon SQS 메시지 보존 기간은 1분에서 14일 사이의 값으로 구성할 수 있습니다. 기본 설정은 4일입니다. 메시지 보존 한도에 도달하면 메시지가 자동으로 삭제됩니다.

Q: Amazon SQS에서 메시지를 더 오래 보관하도록 구성하려면 어떻게 해야 합니까?

메시지 보존 기간을 구성하려면 콘솔 또는 Distributiveness 메서드를 사용하여 MessageRetentionPeriod 속성을 설정합니다. 이 속성을 사용하여 메시지가 Amazon SQS에 보존되는 기간을 초 단위로 지정합니다.

MessageRetentionPeriod 속성을 사용하여 메시지 보존 기간을 60초(1분)에서 1,209,600초(14일) 사이의 값으로 설정할 수 있습니다. 이 메시지 속성을 사용하는 방법에 대한 자세한 내용은 Amazon SQS API Reference를 참조하십시오.

Q: Amazon SQS의 최대 메시지 크기를 구성하려면 어떻게 해야 합니까?

최대 메시지 크기를 구성하려면 콘솔이나 SetQueueAttributes 메서드를 사용하여 MaximumMessageSize 속성을 설정합니다. 이 속성은 Amazon SQS 메시지가 포함할 수 있는 바이트 한도를 지정합니다. 이 한도를 1,024바이트(1KB)와 262,144바이트(256KB) 사이의 값으로 설정합니다. 자세한 내용은 Amazon SQS Developer GuideUsing Amazon SQS Message Attributes를 참조하십시오.

256KB보다 큰 메시지를 전송하려면 Java용 Amazon SQS 확장 클라이언트 라이브러리를 사용합니다. 이 라이브러리를 사용하면 참조가 포함된 Amazon SQS 메시지를 최대 2GB까지 Amazon S3의 메시지 페이로드로 전송할 수 있습니다. 

Q: 메시지에 포함할 수 있는 데이터 종류는 무엇입니까?

Amazon SQS 메시지는 XML, JSON, 서식 없는 텍스트 등의 텍스트 데이터를 최대 256KB까지 포함할 수 있습니다. 다음 Unicode 문자를 사용할 수 있습니다.

#x9 | #xA | #xD | [#x20 ~ #xD7FF] | [#xE000 ~ #xFFFD] | [#x10000 ~ #x10FFFF]

자세한 내용은 XML 1.0 사양을 참조하십시오.

Q: Amazon SQS 메시지 대기열의 최대 크기는 얼마나 됩니까?

단일 Amazon SQS 메시지 대기열은 메시지를 무제한으로 포함할 수 있습니다. 다만 inflight 메시지 수 한도는 표준 대기열은 120,000개이며, FIFO 대기열은 20,000개입니다. 메시지를 사용하는 구성 요소가 대기열에서 메시지를 수신하였지만 메시지가 대기열에서 삭제되지 않으면 메시지는 inflight 상태가 됩니다.

Q: 메시지 대기열은 몇 개까지 생성할 수 있습니까?

원하는 만큼 메시지 대기열을 생성할 수 있습니다.

Q: Amazon SQS 메시지 대기열의 이름에 크기 제한이 있습니까?

대기열 이름은 80자까지 설정할 수 있습니다.

Q: Amazon SQS 메시지 대기열 이름에 대한 제한이 있습니까?

영숫자 문자, 하이픈(-) 및 밑줄(_)을 사용할 수 있습니다.

Q: 메시지 대기열 이름을 재사용할 수 있습니까?

메시지 대기열의 이름은 AWS 계정과 리전 내에서 고유해야 합니다. 메시지 대기열을 삭제한 후에는 해당 메시지 대기열의 이름을 재사용할 수 있습니다.


Q: 메시지 대기열은 어떻게 공유합니까?

액세스 정책 문을 메시지 대기열에 연결(및 부여한 권한을 지정)하여 공유할 수 있습니다. Amazon SQS는 액세스 정책 문을 생성 및 관리할 수 있는 API를 제공합니다.

  • AddPermission
  • RemovePermission
  • SetQueueAttributes
  • GetQueueAttributes

자세한 내용은 Amazon SQS API Reference를 확인하십시오.

Q: 대기열 액세스를 공유하면 비용은 누가 지불합니까?

공유 메시지 대기열 액세스에 대한 비용은 메시지 대기열 소유자가 지불합니다.

Q: 메시지 대기열을 공유할 다른 AWS 사용자를 식별하려면 어떻게 해야 합니까?

Amazon SQS API는 AWS 계정 번호를 사용해 AWS 사용자를 식별합니다.

Q: 메시지 대기열을 공유하려는 AWS 사용자에게 어떤 정보를 제공해야 합니까?

AWS 사용자와 메시지 대기열을 공유하려면 공유하려는 메시지 대기열의 전체 URL을 제공하십시오. CreateQueue 및 ListQueues 작업을 수행하면 응답으로 이 URL이 반환됩니다.

Q: Amazon SQS에서는 익명 액세스를 지원합니까?

예. 익명 사용자가 메시지 대기열에 액세스할 수 있도록 액세스 정책을 구성하면 됩니다.

Q: Permissions API는 언제 사용해야 합니까?

Permissions API는 개발자에게 메시지 대기열에 대한 액세스를 공유할 수 있는 인터페이스를 제공합니다. 하지만 이 API는 조건부 액세스 또는 고급 사용 사례는 지원하지 않습니다.

Q: 언제 JSON 객체에 SetQueueAttributes 작업을 사용해야 합니까?

SetQueueAttributes 작업은 전체 액세스 정책 언어를 지원합니다. 예를 들어 이 정책 언어를 사용하여 IP 주소와 시간으로 메시지 대기열에 대한 액세스를 제한할 수 있습니다. 자세한 내용은 Amazon SQS Developer GuideAmazon SQS Policy Examples를 참조하십시오.


Q: Amazon SQS는 어떤 AWS 리전에서 사용할 수 있습니까?

서비스 리전 가용성은 AWS 글로벌 인프라 리전 표를 참조하십시오.
참고: FIFO 대기열은 현재 미국 서부(오레곤), 미국 동부(오하이오), 미국 동부(버지니아 북부) 및 EU(아일랜드) 리전에서만 사용할 수 있습니다. 이 기능은 앞으로 몇 달에 걸쳐 더 많은 리전에서 지원할 예정입니다.

Q: 서로 다른 리전의 대기열 간에 메시지를 공유할 수 있습니까?

아니요. 각 Amazon SQS 메시지 대기열은 각 리전 내에서 독립적입니다.

Q: 리전별로 요금이 다릅니까?

Amazon SQS 요금은 중국(베이징) 리전을 제외하고 다른 모든 리전에서 동일합니다. 자세한 내용은 Amazon SQS 요금을 참조하십시오.

Q: 서로 다른 리전 간의 요금 구조는 어떻게 됩니까?

단일 리전 내에서는 Amazon SQS와 Amazon EC2 또는 AWS Lambda 간에 데이터를 무료로 전송할 수 있습니다.

서로 다른 리전에서 Amazon SQS와 Amazon EC2 또는 AWS Lambda 간에 데이터를 전송하는 경우 일반 데이터 전송 요금이 부과됩니다. 자세한 내용은 Amazon SQS 요금을 참조하십시오.