다음을 통해 공유

Azure의 AI 워크로드용 데이터 플랫폼

  • 아티클

데이터 플랫폼은 원본 데이터를 수집한 다음, 필터링, 집계 및 사용을 위해 준비하여 워크로드 요구 사항을 관리하도록 설계된 통합 기술 집합입니다.

데이터에는 의도한 용도를 기반으로 하는 고유한 특성이 있습니다. 이 문서에서 설명하는 기술 기능을 살펴보기 전에 좋은 데이터 파이프라인 디자인의 원칙을 이해하는 것이 좋습니다. 자세한 내용은 학습 데이터 디자인 및 접지 데이터 디자인을 참조하세요.

또한 플랫폼은 데이터가 파이프라인의 특정 지점에 있을 때 스토리지 요구 사항을 충족합니다. 워크로드가 복잡하고 대규모 데이터를 처리하는 경우 다양한 구성 요소 간에 파이프라인 작업을 분산할 수 있습니다. 더 간단한 사용 사례의 경우 이러한 결합된 기능을 제공하는 저장소의 원본 데이터를 사용할 수 있는지 여부를 평가합니다.

데이터 플랫폼에 대해 지나치게 복잡한 아키텍처를 설계하지 않도록 다음 질문을 스스로에게 묻습니다. 가능하면 간단하게 유지하는 것이 항상 가장 좋습니다.

  • 애플리케이션이 단일 원본에서 데이터를 수집하여 예상 예측 능력을 가질 수 있나요?
  • 데이터 저장소의 초기 선택은 데이터 웨어하우징 기능을 지원하나요?
  • 원본 데이터가 이미 AI 검색에 최적화되어 있나요?

이러한 질문에 '예'라고 대답하면 애플리케이션이 데이터 원본에 직접 액세스할 수 있도록 하여 아키텍처를 간소화할 수 있습니다. 이 방법을 사용하면 데이터 수집, 분석 저장소 통합 및 외부 데이터 처리와 같은 빅 데이터 아키텍처 구성 요소가 필요하지 않습니다. 원본 데이터베이스가 필요한 검색을 처리할 수 있는 경우 검색 인덱스 기능을 원본 데이터베이스에 직접 통합하는 것이 실용적인 방법일 수 있습니다. 원본이 새로운 요구를 충족하기 위해 비용 효율적으로 확장할 수 있는지 확인합니다.

예를 들어 Azure Cosmos DB는 벡터 검색을 지원하므로 다른 인덱스가 필요하지 않을 수 있습니다. 또 다른 사용 사례는 검색 작업의 엔드포인트로 읽기 복제본을 사용하는 것입니다. 읽기 복제본이 있는 SQL 데이터베이스의 경우 이러한 복제본으로 직접 검색하면 성능을 최적화할 수 있습니다. 데이터베이스의 기본 제공 기능을 활용하여 아키텍처를 최대한 간소화합니다.

대규모 워크로드에 대한 데이터 플랫폼 아키텍처는 더 복잡합니다.

여러 데이터 원본에서 데이터를 수집하고 다양한 플랫폼에서 검색을 오케스트레이션하면 복잡하고 비효율적일 수 있습니다. 또한 일부 추출, 변환 및 로드(ETL)가 여전히 필요합니다. ELT(추출, 로드 및 변환); 또는 EL(추출 및 로드) 프로세스를 사용하여 데이터 저장소 내의 데이터를 재구성합니다. 데이터에 더 많은 처리가 필요하므로 시나리오가 더 복잡해집니다. 수집에서 서비스 쿼리에 이르는 엔드 투 엔드 파이프라인을 처리하려면 아키텍처에 많은 구성 요소를 추가해야 합니다. 많은 빅 데이터 기술은 고도로 전문화되고 이러한 처리 작업을 효과적으로 처리하도록 빌드되었습니다.

이러한 기술 중 하나는 검색 인덱스입니다. 별도의 인덱스를 추가하는 주요 이점은 쿼리를 효율적으로 관리하고 처리량이 많은 대량의 데이터를 처리하는 기능입니다. 이 함수는 원래 데이터 원본에서 AI 기능을 오프로드하여 인덱스가 주 함수에 집중하여 쿼리를 처리할 수 있도록 합니다.

특정 기능 및 목적에 따라 플랫폼을 선택하고 기능 및 기술 요구 사항을 고려합니다. 복잡한 사용 사례를 처리하기 위해 아키텍처가 진화하는 경우 집계된 데이터 저장소, 처리 파이프라인 및 검색 인덱스에 대해 다음 섹션에 집중합니다.

권장 사항

다음은 이 문서에 제공된 권장 사항의 요약입니다.

추천 설명
안전하고 성능이 좋은 비용 효율적인 데이터 저장소를 빌드합니다. 데이터 플랫폼의 핵심 부분은 여러 원본의 데이터를 집계하고 다양한 통합 작업과 통합할 수 있는 데이터 저장소입니다. 이렇게 하면 워크로드가 대규모로 수행됩니다. 비용 효율적인 배포를 보장하려면 데이터 저장소의 다양한 기능 및 비기능적 요구 사항을 검토해야 합니다.

▪ 집계된 데이터를 저장하기 위한 고려 사항
데이터 수집 및 처리에 대한 모범 사례를 따릅니다. 고품질 데이터는 워크로드의 안정성과 최종 사용자 환경을 개선하는 데 도움이 됩니다. 고품질 막대를 유지하는 데 도움이 되는 효율적인 수집 및 데이터 전환 프로세스를 빌드하기 위한 주요 모범 사례뿐만 아니라 워크로드의 요구 사항을 고려합니다.

