1. 강의 내용

학습 범위

  • 17. 디커플링 애플리케이션: SQS, SNS, Kinesis, Active MQ
  • 18. AWS의 컨테이너: ECS, Fargate, ECR 및 EKS
  • 19. 솔루션 설계자 관점의 서버리스 개요

 

2. 강의 정리

1) SQS

: 메시지 큐 서비스로, 애플리케이션 간에 데이터를 주고받을 때 중간에 메시지를 임시로 저장하고 전달하는 기능을 한다.

 

 

1. 특징

  • 완전 관리형: 인프라 관리 없이 사용할 수 있음
  • 확장성: 무제한에 가까운 처리량, 대기열 메시지
  • 비동기 처리: 메시지를 보내고 즉시 다음 작업을 수행할 수 있음
  • 안전성: 메시지 손실 방지

    → 서비스 간의 의존성이 최소화 되고, 독립적으로 실행되어 전체적인 서비스의 유연성을 높임

 

 

2. SQS 구성 요소

  • 메시지(Message)
    • 전달하려는 데이터
    • 최대 256KB 텍스트 데이터 (더 큰 데이터는 S3와 연계 처리)
    • 기본적으로 4일 동안 저장되며, 최대 14일까지 연장 가능
  • 큐(Queue)
    • 메시지가 저장되는 공간

    • Standard Queue
      • 무제한에 가까운 처리량(자동 확장)과 최소 지연 시간 지원
      • 메시지가 적어도 한 번 이상 전달된다. (At Least Once Delivery)
      • 메시지 순서 보장 X, 중복 전달 방지 X
    • FIFO Queue
      • 기본으로 300 TPS, 높은 처리량 모드 시 최대 3000 TPS 지원
      • 중복 처리가 없도록 정확히 한 번만 전달된다. (Exactly Once Delivery)
      • 메시지 순서 보장 O, 중복 전달 방지 O
  •  
  • 생산자(Producer)
    • 큐에 메시지를 보내는 서비스
  • 소비자(Consumer)
    • 큐에서 메시지를 가져와 처리하는 서비스

 

 

3. 주요 기능

  • 가시성 타임아웃(Visibility Timeout)
    • 소비자가 메시지를 처리하는 동안 다른 소비자가 동일한 메시지를 중복 처리하지 않도록 설정된 시간
    • 기본값 30초, 최대 12시간까지 조정 가능
  • 긴 폴링(Long Polling)
    • 소비자가 큐에 메시지를 요청할 때, 대기열에 메시지가 없다면 메시지가 도착할 때까지 기다림
    • 빈 응답을 줄여 비용과 대기 시간을 최적화
  • 짧은 폴링(Short Polling)
    • 소비자가 큐에 메시지를 요청할 때, 즉시 응답을 반환하며 메시지가 없으면 빈 응답을 받음 (기본 설정)
  • 데드 레터 큐(Dead Letter Queue, DLQ)
    • 일정 횟수 이상 처리 실패한 메시지를 별도의 큐로 이동시킴
    • 디버깅 및 문제 분석 가능
  • 메시지 지연(Delay Queues)
    • 메시지를 큐에 추가한 후 일정 시간 동안 소비자에게 보이지 않도록 설정 (최대 15분)

 

 

4. SQS 동작 방식

  1. 생산자가 SQS 큐에 메시지를 전송 (SendMessage API 호출)
  2. 메시지는 SQS에 저장되며, 필요에 따라 복제되어 내구성을 보장
  3. 소비자가 큐에서 메시지를 polling하여 가져옴 (ReceiveMessage API 호출)
    • 처리 중 메시지가 다른 소비자에게 다시 할당되지 않도록 가시성 타임아웃이 설정됨.
  4. 메시지를 처리한 후, 소비자가 처리 완료를 알리기 위해 메시지를 삭제 (DeleteMessage API 호출)

 

 

5. 사용 사례

 

SQS 메시지 트래픽에 따른 Auto Scaling 적용





 

2) SNS

: 메시지를 발행(Publish)하면 이를 구독(Subscribe)한 모든 수신자에게 동시에 전달하는 push 기반 서비스이다.

SQS와 달리 메시지를 큐에 저장하고 소비자가 가져가기를 기다리는 방식이 아니라, 실시간으로 메시지를 push한다.

 

 

1. 특징

  • 완전 관리형: 인프라 관리 없이 사용할 수 있음
  • 확장성: 수백만 구독자에게 메시지 전송 가능
  • 실시간성: 메시지를 즉시 전달
  • 다양한 서비스 지원: 이메일, 

    → 서비스 간의 의존성이 최소화 되고, 독립적으로 실행되어 전체적인 서비스의 유연성을 높임

 

 

2. SQS 구성 요소

  • 토픽(Topic)
    • 메시지를 발행하고 구독자가 수신하는 논리적 채널
    • 각 토픽은 고유한 ARN(Amazon Resource Name)을 가짐.

    • Standard Topic
      • 무제한에 가까운 처리량(자동 확장)과 최소 지연 시간 지원
      • 메시지가 적어도 한 번 이상 전달된다. (At Least Once Delivery)
      • 메시지 순서 보장 X, 중복 전달 방지 X
      • 다양한 서비스 구독자를 지원한다. (Email, SMS, HTTP, SQS, Lambda 등)
    • FIFO Topic
      • 기본으로 300 TPS , 높은 처리량 모드 시 최대 3000 TPS 지원
      • 중복 처리가 없도록 정확히 한 번만 전달 (Exactly Once Delivery)
      • 메시지 순서 보장 O, 중복 전달 방지 O
      • SQS FIFO Queue 구독자만 지원한다.
  • 발행자(Publisher)
    • 토픽에 메시지를 보내는 애플리케이션 또는 서비스.
  • 구독자(Subscriber)
    • 토픽에서 메시지를 받는 엔드포인트 (ex: 이메일, SMS, Lambda, SQS 등)
  • 메시지(Message)
    • 전달하려는 데이터
    • 최대 256KB 텍스트 데이터 (더 큰 데이터는 S3와 연계 처리)
    • 속성(Message Attributes)을 추가해 필터링 가능
  • 구독(Subscription)
    • 토픽과 구독자를 연결하는 설정.

 

 

