엣지 서비스

AWS 엣지 컴퓨팅 서비스는 필요에 따라 엔드포인트에 가깝게 데이터 처리 및 분석 기능을 이동하는 인프라와 소프트웨어를 제공합니다. 여기에는 AWS 데이터 센터 외부 위치, 심지어 고객 소유 디바이스에 AWS 관리형 하드웨어 및 소프트웨어를 배포하는 것이 포함됩니다.

다음과 같이 위치와 관련된 AWS 엣지 서비스를 사용하여 일관된 하이브리드 경험을 위해 클라우드를 확장할 수 있습니다.

• AWS 엣지 로케이션
  엣지 로케이션은 AWS 네트워크 백본을 통해 AWS 리전에 연결됩니다. CloudFront, WAF 및 Shield가 여기에서 사용되는 서비스입니다.
• AWS 로컬 영역
  AWS 클라우드의 확장인 로컬 영역은 인구가 많은 산업 중심지와 가까운 곳에 배치됩니다. 
• AWS Outposts
  이를 사용항 온프레미스나 자체 데이터센터에서 일부 AWS 서비스를 싱행할 수 있습니다.
• Snow 패밀리
  Snow 제품 패밀리는 엣지에서 오프라인 스토리지를 제공합니다. 이러한 스토리지를 사용하여 AWS 리전에 데이터를 다시 전송합니다.

동일한 인프라, 서비스, API 및 도구를 사용하여 일관된 환경을 구축할 수 있습니다.

엣지 서비스 아키텍처

사용자가 온프레미스에서 부분적을 호스트되는 애플리케이션으로 요청을 전송합니다. 사용자 요청이 Route 53, WAF, CloudFront, Outposts와 상호작용합니다. 클라우드에서 호스트되는 AWS 서비스는 AWS Shield를 통해 보호됩니다.

Route 53

Route 53은 DNS, 도메인 이름 등록 및 상태 확인 기능을 제공합니다. Route 53은 개발자와 기업이 안정적이고 비용 효율적인 방식으로 최종 사용자를 인터넷 애플리케이션에 라우팅할 수 있도록 설계되었습니다. 이 서비스는 example.com과 같은 이름을 컴퓨터의 상호 연결에 사용되는 숫자 IP 주소로 변환합니다.

Route 53을 사용해 example.com 같은 도메인 이름을 구매 및 관리하고 도메인에 대한 DNS 설정을 자동으로 구성할 수 있습니다.

Route 53은 EC2 인스턴스, ELB(Elastic Load Balancing) 로드 벨런서 또는 S3 버킷 등 AWS에서 실행되는 인프라에 사용자 요청을 효율적으로 연결합니다. 사용자를 AWS 외부의 인프라로 라우팅하기 위해 Route 53을 사용할 수도 있습니다.

CloudWatch 경보를 구성하여 엔드포인트 상태를 확인할 수 있습니다. DNS를 상태 확인 지표와 결합하여 정상 엔드포인트를 모니터링하고 해당 엔드포인트로 트래픽을 라우팅합니다.

상세 

Route 53  퍼빌릭  및 프라이빗 DNS

호스팅 영역은 레코드의 컨테이너입니다. 레코드에는 특정 도메인(example.com)과 그 하위 도메인(www.example.com 등)의 트래픽을 라우팅하는 방식에 대한 정보가 포함됩니다. 호스팅 영역과 해당 도메인의 이름은 동일합니다.

호스팅 영역의 유형은 두 가지입니다.

• 퍼블릭 호스팅 영역은 인터넷에서 트래픽을 라우팅하고자 하는 방법을 지정하는 레코드를 포함합니다.
  • 인터넷 이름 해석
  • 위임 세트: 등록 기관 또는 상위 도메인에 제공할 권한 네임 서버
• 프라이빗 호스팅 영역은 VPC에서 트래픽을 라우팅하고자 하는 방법을 지정하는 레코드를 포함합니다.
  • VPC 내부에서의 이름 해석
  • 계정 간에 여러 VPC와 연결할 수 있음

라우팅 정책

레코드를 생성할 때 라우팅 정책을 선택하게 되는데, 이는 Route 53이 쿼리에 응답하는 방식을 결정합니다.

1. 단순 라우팅 정책
   도메인과 관련하여 특정 기능을 수행하는 리소스 하나에 사용합니다. 이러한 리소스의 예시는 example.com 웹 사이트용 콘텐츠를 제공하는 웹 서버 등이 있습니다.
   
   단순 라우팅을 사용할 경우 표준 DNS 레코드를 구성할 수 있으므로 가중치 기반 라우팅, 지연 시간 라우팅 등의 특수 Route 53 라우팅을 사용할 필요가 없습니다. 단순 라우팅을 사용할 때는 대개 리소스 하나에 트래픽을 라우팅합니다.
   
   
