Amazon SAP-C02: 데이터베이스 및 분석 — 학습 가이드

By Laurynas Brazys · 1 August 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

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

트랜잭션 데이터베이스, 확장 패턴 및 캐싱

Amazon RDS (MySQL/PostgreSQL/Oracle/SQL Server), Amazon Aurora, Amazon DynamoDB 중에서 선택하는 것은 워크로드 프로필을 파악하는 것에서 시작됩니다. 엄격한 관계형 스키마와 복잡한 트랜잭션이 필요하다면 RDS/Aurora가 유리하고, 대규모 확장성, 한 자릿수 밀리초의 조회 속도, 유연한 스키마가 필요하다면 DynamoDB가 유리합니다. Aurora는 분산 스토리지, 복제본 오토스케일링, 빠른 장애 조치, 리전 간 읽기 및 더 짧은 지연 시간의 재해 복구를 위한 Global Database를 통해 높은 처리량을 제공합니다. RDS 다중 AZ는 가용성을 위해 동기식 복제를 제공하지만 읽기 확장(read scaling)은 지원하지 않으며, 읽기 전용 복제본(RDS/Aurora)은 읽기 중심(read-heavy) 워크로드를 처리합니다. 키-값 캐싱과 마이크로초 수준의 지연 시간이 필요할 경우, ElastiCache(Redis 또는 Memcached)를 사용하여 DB 부하를 줄일 수 있습니다. 데이터의 고가용성 및 복구 가능성이 중요한 경우, 내구성과 Redis 호환 지속성을 추가한 MemoryDB for Redis를 사용합니다. 흔히 발생하는 문제로는 연결 제한(MySQL max connections)을 과소평가하거나, 커넥션 풀링을 사용하지 않거나(Lambda/컨테이너가 많은 연결을 생성), 잘못된 키 설계로 인한 DynamoDB의 핫 파티션 발생, 캐시 제거/설계 미비로 인한 데이터 정합성 문제 등이 있습니다. 의사 결정 시에는 주로 비용과 성능 및 복원력 사이의 트레이드오프를 고려합니다. 프로비저닝된 Aurora/대규모 RDS 인스턴스는 비용이 더 높지만 지연 시간을 줄이고 트랜잭션을 단순화합니다. 반면, 온디맨드 또는 오토스케일링을 사용하는 DynamoDB는 운영 부담을 줄일 수 있지만 신중한 스키마 및 용량 계획이 필요합니다. 암호화, 자동 백업, PITR, 리전 간 복제 패턴은 RPO/RTO에 따라 선택해야 합니다.

데이터 레이크, ETL 및 분석 쿼리 엔진

S3는 표준적인 내구성 있는 데이터 레이크입니다. 비용 효율적인 쿼리를 위해 파티셔닝, 열 기반 포맷(Parquet/ORC), 압축, 컴팩션(compaction)을 중심으로 설계해야 합니다. AWS Glue와 AWS Glue Data Catalog는 서버리스 ETL, 스키마 검색, 카탈로깅 기능을 제공합니다. Lake Formation은 중앙 집중식 접근 제어, 세분화된 권한, 계정 간 공유 기능을 추가하여 거버넌스가 적용된 데이터 레이크를 구축할 수 있게 합니다. 대화형 분석을 위해 Amazon Athena는 S3 데이터를 직접 쿼리하며(서버리스, 쿼리당 과금), Amazon Redshift(RA3/Iceberg 지원)는 복잡한 BI 및 조인을 위한 고성능의 관리형 MPP 웨어하우징을 제공합니다. Redshift Spectrum을 사용하면 모든 데이터를 수집하지 않고도 Redshift에서 S3 데이터를 쿼리할 수 있습니다. Kinesis Data Firehose는 스트리밍 이벤트를 S3나 Redshift로 적재하는 관리형 수집 경로입니다. 아키텍처 설계 시 흔히 발생하는 문제로는 너무 많은 작은 파일로 인해 Athena/Redshift의 오버헤드가 증가하거나, 잘못 선택된 파티션 키로 인해 데이터 쏠림(skew)이 발생하거나, 열 기반 포맷으로 변환 또는 컴팩션을 하지 않는 경우 등이 있습니다. 트레이드오프는 지연 시간과 비용 사이에서 이루어집니다. Athena는 애드혹 쿼리에 대한 운영 비용이 낮고, Redshift는 더 높은 프로비저닝 비용으로 더 높은 지속 성능을 제공합니다. 규정 준수 및 여러 팀의 소유권 관리를 위해서는 Glue/Lake Formation을 통한 데이터 거버넌스 및 리니지(lineage) 확보가 필수적입니다.

스트리밍, 실시간 처리 및 검색

실시간 수집 및 처리를 위해서는 Kinesis Data Streams(샤드 기반 처리량 및 순서 보장), Kinesis Data Firehose(싱크로의 관리형 전송), Kinesis Data Analytics(SQL/Apache Flink 처리) 또는 Kafka 호환이 필요한 경우 Amazon MSK를 사용합니다. AWS 네이티브 서버리스 환경과 간단하게 통합하려면 Kinesis를 선택하고, 클라이언트가 Kafka 생태계 도구에 의존하는 경우 MSK를 선택합니다. 최소 한 번 전송(At-least-once delivery) 의미 체계, 샤드 제한, 소비자(consumer) 병렬 처리, 적절한 샤드 프로비저닝은 흔히 발생하는 운영상의 문제입니다. 다운스트림에서의 빠른 검색과 관찰 가능성을 위해, Amazon OpenSearch Service는 인덱싱, 거의 실시간 검색, 내장된 Kibana 대시보드를 제공합니다. 인덱스 수명 주기 관리와 웜/콜드 티어는 오래된 데이터의 비용을 절감합니다. Kinesis + Lambda 또는 Kinesis + KDA를 사용하여 이벤트를 OpenSearch나 S3에 저장하기 전에 보강/변환할 수 있습니다. 재시도나 재처리로 인해 중복이 발생할 수 있으므로, 소비자(consumer)에 멱등성과 중복 제거 로직을 설계해야 합니다. 의사 결정 기준은 처리량과 지연 시간 사이의 균형을 맞추는 것입니다. 많은 샤드를 가진 Kinesis는 높은 처리량을 지원하지만 비용과 관리 부담이 증가하며, Firehose는 소비자 부담을 덜어주지만 변환 유연성은 떨어집니다.

마이그레이션, 복제, 거버넌스 및 운영 탄력성

AWS Database Migration Service(AWS DMS)와 Schema Conversion Tool(SCT)은 동종 및 이기종 마이그레이션을 위한 주요 도구이며, 지속적인 변경 데이터 캡처(CDC)를 지원합니다. 마이그레이션 패턴에는 리호스트(lift-and-shift), 리플랫폼(예: Aurora로 이전), 그리고 적절한 경우 DynamoDB 또는 서버리스로 리팩터링하는 것이 포함됩니다. 사전 및 사후 마이그레이션 검증, 병렬 테이블 복사, 신중한 LOB/LOBLOB 처리를 DMS와 함께 사용해야 합니다. 계정 간 및 리전 간 복제에는 KMS 키 액세스, VPC 피어링 또는 Transit Gateway, 네트워크 대역폭 계획이 필요합니다. 리전 간에 짧은 지연 시간의 읽기가 필요할 때는 Global Databases와 읽기 전용 복제본이 대안이 될 수 있습니다. 거버넌스 및 보안에는 데이터 공유를 위한 Lake Formation, IAM 최소 권한 원칙, S3 및 RDS 스냅샷에 대한 리소스 정책, 퍼블릭 이그레스를 피하기 위한 VPC 엔드포인트/PrivateLink가 포함되어야 합니다. 운영상의 함정으로는 불충분한 모니터링(복제 지연 누락), 장애 조치/런북 미테스트, 대량 전송 중 숨겨진 이그레스 비용 등이 있습니다. 백업, PITR 전략, 자동 복구는 RTO/RPO 절충에 영향을 미칩니다. 가용성을 위한 복제와 장기 보존 및 규정 준수를 위한 정기 백업을 결합해야 합니다.

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

시나리오: Acme Retail은 us-east-1과 europe-west-1에 프로덕션 워크로드를 둔 다중 계정 AWS Organization에서 전자 상거래 플랫폼을 운영하고 있습니다. 클릭스트림과 트랜잭션 이벤트를 S3에 저장하고 있으며, 최소한의 다운타임으로 AWS로 마이그레이션해야 하는 온프레미스 OLTP DB를 운영 중입니다.

과제: 실시간 수집 및 쿼리 기능을 갖춘 S3 기반의 거버넌스가 적용된 분석 레이크를 구축하면서, OLTP 데이터베이스를 고가용성의 교차 리전 읽기 확장 가능 대상(target)으로 마이그레이션해야 합니다.

권장 접근 방식:

AWS DMS와 SCT를 사용하여 스키마를 변환하고, 온프레미스 DB에서 us-east-1의 Amazon Aurora(Global Database)로 지속적인 CDC를 설정하며, europe-west-1에 Aurora 읽기 전용 복제본을 구성합니다.
Amazon Kinesis Data Streams와 Firehose를 통해 클릭스트림 및 트랜잭션 이벤트를 수집하고, 원시 이벤트를 버퍼링하여 날짜와 리전별로 파티셔닝된 Parquet 형식으로 S3에 전달합니다.
AWS Glue로 S3 데이터를 카탈로그화하고, Lake Formation을 통해 액세스 제어를 시행하며, Glue 작업(또는 Glue Studio)으로 ETL을 수행하여 큐레이션된 데이터 세트를 생성합니다. 이 데이터 세트를 Amazon Athena와 Redshift Spectrum을 통해 분석가에게 제공합니다.
자주 액세스하는 제품 및 세션 데이터의 읽기 성능 향상을 위해 ElastiCache(Redis)를 추가합니다. CloudWatch로 엔드투엔드 모니터링을 구축하고, Aurora에서 Enhanced Monitoring을 활성화하며, 런북으로 장애 조치를 검증합니다.

근거: 이 접근 방식은 DMS CDC를 사용하여 다운타임을 최소화하고, Aurora Global Database를 통해 짧은 지연 시간의 글로벌 읽기를 제공하며, 분석 민첩성을 위해 거버넌스가 적용된 S3 데이터 레이크를 구축합니다. 또한 캐싱과 분리된 스트리밍 수집을 통해 OLTP 시스템의 부하를 줄여 엔터프라이즈 탄력성 및 성능 모범 사례에 부합하도록 합니다.

← 스토리지 및 데이터 관리 · 모든 도메인 · 마이그레이션 및 현대화 →

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