Databricks에서의 기능적 워크스페이스 구성

소개

이 블로그는 관리자 필수 사항 시리즈의 첫 번째 부분으로, Databricks 환경을 관리하고 유지 관리하는 데 중요한 주제에 초점을 맞출 것입니다. 가까운 미래에 데이터 거버넌스, 운영 및 자동화, 사용자 관리 및 접근성, 비용 추적 및 관리에 대한 추가 블로그를 기대해 주세요!

2020년에 Databricks는 Enterprise 2.0(또는 E2)으로 통칭되는 여러 플랫폼 기능의 비공개 미리 보기를 출시하기 시작했습니다. 이 기능은 Lakehouse 플랫폼의 다음 반복을 제공하여 Databricks에서 이미 사용 가능한 강력한 성능과 속도에 맞는 확장성과 보안을 제공했습니다. Enterprise 2.0이 공개적으로 사용 가능해졌을 때 가장 기대되었던 추가 기능 중 하나는 단일 계정에서 여러 워크스페이스를 생성하는 기능이었습니다. 이 기능은 협업, 조직 정렬 및 단순화를 위한 새로운 가능성을 열었습니다. 그러나 우리가 경험했듯이 이는 또한 많은 질문을 불러일으켰습니다. 모든 규모, 형태 및 산업 분야의 엔터프라이즈 고객에 걸친 당사의 경험을 바탕으로 이 블로그는 Databricks 내 워크스페이스 관리에 대한 가장 일반적인 질문에 대한 답변과 모범 사례를 제시할 것입니다. 기본적으로 이는 간단한 질문으로 귀결됩니다. 새 워크스페이스는 정확히 언제 생성해야 할까요? 구체적으로 워크스페이스를 구성하기 위한 주요 전략과 각 전략의 모범 사례를 강조할 것입니다.

워크스페이스 구성 기본 사항

각 클라우드 공급자(AWS, Azure 및 GCP)는 다른 기본 아키텍처를 가지고 있지만, 클라우드 전반의 Databricks 워크스페이스 구성은 유사합니다. 논리적 최상위 구성 요소는 E2 마스터 계정(AWS) 또는 구독 개체(Azure Databricks/GCP)입니다. AWS에서는 모든 워크스페이스에 대한 통합된 가시성 및 제어 창을 제공하는 조직당 단일 E2 계정을 프로비저닝합니다. 이러한 방식으로 관리자 활동이 중앙 집중화되어 SSO, 감사 로그 및 Unity Catalog를 활성화할 수 있습니다. Azure는 최상위 구독 개체 생성에 상대적으로 제한이 적습니다. 그러나 Databricks 워크스페이스를 생성하는 데 사용되는 최상위 구독 수를 가능한 한 많이 제어하는 것이 좋습니다. 이 블로그 전체에서 AWS E2 계정이든 GCP/Azure 구독이든 최상위 구성을 계정이라고 부르겠습니다.

최상위 계정 내에서 여러 워크스페이스를 생성할 수 있습니다. Azure의 계정당 권장 최대 워크스페이스 수는 20~50개이며, AWS에는 하드 제한이 있습니다. 이 제한은 워크스페이스 수가 증가함에 따라 발생하는 관리 오버헤드에서 비롯됩니다. 수백 개의 워크스페이스에 걸쳐 협업, 액세스 및 보안을 관리하는 것은 뛰어난 자동화 프로세스를 통해서도 매우 어려운 작업이 될 수 있습니다. 아래에서는 Databricks 계정의 개략적인 개체 모델을 제시합니다.

기업은 멀티테넌시 요구 사항을 지원하기 위해 클라우드 계정에 리소스를 생성해야 합니다. 각 새 사용 사례에 대해 별도의 클라우드 계정 및 워크스페이스를 생성하는 것은 비용 추적 용이성, 데이터 및 사용자 격리, 보안 사고 발생 시 더 작은 영향 범위와 같은 명확한 이점이 있습니다. 그러나 계정 확산은 별도의 복잡성을 야기합니다. 거버넌스, 메타데이터 관리 및 협업 오버헤드는 계정 수에 따라 증가합니다. 물론 핵심은 균형입니다. 아래에서는 먼저 엔터프라이즈 워크스페이스 구성에 대한 일반적인 고려 사항을 살펴본 다음, 고객들 사이에서 볼 수 있는 두 가지 일반적인 워크스페이스 격리 전략인 LOB 기반 및 제품 기반을 살펴볼 것입니다. 각 전략에는 강점, 약점 및 복잡성이 있으며, 이를 논의한 후 모범 사례를 제시할 것입니다.

일반 워크스페이스 구성 고려 사항

워크스페이스 전략을 설계할 때 고객이 가장 먼저 고려하는 것은 거시적 수준의 구성 선택입니다. 그러나 훨씬 더 중요한 낮은 수준의 결정도 많이 있습니다! 가장 관련성이 높은 사항들을 아래에 정리했습니다.

간단한 3개 워크스페이스 접근 방식

이 블로그의 대부분은 워크스페이스를 최대한 효과적으로 분할하는 방법에 대해 이야기하지만, 단일 통합 워크스페이스가 환경당 충분한 Databricks 고객층도 있습니다! 실제로 Repos, Unity Catalog, 페르소나 기반 랜딩 페이지 등과 같은 기능의 등장으로 이는 점점 더 실용적으로 되고 있습니다. 이러한 경우에도 유효성 검사 및 QA 목적으로 개발, 스테이징 및 프로덕션 워크스페이스를 분리하는 것이 좋습니다. 이는 소규모 비즈니스 또는 복잡성보다 민첩성을 중시하는 팀에 이상적인 환경을 만듭니다.

단일 워크스페이스 세트를 만드는 것의 장단점은 다음과 같습니다.

단일 워크스페이스 세트가 귀하에게 적합한 접근 방식이라고 생각된다면, 다음 모범 사례가 Lakehouse를 원활하게 운영하는 데 도움이 될 것입니다.

• 다양한 환경 간에 코드를 푸시하는 표준화된 프로세스를 정의합니다. 단일 환경 세트만 있으므로 다른 접근 방식보다 간단할 수 있습니다. Repos 및 Secrets와 같은 기능과 좋은 CI/CD 프로세스를 지원하는 외부 도구를 활용하여 전환이 자동으로 원활하게 이루어지도록 합니다.
• Databricks 에셋에 매핑된 ID 공급자 그룹을 설정하고 정기적으로 검토합니다. 이러한 그룹은 이 전략에서 사용자 권한의 주요 동인이므로 정확하고 적절한 기본 데이터 및 컴퓨팅 리소스에 매핑되는 것이 중요합니다. 예를 들어, 대부분의 사용자는 프로덕션 워크스페이스에 액세스할 필요가 없을 수 있습니다. 소수의 엔지니어 또는 관리자만 권한을 가질 수 있습니다.
• 사용량 현황을 주시하고 Databricks 리소스 제한을 파악하세요. 워크스페이스 사용량이나 사용자 수가 증가하기 시작하면, 워크스페이스당 제한을 피하기 위해 더 복잡한 워크스페이스 구성 전략을 고려해야 할 수 있습니다. 비용 및 사용량 지표를 추적하기 위해 가능한 모든 곳에서 리소스 태깅을 활용하세요.

샌드박스 워크스페이스 활용