2. 장애 조치 라우팅 정책
   액티브-패시브 장애 조치를 구성하려는 경우 사용합니다. 이 경우 Route 53 상태 확인을 통해 웹 애플리케이션, 웹 서버 및 기타 리소스의 상태와 성능을 모니터링합니다.
   
   상태 확인을 각각 생성하여 다음 중 하나를 모니터링할 수 있습니다.
   • 지정한 리소스의 상태
   • 다른 상태 확인 상태
     > 상태 확인을 생성하면 상태 확인의 상태를 받고, 상태가 변경될 때 알림을 받으며, DNS 장애 조치를 구성할 수 있습니다.
   • CloudWatch 경보 상태
     
     
3. 지리적 위치 라우팅 정책
   사용자의 위치를 기준으로 트래픽을 라우팅하려는 경우에 사용합니다. 이를 사용하면 사용자의 지리적 위치(DNS 쿼리가 시작된 위치)에 따라 트래픽을 지원할 리소스를 선택할 수 있습니다. 예를 들어 유럽에서 시작된 모든 쿼리를 프랑크푸르트 리전의 ELB 로드 밸런서로 라우팅할 수 있습니다.
   
   
4. 지리 근접 라우팅 정책
   리소스 위치를 기반으로 트래픽을 라우팅하고 선택적으로 한 위치의 리소스에서 다른 리소스로 트래픽을 이동하려는 경우에 사용합니다. 이를 사용해 Route 53이 사용자 및 리소스의 지리적 위치에 따라 트래픽을 리소스로 라우팅할 수 있습니다. 선택적으로 바이어스라고 하는 값을 지정하여 지정된 리소스로 트래픽을 더 많이 또는 더 적게 라우팅하도록 선택할 수 있습니다. 바이어스는 트래픽이 리소스로 라우팅되는 지리적 리전의 크기를 확장하거나 축소합니다.
   
   
5. 지연 시간 라우팅 정책
   여러 AWS 리전에 리소스가 있고 더 짧은 왕복 시간으로 가장 짧은 지연 시간을 제공하는 리전으로 트래픽을 라우팅하려는 경우 사용합니다.
   
   애플리케이션이 여러 AWS 리전에서 호스트된다면, 사용자들의 요청을 지연 시간이 가장 낮은 AWS 리전에서 처리함으로써 최종 사용자를 위해 성능을 향상시킬 수 있습니다.
   
   사용자와 리소스 간의 지연 시간에 대한 데이터는 전적으로 사용자와 AWS 데이터 센터 간의 트래픽에 기반합니다. AWS 리전에서 리소스를 사용하지 않는 경우 사용자와 리소스 간의 실제 지연 시간은 AWS 지연 시간 데이터와 크게 다를 수 있습니다. 리소스가 AWS 리전과 동일한 도시에 위치하는 경우에도 마찬가지입니다.
   
   
6. 다중 응답 라우팅 정책
   Route 53이 무작위로 선택도니 최대 8개의 정상 레코드로 DNS 쿼리에 응답하도록 하려는 경우에 사용합니다. 이를 사용하여, DNS 쿼리에 응답하여 웹 서버의 IP 주소와 같은 여러 값을 반환하도록 Route 53을 구성할 수 있습니다. 다중 값은 거의 모든 레코드에 대해 지정할 수 있지만, 다중 응답 라우팅을 사용하면 각 리소스의 상태도 확인할 수 있습니다. Route 53은 정상 리소스의 값만 반환합니다.
   
   다수의 상태 확인 가능한 IP 주소를 반환하는 기능은 DNS를 사용하여 가용성 및 로드 밸런싱을 개선하는 한 방법입니다. 하지만 이 기능이 로드 밸런서를 대처하는 것은 아닙니다.
   
   
7. 가중치 기반 라우팅 정책
   트래픽을 지정한 비율로 여러 리소스로 라우팅하는 데 사용합니다. 이를 사용해 리소스 레코드 세트에 가중치를 할당하여 각 응답이 처리되는 빈도를 지정할 수 있습니다.
   
   
   아래 블루/그린 배포 예시에서는 소량의 트래픽을 새 프로덕션 환경으로 라우팅하는데 가중치 기반 라우팅 정책이 사용되고 있습니다. 새 환경이 의도한 대로 작동하면 가중치 기반 트래픽의 양을 늘려 환경이 증가된 로드를 처리할 수 있는지 확인할 수 있습니다. 테스트가 성공적이면 모든 트래픽을 새 환경으로 보낼 수 있습니다.

라우팅 정책 선택법

Step Functions

현대적 클라우드 애플리케이션이 다수의 서비스 및 구성 요소로 구성되는 것은 일반적입니다. 애플리케이션 규모가 커지면서 모든 구성 요소의 상호 작용을 조율하기 위해 점점 더 많은 코드를 작성해야 합니다. Step Functions를 사용하면 상호 작용을 위한 소프트웨어 작성보다는 구성 요소 상호 작용의 정의에 집중할 수 있습니다.

Step Functions는 다음 AWS 서비스와 통합됩니다. Step Functions에서 직접 API 작업을 호출하고 파라미터를 다음 서비스의 API로 전달할 수 있습니다.

• 컴퓨터 서비스: Lambda, ECS, EKS, Fargate
• 데이터베이스 서비스: DynamoDB
• 메시징 서비스: SNS 및 SQS
• 데이터 처리 및 분석 서비스: Athena, Batch, Glue, EMR, Glue DataBrew
• 기계 학습 서비스 SageMaker
• API Gateway에 의해 생성된 API

Step Functions 서비스 태스크를 사용하여 다른 AWS 서비스를 호출하도록 Step Functions 워크플로를 구성할 수 있습니다.

상태 머신

상태 머신은 출력을 결정하기 위해 이전 조건에 의존하는 일련의 작동 조건을 가진 객체입니다.

상태 머신의 일반적인 예는 탄산음료 자판기입니다. 자판기는 작동 상태(거래 대기)에서 시작하여 고객이 동전 또는 ㅈ폐를 투입하면 탄산음료 선택 상태로 전환됩니다. 그러면 판매 상태가 시작되어 탄산음료가 고객에게 제공됩니다. 완료 후 운영 상태로 돌아갑니다.

Step Functions를 사용하면 AWS 환경에서 사용자 고유의 상태 머신을 생성하여 자동화할 수 있습니다. States Language에는 다양한 상태, 태스크, 선택, 오류 처리 등으로 구성된 구조가 포함돼 있습니다.

복잡한 분산 워크플로의 오케스트레이션

상태는 상태 머신의 요소입니다. 상태는 상태 머신에서 다양한 기능을 수행할 수 있습니다. 상태가 수행할 수 있는 기능은 다음과 같습니다.

• 상태 머신에서 몇 가지 태스크 수행(Task 상태)
• 실행할 브랜치 선택(Choice 상태)
• 오류 또는 성공으로 실행 중지(Fail 또는 Succeed 상태)
• 입력을 출력으로 전달하거나 일부 수정된 데이터 전달(Pass 상태)
• 특정 시간 동안 또는 지정된 시간/ 날짜까지 실행 지연(Wait 상태)
• 병렬 브랜치 시작(Parallel 상태)
• 동적으로 단계 반복(Map 상태)

Step Functions에서는 Standard와 Express의 두 가지 워크플로 유형을 생성할 수 있습니다.

• 내구성이 우수하며 감사가 가능한 장기 실행 워크플로에는 Standard Workflow 유형을 사용합니다. 이러한 워크플로는 최대 1년까지 실행할 수 있으며, 워크플로가 완료된 후 최대 90일 동안 워크플로 활동의 전체 기록에 액세스할 수 있습니다. Standard Workflow에 사용되는 정확히 1회 모델에서는 재시도 동작을 지정하는 경우가 아니면 태스크와 상태가 2회 이상 실행되지 않습니다.
• IoT 데이터 수집, 스트리밍 데이터 처리 및 변환, 모바일 애플리케이션 백엔드 등의 대용량 이벤트 처리 워크로드에는 Express Workflow 유형을 사용합니다. 이러한 워크플로는 최대 5분까지 실행할 수 있습니다. Express Workflow에 사용되는 최소 1회 모델에서는 태스크와 상태가 여러 번 실행될 수도 있습니다.

데이터 수집과 분석에 사용되는 Kinesis

Kinesis를 사용하면 다음과 같은 작업을 수행할 수 있습니다.

• 실시간으로 데이터 스트림을 수집 처리 분석할 수 있습니다. Kinesis는 어떤 규모에서든 스트리밍 데이터를 처리할 수 있는 용량을 제공합니다. 그러므로 애플리케이션의 요구 사항을 비용 효율적인 방식으로 가장 적절하게 충족하는 도구를 유동적으로 선택할 수 있습니다.
• 비디오, 오디오, 애플리케이션 로그, 웹 사이트 클릭스트림, 사물 인터넷(IoT) 원격 측정 데이터와 같은 실시간 데이터를 수집할 수 있습니다. 수집된 데이터는 기계 학습, 분석 및 기타 애플리케이션에 사용할 수 있습니다.
• 정형 쿼리 언어(SQL) 또는 Apache Fink를 사용하여 수신되는 데이터를 처리 및 분석한 후 응답을 즉시 제공할 수 있습니다. 모든 데이터가 수집될 때까지 기다렸다가 처리를 시작할 필요가 없습니다.

Kinesis Data Streams

