Databricks 작업 영역에 대한 재해 복구 구현

이 게시물은 재해 복구 개요, 전략 및 평가와 Databricks 작업 공간을 위한 재해 복구 자동화 및 도구에 이어지는 내용입니다.

재해 복구는 자연재해 또는 인재 발생 후 중요한 기술 인프라 및 시스템의 복구 또는 지속을 가능하게 하는 정책, 도구 및 절차 세트를 의미합니다. AWS, Azure, Google Cloud와 같은 클라우드 서비스 제공업체 및 SaaS 회사는 단일 실패 지점에 대한 안전 장치를 구축하지만, 장애는 발생합니다. 중단의 심각성과 조직에 미치는 영향은 다를 수 있습니다. 클라우드 네이티브 워크로드의 경우 명확한 재해 복구 패턴이 중요합니다.

Databricks 재해 복구 설정

계획, DR 솔루션 전략 설정 및 자동화 방법에 대한 1단계부터 4단계까지 이해하려면 이 DR 블로그 시리즈의 이전 게시물을 참조하십시오. 이 게시물의 5단계와 6단계에서는 DR 설정을 모니터링, 실행 및 검증하는 방법을 살펴보겠습니다.

재해 복구 솔루션

일반적인 Databricks 구현에는 최종 사용자에게 중단과 서비스 지속을 최소화하기 위해 원활하게 복구해야 하는 노트북 소스 코드, 쿼리, 작업 구성 및 클러스터와 같은 여러 중요 자산이 포함됩니다.

개략적인 DR 고려 사항:

• 아키텍처가 Terraform(TF)을 통해 복제 가능하도록 하여 다른 위치에 이 환경을 생성하고 다시 생성할 수 있도록 합니다.
• Databricks Repos(AWS | Azure | GCP)를 사용하여 지원되는 임의 파일(AWS | Azure | GCP)에 노트북 및 애플리케이션 코드를 동기화합니다.
• Terraform Cloud를 사용하여 인프라 및 앱 파이프라인에 대한 TF 실행(계획 및 적용)을 트리거하는 동시에 상태를 유지합니다.
• Amazon S3, Azure ADLS 및 GCS와 같은 클라우드 스토리지 계정에서 DR 리전으로 데이터를 복제합니다. AWS를 사용하는 경우 여러 AWS 리전에 있는 여러 S3 버킷에 걸쳐 데이터를 저장하기 위해 S3 다중 리전 액세스 포인트를 사용할 수도 있습니다.
• Databricks 클러스터 정의에는 가용 영역별 정보가 포함될 수 있습니다. AWS에서 Databricks를 실행할 때 리전 장애 조치 중 발생할 수 있는 문제를 방지하기 위해 “auto-az” 클러스터 속성을 사용합니다.
• DR 리전에서 구성 드리프트를 관리합니다. DR 리전에서 인프라, 데이터 및 구성이 필요한 대로 되어 있는지 확인합니다.
• 프로덕션 코드 및 자산의 경우 변경 사항을 두 리전에 동시에 프로덕션 시스템에 푸시하는 CI/CD 도구를 사용합니다. 예를 들어, 스테이징/개발에서 프로덕션으로 코드를 푸시할 때 CI/CD 시스템은 이를 두 리전에 동시에 사용할 수 있도록 합니다.
• Git을 사용하여 TF 파일 및 인프라 코드베이스, 작업 구성 및 클러스터 구성을 동기화합니다.
  • 보조 리전에서 TF `apply`를 실행하기 전에 리전별 구성을 업데이트해야 합니다.

모니터링 및 감지

워크로드가 정상 상태가 아님을 가능한 한 빨리 알면 재해를 신속하게 선언하고 사고로부터 복구할 수 있습니다. 이 응답 시간과 적절한 정보가 결합되면 공격적인 복구 목표를 달성하는 데 중요합니다. 현실적이고 달성 가능한 목표를 제공하기 위해 사고 감지, 알림, 에스컬레이션, 검색 및 선언을 계획 및 목표에 포함하는 것이 중요합니다.

서비스 상태 알림

제어 영역의 모든 핵심 Databricks 서비스 개요는 Databricks 상태 페이지에서 제공됩니다. 상태 페이지를 보면 특정 서비스의 상태를 쉽게 확인할 수 있습니다. 선택적으로 개별 서비스 구성 요소에 대한 상태 업데이트를 구독할 수도 있으며, 구독한 상태가 변경될 때마다 알림이 전송됩니다.

데이터 영역에 대한 상태 확인은 AWS 상태 대시보드, Azure 상태 페이지 및 GCP 서비스 상태 페이지를 사용하여 모니터링해야 합니다.

AWS와 Azure는 도구가 상태 확인을 수집하고 알림을 보내는 데 사용할 수 있는 API 엔드포인트를 제공합니다.

인프라 모니터링 및 알림

인프라에서 데이터를 수집하고 분석하는 도구를 사용하면 팀이 시간에 따른 성능을 추적할 수 있습니다. 이를 통해 팀은 다운타임과 서비스 저하를 전반적으로 최소화할 수 있습니다. 또한 시간에 따른 모니터링은 최적화 및 알림에 필요한 기준 성능 기준선을 설정합니다.

DR의 맥락에서 조직은 서비스 제공업체의 알림을 기다릴 수 없을 수 있습니다. RTO/RPO 요구 사항이 서비스 제공업체의 알림을 기다릴 만큼 허용적이더라도 성능 저하에 대해 공급업체 지원팀에 미리 알리면 더 빠른 커뮤니케이션 라인이 열립니다.

DataDog와 Dynatrace 모두 AWS, Azure, GCP 및 Databricks 클러스터에 대한 통합 및 에이전트를 제공하는 인기 있는 모니터링 도구입니다.

상태 확인

가장 엄격한 RTO 요구 사항의 경우 Databricks 서비스 및 워크로드가 직접 인터페이스하는 다른 서비스(예: 클라우드 제공업체의 객체 저장소 및 VM 서비스)의 상태 확인을 기반으로 자동화된 장애 조치를 구현할 수 있습니다.

사용자 경험을 나타내고 핵심 성과 지표(KPI)를 기반으로 하는 상태 확인을 설계합니다. 얕은 하트비트 확인은 클러스터가 실행 중인지 즉, 시스템이 작동하는지 여부를 평가할 수 있습니다. 반면, 개별 노드의 CPU, 디스크 사용량 및 활성 단계 또는 캐시된 파티션 전반의 Spark 메트릭과 같은 시스템 메트릭에 대한 심층 상태 확인은 얕은 하트비트 확인을 넘어 성능의 상당한 저하를 결정합니다. 워크로드의 기능 및 기준 성능에 따라 여러 신호를 기반으로 하는 심층 상태 확인을 사용합니다.

건강 검진을 통해 장애 조치(failover)를 완전히 자동화하는 경우 주의하십시오. 잘못된 긍정(false positive)이 발생하거나 경보가 울리더라도 비즈니스가 영향을 흡수할 수 있다면 장애 조치가 필요하지 않습니다. 잘못된 장애 조치는 가용성 위험과 데이터 손상 위험을 초래하며 시간적으로 비용이 많이 드는 작업입니다. 경보가 울릴 경우, 현장 담당 사고 관리자와 같이 사람이 개입하여 결정을 내리는 것이 좋습니다. 불필요한 장애 조치는 치명적일 수 있으며, 추가 검토를 통해 장애 조치가 필요한지 여부를 판단하는 데 도움이 됩니다.

DR 솔루션 실행

재해 복구(Disaster Recovery) 솔루션에는 크게 두 가지 실행 시나리오가 있습니다. 첫 번째 시나리오에서는 DR 사이트를 임시로 간주합니다. 기본 사이트의 서비스가 복원되면, 솔루션은 DR 사이트에서 영구적인 기본 사이트로 장애 조치를 조정해야 합니다. 이 시나리오에서는 DR 사이트가 활성 상태일 때 새 아티팩트 생성을 제한해야 합니다. 이는 임시적이며 장애 복구(failback)를 복잡하게 만들기 때문입니다. 반대로 두 번째 시나리오에서는 DR 사이트가 새로운 기본 사이트로 승격되어 사용자가 서비스를 복원할 때까지 기다릴 필요 없이 더 빨리 작업을 재개할 수 있습니다. 또한 이 시나리오에서는 장애 복구가 필요하지 않지만, 이전 기본 사이트를 새로운 DR 사이트로 준비해야 합니다.

어떤 시나리오든 DR 솔루션 범위 내의 각 리전은 필요한 모든 서비스를 지원해야 하며, 대상 작업 공간이 양호한 운영 상태인지 검증하는 프로세스가 안전 장치로 존재해야 합니다. 검증에는 시뮬레이션된 인증, 자동화된 쿼리, API 호출 및 ACL 검사가 포함될 수 있습니다.

