이 게시물은 Claudia Chitu와 공동으로 작성되었습니다. ACAST의 Spyridon Dosis.

2014 년에 설립 된, Acasta 는 세계 최고의 독립 팟캐스트 회사로, 팟캐스트 제작자와 팟캐스트 광고주에게 최고의 청취 경험을 선사합니다. Acast는 팟캐스팅을 위한 독립적이고 개방적인 생태계를 옹호함으로써 성공하는 데 필요한 도구와 수익화를 통해 팟캐스팅을 촉진하는 것을 목표로 합니다.

이 회사는 AWS 클라우드 서비스를 사용하여 데이터 기반 제품을 구축하고 엔지니어링 모범 사례를 확장합니다. 성장 및 수익성 단계에서 지속 가능한 데이터 플랫폼을 보장하기 위해 기술 팀은 분산형 플랫폼을 채택했습니다. 데이터 메쉬 아키텍처.

이 게시물에서는 Acast가 데이터 메시 개념을 사용하여 대규모 데이터 작업을 수행하는 팀 간의 결합 종속성 문제를 어떻게 극복했는지 논의합니다.

문제

가속화된 성장과 확장으로 Acast는 전 세계적으로 공감되는 과제에 직면했습니다. Acast는 다양한 사업부와 조직 전반에 걸쳐 생성된 방대한 양의 데이터를 보유하고 있습니다. 기존의 모놀리스 및 중앙 집중식 아키텍처는 증가하는 데이터 소비자의 요구를 충족하는 데 어려움을 겪고 있었습니다. 데이터 엔지니어들은 데이터 인프라를 유지 관리하고 확장하는 것이 점점 더 어려워지고 있으며, 이로 인해 데이터 액세스, 데이터 사일로 및 데이터 관리의 비효율성이 발생하고 있습니다. 주요 목표는 비즈니스 요구 사항부터 시작하여 엔드투엔드 사용자 경험을 향상시키는 것이었습니다.

Acast는 운영 규모에 도달하기 위해 이러한 문제를 해결해야 했습니다. 즉, 독립적으로 운영하고 가치를 제공할 수 있는 인력의 수가 전 세계적으로 최대화되는 것을 의미합니다. 이 경우 Acast는 이러한 모놀리식 구조의 문제와 제품 팀, 기술 팀, 최종 소비자를 위한 높은 가치 실현 시간을 해결하려고 노력했습니다. AWS 계정이 없는 운영 또는 비즈니스 팀을 포함한 다른 제품 및 기술 팀도 있다는 점을 언급할 가치가 있습니다.

Acast에는 다양한 수의 제품 팀이 있으며 기존 팀을 병합, 분할, 새로운 인력 추가 또는 단순히 새 팀 생성을 통해 지속적으로 발전하고 있습니다. 지난 2년 동안 각 팀은 10~20명으로 구성된 4~10개 팀을 보유했습니다. 각 팀은 소유권에 따라 최소 10개, 최대 XNUMX개의 AWS 계정을 소유합니다. 이러한 계정에서 생성된 데이터의 대부분은 비즈니스 인텔리전스(BI) 목적을 위해 다운스트림으로 사용됩니다. 아마존 아테나, 매일 수백 명의 비즈니스 사용자가

Acast가 구현한 솔루션은 AWS를 기반으로 설계된 데이터 메시입니다. 솔루션은 명시적인 아키텍처 결정보다는 조직 구조를 반영합니다. Inverse Conway Maneuver에 따르면 Acast의 기술 아키텍처는 비즈니스 아키텍처와 동형을 나타냅니다. 이 경우 비즈니스 사용자는 데이터 메시 아키텍처를 통해 더 빠르게 통찰력을 얻고 도메인별 소유자가 누구인지 직접 알 수 있어 협업 속도가 빨라집니다. 역할 중 하나가 비즈니스 그룹 전용이므로 AWS 인증에 사용되는 AWS Identity and Access Management(IAM) 역할에 대해 논의할 때 이에 대해 더 자세히 설명하겠습니다.