▪ 데이터 처리에 대한 고려 사항
신뢰할 수 있는 관련 검색 인덱스를 디자인합니다. 즉석 및 유사 쿼리를 효율적으로 처리하여 쿼리가 정확하지 않은 경우에도 사용자 기반에 관련 결과를 제공하는 고성능의 쓰기-한 번 읽기-다 데이터 저장소를 목표로 합니다.

▪ 검색 인덱스에 대한 고려 사항
기능 데이터 저장소가 대규모로 수행되도록 합니다. 워크로드의 기능 요구 사항에 따라 기능 데이터 저장소(예: 오프라인 추론)를 만들어야 할 수 있습니다. 지정된 함수를 염두에 두고 데이터 저장소를 만들고 함수에 대한 모범 사례를 적용하는 것이 중요합니다.

▪ 기능 저장소에 대한 고려 사항
▪ 오프라인 추론 데이터 저장소에 대한 고려 사항

집계된 데이터를 저장하기 위한 고려 사항

AI 워크로드에서 데이터는 이러한 단계 간에 워크플로를 오케스트레이션하는 파이프라인의 도움을 받아 다양한 스토리지 및 처리 단계를 진행합니다. 한 가지 주요 단계는 여러 원본에서 수집 및 집계되는 데이터를 포함하는 데이터 저장소입니다. 데이터가 학습 또는 인덱싱에 적합한 상태에 도달할 때까지 처리를 수행하려면 이 저장소가 필요합니다. 주요 초점은 데이터가 원본을 정확하게 반영하는지 확인하는 것입니다.

참고 항목

다른 방법은 데이터 원본에 직접 액세스하는 것입니다. 그러나 이 방법은 원본 시스템에 AI 기능을 오버로드할 수 있으므로 성능 문제가 발생할 수 있습니다. 데이터 액세스 문제도 있을 수 있습니다. 이러한 문제를 방지하려면 이 저장소에 데이터를 복사하는 것이 좋습니다.

이 저장소의 데이터 플랫폼은 데이터 원본에 적용되는 보안 표준을 충족하고 비용 효율적이며 ETL, ELT 및 EL 처리 작업과의 통합을 지원해야 합니다. 옵션은 데이터 볼륨에 따라 기본 스토리지에서 빅 데이터 기술에 이르기까지 다양합니다. 충분한 안정성과 성능을 달성하는 데 도움이 되는 경제적인 스토리지를 선택합니다.

다음 섹션에서는 데이터 저장소 기술을 선택할 때 고려해야 할 기능에 대한 지침을 제공합니다. 자세한 내용은 데이터 처리 파이프라인을 참조 하세요.

기능 요구 사항

  • 플랫폼이 다양한 데이터 형식을 처리할 수 있나요?

    데이터 저장소는 다양한 데이터 형식을 저장하고 필요한 경우 다른 형식으로 변환할 수 있어야 합니다.

    수집 파이프라인이 관계형 데이터베이스 및 Parquet 파일에서 데이터를 원본으로 지정하여 구조화된 데이터와 반구조화된 데이터를 모두 지원한다고 가정합니다. 스키마 정의에 따라 관계형 데이터를 Parquet 형식으로 변환하려고 합니다. 데이터 플랫폼에는 사용자 지정 코드를 작성하지 않고도 해당 변환을 수행할 수 있는 기본 제공 기능이 있어야 합니다.

  • 여러 버전의 데이터를 저장해야 합니까?

    데이터 값과 스키마는 시간이 지남에 따라 변경될 수 있으며 여러 버전의 데이터를 관리하는 것이 중요해집니다.

    원본 시스템은 일반적으로 기록 데이터가 아닌 현재 데이터만 저장합니다. 기록 데이터를 유지하는 것이 중요한 경우 원본 시스템에서 큰 데이터 집합을 복제해야 할 수 있습니다. 이 경우 버전 관리가 기록 데이터에서 현재 데이터를 명확하게 구분할 수 있습니다.

    경우에 따라 다른 사용 사례에 대한 데이터 복사본을 유지 관리해야 할 수 있습니다. 이 시나리오를 지원하려면 데이터를 포크해야 할 수 있습니다. 각 포크는 독립적으로 변경하여 품질과 유용성을 향상시킬 수 있습니다. 데이터 플랫폼은 해당 포크의 적절한 버전 관리를 유지할 수 있어야 합니다.

    데이터 플랫폼은 기록 컨텍스트를 제공하기 위해 시간이 지남에 따라 데이터 버전을 저장할 수 있어야 합니다. 이 contetxt는 단일 시점이 아닌 여러 관찰을 제공하므로 AI 모델을 처리하고 학습하는 데 유용합니다.

  • 플랫폼에 기본 제공 데이터 수명 주기 관리 기능이 있나요?

    DLM(데이터 수명 주기 관리)은 데이터 수집, 스토리지, 사용량, 보관 및 폐기와 같은 단계를 사용하여 데이터를 생성에서 삭제까지 관리하는 프로세스입니다.

    DLM이 없으면 데이터가 제어할 수 없게 증가하여 품질 계층을 통해 이동하면서 여러 복사본이 생성되는 경우가 많습니다. 데이터 플랫폼에는 무제한 데이터 증가를 방지하기 위한 DLM 기능이 있어야 합니다.

    이 시나리오를 고려합니다. 전처리 단계는 학습 목적으로 허용되는 품질에 도달할 때까지 데이터를 구체화하기 위해 반복되어야 합니다. 데이터 플랫폼은 데이터의 중간 복사본을 삭제할 수 있어야 합니다.

    경우에 따라 규제 감사를 위해 데이터를 보존해야 할 수 있습니다. 데이터 플랫폼에는 자주 액세스하지 않는 데이터에 대한 콜드 스토리지 기능이 있어야 더 저렴한 비용으로 보관할 수 있습니다.

  • 플랫폼이 데이터 거버넌스 기능을 지원하나요?

    감사 가능성은 AI 워크로드의 중요한 측면입니다. 데이터 저장소는 데이터 액세스를 추적하고, 개인 정보를 보장하며, 데이터 원본을 이해할 수 있는 감사 내역을 유지해야 합니다.

    데이터 사전 기능을 사용하여 메타데이터, 데이터 형식, 목적 및 계보를 관리할 수 있습니다. 이 기능은 여러 원본에서 데이터를 수집할 때 특히 중요합니다.

  • 프로덕션 데이터를 사용하여 교육을 수행할 계획입니까?

    배포에는 모델 배포 및 코드 배포의 두 가지 방법이 있습니다. 모델 배포에서 프로덕션 데이터는 개발에 사용되므로 엄격한 보안 조치가 필요합니다. 코드 배포에서 모델은 프로덕션 상태일 때까지 프로덕션 데이터를 볼 수 없습니다. 코드 배포는 개발 환경의 보안 문제를 간소화하지만 컴퓨팅 비용을 증가시킬 수 있습니다. 어떤 방법을 선택하든 데이터 플랫폼은 개발 및 프로덕션을 위한 별도의 환경을 지원해야 합니다.

  • 주요 기능 기능보다 편의 기능의 우선 순위를 지정하고 있나요?

    AI 또는 기계 학습을 위한 데이터 플랫폼을 선택하는 경우 Notebook 기능에만 의존하지 마세요. Notebook은 예비 데이터 분석에 유용하지만 결정 요소가 되어서는 안 됩니다. Notebook에 대한 컴퓨팅 리소스는 일반적으로 집계 데이터 저장소의 범위를 벗어집니다. 일반적으로 Azure Machine Learning과 같은 다른 리소스와 통합됩니다.

