AWS DEA-C01 문제로 공부하기 — Day 14
Glue FindMatches 중복 레코드, CloudTrail Lake IAM 역할별 감사, Lake Formation 행 수준 필터, Glue 크롤러 + Redshift Serverless + Spectrum, Glue 카탈로그 테이블 버전 한도(복수) — 5문제 핵심 정리.
AWS Glue FindMatches 변환은 필드 이름이 달라도 같은 개념을 나타내는 레코드를 ML 기반으로 연결·식별하는 내장 기능입니다. EMR 클러스터나 SageMaker 모델 없이 Glue ETL 파이프라인에서 바로 사용 가능합니다.
분석 플랫폼이 여러 Amazon RDS 데이터베이스에서 고객 데이터를 읽습니다. 한 DB는 위치 필드를 place_id로, 다른 DB는 location_id로 저장합니다. 이처럼 필드명이 달라도 여러 DB의 고객 레코드를 연결해야 합니다. 운영 오버헤드를 최소화하는 방법은 무엇일까요?
- A프로비저닝된 Amazon EMR 클러스터를 생성해 Zeppelin 노트북에서 FindMatches 변환으로 중복 레코드를 찾습니다.❌ Amazon EMR 클러스터 프로비저닝·관리 자체가 상당한 운영 오버헤드. 서버리스 Glue로 해결 가능한데 불필요하게 복잡함.
- BAWS Glue 크롤러로 데이터베이스를 크롤링하고, FindMatches 변환을 적용해 중복 레코드를 식별·연결합니다. 성능을 평가하며 변환을 튜닝합니다.✅ AWS Glue FindMatches 변환 — 필드명이 달라도 같은 실체를 나타내는 레코드를 ML로 연결하는 완전관리형 내장 기능. 크롤러로 메타데이터 등록 후 ETL 작업에서 FindMatches 적용. 별도 ML 모델 개발·인프라 없이 최소 오버헤드로 레코드 매칭.
- CAWS Glue 크롤러로 DB를 크롤링하고, Amazon SageMaker에서 Apache Spark ML 파이프라인을 구성해 중복 레코드를 찾습니다.❌ SageMaker ML 모델 훈련 스크립트 작성·훈련 작업 관리까지 필요. FindMatches 내장 기능 대비 추가 개발·운영 부담이 큼.
- D프로비저닝된 Amazon EMR 클러스터에서 Apache Spark ML 모델로 중복 레코드를 찾고 평가·튜닝합니다.❌ EMR 클러스터 프로비저닝 + Spark ML 파이프라인 직접 개발 + 모델 튜닝까지 운영 오버헤드가 가장 큼. Glue FindMatches로 코드 없이 해결 가능.
| 방법 | ML 개발? | 인프라 관리? | 운영 부담 |
|---|---|---|---|
| Glue FindMatches | 없음 (내장) | 없음 (서버리스) | 최소 |
| SageMaker Spark ML | 직접 작성 | 모델 관리 필요 | 높음 |
| EMR + Spark ML | 직접 작성 | 클러스터 관리 | 최대 |
"필드명 달라도 같은 레코드 연결 + 최소 오버헤드"
→ Glue FindMatches 변환
완전관리형 ML 내장 → EMR·SageMaker 불필요
튜닝 가능 → 라벨 데이터로 정확도 개선AWS CloudTrail Lake는 IAM 역할 단위로 이벤트 데이터 스토어를 분리하고 SQL로 쿼리할 수 있습니다. CloudFormation 이벤트는 CloudTrail이 캡처하며, S3 전달 포맷은 JSON(ORC 불가)입니다.
페더레이션 IAM 역할을 통해 사용자들이 AWS CloudFormation으로 애플리케이션을 배포·확장·종료합니다. 감사팀이 각 역할의 활동 이력을 SQL 쿼리로 분석할 수 있어야 합니다. 이 요건을 충족하는 솔루션은 무엇일까요?
- ACloudTrail Lake에 여러 이벤트 데이터 스토어를 생성합니다. 각 스토어에 관련 IAM 역할 기반 이벤트 유형을 선택합니다. 감사자가 SQL 쿼리를 실행할 수 있도록 CloudTrail Lake 권한을 설정합니다.✅ CloudTrail Lake 이벤트 데이터 스토어 — 이벤트 스키마 기반으로 데이터를 집계. IAM 역할별 이벤트를 분리된 데이터 스토어로 관리. SQL로 직접 쿼리 가능. 추가 S3·Glue·Athena 설정 없이 최소 설정으로 감사 + SQL 분석 구현.
- BS3 버킷으로 이벤트를 전송하도록 CloudFormation을 구성하고, Glue로 Apache ORC 형식으로 변환한 뒤 Athena SQL로 쿼리합니다.❌ CloudFormation은 이벤트를 S3로 직접 전송하는 기능이 없음. CloudTrail이 API 활동을 캡처해야 함. 또한 CloudTrail S3 전달 형식은 JSON 전용(ORC 불가).
- CCloudWatch Logs의 CloudFormation 로그 그룹을 특정하고, CloudWatch Logs Insights 쿼리를 실행할 권한을 감사자에게 부여합니다.❌ CloudWatch Logs Insights는 자체 쿼리 언어 사용. SQL을 지원하지 않음. SQL 쿼리 요건 미충족.
- D새 CloudTrail 추적을 만들어 Apache ORC 형식으로 S3에 전달하고, Athena SQL로 쿼리합니다.❌ CloudTrail은 S3 전달 시 JSON 행 기반 형식만 지원. ORC 형식으로 직접 구성 불가. 형식 변환을 위해 Glue ETL이 추가로 필요.
| 방법 | SQL 지원? | 설정 복잡도 | IAM 역할별 분리? |
|---|---|---|---|
| CloudTrail Lake | ✓ 내장 | 최소 | ✓ |
| CloudTrail + S3 + Athena | ✓ (설정 필요) | 중간 | 직접 구성 필요 |
| CloudWatch Logs Insights | ✗ 전용 언어 | 낮음 | 로그 그룹 단위 |
"CloudTrail 이벤트 SQL 쿼리 + 최소 설정" → CloudTrail Lake
CloudTrail S3 전달 = JSON 전용 (ORC 불가)
CloudWatch Logs Insights = SQL 아님 (전용 쿼리 언어)Lake Formation 행 수준 필터(Row-level Filter)는 특정 컬럼 값을 조건으로 행 전체에 대한 접근을 차단합니다. IAM 정책은 테이블·버킷 단위만 제어하고, Lake Formation 태그(LF-TBAC)는 행에 적용할 수 없습니다.
AWS Lake Formation 데이터 레이크에 고객 주소를 포함한 고객 데이터 테이블이 있습니다. 새 규정에 따라 캐나다 고객의 데이터 행에 대한 사용자 접근을 차단해야 합니다. 운영 노력을 최소화하는 방법은 무엇일까요?
- A행 수준 필터를 설정하여 국가가 캐나다인 행에 대한 사용자 접근을 차단합니다.✅ Lake Formation 행 수준 필터 — 컬럼 값 조건(국가 = 'Canada')으로 해당 행 전체에 대한 접근 차단. 코드 없이 Lake Formation 콘솔에서 필터 조건만 설정하면 Athena 쿼리 시 자동 적용. 최소 설정으로 행 단위 규정 준수.
- B국가가 캐나다인 주소에 대한 접근을 제한하는 IAM 역할을 생성합니다.❌ IAM은 테이블·버킷·API 호출 단위 접근 제어. 특정 컬럼 값 기반 행 수준 접근 제어 불가. Lake Formation으로만 구현 가능.
- C열 수준 필터를 설정하여 국가가 캐나다인 행에 대한 접근을 차단합니다.❌ 열 수준 필터는 특정 컬럼 자체에 대한 접근 제어. 캐나다 여부에 관계없이 모든 행에서 해당 컬럼이 숨겨짐. 특정 행 차단과 다른 기능.
- D캐나다 고객 행에 태그를 적용하고 해당 태그의 행 접근을 차단합니다.❌ Lake Formation LF-TBAC(태그 기반 접근 제어)는 카탈로그 리소스(데이터베이스·테이블·컬럼)에 태그 적용 가능. 행에는 태그를 연결할 수 없음. 행 수준 제어는 행 필터를 사용해야 함.
| 유형 | 제어 단위 | 행 차단 가능? |
|---|---|---|
| 행 수준 필터 | 컬럼 값 조건 → 행 전체 | ✓ |
| 열 수준 필터 | 특정 컬럼 | ✗ (컬럼 숨김) |
| LF-TBAC (태그) | 카탈로그 리소스 | ✗ (행 태그 불가) |
| IAM 정책 | 테이블·버킷·API | ✗ |
"특정 컬럼 값 기준으로 행 차단"
→ Lake Formation 행 수준 필터
태그(LF-TBAC) = 행에 적용 불가 (카탈로그 리소스만)
열 필터 = 행 차단 아님 (컬럼 숨김)Glue 크롤러 + Redshift Serverless + Redshift Spectrum 조합은 파티션·압축된 S3 데이터를 서버리스로 쿼리하는 표준 패턴입니다. 프로비저닝 클러스터나 재파티셔닝 없이 최소 오버헤드로 구현 가능합니다.
3년치 고객 서비스 데이터가 S3에 CSV 형식으로 저장되어 있습니다. 데이터는 동일 크기 파일로 파티셔닝되고 gzip으로 압축되어 있습니다. 전체 기록 분석이 필요합니다. 운영 오버헤드를 최소화하는 솔루션은 무엇일까요?
- AHive가 설치된 Amazon EMR 클러스터를 만들어 외부 Hive 메타스토어를 설정하고, Athena 데이터 커넥터로 쿼리합니다.❌ EMR 클러스터 + Hive 메타스토어 + Athena 데이터 커넥터까지 여러 구성 요소를 직접 설정·관리해야 함. 운영 오버헤드 높음.
- BGlue 크롤러를 실행해 파티셔닝된 데이터로 Glue 데이터 카탈로그를 채웁니다. Amazon Redshift Serverless 엔드포인트를 생성하고 데이터 카탈로그 기반 외부 스키마·테이블을 정의합니다. Redshift Spectrum으로 S3 데이터를 쿼리합니다.✅ Glue 크롤러 — 파티션·압축 데이터에서 자동으로 스키마 추출 + 카탈로그 등록. Redshift Serverless — 컴퓨팅 용량 자동 프로비저닝. Redshift Spectrum — S3 데이터를 직접 쿼리. 서버리스 서비스만 사용해 최소 운영 오버헤드.
- CAmazon Redshift 프로비저닝 클러스터를 만들고 Glue ETL 작업으로 S3 데이터를 Redshift 테이블로 수집합니다.❌ 프로비저닝 클러스터 구성 + 수집 ETL 작업 생성까지 추가 오버헤드. 데이터를 이동해야 하므로 S3에서 직접 쿼리하는 방법보다 복잡. Serverless가 더 효율적.
- D데이터를 압축 해제하고 더 큰 파일로 재파티셔닝한 뒤 Glue 크롤러와 Redshift 클러스터 + Spectrum으로 쿼리합니다.❌ Glue 크롤러는 압축·파티션 데이터 그대로 처리 가능. 불필요한 재파티셔닝 작업이 추가 오버헤드. Redshift 프로비저닝 클러스터도 Serverless보다 관리 부담이 큼.
| 방법 | 데이터 이동? | 서버리스? | 운영 부담 |
|---|---|---|---|
| Glue 크롤러 + Redshift Serverless + Spectrum | ✗ S3 직접 | ✓ | 최소 |
| EMR + Hive + Athena | ✗ 직접 | ✗ 클러스터 | 높음 |
| Glue ETL → Redshift 클러스터 | ✓ 이동 필요 | 부분 | 중간 |
"S3 파티션·압축 데이터 최소 오버헤드 쿼리"
→ Glue 크롤러 + Redshift Serverless + Spectrum
재파티셔닝·압축 해제 불필요 → 크롤러가 그대로 처리
Serverless = 클러스터 관리 없음ResourceNumberLimitExceededException은 Glue 데이터 카탈로그의 테이블당 최대 테이블 버전 수를 초과했을 때 발생합니다. 해결 방법은 서비스 할당량 증가 요청이나 오래된 테이블 버전 삭제입니다. 테이블 수·스키마와는 무관합니다.
데이터 엔지니어가 AWS Glue 데이터 카탈로그의 테이블 버전을 업데이트하려다 ResourceNumberLimitExceededException 오류를 받았습니다. 테이블 버전 리소스 수가 테이블당 허용 최대치를 초과했다고 표시됩니다. 이 오류를 해결하는 방법 두 가지는 무엇일까요?
- A데이터 카탈로그가 실행되는 AWS 리전에서 테이블당 최대 테이블 버전 수 할당량을 늘립니다(AWS Support 티켓).✅ 서비스 할당량(Soft Limit) 증가 — 테이블당 최대 버전 수는 소프트 한도로 AWS Support 티켓으로 증가 요청 가능. 근본 한도 자체를 높여 오류 해결. 버전이 계속 쌓이는 환경에서 지속 가능한 해결책.
- BAWS 리전에 허용되는 최대 테이블 수 할당량을 늘립니다.❌ 오류는 테이블 수가 아닌 테이블 버전 수와 관련. 테이블 수 할당량을 늘려도 이 오류는 해결되지 않음.
- C스키마에서 오래된 테이블을 검색하고 삭제합니다.❌ 오류는 테이블 수가 아닌 테이블 버전 수 초과. 테이블 자체를 삭제해도 버전 수 문제가 해결되지 않음.
- D오래된 테이블 스키마 버전을 검색하고 삭제합니다.✅ 테이블 버전 삭제 — Glue 카탈로그 테이블의 이전 버전 메타데이터를 삭제하면 버전 수가 줄어 한도 이하로 낮아짐. 즉각적인 오류 해결. BatchDeleteTableVersion API 또는 콘솔 사용.
- EAWS 계정에서 오래된 스키마를 검색하고 삭제합니다.❌ 오류는 스키마 수가 아닌 테이블 버전 수와 관련. 스키마 삭제는 이 오류 해결과 무관.
| 오류 원인 | 해결 방법 |
|---|---|
| 테이블당 버전 수 초과 | 할당량 증가 요청 또는 오래된 버전 삭제 |
| 리전당 테이블 수 초과 | 테이블 수 할당량 증가 요청 |
| 리전당 DB 수 초과 | DB 수 할당량 증가 요청 |
ResourceNumberLimitExceededException (테이블 버전)
→ 할당량 증가 요청 OR 오래된 테이블 버전 삭제
테이블 수/스키마 수와는 무관 → 버전(Version)이 핵심 키워드