성공의 매개변수

Acast는 새로운 팀 및 도메인 중심 데이터 제품과 해당 인프라 및 설정을 부트스트랩하고 확장하는 데 성공하여 통찰력을 수집하는 데 있어 마찰이 줄어들고 사용자와 소비자가 더 행복해졌습니다.

구현의 성공은 데이터 인프라, 데이터 관리 및 비즈니스 결과의 다양한 측면을 평가하는 것을 의미했습니다. 그들은 측정항목과 지표를 다음 범주로 분류했습니다.

• 데이터 사용 – 누가 어떤 데이터 소스를 소비하는지에 대한 명확한 이해가 소비자와 생산자의 매핑을 통해 구체화됩니다. 사용자와의 토론을 통해 사용자는 더 간단한 방법, 보다 구조화된 데이터 구성, 생산자가 누구인지에 대한 명확한 매핑으로 데이터에 더 빠르게 액세스할 수 있는 것이 더 행복하다는 사실이 나타났습니다. 데이터 기반 문화(데이터 활용 능력, 데이터 공유, 사업부 간 협업)를 발전시키는 데 많은 진전이 있었습니다.
• 데이터 거버넌스 – 데이터 소스를 사용할 수 있는 시기(기타 세부 사항 중에서)를 알려주는 서비스 수준 개체를 통해 팀은 누구에게 알릴지 알 수 있으며, 데이터가 늦게 들어오거나 데이터에 다른 문제가 있는 경우 더 짧은 시간에 알릴 수 있습니다. 데이터 관리자 역할이 확립되면서 소유권이 강화되었습니다.
• 데이터 팀 생산성 – Acast는 엔지니어링 회고를 통해 팀이 데이터 도메인과 관련된 의사 결정의 자율성을 높이 평가한다는 사실을 발견했습니다.
• 비용 및 자원 효율성 – 이는 Acast가 확장을 활성화하는 동안 여러 계정에서 데이터를 읽어 데이터 중복이 감소하고 그에 따른 비용 절감(일부 계정에서는 데이터 복사본 100% 제거)을 관찰한 영역입니다.

데이터 메시 개요

데이터 메시는 도메인 지향, 셀프 서비스 설계(소프트웨어 개발 관점에서)를 사용하여 분산형 데이터 아키텍처를 구축하기 위한 사회기술적 접근 방식으로 Eric Evans의 도메인 중심 설계 이론과 Manuel Pais 및 Matthew Skelton의 이론을 차용합니다. 팀 토폴로지 이론. 데이터 메시가 무엇인지 이해하기 위한 컨텍스트를 설정하는 것이 중요합니다. 왜냐하면 이는 뒤따르는 기술적 세부 사항에 대한 단계를 설정하고 이 게시물에서 논의된 개념이 데이터 메시의 더 넓은 프레임워크에 어떻게 적용되는지 이해하는 데 도움이 될 수 있기 때문입니다.

Acast 구현에 대해 자세히 알아보기 전에 요약하자면 데이터 메시 개념은 다음 원칙을 기반으로 합니다.

• 일류 관심사인 파이프라인과 달리 도메인 중심입니다.
• 데이터를 제품으로 제공합니다.
• 사용자를 기쁘게 하는 좋은 제품입니다. (데이터는 신뢰할 수 있고 문서가 제공되며 쉽게 사용할 수 있습니다.)
• 연합된 컴퓨팅 거버넌스와 분산된 소유권을 제공하는 셀프 서비스 데이터 플랫폼입니다.

도메인 기반 아키텍처

