Amazon DOP-C02: 스토리지, 데이터베이스 및 데이터 관리 — 학습 가이드

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

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

개요

AWS의 스토리지, 데이터베이스, 데이터 이동은 내구성, 가용성, 비용 효율성, 자동화를 고려하여 설계해야 합니다. S3 스토리지 클래스와 복제, DynamoDB 용량과 글로벌 배포, RDS/Aurora 구성 제어와 백업 패턴, 인메모리 캐싱, 공유 파일 시스템, 데이터 마이그레이션 서비스에 대한 숙달은 예측 가능한 복구 동작과 통제된 비용으로 안정적이고 지연 시간이 짧은 시스템을 구현할 수 있게 합니다.

Amazon S3: 스토리지 클래스, 수명 주기, 인텔리전트 티어링, 복제

S3 스토리지 클래스는 액세스 패턴에 맞춰 비용을 조정합니다:

Standard: 다중 AZ, 짧은 지연 시간, 검색 요금 없음. 핫 데이터의 기본값.
Intelligent-Tiering (S3 INT): 다중 AZ이며 Frequent Access 티어와 Infrequent Access 티어, 그리고 선택적 아카이브 티어 간에 자동 티어링을 제공합니다. 객체당 모니터링 및 자동화 요금이 부과되며, 128KB보다 작은 객체는 자동 티어링되지 않습니다. Archive Access 및 Deep Archive Access 티어는 마지막 액세스 임계값과 함께 옵트인(opt-in) 방식으로 제공되며, frequent가 아닌 티어에서 검색 시 검색 요금이 적용됩니다.
Standard-IA 및 One Zone-IA: 검색 요금이 있지만 스토리지 비용이 더 저렴하며, 최소 30일의 스토리지 요금이 부과됩니다. One Zone-IA는 단일 AZ로, 재생성 가능한 데이터에 적합합니다.
Glacier Instant Retrieval: 아카이브 수준의 경제성으로 밀리초 단위 액세스를 제공하며, 최소 90일 보관이 필요합니다.
Glacier Flexible Retrieval: 분에서 시간 단위의 검색, 대량/표준/신속 옵션 제공. 최소 90일 보관이 필요합니다.
Glacier Deep Archive: 시간에서 12시간 단위의 검색. 최소 180일 보관이 필요합니다. 최소 스토리지 기간 요금, 검색 요금, 필요한 액세스 시간을 고려하여 실행 가능한 가장 콜드한 티어를 선택하세요.

수명 주기 정책은 필터(접두사, 태그)를 사용하여 전환 및 만료를 자동화하여 세분화된 제어를 제공합니다. 주요 작업에는 비활성 임계값 이후 IA/Glacier 티어로의 전환, 버전 관리가 활성화된 버킷에서 현재 버전이 아닌 객체의 전환/만료, 삭제 마커 만료, 완료되지 않은 멀티파트 업로드 중단 등이 포함됩니다. 불변성이 요구될 때, 수명 주기 및 객체 태깅은 S3 Object Lock(거버넌스/규정 준수 모드)과 함께 데이터 보존 및 방어 가능한 삭제를 시행하는 데 중요합니다.

Intelligent-Tiering은 액세스 패턴을 알 수 없거나 가변적일 때 이상적입니다. 성능을 유지하고(frequent/IA 티어에서 검색 지연 없음), 패턴이 변경될 때 아키텍처를 재설계할 필요가 없으며, 마지막 액세스를 기반으로 딥 티어로 자동 아카이브할 수 있는 옵션을 제공하여, 간헐적으로 액세스되는 장기 데이터 세트에 대해 민첩성과 비용 제어의 최상의 조합을 제공합니다.

S3 복제는 객체의 내구성 있는 비동기식 사본을 제공합니다:

