Architecting on AWS - 04

Amazon SNS vs. Amazon SQS

기준	Amazon SNS (게시자/구독자)	Amazon SQS (생산자/소비자)
메시지 지속성	X	O
전송 매커니즘	푸시(수동적)	폴링(능동적)
생산자/소비자	게시/구독	송신/수신
배포 모델	일대다	일대일

 

Amazon SQS (Simple Queue Service)

아마존의 완전관리형 메시지 서비스이다. 마이크로 서비스 아키텍처를 위한 발신자와 수신자 간 버퍼의 역할을 담당한다. 하루에 수십억 건의 메시지를 처리할 수 있으며, Multi-AZ로 고가용성을 확보해 단일 리전 내에 모든 메시지 대기열과 메시지를 저장한다. 

SSE(Server Side Encryption)는 AWS KMS(Key Management Service)에서 관리하는 키를 사용하여 Amazon SQS 대기열의 메시지 콘텐츠를 보호한다. SSE는 Amazon SQS가 메시지를 수신하는 즉시 이를 암호화해 저장하며, 권한이 있는 사용자에게 전송할 메시지만 복호화한다.

메시지 하나 당 최대 256KB의 용량을 가지며, Producer - Consumer의 관계로 데이터를 처리할 인스턴스(소비자)가 큐(생산자)에 접근하여 능동적으로 메시지를 가져간다(Polling).

 

여러 애플리케이션에서 동시에 하나의 메시지를 처리하면 경합이 발생할 것이므로 가시성 제한 시간을 두어 하나의 애플리케이션에서만 처리할 수 있게 한다. 일반적으로 이 시간동안 메시지를 처리한 후 처리 완료한 메시지를 대기열에서 삭제한다. default는 30초이며, 0초~12시간 범위에서 설정 가능하다.

 

애플리케이션 예외 또는 트랜잭션 장애가 발생하면 Amazon SQS DLQ (Dead Letter Queue)로 리디렉션하여 나중에 다시 처리하게 할 수 있다.

 

Amazon SNS (Simple Notification Service)

Publisher - Topic - Subscriber의 구조로 퍼블리셔가 하나의 토픽으로 게시물을 게시하고(Pushing), 구독자는 게시물에 대한 알림을 받는 구조라고 볼 수 있다. 주로 애플리케이션에 대한 변경점에 이벤트를 걸어 특정 조건에서 트리거링 되게끔 설정한다. 예를 들어 Amazon S3에 새로운 데이터가 업로드 되었는데, 그 중 특정 컬럼값이 0이라면 푸시한다.

또한 당연히 Amazon SNS에 게시된 모든 메시지는 여러 서버와 데이터 센터에 걸쳐 저장된다.

 

Pushing : 흔히 푸시 알림이라고 하는 것이 이것이다. 

 

Amazon SNS의 구독 유형은 아래와 같다.

• Email/Email-JSON : 등록된 이메일 주소로 텍스트/JSON객체가 전송된다. 
• HTTP/HTTPS : 등록된 URL로 HTTP POST를 통해 알림이 전송된다.
• SMS 클라이언트 : 등록된 전화번호로 SMS 문자 메시지가 전송된다.
• Amazon SQS Queue : SQS 대기열에 알림 메시지가 추가된다(FIFO 대기열은 불가).
• AWS Lambda 함수 : 람다 함수에 메시지를 전송하여 후속적인 처리를 할 수 있다.

Amazon SQS에는 리콜 옵션이 없다. 메시지가 성공적으로 전송되면 이를 회수할 수 없다. 또한 주문 및 전달을 보장할 수 없다.

 

Amazon MQ (Message Queue)

Amazon MQ를 이용해 On-premise에서 사용하고 있는 Apache Active MQ와 연결된 하이브리드 시스템을 만들 수 있다.

또한 각 Amazon MQ를 서로 다른 AZ에 Primary와 Standby로 이중화하여 사용한다.

Amazon MQ	Amazon SQS 및 SNS
애플리케이션 마이그레이션 용도	클라우드 기반 앱 용도
프로토콜: JMS, NMS, AMQP, STOMP, MQTT, Web Socket	프로토콜: HTTPS
풍부한 기능	무제한 처리량
시간당 지불 및 GB당 지불	요청당 지불
Pub/Sub 가능	SQS는 불가, SNS는 가능

---

Micro Service (Container)

각 서비스들이 Tightly Coupled 되어 있는 Monolithic 방식은 한 애플리케이션이 Failure되면 전체 구조에 문제가 생기기 때문에 Loosely Coupled하게 구조화함으로써 독립적으로 만든다. 기본적으로 서비스들을 격리해놓고 서비스 간 통신은 REST API로 한다.

 

한 애플리케이션의 Code, Library, Dependency, Configuration 등을 패키지화 해서 하나의 컨테이너 이미지로 만들 수 있다. 컨테이너는 Hardware Level의 VM과는 달리 OS Level에서 만들고 운용되기 때문에 처리 속도가 더 빠르다(Docker Engine의 사용으로 GuestOS가 없음).

