AWS 복원력을 갖춘 아키텍처 설계

안정적이고 복원력을 갖춘 스토리지 선택

스토리지는 안정성과 복원력이 있어야한다. 스토리지에 복원력이 있어야 하는 이유는 그래야 재해가 발생해도 데이터나 상태가 손실되지 않기 때문이다.

AWS 서비스를 사용하여 결합 해제 메커니즘을 설계하는 방법 결정

AWS 서비스가 제공하는 느슨한 결합 메커니즘을 아키텍처에 사용해야 한다. 느슨한 결합은 한 티어나 구성 요소에 장애가 발생해도 다른 것은 영향을 받지 않는다. 이미 분리되어 있기 때문이다. AWS가 제공하는 서비스를 사용하면 느슨한 결합을 구성하기 더 쉽다.

멀티 티어 아키텍처 솔루션을 설계하는 방법 결정

가능하면 멀티 티어 아키텍처를 사용하여 설계해야 한다. 멀티 티어 아키텍처는 자연적으로 분리된다. 각 티어는 독립적으로 조정할 수 있다. 조정 이벤트가 발생할때 전체 애플리케이션을 조정하지 않아도 된다.

고가용성 및 내결함성을 갖춘 아키텍처를 설계하는 방법 결정

고가용성과 내결함성을 갖춘 아키텍처를 설계해야한다. 대규모로 운영할 때는 장애를 비정상적이거나 예외적인 이벤트로 취급하는 대신 정상적인 운영 이벤트로 취급해야 한다. 결함이 발생하더라도 애플리케이션이 고가용성을 유지하고 사용자들에게 계속 가치와 서비스를 제공해야 한다.

스토리지 옵션

EC2 인스턴스 스토어

EC2 컴퓨팅 인스턴스가 실행되는 물리적 하드웨어에 있다. 인스턴스 스토어는 휘발성으로 인스턴스가 종료되거나 중지되면 손실된다. EBS와 대조적이다. 인스턴스 스토어는 특정 EC2 인스턴스 유형에만 있다. 물리적 호스트에 있는 스토리지이기 때문에 크기가 고정되어 있다. SSD 또는 하드 디스크 드라이브 같은 스토리지 유형도 인스턴스 유형에 따라 고정되어 있고 용량 또한 마찬가지로 고정되어 있다. 두 가지 모두 인스턴스 유형의 함수이다. 애플리케이션이 실행되는 동안에는 인스턴스스토어에 의존해도 되지만 휘발성이므로 그 이상 의존해서는 안된다. 일반적으로 캐싱 또는 다른 곳에 복제하는 임시 데이터를 저장하는데 사용한다. 이렇게하면 인스턴스 스토어가 제공하는 빠른 액세스를 사용하면서 인스턴스 스토어의 휘발성에는 영향을 받지 않는다.

• 휘발성 볼륨
• 특정 EC2 인스턴스만
• 고정 용량
• 디스크 유형과 용량은 EC2 인스턴스 유형에 따라 결정
• 애플리케이션 수준 내구성

Elastic Block Store

EBS는 한 번에 하나에 EC2 인스턴스에 연결가능한

• 다양한 유형
• 암호화
• 스냅샷
• 프로비저닝된 용량
• EC2 인스턴스와 독립적인 수명 주기
• 대량의 볼륨을 생성할 수 있도록 여러 볼륨 스트라이프

	SSD		HDD
볼륨 유형	범용 (gp2)	프로비저닝된 IOPS(io1)	처리량 최적화(st1)	콜드(sc1)
사례	대부분 워크로드 권장 시스템 부트 볼륨 가상 데스크톱 짧은 지연시간 대화형 앱 개발 및 테스트 환경	지속적인 IOPS 성능이나 높은 처리량을 필요로 하는 비즈니스 대규모 데이터베이스 워크로드	저렴한 가격으로 일관되고 빠른 처리량을 요구하는 스트리밍 워크로드 빅 데이터 데이터 웨어하우스 로그 처리 부트 볼륨 불가능!	자주 액세스하지 않는 대용량 데이터의 처리량 중심 스토리지 비용이 낮아야하는 경우 부트 볼륨 불가능!
볼륨 크기	1GiB~16TiB	4GiB~16TiB	500GiB~16TiB	500GiB~16TiB
최대 IOPS/볼륨	10,000	32,000	500	250
최대 처리량/볼륨	160MiB/s	500MiB/s	500MiB/s	250MiB/s
기준 성능 속성	IOPS	IOPS	MiB/s	MiB/s

Amazon EFS(Elasic File System)

EFS는 공유 스토리지를 제공하며 여러 EC2 인스턴스가 동일한 EFS 볼륨에 액세스할 수 있다. EFS는 페타바이트 규모의 스토리지를 제공하며 탄력적으로 사용량에 따라 확장되고 축소된다.

• AWS 클라우드의 파일 스토리지
• 공유 스토리지
• 페타바이트 규모 파일 시스템
• 탄력적 용량
• NFS v4.0 및 4.1(NFSv4) 프로토콜 지원
• Amazon EC2의 Linux 기반

EFS 아키텍처

EFS 볼륨을 만든 다음 특정 VPC에 탑재 지점을 만든다. EFS 볼륨은 한번에 하나의 VPC에 연결할 수 있다. 이 VPC안에서 EC2 인스턴스가 연결할 수 있는 탑재 지점이 제공된다.

Amazon S3