요구 사항: 소스 및 대상 버킷에 버전 관리 활성화. 복제 구성은 대상 버킷/계정/리전, 접두사/태그 필터, 메타데이터 복제(ACL, 태그, S3 Object Lock), 스토리지 클래스, 삭제 마커 및 기존 객체 복제 여부를 정의합니다.
Same-Region Replication (SRR): 규정 준수/데이터 주권, 로그 집계, 계정 간 원자적 처리.
Cross-Region Replication (CRR): 재해 복구(DR), 지연 시간 감소, 글로벌 배포, 규정 준수.
KMS 암호화 객체: 복제 역할은 소스 KMS 키로 복호화하고 대상 KMS 키로 암호화할 수 있는 권한이 있어야 합니다. 복제 규칙의 EncryptionConfiguration에 복제본 KMS 키를 지정해야 합니다. 계정 간 복제의 경우, 대상 버킷 정책을 업데이트하여 복제 역할이 쓰기 작업을 수행할 수 있도록 허용해야 합니다.
기존 객체: S3 Batch Replication을 사용하여 백필(backfill)합니다.
Replication Time Control (RTC): 복제 완료에 대해 15분 SLA를 추가하고, SLA 모니터링을 위한 복제 지표 및 알림을 제공합니다. 규정 준수 및 엄격한 RPO에 유용합니다.
소유권 및 액세스: 계정을 교차할 때, ACL 복잡성을 피하고 대상 계정이 복제본을 소유하도록 하려면 ‘버킷 소유자 선호’ 또는 객체 소유권의 ‘버킷 소유자 적용’을 활성화하세요.

AWS의 데이터베이스: DynamoDB, RDS, Aurora

DynamoDB 용량 모드 및 스케일링:

온디맨드: 용량 계획이 필요 없음. 요청당 과금. 예측 불가능하거나 스파이크가 심한 워크로드 및 트래픽을 알 수 없는 새 테이블에 이상적.
프로비저닝됨: 목표 사용률에 맞춰 DynamoDB Application Auto Scaling으로 RCU/WCU를 설정. 안정적이거나 예측 가능한 트래픽 및 비용 관리에 적합.
적응형 용량: 파티션 처리량을 핫 키에 자동으로 재분배하지만, 극심한 핫 파티션은 여전히 부하 분산(예: 쓰기 샤딩)이 필요. GSI는 별도의 용량을 가지므로 쓰로틀링을 피하기 위해 신중하게 모델링해야 함.
항목 크기가 용량에 영향을 미침: 1KB 쓰기당 1 WCU, 4KB 강력한 일관성의 읽기당 1 RCU 또는 8KB 최종적 일관성의 읽기당 1 RCU.

DynamoDB 스트림 및 DAX:

스트림은 24시간 보존 기간으로 항목 수준 변경을 캡처. NEW/OLD 이미지를 포함하도록 뷰 유형을 선택. 일반적인 패턴: CQRS/이벤트 기반 쓰기를 위한 Lambda 트리거, 테이블 간 동기화, 감사 추적. 순서는 파티션 키별로 보장되며, 전달은 최소 한 번(at-least-once) 이상.
DAX는 DynamoDB를 위한 관리형 API 호환 인메모리 캐시로, 읽기 지연 시간을 크게 줄여줌. 최종적 일관성의 읽기를 지원하며, 강력한 일관성의 읽기는 DAX를 우회해야 함. 항목 변경에 대한 쓰기 관통(write-through) 및 TTL 기반 무효화를 제공. 고가용성을 위해 다중 AZ 클러스터를 사용하고 DAX 서브넷을 클라이언트 가까이에 배치.

DynamoDB 전역 테이블:

시스템 타임스탬프를 기반으로 한 최종 쓰기자 우선(last-writer-wins) 충돌 해결 방식을 사용하는 스트림 기반의 다중 리전, 다중 마스터 복제. 여러 리전에서 동일한 속성에 대한 동시 업데이트를 피하도록 설계하거나 애플리케이션 측 조정을 구현.
TTL 속성은 일반 항목 데이터로 복제됨. TTL 기반 삭제는 리전별로 처리되며 명시적 삭제로 복제되지 않음.
백업 및 PITR(특정 시점 복구)은 리전 범위. 리전별로 새 테이블에 복원하고 (선택적으로) 새 전역 테이블로 다시 생성.

Amazon RDS 구성 및 백업:

파라미터 그룹은 엔진 파라미터를 정의. 정적 파라미터는 재부팅이 필요하며, 동적 파라미터는 지원되는 경우 즉시 적용됨. 인스턴스 수준 엔진에는 DB 파라미터 그룹을, Aurora에는 클러스터 파라미터 그룹을 사용.
옵션 그룹은 엔진 네이티브 기능(예: Oracle TDE/OEM, SQL Server 네이티브 백업/복원, MySQL/MariaDB 플러그인)을 활성화. 옵션은 엔진 재시작이 필요할 수 있으므로 변경 기간을 신중하게 관리.
자동 백업은 보존 기간(최대 35일) 내에 PITR을 활성화. 매일의 스냅샷과 트랜잭션 로그를 S3에 캡처하며, 복원 시 새 인스턴스가 생성됨.
수동 스냅샷은 삭제될 때까지 보존되며, 리전 간 복사 및 계정 간 공유가 가능(암호화된 스냅샷의 경우 KMS 키 권한 준수). DR 시드를 위해 리전 간 스냅샷 복사를 사용.

