8. AWS 의 애플리케이션 서비스

 AWS는 EC2나 RDS, VPC와 같은 IaaS나 PaaS 뿐만 아니라, SaaS라고 불리는 애플리케이션 서비스도 적극적으로 제공하고 있다.  AWS를 이용하여 보다 효율적인 시스템을 구축, 운용하기 위해서는 애플리케이션 서비스를 충분히 활용하는 것이 중요하다.

시험의 관점에서도 코스트 면이나, 가용성이 우수한 시스템을 구축할 경우 애플리케이션 서비스가 중요한 포인트가 될 것이다.

AWS의 애플리케이션 서비스의 공통적인 접근법

AWS에는 많은 애플리케이션 서비스가 있지만, 기본적인 접근방법은 동일하다. 많은 유저가 이용하는 범용적인 서비스를 AWS의 대규모 리소스를 이용하여 개발, 운영하는 것으로 낮은 코스트로 높은 품질의 서비스를 제공 하고 있다는 점이다.

애플리케이션 서비스의 개념도

여기서 중요한 것은 AWS의 애플리케이션 서비스는 AWS가 제공하는 많은 서버 리소스 상에서 구축되어 있는 점이다. 또한 서버와 애플리케이션의 메인테넌스는 AWS측에서 행한다 그렇기 때문에 스스로 다양한 구성을 만들려고 하는 것 보다. 대부분의 경우 코스트 측면과, 안정성측면에서도 뛰어나다 할 수 있다.

이것은 AWS 인증 시험 문제의 문제 풀이와도 연결된다. 애플리케이션 서비스로서 풀 매니지드 서비스를 이용하고 있는 경우 해당 서비스의 제약 이외에는 확정성이나 가용성은 생각하지 않아도 된다는 전제가 되어있다.

SQS

Amazon Simple Queue Service (SQS)는 AWS가 제공하는 풀 매니지드 서비스 큐잉 서비스이다. AWS의 서비스 군 중에서는 가장 오래되었으며 2004년 부터 서비스되기 시작했다. AWS의 메인 기능중 하나인 EC2나, S3의 제공이 시작된 2006년 보다 이전이며 이러한 사실로부터 시스템 간의 제휴 속에서 큐가 담당하고 있는 역할이 중요하다는 것을 알 수 있다.

큐잉 서비스를 이용함으로써 시스템간의 밀접도를 줄일 수 있다.

SQS의 기능으로는 큐의 관리와 메시지 관리 2가지가 있다. 큐는 메시지를 관리하기 위한 그릇과 같은 것으로 기본적으로는 처음 이용 할 때 작성하면, 이후로 따로 설정을 바꿀 필요 없이 엔드포인트라고 불리는 URL을 통해 이용하는 형태가 된다.

메시지의 관리 기능으로는 큐에 대하여 메시지의 송신, 취득과 처리가 끝난 메시지의 삭제가 있다 이것이외에도 복수의 큐를 한번에 처리하는 배치용 API나 처리중에 다른 프로세스에서 취득할 수 없도록 하기 위한 가시성 제한 API도 있다.

큐 관리와 메시지 관리

Standard 큐 와 FIFO 큐

SQS의 큐에는 standard 큐 와 FIFO 큐가 존재한다. SQS에는 베스트 Effort를 위해 원래 메시지의 전달 순서는 보장되지 않았다. 이에 2016년 11월에 전달 순서가 보장되는 FIFO 큐가 제공되었다. 순서를 보장하는 FIFO큐가 등장함에 따라 기존의 큐는 standard 큐라고 불리게 되었다.

Standard 큐에는 취득의 타이밍에 의해 동일의 메시지가 2회 전달될 가능성이 있다. 따라서 이용하는 시스템 측에서 동일한 메시지를 수신해도 영향이 없는 이용방법 ( 멱등성 보장 )을 구현할 필요가 있었다. 이를 FIFO 큐의 경우 동일 메시지의 이중 취득 문제또한 해결되었다.

큐로서 편의성은 Standard큐 보다 FIFO큐가 우수하다. 하지만 FIFO는 전달 순서를 보장하기 때문에 standard큐 보다 초당처리 건수가 뒤떨어진다. Standard큐는 초당 트랜잭션 수 (TPS)는 거의 무제한인데 반해 FIFO큐는 초당 트랜젝션은 비처리 300건, 배치 처리의 경우 3000건으로 제한되어 있다.

롱 폴링과 쇼트 폴링

큐의 메시지 취득 방법으로는 롱 폴링(Long Polling)과 쇼트 폴링 (Short Polling)이 있다. 이 둘의 차이는 SQS의 큐 측이 리퀘스트 받을 때 처리에서 차이가 있다. 기본인 숏 폴링의 경우, 요청을 받으면 메시지 유무에 관계없이 즉시 응답을 반환한다. 이에 대해 롱 폴링의 경우 메시지가 있는 경우 직시 응답을 반환하는 것은 동일하지만, 메시지가 없는 경우 설정된 타임아웃 직전까지 응답을 반환하지 않는다.

