Amazon SOA-C02: 데이터베이스 및 캐싱 — 학습 가이드

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

다음의 일부입니다: AWS SysOps Administrator Associate SOA-C02 — 학습 가이드. 검증된 답안으로 연습하기: Amazon 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

데이터베이스와 캐싱은 SysOps 관리자의 핵심 운영 책임입니다. 애플리케이션에 영구 스토리지, 가용성, 짧은 지연 시간의 읽기를 제공하기 때문입니다. 이 영역에서는 관리형 관계형 데이터베이스(RDS 및 Aurora) 실행, 읽기/쓰기 용량 확장, 복제 및 장애 조치(failover) 동작, ElastiCache를 사용한 DB 부하 감소 등을 다룹니다. 백업, 파라미터 그룹, 모니터링, 캐시 무효화 패턴을 올바르게 구성하면 데이터 손실을 방지하고 운영 사고를 줄일 수 있습니다.

RDS 및 Aurora 운영, 백업, 다중 AZ

RDS(MySQL, PostgreSQL, MariaDB, Oracle, SQL Server)와 Amazon Aurora(MySQL 및 PostgreSQL 호환)는 운영 방식이 다른 관리형 관계형 엔진입니다. RDS의 다중 AZ는 다른 AZ에 동기식 대기(standby) 인스턴스를 생성합니다. 이는 AWS가 관리하며, 몇 분 내에 자동 장애 조치가 이루어지고, 수동 승격이 필요 없으며, 대기 인스턴스는 읽기용으로 액세스할 수 없습니다. Aurora는 쓰기(writer) 엔드포인트와 읽기(reader) 엔드포인트를 분리합니다. 쓰기 엔드포인트는 기본(primary) 인스턴스가 지원하는 클러스터 엔드포인트이며, Aurora는 AZ 간에 자동으로 복제되는 분산 스토리지를 사용하므로 스토리지가 공유되어 일반적으로 RDS보다 더 빠르게 장애 조치할 수 있습니다.

다음을 사용하여 백업 및 보존을 구성합니다:

자동 백업: 보존 기간을 설정하여 활성화합니다(예: modify-db-instance –backup-retention-period 7). 지원되는 엔진의 경우 보존 기간 내의 특정 시점(초 단위)으로 복구(PITR)할 수 있습니다.
수동 스냅샷: create-db-snapshot(Aurora의 경우 create-db-cluster-snapshot)을 사용하여 보존할 스냅샷을 생성합니다. 스냅샷은 직접 삭제하기 전까지 유지됩니다.
PITR 복원: RDS의 경우 aws rds restore-db-instance-to-point-in-time, Aurora의 경우 restore-db-cluster-from-snapshot을 실행한 후 인스턴스를 생성합니다.

결정 기준:

쓰기 가용성이 중요하고 대기 인스턴스에서의 읽기가 필요하지 않은 경우, 고가용성 및 자동 장애 조치를 위해 다중 AZ를 사용합니다.
높은 IOPS, 빠른 장애 조치, 스토리지 자동 확장이 필요한 경우 Aurora(클러스터형 스토리지)를 사용합니다.
읽기 확장 및 리전 간 재해 복구(DR)를 위해 읽기 전용 복제본(read replica)을 사용합니다(비동기식이며 승격 가능).

운영 CLI 예시:

다중 AZ 활성화: aws rds modify-db-instance –db-instance-identifier mydb –multi-az –apply-immediately
자동 스냅샷 생성: aws rds create-db-snapshot –db-snapshot-identifier snap1 –db-instance-identifier mydb
PITR 복원: aws rds restore-db-instance-to-point-in-time –source-db-instance-identifier mydb –target-db-instance-identifier mydb-restore –restore-time “YYYY-MM-DDTHH:MM:SSZ”

읽기 전용 복제본, 장애 조치, 복제 전략

읽기 전용 복제본은 주로 읽기 트래픽을 확장하고 리포팅 부하를 분산시키는 데 사용되는 비동기식 사본(RDS 또는 Aurora 리더)입니다. 복제 지연(ReplicaLag 지표 모니터링)이 발생하며, 강력한 일관성이 요구되는 작업에는 적합하지 않습니다. 읽기 전용 복제본은 독립형 DB 인스턴스로 승격하여 재해 복구를 지원할 수 있습니다.

복제 전략 및 선택:

동기식(RDS 다중 AZ 대기) — 데이터 차이 없음 보장, 대기 인스턴스에서 읽기 용량 없음.
비동기식 읽기 전용 복제본 — 읽기 확장, 리전 간 복사 활성화, 복제 지연 및 장애 조치 시 데이터 손실 가능성 있음.
Aurora 리더 — 클러스터형 읽기 엔드포인트 제공, 엔드포인트 재라우팅을 통한 짧은 지연 시간의 장애 조치, 자동 리더 엔드포인트 밸런싱.

