interplanetary detour

Amazon SNS vs. Amazon SQS

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로 이중화하여 사용한다.

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의 인스턴스가 올라오고 서비스를 지속할 수 있게 된다. 

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

WAF (Well Architected Framework)

Web Application Firewall과 헷갈리지 말자.
설계를 검토해주는 역할을 한다.
보안, 안전성, 비용 최적화, 성능 효율성, 운영 우수성 5가지 항목을 확인.

대규모 아키텍처 다이어그램

S3 vs. EBS

S3 (Simple Storage Service)

Region Level로 만들 수 있는 Web 기반의 스토리지 서비스.
위 다이어그램에 있는 양동이 모양의 '정적 자산'이 바로 이 S3이다.
S3 안에 여러 개의 Bucket이 있고, Bucket 안에 Object 단위로 파일을 저장한다.

업로드한 파일의 일부만 변경되어도 전체 파일을 처음부터 다시 업로드해야 하므로 S3에는 정적인 파일을 저장하는 편이 좋다(WORM : Write Once Read Many).
주로 온프레미스, AMI, EBS의 백업 데이터를 저장하며, Data Lake로써 머신 러닝 등에 사용될 수도 있다.
병렬(Load Balancing)로 읽기/쓰기가 가능하다.

1. 파일 1개 당 5TB 이하
2. 업로드 파일 갯수 무제한
3. 스토리지 전체 사이즈 무제한
4. 업로드 횟수 무제한
이라는 특징을 가지고 있다. 업로드 관련 기능은 무료이지만 스토리지로부터 데이터를 GET할 때 비용이 발생한다.

S3 Bucket Policy
Permissions의 Bucket Policy에 JSON 형식으로 Bucket 별 액세스 제어 정책을 정의할 수 있다.
디폴트로는 비공개이며, 외부로부터의 모든 접근 허용 또는 일부 접근 허용 등의 설정이 가능하다.

Amazon S3 Transfer Acceleration
파일의 근원지로부터 S3에 업로드 되기까지 100% 인터넷 회선을 통하는 대신 이동 과정 중간부터는 Amazon CloudFront(One of Edge Location Features)를 이용해 Amazon Backbone Network를 통한 보다 안전하고 신속한 데이터 이동이 가능하다.

AWS Physical Data Transfer Solutions
10TB 초과의 대용량 데이터를 더 빨리 전송할 수 있는 물리적 솔루션이다.
AWS Snowball은 기내용 캐리어 정도 크기의 저장소이다. 약 80TB의 데이터를 물리적으로 운송할 수 있다.
AWS Snowmobile은 대형 트럭 크기의 데이터 트럭이다. 약 100PB의 데이터를 물리적으로 운송할 수 있다.

S3 4 Tiers
S3 Standard
S3 Standard IA (Infrequent Access)
S3 One Zone IA
S3 Glacier (Backup)

아래로 갈 수록 저장 비용↓ 검색 비용 및 속도↓
Glacier는 신속 검색 5분, 표준 검색 3~5시간, 대량 검색 5~12시간이 소요된다.
S3 Intelligent Tiering : AWS에서 자동으로 데이터들을 티어링한다.

ILM (Information Lifecycle Management)

Amazon S3 수명 주기 정책을 사용하면 생성 후 기간을 기준으로 객체를 삭제 또는 이동할 수 있다.

EBS (Elastic Block Store)

하나의 인스턴스에 Attach 되어 종속되어지는 스토리지이다. EBS 1개 당 최대 16TB까지 저장 가능하다.
외장 하드를 구매할 때와 같이 리소스를 Provisioning할 때 그만큼 지불한다.

인스턴스의 데이터 저장용으로 실제 물리적 호스트의 Local Storage 이용 시 인스턴스가 멈췄다가 다시 시작될 경우 다른 물리적 호스트에서 실행될 것이기 때문에(같은 AZ 내일 뿐) 휘발성인 Local Storage가 아닌 별도의 Storage Farm에 있는 EBS를 인스턴스에 매핑시켜 데이터를 저장하게 한다(네트워크를 통한 연결).

Database on AWS

DB 결정 시 고려할 사항으로는 확장성, 총 스토리지 요구 사항, 객체 크기 및 유형, 내구성이 있다.

DB - RDS (Relational Database Service)

AWS에서 관계형 데이터베이스는 Oracle DB, MS-SQL Server, MySQL, MariaDB, PostgreSQL, Aurora 총 6가지를 사용할 수 있다. 이 중 Aurora는 AWS에서 자체 개발한 DB로 완전관리형 데이터베이스이며, MySQL, PostgreSQL과 호환이 가능하다. Aurora를 플랫폼으로 MySQL 사용 시 기존의 최대 5배 처리량, PostgreSQL의 경우 최대 3배.
수직적으로 리소스 조절(Scale Up/Down).

RDS Security
I/O 경합을 막기 위해 Read Replica를 만들어 읽기 부하를 분산시킬 수 있다.
Amazon Aurora는 15개, 나머지 5가지 RDB는 5개까지 Read Replica를 만들 수 있다.
저장 시 KMS를 이용해서 암호화. 통신 시 SSL 암호화 사용.

DB - NoSQL

Document DB : MongoDB
GraphDB : Amazon Neptune, Cassandra
Key-Value DB : Amazon DynamoDB, Redis

DynamoDB는 완전관리형 비관계형 데이터베이스 서비스이다.
Amazon의 전자상거래 서비스에서 일어나는 많은 트랜잭션을 처리하기 위해 개발되었다.
이벤트 중심 프로그래밍(서버리스 컴퓨팅)이다.
수평적으로 리소스 조절(Scale In/Out).

Eventually Consistance Read(DynamoDB default) : 레이턴시 최소화. 게임 등에서 사용한다.
Strongly Consistance Read : 금융권 등에서 사용. 계좌의 잔고가 동기화되지 않으면 큰일이므로 강력하게 읽기 일관성을 정의한다.

DynamoDB Security
Row, Column 등 모든 것에 대해 액세스 권한 부여 가능.
저장 시 KMS를 이용해서 암호화. 통신 시 SSL 암호화 사용.

AWS DMS (Database Migration Service)

AWS는 대부분의 상용 및 오픈 소스 데이터베이스와의 마이그레이션을 지원.
데이터베이스가 너무 클 경우 AWS Snowball Edge(Snowball + Computing Resource)와 연동해 마이그레이션 할 수 있다.

AWS Schema Conversion Tool
이종 마이그레이션의 경우 AWS SCT를 통해 데이터베이스 엔진을 변환해 마이그레이션이 가능하다.