Kinesis Data Streams 사용을 시작하려면 스트림을 생성하고 샤드 수를 지정합니다. 각 샤드는 스트림에서 고유하게 식별되는 데이터 레코드 시퀸스입니다. 스트림은 각 샤드에서 초당 1MB를 수신할 수 있습니다. 각 샤드에는 2MBs 애플리케이션 읽기 제한이 있습니다. 스트림의 총 용량은 해당 샤드 용량의 합계입니다. 리샤딩을 사용하여 필요에 따라 스트림의 샤드 수를 늘리거나 줄입니다.

생산자는 스트림에 데이터를 씁니다. 생산자는 EC2 인스턴스, 모바일 클라이언트, 온프레미스 서버 또는 IoT 디바이스일 수 있습니다. 인프라 로그, 애플리케이션 로그, 시장 데이터 피드, 웹 클릭스트림 데이터 등의 데이터를 전송할 수 있습니다.

소비자는 생산자가 생성하는 스트리밍 데이터를 읽습니다. 소비자는 EC2 인스턴스 또는 AWS Lambda에서 실행 중인 애플리케이션일 수 있습니다. EC2 인스턴스에 있는 애플리케이션은 스트리밍 데이터 증가에 따라 확장되어야 합니다. 이러한 경우 Auto Scaling 그룹에서 애플리케이션을 실행할 수 있습니다. 소비자 애플리케이션을 쓰는 또 한 가지 방법은 Lambda 함수를 사용하는 것으로, 서버를 프로비저닝하거나 관리하지 않고도 코드를 실행할 수 있습니다. 스트림의 동일한 데이터를 처리하는 애플리케이션이 두 개 이상 있을 수 있습니다.

소비자 애플리케이션의 결과를 저장하기 위해 S3, DynamoDB, Redshift 등의 AWS 서비스를 사용할 수 있습니다.

샤드(Shard)
샤드란 데이터베이스를 물리적으로 분할하는 기법 중 수평분할(수평 파티셔닝)을 했을 때 그 분할된 파티셔닝을 가리키는 말입니다. 샤드로 분리하는 이유는 데이터의 양이 많아지면 그 만큼 성능이나 퍼포먼스가 떨어지기 때문에 이를 케어하기 위해 사용됩니다.

Kinesis Data Firehose

이는 데이터를 거의 실시간으로 처리하는 역할을 합니다. Kinesis Data Firehose는 레코드를 S3, Redshift, OpenSearch service 및 사용자가 소유한 임의의 HTTP 엔드포인트로 전송할 수 있습니다. 또한 레코드를 Datadog, New Relic, Splunk 등 모든 서드 파티 서비스 공급자로 전송할 수 있습니다.

Kinesis Data Firehose는 전송 스트림의 버퍼링 구성을 기반으로 여러 수신 레코드를 연결합니다. 그런 다음 연결된 레코드를 S3에 S3 객체로 전달합니다.

Redshift에 데이털르 전송하기 위해, Kinesis Data Firehose는 다음 작업을 수행합니다.

1. 수신 데이터를 앞서 설명한 형식으로 S3 버킷에 전송합니다.
2. Redshift COPY 명령을 실행하여 S3 버킷에서 Redshift 클러스터로 데이터를 로드합니다.

OpenSearch Service는 OpenSearch API 및 실시간 분석 기능을 제공하는 완전관리형 서비스입니다. 처리된 데이터를 사용하여 기존 비즈니스 인텔리전스 도구 및 대시보드로 준실시간 분석을 생성할 수 있습니다. OpenSearch Service를 사용하면 Kinesis Data Firehose가 전송 스트림의 버퍼링 구성에 따라 수신 레코드를 버퍼링합니다. 그런 다음 Kinesis Data Firehose는 대량 요청을 생성하여 OpenSearch Service 클러스터에 여러 레코드를 인덱싱합니다.

SNS

SNS는 클라우드에서 손쉽게 알림을 설정, 운영 및 전송할 수 있는 웹 서비스입니다. 이 서비스는 게시-구독(pub-sub) 메시징 패러다임을 따르며 푸시 메커니즘을 사용하여 클라이언트에 알림을 전달합니다.

사용자는 주제를 생성하고 어떤 게시자 및 구독자가 주제와 통신할 수 있는지를 결정하는 정책을 정의함으로써 주제에 대한 액세스를 제어합니다. 게시자는 자신이 생성한 주제 또는 게시할 권한이 있는 주제로 메시지를 보냅니다.

게시자는 각 메시지에 특정 대상 주소를 포함하는 대신 메시지를 해당 주제로 전송할 수 있습니다. SNS는 주제와 해당 주제의 구독자 목록을 일치시켜 각 구독자에게 메시지를 정송합니다.

각 주제에는 SNS 엔드포인트를 식별하는 고유한 일므이 있으므로, 게시자는 메시지를 게시하고 구독자는 알림을 받도록 등록할 수 있습니다. 구독자가 구독하는 주제에 게시된 모든 메시지를 수신합니다. 특정 주제의 모든 구독자는 동일한 메시지를 수신합니다.