운영 패턴:

읽기 전용 복제본 생성: aws rds create-db-instance-read-replica –db-instance-identifier read1 –source-db-instance-identifier primary
복제본 승격: aws rds promote-read-replica –db-instance-identifier read1
모니터링: CloudWatch의 DatabaseConnections, ReplicaLag, ReadIOPS, WriteIOPS 및 Performance Insights를 사용하여 복제본 추가 또는 제거 시점을 결정합니다.

결정 기준:

쓰기 작업에 대한 고가용성(HA)이 필요하면 다중 AZ를 선택합니다. 읽기 처리량과 분석 부하 분산이 필요하면 읽기 전용 복제본이나 Aurora 리더를 선택합니다.
리전 간 DR의 경우, 대상 리전에 읽기 전용 복제본을 생성하고 마이그레이션을 위해 자동 스냅샷 복사 또는 DMS를 고려합니다.

ElastiCache를 사용한 캐싱 및 캐시 무효화

ElastiCache는 DB 부하와 지연 시간을 줄이기 위해 Redis와 Memcached를 제공합니다. 지속성, 복제, 데이터 구조, 다중 AZ 및 자동 장애 조치를 통한 고가용성이 필요할 때는 Redis를 선택합니다. 샤딩과 멀티스레드 성능이 우선시되는 간단한 수평적 캐싱에는 Memcached를 선택합니다.

주요 구성 및 패턴:

복제본 및 다중 AZ를 갖춘 Redis 클러스터 생성: aws elasticache create-replication-group –replication-group-id rg1 –replication-group-description “rg” –engine redis –num-cache-clusters 3 –automatic-failover-enabled
샤드를 확장하려면 Redis에서 클러스터 모드를 활성화하여 사용합니다. Memcached는 샤딩을 위해 클라이언트 측 해싱이 필요합니다.
제거 정책: volatile-lru, allkeys-lru, noeviction — 메모리가 가득 찼을 때 만료된 키만 제거할지, 아니면 모든 키를 제거할지에 따라 조정합니다.
CacheHits와 CacheMisses를 모니터링하여 캐시 적중률을 계산합니다: hit_ratio = CacheHits / (CacheHits + CacheMisses). DB 읽기를 줄이기 위해 높은 적중률을 목표로 합니다.

캐시 무효화 전략:

Cache-aside(캐시 우선 조회): 애플리케이션이 캐시를 먼저 확인하고, 캐시에 데이터가 없으면(miss) DB를 읽어 캐시를 채웁니다. 쓰기 작업 시에는 캐시를 명시적으로 만료시키거나 삭제합니다.
Write-through/write-behind(캐시 후 DB 쓰기): 캐시 쓰기가 DB로 전파됩니다. Write-behind는 DB 쓰기를 일괄 처리합니다(복잡성 증가).
Time-to-live(TTL): 오래된 데이터가 될 수 있는 데이터에 대해 보수적인 TTL을 설정합니다. 스키마 변경이나 대량 무효화를 위해 캐시 버전 관리 또는 무효화 키와 결합하여 사용합니다.
필요한 경우 Redis pub/sub 또는 Lambda 이벤트를 사용하여 분산된 무효화를 위해 애플리케이션 인스턴스에 알립니다.

데이터베이스 파라미터 그룹, 스케일링 및 모니터링

파라미터 그룹은 엔진별 설정(예: max_connections, innodb_buffer_pool_size)을 제어합니다. RDS는 인스턴스용 DB 파라미터 그룹을, Aurora는 DB 클러스터 파라미터 그룹을 사용합니다. 일부 파라미터 변경은 재부팅이 필요하며(pending-reboot 적용), 다른 파라미터는 즉시 적용됩니다.

관리 패턴:

파라미터 그룹 생성 및 수정:

undefined

; 그 다음

undefined

인스턴스 클래스 스케일링:

undefined

(또는 재시작을 피하기 위해 유지 관리 기간 동안 적용).

스토리지 오토스케일링: 지원되는 엔진 유형에 대해 활성화합니다. Aurora는 스토리지를 자동으로 확장합니다.

모니터링 및 스케일링 신호:

CloudWatch(FreeableMemory, CPUUtilization, DatabaseConnections, WriteLatency, ReadLatency, DiskQueueDepth) 및 Performance Insights를 사용하여 느린 SQL 및 상위 대기 이벤트를 확인합니다.
Enhanced Monitoring을 활성화하고 세분화 수준(예: 문제 해결을 위해 1초)을 설정합니다.
RDS Proxy를 사용하여 커넥션 풀링을 관리하고, 서버리스 또는 동시성이 높은 애플리케이션의 커넥션 폭증(connection storm)을 줄입니다.