비기능적 요구 사항

  • 얼마나 많은 데이터를 저장할 것으로 예상합니까?

    AI 워크로드는 많은 데이터를 생성합니다. 볼륨은 여러 버전과 추가 메타데이터로 인해 크게 증가할 수 있습니다.

    스토리지 및 처리량에 대한 확장성이 중요합니다. 데이터 플랫폼은 데이터 볼륨을 처리하고, 동시 쓰기를 관리하고, 성능 저하 없이 개별 쓰기 성능을 보장하는 동안 수집 파이프라인의 데이터를 효율적으로 사용해야 합니다. 이러한 조건은 저장소를 읽고, 처리하고, 심지어 저장소에 다시 쓰는 처리 파이프라인에도 적용됩니다.

    결정을 내릴 때 수집 및 처리가 동시에 발생하는 경우가 많기 때문에 전체 프로세스를 고려합니다. 디자인은 빈번한 데이터 이동 및 처리를 관리할 수 있어야 합니다. 데이터 플랫폼은 데이터를 효과적으로 처리하기 위해 높은 수준의 병렬 처리를 제공해야 합니다.

    플랫폼 기술은 읽기 및 쓰기 작업의 처리량 및 성능에 대한 의미 있는 인사이트를 제공하는 원격 분석을 내보내야 합니다.

  • 이 데이터 저장소는 워크로드의 안정성 목표에 기여하는 중요한 구성 요소인가요?

    여러 인스턴스를 사용하여 안정성과 확장성을 모두 향상시키는 데이터 저장소를 선택합니다. 빅 데이터 저장소에는 인스턴스 간에 데이터 처리를 오케스트레이션하는 기본 제공 컨트롤러가 있는 경우가 많습니다. 한 복사본이 실패하면 다른 복사본을 사용할 수 있습니다.

    데이터가 올바르지 않거나 액세스할 수 없는 경우 해당 용도로 작동하지 않습니다. 데이터 플랫폼은 내구성을 보장하고 데이터가 그대로 유지되도록 해야 합니다. 데이터를 쿼리하는 API에 액세스할 수 있는지 확인합니다. 또한 백업 기능이 있는 데이터 저장소를 고려해 보세요.

    일반적으로 이 데이터를 백업할 필요가 없습니다. 그러나 매번 처음부터 데이터를 집계하는 비용이 상당히 높은 경우 백업에서 데이터를 리하일링하는 것이 좋습니다.

  • 비용 제약 조건이 있나요?

    데이터 안정성 및 성능이 충분한 경우 비용 영향을 고려합니다.

    시스템은 한 번 쓰기에 최적화되어야 하며, 데이터 스토리지에 대한 과다 지출을 방지하기 위해 많은 데이터를 읽어야 합니다. 학습 또는 접지 데이터는 중요하지만 즉각적인 응답성이 필요한 프로덕션 데이터베이스처럼 중요하지는 않습니다. 투자 수익률을 극대화하기에 충분한 효율성으로 비용의 균형을 맞추는 데 중점을 두고 있습니다.

이전 요구 사항은 DLM, 품질 계층, 관찰 가능성 및 다양한 파일 형식에 대한 지원을 제공하므로 데이터 레이크 사용을 자연스럽게 고려할 수 있습니다. 워크로드가 이미 데이터 레이크를 사용하는 경우 해당 리소스를 활용하여 AI 요구 사항을 충족합니다. 또는 일부 수준의 DLM, 모니터링 기능 및 높은 트랜잭션 속도를 제공하는 Azure Blob Storage와 같은 다른 스토리지 옵션을 선택할 수 있습니다.

