AWS 성능이 뛰어난 아키텍처 설계

성능이 뛰어난 스토리지 및 데이터베이스 선택

EBS는 블록 스토리지에 해당한다. EC2 인스턴스에 EBS 볼륨을 디스크로 탑재할 수 있다.

SSD는 더 비싸고 IOPS, 랜덤 액세스 읽기 및 쓰기 성능이 더 좋다. HDD는 저렴하고 순차적 읽기 및 쓰기 성능이 더 좋다. (ex 순차적 빅 데이터 파일 처리)

	솔리드 스테이트 드라이브(SSD)		하드 디스크 드라이브(HDD)
	범용	프로비저닝된 IOPS	처리량 최적화	콜드
최대 볼륨 크기	16TiB	16TiB	16TiB	16TiB
볼륨당 최대 IOPS	10,000	32,000	500	250
최대 처리량/볼륨	160MiB/s	500MiB/s	500MiB/s	250MiB/s

고성능 아키텍처의 관건은 모든 정적 처리를 서버에 오프로드 하는 것이 아닌 S3에 위임하는 것이다. HTML 파일, JavaScript 파일, CSS 파일, 이미지, 비디오 등의 정적 콘텐츠가 있는 정적 폴더를 S3로 이동하면 웹 서버의 성능이 향상되고 부하를 줄여준다.

Amazon S3

파일을 S3에 업로드하기위해서는 1. AWS 리전 중 한곳에 버킷을 생성하고, 2. 원하는 만큼 버킷에 업로드 한다.

버킷의 이름은 리전에 관계없이 고유하며 S3 URL의 하위 도메인이 된다. 업로드한 객체는 S3 버킷 이름에 따라 자동으로 URL이 할당된다. URL은 가상 호스팅 스타일 또는 경로 호스팅 스타일 URL이 될 수 있다.

가상 호스팅 스타일 URL에는 도메인 이름의 일부로 버킷 이름이 포함되어 있으며, 경로 호스팅 스타일의 경우에는 첫 번째 부분에 버킷 이름이 있다. URL에 리전을 지정하거나 리전이 없어도 버킷이 저장된 적절한 리전으로 연결된다. (리전과 독립적인 이름을 참조하더라도 버킷은 항상 리전에 연결된다.)

버킷의 이름뒤에 오는 파일의 경로를 ‘키’라고 부른다.

Bucket의 요금

버킷의 요금은 GB단위 월별 스토리지, 리전 밖으로 전송, API 요청 세 가지 요소로 구성된다. 사용한 만큼만 비용을 지불한다.

Amazon S3로 전송과 Amazon S3에서 Amazon CloudFront 또는 같은 리전의 전송또한 무료

S3의 스토리지 클래스

Amazon S3 Standard(범용): 검색 요금이 저렴하지만 스토리지 비용이 비싸다. 가용성 요구 사항이 더 높은 경우 교차 리전 복제를 사용하면 된다.

Amazon S3 Standard - Infrequent Access: 액세스 빈도가 낮은 데이터로 저장된 GB당 비용이 저렴하다. 하지만 API (GET, POST, PUT, COPY) 요청당 비용이 높다. 최소 30일 저장 기간을 가진다.

S3의 수명 주기 정책

Amazon S3 수명 주기 정책을 사용하여 생성 후 기간을 기준으로 객체를 삭제 또는 제거한다.

(S3 Standard → S3 IA → Amazon Glacier 로 저장 기간에 따라 자동으로 이동하고 최종적으로 삭제도 가능하다 또한, 액세스 빈도가 낮은경우, 높은 한 데이터의 경우 구분하여 남겨두기)

Amazon S3와 블록 및 파일 스토리지가 다른점

S3는 객체를 무한대로 저장하는 것이 가능하며, 객체가 불변으로 바이트 하나라도 바꾸려면 객체 자체를 교체한다. 따라서 버전관리를 할 수 있다. 그리고 객체가 가용 영역간에 복제된다. 리전 복제는 아니다!

Amazon EBS에 저장된 데이터는 가용 영역 내에 자동 복제된다.

데이터베이스의 고성능 스토리지

RDS

RDS(Relational Database Service)를 사용하여 관계형 데이터 베이스 설정

