[문제 23]
회사는 단일 가용 영역의 Amazon EC2 인스턴스에서 3개의 애플리케이션을 호스팅합니다. 웹 애플리케이션은 EC2 인스턴스에서 호스팅되는 자체 관리형 MySQL 데이터베이스를 사용하여 Amazon Elastic Block Store(Amazon EBS) 볼륨에 데이터를 저장합니다. MySQL 데이터베이스는 현재 1TB 프로비저닝된 IOPS SSD(io2) EBS 볼륨을 사용하고 있습니다. 회사는 최대 트래픽 시 읽기 및 쓰기 모두에 대해 1,000 IOPS의 트래픽을 예상합니다. 회사는 두 배의 IOPS 용량을 유지하면서 중단을 최소화하고 성능을 안정화하며 비용을 절감하기를 원합니다. 또한, 데이터베이스 계층을 가용성이 높고 내결함성이 뛰어난 완전 관리형 솔루션으로 확장하고자 합니다.
A. io2 Block Express EBS 볼륨이 있는 MySQL DB 인스턴스용 Amazon RDS의 다중 AZ 배포를 사용합니다.
B. 범용 SSD(gp2) EBS 볼륨이 있는 MySQL DB 인스턴스용 Amazon RDS의 다중 AZ 배포를 사용합니다.
C. Amazon S3 Intelligent-Tiering 액세스 계층을 사용합니다.
D. 두 개의 대형 EC2 인스턴스를 사용하여 활성-수동 모드로 데이터베이스를 호스팅합니다.
[문제 분석]
이 문제는 MySQL 데이터베이스를 확장하여 고가용성, 성능 안정성을 유지하면서도 비용을 절감하는 방법을 묻고 있습니다. 현재 회사는 자체 관리형 MySQL을 운영 중이지만, 관리형 서비스를 사용하여 운영 부담을 줄이고자 합니다. 또한, 두 배의 IOPS 용량을 유지하는 것이 목표이므로 스토리지 옵션의 성능과 비용을 모두 고려해야 합니다.
[각 보기 분석]
A. io2 Block Express EBS 볼륨이 있는 MySQL DB 인스턴스용 Amazon RDS의 다중 AZ 배포를 사용합니다.
- 설명: io2 Block Express는 고성능 SSD 옵션으로, 매우 높은 IOPS와 내구성을 제공하지만 비용이 매우 높습니다. 다중 AZ 배포는 고가용성을 보장하며, 데이터베이스 장애 시 자동 장애 조치를 제공합니다.
- 부적합: io2 Block Express는 성능이 매우 뛰어나지만, 현재 트래픽 수준(2,000 IOPS)을 처리하기 위해서는 비용 대비 성능이 과도할 수 있습니다.
B. 범용 SSD(gp2) EBS 볼륨이 있는 MySQL DB 인스턴스용 Amazon RDS의 다중 AZ 배포를 사용합니다.
- 설명: gp2는 성능과 비용의 균형을 제공하는 범용 SSD 스토리지입니다. IOPS는 저장 용량에 비례하며, 대규모 트래픽 처리에도 적합합니다. 다중 AZ 배포는 가용성을 높이고 데이터 손실을 방지합니다.
- 적합성: 이 솔루션은 1,000 IOPS 이상의 성능을 제공하면서도 비용 효율적입니다. 또한 다중 AZ를 통해 고가용성을 유지할 수 있습니다.
C. Amazon S3 Intelligent-Tiering 액세스 계층을 사용합니다.
- 설명: Amazon S3 Intelligent-Tiering은 S3 스토리지 클래스로, 액세스 패턴에 따라 데이터를 자동으로 이동시킵니다. 그러나 이는 주로 비정형 데이터에 사용되며, 데이터베이스와는 관련이 없습니다.
- 부적합: 이 옵션은 데이터베이스 운영에 적합하지 않습니다.
D. 두 개의 대형 EC2 인스턴스를 사용하여 활성(Active)-수동(Passive) 모드로 데이터베이스를 호스팅합니다.
- 설명: 이 옵션은 두 개의 EC2 인스턴스를 사용해 활성-수동 설정을 구성하는 방식입니다. 이는 내결함성을 제공할 수 있지만, 수동 관리가 필요하며 비용이 많이 들 수 있습니다.
- 부적합: 이 방식은 자동 장애 조치나 관리형 서비스가 없으므로 운영 부담이 증가할 수 있습니다.
[정답 분석]
가장 적합한 답은 B. 범용 SSD(gp2) EBS 볼륨이 있는 MySQL DB 인스턴스용 Amazon RDS의 다중 AZ 배포입니다. gp2 볼륨은 비용을 절감하면서도 1,000 IOPS 이상의 성능을 제공하며, 다중 AZ 배포를 통해 고가용성을 유지할 수 있습니다.
[서비스 및 관련 옵션]
1. Amazon RDS: 완전 관리형 관계형 데이터베이스 서비스로, 백업, 패치, 모니터링, 고가용성 설정을 자동으로 처리합니다.
2. EBS gp2 볼륨: 저렴하면서도 균형 잡힌 성능을 제공하며, 데이터베이스 워크로드에 적합한 범용 SSD 옵션입니다.
3. 다중 AZ 배포: 데이터베이스의 내결함성과 고가용성을 보장하며, 장애 발생 시 자동 장애 조치를 제공합니다.
[도메인]
이 문제는 도메인 3: 비용 효율적인 아키텍처 설계에 해당합니다. 이 도메인은 비용 절감과 성능 유지를 목표로 하는 아키텍처 설계와 관련이 있습니다.
1. 태스크 설명: 태스크 3.4: 비용을 최적화하고 성능을 유지하는 데이터베이스 솔루션을 설계합니다.
2. 관련 지식:
1) Amazon RDS를 사용한 관리형 데이터베이스 운영.
2) EBS gp2의 성능 및 비용 관리.
[시험에서 주로 출제되는 핵심 개념]
Amazon RDS 스토리지 옵션
Amazon RDS는 다양한 스토리지 옵션을 제공합니다. 이를 통해 사용자는 성능과 비용 사이의 균형을 맞출 수 있습니다.
1. 범용 SSD (gp2/gp3)
- 비용 효율적이며, 범용 워크로드에 적합합니다. gp2는 3 IOPS/GB의 성능을 제공하며, 최대 16,000 IOPS까지 처리할 수 있습니다.
\ - gp3는 성능을 독립적으로 설정할 수 있으며, 더 낮은 비용으로 성능 최적화가 가능합니다.
2. 프로비저닝된 IOPS SSD (io1/io2)
- 고성능과 일관된 IOPS를 요구하는 애플리케이션에 적합하며, 높은 IOPS를 제공하지만 비용이 더 높습니다.
시험에서 자주 출제되는 주제
1. RDS 스토리지 유형 비교
- Provisioned IOPS와 범용 SSD의 성능 차이와 각 사용 사례에 대한 이해가 필요합니다. 비용 효율적인 솔루션을 선택하는 시나리오가 자주 출제됩니다.
2. 다중 AZ 배포
- 다중 AZ 배포는 고가용성 및 내결함성을 제공하며, 자동 장애 조치의 중요성이 자주 다뤄집니다.
3. 비용 최적화
- gp2와 같은 비용 효율적 스토리지를 선택해 성능을 유지하면서도 비용을 절감하는 방식이 출제됩니다.
예시 문제
1. Amazon RDS에서 MySQL 데이터베이스를 운영할 때, 비용 효율적이면서도 IOPS를 두 배로 늘리려면 어떤 스토리지 옵션이 적합합니까?
- 정답: 범용 SSD (gp2)
2. Amazon RDS의 다중 AZ 배포를 통해 얻을 수 있는 이점은 무엇입니까?
- 정답: 고가용성과 자동 장애 조치.
[EBS 볼륨 유형표]
아래는 io2 Block Express EBS 볼륨과 다른 주요 EBS 볼륨 유형들 간의 비교를 표로 정리한 것입니다.
EBS 볼륨 유형 | 주요 특징 | 성능 (IOPS) | 사용 사례 | 비용 |
---|---|---|---|---|
io2 Block Express | - 최신 고성능 SSD - 더 높은 IOPS, 처리량, 내구성 제공 - 대규모 워크로드에 적합 - NVMe 인터페이스 사용 |
최대 256,000 IOPS 최대 4,000 MB/s 처리량 |
- 대규모 데이터베이스 - 고성능 트랜잭션 시스템 |
가장 비쌈 |
io2 | - 높은 IOPS와 내구성 제공 - 일관된 성능 - 고성능 애플리케이션에 적합 |
최대 64,000 IOPS 최대 1,000 MB/s 처리량 |
- OLTP 시스템 - 비즈니스 핵심 데이터베이스 |
고가 |
io1 | - 고성능을 요구하는 IOPS 집약적 워크로드에 적합 - io2보다 내구성 낮음 |
최대 64,000 IOPS 최대 1,000 MB/s 처리량 |
- 고성능 데이터베이스 - 미션 크리티컬 애플리케이션 |
고가 |
gp3 | - 비용 효율적이며 성능 사용자 맞춤 가능 - IOPS 및 처리량을 독립적으로 설정 가능 |
기본 3,000 IOPS 최대 16,000 IOPS 최대 1,000 MB/s 처리량 |
- 웹 서버 - 애플리케이션 서버 - 일반적인 비즈니스 워크로드 |
중간 |
gp2 | - 범용 SSD로 성능과 비용의 균형 제공 - 저장 용량에 따라 성능 비례 |
최대 16,000 IOPS 최대 250 MB/s 처리량 |
- 개발/테스트 환경 - 범용 애플리케이션 워크로드 |
저렴 |
st1 (Throughput Optimized HDD) | - 저비용 고용량 HDD - 대규모 순차적 읽기/쓰기 작업에 적합 |
최대 500 IOPS 최대 500 MB/s 처리량 |
- 빅데이터 분석 - 로그 처리 |
저렴 |
sc1 (Cold HDD) | - 가장 저렴한 HDD - 자주 액세스되지 않는 데이터에 적합 |
최대 250 IOPS 최대 250 MB/s 처리량 |
- 자주 사용되지 않는 대용량 데이터 저장 - 아카이빙 및 백업 |
가장 저렴 |
요약
- io2 Block Express는 최고 성능을 제공하며 대규모 워크로드에 적합하지만, 가장 비싼 옵션입니다.
- io1 및 io2는 고성능이 요구되는 워크로드에 적합하며 고성능 데이터베이스에 주로 사용됩니다.
- gp3는 비용 대비 성능이 좋은 선택으로, 일반적인 워크로드에 적합합니다.
- gp2는 중간 수준의 성능을 제공하며 일반적인 비즈니스 애플리케이션에 적합합니다.
- st1 및 sc1은 저렴한 HDD 옵션으로, 빅데이터나 백업용으로 사용됩니다.
참고로, io는(Input/Output)이며 gp(general purpose)이며 st(Throughput Optimized), sc(Cold)를 의미합니다.
Amazon S3 Intelligent-Tiering
Amazon S3 Intelligent-Tiering는 비용 효율적인 스토리지 클래스로, 액세스 패턴이 예측할 수 없는 데이터에 적합하며, 데이터를 자주 또는 드물게 액세스하는지에 따라 자동으로 비용을 최적화합니다. 이를 통해 자주 액세스하지 않는 데이터에 대해 저렴한 비용을 제공하며, 데이터의 액세스 패턴을 모니터링하고, 액세스 빈도가 낮아질 경우 데이터를 자동으로 저비용 스토리지 계층으로 이동시킵니다.
주요 특징:
1. 자동 계층화:
- 빈번 액세스 계층과 비빈번 액세스 계층 간의 자동 전환을 통해 데이터 액세스 패턴에 맞춰 스토리지 비용을 최적화합니다.
- 별도의 액세스 패턴 분석이나 수동 작업 없이 데이터가 적합한 계층으로 자동 이동됩니다.
2. 모니터링 및 전환 비용:
- 데이터를 자주 액세스하면 고비용의 빈번 액세스 계층에서 저장되고, 30일 동안 액세스하지 않으면 비빈번 액세스 계층으로 이동합니다.
- 전환 비용 없이 계층 간 전환이 이루어지며, 자동으로 모니터링됩니다.
3. 다양한 용도:
- 액세스 패턴이 예측 불가하거나, 자주 액세스되는 시기가 불규칙한 데이터를 저장하는 데 이상적입니다.
- 데이터가 자주 액세스될지 확신이 없는 장기 보관 데이터 또는 분석 데이터를 저장하는 데도 유용합니다.
4. 다양한 객체 크기 지원:
- 128KB 이상의 객체에 대해 적용되며, 소규모 객체는 최적화되지 않습니다.
사용 사례:
- 로그 파일, 데이터 분석에 사용되는 데이터, 백업 데이터 등 액세스 패턴이 일정하지 않은 데이터를 효율적으로 저장하는 데 적합합니다.
요약:
Amazon S3 Intelligent-Tiering는 자동 계층화를 통해 스토리지 비용을 절감할 수 있는 스토리지 클래스입니다. 데이터 액세스 빈도에 따라 스토리지 계층을 자동으로 조정하여 비용 최적화가 가능하며, 사용자가 직접 데이터를 관리할 필요가 없어 운영 효율성이 높습니다.
[EC2 Active & Passive Mode]
활성-수동 모드(Active-Passive Mode)로 EC2 인스턴스를 사용하여 데이터베이스를 호스팅하는 방식은 고가용성과 내결함성을 제공하는 아키텍처 패턴 중 하나입니다. 이 방식에서는 두 개의 인스턴스 중 하나가 활성 상태로 데이터베이스 서비스를 제공하며, 다른 하나는 대기(수동) 상태로 운영됩니다. 장애가 발생할 경우, 수동 인스턴스가 활성화되어 서비스 다운타임을 최소화할 수 있습니다.
활성-수동 모드 구성 요소 및 흐름
1. 주 인스턴스 (Active Instance):
- 활성 인스턴스는 애플리케이션 요청을 처리하며, 모든 데이터베이스 작업이 이 인스턴스에서 수행됩니다.
- 일반적으로 읽기 및 쓰기 작업을 처리하고, 데이터가 저장되는 스토리지에 액세스합니다.
- 가용성 장애가 발생하지 않으면, 모든 트래픽은 주 인스턴스에서 처리됩니다.
2. 보조 인스턴스 (Passive Instance):
- 수동 인스턴스는 대기 상태로, 활성 인스턴스의 장애를 대비해 준비되어 있습니다.
- 주 인스턴스의 상태를 지속적으로 모니터링하며, 장애가 발생하면 장애 조치(failover)로 활성화됩니다.
- 수동 인스턴스는 데이터베이스 파일의 동기화 및 백업 상태를 유지합니다.
3. 장애 조치 (Failover):
- 활성 인스턴스에서 문제가 발생하면, 자동 또는 수동 장애 조치가 이루어져 대기 중인 인스턴스가 활성화됩니다.
- 이 과정에서 IP 주소 또는 데이터베이스 엔드포인트가 수동 인스턴스로 재지정되며, 트래픽이 자동으로 전환됩니다.
4. 데이터 동기화:
- 두 인스턴스 간에 데이터를 동기화하는 것이 매우 중요합니다. 일반적으로 이를 위해 데이터 복제(Replication) 또는 공유 스토리지가 사용됩니다.
- Amazon EBS 볼륨을 사용하여 데이터를 주 인스턴스와 수동 인스턴스가 공유 스토리지 방식으로 접근할 수 있습니다.
다양한 활성-수동 아키텍처
1. EC2 인스턴스 기반:
- Amazon EC2 인스턴스를 사용하여, 수동 인스턴스가 장애 발생 시 자동 장애 조치(failover)를 통해 활성화됩니다.
- 이때, 데이터 복제를 위해 Amazon EBS 스냅샷을 활용하거나 데이터베이스 자체 복제 기능(예: MySQL 복제)을 사용할 수 있습니다.
2. RDS Multi-AZ 활성-수동:
- Amazon RDS의 Multi-AZ 배포는 활성-수동 아키텍처의 관리형 솔루션입니다. 하나의 가용 영역(AZ)에서 주 인스턴스가 작동하고, 다른 AZ에서 보조 인스턴스가 대기 상태로 준비되어 있습니다.
- 자동 장애 조치가 제공되며, 데이터베이스 서비스에 장애가 발생하면 보조 인스턴스가 즉시 활성화됩니다. 이 방식은 수동 관리 부담을 줄이고, RDS가 자동으로 모든 복제 및 장애 조치를 처리합니다.
활성-수동 모드의 이점
1. 고가용성:
- 장애가 발생하더라도, 서비스는 대기 중인 인스턴스로 자동으로 전환되기 때문에 다운타임을 최소화할 수 있습니다.
2. 내결함성:
- 활성-수동 구조는 장애 복구 능력이 높으며, 중요한 데이터베이스 애플리케이션을 보호하는 데 적합합니다.
3. 비용 절감:
- 활성-활성 모드에 비해 수동 인스턴스는 대기 상태이므로 비용이 절감될 수 있습니다. 사용자는 하나의 활성 인스턴스만 트래픽을 처리하고, 수동 인스턴스는 대기 상태로 유지되기 때문입니다.
활성-수동 모드의 단점
1. 전환 지연:
- 장애 조치가 발생하는 동안 잠시 전환 지연이 발생할 수 있습니다. 수동 인스턴스가 활성화되기까지 몇 분이 걸릴 수 있습니다.
2. 데이터 동기화 이슈:
- 수동 인스턴스와의 데이터 동기화 지연이 발생할 수 있으며, 최신 데이터가 제대로 복제되지 않으면 장애 발생 시 데이터 손실 가능성이 있습니다.
3. 관리 복잡성:
- 사용자가 직접 EC2 인스턴스 기반의 활성-수동 아키텍처를 구성할 경우, 수동 관리가 필요하므로 운영 복잡성이 높을 수 있습니다. 특히, 수동으로 장애 조치를 설정하거나 모니터링해야 하는 경우 더 많은 관리가 필요합니다.
활성-수동 모드의 AWS 서비스 활용
- EC2 Auto Scaling: 자동으로 활성/수동 인스턴스를 확장하거나 장애 조치를 처리할 수 있습니다.
- Elastic Load Balancing (ELB): 데이터베이스 트래픽을 분산하고, 활성 인스턴스가 비정상 상태일 때 트래픽을 자동으로 수동 인스턴스로 라우팅할 수 있습니다.
- Amazon Route 53: 장애 조치 시 DNS를 통해 데이터베이스 엔드포인트를 빠르게 전환하여 사용자가 계속해서 서비스에 액세스할 수 있도록 할 수 있습니다.
요약:
EC2 인스턴스를 사용한 활성-수동 데이터베이스 호스팅은 고가용성과 내결함성을 제공하면서도 비용을 절감할 수 있는 방식입니다. 관리형 RDS 서비스를 사용하면 자동화된 장애 조치와 복제가 제공되지만, 직접 EC2 인스턴스를 구성할 경우 사용자 관리가 더 많이 필요하며, 데이터 동기화와 장애 조치가 핵심 요소입니다.
'스케쥴 > 시험' 카테고리의 다른 글
AWS-SAA-V18.35 - 1번 (0) | 2024.10.21 |
---|---|
AWS SAA-C03 한국어 샘플 24번 (0) | 2024.10.21 |
AWS SAA-C03 한국어 샘플 22번 (0) | 2024.10.20 |
AWS SAA-C03 한국어 샘플 21번 (0) | 2024.10.20 |
AWS SAA-C03 한국어 샘플 20번 (0) | 2024.10.20 |