운영 및 분석 데이터 세트를 소유하는 Acast의 접근 방식에서 팀은 도메인 기반 소유권으로 구성되어 API를 통해 데이터 생산자로부터 직접 읽거나 Amazon S3 스토리지에서 프로그래밍 방식으로 읽거나 Athena를 SQL 쿼리 엔진으로 사용합니다. Acast 도메인의 몇 가지 예가 다음 그림에 나와 있습니다.

앞의 그림에 표시된 것처럼 일부 도메인은 소유권이 다른 다른 도메인의 운영 또는 분석 엔드포인트에 느슨하게 연결되어 있습니다. 다른 사람들은 비즈니스에 대한 의존도가 더 높을 수 있습니다(일부 팟캐스터는 광고주가 될 수도 있고, 자체 프로그램을 위한 후원 광고를 만들고 캠페인을 실행하거나 Acast의 소프트웨어를 서비스로 사용하여 광고를 거래할 수도 있습니다).

제품으로서의 데이터

데이터를 제품으로 취급하려면 데이터 자체, 메타데이터, 관련 코드 및 인프라라는 세 가지 주요 구성 요소가 필요합니다. 이 접근 방식에서는 데이터 생성을 담당하는 팀을 다음과 같이 지칭합니다. 생산. 이러한 생산자 팀은 소비자에 대한 심층적인 지식을 보유하고 있으며 데이터 제품이 어떻게 활용되는지 이해하고 있습니다. 데이터 생산자가 계획한 모든 변경 사항은 모든 소비자에게 사전에 전달됩니다. 이러한 사전 알림을 통해 다운스트림 프로세스가 중단되지 않습니다. 소비자에게 사전 통지를 제공함으로써 소비자는 다가오는 변화에 대비하고 적응할 수 있는 충분한 시간을 갖게 되며 원활하고 중단 없는 작업 흐름을 유지할 수 있습니다. 생산자는 초기 데이터 세트의 새 버전을 병렬로 실행하고, 소비자에게 개별적으로 알리고, 새 버전 사용을 시작하는 데 필요한 기간에 대해 논의합니다. 모든 소비자가 새 버전을 사용하는 경우 생산자는 초기 버전을 사용할 수 없도록 만듭니다.

데이터 스키마는 팀 간에 파일을 공유하기 위해 합의된 공통 형식(Acast의 경우 Parquet)에서 추론됩니다. 데이터는 파일, 일괄 처리 또는 스트림 이벤트 등에서 공유될 수 있습니다. 각 팀에는 자체 인프라를 갖춘 독립적이고 자율적인 엔터티 역할을 하는 자체 AWS 계정이 있습니다. 오케스트레이션을 위해 그들은 AWS 클라우드 개발 키트 코드형 인프라(IaC)용 (AWS CDK) 및 AWS 접착제 메타데이터 관리를 위한 데이터 카탈로그. 사용자는 생산자에게 데이터 표시 방식을 개선하거나 더 높은 비즈니스 가치를 창출하기 위해 새로운 데이터 포인트로 데이터를 강화하도록 요청할 수도 있습니다.

각 팀이 AWS 계정과 Athena의 데이터 카탈로그 ID를 소유하고 있으므로 모든 계정의 모든 카탈로그를 매핑하는 공통 카탈로그를 사용하여 Amazon S3 위에 분산된 데이터 레이크의 렌즈를 통해 이를 쉽게 확인할 수 있습니다.

동시에 각 팀은 다른 카탈로그를 자신의 계정에 매핑하고 자신의 데이터를 사용하여 다른 계정의 데이터와 함께 생성할 수도 있습니다. 민감한 데이터가 아닌 이상, 프로그래밍 방식으로 또는 다음에서 데이터에 액세스할 수 있습니다. AWS 관리 콘솔 데이터 인프라 엔지니어에게 의존하지 않고 셀프 서비스 방식으로 이는 도메인에 구애받지 않고 데이터를 셀프 서비스하는 공유 방법입니다. 제품 검색은 카탈로그 등록을 통해 이루어집니다. Acast는 상호 운용성을 위해 회사 전체에서 일반적으로 합의되고 채택된 몇 가지 표준만을 사용하여 단편화된 사일로와 데이터 교환 또는 도메인에 구애받지 않는 데이터 소비에 대한 마찰을 해결했습니다.

