6. AWS Opensearch를 활용한 Zero ETL RAG 활용

 

최근 AI 기술이 급속도로 발전하면서, 데이터의 중요성이 어느 때보다도 강조되고 있습니다. 우리는 데이터의 시대에 살고 있다해도 과언이 아닐정도로, 데이터는 새로운 기회의 문을 열어주는 열쇠와 같습니다. 하지만 데이터를 수집하고, 처리하며 분석하는 과정에 상당히 많은 시간과 비용이 소모되고 있습니다. 그래서 많은 기업들은 데이터를 보다 효율적으로 활용하고, AI 기술의 잠재력을 최대한 발휘할 수 있는 방안을 모색하고 있습니다. 그 해답 중 하나가 바로 ＇Zero ETL 파이프라인＇입니다. 데이터 수집과 처리/분석에 들어가는 시간과 비용을 대폭 줄이는 동시에, 데이터 생성 즉시 생성형 AI와 연계하여 활용할 수 있는 구조를 제공 할 수 있습니다. 앞으로 소개할 내용은 이러한 Zero ETL 파이프라인을 통해 조직의 데이터 처리 과정을 간소화하고,생성형 AI를 통해 데이터 통찰력을 어떻게 극대화할 수 있는지를 살펴보고자 합니다.

 

ETL은 추출(Extract), 변환(Transform), 로드(Load)를 의미하는 것으로, 여러 데이터를 생성하는 시스템에서 데이터를 추출하고, 데이터의 형태나 특성 등을 변경하여 데이터 웨어하우스 시스템에 저장함으로써 분석 등에 활용하는 일련의 프로세스를 의미합니다. ETL 파이프라인을 구축하는 것은 데이터 소스에서 데이터를 가져와 데이터 웨어하우스에 공급하는 간단한 프로세스라 생각할 수 있지만, 각 단계를 구성하는 것은 매우 복잡한 절차가 필요합니다.  기술적으로 복잡한 ETL 프로세스에는 데이터 엔지니어, 개발자, 분석가 등 각 관련 분야의 전문 지식이 필요합니다.

ETL 파이프라인을 자세히 나타내면 본 슬라이드의 프로세스와 같은데, ETL 과정 중 데이터 추출은 데이터베이스, CRM 시스템, 파일 등 다양한 소스에서 필요한 데이터를 업데이트 알림, 증분 추출, 전체 추출 등으로 수집하여 일시적인 스테이징 영역에 저장합니다. 스테이징 영역에 저장된 추출 데이터를 비즈니스 요구사항과 분석 목적에 맞게 데이터 중복 제거, 형식 수정, 데이터 결합 및 분할 등으로 변환 과정을 거친 후 변환된 데이터를 최종 목적지인 데이터 웨어하우스나 다른 저장 시스템으로 옮기게 됩니다. 이 때 데이터를 추출, 변환, 로드하는 과정에서 맞춤형 코드 작성이 필요하고, 데이터의 정확성, 일관성을 보장하기 위해 사용자 지정 검증 로직이나 클렌징 코드 작성이 요구될 수 있습니다. 특히 ETL 프로세스에서 데이터 이동 시 복잡한 데이터 매핑 규칙, 데이터 불일치 및 충돌 처리, 오류 처리 및 로깅 메커니즘 구현의 문제로 사용자 지정 코드 생성, 인프라 배포 및 관리, 데이터 소스 변경에 따른 수동 수정 및 재배포 등으로 인해 분석 및 기계 학습 워크로드 실행에 지연이 발생하는 어려움이 있습니다. 또한 파이프라인을 구축하거나 변경하는 데 필요한 시간으로 인해 거의 실시간으로 분석이 필요한 사기 거래 분석, 개인 맞춤형 온라인 광고 같은 실시간 분석 사용에 기존의 ETL은 적합하지 않습니다. 

따라서, 기존의 ETL로는 고객 경험을 개선하는 것이 어렵고 새로운 비즈니스 기회가 손실될 수 있습니다.

 