SNS는 암호화된 주제를 지원합니다. 암호화된 주제에 메시지를 게시하면 SNS는 AWS Key Management Service(AWS KMS)키를 사용하여 메시지를 암호화합니다.

SNS 알림을 사용하는 예시는 다음과 같습니다.

• Auto Scaling 그룹에 특정 변경 사항이 발생하는 등의 이벤트가 있을 경우, 사용자는 즉시 알림을 받을 수 있습니다.
• 구독자에게 이메일 또는 SMS로 특정 뉴스 헤드라인을 푸시할 수 있습니다. 수신한 이메일 또는 SMS 문자에 흥미를 느낀 사람은 자세한 내용을 확인하기 위해 웹사이트를 방문하거나 애플리케이션을 시작할 수 있습니다.
• 업데이트가 가능함을 나타내는 알림을 앱으로 전송할 수 있습니다. 알림 메시지는 업데이트를 다운로드 및 설치하기 위한 링크를 포함할 수 있습니다.

SNS의 특성

모든 알림 메시지에는 게시 메시지가 하나만 포함됩니다. SNS는 게시자가 주제에 게시한 메시지를 그 순서 그대로 전송하려고 시도합니다. 하지만 네트워크 문제로 인해 구독자에게 순서가 바뀌어 전송될 가능성도 없진 않습니다. 엄격한 메시지 순서 및 하나 이상의 구독자에게 중복 제거된 메시지 전달이 필요한 경우 SNS FIFO 주제를 사용합니다.

SNS의 특징은 다음과 같습니다.

• 메시지가 성공적으로 전송되면, 이를 회수할 방법은 없습니다.
• SNS 전송 정책을 사용해 재시도 패턴(선형, 기하학, 지수 백오프, 최대/최소 재시도 지연 및 기타 패턴)을 제어할 수 있습니다.
• 메시지가 손실되지 않도록 모든 메시지는 여러 서버와 데이터 센터에 걸쳐 중복 저장됩니다.
• SNS는 가장 크고 수요가 가장 많은 애플리케이션의 요구 사항에 부합하도록 설계되어, 어플리케이션이 무제한의 메시지를 게시할 수 있습니다.
• SNS를 사용하면 다양한 디바이스의 애플리케이션 및 최종 사용자가 모바일 푸시 알림에 의해 알림을 수신할 수 있습니다. 여기에는 Apple, Google, 및 Kindle Fire 디바이스, HTTP 또는 HTTPS, 이메일 또는 이메일-JSON, 는 또는 SQS 대기열, 그리고 Lambda 함수가 포함됩니다.
• SNS는 액세스 제어 메커니즘을 갖추고 있어 주제와 메시지가 무단 액세스로부터 확실하게 보호됩니다. 주제와 메시지가 무단 액세스로부터 확실하게 보호됩니다. 주제의 소유자가 주제 별로 일정한 정책을 수립해 주제를 게시하거나 구독할 수 있는 대상을 제한할 수 있습니다. 주제 소유자는 전송 메커니즘을 HTTPS로 지정하여 알림을 암호화할 수도 있습니다.

여러 SQS 대기열에 SNS 게시

SNS와 같은 고가용성 서비스를 사용하여 기본 메시지 라우팅을 수행하는 것은 메시지를 마이크로서비스로 배포하는 효과적인 방법입니다. 마이크로서비스의 두 가지 주요 통신 형태는 요청-읍답과 관찰자입니다.

위 예시에는 SNS 및 SQS를 사용하는 팬아웃 시나리오가 나와 있습니다. 팬아웃 시나리오에서는 메시지가 SNS 주제로 전송된 후 복제되어 여러 SNS 대기열, HTTP 엔드포인트 또는 이메일 주소로 푸시됩니다. 따라서 비동기식 병렬 처리가 허용됩니다.

여기서 SNS는 서로 다른 두 SQS 대기열로 주문을 팬아웃합니다. 2개 EC2 인스턴스가 각각 대기열을 관찰합니다. 두 인스턴스 중 하나는 주문 처리 과정을 진행하고, 다른 하나는 데이터 웨어하우스에 연결되어 접수되는 모든 주문을 분석합니다.

SNS 알림을 SQS 대기열로 전송하려는 경우 주제를 구독하고 SQS를 전송 프로토콜로, 유효한 SQS 대기열을 엔드포인트로 지정합니다. SQS 대기열에 SNS의 알림을 수신하도록 하려면, SQS 대기열 소유자는 SNS의 주제에 해당 SQS 대기열을 구독해야 합니다. 사용자가 구독 대상인 SNS 주제와 알림을 수신하는 SQS 대기열을 소유하고 있다면 추가로 필요한 작업은 없습니다. 주제에 게시되는 모든 메시지는 지정된 SQS 대기열로 자동 전송됩니다. 사용자가 SQS 대기열은 소유하고 있지만 주제 소유자는 아닌 경우 SNS는 구독 요청에 대한 명시적인 확인을 요구합니다.