Amazon Aurora 특성:

엔드포인트: 클러스터(라이터) 엔드포인트는 항상 쓰기를 위해 프라이머리를 가리킴. 리더 엔드포인트는 복제본 간에 로드 밸런싱을 수행. 사용자 지정 엔드포인트는 계층화된 읽기 풀이나 특수 워크로드를 위해 리더의 하위 집합을 선택할 수 있음. 장애 조치 중 중단을 최소화하려면 쓰기는 항상 라이터 엔드포인트로, 읽기는 리더/적절한 사용자 지정 엔드포인트로 지정.
서버리스 v2: 재시작 없이 ACU를 세분화되고 즉각적으로 스케일링. Aurora 클러스터 내에서 실행되며, 서버리스 인스턴스와 프로비저닝된 인스턴스의 혼합을 지원. 스파이크가 심한 워크로드, 개발/테스트 또는 수요가 고르지 않은 다중 테넌트 앱에 매우 적합. 지속적인 스케일링 덕분에 v1보다 연결 일관성을 더 잘 보존.
클로닝: 개발/테스트, 데이터 사이언스 또는 블루/그린 변경 검증을 위해 리전 내에서 빠른 쓰기 시 복사(copy-on-write) 클론을 생성. 클론은 공간 효율적이며 변경된 페이지에서만 분기됨. 클론을 연쇄적으로 생성할 수 있으며, 완료되면 삭제하여 스토리지를 회수.

캐싱 및 공유 파일 시스템: ElastiCache 및 EFS

ElastiCache for Redis vs Memcached:

Redis: 고급 데이터 구조, 복제, Pub/Sub, Lua, 스트림, 지리 공간, 정렬된 세트 및 스냅샷을 통한 영속성 지원. 다중 AZ 자동 장애 조치 및 리전 간 읽기 전용 복제본을 위한 Redis Global Datastore를 지원. 풍부한 데이터 유형, 내구성(스냅샷 복원) 또는 장애 조치가 포함된 고가용성이 필요할 때 Redis를 선택.
Memcached: 단순하고, 멀티스레드이며, 복제나 영속성이 없음. 클라이언트 측 샤딩을 통한 스케일 아웃. 상태 비저장(stateless)이며 수평 확장이 용이. 처리량이 매우 높은 임시적인 순수 캐싱이 필요하고 클라이언트에서 샤딩을 제어하고 싶을 때 Memcached를 선택. Redis 클러스터 모드 및 복제 그룹:
클러스터 모드 비활성화: 하나의 샤드에 프라이머리와 복제본이 있음. 수직 확장 또는 읽기 전용 복제본을 통한 제한된 수평 확장.
클러스터 모드 활성화: 여러 프라이머리 샤드에 걸쳐 해시 슬롯 샤딩을 수행하며, 각 샤드에는 복제본이 있어 선형에 가까운 스케일 아웃이 가능. 복제 그룹은 프라이머리/복제본 토폴로지 및 다중 AZ 장애 조치를 정의. 백업은 복제 그룹별로 수행되며, 장애 조치를 테스트하여 RTO를 검증.

공유 POSIX 파일을 위한 Amazon EFS:

탑재 대상: VPC의 각 AZ에 하나씩 생성하여 AZ 내 액세스 경로와 가용성을 보장. 탑재 대상의 보안 그룹은 NFS 트래픽을 제어. 필요한 경우 전송 중 TLS 및 IAM 권한 부여를 위해 EFS 탑재 헬퍼를 사용.
액세스 포인트: 애플리케이션에 대한 루트 디렉터리 및 POSIX 자격 증명(UID/GID)을 강제하여, OS 사용자 관리를 조정할 필요 없이 ECS/EKS/EC2에서 다중 테넌트 격리 및 간단한 최소 권한 탑재를 가능하게 함.
수명 주기 관리 및 스토리지 클래스: EFS Standard 및 Standard-IA(리전, 다중 AZ)와 One Zone/One Zone-IA(단일 AZ). 인텔리전트 티어링은 마지막 액세스 시간을 기준으로 표준 클래스와 IA 클래스 간에 파일을 자동으로 이동시키며, 명시적 전환 정책을 설정할 수도 있음. 비용 절감을 위해 재생성 가능하거나 중요하지 않은 데이터에는 One Zone 변형을 선택. AWS Backup과 결합하여 중앙 집중식 정책 및 계정/리전 간 백업을 구현.