장애 조치(Failover)

DR 사이트로 장애 조치를 트리거할 때, 시스템을 정상적으로 종료할 수 있다고 가정할 수 없습니다. 솔루션은 기본 사이트에서 실행 중인 서비스를 종료하려고 시도하고, 각 서비스의 종료 상태를 기록한 다음, 정의된 시간 간격으로 적절한 상태 없이 서비스를 계속 종료하려고 시도해야 합니다. 이렇게 하면 기본 사이트와 DR 사이트에서 동시에 데이터가 처리될 위험을 줄여 데이터 손상을 최소화하고 서비스가 복원된 후 장애 복구 프로세스를 용이하게 합니다.

DR 사이트를 활성화하기 위한 개략적인 단계는 다음과 같습니다:

1. 기본 사이트에서 종료 프로세스를 실행하여 기본 리전의 풀, 클러스터 및 예약된 작업을 비활성화합니다. 이렇게 하면 실패한 서비스가 온라인 상태로 돌아올 경우 기본 리전에서 새 데이터를 처리하지 않도록 할 수 있습니다.
2. DR 사이트 인프라 및 구성이 최신 상태인지 확인합니다.
3. 최신 동기화 데이터의 날짜를 확인합니다. 재해 복구 업계 용어를 참조하십시오. 이 단계의 세부 정보는 데이터를 동기화하는 방법과 고유한 비즈니스 요구 사항에 따라 달라집니다.
4. 데이터 소스를 안정화하고 모두 사용 가능한지 확인합니다. 객체 스토리지, 데이터베이스, pub/sub 시스템 등 모든 중요 외부 데이터 소스를 포함합니다.
5. 플랫폼 사용자를 알립니다.
6. 관련 풀을 시작하거나(또는 min_idle_instances를 관련 숫자로 늘립니다).
7. 관련 클러스터, 작업 및 SQL 웨어하우스를 시작합니다(종료되지 않은 경우).
8. 작업의 동시 실행을 변경하고 관련 작업을 실행합니다. 이는 일회성 실행 또는 주기적 실행일 수 있습니다.
9. 작업 일정을 활성화합니다.
10. Databricks 작업 영역에 URL 또는 도메인 이름을 사용하는 외부 도구의 경우, 새 제어 평면을 수용하도록 구성을 업데이트합니다. 예를 들어 REST API 및 JDBC/ODBC 연결의 URL을 업데이트합니다. Databricks 웹 애플리케이션의 고객 대면 URL은 제어 평면이 변경될 때 변경되므로, 조직의 사용자에게 새 URL을 알립니다.

장애 복구(Failback)

장애 복구 중 기본 사이트로 복귀하는 것은 제어하기가 더 쉬우며 유지 관리 기간 동안 수행할 수 있습니다. 장애 복구는 네 가지 주요 예외를 제외하고 장애 조치와 매우 유사한 계획을 따릅니다:

1. 대상 리전은 기본 리전이 됩니다.
2. 장애 복구는 제어된 프로세스이므로, 서비스가 다시 온라인 상태가 될 때 상태 확인이 필요하지 않은 일회성 활동입니다.
3. 향후 장애 조치를 위해 DR 사이트를 필요에 따라 재설정해야 합니다.
4. 학습된 내용은 DR 솔루션에 통합하고 향후 재해 발생 시 테스트해야 합니다.

결론

재해 복구 설정이 제대로 작동하는지 확인하기 위해 실제 조건에서 정기적으로 테스트하십시오. 필요할 때 사용할 수 없는 재해 복구 솔루션을 유지하는 것은 의미가 거의 없습니다. 일부 조직은 몇 달마다 리전 간 장애 조치 및 장애 복구를 수행하여 DR 인프라를 테스트합니다. 정기적으로 DR 사이트로 장애 조치를 수행하면 RPO 및 RTO 측면에서 복구 요구 사항을 충족하는지 확인하기 위해 가정을 검증하고 프로세스를 테스트할 수 있습니다. 또한 조직의 비상 정책 및 절차가 최신 상태인지 확인합니다. 일반적인 프로세스 및 구성에 필요한 조직 변경 사항을 테스트하십시오. 재해 복구 계획은 배포 파이프라인에 영향을 미치므로 팀이 동기화해야 하는 사항을 인지하고 있는지 확인하십시오.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)