SNS 및 SQS

SNS 메시지는 영구적이지 않습니다. SNS에서는 각 전송 프로토콜에 대한 전송 정책을 정의합니다. 전송 정책은 서버 측 오류 발생 시 SNS에서 메시지 전송을 재시도하는 방법을 정의합니다. 정송 정책이 다사용되면 SNS에서 전송 재시도를 중지하고 메시지를 폐기합니다. 예외의 경우는 DLQ(Dead Letter Queue)가 구독에 연결되어 있는 경우입니다.

SNS를 사용하면 애플리케이션에서 푸시 메커니즘을 통해 타임 크리티컬 메시지를 여러 구독자에게 전송할 수 있습니다.

SQS는 폴링 모델을 통해 메시지를 교환합니다. 즉, 전송 및 수신 구성 요소가 분리됩니다. 또한, 애플리케이션의 분산 구성 요소를 위한 유연성을 제공하므로 각 구성 요소를 동시에 사용하지 않고도 메시지를 송신 및 수신할 수 있습니다.

SQS

SQS는 관리 부담 없이 최소한의 구성으로 바로 사용할 수 있는 완전 관리형 서비스입니다. 이 서비스는 방대한 규모로 작동하느므로 하루에 수십억 건의 메시지를 처리할 수 있습니다. SQS는 여러 이중화 가용 영역을 사용하여 가용성이 높은 단일 AWS 리전에 모든 메시지 대기열과 메시지를 저장합니다. 그러므로 단일 컴 퓨터, 네트워크 또는 가용 영역 장애로 인해 메시지에 액세스하지 못하는 경우가 없습니다. 메시지는 동시에 보내고 읽을 수 있습니다.

개발자는 SQS 대기열을 익명으로 또는 특정 AWS 계정과 안전하게 공유할 수 있습니다. 특정 IP 주소와 특정 시간으로 대기열 공유를 제한할 수도 있습니다. 스트리밍 SIMD(Single Instruction  Multiple Data) 확장 (SSE)은 AWS KMS에서 관리되는 키를 사용하여 SQS 대기열에 있는 메시지의 콘텐츠를 보호합니다. SIMD 확장은 SQS가 메시지를 수신하는 즉시 이를 암호화합니다. 이 메시지는 암호화된 형태로 저장되며 SQS는 권한이 있는 사용자에게 전송할 메시지만 복호화합니다.

SQS 대기열

위 예시에서는 생산자 애플리케이션이 고객 주문을 생성한 후 SQS 대기열로 전송합니다. 소비자 애플리케이션 티어가 생산자 애플리케이션 티어의 주문을 처리합니다. 이 애플리케이션은 대기열을 폴링하고 메시지를 수신합니다. 그런 다음 RDS DB에 기록하고 처리된 메시지를 SQS 대기열에서 삭제합니다. SQS는 처리할 수 없는 메시지를 나중에 처리할 수 있는 DLQ(Dead Letter Queue)로 전송합니다. 이 대기열에서 해당 메시지를 나중에 처리할 수 있습니다.

SQS 대기열을 사용하면 다음과 같은 이점이 있습니다.

• 느슨한 결합
  SQS를 사용하면 전처리 단계를 컴퓨팅 단계 및 후처리 단계와 분리할 수 있습니다. 비동기식 처리가 사용되므로 생산자 로직이 소비자 로직과는 별도의 자체 구성 요소에 격리됩니다.
• 내결함성
  애플리케이션 예외나 트랜잭션 장애가 발생하는 경우 주문 처리를 재시도할 수 있습니다. 최대 재시도 횟수에 도달하면 SQS는 SQS DLQ로 메시지를 리디렉션할 수 있습니다. 그러므로 나중에 이 대기열에서 메시지를 다시 처리하거나 디버그할 수 있습니다. 느슨하게 결합된 워크로드에서 한 노드 또는 작업이 손실되어도 일반적으로 전체 계산이 지연되지 않습니다.
• 급증하는 트래픽 처리
  SQS 대기열 사용 시에는 시스템의 복원력이 향상됩니다. 대기열은 급증하는 트래픽 처리를 위한 버퍼로 사용됩니다. 그러므로 애플리케이션이 확장 작업을 완료할 수 있는 추가 시간이 제공됩니다. 그리고 급증하는 트래픽 처리를 위한 유휴 컴퓨팅 리소스를 프로비저닝할 필요가 없으므로 비용 효율성도 높아집니다.

SQS는 다음과 같은 사례에서 사용을 검토할 수 있습니다.