데이터 마이그레이션: DMS, Snowball, DataSync

AWS Database Migration Service (DMS): 전체 로드(full load)와 변경 데이터 캡처(CDC)를 사용하여 최소한의 다운타임으로 온라인 마이그레이션을 수행합니다. 내장된 스키마 변환 기능을 통해 동종 및 이기종 마이그레이션을 지원합니다(복잡한 변환은 AWS Schema Conversion Tool 사용). RDS/Aurora로의 리프트 앤 시프트, DynamoDB로의 마이그레이션(JSON 매핑 사용), 또는 읽기 오프로딩이나 단계적 컷오버를 위한 지속적인 복제에 사용합니다. 최대 변경률에 맞춰 복제 인스턴스의 크기를 조정하고, 소스 로그(예: binlog/redo)가 충분한 기록을 유지하도록 보장해야 합니다.
AWS Snowball (Edge Storage/Compute Optimized): 네트워크가 제한적이거나 비쌀 때, 또는 대규모 S3/EFS 데이터 세트를 빠르게 시딩(seed)해야 할 때 사용하는 페타바이트 규모의 오프라인 데이터 전송 서비스입니다. 여러 디바이스를 연결하여 수 페타바이트의 로드를 처리할 수 있습니다. 초기 대량 로드, 원격/엣지 데이터 수집, 또는 제약이 있는 데이터 센터로부터의 마이그레이션에 사용합니다. 데이터는 KMS로 종단 간 암호화되며, 디바이스 추적 및 변조 방지 씰이 관리 연속성을 지원합니다.
AWS DataSync: NFS/SMB에서 S3/EFS/FSx로, 그리고 AWS 스토리지 서비스/리전 간의 온라인 가속 전송을 지원합니다. 증분 변경 감지, 병렬화, 압축, 대역폭 제어, 스케줄링 및 무결성 검사를 처리합니다. 반복적인 델타 이동, 하이브리드 워크플로, 그리고 사용자 지정 rsync 스크립트를 관리형 자동화로 대체하는 데 사용합니다. 온프레미스에 DataSync 에이전트를 배포하여 로컬 스토리지에 액세스합니다.

실제 문제 시나리오

Shopify는 전 세계 구매자의 복원력과 지연 시간을 개선하면서 글로벌 제품 미디어 파이프라인과 카탈로그 데이터를 현대화해야 합니다. 이 회사는 다음을 수행해야 합니다: 엄격한 RPO를 준수하며 여러 리전 및 계정에 걸쳐 제품 이미지를 복제하고, 북미와 유럽의 DynamoDB 읽기 지연 시간을 줄이고, 지속적인 델타가 발생하는 온프레미스 NFS 자산을 마이그레이션하고, 신뢰할 수 있는 백업으로 RDS 운영을 단순화해야 합니다.

기본 미디어 버킷(us-east-1, 상품 관리 계정)에서 대상 버킷(eu-west-1, 제공 계정)으로 Replication Time Control(RTC)이 적용된 S3 CRR을 구현합니다.

이유: CRR은 최소 권한 및 데이터 주권 원칙을 위해 리전 간 및 계정 간 분리를 충족합니다. RTC는 규정 준수 등급의 RPO를 위한 15분의 복제 SLA와 모니터링을 제공합니다. 계정 간 버킷 정책은 소스 복제 역할이 쓰기 작업을 수행할 수 있도록 보장하며, 대상 KMS 키를 지정하여 암호화 도메인을 유지합니다.

원본, 썸네일, 로그를 분리하기 위해 접두사 및 태그로 필터링된 S3 복제 규칙을 정의하고, 삭제 마커 복제를 활성화합니다. S3 Batch Replication을 사용하여 레거시 객체를 백필(backfill)합니다.

이유: 규칙 범위를 지정하면 불필요한 복제 비용을 피할 수 있고, 삭제 마커 복제는 리전 간의 의미론적 일관성을 유지합니다. Batch Replication은 맞춤형 스크립트 없이 과거 데이터의 격차를 해소합니다.

제품 카탈로그와 인벤토리를 us-east-1과 eu-west-1에 걸친 DynamoDB 글로벌 테이블로 변환합니다. 테이블을 온디맨드 용량으로 전환하고, 읽기 집약적인 API를 위해 각 리전에 DAX 클러스터를 추가합니다.

