[AWS DEA] 문제로 공부하기 20 - OpenSearch

AWS DEA-C01 데이터 엔지니어 검색 · OpenSearch 메타데이터 인덱싱

S3 스캔 문서 메타데이터 검색 최적화 — OpenSearch가 정답인 이유

AWS DEA-C01 시험에 자주 나오는 검색 성능 최적화 문제입니다. S3에 저장된 수십만 개의 스캔 문서에서 ML로 추출한 메타데이터를 지원자 이름·날짜·텍스트로 빠르게 검색해야 할 때, OpenSearch / Athena / Redshift / EMR Presto 중 어떤 방식이 성능에 가장 최적화되어 있는지 도식과 함께 비교 정리합니다.

📋 문제

한 회사에서는 수십만 개의 스캔한 문서를 Amazon S3에 이미지로 저장한다. 이 문서에는 타자로 입력된 입사 지원서가 포함되어 있으며, 지원자 이름, 지원자 성, 지원 날짜, 지원자 위치 및 지원 텍스트가 입력되어 있다.

이 회사에서는 스캔한 문서에서 메타데이터 값을 추출하는 ML 알고리즘을 보유하고 있다. 회사에서는 데이터 분석가가 지원자 이름, 지원 날짜 또는 지원 텍스트를 사용하여 지원서를 검색할 수 있도록 하려고 한다.

다음 중 성능에 가장 최적화된 방식으로 이러한 요구 사항을 충족하는 솔루션은 무엇인가?

✅ 핵심 요구사항 체크

• 🔍
  이름 · 날짜 · 텍스트 기반 검색 (Full-Text Search)
  단순 쿼리가 아닌 자유 텍스트 검색 → 전문 검색(Full-Text Search) 엔진이 유리
• ⚡
  성능 최적화 (검색 속도)
  수십만 개 문서에서 빠른 응답 → 인덱스 기반 조회가 테이블 스캔보다 월등히 빠름
• 🗂️
  S3 이미지와 메타데이터 연결
  ML이 추출한 메타데이터 + S3 원본 파일 위치를 함께 저장하고 검색 가능해야 함

📐 전체 데이터 파이프라인

📄

스캔 문서

S3 이미지

→

🤖

ML 알고리즘

메타데이터 추출

→

🔎

OpenSearch

메타데이터 + S3 위치 인덱싱

→

📊

OpenSearch Dashboards

분석가 검색 UI

🔑 검색 방식의 핵심 차이 — 인덱스 vs 스캔

🔎

인덱스 기반 검색 (OpenSearch)

역색인(Inverted Index) 구조

• 단어 → 문서 목록 즉시 조회
• 수십만 건도 밀리초(ms) 응답
• 부분 일치·유사 검색 기본 지원
• 전문 검색(Full-Text) 최적화

✅ 검색 성능 최고

📋

테이블 스캔 (Athena / Redshift)

행·열 데이터 순차 조회

• 조건에 맞는 행을 처음부터 스캔
• 데이터 양 많을수록 느려짐
• 분석 쿼리에 최적화된 구조
• 텍스트 검색 기능 제한적

❌ 텍스트 검색 성능 불리

📊 솔루션별 성능 비교

솔루션	텍스트 검색	날짜 검색	이름 검색	검색 응답속도	관리 복잡도
OpenSearch ⭐	●●●	●●●	●●●	최고 (ms)	낮음
Athena + Parquet	●●○	●●●	●●○	보통 (초)	낮음
Redshift	●○○	●●●	●●○	보통 (초)	중간
EMR Presto	●○○	●●●	●●○	느림 (분)	높음

● 많을수록 우수 / ○ 부족

📝 선택지 해설

각 항목을 클릭하면 해설이 펼쳐집니다.

A

❌ S3 객체 태그 + EMR Presto — 객체 태그로 메타데이터 추가 후 Presto로 검색

Amazon EMR (Presto) — 대규모 분산 쿼리 엔진

💡 S3 객체 태그는 태그 수(10개)와 값 길이(256자)에 제한이 있어 풍부한 메타데이터 저장에 부적합합니다. EMR 클러스터는 프로비저닝·관리 오버헤드가 크고, 단건 검색보다 배치 처리에 최적화되어 있습니다. 검색 응답속도도 인덱스 기반 서비스에 비해 크게 느립니다.