데이터 처리에 대한 고려 사항

유틸리티 다운스트림을 늘리려면 집계 데이터 저장소의 데이터를 처리해야 합니다. ETL 파이프라인은 다음 지점에서 가장 중요한 이 작업을 수행합니다.

  • 수집 계층

    파이프라인은 다양한 원본에서 데이터를 수집하고 집계 데이터 저장소로 이동하는 작업을 담당합니다. 이 프로세스 중에 파이프라인은 일반적으로 기본 전처리를 수행하며 쿼리 가능한 형식으로 데이터를 구조화할 수도 있습니다.

    사용자 지정 코드의 필요성을 최소화하려면 이 책임의 상당 부분을 데이터 플랫폼으로 오프로드하는 것이 좋습니다. 기술을 선택할 때 모델 학습 및 확대를 지원하는 데 필요한 ETL 특성을 고려합니다.

  • 처리 계층

    집계 데이터 저장소의 데이터는 인덱싱 또는 모델 학습 사용 사례에 사용하기 전에 광범위한 처리를 거칩니다. 처리 파이프라인에는 수집 파이프라인과 유사한 수준의 안정성 및 크기 조정이 필요합니다. 주요 차이점은 데이터에서 수행되는 처리 유형입니다.

    이 프로세스에는 데이터의 상당한 범위 지정 및 재구성이 포함됩니다. 이 프로세스에는 엔터티 인식, 데이터 집합에 추가 데이터 통합 및 조회 수행과 같은 작업이 포함됩니다. 이 프로세스에는 불필요한 데이터를 삭제하고 데이터 오케스트레이션 플랫폼을 통해 데이터 논리를 적용하는 것도 포함될 수 있습니다.

데이터 처리 단계에서는 다양한 출력을 생성할 수 있으며, 이 출력은 서로 다른 의도에 대해 서로 다른 대상에 배치됩니다. 주요 목표는 최종 대상에서 사용할 수 있도록 집계된 데이터 저장소에서 데이터를 준비하고 전송하는 것입니다. 소비자는 필요할 때 데이터를 끌어오거나 처리 계층이 준비되면 데이터를 푸시할 수 있습니다.

참고 항목

기계 학습 및 생성 AI의 컨텍스트에서 ETL, ELT 및 EL 프로세스를 구분하는 것이 중요합니다. 기존 ETL은 데이터 웨어하우징 및 개체 관계형 매핑에 매우 중요하며, 스키마 제한으로 인해 대상 시스템에 로드하기 전에 데이터를 변환해야 합니다. ELT에는 데이터를 추출하고, 데이터 레이크로 로드한 다음, Python 또는 PySpark와 같은 도구를 사용하여 변환하는 작업이 포함됩니다. 생성 AI, 특히 RAG(검색 보강 생성)의 경우 프로세스에는 문서를 먼저 스토리지에 추출하고 로드한 다음 청크 또는 이미지 추출과 같은 변환이 수반되는 경우가 많습니다.

다음 섹션에서는 ETL 기능이 있는 데이터 처리 기술을 선택할 때 고려해야 할 지침을 제공합니다.

기능 요구 사항

  • 데이터 원본에 연결하기 위한 지원은 무엇인가요?

    처리해야 하는 데이터는 관계형 데이터베이스, 빅 데이터 원본 또는 다양한 스토리지 솔루션에 저장될 수 있습니다.

    대부분의 데이터 처리 기술은 코드를 작성하지 않고 다양한 데이터 원본에 연결할 수 있는 미리 빌드된 통합을 지원합니다. 커넥터에는 원본에서 싱크로 데이터를 복사하고, 조회를 수행하고, 일종의 데이터 거버넌스를 적용하는 기능과 같은 기능이 있습니다. 불필요한 코딩을 방지하기 위해 끌어서 놓기 기능을 제공하는 도구가 있습니다.

    예상 데이터 원본과 쉽게 통합할 수 있는 데이터 플랫폼을 선택합니다.

  • 플랫폼이 다양한 데이터 형식을 처리할 수 있나요?

    데이터는 데이터베이스 및 JSON과 같은 구조화된 데이터, 이미지 및 문서와 같은 구조화되지 않은 데이터 또는 사물 인터넷 디바이스의 데이터와 같은 스트리밍 데이터와 같은 다양한 형식으로 제공됩니다. 파이프라인은 예상된 파일 형식을 처리할 수 있어야 합니다.

  • 플랫폼은 데이터 준비 및 범위 조정을 위한 기능을 제공하나요?

    학습, 미세 조정 또는 인덱싱에 적합할 때까지 학습 또는 확대에 사용하려는 데이터를 처리해야 합니다. 데이터 디자인 전략은 요구 사항을 명시적으로 간략하게 설명해야 합니다.

    다음 문서에서는 특정 고려 사항을 설명합니다.

    기본 정리의 일환으로 플랫폼은 중복 항목을 제거하고 누락된 값을 채우며 수집 중에 불필요한 노이즈를 제거합니다. RAG 패턴 구현과 같은 특정 사용 사례의 경우 청크를 소문자로 사용하는 것이 좋습니다.

    이러한 전처리 단계가 필요하지만 플랫폼은 요구 사항에 특정한 풍부한 데이터 조작도 지원해야 합니다. 이 프로세스에는 데이터 로드, 범위 지정 및 변환이 포함됩니다. 특정 모델의 경우 플랫폼은 문서 인텔리전스 또는 기타 AI 도구와 같은 문서 분석을 위해 외부 원본을 쿼리할 수 있어야 합니다. 이 작업은 데이터 준비 및 데이터 보강에 필요합니다.

    데이터 저장소가 이러한 수준의 처리를 지원하는 경우 다른 곳으로 이동하지 않고 저장소에서 이 단계를 지역화할 수 있습니다. 그렇지 않으면 Azure Databricks 또는 Azure Data Factory와 같은 외부 기술이 필요합니다. 이러한 기술은 데이터를 이동하고 필터링, 누락 값 채우기 및 문자열 대/소문자 표준화와 같은 조작을 수행하는 데 적합합니다. 더 복잡한 작업의 경우 일반적으로 작업 호스팅 플랫폼이 필요합니다. 빅 데이터 오케스트레이션에 Spark 풀을 사용할 수 있습니다.

    특정 사용 사례에서는 이 책임을 데이터 소비자에게 외부화할 수 있습니다. 예를 들어 기계 학습을 사용하는 AI 모델은 사용자 지정 Python 코드를 사용하여 데이터를 읽고 조작하고 쓰는 작업 처리 기능을 제공합니다.

    또 다른 예로 RAG 구현이 있습니다. 일반적인 처리 단계는 문서가 여러 청크로 나뉘고 각 청크가 인덱스의 행이 되는 청크 분할입니다. 또한 이러한 청크에 대해 OpenAI 서비스에서 자주 생성하는 포함 항목도 저장합니다. AI 검색에서 이 프로세스는 OpenAI 또는 Azure AI Search를 사용하여 인덱싱 워크플로 내에서 오케스트레이션됩니다.

  • 워크플로를 관리하기 위한 기본 제공 오케스트레이터가 있나요?

    처리 작업은 모듈식이며 작업으로 실행됩니다. 플랫폼에는 워크플로를 단계 또는 작업으로 분해하는 오케스트레이션 기능이 있어야 합니다. 각 작업은 독립적으로 정의, 실행 및 모니터링되어야 합니다.

    복잡한 워크플로에서 특정 단계는 이전 단계의 성공적인 완료에 따라 달라집니다. 오케스트레이터는 작업 종속성을 처리하고 작업이 올바른 순서로 완료되었는지 확인해야 합니다.

    데이터 디자인은 반복적인 프로세스이므로 오케스트레이터 도구는 워크플로를 쉽게 수정할 수 있을 만큼 유연해야 합니다. 코드의 상당 부분을 다시 작성하지 않고도 새 단계를 삽입하거나 기존 단계를 조정할 수 있어야 합니다.

    Data Factory는 데이터 워크플로를 관리하기 위한 다양한 기능 집합을 제공하기 때문에 인기 있는 선택입니다. Azure Databricks는 복잡한 워크플로를 관리하고 작업을 예약하고 모니터링할 수도 있습니다. 비용 영향도 고려해야 합니다. 예를 들어 Azure Databricks 기능은 광범위할 수 있지만 비용이 많이 듭니다. Apache NiFi와 같은 오픈 소스 대체 옵션은 비용 효율적일 수 있습니다.

    궁극적으로 선택하는 도구는 조직에서 허용하는 항목과 워크로드 팀이 편안하게 사용할 수 있는 기술에 따라 달라집니다.

비기능적 요구 사항