이 원칙을 통해 팀은 데이터가 안전하고 신뢰할 수 있으며 정확하다는 확신을 얻을 수 있으며 각 도메인 수준에서 적절한 액세스 제어가 관리됩니다. 또한 중앙 계정에서는 다음을 사용하여 다양한 유형의 권한 및 액세스에 대한 역할이 정의됩니다. AWS IAM 자격 증명 센터 권한. 모든 데이터 세트는 단일 중앙 계정에서 검색할 수 있습니다. 다음 그림은 두 가지 유형의 사용자(소비자) 그룹이 두 가지 IAM 역할을 가정하는 방식을 보여줍니다. 하나는 제한된 데이터인 제한된 데이터 세트에 대한 액세스 권한이 있는 그룹이고 다른 하나는 제한되지 않은 데이터에 대한 액세스 권한이 있는 그룹입니다. 데이터 처리 작업에 사용되는 것과 같은 서비스 계정에 대해 이러한 역할을 맡는 방법도 있습니다. Apache Airflow용 Amazon 관리형 워크플로 (아마존 MWAA) 등이 있습니다.

Acast가 높은 정렬과 느슨하게 결합된 아키텍처를 해결하는 방법

다음 다이어그램은 Acast 팀이 데이터를 구성하고 서로 협력하는 방법에 대한 개념적 아키텍처를 보여줍니다.

Acast는 다음을 사용했습니다. 잘 설계된 프레임워크 중앙 계정이 클라우드에서 분석 워크로드를 실행하는 방식을 개선하기 위한 것입니다. 도구의 렌즈를 통해 Acast는 더 나은 모니터링 문제를 해결할 수 있었습니다. 비용 최적화, 성능 및 보안. 워크로드를 개선할 수 있는 영역과 자동화된 솔루션을 통해 일반적인 문제를 해결하는 방법, 성공을 측정하는 방법, KPI를 정의하는 방법을 이해하는 데 도움이 되었습니다. 그렇지 않으면 찾는 데 더 오랜 시간이 걸렸을 학습 내용을 얻는 데 시간이 절약되었습니다. Acast의 정보 보안 책임자인 Spyridon Dosis는 다음과 같이 말합니다. “AWS가 항상 다중 계정 설정의 구성, 평가 및 검토를 가능하게 하는 도구를 출시하는 데 앞장서서 기쁩니다. 이는 분산된 조직에서 일하는 우리에게 큰 장점입니다.” Spyridon은 또한 "우리가 중요하게 생각하는 매우 중요한 개념은 AWS 보안 기본값(예: S3 버킷의 기본 암호화)입니다."라고 덧붙입니다.

아키텍처 다이어그램에서는 중앙 데이터 플랫폼 역할을 하는 중앙 계정을 소유한 팀을 제외하고 각 팀이 데이터 생산자가 될 수 있으며 전체 비즈니스 그림을 그리기 위해 여러 도메인의 논리를 모델링하는 것을 볼 수 있습니다. 다른 모든 팀은 데이터 생산자 또는 데이터 소비자가 될 수 있습니다. 중앙 계정에 연결하고 교차 계정 AWS Glue 데이터 카탈로그를 통해 데이터 세트를 검색하고, Athena 쿼리 편집기 또는 Athena 노트북을 사용하여 분석하거나, 카탈로그를 자신의 AWS 계정에 매핑할 수 있습니다. 중앙 Athena 카탈로그에 대한 액세스는 공개 데이터 및 제한된 데이터 액세스에 대한 역할을 갖춘 IAM ID 센터를 통해 구현됩니다.