B

✅ Amazon OpenSearch Service — 메타데이터와 S3 위치를 인덱싱, OpenSearch Dashboards로 검색

Amazon OpenSearch Service (역색인 기반 전문 검색 엔진)

💡 정답. OpenSearch는 역색인(Inverted Index) 구조로 텍스트 검색에 특화되어 있습니다. 이름·날짜·긴 텍스트 모두 고성능으로 검색할 수 있으며, 부분 일치·유사어 검색도 기본 지원합니다. ML이 추출한 메타데이터와 S3 파일 경로를 함께 인덱싱하면 분석가가 OpenSearch Dashboards에서 즉시 원본 문서 위치까지 확인할 수 있습니다. 수십만 건도 밀리초(ms) 수준으로 응답합니다.

C

❌ Amazon Redshift — 메타데이터와 S3 위치를 Redshift 테이블에 저장 후 쿼리

Amazon Redshift — 페타바이트급 열 기반 데이터 웨어하우스

💡 Redshift는 대규모 집계·분석 쿼리에 최적화된 데이터 웨어하우스입니다. 텍스트 기반 전문 검색은 지원하지만 OpenSearch의 역색인에 비해 성능이 낮습니다. 특히 "지원 텍스트" 같은 자유 형식 텍스트 검색은 LIKE 쿼리를 사용해야 해 속도가 느립니다. 검색 전용 시나리오에는 과분한 구성입니다.

D

❌ S3 Parquet + AWS Glue + Amazon Athena — Parquet 파일로 저장, Glue 카탈로그 정의, Athena로 쿼리

Amazon Athena (서버리스 S3 쿼리) + AWS Glue Data Catalog

💡 Athena + Parquet 조합은 데이터 레이크 분석에 탁월하지만, 검색 요청마다 S3 파일을 스캔하는 구조라 단건 검색 응답이 수 초~수십 초 걸립니다. 전문 검색 인덱스가 없어 텍스트 검색 성능이 OpenSearch보다 낮습니다. 대규모 집계·분석에는 적합하지만 "검색 성능 최적화" 요건에는 부족합니다.

정답 및 핵심 정리 (클릭)

정답: B — Amazon OpenSearch Service

텍스트·이름·날짜 검색 성능이 핵심인 이 시나리오에서 역색인 기반의 OpenSearch가 유일하게 밀리초 수준 응답을 보장합니다. ML이 추출한 메타데이터를 인덱싱할 때 S3 파일 경로도 함께 저장하면, 분석가가 OpenSearch Dashboards에서 검색 즉시 원본 문서에 접근할 수 있습니다.

# 흐름 요약 S3 스캔 이미지 └─ ML 알고리즘 (메타데이터 추출) └─ OpenSearch 인덱스에 저장 ├─ applicant_name: "홍길동" ├─ application_date: "2024-03-15" ├─ application_text: "지원 동기 텍스트..." └─ s3_location: "s3://bucket/docs/doc001.jpg" 분석가 검색 (OpenSearch Dashboards) └─ "홍길동" 검색 → 역색인 즉시 조회 → ms 응답 ✅ └─ "열정적인" 텍스트 검색 → Full-Text Search → ms 응답 ✅

📊 선택지 비교 요약

솔루션	검색 방식	텍스트 검색 성능	관리 오버헤드	적합 용도
OpenSearch ⭐	역색인	✅ 최고 (ms)	낮음	전문 검색
Athena + Parquet	S3 스캔	⚠️ 보통 (초)	낮음	데이터 레이크 분석
Redshift	열 기반 스캔	⚠️ 보통 (초)	중간	대규모 집계 분석
EMR Presto	분산 스캔	❌ 느림 (분)	높음	대용량 배치 처리

#AWS_DEA-C01 #AWS데이터엔지니어 #AmazonOpenSearch #OpenSearchDashboards #전문검색 #메타데이터인덱싱 #역색인 #AmazonAthena #AWSGlue #ApacheParquet #AmazonRedshift #EMRPresto #S3검색 #AWS자격증