백업/복원 절차 및 마이그레이션 고려 사항

백업 및 복원은 명시적으로 수행하고 테스트해야 합니다. 자동 백업은 보존 기간 내에서 PITR(지정 시간 복구)을 제공합니다. 수동 스냅샷은 삭제될 때까지 보존되며, 다른 리전으로 복사하거나 다른 KMS 키로 암호화할 수 있습니다. 복원 시 리전과 타임스탬프를 명시적으로 지정해야 합니다.

일반적인 복원 명령어:

지정 시간으로 복원(RDS):

undefined

/ 또는

undefined

지정

스냅샷 복원(리전 간): 먼저 대상 리전으로

undefined

를 실행한 후 복원합니다.

마이그레이션 고려 사항:

최소 다운타임 마이그레이션(이기종/동기종)을 위해 AWS DMS를 사용합니다. DMS는 지속적인 복제를 지원합니다. 소스 엔진 설정이 올바른지 확인해야 합니다(MySQL의 경우 binlog 활성화).
간단한 내보내기에는 논리적 마이그레이션(mysqldump, pg_dump)을, 대용량 데이터셋에는 물리적 스냅샷 복원을 사용합니다.
암호화된 스냅샷의 경우 문자 집합, 파라미터 그룹 차이, KMS 키를 검증합니다.

일반적인 함정과 의사 결정 기준

잘못된 리전이나 시간으로 백업 복원: 복원 전 항상

undefined

및

undefined

를 확인하고, 대상 리전으로 복사된 스냅샷을 사용하여 스테이징 환경에서 복원을 테스트합니다.

읽기 전용 복제본이 고가용성을 제공한다고 가정: 복제본은 비동기식임을 기억해야 합니다. 쓰기 HA 및 동기식 복제를 위해서는 Multi-AZ 또는 Aurora를 사용합니다.
캐시 무효화 간과: TTL, 버전 관리 키 또는 이벤트 기반 무효화를 설계합니다. 정확성을 위해 짧은 TTL에만 의존하지 마십시오.
자동 백업 또는 보존 기간을 올바르게 활성화하지 않음:

undefined

을 0보다 크게 설정하고 테스트 복원으로 PITR을 검증합니다. 스냅샷 복사를 위해 대상 리전에서 KMS 키를 사용할 수 있는지 확인합니다.

재부팅 없이 파라미터 그룹 수정:

undefined

를 확인합니다. 예기치 않은 다운타임을 피하기 위해 재부팅이 필요한 파라미터는 유지 관리 기간에 재부팅을 예약합니다.

커넥션 관리 없이 스케일링: RDS Proxy나 커넥션 풀링 없이 인스턴스 클래스를 높이는 것은 커넥션 폭증을 해결하지 못할 수 있습니다. 수많은 단기 커넥션을 관리하기 위해 풀링을 구현합니다.

실용적인 문제: 사용 사례 시나리오

Acme Retail은 읽기 트래픽이 많고 간헐적으로 분석 작업이 급증하는 MySQL RDS 프라이머리를 운영하고 있습니다. 야간 ETL 작업 중 복제 지연(replica lag)이 발생하고, 잦은 커넥션 교체로 인한 CPU 급증을 겪고 있습니다.

애플리케이션 읽기 작업과 분리된 분석용 읽기 전용 복제본 그룹을 추가로 활성화하고, DR을 위해 다른 AZ나 리전에 배치합니다.
복제본 모니터링(ReplicaLag 지표)을 구성하고, 지연 또는 ReadLatency가 임계값을 초과할 때 읽기 전용 복제본을 추가하는 오토스케일링 로직을 추가합니다.
애플리케이션 앞에 RDS Proxy를 배포하여 커넥션을 다중화하고 커넥션 교체를 줄입니다. 파라미터 그룹에서

undefined

을 적절히 조정합니다. 4. 분석 작업을 분석용 복제본으로 이전하고, 반복적인 쿼리를 줄이기 위해 적절한 TTL을 설정한 ElastiCache Redis를 통해 cache-aside 캐싱을 도입합니다. 5. 장애 조치 및 복원 절차를 테스트합니다. 스테이징 인스턴스에서 PITR 복원을 수행하고 복제본 승격 단계를 검증합니다.

이 접근 방식은 읽기 워크로드를 분리하고, 프라이머리의 커넥션 부하를 줄이며, 캐싱을 사용하여 DB 읽기 볼륨을 낮춥니다. 이는 읽기 스케일링, 커넥션 풀링, 테스트된 백업/복원 프로세스를 결합하여 가용성과 운영 탄력성을 유지하는 AWS 모범 사례를 따릅니다.

← 컴퓨팅 및 Auto Scaling · 모든 도메인 · 서버리스 및 애플리케이션 통합 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →