안정성을 위한 모범 사례
이 문서에서는 다음 섹션에 나열된 아키텍처 원칙에 따라 구성된 안정성 관련 모범 사례를 설명합니다.
1. 오류를 고려한 디자인
ACID 트랜잭션을 지원하는 데이터 형식 사용
ACID 트랜잭션은 데이터 무결성 및 일관성을 유지하기 위한 중요한 기능입니다. ACID 트랜잭션을 지원하는 데이터 형식을 선택하면 더 간단하고 신뢰할 수 있는 파이프라인을 빌드하는 데 도움이 됩니다.
Delta Lake는 ACID 트랜잭션뿐만 아니라 스키마 적용, 확장 가능한 메타데이터 처리 및 스트리밍 및 일괄 처리 데이터 처리를 통합하는 오픈 소스 스토리지 프레임워크입니다. Delta Lake는 Apache Spark API와 완벽하게 호환되며 구조적 스트리밍과 긴밀하게 통합되도록 설계되어 일괄 처리 및 스트리밍 작업 모두에 단일 데이터 복사본을 쉽게 사용하고 대규모로 증분 처리를 제공할 수 있습니다.
모든 워크로드에 복원력 있는 분산 데이터 엔진 사용
Azure Databricks Lakehouse의 컴퓨팅 엔진인 Apache Spark는 복원력 있는 분산 데이터 처리를 기반으로 합니다. 내부 Spark 태스크가 예상대로 결과를 반환하지 않으면 Apache Spark는 자동으로 누락된 작업의 일정을 조정하고 전체 작업을 계속 실행합니다. 이는 간단한 네트워크 문제 또는 철회된 스폿 VM과 같은 코드 외부 오류에 유용합니다. SQL API와 Spark DataFrame API를 모두 사용한 이 복원력 기능은 엔진에서 기본 제공됩니다.
Databricks Lakehouse에서 온전히 C++로 작성된 네이티브 벡터화 엔진인 Photon은 Apache Spark API와 호환되는 고성능 컴퓨팅 솔루션입니다.
잘못되었거나 형식이 잘못된 데이터를 자동으로 복구
데이터가 잘못되었거나 형식이 잘못되면 설정된 데이터 형식을 사용하는 워크로드가 충돌할 수 있습니다. 전체 프로세스의 엔드투엔드 복원력을 높이기 위해 수집 시 유효하지 않은 데이터를 필터링하는 것이 가장 좋습니다. 복구된 데이터에 대한 지원은 수집 또는 ETL 중에 데이터를 손실하거나 누락하지 않도록 합니다. 지정된 스키마에서 누락되었거나 형식이 일치하지 않거나 레코드 또는 파일의 열 본문이 스키마의 본뭉ㄴ과 일치하지 않으므로 복구된 데이터 열에는 구문 분석되지 않은 모든 데이터가 포함됩니다.
- Databricks 자동 로더: 자동 로더는 파일 수집을 스트리밍하는 데 이상적인 도구입니다. JSON 및 CSV에 대해 복구된 데이터를 지원합니다. JSON을 예로 들면, 복구된 데이터 열에는 지정된 스키마에서 누락되었거나 유형 불일치가 있거나 열의 대/소문자가 일치하지 않아 구문 분석하지 못한 모든 데이터가 포함됩니다. 스키마가 유추될 때 복구된 데이터 열은 기본적으로 자동 로더에서
_rescued_data로 반환하는 스키마의 일부입니다. - Delta Live Tables: 복원력을 위한 워크플로를 빌드하는 또 다른 옵션은 품질 제약 조건이 있는 Delta Live Tables를 사용하는 것입니다. Delta Live Tables를 사용하여 데이터 품질 관리를 참조하세요. Delta Live Tables는 잘못된 레코드를 유지, 삭제 및 실패하는 세 가지 모드를 지원합니다. 식별된 잘못된 레코드를 격리하기 위해 잘못된 레코드가 다른 테이블에 저장("격리")되도록 특정 방식으로 예상 규칙을 정의할 수 있습니다. 잘못된 데이터 격리를 참조하세요.
자동 재시도 및 종료하도록 작업 구성
분산 시스템이 복잡하면 한 지점의 오류는 시스템 전체에서 잠재적으로 중첩될 수 있습니다.
- Azure Databricks 작업은 실패한 실행이 재시도되는 시기와 횟수를 결정하는 태스크에 대한 재시도 정책을 지원합니다. 다시 시도 정책 설정을 참조하세요.
- 태스크의 예상 완료 시간 및 태스크에 대한 최대 완료 시간을 포함하여 태스크에 대한 선택적 기간 임계값을 구성할 수 있습니다.
- 또한 Delta Live Tables는 속도와 안정성의 균형을 맞추기 위해 에스컬레이션 재시도를 사용하여 오류 복구를 자동화합니다. 개발 및 프로덕션 모드를 참조하세요.
반면에 작업 중단으로 인해 전체 작업이 완료되지 못하게 하여 비용이 많이 들 수 있습니다. Databricks 작업은 예상보다 오래 걸리는 작업을 종료하는 시간 제한 구성을 지원합니다.
인프라를 제공하는 확장성 있는 프로덕션 등급 모델 사용
일괄 처리 및 스트리밍 유추의 경우 Azure Databricks 작업 및 MLflow를 사용하여 모델을 Apache Spark UDF로 배포하여 작업 예약, 재시도, 자동 크기 조정 등을 활용합니다. 일괄 처리 유추 및 예측은 모델 배포를 참조하세요.
모델 서비스 제공은 실시간 모델 제공을 위한 확장성 있는 프로덕션 등급 인프라를 제공합니다. MLflow를 사용해서 기계 학습 모델을 처리하고 이를 REST API 엔드포인트로 노출합니다. 이 기능은 서버리스 컴퓨팅을 사용합니다. 즉, 엔드포인트 및 연관된 컴퓨팅 리소스가 Azure Databricks 클라우드 계정으로 관리되고 실행됩니다.
가능한 경우 관리형 서비스 사용
다음과 같이 Databricks Data Intelligence 플랫폼에서 관리되는 서비스(서버리스 컴퓨팅)를 활용합니다.
이러한 서비스는 Databricks에서 고객에게 추가 비용 없이 안정적이고 확장 가능한 방식으로 운영되므로 워크로드가 더 안정적입니다.
2. 데이터 품질 관리
계층화된 스토리지 아키텍처 사용
계층화된 아키텍처를 만들고 데이터가 계층을 통과할 때 데이터 품질이 향상되도록 하여 데이터를 큐레이팅합니다. 일반적인 계층화 방법은 다음과 같습니다.
- 원시 계층(브론즈): 원본 데이터가 레이크하우스로 첫 번째 계층으로 수집되고 이 계층에 유지되어야 합니다. 원시 계층에서 모든 다운스트림 데이터를 만들 때 필요에 따라 이 계층에서 후속 계층을 다시 빌드할 수 있습니다.
- 큐레이팅된 계층(실버): 두 번째 계층은 정리, 구체화, 필터링 및 집계된 데이터를 보관하는 것을 목적으로 합니다. 이 계층의 목표는 모든 역할 및 함수에서 분석 및 보고를 위한 견고하고 신뢰할 수 있는 기반을 제공하는 것입니다.
- 최종 계층(골드): 세 번째 계층은 비즈니스 또는 프로젝트 요구 사항을 중심으로 빌드됩니다. 다른 사업부 또는 프로젝트에 대한 데이터 제품으로 다른 보기를 제공하며, 보안 요구 사항(예: 익명화된 데이터)에 대한 데이터를 준비하거나 성능 최적화(예: 미리 집계된 보기 포함)를 제공합니다. 이 계층의 데이터 제품은 비즈니스의 필수 요소로 간주됩니다.
최종 계층은 고품질 데이터만 포함해야 하며 비즈니스 관점에서 완전히 신뢰할 수 있어야 합니다.
데이터 중복성을 줄여 데이터 무결성 향상
데이터를 복사하거나 복제하면 데이터 중복성이 생성되고 무결성 손실, 데이터 계보 손실 및 종종 다른 액세스 권한이 발생합니다. 이렇게 하면 레이크하우스의 데이터 품질이 줄어듭니다.
데이터의 임시 또는 일회용 복사본은 그 자체로 해롭지 않습니다. 민첩성, 실험 및 혁신을 향상해야 하는 경우도 있습니다. 그러나 이러한 복사본이 작동되고 비즈니스 의사 결정을 내리는 데 정기적으로 사용되는 경우 데이터 사일로가 됩니다. 이러한 데이터 사일로가 동기화되지 않으면 데이터 무결성 및 품질에 상당한 부정적인 영향을 미치며 "마스터 데이터 세트는 무엇인가요?" 또는 "데이터 집합이 최신인가요?와 같은 질문을 야기합니다.
스키마를 적극적으로 관리
제어되지 않은 스키마 변경으로 인해 이러한 데이터 집합을 사용하는 잘못된 데이터 및 실패한 작업이 발생할 수 있습니다. Azure Databricks에는 스키마의 유효성을 검사하고 적용하는 몇 가지 방법이 있습니다.
- Delta Lake는 수집 중에 잘못된 레코드가 삽입되지 않도록 스키마 변형을 자동으로 처리함으로써 스키마 유효성 검사 및 스키마 적용을 지원합니다. 스키마 적용을 참조하세요.
- 자동 로더는 데이터를 처리할 때 새 열 추가를 검색합니다. 기본적으로 새 열을 추가하면
UnknownFieldException으로 인해 스트림이 중지됩니다. 자동 로더는 스키마 진화를 위한 여러 모드를 지원합니다.
제약 조건 및 데이터 기대치 사용
델타 테이블은 테이블에 추가된 데이터의 품질과 무결성이 자동으로 확인되도록 하는 표준 SQL 제약 조건 관리 절을 지원합니다. 제약 조건을 위반하면 Delta Lake는 새 데이터를 추가할 수 없다는 신호로 InvariantViolationException 오류를 throw합니다. Azure Databricks의 제약 조건을 참조하세요.
이 처리를 더욱 개선하기 위해 Delta Live Tables는 기대를 지원합니다. 기대는 데이터 집합의 내용에 대한 데이터 품질 제약 조건을 정의합니다. 예상은 설명, 불변 및 레코드가 불변을 위반할 때 취하는 작업으로 구성됩니다. 쿼리의 기대치에는 Python 데코레이터 또는 SQL 제약 조건 절이 사용됩니다. Delta Live Tables를 사용하여 데이터 품질 관리를 참조하세요.
기계 학습에 대한 데이터 중심 접근 방식 수행
Databricks Data Intelligence Platform에 대한 AI 비전의 핵심에 남아 있는 지침 원칙은 기계 학습에 대한 데이터 중심 접근 방식입니다. 생성형 AI가 더 널리 보급됨에 따라 이러한 관점도 여전히 중요합니다.
모든 ML 프로젝트의 핵심 구성 요소는 단순히 데이터 파이프라인으로 생각할 수 있습니다. 기능 엔지니어링, 학습, 모델 배포, 유추 및 모니터링 파이프라인은 모두 데이터 파이프라인입니다. 따라서 ML 솔루션을 운영하려면 예측, 모니터링 및 기능 테이블의 데이터를 다른 관련 데이터와 병합해야 합니다. 기본적으로 이 작업을 수행하는 가장 쉬운 방법은 프로덕션 데이터를 관리하는 데 사용되는 동일한 플랫폼에서 AI 기반 솔루션을 개발하는 것입니다. 데이터 중심 MLOps 및 LLMOps 참조
3. 자동 크기 조정을 위한 디자인
ETL 워크로드에 자동 크기 조정 사용
자동 크기 조정을 사용하면 워크로드에 따라 클러스터 크기를 자동으로 조정할 수 있습니다. 자동 크기 조정은 비용 및 성능 관점에서 많은 사용 사례와 시나리오에 이점을 줄 수 있습니다. 설명서에서는 자동 크기 조정을 사용할지 여부와 최대 이점을 얻는 방법을 결정할 때 고려해야 할 사항을 제시합니다.
스트리밍 워크로드에 대해 향상된 자동 크기 조정과 함께 Delta Live Tables를 사용하는 것이 좋습니다. Databricks 향상된 자동 크기 조정은 파이프라인의 데이터 처리 대기 시간에 미치는 영향을 최소화하면서 워크로드 볼륨에 따라 클러스터 리소스를 자동으로 할당하여 클러스터 사용률을 최적화합니다.
SQL 웨어하우스에 자동 크기 조정 사용
SQL 웨어하우스의 스케일링 매개 변수는 웨어하우스로 전송된 쿼리가 분산되는 최소 및 최대 클러스터 수를 설정합니다. 기본값은 자동 크기 조정 없이 하나의 클러스터입니다.
지정된 웨어하우스에 대해 더 많은 동시 사용자를 처리하려면 클러스터 수를 늘립니다. Azure Databricks가 클러스터를 웨어하우스에 추가하고 웨어하우스에서 클러스터를 제거하는 방법을 알아보려면 SQL 웨어하우스 크기 조정, 스케일링 및 큐 동작을 참고하세요.
4. 테스트 복구 절차
구조적 스트리밍 쿼리 실패에서 복구
구조적 스트리밍은 스트리밍 쿼리에 대한 내결함성 및 데이터 일관성을 제공합니다. Databricks 작업을 사용하면 오류 발생 시에 자동으로 다시 시작하도록 구조적 스트리밍 쿼리를 쉽게 구성할 수 있습니다. 스트리밍 쿼리에 대한 검사점 설정을 활성화하면 실패 후 쿼리를 다시 시작할 수 있습니다. 다시 시작한 쿼리는 실패한 쿼리가 중단된 곳에서 계속됩니다. 구조적 스트리밍 검사점 및 구조적 스트리밍에 대한 프로덕션 고려 사항을 참조하세요.
데이터 시간 이동 기능을 사용하여 ETL 작업 복구
철저한 테스트에도 불구하고 작업이 프로덕션에서 실패하거나 예기치 않은 잘못된 데이터를 생성할 수 있습니다. 문제의 원인을 파악하고 처음에 문제를 일으킨 파이프라인을 수정한 후 추가 작업으로 이 문제를 해결할 수 있는 경우도 있습니다. 그러나 이 작업은 간단하지 않고 문제의 작업을 롤백해야 하는 경우가 많습니다. 델타 시간 이동 기능을 사용하여 사용자는 변경 내용을 이전 버전 또는 타임스탬프로 쉽게 롤백하고, 파이프라인을 복구하고, 고정 파이프라인을 다시 시작할 수 있습니다.
이렇게 하는 편리한 방법은 RESTORE 명령입니다.
기본 제공 복구를 사용하여 작업 자동화 프레임워크 활용
Databricks 작업은 복구를 위해 설계되었습니다. 다중 작업 작업의 태스크가 실패하는 경우(및 모든 종속 작업) Azure Databricks 작업은 오류를 발생시킨 문제를 조사할 수 있는 실행의 행렬 보기를 제공합니다. 작업에 대한 실행 보기를 참조하세요. 짧은 네트워크 문제이든 데이터의 실제 문제이든 관계없이 이를 수정하고 Azure Databricks 작업에서 복구 실행을 시작할 수 있습니다. 실패한 종속 작업만 실행하고 이전 실행의 성공적인 결과를 유지하여 시간과 비용을 절약합니다. 문제 해결 및 작업 오류 복구를 참조하세요.
재해 복구 패턴 구성
Azure Databricks와 같은 클라우드 네이티브 데이터 분석 플랫폼의 경우 명확한 재해 복구 패턴이 중요합니다. 허리케인, 지진 또는 기타 원인과 같은 국지적 재해로 인한 지역 서비스 전체 클라우드 서비스 공급자 운영 중단이 일어나는 경우에도 데이터 팀이 Azure Databricks 플랫폼을 사용할 수 있어야 합니다.
Azure Databricks는 종종 업스트림 데이터 수집 서비스(일괄/스트리밍), Azure Data Lake Storage Gen2와 같은 클라우드 네이티브 스토리지, 비즈니스 인텔리전스 앱과 같은 다운스트림 도구 및 서비스, 오케스트레이션 도구를 비롯한 많은 서비스를 포함하는 전체 데이터 에코시스템의 핵심 부분입니다. 일부 사용 사례는 지역 서비스 전체 중단에 특히 중요할 수 있습니다.
재해 복구에는 자연 재해 또는 인적 재해가 발생한 후 중요한 기술 인프라 및 시스템의 복구 또는 지속을 가능하게 하는 일련의 정책, 도구 및 절차가 포함됩니다. Azure와 같은 대규모 클라우드 서비스는 많은 고객에게 서비스를 제공하며 단일 장애에 대한 기본 제공 보호 기능을 갖추고 있습니다. 예를 들어 리전은 단일 전력 손실으로 리전이 종료되지 않도록 보장하기 위해 서로 다른 전원에 연결된 건물의 그룹입니다. 그러나 클라우드 지역 오류가 발생할 수 있으며 실패의 심각도 및 비즈니스에 미치는 영향은 다를 수 있습니다.
5. 배포 및 워크로드 자동화
최적의 작동 - 배포 및 워크로드 자동화를 참조하세요.
6. 시스템 및 워크로드 모니터링
최적의 작동 - 모니터링, 경고 및 로깅 설정을 참조하세요.