그래서 나타난 개념이 제로 ETL로 데이터 이동과 변환 과정을 최소화하고, 데이터 관리를 간소화하게 만드는 데이터 통합 접근이 가능해졌습니다. 기존 ETL에서는 데이터를 원본 위치에서 추출하여 변환 과정을 거친 후 각각 용도에 맞는 여러 데이터베이스에 적재하기 위해 별도의 추출/변환 과정이 필요하지만, 제로 ETL은 이러한 데이터 이동을 최소화하거나 제거하여 데이터 처리의 복잡성과 시간을 줄일 수 있습니다. “슬라이드에 보이는 것처럼” 제로 ETL은 하나의 데이터베이스에서 다양한 데이터 소스에 대한 통합된 접근을 제공합니다. 이를 통해 사용자는 한 채널에서 여러 데이터 소스를 쿼리하고, 데이터를 결합하며, 분석을 수행할 수 있습니다. AWS에서는 이 채널을 Redshift로 만들어 aurora, dynamoDB, rds 등 여러 DB 클러스터에 있는 데이터를 Redshift에서 확인 및 분석할 수 있게 되었습니다. 제로 ETL의 이러한 특징으로 인해 ETL 파이프라인 아키텍처를 단순화하고, 데이터 엔지니어링 작업을 줄여 빠른 데이터 통합과 의사 결정을 지원할 수 있으며,

인프라 비용과 유지 관리 오버헤드를 줄일 수 있습니다.

슬라이드에 보여지는 것처럼 AWS에서는 최근 데이터 이동과 관련된 복잡성과 비용을 대폭 줄여주며, 데이터 관리 및 분석을 효율적으로 만들어주는 제로 ETL 통합 서비스 4종을 공개했습니다. 먼저, Amazon RDS MySQL 및 PostgreSQL과 Amazon Redshift 간의 통합을 통해, PostgreSQL과 RDS의 트랜잭션 데이터를 복잡한 ETL 파이프라인 없이도 데이터 분석을 지원하는 데이터 웨어하우스인 Redshift로 이동하는 과정을 간소화함으로써 여러 소스의 데이터 분석을 위한 강력한 기능을 제공할 수 있습니다. 다음으로, Amazon DynamoDB와 Amazon Redshift 간의 통합을 통해서는 DynamoDB의 비관계형 데이터를 Amazon Redshift로 쉽게 이동시켜 비관계형 데이터의 효율적인 활용과 분석 기능을 향상시켰습니다.

마지막으로, DynamoDB와 Amazon OpenSearch Service 간의 통합을 통해 사용자는 DynamoDB 데이터에 저장된 문서 전문 검색 및 벡터 검색을 거의 실시간으로 수행할 수 있습니다. 이는 기업 내부의 문서 검색 및 분석 기능을 크게 향상시킬 수 있습니다. Redshift와 OpenSearch 중심으로 통합된 이러한 제로 ETL 연계 서비스들은 한 채널에서 데이터 소스 간의 통합을 용이하게 하여 새로운 인사이트를 발굴하고, 데이터 기반 의사 결정을 지원할 수 있습니다.

슬라이드에 보여지는 것처럼 Zero ETL과 생성형 AI를 연계 할 경우 데이터 통합과 처리를 간소화하여, 생성형 AI의 기술을 최대한 활용할 수 있는 시스템의 아키텍처는 다음과 같습니다. 여러 데이터 소스에서 정형 및 비정형 데이터, 스트리밍 데이터를 Amazon Kinesis, AWS Glue, Amazon EMR과 같은 서비스를 사용하여 식별, 수집, 처리하고 데이터 레이크 또는 웨어하우스에 전송되는 파이프라인을 구축하는 복잡한 과정 없이 생성형 AI인 Amazon Bedrock과 연계 할 경우 통계적 지식이나 SQL 쿼리 분석 기술 없이도 누구나 고급 분석이 가능해, 비즈니스에 대한 깊이 있는 인사이트와 개선된 고객 경험을 제공할 수 있습니다. Zero ETL과 생성형 AI를 연계하는 이 아키텍처는 다양한 데이터 원천에서 수집된 정보를 바탕으로 별도의 복잡한 과정 없이 생성형 AI 서비스를 통해 수집된 데이터를 거의 실시간으로 쉽게 활용할 수 있는 기반을 마련합니다.