숏 폴링 쪽이 API 호출 회수도 많고, 코스트도 높아진다. 여러 큐를 단일 스레드로 처리하는 예외적인 케이스 이외에는 롱 폴링을 이용하는 것이 좋다.

가시성 타임아웃

메시지는 수신한 것 만으론 삭제되지 않는다. 클라이언트 측으로부터 명시적으로 삭제 지시를 받았을 때에만 삭제된다. 그 때문에 메시지의 수신 중에 다른 클라이언트가 취득해 버리는 가능성이 있다.

그것을 방지하기 위해서 SQS에는 같은 메시지의 수시을 방지하는 기능으로 가시성 타임아웃 (Visibility Timeout)이 있다. 가시성 타임아웃의 기본 설정값은 30초로 최대 12시간 까지 연장할 수 있다.

가시성 타임아웃

지연큐와 메시지 타이머

메시지 전달 시간 컨트롤에는 지연 큐(Delay Queue)와 메시지 타이머(Message Timer)라는 두 가지 기능이 있다. 지연 큐는 큐에 보낼 메시지를 일정 시간 보이지 않게 하는 기능이다. 이에 비해 메시지 타이머는 개별 메시지에 대해 일정 시간 보이지 않게 하는 기능이다. 양쪽 모두 메시지 전송 후 바로 처리되면 문제가 있을 때 사용한다.

지연큐와 메시지 타이머

데드 레터 큐

데드 레터 큐(Dead Letter Queue)는 처리할 수 없는 메시지를 다른 큐로 이동 시키는 기능이다. 설정된 횟수 (1 ~ 1000회) 만큼의 처리가 실패한 메시지를 일반 큐에서 제외하고 데드 레터 큐로 이동 시킨다. 데이터 상 혹은 시스템 상의 이유로 반드시 실패하야 하는 작업이 있는 경우 이들은 큐에 계속 남게된다. 데드 레터 큐는 이러한 상황을 사전 예방하는데 효과적이다. 데드 레터 큐를 잘 사용하면 애플리케이션 측의 예외 처리를 큰 폭으로 간소화 할 수 있다.

데드 레터 큐

메시지 사이즈

큐에 저장할 수 있는 메시지의 최대 크기는 256KB 이다. 문자열 정보로는 충분한 크기이지만, 이미지 정보 등을 취급하기에는 여의치 않은 사이즈이다. SQS에서는 큰 사이즈의 데이터는 S3나 DynamoDB에 저장하고, 그곳의 패스나, 키와 같은 포인터 정보를 받아 넘김으로 대응하고 있다.

 SWF와 Step Functions

시스템 개발을 할 때 반드시 나오는 것이 여러 처리 간의 연관성이다. 단순히 [1 → 2 → 3] 의 처리가 순서대로 흘러가는 경우도 있지만, [ 1 → 3 → 2 or 4 ]와 같이 처리 결과에 따라 나눠지는 경우도 있다. 이러한 일련의 처리 흐름은 워크 플로우라고 부른다. 워크 플로우 안에는 시스템 간의 연계 뿐만 아니라 사람에 의한 처리도 추가하여 조합하는 경우도 있다.

AWS의 워크 플로우 서비스

AWS에는 워크 플로우 서비스로 Amazon Simple Work Flow(SWF) 와 AWS Step Functions 가 있다. Step Functions의 워크 플로우 엔진은 SWF를 이용하는 것으로 알려져 있다. 때문에 일부 기능으로 Strep Functions가 커버하지 못하는부분도 있지만, 워크 플로우 동작으로 두 시스템은 거의 동일하다 할 수 있다.

Step Functions와 SWF의 차이는 가시화 기능이다. Step Functions 에는 워크 플로우를 가시화 하고, 편집 할 수 있는 기능이 있다. 매우 난해한 서비스인 SWF 보다 Step Functions 는 훨씬 쉽게 워크 플로우를 생성할 수 있다. 신규 워크 플로우를 만드는 경우 기본적으로 Step Functions 를 이용하는 것을 추천한다.

인증 시험에서는 아키텍처상의 설계 포인트를 주로 묻는다. 그 때문에 SWF와 Strep Functions의 특징을 기억해 둘 필요가 있다. 양쪽 모두 분기 처리 및 벙렬 처리가 가능하고 또한 SQS의 Standard Queue와 달리 1회성 실행 보증이 있다. 처리의 순서성도 보증하고 있다. 또한 시스템의 처리와 유사하게 사람의 처리가 들어가는 경우에는 상당한 확률로 Amazon Mechanical Turk와 병용하여 이용되게 된다. Mechanical Turk 는 클라우드 소싱 서비스이다.

워크 플로우의 예

SNS와 SES

