AWS에서 제공하는 SAA 준비 교육 영상 컨텐츠를 글로 적었습니다.
| SSD | HDD | |||
|---|---|---|---|---|
| 볼륨유형 | 범용 SSD(gp2) | 프로비저닝된 IOPS SSD(io1) | 처리량 최적화 HDD(st1) | 콜드 HDD(sc1) |
| 사용 사례 | - 대부분의 워크로드에 권장됨 - 시스템 부트 볼륨 - 가상 데스크톱 지연 시간이 짧은 대화형 앱 - 개발 및 테스트 환경 |
- 지속적인 IOPS 성능이나 10,000 IOPS 또는 160MiB/s 이상의 볼륨당 처리량을 필요로 하는 중요한 비즈니스 애플리케이션 - 대규모 데이터베이스 워크로드 |
- 저렴한 가격으로 일관되고 빠른 처리량을 요구하는 스트리밍 워크로드 - 빅 데이터 - 데이터 웨어하우스 - 로그 처리 - 부트 볼륨이 될 수 없음 |
- 자주 엑세스하지 않는 대용량 데이터를 위한 처리량 중심의 스토리지 - 스토리지 비용이 최대한 낮아야 하는 시나리오 - 부팅 볼륨이 될 수 없음 |
| 볼륨 크기 | 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/초 | MiB/초 |
HDD가 순차적 엑세스에 좋은 이유는 무엇일까?
순차적 엑세스에서는 읽어야 하는 데이터 블록은 크고 읽기 및 쓰기 작업은 적다.
예를 들어 로그 파일을 처리하는 경우나 레코드 시퀀스가 포함된 파일로 구성된 빅데이터 워크로드를 처리하는 경우 HDD는 저렴한 가격으로 뛰어난 성능을 제공한다.
SSD와 HDD 안에는 두 가지 EBS 볼륨 하위 유형이 있다.
gp2, 즉 범용 SSD는 보다 저렴한 SSD 볼륨이고 io1, 즉 프로비저닝된 IOPS SSD는 보다 비싸다.
프로비저닝된 IOPS는 가격이 더 비싸지만 읽기 및 쓰기 수를 확장할 수 있고 더 나은 성능을 제공한다.
마찬가지로 HDD의 경우 처리량 최적화 HDD st1이 콜드 HDD인 sc1보다 비싸고 사양이 더 좋다.
요약하면 SSD는 랜덤 엑세스에 적합하다. HDD는 순차적 엑세스에 적합하다.
SSD와 HDD에도 더 비싼 옵션과 더 저렴한 옵션이 있다.
SSD가 HDD보다 비싸다. SSD 안에서도 프로비저닝된 IOPS SSD가 범용 SSD보다 비싸다.
HDD 안에서는 처리량 최적화 HDD가 콜드 HDD보다 비싸다.
데이터베이스가 EC2 인스턴스에서 실행중입니다. 데이터베이스 소프트웨어에는 블록 스토리지가 필요한 백업 기능이 있습니다. 어떤 스토리지가 백업 데이터에 가장 저렴한 옵션입니까?
A. Amazon Glacier
B. EBS 콜드 HDD 볼륨
C. Amazon S3
D. EBS 처리량 최적화 HDD 볼륨
문제를 보면 데이터베이스가 있고 EC2 인스턴스가 있다. 블록 스토리지가 필요하고 가장 저렴한 옵션을 원한다.
그렇다면 블록 스토리지가 아닌 Glacier를 제거할 수 있다.
동일한 논리로 S3도 제거할 수 있다.
Glacier와 S3는 사용자가 들어가 파일을 수정할 수 없다. 객체 스토어이기 때문이다.
객체를 변경하려면 교체해야 한다.
남은 두가지 EBS 옵션 중 하나는 다른 하나보다 비싸다. 그러므로 EBS 처리량 최적화 HDD 볼륨 옵션을 제거할 수 있다.
EFS는 공유 스토리지를 제공하며 여러 EC2 인스턴스가 동일한 EFS 볼륨에 엑세스할 수 있다.
EFS는 페타바이트 규모의 스토리지를 제공한다.
이 용량은 탄력적이다. 사용량에 따라 확장되고 축소된다.
EFS는 NFS 4.0 및 4.1을 지원하고 Amazon EC2의 Linux기반 AMI와 호환된다.
EFS 볼륨을 만든 다음 특정 VPC에 탑재 지점을 만든다. EFS 볼륨은 한 번에 하나의 VPC에만 연결할 수 있다. 이 VPC 안에서 EC2 인스턴스가 연결할 수 있는 탑재 지점이 제공된다.
객체 스토리지의 경우 AWS가 제공하는 기본 옵션은 S3이다.
S3의 일관성 모델을 이해하는 것이 중요하다.
S3는 무제한 스토리지를 제공하기 위해 분산 시스템으로 구현된다.
분산 시스템에 대해 늘 해야 할 질문이 있다. 일관성 모델이 강력한 일관성(strong consistency)인지 최종 일관성(eventual consistency)인지 알아야 한다.
S3는 새로운 객체의 경우 강력한 일관성을 제공한다. 업데이트의 경우에는 최종 일관성을 제공한다.
최종 일관성이란 객체를 업데이트하고 그 후에 읽기-쓰기를 수행하면 객체의 이전 버전을 얻을 수 있다는 뜻이다. 그 이유는 확장 가능한 분산 시스템이기 때문이다.
S3는 몇가지 스토리지 클래스를 제공하는데 특히 S3 Standard와 S3 Standard-IA가 중요하다.
스토리지 클래스마다 장단점이 있다.
S3 Standard는 엑세스 비용이 저렴하다. 업로드 및 다운로드 비용이 더 저렴하다.
S3 Standard-IA는 스토리지 비용이 저렴하지만 엑세스 비용은 더 비싸다.
S3 Standard-IA는 서버 측 암호화를 위한 몇 가지 옵션을 제공한다.
이러한 약어는 AWS 설명서에서 흔히 사용되므로 알아 두는 것이 좋다.
S3는 HTTPS를 사용한 업로드와 다운로드를 지원하므로 전송 데이터를 암호화할 수 있다.
S3에서는 버킷의 버전 관리를 활성화할 수 있다. 이렇게 하면 업데이트되거나 삭제된 파일의 이전 버전을 여전히 사용할 수 있다. 이 방법은 실수로 인한 삭제나 재정의로부터 파일을 보호할 수 있는 좋은 방법이다.
IAM 사용자 정책이나 버킷 정책 또는 ACL(엑세스 제어 목록)을 통해 S3 엑세스를 제어할 수 있다.
S3는 멀티파트 업로드를 지원하므로 큰 파일을 분할해 병렬로 업로드할 수 있다.
S3에는 인터넷 엑세스가 가능한 API가 있다.
S3의 용량은 무제한이다.
S3는 리전으로 범위가 지정되며 99.999999999%의 내구성을 제공한다.
장기간 보관하려는 데이터가 있다고 가정해보자.
예를 들어 재무제표 같은 데이터를 콜드 스토리지에 보관하면 영구적으로 저장되지만 이 데이터에 자주 엑세스할 계획은 없다.
이때 필요한 것이 Glacier이다.
Glacier는 데이터 백업 및 아카이브 스토리지 솔루션이다.
Glacier는 파일 및 저장소에 해당하는 아카이브를 제공하는 아카이브의 모음이다.
Glacier에는 신속, 표준, 벌크의 세 가지 검색 유형이 있다. 각각 장단점이 있다.
Glacier는 기본적으로 데이터를 암호화한다.
Glacier를 사용하는 좋은 방법은 버킷에 S3 수명 주기 정책을 설정하는 것이다.
이 수명 주기 정책은 일정 기간 후 자동으로 S3 데이터를 Glacier로 이동할 수 있다. 오래된 데이터를 보관하기에 좋은 방법이다.
Glacier에는 리전별 가용성이 적용된다.
S3처럼 99.999999999%의 내구성을 제공한다.
느슨한 결합의 기본 개념은 서버가 일시적으로 다운되더라도 처리에 영향을 미치지 않는다는 것이다. 손실되는 데이터도 없다. 시스템의 다른 부분은 계속 정상 작동한다.
웹 서버 -> 이메일 서비스 -> 이메일 서버
첫 번째 그림에는 밀접하게 결합된 시스템이 나와 있다.
웹서버가 요청을 받은 다음 이메일서비스를 통해 이메일을 보낸다. 이메일서비스가 작동 중지되면 웹서버 작동도 중지된다.
이메일서비스 작동 중지는 아주 정상적인 이벤트일 수 있다. 새 이메일 서비스 버전을 배포하기 위해 이메일 서비스를 중지할 수도 있고 하드웨어 업그레이드를 위해 작동을 중지할 수도 있다. 이메일 서비스의 결함이 원인일 수도 있다.
어떤 경우든 밀결합된 시스템에서는 장애의 폭발 반경이 넓다.
웹 서버 -> SQS 대기열 <- 이메일 서비스 -> 이메일 서버
이제 두 번째 그림을 살펴보자.
이메일 서비스를 위한 메시지가 보관된 SQS 대기열이 있다. 웹 서버는 이메일 서비스가 작업을 수행하기를 기다릴 필요가 없다. 작업을 대기열에 넣고 다음 작업을 하면 된다.
이런 종류의 비동기 상호 작용을 통해 웹 서버 측에서 리소스를 훨씬 효율적으로 사용할 수 있다.
게다가 이메일 서비스 작동이 중지되더라도 웹 서버는 영향을 받지 않고 계속 작동할 수 있다. 뿐만 아니라 메시지도 손실되지 않는다.
메시지는 SQS 대기열에 안전하게 유지되고 이메일 서비스가 다시 작동할 때까지 대기한다. 서비스가 다시 온라인 상태가 되면 메시지 처리를 시작할 수 있다.
또 다른 서비스의 느슨한 결합의 예제와 느슨한 결합의 이점을 살펴보자.
웹 서버 -> 로깅 서비스 -> Amazon DynamoDB
여기 로깅 서비스를 호출하는 웹 서버가 있다.
웹 서버가 로깅 서비스에 보내는 요청의 양이 많으면 로깅 서비스가 감당하지 못하고 과부하될 수 있다.
웹 서버 -> SQS <- 로깅 서비스 1,2,3 -> Amazon DynamoDB
이 문제는 SQS 대기열을 사용하여 웹 서버와 로깅 서비스를 분리하면 해결할 수 있다.
대기열의 요청 양이 증가하면 로깅 서비스가 확장할 수 있고 양이 줄어들면 로깅 서비스가 다시 축소할 수 있다.
여분의 서버를 사용하지 않을 때 비용을 줄이려면 축소가 중요하다.
이것은 마트와도 비슷하다. 기다리는 줄이 길어지면 계산대를 더 열고 줄이 다시 짧아지면 다시 하나만 열면 된다.
결합 해제도 비슷한 방법으로 백엔드 서비스를 확장 및 축소할 수 있다.
대기열을 사용하는 대신 느슨한 결합에 로드 밸런서를 사용할 수도 있다. 로드 밸런서는 들어오는 요청을 로깅 서비스를 실행하는 여러 서버에 분산한다.
로드 밸런서는 백엔드 서비스가 중요한 응답을 반환하는 경우에 유용하다.
색상, 이 경우 웹 서버에 필요한 응답이 없는 경우 대기열을 대신 사용할 수 있다.
느슨한 결합의 또 다른 예를 살펴보자.
외부 클라이언트 <-클라우드-> VPC 퍼블릭 IP가 있는 웹 서비스
VPC 내부에서 실행되는 서버에 외부 클라이언트가 요청을 한다고 가정해보자.
외부 클라이언트의 요청과 응답은 퍼블릭 인터넷을 거친다.
이제 웹 서버가 오프라인이 되면 어떻게 될까?
제일 먼저 클라이언트에 오류가 발생할 것이다. 다행히도 자동화를 설정해 두었기 때문에 웹 서버가 오프라인 상태가 되면 새로운 서버로 대체한다.
같은 이미지를 기반으로 하지만 이 새 서버에는 VPC에 의해 할당된 새 IP 주소가 있다. 즉, 클라이언트는 DNS를 통해 IP 주소가 클라이언트로 전파될 때까지 통신을 할 수 없다.
이 문제를 어떻게 해결해야할까?
이 문제를 해결하는 한 가지 방법은 탄력적 IP 주소를 사용하는 것이다.
이 시나리오에서는 이렇게 설정된 서버가 작동 중지되더라도 문제 없다.
백엔드 서비스를 제공하는 새 서버로 탄력적 IP 주소를 이동할 수 있기 때문이다.
탄력적 IP 주소는 이동이 가능한 IP 주소 또는 한 서버에서 다른 서버로 이동할 수 있는 고정 IP 주소로 생각하면 된다.
결과적으로 이제 서버의 ID에서 IP 주소를 분리했다.
클라이언트가 탄력적 IP 주소와 통신하고 있고 백엔드 서비스를 어느 서버에서 제공하는지는 알지도 못하고 신경 쓰지도 않는다.
다음 중 느슨하게 결합된 아키텍처의 구현을 촉진하는 AWS 서비스는 무엇입니까? (2개 선택) A. AWS CloudFormation B. Amazon Simple Queue Service C. AWS CloudTrail D. Elastic Load Balancing E. Amazon Elastic MapReduce
키워드는 느슨하게 결합된 아키텍처이다.
AWS CloudFormation은 제외해도 된다. 구성 요소의 스택을 유지하기 때문이다.
SQS는 유력한 정답 후보이다.
AWS CloudTrail도 제외할 수 있다. 로깅 서비스이기 때문이다.
Amazon Elastic MapReduce도 제외할 수 있다. 관리형 Hadoop이기 때문이다.
정답은 B와 D이다.
탄력성과 내결함성에 대해 생각할 때 기억해야 할 주요 사항은 Amazon.com의 CTO인 Werner Vogels의 말을 인용하자면 다음과 같다. “오류는 언제든 발생하기 마련이다.” 대규모 운영 시 오류는 예외적 이벤트가 아니다. 오류는 언제든지 발생할 수 있는 운영상 이벤트로 여겨지고 처리되어야 한다. 여러분은 인스턴스 또는 인스턴스 코드의 오류에 영향을 받지 않도록 서비스를 설계하고자 한다. 서비스는 중단 없이 계속 작동해야 한다. AWS 서비스를 사용하면 여러분은 서비스가 오류를 예외적이지 않은 이벤트로 처리하도록 할 수 있다.
내결함성 시스템이 느슨하게 결합될수록 보다 쉽게 조정할 수 있고 내결함성이 강화된다.
웹서버 -> 앱서버 (밀결합됨) 웹서버 -> 로드밸런서 -> 앱서버 (소결합됨)
위 그림에서 알 수 있듯이 소결합된 시스템은 확장성과 내결함성이 뛰어난다. 각 계층은 독립적으로 확장 및 축소할 수 있다. 단일 서버 장애는 계층이나 애플리케이션 전체에 영향을 미치지 않는다. 여기서는 AWS Elastic Load Balancer를 사용하여 웹 서버를 앱 서버에서 분리한다.
웹 서비스에 1초 내에 요청의 99%에 응답해야 하는 성능 SLA가 있다고 합시다. 정상 작업과 부하가 심한 작업에서는 4개의 인스턴스에 요청을 분산시키면 성능 요구 사항이 충족됩니다.
가용 영역에 도달할 수 없는 경우, 비용 효율적인 방식으로 서비스의 고가용성을 보장하는 아키텍처는 무엇입니까?
A. 단일 가용 영역에 있는 4개의 서버에 서비스 배포
B. 단일 가용 영역에 있는 6개의 서버에 서비스 배포
C. 2개의 가용 영역에 있는 4개의 서버에 서비스 배포
D. 2개의 가용 영역에 있는 8개의 서버에 서비스 배포
A는 제외할 수 있다. 단일 AZ 배포는 가용성이 높지 않다.
같은 이유로 B도 제외할 수 있다. 단일 AZ 배포는 가용성이 높지 않다.
D는 컴퓨팅이 지나치게 많기 때문에 제외할 수 있다. 대부분의 경우 이 컴퓨팅이 다 필요하지는 않는다. 비용 효과도 생각해야 하기 때문이다.
그러면 정답인 C가 남는다.
웹 서비스에 1초 내에 요청의 99%에 응답해야 하는 성능 SLA가 있다고 합시다. 정상 작업과 부하가 심한 작업에서는 4개의 인스턴스에 요청을 분산시키면 성능 요구 사항이 충족됩니다.
가용 영역에 도달할 수 없는 경우, 비용 효율적인 방식으로 서비스의 내결함성을 보장하는 아키텍처는 무엇입니까?
A. 단일 가용 영역에 있는 4개의 서버에 서비스 배포
B. 단일 가용 영역에 있는 6개의 서버에 서비스 배포
C. 2개의 가용 영역에 있는 4개의 서버에 서비스 배포
D. 2개의 가용 영역에 있는 8개의 서버에 서비스 배포
고가용성 대신 내결함성이 필요하다. 차이점은 무엇인가?
내결함성이 달성하기 더 어렵다.
고가용성은 시스템이 작동하고 사용 가능함을 뜻한다. 하지만 성능이 저하된 상태일 수 있다.
내결함성은 사용자가 결함의 영향을 전혀 경험하지 못하고 SLA가 충족되는 것을 뜻한다.
중요한 것은 인스턴스를 항상 사용할 수 있고 SLA를 충족해야 한다는 것이다.
이전과 같은 이유로 A와 B를 배제할 수 있다. 단일 AZ는 내결함성이 없기 때문이다.
C로는 충분하지 않다. 가용 영역에 장애가 발생할 경우 필요한 인스턴스 수인 4개 미만이 되기 때문이다.
그렇다면 하나의 AZ에 장애가 발생하더라도 4개의 인스턴스가 보장되는 D가 정답이 된다.
많은 S3 버킷, EC2 인스턴스, RDS 데이터베이스, DynamoDB 테이블, 네트워크 기타 요소가 포함된 대규모 배포를 구성하려 한다고 가정해 보자.
빠르게 만드는 방법과 배포의 복사본을 여러 개 만드는 방법은 무엇일까?
이 경우 CloudFormation이 필요하다.
CloudFormation은 인프라를 JSON 템플릿으로 설명한 다음 이를 스택이라고 하는 인프라로 변환할 수 있는 서비스이다.
이렇게 하면 인프라의 여러 복사본을 아주 쉽게 만들 수 있다.
CloudFormation 템플릿은 하드웨어를 정의하지만 코드로 취급할 수 있다.
이 때문에 하드웨어와 소프트웨어의 구별이 모호해진다.
또한 복원력을 촉진한다. 원하면 언제든 아무것도 없는 상태에서 애플리케이션을 다시 시작할 수 있다.
CloudFormation은 시스템의 DNA와도 같다.
동일한 기본 Amazon Machine Image(AMI)를 사용하여 서로 다른 두 리전에 Linux EC2 인스턴스를 배포하기 위해 CloudFormation을 사용할 계획입니다.
이렇게 하려면 CloudFormation을 어떻게 사용해야 합니까?
A. CloudFormation 템플릿은 리전별로 고유하기 때문에 두 가지 CloudFormation 템플릿을 사용합니다.
B. AMI ID는 리전마다 다르기 때문에 매핑을 사용하여 기본 AMI를 지정합니다.
C. AMI ID는 리전마다 다르기 때문에 파라미터를 사용하여 기반 AMI를 지정합니다.
D. AMI ID는 모든 리전에서 동일합니다.
템플릿은 리전마다 달라지지 않으므로 A는 제외할 수 있다.
파라미터는 사용자의 입력이므로 C도 제외할 수 있다. AMI ID는 사용자가 입력하기 어렵다.
AMI ID에 파라미터를 사용할 수는 있지만 권장되지 않으며 템플릿이 취약해진다.
AMI ID는 리전마다 다르기 때문에 D를 제외할 수 있다.
정답은 B이다.
애플리케이션은 데이터와 컴퓨팅으로 구성된다.
데이터는 S3, DynamoDB 데이터베이스에 저장할 수 있다.
하지만 컴퓨팅은 EC2 인스턴스 유지 관리가 필요하다. 즉, 패치와 보안이 필요하다. 이 작업에는 시간이 걸린다.
코드를 제공하면 AWS가 서버에 코드를 배포하고 서버에서 관리한다고 상상해 보자.
이것이 Lambda의 기본 개념이다.
상태 비저장 코드를 제공하면 AWS는 호출할 때마다 온디맨드로 코드를 실행하는 컨테이너를 스핀업한다.
호출당 비용을 지불해야 한다.
애플리케이션을 확장 가능하고 복원력이 있도록 만드는 좋은 방법은 Lambda를 기반으로 하는 것이다.
Lambda를 사용하면 복원력과 확장성을 AWS에 위임할 수 있다.
Lambda에서 인쇄 명령문의 출력에 어떻게 엑세스할 수 있습니까?
A. Lambda에 SSH로 연결하고 시스템 로그를 확인합니다.
B. Lambda는 Amazon S3에 모든 출력을 기록합니다.
C. CloudWatch Logs를 사용합니다.
D. Lambda에서 인쇄 명령문이 무시됩니다.
Lambda는 SSH 엑세스를 허용하지 않기 때문에 A는 제외할 수 있다.
Lambda는 S3에 모든 출력을 기록하지 않기 때문에 B도 제외할 수 있다.
Lambda에서는 print 명령문이 무시되지 않기 때문에 D도 제외할 수 있다.
print 명령문은 CloudWatch Logs에 기록된다.
모든 print 명령문과 로깅 출력은 CloudWatch Logs에 표시된다.
CloudWatch Logs는 Lambda 디버깅에 매우 유용하다.
상태 저장을 위해 EBS를 사용하는 EC2 인스턴스를 실행하고 있습니다. 매일 EBS 스냅샷을 생성합니다. 시스템 작동이 중단될 경우, 스냅샷에서 시스템을 다시 시작하는 데 10분이 걸립니다. RTO와 RPO는 어떻게 됩니까?
A. RTO는 1일, RPO는 10분
B. RTO는 10분, RPO는 1일
C. RTO와 RPO는 10분
D. RTO와 RPO는 1일
이 질문에 답하기 위해서는 RTO와 RPO가 무엇인지 알아야 한다.
RTO는 복구 시간 목표이고 RPO는 복구 시점 목표이다.
RTO, 즉 복구 시간 목표는 시스템이 복구되어 다시 온라인 상태가 되는 데 걸리는 시간을 뜻한다.
RTO는 시스템이 다시 작동하는 데 걸리는 시간에 따라 초, 분, 시간으로 측정된다.
RPO, 즉 복구 시점 목표는 시스템 장애 시 손실되는 데이터 양을 말한다.
RPO는 메가바이트 또는 기가바이트 단위로 측정할 수 있다.
초, 분, 시간 같은 시간 단위로도 측정되는데 이 기간 동안의 데이터가 손실된다는 뜻이다.
따라서 RPO 1시간은 한 시간 분량의 데이터 손실을 뜻한다.
여기서는 매일 스냅샷을 생성하기 때문에 하루 분량의 데이터가 손실되며 따라서 RPO는 하루이다.
시스템이 다시 온라인 상태가 되는 데 10분이 걸리므로 RTO는 10분이다.
정답은 B이다.
여기서 핵심은 RTO와 RPO의 의미이다.
이것은 시험에 나올 만한 내용이다.
각 모듈 끝에 나오는 시험에 대한 조언은 방금 다룬 영역과 관련하여 기억해야 할 중요한 사항이다.
이 영역에서는 복원력을 갖춘 시스템 구축을 다뤘다.
조언은 다음과 같다.
시험에 대한 조언
내결함성의 요구 사항이 더 높다.
고가용성은 시스템이 항상 작동되며 장애 발생 시 장애 조치될 수 있도록 한다.
내결함성은 시스템이 사용자로부터 장애를 숨기며 서비스 손실이 없도록 한다.
모든 것은 언젠가 장애가 발생하므로 이를 감안하여 디자인해야 한다.