데이터 유형에 따라 Zero ETL 파이프라인과 생성형 AI 연계 활용 방안이 달라질 수 있는데, 첫번째 활용 방안으로 텍스트 기반의 문서를 생성형 AI와 연계해 활용할 수 있는 RAG 아키텍처 입니다. 슬라이드의 아키텍처를 보며 설명드리도록 하겠습니다. RAG는 사용자의 질문과 관련 있는 문서나 데이터를 지식 베이스라 불리는 대규모의 문서 데이터베이스에서 검색하여 검색된 문서의 내용을 바탕으로 정확하고 상세한 답변을 생성하는 방식을 의미합니다. RAG 아키텍처 구성을 위해 조직 내의 방대한 문서들을 숫자로 구성된 벡터로 변환하여 데이터를 벡터 데이터베이스에 저장하게 되면 각 단어의 의미를 수치적으로 표현할 수 있습니다. 벡터 데이터를 저장하고 고급 검색 기능을 지원하는 AWS의 오픈서치 또는 켄드라와 같은 서비스를 활용하여 사용자가 자연어로 생성형 AI 모델에 질의를 하면 벡터 데이터베이스를 즉각적으로 검색하여 관련성 높은 문서를 식별합니다. 벡터 검색 접근법은 질문에 대한 답변을 생성하는 데 있어 기존의 단순한 키워드 매칭을 넘어 문맥적 이해가 가능해 사용자의 질의에 대해 정확한 답변을 제공할 수 있습니다.

 

본 게시글에서는 OpenSearch의 AI/ML 커넥터와 다양한 검색 기능(Dense, Sparse, Hybrid)을 통해 외부 ML 플랫폼(SageMaker, Bedrock 등)과 통합하여 ML 기반 검색 시스템을 구축하고 확장할 수 있는 방안을 설명하고자 합니다.

 

USE CASE

---

1. OpenSearch AI/ML 커넥터 (Bedrock 임베딩 모델) 호출

 

오픈서치(OpenSearch)에 이미 AWS Bedrock LLM모델을 호출하기 위한 AI/ML 커넥터가 생성되어 있는 상태입니다.
커넥터를 다시 생성할 필요 없이, Dev Tools에서 제공된 쿼리를 실행하여 커넥터 ID만 조회하면 됩니다. 이 커넥터 ID는 이후 단계에서 모델 호출이나 설정에 사용됩니다.

POST /_plugins/_ml/connectors/_search
{
  "size": 1,
  "query": {
    "match": {"name": "BEDROCK_TEXT: EMBEDDING"}
  }
}

 

 

2. 임베딩 모델 등록 & 배포

 

텍스트 임베딩 모델을 OpenSearch Service에 등록하고 배포합니다. 확인된 model_id는 추후 semantic search 실행과 ingest pipeline 생성에 사용됩니다.

POST _plugins/_ml/models/_register?deploy=true
{
  "name": "Bedrock Text Embedding",
  "function_name": "remote",
  "description": "Bedrock Text Embedding embeddings model",
  "connector_id": "<connector_id>"
}

 

3. Ingest Pipeline 생성

 

인제스트 파이프라인을 생성하여 데이터 수집 시 텍스트를 벡터 임베딩으로 변환하도록 설정합니다.

먼저, 아래 코드를 통해 임베딩 프로세서를 추가합니다.

• product_description 필드를 텍스트 임베딩 프로세서를 통해 처리하고, 이를 벡터 필드인 product_description_vector에 저장합니다.
• 이후 모든 데이터 수집 시, 이 파이프라인이 자동으로 호출되어 벡터 임베딩을 생성합니다.

 

PUT _ingest/pipeline/ml_ingest_pipeline
{
  "description": "text embedding ingest pipeline",
  "processors": [
    {
      "text_embedding": {
        "model_id": "<model_id>",
        "field_map": {
          "product_description": "product_description_vector"
        }
      }
    }
  ]
}

 

이후 아래 코드를 실행하여 생성된 임베딩을 확인합니다.

POST _ingest/pipeline/ml_ingest_pipeline/_simulate?verbose
{
  "docs": [
    {
      "_source": {
        "product_description": "black jacket for men"
      }
    }
  ]
}

 

 

생성된 인제스트 파이프라인이 데이터 수집 시 자동으로 벡터 임베딩을 생성하여 텍스트 필드와 함께 저장합니다.
product_description_vector 필드에 생성된 임베딩을 사용해 시맨틱 검색을 수행할 수 있습니다.

 

4. k-nn 인덱스 재생성

 

기존 인덱스를 삭제하고 k-NN 검색을 위한 새로운 k-NN 인덱스를 생성합니다. 이 인덱스는 벡터 임베딩을 저장하고 검색을 수행하는 데 사용됩니다.