중요하지 않은 데이터(공개 데이터)의 경우 Acast는 다음 코드 조각과 같이 조직 할당 ID 매개 변수를 제공하는 조건을 사용하여 기본적으로 전체 조직에서 읽을 수 있도록 데이터 세트가 열려 있는 템플릿을 사용합니다.

{
    "Version": "2012-10-17",
    "Statement": [
        
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
               "s3:GetObject*",
                "s3:GetBucket*",
                "s3:List*"  
            ],
            "Resource": [
                "arn:aws:s3:::DOC-EXAMPLE-BUCKET",
                "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalOrgID": "ORG-ID-NUMBER"
                }
            }
        }
    ]
}

재무와 같은 민감한 데이터를 처리할 때 팀은 협업 데이터 관리자 모델을 사용합니다. 데이터 관리자는 요청자와 협력하여 의도된 사용 사례에 대한 액세스 정당성을 평가합니다. 이들은 함께 보안을 유지하면서 요구 사항을 충족하는 적절한 액세스 방법을 결정합니다. 여기에는 IAM 역할, 서비스 계정 또는 특정 AWS 서비스가 포함될 수 있습니다. 이 접근 방식을 사용하면 기술 조직 외부(즉, AWS 계정이 없음)의 비즈니스 사용자가 필요한 정보에 독립적으로 액세스하고 분석할 수 있습니다. AWS Glue 리소스 및 S3 버킷에 대한 IAM 정책을 통해 액세스 권한을 부여함으로써 Acast는 셀프 서비스 기능을 제공하는 동시에 인적 검토를 통해 민감한 데이터를 관리합니다. 데이터 관리자 역할은 사용 사례를 이해하고, 보안 위험을 평가하고, 궁극적으로 분석적 통찰력을 통해 비즈니스를 가속화하는 액세스를 촉진하는 데 유용했습니다.

Acast 사용 사례의 경우 세분화된 행 또는 열 수준 액세스 제어가 필요하지 않았으므로 접근 방식이 충분했습니다. 그러나 다른 조직에서는 민감한 데이터 필드에 대해 보다 세분화된 거버넌스가 필요할 수 있습니다. 이러한 경우 다음과 같은 솔루션이 있습니다. AWS Lake 형성 셀프 서비스 데이터 액세스 모델을 제공하면서 필요한 권한을 구현할 수 있습니다. 자세한 내용은 다음을 참조하세요. AWS Lake Formation 및 AWS Glue를 사용하여 데이터 메시 아키텍처 설계.

동시에 팀은 Amazon S3 또는 API를 통해 다른 생산자로부터 직접 읽을 수 있으므로 종속성을 최소한으로 유지하여 개발 및 제공 속도를 높일 수 있습니다. 따라서 계정은 동시에 생산자이자 소비자가 될 수 있습니다. 각 팀은 자율적이며 자체 기술 스택에 대한 책임이 있습니다.

추가 학습

Acast는 무엇을 배웠나요? 지금까지 우리는 아키텍처 설계가 조직 구조의 영향이라는 점을 논의했습니다. 기술 조직은 여러 부서 간 팀으로 구성되어 있고 데이터 메시의 공통 원칙에 따라 새 팀을 부트스트랩하는 것이 간단하기 때문에 Acast는 이것이 매번 원활하게 진행되지는 않는다는 것을 깨달았습니다. AWS에서 완전히 새로운 계정을 설정하기 위해 팀은 동일한 여정을 거치지만 고유한 특성을 고려하여 약간 다릅니다.

이로 인해 특정 마찰이 발생할 수 있으며 모든 데이터 생산 팀이 데이터 생산자로서 높은 성숙도에 도달하도록 하는 것은 어렵습니다. 이는 전담 데이터 팀이 아닌 다기능 팀의 다양한 데이터 역량으로 설명할 수 있습니다.