이유: 글로벌 테이블은 짧은 지연 시간의 로컬 읽기/쓰기와 지속적인 복제를 통해 액티브-액티브 쓰기를 제공합니다. 온디맨드 모드는 트래픽 급증 시 용량 계획의 위험을 제거합니다. DAX는 빈번한 읽기 요청에 대한 P99 지연 시간을 줄여, 급증하는 액세스로부터 DynamoDB를 보호합니다.

주문 관련 관계형 워크로드를 쓰기 및 읽기 엔드포인트가 있는 Amazon Aurora MySQL로 리플랫포밍합니다. 급증하는 분석 워크로드를 위해 작은 Aurora Serverless v2 읽기 전용 인스턴스를 추가하고, 14일 보존 정책으로 자동 백업을 활성화합니다.

이유: 클러스터/읽기 엔드포인트는 읽기/쓰기를 분리하고 유지 관리 또는 장애 조치 중 중단을 최소화합니다. Serverless v2는 예측 불가능한 분석 버스트를 비용 효율적으로 흡수합니다. 자동 백업은 PITR(지정 시간 복구)과 단순화된 복원 프로세스를 제공합니다.

세션 스토리지 및 제품 가용성 캐싱을 위해 ElastiCache for Redis(클러스터 모드 활성화)를 도입하고, Multi-AZ 및 스냅샷 백업을 구성합니다. 비즈니스 SLA에 맞춰 TTL을 설정합니다.

이유: Redis 데이터 구조와 Multi-AZ 장애 조치는 빠르고 상태를 유지하는 세션과 거의 실시간에 가까운 캐시 무효화를 보장합니다. 클러스터 모드는 카탈로그 크기와 트래픽이 증가함에 따라 수평적으로 확장됩니다.

각 애플리케이션 AZ에 탑재 대상이 있는 EFS Regional 파일 시스템을 생성하고, 공유 POSIX 스토리지가 필요한 워크로드(예: 미디어 프로세서)를 위해 Access Point를 사용합니다. 30일 후 IA로 전환하는 EFS 수명 주기 정책을 활성화합니다.

이유: EFS는 탄력적인 다중 AZ 공유 스토리지를 제공합니다. Access Point는 애플리케이션별 격리 및 POSIX ID를 강제합니다. 수명 주기 관리는 액세스는 가능하지만 자주 사용하지 않는 콜드 자산에 대한 비용을 자동으로 절감합니다.

AWS DataSync를 사용하여 온프레미스 NFS 미디어 라이브러리를 마이그레이션하고, 야간 증분 동기화를 위한 예약된 작업을 통해 S3 및 EFS로 데이터를 전송합니다.

이유: DataSync는 임시방편의 rsync보다 변경 감지, 병렬 처리, 무결성 검증 및 대역폭 제어를 더 잘 처리하여, 최소한의 운영으로 지속적인 델타 전송을 자동화합니다.

AWS DMS(전체 로드 + CDC)와 필요한 경우 AWS Schema Conversion Tool을 사용하여 레거시 PostgreSQL 카탈로그를 Aurora로 이전합니다. CDC 지연이 해소된 후 컷오버합니다.

이유: DMS는 거의 제로 다운타임에 가까운 마이그레이션을 가능하게 하며, 지속적인 복제를 통해 컷오버 시점의 데이터 일치를 보장합니다. SCT는 엔진별 변환을 처리합니다.

Snowball Edge 디바이스를 사용하여 수 페타바이트의 과거 미디어를 S3로 시딩한 다음, 지속적인 증분 업데이트를 위해 DataSync로 전환합니다.

이유: Snowball은 WAN 링크를 포화시키지 않고 초기 대량 전송을 가속화합니다. DataSync는 시딩 후 검증 및 스케줄링 기능을 통해 지속적인 업데이트를 유지합니다.

이 아키텍처는 전 세계적인 읽기 지연 시간을 줄이고, 예측 가능한 복제 RPO를 제공하며, 관계형 데이터베이스 운영 및 백업을 단순화하고, 액세스 제어 기능이 있는 중앙 집중식 공유 스토리지를 제공하며, 대규모 오프라인 마이그레이션에서 자동화된 증분 데이터 이동으로 전환하는 실용적인 경로를 제시합니다.

← 이벤트 기반 아키텍처 및 자동화 · 모든 도메인 · 네트워킹 및 콘텐츠 전송 →

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