# 기존 Lexical Search 인덱스 삭제
DELETE demostore-search-index

# 새로운 k-NN 인덱스 생성
PUT demostore-search-index
{
  "settings": {
    "index.knn": true,
    "default_pipeline": "ml_ingest_pipeline"
  },
  "mappings": {
    "_source": {
      "excludes": [
        "product_image"
      ]
    },
    "properties": {
      "image_url": {
        "type": "text"
      },
      "product_description": {
        "type": "text"
      },
      "product_description_vector": {
        "type": "knn_vector",
        "dimension": 1536,
        "method": {
          "engine": "faiss",
          "space_type": "l2",
          "name": "hnsw",
          "parameters": {}
        }
      }
    }
  }
}

 

5. Semantic Search 실행

 

 

시맨틱 검색은 쿼리와 벡터 임베딩 간의 유사성을 기반으로 더 관련성 높은 검색 결과를 제공합니다. 필터링을 추가하면 특정 조건(예: "남성용 제품")을 기준으로 검색 결과를 세부적으로 조정할 수 있습니다.

 

GET demostore-search-index/_search
{
  "query": {
    "neural": {
      "product_description_vector": {
        "query_text": "silver bracelets for men",
        "model_id": "<model_id>",
        "k": 5
      }
    }
  }
}

 

필요 시 필터링을 적용하여 검색 범위를 좁힐 수 있습니다. 아래는 gender_affinity.keyword 필드를 활용하여 남성용 제품만 포함하는 검색 쿼리입니다.

GET demostore-search-index/_search
{
  "query": {
    "neural": {
      "product_description_vector": {
        "query_text": "silver bracelets for men",
        "model_id": "<model_id>",
        "k": 5,
        "filter": {
          "term": {
            "gender_affinity.keyword": "Male"
          }
        }
      }
    }
  }
}

 

6. Bedrock 활용 Hybrid Search 구성

 

하이브리드 검색은 다양한 검색 기능(예: Lexical Search와 Semantic Search)을 단일 검색 쿼리로 결합하여 검색 결과의 품질을 향상시키는 기술입니다.

• Lexical Search: 키워드 중심의 정확한 검색
• Semantic Search: 문맥과 의미를 기반으로 관련성 높은 결과 제공
• Hybrid Search: 두 가지 검색 방식을 결합하여 각 방식의 장점을 극대화

하이브리드 검색 쿼리의 점수를 정규화하고 결합하는 검색 파이프라인을 생성합니다.

• 정규화 방식: min_max (최소-최대 값을 사용해 점수를 스케일링)
• 결합 방식: arithmetic_mean (산술 평균으로 각 하위 쿼리에 동일 가중치 부여)

PUT _search/pipeline/ml_search_pipeline
{
  "description": "Post processor for hybrid search",
  "phase_results_processors": [
    {
      "normalization-processor": {
        "normalization": {
          "technique": "min_max"
        },
        "combination": {
          "technique": "arithmetic_mean",
          "parameters": {
            "weights": [
              0.5,
              0.5
            ]
          }
        }
      }
    }
  ]
}

 

7. Hybrid Query 생성

 

Lexical 검색과 Neural 검색을 결합하여 검색 결과의 관련성을 향상시킵니다. 1단계에서 생성한 검색 파이프라인(ml_search_pipeline)은 각 하위 쿼리에 동일한 가중치(50%)를 부여합니다.

GET demostore-search-index/_search?search_pipeline=ml_search_pipeline
{
  "_source": {
    "exclude": [
      "product_description_vector",
      "product_multimodal_vector",
      "product_image"
    ]
  },
  "query": {
    "hybrid": {
      "queries": [
        {
          "match": {
            "description": {
              "query": "silver bracelets for men"
            }
          }
        },
        {
          "neural": {
            "product_description_vector": {
              "query_text": "silver bracelets for men",
              "model_id": "<model_id>",
              "k": 5
            }
          }
        }
      ]
    }
  },
  "size": 5
}

 

 

8. Hybrid Search 결과 확인

 

Lexical 검색과 Semantic 검색 또는 Multimodal 검색을 결합하여 다양한 하이브리드 검색 방식을 실험합니다.
각 서브쿼리의 가중치를 조정하여 검색 결과가 어떻게 달라지는지 분석합니다.