Amazon DynamoDB로 관리형 NoSQL 데이터베이스를 설정

Amazon Redshift로 데이터 웨어하우스를 설정. 순차적 인터페이스를 제공하며 분석 쿼리와 트랜잭션 쿼리가 있는 경우 유용하다. 행을 삽입하거나 가져오지 않고 전체 테이블에서 집계 수를 계산할 수 있다. (ex 전국 매장의 판매량 계산)

RDS를 사용하는 경우

• 복잡한 트랜잭션 또는 복잡한 쿼리
• 중간 또는 높은 수준의 쿼리/쓰기 속도
• 단일 작업자 노드/샤드를 사용
• 높은 내구성

RDS는 관리되는 관계형 데이터베이스를 제공한다. MySQL, Postgres, MariaDB, Aurora SQL Server, Oracle 중에서 선택할 수 있다. 쿼리 쓰기 속도는 DynamoDB보다 낮다.

RDS를 사용하지 않아야 하는 경우

• 대규모 읽기/쓰기 속도(ex 150,000 쓰기/초)
• 샤딩
• 간단한 GET/PUT 요청 및 쿼리
• RDBMS 사용자 지정

DynamoDB는 읽기 쓰기 속도가 매우 빠르며, 자동으로 샤딩을 지원한다. 또한 서버를 더 추가하여 수평 확장을 무제한으로 할 수 있다. 간단한 요청 및 쿼리 또한 DynamoDB가 유리

읽기 전용 복제본을 사용하는 RDS

Aurora, Postgres, MySQL, MariaDB에서 지원된다. 읽기 전용 복제본을 사용하면 READ 요청은 읽기 전용 복제본에 오프로드 하고 프라이머리 데이터베이스의 부하 일부를 덜 수 있다.

DynamoDB

원하는 읽기 쓰기 횟수 즉, 처리 용량 요구 사항에 따라 리소스를 할당 한다. 비관계형

• 읽기 용량 단위(RCU): 최대 4KB 크기의 항목. 초당 1건의 강력한 일관된 읽기 즉 항목을 쓰고 다시 읽는 경우 언제나 최신 값을 얻을 수 있다, 초당 2건의 최종적 일관된 읽기로 줄일 수 있다.
• 쓰기 용량 단위(WCU): 최대 1KB 크기으 항목. 초당 1건의 쓰기

DynamoDB는 영구 데이터 스토어로 쉽게 설정하고 사용할 수 있는 AWS 관리형 NoSQL

캐싱을 적용하여 성능 개선

CloudFront

CloudFront 같은 CDN을 사용하여 캐싱하면 즉각적인 성능 향상을 보인다.

사용자가 데이터를 요청하면 최적의 엣지 로케이션으로 요청이 라우팅 된다. 엣지 로케이션에 데이터가 없다면 오리진에서 데이터를 받아오고 응답한다. 그 다음 요청부터는 엣지 로케이션에서 데이터를 전달하기 때문에 오리진까지 가는 소요 시간 이득을 얻을 수 있다.

인터넷을 통한 콘텐츠 전송 속도를 높이는데 유용하다. 정적, 동적 콘텐츠 모두에 사용할 수 있다. 동적 컨텐츠를 사용하는 경우 캐싱의 이점은 없지만 AWS 백본을 통해 이동한다는 이점을 얻을 수 있다.

정적 콘텐츠의 오리진으로 S3를 선택할 수 있고, 동적 콘텐츠의 오리진으로 EC2, Elastic Load Balancer 또는 HTTP 서버가 될 수 있다.

SSL을 지원한다. 컨텐츠 거부 공격 보호하는 AWS Shield와 통합되어 있다. AWF도 통합. AWF는 요청의 내용을 보고 필터링 할 수 있다.

ElasticCache

데이터베이스 백엔드에서 반복해서 데이터를 가져오는 리소스 낭비를 줄일 수 있다.

Memcached와 Redis 두 가지 캐시 옵션을 지원한다.

Memcached

설정이 간편하여 유지 관리가 용이하다. 멀티스레딩을 지원하며 Auto Discovery를 통한 간편한 수평 조정을 할 수 있다.

Redis

• 데이터 구조를 지원
• 지속성
• 최소 단위 작업
• Pub/Sub 메시징
• 읽기 전용 복제본/페일오버
• 클러스터 모드/분할된 클러스터