• 작업 대기열
  동일한 양의 작업을 동시에 처리하지 못할 수 있는 분산 애플리케이션의 구성 요소를 분리합니다. 애플리케이션의 요구 사항에 따라 표준 대기열 또는 FIFO(선입선출) 대기열을 선출할 수 있습니다.
• 버퍼링 및 배치 작업
  아키텍처에 확장성과 안정성을 더하고, 메시지를 손실하거나 지연시간을 늘리지 않고 일시적인 볼륨 스파이크를 원활하게 처리합니다.
• 요청 오프로딩
  요청을 대기열에 전송하여 대화식 요청 경로에서 속도가 느린 작업을 이동합니다.
• 인스턴스 자동 크기 조정
  SQS 대기열을 사용하여 애플리케이션의 로드를 확인할 수 있습니다. 자동 크기 조정과 함께 사용하면 트래픽 볼륨에 따라 EC2 인스턴스 수를 늘리거나 줄일 수 있습니다.

대기열 종류

1. 표준 대기열
   최소 1회 메시지 전송을 지우너하고 최선의 정렬로 제공합니다. 메시지는 일반적으로 수신된 순서와 동일한 순서로 전송됩니다. 하지만 고도로 분산된 아키텍처의 특성상 때로는 2개 이상의 메시지 사본이 순서가 맞지 않게 전송될 수 있습니다. 포준 대기열은 처리할 수 있는 초당 API 호출 수에 거의 제한이 없습니다. 한 번 이상 잘못된 순서로 도착하는 메시지를 애플리케이션에서 처리할 수 있는 경우, 포준 메시지 대기열을 사용할 수 있습니다.
2. FIFO 대기열
   작업 및 이벤트 순서가 중요하거나 중복 항목이 허용되지 않는 경우에 애플리케이션 간 메시징을 강화하도록 설계되었습니다. 또한 FIFO 대기열은 정확히 한 번 처리를 제공하지만 초당 API 호출수가 제한됩니다.

구성 최적화

SQS 대기열 애플리케이션을 생성할 때는 애플리케이션이 대기열과 상호 작용하는 방식을 고려해야 합니다. 이 정보는 대기열 구성을 최적화하여 비용을 제어하고 성능을 향상시크는 데 도움이 됩니다.

• 가시성 제한시간
  소비자가 수신한 SQS 메시지는 소비자가 삭제할 때까지 대기열에 유지됩니다. 해당 메시지가 일정 기간동안 다른 소비자에게는 표시되지 않도록 SQS 대기열의 가시성 제한 시간 설정을 구성할 수 있습니다. 그러면 다른 소비자가 같은 메시지를 처리하지 못하도록 설정할 수 있습니다. 가시성 제한 시간의 기본값은 30초 입니다. 소비자는 처리를 완료한 메시지를 삭제합니다. 가시성 제한 시간이 만료되기 전에 소비자가 메시지를 삭제하지 않을 경우, 다른 소비자가 메시지를 볼 수 있게 되며 해당 메시지는 다시 처리될 수 있습니다.
  
  일반적으로 가시성 제한 시간 설정 시 애플리케이션이 대기열에서 메시지를 처리하고 삭제하는 데 걸리는 최대 시간으로 설정해야 합니다. 시간 제한을 너무 짧게 설정하면 애플리케이션이 메시지를 두 번 처리할 가능성이 높아집니다. 반면 가시성 제한 시간을 너무 길게 설정하면 후속 메시지 처리 시도가 지연됩니다.
  
  
• 폴링 유형
  짧은 폴링이나 긴 폴링을 사용하도록 SQS 대기열을 구성할 수 있습니다.
  • 짧은 폴링을 사용하는 SQS 대기열의 특징을 다음과 같습니다.
    
    • 요청을 수신하는 즉시 소비자에게 응답을 전송하므로 응답이 더 빠르게 제공됩니다.
    • 응답 수가 늘어나므로 비용도 증가합니다.
  • 긴 폴링 시간을 사용하는 SQS 대기열의 특징은 다음과 같습니다.
    • 메시지가 하나 이상 도착하거나 폴링 시간이 초과될 때까지는 응답을 반환하지 않습니다.
    • 응답 빈도는 낮아지지만 비용 또한 감소합니다.

대기열에 메시지가 도착하는 빈도에 따라서는 짧은 폴링을 사용하는 대기열의 응답 중 대다수가 빈 대기열을 보고하게 될 수 있습니다. 애플리케이션이 폴링 요청의 응답을 즉시 받아야 하는 경우가 아니라면 긴 폴링 옵션을 사용하는 것이 좋습니다.

메시지 대기열을 사용해야 하는 이유