이 문서 전반에 걸쳐 언급된 모든 전략에서 샌드박스 환경은 덜 형식적이지만 잠재적으로 가치 있는 작업을 사용자가 구상하고 개발할 수 있도록 하는 좋은 방법입니다. 중요하게도, 이러한 샌드박스 환경은 실제 데이터 탐색의 자유와 프로덕션 워크로드에 의도치 않게(또는 의도적으로) 영향을 미치는 것으로부터의 보호 사이의 균형을 맞춰야 합니다. 이러한 워크스페이스에 대한 일반적인 모범 사례 중 하나는 완전히 별도의 클라우드 계정에서 호스팅하는 것입니다. 이렇게 하면 워크스페이스 내 사용자들의 영향 범위를 크게 제한할 수 있습니다. 동시에, 간단한 안전 장치(예: 클러스터 정책, “플레이” 또는 정리된 데이터셋으로 데이터 액세스 제한, 가능한 경우 아웃바운드 연결 차단)를 설정하면 사용자는 관리자의 지속적인 감독 없이도 (거의) 원하는 모든 것을 자유롭게 할 수 있습니다. 마지막으로, 내부 커뮤니케이션도 마찬가지로 중요합니다. 사용자가 샌드박스에서 수천 명의 사용자를 끌어들이는 놀라운 애플리케이션을 무심코 구축하거나 이 환경에서 작업에 대한 프로덕션 수준의 지원을 기대하는 경우, 이러한 관리 절감 효과는 빠르게 사라질 것입니다.

샌드박스 워크스페이스에 대한 모범 사례는 다음과 같습니다.

• 민감하거나 프로덕션 데이터가 포함되지 않은 별도의 클라우드 계정을 사용하세요.
• 사용자가 관리자 감독 없이 환경에 대한 상대적인 자유를 누릴 수 있도록 간단한 안전 장치를 설정하세요.
• 샌드박스 환경은 “셀프 서비스”임을 명확하게 소통하세요.

데이터 격리 및 민감도

민감한 데이터는 모든 산업 분야의 고객들 사이에서 중요성이 커지고 있습니다. 한때 의료 제공업체나 신용카드 처리업체에 국한되었던 데이터가 이제 환자 분석 또는 고객 감정 이해, 신흥 시장 분석, 신제품 포지셔닝 등 생각할 수 있는 거의 모든 것을 위한 소스가 되고 있습니다. 이러한 풍부한 데이터는 데이터 유출의 끊임없이 증가하는 위협과 함께 높은 잠재적 위험을 수반합니다. 이러한 이유로, 어떤 조직 전략을 선택하든 민감한 데이터를 분리하고 보호하는 것이 중요합니다. Databricks는 민감한 데이터 보호(예: ACL 및 보안 공유)를 위한 여러 수단을 제공하며, 클라우드 제공업체 도구와 결합하여 구축한 Lakehouse를 가능한 한 낮은 위험으로 만들 수 있습니다. 데이터 격리 및 민감도에 대한 모범 사례 중 일부는 다음과 같습니다.

• 고유한 데이터 보안 요구 사항을 이해하세요. 이것이 가장 중요한 점입니다. 모든 비즈니스는 다른 데이터를 가지고 있으며, 데이터가 거버넌스를 주도할 것입니다.
• 스토리지 레벨과 메타스토어 레벨 모두에서 정책과 제어를 적용하세요. S3 정책과 ADLS ACL은 항상 최소 권한 원칙을 사용하여 적용해야 합니다. Unity Catalog를 활용하여 데이터 액세스에 대한 추가 제어 계층을 적용하세요.
• 논리적으로나 물리적으로 민감한 데이터와 민감하지 않은 데이터를 분리하세요. 많은 고객이 민감한 데이터와 민감하지 않은 데이터에 대해 완전히 별도의 클라우드 계정(및 Databricks 워크스페이스)을 사용합니다.

DR 및 지역 백업

AWS, Azure 또는 GCP를 사용하든 재해 복구(DR)는 중요한 광범위한 주제입니다. 이 블로그에서는 모든 것을 다루지 않고, 대신 DR 및 지역 고려 사항이 워크스페이스 설계에 어떻게 영향을 미치는지에 초점을 맞출 것입니다. 이 맥락에서 DR은 표준 프로덕션 워크스페이스와 별도의 지역에 워크스페이스를 생성하고 유지 관리하는 것을 의미합니다.

DR 전략은 비즈니스 요구 사항에 따라 크게 달라질 수 있습니다. 예를 들어, 일부 고객은 한 워크스페이스의 모든 자산이 보조 워크스페이스에 지속적으로 복제되는 활성-활성 구성을 유지하는 것을 선호합니다. 이는 최대 수준의 중복성을 제공하지만 복잡성과 비용(크로스 리전 데이터 전송 및 객체 복제 및 중복 제거 수행은 복잡한 프로세스)을 수반합니다. 반면에 일부 고객은 비즈니스 연속성을 보장하기 위해 필요한 최소한의 작업을 수행하는 것을 선호합니다. 보조 워크스페이스에는 장애 조치가 발생할 때까지 매우 적은 내용이 포함되거나 간헐적으로만 백업될 수 있습니다. 적절한 수준의 장애 조치를 결정하는 것이 중요합니다.

구현하기로 선택한 DR 수준에 관계없이 다음을 권장합니다.

• 선택한 Git 리포지토리(온프레미스 또는 클라우드)에 코드를 저장하고, 가능한 경우 Databricks와 동기화하기 위해 Repos와 같은 기능을 사용하세요.
• 가능한 경우 Deep Clone과 함께 Delta Lake를 사용하여 데이터를 복제하세요. 이는 데이터를 효율적으로 백업하는 쉬운 오픈 소스 방법을 제공합니다.
• 클라우드 제공업체가 제공하는 클라우드 네이티브 도구를 사용하여 Delta Lake에 저장되지 않은 데이터, 외부 데이터베이스, 구성 등과 같은 항목을 백업하세요.
• 노트북, 작업, 비밀, 클러스터 및 기타 워크스페이스 객체와 같은 객체를 백업하기 위해 Terraform과 같은 도구를 사용하세요.

기억하세요: Databricks는 컨트롤 플레인에서 지역 워크스페이스 인프라를 유지 관리할 책임이 있지만, 워크스페이스별 자산과 프로덕션 작업이 의존하는 클라우드 인프라에 대한 책임은 귀하에게 있습니다.

비즈니스 라인(LOB)별 격리

이제 엔터프라이즈 컨텍스트에서 워크스페이스의 실제 구성에 대해 자세히 알아보겠습니다. LOB 기반 프로젝트 격리는 IT 리소스를 바라보는 전통적인 엔터프라이즈 중심 방식에서 비롯됩니다. 또한 LOB 중심 정렬의 많은 전통적인 강점(및 약점)을 가지고 있습니다. 따라서 많은 대기업의 경우 워크스페이스 관리에 대한 이 접근 방식은 자연스럽게 느껴질 것입니다.

LOB 기반 워크스페이스 전략에서는 비즈니스의 각 기능 단위가 워크스페이스 세트를 받게 됩니다. 전통적으로 여기에는 개발, 스테이징 및 프로덕션 워크스페이스가 포함되지만, 최대 10개의 중간 단계를 가진 고객도 보았으며 각 단계마다 자체 워크스페이스가 있을 수 있습니다(권장하지 않음!). 코드는 DEV에서 작성 및 테스트된 다음(CI/CD 자동화를 통해) STG로 승격되고, 마지막으로 PRD에 배치되어 예약된 작업으로 실행되다가 사용 중단됩니다. 환경 유형과 독립적인 LOB는 이 모델에서 새 워크스페이스를 시작하는 주요 이유입니다. 모든 사용 사례 또는 데이터 제품에 대해 이렇게 하는 것은 과도할 수 있습니다.

위 다이어그램은 LOB 기반 워크스페이스를 구성할 수 있는 한 가지 잠재적인 방법을 보여줍니다. 이 경우 각 LOB는 각 환경(dev/stg/prd)에 하나의 워크스페이스가 있는 별도의 클라우드 계정을 가지며 전담 관리자도 있습니다. 중요하게도, 이러한 모든 워크스페이스는 동일한 Databricks 계정에 속하며 동일한 Unity Catalog를 활용합니다. 일부 변형에는 클라우드 계정 공유(및 잠재적으로 VPC 및 클라우드 서비스와 같은 기본 리소스)가 포함될 수 있으며, 별도의 dev/stg/prd 클라우드 계정을 사용하거나 각 LOB에 대해 별도의 외부 메타스토어를 만드는 것이 포함될 수 있습니다. 이들은 모두 비즈니스 요구 사항에 따라 크게 달라지는 합리적인 접근 방식입니다.

전반적으로 LOB 접근 방식에는 몇 가지 장점과 몇 가지 단점이 있습니다.

모범 사례로, LOB 기반 Lakehouse를 구축하는 분들께 다음을 권장합니다.

• 사용자 및 환경에 대한 세분화된 액세스 제어를 사용하여 최소 권한 액세스 모델을 사용하세요. 일반적으로 프로덕션 액세스 권한을 가진 사용자는 매우 적어야 하며, 이 환경과의 상호 작용은 자동화되고 엄격하게 제어되어야 합니다. 이러한 사용자 및 그룹을 ID 공급자에 캡처하고 Lakehouse로 동기화하세요.
• Lakehouse의 전반적인 거버넌스를 이해하고 계획하며 전반적인 위험을 줄이세요.
• 가능한 한 표준화된 메타스토어/카탈로그와 강력한 액세스 제어를 사용하세요. 이를 통해 격리를 손상시키지 않고 에셋을 재사용할 수 있습니다. Unity Catalog는 테이블 및 워크스페이스 에셋에 대한 세분화된 제어를 제공하며, 여기에는 MLflow 실험과 같은 개체가 포함됩니다.
• 데이터 공유를 최대한 활용하여 노력을 중복할 필요 없이 LOB 간에 데이터를 안전하게 공유하세요.

데이터 제품 격리

LOB가 상호 기능적으로 협업해야 하거나 간단한 개발/스테이징/프로덕션 모델이 LOB의 사용 사례에 맞지 않을 때는 어떻게 해야 할까요? 엄격한 LOB 기반 Lakehouse 구조의 형식성을 일부 버리고 약간 더 현대적인 접근 방식을 채택할 수 있습니다. 이를 데이터 제품별 워크스페이스 격리라고 합니다. 핵심은 LOB별로 엄격하게 격리하는 대신 최상위 프로젝트별로 격리하여 각 프로젝트에 프로덕션 환경을 제공하는 것입니다. 또한 워크스페이스 확산을 방지하고 에셋 재사용을 단순화하기 위해 공유 개발 환경을 혼합합니다.

처음에는 위에서 설명한 LOB 기반 격리와 유사해 보이지만 몇 가지 중요한 차이점이 있습니다.

• 각 최상위 프로젝트에 대한 별도의 워크스페이스와 공유 개발 워크스페이스가 있습니다(이는 각 LOB마다 전체 워크스페이스 수가 다를 수 있음을 의미합니다).
• 샌드박스 워크스페이스의 존재. 이는 LOB별로 특정하며, 기존 개발 워크스페이스보다 더 많은 자유와 적은 자동화를 제공합니다.
• 리소스 및/또는 워크스페이스 공유. 이는 LOB 기반 아키텍처에서도 가능하지만, 보다 엄격한 분리로 인해 복잡한 경우가 많습니다.

이 접근 방식은 LOB 기반 격리와 동일한 강점과 약점을 많이 공유하지만, 더 많은 유연성을 제공하고 현대적인 Lakehouse에서 프로젝트의 가치를 강조합니다. 점점 더 많은 경우, 이는 기술이 주로 비용 동인에서 가치 창출자로 이동함에 따라 워크스페이스 구성의 “골드 스탠다드”가 되고 있습니다. 언제나 그렇듯이, 비즈니스 요구 사항에 따라 엄격한 LOB 기반 Lakehouse 구조에서 벗어나, 예를 들어 특히 대규모 프로젝트, LOB 간 프로젝트, 클라우드 리소스의 더 많거나 적은 분리 등을 위해 전용 개발/스테이징/프로덕션 환경을 사용하는 것과 같은 약간의 편차가 발생할 수 있습니다. 정확한 구조에 관계없이 다음 모범 사례를 제안합니다.