종속성, 라이브러리 등이 컨테이너 이미지 안에 전부 포함되어 있기 때문에 환경에 구애받지 않고 컨테이너를 돌릴 수 있다는 장점도 있다.

 

Amazon ECS(Elastic Container Service) / EKS(Elastic K8S Service)

Containers on EC2 Instances

위의 사진과 같은 구조로 볼 수 있다. 여러 개의 EC2 인스턴스들을 묶은 Amazon ECS Cluster 위에서 컨테이너가 실행되는 것이다.

ECS는 실행하는 노드 플릿을 유지 관리하고 확장한다. 또한 컨테이너의 배포를 모니터링하며, 클러스터의 전체 상태를 관리한다(인스턴스의 Auto Scaling 포함). Fargate 또는 EC2 두 가지 유형으로 시작 가능하다.

컨테이너 관리를 Docker가 하면 ECS, k8s가 하면 EKS이다. 

 

전체적인 ECS의 구조는 위와 같다. 마이크로 서비스로써 분리한 3가지의 서비스를 ALB를 통해 접근할 수 있다.

 

ECR(Registry)

컨테이너 이미지를 보관하는 레지스트리이다. ECS에서 컨테이너를 생성할 때 이곳을 참조해 이미지를 가져온다. 도커 허브와 비슷한 공간이라고 보면 된다.

---

Serverless

서버리스라고 해서 실제로 서버가 없는 것은 아니고 본인이 관리할 서버가 없다는 것이다.

서버리스는 개발자 등 인프라에 대한 지식이 충분하지 않은 사람이 앱과 서비스를 서버 위에서 실행할 수 있도록 AWS에서 서버를 자동적으로 관리해주는 서비스이다.

 

AWS Fargate - 완전 관리형 컨테이너 서비스

AWS Fargate는 완전관리형 컨테이너 서비스로써 모든 런타임 환경과 규모를 자동적으로 조정한다.

• 클러스터 프로비저닝 및 관리
• 런타임 환경 관리
• 규모 조정
• ECS 및 EKS 실행 가능

 

AWS Lambda

• 완전 관리형 컴퓨팅 서비스
• 상태 비저장 코드 실행
• Node.js, Java, Python, C#, Go, Ruby 지원
• 일정 또는 이벤트에 대한 응답으로 코드 실행=Kicking (ex: Amazon S3 버킷 또는 Amazon DynamoDB 테이블의 데이터 변경)
• 엣지에서 실행 가능(Node.js only)
• 구성이 아닌 애플리케이션에 집중
• 요청 시에만 컴퓨팅 리소스 사용
• 마이크로 서비스 아키텍처 구축
• 월별 100만 건 호출까지 무료
• 메모리 사이즈 범위 128MB~3GB를 64MB씩 46단계로 분류(CPU는 메모리에 맞춰 변경됨)되어 비용 발생
• 최대 15분 동안만 명령을 실행할 수 있기 때문에 하루종일 운용해야 하는 서비스의 경우엔 서버리스가 아닌 수동으로 EC2 인스턴스를 만들어 실행하는 편이 낫다.

AWS Lambda가 처리하는 작업

• 서버
• 용량 요구
• 배포
• 조정 및 내결함성
• OS 또는 언어 업데이트
• 지표 및 로깅

AWS Lambda 응용 아키텍처 시나리오

API Gateway

애플리케이션의 현관 역할을 하는 API를 생성할 수 있다.

최대 수십만 건의 동시 API 호출을 처리한다. Amazon EC2, AWS Lambda, 모든 웹 애플리케이션에서 실행되는 워크로드를 처리할 수 있다.

API Gateway를 사용함으로써 엔드포인트 노출 방지, DDoS 및 스크립트 주입 공격으로부터 보호된다.

 

API Gateway는 API 키를 생성하여 개발자에게 배포하고, 서명 버전 4를 이용해 API에 대한 액세스를 승인한다. 또한 AWS Lambda와 긴밀하게 통합된다.

API Gateway를 활용해 위와 같은 아키텍처를 가져갈 수 있다.

---

RTO/RPO - Backup

RTO (Recovery Time Objective)

장애가 발생했을 경우의 목표 복구 시간이다. 실제로 애플리케이션을 사용할 수 없는 시간을 의미한다.

 

RPO (Recovery Point Objective)

장애가 발생했을 경우 그 이전의 알려진 상태로의 롤백할 포인트를 의미한다. 쉽게 말해 백업 주기라고 할 수 있다.

 

AWS Backup

• 중앙 집중식 백업 관리
• 정책 기반 백업 솔루션
• 태그 기반 백업 정책
• 자동화된 백업 일정 관리

---

Recovery

위의 다이어그램은 인프라 복구 방법 중 파일럿 라이트 방식이다. 온프레미스에서 기본적으로 서버를 구동하고 있으며, AWS 측엔 실행 중이 아닌 준비된 인스턴스(Seed Light=불씨)들이 있고 Standby DB가 미러링 되어지고 있다.

온프레미스 측에서 Failure가 나면 몇 분 안으로 AWS의 인스턴스가 올라오고 서비스를 지속할 수 있게 된다. 

파일럿 라이트 밖에도 비용과 가용성이 높은 솔루션들이 존재한다.