더 정교하고 여러 데이터 형식을 지원한다. 단순한 키-값 저장 이상이다.

탄력성과 확장성을 갖춘 솔루션 설계

트래픽 스파이크에 대응하여 리소스를 확장하거나 축소 가능한 설계를 해야 한다.

수직정 조정: 인스턴스의 사양을 변경(스케일 업, 스케일 다운) 수평적 조정: 인스턴스의 수 변경(스케일 인, 스케일 아웃)

Auto Scaling

오토스케일링은 AZ에서 인스턴스를 시작 또는 종료할 수 있다.

새 인스턴스를 로드 밸런서에 자동으로 등록하고 인스턴스가 종료되기 전에 등록을 해지할 수 있다.

여러 가용 영역에 걸쳐 시작할 수 있다.

AWS의 모니터링 서비스 CloudWatch를 사용하여 인스턴스를 모니터링한다. 예를들어 인스턴스의 CPU 사용율을 모니터링하는 경우 CloudWatch에 수집된 지표가 임계값을 초과하면 Auto Sacling에 경보를 생성하는데 이 경보를 Auto Sacling이 인식할 수 있다. 이때, Auto Scaling 정책을 사용하여 어떤 작업을 수행할지 지정한다. 정책은 어떤 인스턴스 타입인지 수는 얼마인지 결정한다.

Auto Scaling 구성 요소

• Auto Scaling 시작 구성: EC2 인스턴스 크기 및 AMI 이름 및 기타 인스턴스 시작을 위한 정보 지정
• Auto Scaling 그룹: 시작 구성을 가리킨다. 최소 인스턴스 수와 최대 인스턴스 수 그리고 원하는 인스턴스 수를 지정한다. 이것이 어느 ELB를 가리키는지 설정하고 인스턴스 도움말을 확인하는 방법 지정
• Auto Scaling 정책: 스케일 인과 스케일 아웃 규모를 지정한다. 여러 Auto Scaling 정책을 하나의 그룹에 지정 할 수 있다.

CloudWatch 지표

Auto Scaling은 ClousWatch를 이용하여 스케일 아웃/인 할 시기를 결정한다.

CloudWatch는 CPU 사용률, 네트워크 지표, 대기열 크기 등의 지표를 모니터링 할 수 있다. 단, 인스턴스의 프로세스 공간에 액세스하지 않으므로 메모리 사용률을 추적할 수는 없다.

EC2, Lambda 그리고 CloudTrail에서 로그를 수집하는 CloudWatch Logs 기능이 있는데 로그를 저장할 수 있고, 로그를 추출하여 지표로 변환할 수 있다.

애플리케이션에서 사용자 지정 지표를 정의할 수 있다.

운영 우수성을 지원하는 AWS 서비스

운영 우수성의 기본 개념은 변화하는 환경에 적응하는 자동화된 시스템을 갖추는것이다.

운영 우수성의 원칙으로 코드를 사용하여 운영한다. 인프라 운영은 자동화 하는것이 좋다.

설명서에 주석을 추가한다. 설명서가 배포된 리소스를 실시간으로 나타낼 수 있도록 주석을 추가하자.

소규모의 취소 가능한 변경을 빈번하게 수행한다. 시스템을 모니터링 할 방법이 필요하다. 변경 후 시스템의 동작을 관찰하고 눈에 띄는 개선이 없다면 되돌려야 한다.

장애를 예측하고, 게임 데이를 연습해서 실패에서 학습한다. 같은 장애를 재발 방지.

AWS Config

EBS 볼륨 및 EC2 인스턴스와 같은 리소스를 추적한다. 새 리소스가 구성 규칙을 준수하는지 확인한다.

AWS CloudFormation

JSON 또는 YAML 템플릿을 인프라와 리소스로 변환한다.

AWS CloudTrail

API 호출을 로깅한다.

AWS Trusted Advisor

계정에서 보안, 안정성, 성능, 비용 그리고 서비스 한도에 관한 모범 사례를 검사한다.

AWS Inspector

EC2 보안 취약점을 검사

VPC Flow Logs

네트워크 트래픽을 로깅한다. 계층 3및 4의 IP 수준 로그를 수집한다.