3. 주요 기능

  • 메시지 필터링(Message Filtering)
    • 구독자가 메시지 속성을 기반으로 수신 여부를 결정(예: "type=error" 메시지만 수신)
  • 팬아웃(Fan-out)
    • 하나의 토픽에서 여러 SQS 큐로 메시지를 분배 가능
    • SQS 큐의 액세스 정책에서 SNS가 메시지를 보낼 수 있도록 허용해야 함
  • 데드 레터 큐(Dead Letter Queue, DLQ)
    • 전달 실패한 메시지를 별도의 SQS 큐로 저장

 

 

4. SQS 동작 방식

  1. 발행자가 SNS 토픽에 메시지를 발행 (Publish API 호출)
  2. 메시지는 해당 모든 토픽 구독자에게 실시간으로 푸시
    • 메시지 필터링 정책이 적용된 경우, 조건에 맞는 구독자에게만 전달됨
  3. 구독자가 메시지를 수신하고 처리함
  4. SNS 메시지 전달 확인 (Optional)
    • SNS가 메시지 전달이 성공적으로 되었는지 확인하여, 실패 시 DLQ로 메시지를 보냄

 

 

5. 사용 사례

 

S3 이벤트를 여러 SQS 큐로 전달 / SNS → Kinesis Data Firehose → S3 (실시간 로그 분석, 대규모 데이터 저장 등의 아키텍처 설계 가능)

 

 

 

3) Kinesis

: 실시간으로 스트리밍 데이터를 빠르게 수집/처리/분석할 수 있도록 지원하는 완전 관리형 서비스이다.

 

 

1. Kinesis Data Streams

  • 실시간으로 데이터 스트림을 수집하는 서비스
  • 샤드(Shard) 기반 아키텍처
    • 데이터 스트림은 샤드 단위로 나뉘어짐
    • 각 샤드의 초당 1MB 쓰기, 2MB 읽기 처리 가능
    • 처리량은 샤드 수에 비례하여 확장됨

    • 프로비저닝 모드
      • 사용자가 직접 샤드 개수를 지정하여 용량 설정
      • 지정한 샤드 개수에 따른 시간 단위의 비용
    • 온디멘드 모드
      • 마지막 30일간의 최대 처리량을 기준으로 자동 스케일링
      • 입출력 된 데이터(GB) 기준 비용
  • 데이터 레코드
    • 스트림에 저장되는 데이터
    • 각 레코드는 Partition Key와 Sequence Number로 식별된다.(Partition Key는 저장될 샤드를 결정한다.)
  • 데이터를 스트림에 넣는 Producer
    • 직접 개발: AWS SDK / Kinesis Agent / KPL(Kinesis Producer Library)
  • 데이터를 읽어 처리하는 Consumer
    • 직접 개발: AWS SDK / KCL(Kinesis Client Library)
    • 관리형 서비스: Lambda / Kinesis Data Firehose / Kinesis Data Analytics
  • 최소 1일 ~ 최대 365일까지 데이터가 보관된다.
  • 한 번 삽입된 데이터는 삭제할 수 없다.

 

 

2. Kinesis Data Firehose

  • 스트리밍 데이터를 지정된 AWS 데이터 저장소나 분석 서비스로 자동 전송하는 서비스 (S3, Redshift, OpenSearch)
  • Lambda를 통한 데이터의 변환(포맷, 필터링) 지원
  • 데이터를 일정 크기나 시간 간격으로 묶어 배치 단위로 저장소에 전송함 → Near Real-Time Service
더보기

Kinesis Data Streams vs Kinesis Data Firehose

 

  Kinesis Data Streams Kinesis Data Firehose
목적 대규모 데이터 스트리밍 수집 스트리밍 데이터를 AWS 및 외부 저장소로 전송
직접 개발 Custom Producer/Consumer 코드 작성 필요 완전 관리형(Fully Managed), 개발 없이 사용 가능
실시간 처리 실시간(Real-time, 약 200ms 지연) 거의 실시간(Near Real-time), 버퍼링 적용됨
확장성 샤드(Shard) 기반 수동 확장 또는 API로 확장 가능 자동 확장(Auto Scaling)
데이터 저장 기간 최소 1일 ~ 최대 365일 데이터 저장 없음
(즉시 대상 시스템으로 전송)
데이터 재처리 지원 (데이터 저장 후 다시 읽기 가능) 미지원 (한 번 전송 후 다시 불러올 수 없음)

 

 

 

3. Kinesis Data Analytics

  • 스트리밍 데이터를 실시간으로 분석하는 서비스
    SQL 쿼리 또는 Apache Flink를 사용해 실시간 데이터 분석
  • 실시간 분석 결과를 다른 Kinesis Stream, S3, Lambda 등으로 전송

 

4. Kinesis Video Streams

  • 비디오와 오디오 스트림을 실시간으로 수집, 처리, 저장하기 위한 서비스 (CCTV, 드론, IoT 카메라)

 

저작자표시

'DevOps > AWS' 카테고리의 다른 글

AWS SAA 6주차  (0) 2025.03.29
AWS SAA 5주차  (0) 2025.03.24
AWS SAA 4주차 (1)  (0) 2025.03.14
AWS SAA 3주차  (0) 2025.03.08
AWS SAA 2주차  (0) 2025.03.01

티스토리툴바