AWS가 제공하는 기본 옵션으로 S3는 무제한 스토리지를 제공하기 위해 분산시스템으로 제공된다. 일관성 모델이 강력한 일관성인지 최종 일관성인지 알아야한다.

새로운 객체의 경우 강력한 일관성을 제공하며, 업데이트의 경우에는 최종 일관성을 제공한다.

최종 일관성이란 객체를 업데이트하고 그 후에 읽기-쓰기를 수행하면 객체의 이전 버전을 얻을 수 있다. 그 이유는 분산 시스템이기 때문이다.

• S3 Standard: 액세스 비용이 저렴하다. 업로드 및 다운로드 비용이 저렴
• S3 Standard-IA: 스토리지 비용이 저렴하지만 액세스 비용이 비싸다. 서버 측 암호화를 위한 몇가지 암호화를 제공한다.

-- SSE-S3: S3가 관리하는 마스터 키를 사용하여 서버 측에서 파일을 암호화한다.

-- SSE-KMS: KMS 관리형 마스터키를 사용하여 서버 측에서 파일을 암호환다.

--SSE-C: 고객에 제공하고 관리하는 키를 사용하여 서버 측에서 파일을 암호화한다.

S3는 HTTPS를 이용한 업로드, 다운로드를 지원하여 전송 데이터를 암호화할 수 있다.

버킷의 버전관리를 활성화할 수 있다. 사용자의 실수로 인한 파일 삭제, 재정의로부터 파일을 보호한다.

IAM 사용자 정책이나 버킷 정책 또는 ACL을 통해 S3 액세스를 제어할 수 있다.

멀티파트 업로드를 지원하므로 큰 파일을 병렬 업로드가 가능하다.

인터넷 액세스가 가능한 API를 지원하며 무제한의 용량을 지원한다.

일레븐 나인의 가용성을 제공한다.

Amazon Glacier

데이터 백업 및 아카이브 스토리지 솔루션으로 파일 및 저장소에 해당하는 아카이브를 제공하는 아카이브의 모음이다. 기본적으로 데이터를 암호화하며 신속, 표준, 벌크의 세 가지 검색 유형이 있다.

• 신속: 비싸지만 빠르며 현재 최대 5분
• 벌크: 가장 저렴하지만 가장 느리다. 현재 최대 12시간

버킷에 S3 객체 수명 주기 정책을 설정하여 Glacier를 사용하는 방법이 추천된다. 수명 주기 정책은 일정기간 후 자동으로 Glacier으로 이동하는것으로 오래된 파일을 관리하는데 용이하다.

일레븐 나인의 가용성을 제공한다.

고가용성과 내결함성의 차이

고가용성은 시스템이 작동하고 사용 가능함

내결함성은 사용자가 결함의 경험을 전혀 하지못하고 SLA가 충족되는 것 인스턴스를 항상 사용할 수 있어야하는것으로 내결함성의 요구사항이 고가용성보다 높다.

CloudFormation

AWS 리소스를 배포하기 위한 선언형 프로그래밍 언어로 템플릿과 스택을 사용하여 리소스를 프로비저닝 한다.

리소스 집합을 단일 단위(스택)로 생성, 업데이트, 삭제한다.

인프라를 JSON 템플릿으로 설명한 다음 이를 스택이라고 하는 인프라로 변환할 수 있는 서비스로 인프라의 여러 복사본을 쉽게 만들수 있다. 하드웨어를 정의하지만 코드로 취급할 수 있어 하드웨어와 소프트웨어의 구분이 모호해지며 복원력을 촉진시킨다. 언제든 아무것도 없는 상태에서 애플리케이션을 시작할 수 있다. CloudFormations은 시스템의 DNA와 같다.

AMI를 사용하여 서로 다른 두 리전에 EC2 인스턴스를 배포하기 위해 CloudFormation을 사용하는 경우 어떻게 해야하는가?

템플릿은 리전마다 달라지지 않는다.

AMI ID에 파라미터를 사용할 수 있지만 템플릿이 취약해져 권장되지 않는다.

AMI ID는 리전마다 다르기 때문에 매핑을 사용하여 기본 AMI를 지정한다.

AWS Lambda

이벤트 또는 시간 기반 간격에 대한 응답으로 상태 비저장 코드(Node.js, Java, C#, Go, Python)를 실행하는 완전관리형 컴퓨팅 서비스이다.

Amazon EC2 인스턴스 및 Auto Sacling 그룹과 같은 인프라를 관리하지 않고도 코드를 실행할 수 있다.

상태 비저장 코드를 제공하면 AWS는 호출할때마다 온디멘드로 코드를 실행하는 컨테이너를 스핀업 한다. 호출당 비용을 지불한다. 애플리케이션을 확장 가능하고 복원력이 있도록 만드는 좋은 방법으로 Lambda가 추천된다. 확장력과 복원력을 AWS에 위임하기 때문이다.

Lambda는 SSH 접속을 허용하지 않으며, 로그문은 S3가 아닌 CloudWatch Logs에 남는다. 이는 Lambda 디버깅에 유용하다.

RTO와 RPO

RTO 복구 시간 목표는 시스템이 복구되어 다시 온라인 상태가 되는데 걸리는 시간(초, 분, 시간으로 측정)

RPO 복구 시점 목표로 시스템 장애시 손실되는 데이터의 양을 뜻한다. 메가바이트 또는 기가바이트 단위로 측정되며 시간 단위로도 측정된다. 이때는 그 기간만큼의 양이 손실된다는 것