처리 파이프라인을 선택하는 경우 처리량과 관찰 가능성의 균형을 맞추는 것이 중요합니다. 파이프라인은 충분한 기간 내에 모델 또는 인덱스에 필요한 데이터를 안정적으로 처리하고 배치해야 합니다. 현재 요구 사항을 지원할 수 있을 만큼 가벼우며 향후 성장을 위해 확장할 수 있어야 합니다. 팀은 나중에 기술적인 문제를 피하기 위해 플랫폼을 미래 지향하는 데 필요한 양을 결정해야 합니다. 주요 고려 사항에는 데이터 수집 빈도 및 볼륨, 프로세스의 안정성 및 문제를 신속하게 모니터링하고 해결하기 위한 관찰성의 필요성이 포함됩니다.

  • 얼마나 많은 데이터를 수집할 것으로 예상합니까?

    수집 및 처리 단계의 경우 작업 처리에 대한 플랫폼의 확장성 및 속도를 고려합니다. 예를 들어 인덱스 또는 모델 학습을 위해 매일 10테라바이트의 데이터를 로드해야 합니다. 데이터 수집 플랫폼은 해당 볼륨과 예상 처리량을 처리할 수 있어야 합니다. 이 경우 이러한 부하에서 실패할 수 있으므로 Azure Logic Apps를 사용하는 것이 불가능할 수 있습니다. 대신 Data Factory는 이러한 데이터 처리 규모에 더 적합합니다.

    높은 볼륨을 처리하는 한 가지 방법은 병렬 처리를 통해 보다 효율적인 데이터 처리 및 처리를 허용하기 때문입니다. Azure Databricks와 같은 플랫폼은 동일한 작업에 대해 여러 인스턴스를 만들고 부하를 효율적으로 배포하여 작업을 오케스트레이션할 수 있습니다.

    또한 허용되는 대기 시간과 작업의 복잡성을 고려합니다. 예를 들어 데이터 정리에는 잘못된 필드의 유효성을 검사하고 대체하거나 중요한 정보를 마스킹하는 작업이 포함됩니다. 이러한 작업은 기본적으로는 각 행이 개별적으로 처리되므로 상당한 리소스가 필요하며, 이로 인해 전체 시간이 늘어나게 됩니다.

  • 필요한 모니터링 기능은 무엇인가요?

    데이터 처리 파이프라인에는 모니터링 기능이 있어야 하며 파이프라인의 성능 및 작업 상태에 대한 인사이트를 제공해야 합니다.

    작업의 진행률을 추적할 수 있어야 합니다. 파이프라인이 부분적으로 완료되지 않거나 완료되지 않는 데이터 정리 작업을 실행한다고 가정합니다. 모델이 학습되는 데이터의 품질에 다운스트림 영향을 줄 수 있으며 예측 성능에 영향을 줄 수 있습니다.

    워크로드의 다른 구성 요소와 마찬가지로 데이터 파이프라인에서 로그, 메트릭 및 경고를 사용하도록 설정하여 해당 동작을 이해해야 합니다. 성능 메트릭을 수집하고 분석하여 효율성 및 안정성 측면을 이해합니다.

    기본 제공 원격 분석의 간격을 식별하고 구현해야 하는 추가 모니터링을 결정합니다. 이 모니터링에는 사용자 지정 로깅 또는 메트릭을 추가하여 작업 단계에 대한 특정 세부 정보를 캡처하는 작업이 포함될 수 있습니다.

  • 데이터 처리 플랫폼의 안정성은 얼마나 기대되나요?

    데이터 처리 파이프라인의 안정성은 플랫폼 선택에 따라 달라집니다. Logic Apps에는 오케스트레이션 기능이 있지만 Data Factory만큼 안정적이지 않을 수 있습니다. AKS(Azure Kubernetes Service) 클러스터에서 호스트되는 Data Factory는 안정성 특성이 다를 수 있습니다.

    단일 인스턴스 설정은 실패 지점으로 간주됩니다. 요구 사항을 충족하기 위해 여러 인스턴스와 같은 안정성 기능을 지원하는 플랫폼을 선택합니다.

    플랫폼은 복원력 기능도 지원해야 합니다. 예를 들어 오케스트레이터는 실패한 작업을 자동으로 다시 시도해야 하므로 수동 다시 시작이 필요하지 않습니다.

    일괄 처리는 데이터 새로 고침 및 대기 시간 요구 사항에 따라 추론보다 신뢰성이 낮을 수 있습니다. 매주 학습이 발생하고 처리에 하루가 걸리는 경우 재시도할 충분한 시간이 있기 때문에 가끔 오류가 허용됩니다.

  • 비용 제약 조건이 있나요?

    데이터 처리 파이프라인의 비용 효율성을 고려할 때 불필요한 비용 없이 요구 사항을 충족하는 솔루션을 선택하는 것이 중요합니다. 요구 사항이 Azure Databricks의 고급 기능을 정당화하지 않는 경우 Data Factory와 같은 보다 경제적인 옵션으로 충분할 수 있습니다. 또한 Apache Airflow 또는 Apache NiFi와 같은 오픈 소스 도구는 저렴한 비용으로 강력한 기능을 제공할 수 있습니다. 핵심은 필요하지 않은 기능에 대한 과다 지출을 방지하고 기능과 비용 효율성의 균형을 맞추는 플랫폼을 선택하는 것입니다.

  • 워크플로 및 처리하는 데이터에 대한 보안 요구 사항은 무엇인가요?

    보안, 개인 정보 보호 및 데이터 보존 요구 사항에 대해 명확히 설명합니다. 예를 들어 지리적 규제 요구 사항을 고려합니다. 특정 지역 내에서 데이터가 저장 및 처리되도록 하여 데이터 보존 요구 사항을 준수합니다. 지역 규정 준수 규정을 충족하기 위해 유럽 및 미국용 파이프라인과 같은 다른 지역에 대해 별도의 파이프라인을 실행해야 할 수 있습니다.

    데이터 파이프라인 플랫폼은 권한 있는 ID만 워크플로 내의 특정 작업 또는 단계에 액세스할 수 있도록 ID 및 액세스 관리를 지원해야 합니다. 예를 들어 ETL 프로세스가 여러 워크플로로 구성되고 그 중 하나가 기밀 데이터를 처리하는 경우 플랫폼은 다른 워크플로에 대한 액세스를 제한하면서 액세스할 수 있도록 허용해야 합니다. 이 기능은 다양한 데이터 민감도 수준에 대해 별도의 플랫폼을 요구하지 않고도 보안 요구 사항을 충족하는 데 도움이 됩니다. 이상적으로 플랫폼은 효율적이고 안전한 데이터 관리를 가능하게 하는 격리를 기본적으로 지원해야 합니다.

데이터 처리 파이프라인은 검색 인덱스 또는 모델 학습 파이프라인에 데이터를 출력할 수 있습니다. 사용 사례에 따라 검색 인덱스 또는 기능 저장소의 섹션을 참조하세요.

검색 인덱스에 대한 고려 사항

검색 인덱스는 프롬프트와 함께 모델 유추 엔드포인트로 보낼 컨텍스트 또는 접지 데이터를 저장하도록 설계되었습니다. 인덱스 쿼리와 유추 엔드포인트 호출은 모두 동일한 클라이언트 HTTP 요청을 서비스하는 컨텍스트에서 수행됩니다. 오프라인 및 일괄 처리 작업을 처리하는 ETL 프로세스와 달리 이 인덱스는 고성능 및 안정성이 필요한 실시간 추론을 지원합니다. AI 쿼리용으로 전문화되어 있으며, 빅 데이터 저장소의 일반적인 기능이 아닌 키워드 인덱싱 및 필터링과 같은 기능을 제공합니다. 즉석 및 유사 쿼리를 지원하는 고성능 의 쓰기-한 번 읽기-다 데이터 저장소를 만드는 것이 목표입니다. 이 데이터 저장소는 정확한 쿼리 없이 관련 결과를 제공할 수 있습니다.