• 가능한 한 많은 데이터를 공유하세요. 인프라 및 워크스페이스의 분리는 거버넌스 및 추적에 유용하지만, 리소스의 확산은 빠르게 부담이 됩니다. 사전에 신중하게 분석하면 재사용할 수 있는 영역을 식별하는 데 도움이 됩니다.
• 프로젝트 간에 광범위하게 공유하지 않는 경우에도 가능한 한 Unity Catalog와 같은 공유 메타스토어 및 공유 코드베이스(예: Repos 사용)를 사용하세요.
• Terraform(또는 유사한 도구)을 사용하여 워크스페이스 및 클라우드 인프라를 생성, 관리 및 삭제하는 프로세스를 자동화하세요.
• 샌드박스 환경을 통해 사용자에게 유연성을 제공하되, 클러스터 크기, 데이터 액세스 등을 제한하기 위한 적절한 안전 장치가 마련되어 있는지 확인하세요.

요약

Lakehouse의 모든 이점을 최대한 활용하고 향후 성장 및 관리 용이성을 지원하려면 워크스페이스 레이아웃을 신중하게 계획해야 합니다. 이 설계 중에 고려해야 할 다른 관련 아티팩트에는 협업을 지원하지만 보안을 손상시키지 않는 중앙 집중식 모델 레지스트리, 코드베이스 및 카탈로그가 포함됩니다. 이 문서 전체에서 강조된 모범 사례를 요약하기 위해 주요 내용은 다음과 같습니다.

모범 사례 #1: 가능한 한 (클라우드 공급업체 및 Databricks 수준 모두에서) 최상위 계정 수를 최소화하고, 규정 준수, 격리 또는 지리적 제약 조건으로 인해 분리가 필요한 경우에만 워크스페이스를 생성하세요. 의심스러울 때는 간단하게 유지하세요!

모범 사례 #2: 과도한 복잡성 없이 장기적인 유연성을 제공할 격리 전략을 결정하세요. 요구 사항에 대해 현실적으로 판단하고 워크로드를 Lakehouse에 온보딩하기 전에 엄격한 지침을 구현하세요. 즉, 두 번 측정하고 한 번 자르세요!

모범 사례 #3: 클라우드 프로세스를 자동화하세요. 이는 SSO/SCIM, Terraform과 같은 도구를 사용한 코드형 인프라, CI/CD 파이프라인 및 Repos, 클라우드 백업 및 모니터링(클라우드 네이티브 및 타사 도구 모두 사용)을 포함한 인프라의 모든 측면에 걸쳐 있습니다.

모범 사례 #4: 반복 가능한 데이터 및 머신러닝 파이프라인 측면이 템플릿화되고 자동화되어 다양한 데이터 팀이 충분한 안전 장치를 갖춘 셀프 서비스 기능을 사용할 수 있도록 엔터프라이즈 전체 전략의 중앙 거버넌스를 위한 COE 팀을 설립하는 것을 고려하세요. COE 팀은 종종 데이터 팀을 위한 가볍지만 중요한 허브이며, 문서, SOP, 사용 방법 및 FAQ를 유지 관리하여 다른 사용자를 교육하는 데 중점을 두어야 합니다.

모범 사례 #5: Lakehouse는 Data Lake가 제공하지 않는 수준의 거버넌스를 제공합니다. 이를 활용하세요! Lakehouse를 설정하는 첫 단계 중 하나로 규정 준수 및 거버넌스 요구 사항을 평가하고, Databricks가 제공하는 기능을 활용하여 위험을 최소화하세요. 여기에는 감사 로그 제공, HIPAA 및 PCI(해당하는 경우), 적절한 유출 제어, ACL 및 사용자 제어 사용, 위의 모든 항목에 대한 정기적인 검토가 포함됩니다.

가까운 미래에 데이터 거버넌스부터 사용자 관리까지 다양한 주제에 대한 관리 모범 사례 블로그를 더 제공할 예정입니다. 그동안 워크스페이스 관리 또는 Databricks Lakehouse Platform의 모범 사례에 대해 더 자세히 알고 싶으시면 Databricks 계정 팀에 문의하세요!

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