특정 기술이 사용 사레에 적합하지 않은 경우를 아는 것도 중요합니다. 메시징에는 일반적으로 보게 되는 고유한 안티 패턴이 있습니다. 특정 속성 집합과 일치하거나 심지어 일회성 논리적 쿼리와 일치하는 메시지를 대기열에서 선택적으로 검색하기를 원할 수 있습니다. 예를 들어 서비스는 특정 속성이 있는 메시지를 요청하는데, 서비스가 전송한 다른 메시지에 대한 응답이 포함되어 있기 때문입니다. 이로 인해 아무도 폴링하지 않고 결코 소비되지 않는 메시지가 대기열에 있는 시나리오가 발생할 수 있습니다.

대부분의 메시징 프로토콜과 구현은 메시지의 크가가 적절할 때(수십 또는 수백 킬로바이트) 가장 효과적입니다. 메시지 크기가 커진다면, S3와 같은 전용 스토리지 시스템을 사용하고 해당 스토어에 있는 객체에 대한 참조를 메시지 자체에 넣어 전달하는 것이 가장 좋습니다.

서버리스

서버리스는 더욱 민첩한 애플리케이션을 구축하는 데 사용할 수 있는 서비스, 사례 및 전략입니다. 서버리스 컴퓨팅을 사용하면 혁신하고 변화에 더 빠르게 대응할 수 있습니다. AWS에서 용량 프로비저닝, 패치 적용 등의 인프라 관리 태스크를 처리하므로 고객을 위한 코드 작성 작업만 중점적으로 수행할 수 있습니다.

서버리스 컴퓨팅은 다음과 같은 이점을 제공합니다.

• 프로비저닝하거나 관리할 인프라가 없음
• 서버를 프로비저닝, 운영 또는 패치할 필요가 없음
• 서버 단위가 아니라 소비 단위별로 오토 스케일링
• 종량제 결제 모델(서버 단위가 아닌 해당 단위에 대해 비용 지불)
• 가용성 및 내결함성 기본 제공
• 서비스에 내장되어 있으므로 가용성을 고려한 설계가 필요 없음

서버리스에는 다음과 같은 서비스들이 있습니다.

상세

API Gateway

API Gateway를 사용하여 API 생성, 게시, 유지 관리, 모니터링 및 보호할 수 있습니다. API Gateway를 사용하여 애플리케이션을 AWS 서비스와 기타 퍼블릭 또는 프라이빗 웹 사이트에 연결할 수 있습니다. 또한 모바일 및 웹 애플리케이션이 AWS 서비스 및 AWS 외부에서 호스팅되는 다른 리소스에 액세스할 수 있도록 일관된 RESTful 및 HTTP API를 제공합니다.

이 게이트웨이는 최대 수십만 개의 동시 API 호출을 수락하고 처리하는데 관련된 모든 태스크를 처리합니다. 이러한 작업에는 트래픽 관리, 권한 부여 및 액세스 제어, 모니터링, API 버전 관리가 포함됩니다.

API Gateway의 가능한 작업은 다음과 같습니다.

• 다양한 버전과 단계의 API를 호스팅 및 사용
• API 키를 생성하고 개발자에게 배포
• Signature Version 4(SigV4)를 활용하여 API에 대한 액세스 권한 부여
• RESTful 또는 WebSocker API 사용

주된 기능은 다음과 같습니다.

• 여러 마이크로서비스를 위한 통합 API 프런트 엔드를 생성
• 백엔드에 분산 서비스 거부(DDoS) 보호 및 제한
• 백엔드에 대한 요청을 인증 및 권한 부여
• 서드 파티 개발자에 의해 API 사용을 조절, 측정 및 수익화

예시 아키텍처

위 예시에서는 클라이언트 브라우저가 S3에서 호스팅된 정적 웹 페이지를 요청합니다. 클라이언트 브라우저는 이 웹 페이지를 사용하여 REST API를 통해 API Gateway와 통신합니다. API Gateway는 요청을 인증하고 권한을 부여하며, DynamoDB와 통신하는 Aambda 함수를 호출합니다. 반복 요청을 처리할 때 지연 시간과 백엔드 로드를 줄이기 위해, 이 예에서는 API Gateway 캐시가 포함되어 있습니다.

API Gateway는 Amazon CloudWatch에도 로그를 전송합니다. API Gateway는 API의 각 단계 또는 사용하는 각 메서드에 해당하는 로그를 CloudWatch에 전송할 수 있습니다. 로깅 세부 사항(오류 또는 정보), 그리고 전체 요청 미 ㅊ응답 데이터를 로깅해야 하는지 여부를 설정할 수 있습니다.

API Gateway가 CloudWatch로 전송할 수 있는 세부 지표는 다음과 같습니다.

• API 호출 건수
• 지연 시간
• 통합 지연 시간
• HTTP 400 및 500 오류

또한 액세스 로깅을 활성화하여 누가 API에 액세스했는지, API에 어떤 방식으로 액세스했는지 기록할 수 있습니다.