기능 요구 사항

  • 검색 인덱스가 지원하는 검색 유형은 무엇인가요?

    시스템에서 수신하는 쿼리는 기본적으로 검색이며 인덱스는 다양한 검색 기능을 지원해야 합니다. RAG의 경우 데이터가 검색에 사용되는 계산된 벡터 또는 포함으로 저장되므로 벡터 검색을 사용할 수 없습니다.

    벡터 검색은 강력하며 필터링 및 전체 텍스트 검색과 결합하면 검색 인덱스의 효율성이 향상됩니다. 데이터 디자인은 벡터, 전체 텍스트 검색, 필터링 및 지리적 위치와 같은 특수 데이터 형식과 같은 이러한 유형의 검색을 결합하는 것을 고려해야 합니다.

    데이터 디자인은 이러한 요구 사항을 명시적으로 명시해야 합니다. 자세한 내용은 데이터 디자인의 효율적인 쿼리를 참조 하세요.

  • 인덱스가 다중 모드 데이터를 지원하나요?

    다중 모드 데이터를 지원하는 인덱스 기술을 선택합니다. 예를 들어 AI 검색은 전자 메일을 분석하고, 그 안에 있는 이미지를 벡터로 변환하고, 인덱스에 설명을 저장할 수 있습니다. 이 함수를 사용하여 이미지, 비디오 및 오디오 파일을 비롯한 다양한 콘텐츠 형식을 검색합니다.

  • 데이터 원본의 데이터가 변경되면 인덱스가 자동 업데이트 기능을 지원하나요?

    자동 업데이트 기능이 있는 인덱스 선택 사용할 수 없는 경우 인덱스 변경 내용을 수동으로 검색하고 푸시해야 합니다. 이러한 기능을 사용하면 인덱서가 데이터 원본의 변경 내용을 감지하고 업데이트를 자동으로 끌어올 수 있습니다. 이 책임을 플랫폼에 오프로드하면 운영 오버헤드를 줄이고 유지 관리 프로세스를 간소화할 수 있습니다.

비기능적 요구 사항

  • 인덱스가 대량의 데이터를 사용하여 수행할 수 있나요?

    인덱스는 대량의 데이터를 처리하고, 확장 가능하며, 많은 검색 워크로드에 대해 잘 수행될 수 있어야 합니다. 인덱스는 원시 데이터와 연결된 모든 메타데이터, 보강 및 엔터티를 저장합니다. RAG 패턴의 컨텍스트에서 여러 청크로 분할된 단일 문서는 데이터 볼륨이 크게 증가할 수 있습니다.

  • 인덱스가 기본 제공 안정성 기능을 가지고 있나요?

    유추 엔드포인트의 안정성 또는 모델과 데이터 저장소 간의 맞춤을 고려합니다.

    검색 프로세스에는 데이터 저장소 쿼리 및 추론 엔드포인트 쿼리의 두 단계가 포함됩니다. 두 단계 모두 비슷한 안정성 특성을 가져야 합니다. 두 구성 요소 간에 안정성 목표의 균형을 유지하여 검색 효율성을 보장합니다.

    복원력을 보장하기 위해 워크로드는 예상 동시 사용자 수를 지원하고 트래픽 급증을 처리하기에 충분한 대역폭을 가져야 합니다. 이상적으로 플랫폼은 영역 중단에서 살아남아야 합니다.

    데이터 플랫폼은 추론에 손상된 인덱스의 사용을 방지하도록 설계되어야 합니다. 이러한 경우 인덱스를 쉽게 다시 작성할 수 있어야 합니다. 또한 인덱스는 인덱스 교환 중 가동 중지 시간을 최소화하기 위해 별칭과 같은 기능을 사용하여 인덱스 간에 안정적인 교환을 지원해야 합니다. 이 기능이 없으면 인덱스의 백업을 사용해야 할 수 있습니다. 백업 관리는 더 복잡합니다.

    워크로드 관점에서 잠재적인 오류 모드 또는 제한과 같은 스트레스 지표를 이해합니다. 예를 들어 시스템은 일반적으로 50명의 동시 사용자를 지원할 수 있지만 백그라운드 작업으로 실행되는 다시 인덱싱 프로세스 중에는 30명의 사용자만 지원할 수 있습니다. 이 경우 백그라운드 작업의 타이밍이 중요해집니다. 인덱스의 처리량을 평가할 때 프런트 엔드 쿼리와 백 엔드 작업을 모두 포함합니다.

  • 이 기술의 주요 비용 동인은 무엇입니까?

    비용을 모델링할 때 데이터 볼륨, 쿼리 수 및 인덱스의 예상 처리량과 관련된 비용을 예측합니다. 인덱스는 가격 책정이 추상화된 PaaS(Platform as a Service)입니다. 사용하지 않는 용량 또는 기능에 대한 초과 지급을 방지하기 위해 연구 계층 및 해당 기능.

    예를 들어 AI Search는 용량, 처리량 및 스토리지를 포함할 수 있는 단위로 청구됩니다. 추가 기능으로 인해 더 많은 요금이 발생할 수 있습니다. 예를 들어 이미지 추출 기능을 광범위하게 사용하면 높은 요금이 청구될 수 있습니다. 인덱스의 범위를 벗어나지만 데이터 처리의 일부인 기술 집합 기능과 같은 종속성은 추가 비용이 발생할 수 있습니다.

    전체 용량을 사용하지 않고 계층에 대한 비용을 지불하면 초과 지불이 발생할 수 있습니다. 마찬가지로 인덱스의 테이블 수와 동시 트래픽을 처리하는 기능은 비용에 영향을 줍니다.

    AI Search와 관련된 비용을 이해하려면 AI Search 서비스의 비용 계획 및 관리를 참조하세요.

  • 인덱스의 보안 기능이 보안 데이터 디자인을 충족합니까?

    데이터 디자인은 보안 및 개인 정보 요구 사항을 명확하게 지정해야 합니다. 실제 프로덕션 데이터가 사용되는 개발 및 테스트 환경에서 인덱스는 모든 액세스 제어 및 추적 가능성 측정값을 준수하는 기능을 지원해야 합니다. 데이터 마스킹 및 인덱스의 개인 정보 제거와 같은 보안 기능을 검토합니다.

    Microsoft Entra ID를 통해 클라이언트를 고유하게 식별하는 기능이 있는 인덱스를 선택합니다. 검색 인덱스는 ID별 쿼리 관련성을 허용하도록 문서 수준 액세스 제어도 지원해야 합니다. 인덱스가 이러한 기능을 제공하지 않는 경우 쿼리 필터를 사용하여 유사한 기능을 달성하도록 디자인을 조정합니다. 자세한 내용은 AI Search에서 결과를 트리밍하기 위한 보안 필터를 참조하세요.

    이상적으로 검색 인덱스는 네트워크 보안 요구 사항에 부합해야 합니다. 예를 들어 Microsoft가 아닌 사이트에 대한 송신 트래픽을 필터링하고 관찰 가능성을 유지해야 하는 경우 인덱스는 송신 컨트롤을 제공해야 합니다. 또한 네트워크 세분화를 지원해야 합니다. 백 엔드 컴퓨팅이 가상 네트워크에 있는 경우 공용 인터넷에 노출되지 않도록 인덱스를 포함한 주요 구성 요소에 대한 프라이빗 연결이 필수적입니다. 인덱스는 프라이빗 네트워크와 쉽게 통합되고 Microsoft Entra ID를 통해 인증을 위한 관리 ID를 지원해야 합니다.