분산형 솔루션을 구현함으로써 Acast는 진화하는 비즈니스 요구 사항에 맞춰 팀을 조정함으로써 확장성 문제를 효과적으로 해결했습니다. 이 접근 방식은 높은 분리 및 정렬을 보장합니다. 또한 업스트림 소스를 쉽게 알 수 있고 지정된 SLA를 통해 쉽게 액세스할 수 있기 때문에 소유권을 강화하여 문제를 식별하고 해결하는 데 필요한 시간을 크게 단축했습니다. 비즈니스 사용자가 더 빠른 통찰력을 얻을 수 있게 되면서 데이터 지원 문의량이 50% 이상 감소했습니다. 특히 이전에는 다운스트림 요청을 이행하기 위해서만 복사되었던 수십 테라바이트의 중복 스토리지를 성공적으로 제거했습니다. 이러한 성과는 교차 계정 읽기 구현을 통해 가능해졌으며, 이로 인해 파이프라인에 대한 관련 개발 및 유지 관리 비용이 제거되었습니다.

결론

Acast는 Inverse Conway Maneuver 법칙을 사용하고 각 다기능 제품 팀이 자체 AWS 계정을 갖는 AWS 서비스를 사용하여 확장성, 높은 소유권 및 셀프 서비스 데이터 소비를 허용하는 데이터 메시 아키텍처를 구축했습니다. 이는 데이터 소유권 및 운영에 접근하는 방법과 관련하여 회사의 엔지니어링 원칙을 충족하여 의도적인 의도가 아닌 효과로 데이터 메시를 갖게 되는 방식과 관련하여 회사에 잘 작동했습니다. 다른 조직의 경우 원하는 데이터 메시가 다르게 보일 수 있으며 접근 방식에서 다른 교훈을 얻을 수도 있습니다.

결론적으로, AWS의 최신 데이터 아키텍처 성능 저하 없이 저렴한 비용으로 데이터 제품 및 데이터 메시 인프라를 효율적으로 구축할 수 있습니다.

다음은 AWS에서 원하는 데이터 메시를 설계하는 데 사용할 수 있는 AWS 서비스의 몇 가지 예입니다.

저자에 관하여

클라우디아 치투 데이터 전략가이자 분석 분야의 영향력 있는 리더입니다. 데이터 이니셔티브를 조직의 전반적인 전략적 목표에 맞추는 데 중점을 두고 있는 그녀는 데이터를 장기 계획과 지속 가능한 성장을 위한 지도력으로 활용합니다.

스피리돈 도시스 Acast의 정보 보안 전문가입니다. Spyridon은 회사와 사용자의 데이터를 보호하는 안전한 방식으로 서비스를 설계, 구현 및 운영하는 조직을 지원합니다.

스리칸트 다스 Amazon Web Services의 Acceleration Lab 솔루션 설계자입니다. 그는 빅 데이터 분석 및 데이터 엔지니어링 분야에서 13년 이상의 경험을 보유하고 있으며 안정적이고 확장 가능하며 효율적인 솔루션 구축을 즐깁니다. 업무 외에 그는 여행을 즐기고 자신의 경험을 소셜 미디어에 블로그에 올리는 것을 즐깁니다.

• SEO 기반 콘텐츠 및 PR 배포. 오늘 증폭하십시오.
• PlatoData.Network 수직 생성 Ai. 자신에게 권한을 부여하십시오. 여기에서 액세스하십시오.
• PlatoAiStream. 웹3 인텔리전스. 지식 증폭. 여기에서 액세스하십시오.
• 플라톤ESG. 탄소, 클린테크, 에너지, 환경, 태양광, 폐기물 관리. 여기에서 액세스하십시오.
• PlatoHealth. 생명 공학 및 임상 시험 인텔리전스. 여기에서 액세스하십시오.
• 출처: https://aws.amazon.com/blogs/big-data/design-a-data-mesh-on-aws-that-reflects-the-envisioned-organization/