관리자끼리의 연동이나, 이용자에게의 통지 등 복수의 유저에게 시스템 상태를 알릴 때에 중요한 역할을 완수하는 것이 Amazon Simple Notification Service (SNS) 이다.

SNS는 푸시 형태의 알림 서비스이다. 멀티 프로토콜이므로 복수의 프로토콜에 간단히 전달할 수 있다. 2020년 12월 당시 이용할 수 있는 프로토콜은 SMS, Email, HTTP/HTTPS. SQS 이외에도 iOS, Android등의 모바일 단말기로의 푸시 알림, Lambda와의 연계 등을 이용할 수 있다. 메시지 프로토콜 별로 변환하는 부분은 SNS가하기 때문에 통지하는 사람은 프로토콜의 차이를 의식하지 않고 전달할 수 있다.

SNS의 개요

SNS는 시스템 이벤트 알림의 핵심을 담당한다. SQS나 CloudWatch등과 조합하여, 시스템 간 연계 및 외부 통지 등에 사용한다.

Amazon Simple Email Service는 E메일 송신 서비스이다. SMTP 프로토콜을 이용하고 혹은 프로그램에서 직접 E메일을 송신할 경우 이용한다.

SNS의 이용에 대하여

SNS는 토픽이라는 단위로 정보를 관리한다. 시스템 관리자는 메시지를 관리하는 단위로 주제를 작성한다. 토픽 이용자로는 통지하는 사람 (Publisher)와 통지를 받는 사람 (Subscriber) 라고 한다. Subscriber는 이용하는 토픽 또는 받는 프로토콜을 등록한다. 이것을 구독이라고 한다. Publisher는 토픽에 대하여 메시지를 송신하는 것 만으로 Subscriber의 일도 프로토콜을 의식할 필요가 없다.

SNS 의 이용 순서

SNS를 이용한 이벤트 통지

SNS는 AWS 상에서 이벤트가 발생했을 때의 알림을 도맡아 한다. 이를 위한 아키텍처 설계상 SNS는 중요한 역할을 맡고 있다. 이벤트의 종류에는 여러가지가 있지만, 예를 들어 아래와 같은 것들이 있다.

• 리소스 설정, 상태를 평가하는 AWS Config에서 규칙에 반영하는 사용법이 발견되었다.
• CloudWatch에서 EC2의 CPU, 네트워크 등의 매트릭스를 감시하고 있을 때 한계를 넘었다.

 

SNS는 메일이나 모바일 푸시를 통해 사람들에게 알릴 수 있고, SNS는 Lmabda를 호출하여 프로그램이 대처하도록 할 수 있다. 푸시형 통지가 필요한 아키텍처를 묻는경우 우선 SNS를 사용할 수 있는지 검토해보자.

SES

SES는 이메일 송신 서비스이다. SMTP 프로토콜이나, API를 통한 메일 송신 이외에, E메일을 수신해 S3에 저장하는 것도 가능하다. SES의 특징은 높은 전달 성능에 있다. 최근의 메일 환경은 바이러스 메일이나, 스팸 메일 송신자 등 악의를 가진 송신 차량에 의해 위험에 노출되어 있다. 그 때문에 메일 서버를 운영하는 인터넷 서비스, 프로바이터나 통신 캐리어, 개인, 기업 등은 안전성을 쌓기 위해 여러가지수단을 강구하고 있다.

 

예를 들면 특정 IP로 부터의 단 기간 내에 대량의 메일이 송신될 경우 차단한다. 또는 IP주소나 도메인 과거의 행동 이력을 조사해 평가 값을 입력하여 평가가 낮은 IP 주소로 부터의 송신을 받지 않는다. 와 같은 설정도 가능하다. 게다가 그러한 정보를 데이터베이스화 하여 전세계에서 공용으로 이용하는 것으로써 방어 효과를 높이고 있다.

• 송신시에 바이러스나 멀웨어를 검출하고 차단하는 기능
• 전송 성공 수 및 거부된 수를 통계적으로 처리하여 전달 불능 및 불만 사항을 관리하는 기능
• Sender Policy Framework (SPF)나 DomainKeys Identified Mail (DKIM)과 같은 인증기능

SES는 신뢰성을 유지하기 위해 이용자에게도 몇 가지 제약을 가하고 있다. 우선 SES는 등록을 마친 메일 주소 혹은 도메인을 통해서만 송신 가능하다.

등록시에는 송신원으로서 정식 소유자임을 증명할 필요가 있다. 또한 이용하려면 다음 세가지 조건을충족해야 한다.

•  Bounce Mail (전송 불능 메일)의 비율이 5% 이하로 계속 유지 된다.
• 불만을 방지 (0.1% 미만)
• 악의적인 컨텐츠를 보내지 않는다.

메일 서버의 운용은 해마다 부하가 높아지고 있으며 SES는 그 운용에 필요한 기능을 미리 갖추고 있다고 말할 수 있다.