기능 저장소에 대한 고려 사항

차별적 모델의 경우 데이터 디자인에 추가 구체화를 위해 데이터를 캐시하는 중간 데이터 저장소가 포함될 수 있습니다. 기능 저장소라고 하는 이 저장소를 사용하면 데이터 과학자가 집계된 데이터 저장소 외부에서 기능을 최종 단계로 저장할 수 있습니다.

기능 저장소는 생성 시간 및 원본과 같은 메타데이터를 추가하여 여러 용도에 대한 카탈로그 데이터를 지원합니다. 이 중간 방문 지점은 골든 트레이닝 데이터에 이상적입니다.

Machine Learning의 관리되는 네트워크 격리 MLflow 및 기타 도구와 통합되는 데이터 스토리지 옵션입니다. 집계 데이터 저장소에서 데이터를 가져오고 학습하여 Machine Learning 내에서 더 나은 데이터 계보 및 공식 식별을 위해 재사용 가능한 계층을 추가합니다.

기능 저장소를 사용하는 경우 보안 및 액세스 고려 사항이 있는 데이터 저장소처럼 처리합니다.

오프라인 추론 데이터 저장소에 대한 고려 사항

일부 시나리오에서는 미리 수집되고 미리 계산된 데이터에 대해 추론이 수행되므로 더 빠른 향후 조회에 별도의 저장소를 사용하는 것이 적합합니다. 이 프로세스에서는 사용자 요청이 AI 모델에 도달하지 않습니다. 다음과 같은 몇 가지 이점이 있습니다.

  • 대기 시간을 줄여 효율성과 사용자 환경을 개선했습니다. 결과는 FAQ 생성과 같은 빈번한 쿼리에 대해 더 빠르게 제공됩니다.
  • 유추 호출은 실시간 처리의 제약 조건 없이 일괄 처리 프로세스로 더 쉽게 확장할 수 있습니다.
  • 사전 유효성 검사로 프로덕션 전 정확도를 보장할 수 있습니다.
  • 요청은 간섭 엔드포인트로 전달되지 않으므로 부하를 줄여 워크로드의 안정성을 향상시킵니다.
  • 실시간 처리에 필요한 고성능 하드웨어의 필요성을 줄이면 비용 효율적일 수 있습니다.

그러나 이 방법은 가능한 요청을 예측할 수 있고 예측의 상당 부분이 사용자가 요청할 것으로 예상되는 경우에만 효과적입니다. 반복된 요청이 적은 시나리오의 경우 오프라인 유추 저장소가 덜 효과적일 수 있습니다.

이 시나리오의 데이터 저장소는 읽기 작업에 최적화되어야 하며, 대량의 데이터를 처리하고 효율적인 검색을 제공할 수 있어야 합니다. 또한 집계된 데이터 저장소에 통합할 수 있어야 합니다. 이러한 기능이 있는 모든 저장소(예: Azure Cosmos DB 또는 Table Storage)를 고려할 수 있습니다.

리소스

이러한 문서에서는 이 문서에서 설명하는 고려 사항에 대한 기술 옵션으로 권장되는 Azure 제품에 대한 자세한 정보를 제공합니다.

다음 단계

디자인 영역: MLOps 및 GenAIOps