Bu yazı Claudia Chitu ile birlikte yazılmıştır ve ACAST'tan Spyridon Dosis.

2014 yılında kurulan, Acast dünyanın önde gelen bağımsız podcast şirketidir ve podcast yaratıcılarını ve podcast reklamverenlerini en üst düzey dinleme deneyimi için yükseltir. Acast, podcasting için bağımsız ve açık bir ekosistemi savunarak, podcasting'i gelişmek için gereken araçlarla ve para kazanmayla desteklemeyi hedefliyor.

Şirket, veriye dayalı ürünler oluşturmak ve mühendisliğin en iyi uygulamalarını ölçeklendirmek için AWS Cloud hizmetlerini kullanıyor. Büyüme ve kârlılık aşamalarının ortasında sürdürülebilir bir veri platformu sağlamak için teknoloji ekipleri merkezi olmayan bir sistemi benimsedi. veri ağı mimarisi.

Bu yazıda Acast'in, veri ağı konseptini kullanarak geniş ölçekte verilerle çalışan ekipler arasındaki birleşik bağımlılıklar sorununun üstesinden nasıl geldiğini tartışıyoruz.

Sorun

Hızlandırılmış büyüme ve genişlemeyle Acast, dünya çapında yankı uyandıran bir zorlukla karşılaştı. Acast, kendisini çeşitli iş birimleri ve kuruluş genelinde üretilen büyük miktarda veriyle karşı karşıya buldu. Mevcut monolit ve merkezi mimari, veri tüketicilerinin artan taleplerini karşılamakta zorlanıyordu. Veri mühendisleri, veri altyapısını korumayı ve ölçeklendirmeyi giderek daha zor buluyor, bu da veri erişimine, veri silolarına ve veri yönetiminde verimsizliklere neden oluyordu. Temel hedeflerden biri, iş ihtiyaçlarından başlayarak uçtan uca kullanıcı deneyimini geliştirmekti.

Acast'in operasyonel ölçeğe, yani bağımsız olarak çalışabilecek ve değer sunabilecek küresel maksimum insan sayısına ulaşabilmek için bu zorlukların üstesinden gelmesi gerekiyordu. Bu durumda Acast, bu yekpare yapının getirdiği zorluklarla ve ürün ekipleri, teknoloji ekipleri ve son tüketiciler için yüksek değer elde etme süresiyle mücadele etmeye çalıştı. Operasyon ekipleri veya iş ekipleri de dahil olmak üzere AWS hesapları olmayan başka ürün ve teknoloji ekiplerinin de bulunduğunu belirtmekte fayda var.

Acast'in, mevcut ekipleri birleştirerek, bölerek, yeni insanlar ekleyerek veya yalnızca yeni ekipler oluşturarak sürekli gelişen değişken sayıda ürün ekibi vardır. Son 2 yılda her biri 10-20 kişiden oluşan 4-10 arası ekip oluşturdular. Her ekibin en az iki AWS hesabı, sahipliğe bağlı olarak en fazla 10 hesabı vardır. Bu hesaplar tarafından üretilen verilerin çoğunluğu iş zekası (BI) amaçları için aşağı yönde kullanılır ve Amazon Atina, her gün yüzlerce iş kullanıcısı tarafından.

The solution Acast implemented is a data mesh, architected on AWS. The solution mirrors the organizational structure rather than an explicit architectural decision. As per the Inverse Conway Maneuver, Acast’s technology architecture displays isomorphism with the business architecture. In this case, the business users are enabled through the data mesh architecture to get faster time to insights and know directly who the domain-specific owners are, speeding up collaboration. This will be further detailed when we discuss the AWS Identity and Access Management (IAM) roles used in our AWS certification because one of the roles is dedicated to the business group.

Başarı parametreleri

Acast, yeni bir ekip ve etki alanı odaklı veri ürününü ve buna karşılık gelen altyapıyı ve kurulumu önyükleme ve ölçeklendirmeyi başardı; bu da içgörü toplamada daha az anlaşmazlık ve daha mutlu kullanıcılar ve tüketicilerle sonuçlandı.

Uygulamanın başarısı, veri altyapısının, veri yönetiminin ve iş sonuçlarının çeşitli yönlerinin değerlendirilmesi anlamına geliyordu. Metrikleri ve göstergeleri aşağıdaki kategorilerde sınıflandırdılar:

• Veri kullanımı – Tüketicilerin ve üreticilerin haritalanmasıyla hayata geçirilen, kimin hangi veri kaynağını tükettiğinin net bir şekilde anlaşılması. Kullanıcılarla yapılan tartışmalar, verilere daha basit bir şekilde daha hızlı erişime, daha yapılandırılmış bir veri organizasyonuna ve üreticinin kim olduğuna dair net bir haritaya sahip olmaktan daha mutlu olduklarını gösterdi. Veriye dayalı kültürlerini (veri okuryazarlığı, veri paylaşımı ve iş birimleri arasında işbirliği) geliştirmek için çok fazla ilerleme kaydedildi.
• Veri yönetimi – Veri kaynaklarının ne zaman kullanılabilir olduğunu belirten hizmet seviyesi nesneleri (diğer ayrıntıların yanı sıra) sayesinde ekipler kime bildirimde bulunacaklarını bilir ve geç veri geldiğinde veya verilerle ilgili başka sorunlar olduğunda bunu daha kısa sürede yapabilirler. Veri sorumlusu rolünün uygulamaya konması sayesinde sahiplik güçlendirildi.
• Veri ekibi üretkenliği – Acast, mühendislik retrospektifleri sayesinde ekiplerinin veri alanlarıyla ilgili kararlar alırken özerkliğe değer verdiğini keşfetti.
• Maliyet ve kaynak verimliliği – Bu, Acast'in ölçeklendirmeyi etkinleştirirken hesaplar arasında veri okuyarak veri tekrarında bir azalma ve dolayısıyla maliyette azalma (bazı hesaplarda veri kopyasının %100 kaldırılması) gözlemlediği bir alandır.

Veri ağına genel bakış

Veri ağı, alan odaklı, kendi kendine hizmet eden bir tasarım (yazılım geliştirme perspektifinde) kullanarak merkezi olmayan bir veri mimarisi oluşturmaya yönelik sosyoteknik bir yaklaşımdır ve Eric Evans'ın alan odaklı tasarım teorisi ile Manuel Pais ve Matthew Skelton'ın teorisini ödünç alır. takım topolojileri teorisi. Veri ağının ne olduğunu anlamak için bağlamı oluşturmak önemlidir çünkü takip eden teknik ayrıntılara zemin hazırlar ve bu yazıda tartışılan kavramların veri ağının daha geniş çerçevesine nasıl uyduğunu anlamanıza yardımcı olabilir.

Acast'in uygulamasına daha derinlemesine dalmadan önce özetlemek gerekirse, veri ağı konsepti aşağıdaki ilkelere dayanmaktadır:

• Birinci sınıf bir sorun olan boru hatlarının aksine etki alanına dayalıdır
• Veriyi bir ürün olarak sunar
• Kullanıcıları memnun eden iyi bir üründür (veriler güvenilirdir, belgeler mevcuttur ve kolayca tüketilebilir)
• Birleştirilmiş bilişimsel yönetim ve merkezi olmayan sahiplik (self-servis veri platformu) sunar

Etki alanı odaklı mimari

Acast'in operasyonel ve analitik veri kümelerine sahip olma yaklaşımında ekipler, etki alanına dayalı sahiplik, bir API aracılığıyla doğrudan veri üreticisinden okuma veya Amazon S3 depolama alanından programlı olarak ya da Athena'yı SQL sorgu motoru olarak kullanma şeklinde yapılandırılmıştır. Acast etki alanlarının bazı örnekleri aşağıdaki şekilde gösterilmektedir.

Önceki şekilde gösterildiği gibi, bazı alanlar diğer alanların operasyonel veya analitik uç noktalarına farklı bir sahiplikle gevşek bir şekilde bağlanmıştır. Diğerleri ise beklendiği gibi iş konusunda daha güçlü bir bağımlılığa sahip olabilir (bazı podcast yayıncıları aynı zamanda reklamveren olabilir, kendi şovları için sponsorluk yaratıcıları oluşturabilir ve kampanyalar yürütebilir veya Acast'in yazılımını bir hizmet olarak kullanarak reklam işlemleri gerçekleştirebilir).

Ürün olarak veri

Verileri bir ürün olarak ele almak üç temel bileşeni gerektirir: verinin kendisi, meta veriler ve ilgili kod ve altyapı. Bu yaklaşımda veri üretmekten sorumlu ekiplere denir. üreticileri. Bu üretici ekipleri, tüketicileri hakkında derinlemesine bilgiye sahiptir ve veri ürünlerinin nasıl kullanıldığını anlar. Veri üreticileri tarafından planlanan değişiklikler önceden tüm tüketicilere iletilmektedir. Bu proaktif bildirim, aşağı yönlü süreçlerin kesintiye uğramamasını sağlar. Tüketicilere önceden bildirimde bulunulması sayesinde, yaklaşan değişikliklere hazırlanmak ve uyum sağlamak için yeterli zamana sahip olurlar, sorunsuz ve kesintisiz bir iş akışı sağlarlar. Üreticiler, ilk veri setinin yeni bir versiyonunu paralel olarak çalıştırıyor, tüketicileri bireysel olarak bilgilendiriyor ve onlarla yeni sürümü kullanmaya başlamak için gerekli zaman dilimini tartışıyor. Tüm tüketiciler yeni sürümü kullanırken üreticiler ilk sürümü kullanım dışı bırakıyor.

Veri şemaları, ekipler arasında dosya paylaşımı için üzerinde anlaşmaya varılan ortak formattan (Acast durumunda Parke) çıkarılır. Veriler dosyalarda, toplu veya akış etkinliklerinde ve daha fazlasında paylaşılabilir. Her ekibin, kendi altyapısıyla bağımsız ve özerk bir varlık olarak hareket eden kendi AWS hesabı vardır. Orkestrasyon için şunu kullanırlar: AWS Bulut Geliştirme Kiti (AWS CDK), kod olarak altyapı (IaC) ve AWS Tutkal Meta veri yönetimi için Veri Katalogları. Kullanıcılar ayrıca üreticilerden, verilerin sunulma biçimini iyileştirmeleri veya daha yüksek bir iş değeri oluşturmak için verileri yeni veri noktalarıyla zenginleştirmeleri yönünde talepte bulunabilirler.

Her ekibin bir AWS hesabı ve Athena'dan bir veri kataloğu kimliği olması nedeniyle bunu, tüm hesaplardaki tüm katalogları eşleştiren ortak bir katalogla Amazon S3'ün üzerindeki dağıtılmış veri gölünün merceklerinden görmek kolaydır.

Aynı zamanda her ekip diğer katalogları kendi hesabına eşleyebilir ve kendi ürettiği verileri diğer hesaplardan gelen verilerle birlikte kullanabilir. Hassas veriler olmadığı sürece verilere programlı olarak veya AWS Yönetim Konsolu veri altyapısı mühendislerine bağımlı kalmadan self servis bir şekilde. Bu, verilere kendi kendine hizmet vermenin etki alanından bağımsız, paylaşılan bir yoludur. Ürün keşfi katalog kaydı yoluyla gerçekleşir. Acast, birlikte çalışabilirlik amacıyla şirket genelinde ortak olarak kabul edilen ve benimsenen yalnızca birkaç standardı kullanarak, parçalanmış siloları ve veri alışverişi veya etki alanından bağımsız verileri tüketme konusundaki anlaşmazlıkları ele aldı.

Bu prensiple ekipler, verilerin güvenli, güvenilir ve doğru olduğuna ve her etki alanı düzeyinde uygun erişim kontrollerinin yönetildiğine dair güvence alır. Ayrıca merkezi hesapta farklı izin ve erişim türleri için roller tanımlanır. AWS IAM Kimlik Merkezi izinler. Tüm veri kümeleri tek bir merkezi hesaptan keşfedilebilir. Aşağıdaki şekil, iki IAM rolünün iki tür kullanıcı (tüketici) grubu tarafından üstlenildiği şekilde bunun nasıl kullanıldığını göstermektedir: biri kısıtlı veri olan sınırlı bir veri kümesine erişimi olan, diğeri ise kısıtlanmamış verilere erişimi olan. Ayrıca, veri işleme işlerinde kullanılanlar gibi hizmet hesapları için bu rollerden herhangi birini üstlenmenin bir yolu da vardır. Apache Airflow için Amazon Tarafından Yönetilen İş Akışları (Amazon MWAA) örneğin.

Acast yüksek hizalama ve gevşek bağlı mimariyi nasıl çözdü?

Aşağıdaki diyagram, Acast ekiplerinin verileri nasıl organize ettiğine ve birbirleriyle nasıl işbirliği yaptığına dair kavramsal bir mimariyi göstermektedir.

Acast şunu kullandı: İyi Tasarlanmış Çerçeve merkezi hesabın bulutta analitik iş yüklerini çalıştırma uygulamasını geliştirmesi. Acast, aracın mercekleri sayesinde daha iyi izleme olanağı sunabildi. maliyet optimizasyonu, performans ve güvenlik. İş yüklerini iyileştirebilecekleri alanları ve otomatik çözümlerle ortak sorunları nasıl çözebileceklerini ve KPI'ları tanımlayarak başarının nasıl ölçüleceğini anlamalarına yardımcı oldu. Aksi takdirde bulmaları daha uzun sürecek olan bilgileri edinmeleri için onlara zaman kazandırdı. Acast'in Bilgi Güvenliği Sorumlusu Spyridon Dosis şunları paylaşıyor: "AWS'nin, çoklu hesap kurulumunun yapılandırılmasını, değerlendirilmesini ve gözden geçirilmesini sağlayan araçları yayınlama konusunda her zaman önde olmasından mutluyuz. Merkezi olmayan bir organizasyonda çalışmak bizim için büyük bir artı.” Spyridon ayrıca şunları ekliyor: "Değer verdiğimiz çok önemli bir kavram, AWS güvenlik varsayılanlarıdır (ör. S3 klasörleri için varsayılan şifreleme).

Mimari diyagramda, merkezi veri platformu olarak hizmet veren ve iş resminin tamamını boyamak için birden fazla alandan mantığı modelleyen merkezi hesaba sahip olan ekip dışında her ekibin bir veri üreticisi olabileceğini görebiliriz. Diğer tüm ekipler veri üreticisi veya veri tüketicisi olabilir. Merkezi hesaba bağlanabilir ve hesaplar arası AWS Glue Data Catalog aracılığıyla veri kümelerini keşfedebilir, bunları Athena sorgu düzenleyicisinde veya Athena not defterleriyle analiz edebilir veya kataloğu kendi AWS hesaplarıyla eşleyebilirler. Merkezi Athena kataloğuna erişim, açık veri ve kısıtlı veri erişimi rolleriyle IAM Identity Center ile gerçekleştirilir.

Hassas olmayan veriler (açık veriler) için Acast, aşağıdaki kod parçacığında gösterildiği gibi, kuruluş tarafından atanan kimlik parametresini sağlamaya yönelik bir koşul kullanarak, veri kümelerinin varsayılan olarak tüm kuruluşa okunmak üzere açık olduğu bir şablon kullanır:

{
    "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"
                }
            }
        }
    ]
}

Ekipler, finansal bilgiler gibi hassas verileri işlerken işbirliğine dayalı bir veri yönetimi modeli kullanıyor. Veri sorumlusu, amaçlanan kullanım durumu için erişim gerekçesini değerlendirmek üzere talep sahibiyle birlikte çalışır. Güvenliği korurken ihtiyacı karşılamak için uygun erişim yöntemlerini birlikte belirlerler. Bu, IAM rollerini, hizmet hesaplarını veya belirli AWS hizmetlerini içerebilir. Bu yaklaşım, teknoloji kuruluşu dışındaki iş kullanıcılarının (yani bir AWS hesabına sahip olmadıkları anlamına gelir) ihtiyaç duydukları bilgilere bağımsız olarak erişmelerine ve bunları analiz etmelerine olanak tanır. Acast, AWS Glue kaynakları ve S3 klasörleri üzerinde IAM politikaları aracılığıyla erişim izni vererek, bir yandan kendi kendine hizmet yetenekleri sağlarken bir yandan da hassas verileri insan incelemesi aracılığıyla yönetmeye devam eder. Veri sorumlusu rolü, kullanım örneklerini anlamak, güvenlik risklerini değerlendirmek ve sonuç olarak analitik içgörüler yoluyla işi hızlandıran erişimi kolaylaştırmak açısından değerli olmuştur.

Acast'in kullanım durumunda ayrıntılı satır veya sütun düzeyinde erişim kontrollerine ihtiyaç duyulmadığından yaklaşım yeterliydi. Ancak diğer kuruluşlar, hassas veri alanları üzerinde daha ayrıntılı bir yönetime ihtiyaç duyabilir. Bu durumlarda aşağıdaki gibi çözümler AWS Göl Oluşumu bir yandan kendi kendine hizmet veren bir veri erişim modeli sağlamaya devam ederken, diğer yandan gerekli izinleri uygulayabilir. Daha fazla bilgi için bkz. AWS Lake Formation ve AWS Glue kullanarak bir veri ağı mimarisi tasarlayın.

Aynı zamanda ekipler bağımlılığı minimumda tutarak diğer üreticilerden doğrudan, Amazon S3'ten veya bir API aracılığıyla bilgi okuyabilir ve bu da geliştirme ve teslimat hızını artırır. Dolayısıyla bir hesap paralel olarak hem üretici hem de tüketici olabilir. Her takım özerktir ve kendi teknoloji yığınından sorumludur.

Ek öğrenmeler

Acast ne öğrendi? Buraya kadar mimari tasarımın organizasyon yapısının bir etkisi olduğunu tartıştık. Teknoloji organizasyonu birden fazla işlevler arası ekipten oluştuğundan ve veri ağının ortak ilkelerini takip ederek yeni bir ekibin başlatılması kolay olduğundan, Acast bunun her zaman kusursuz bir şekilde ilerlemediğini öğrendi. AWS'de tamamen yeni bir hesap oluşturmak için ekipler aynı yolculuktan geçer ancak kendi özellikleri dikkate alındığında biraz farklıdır.

Bu, bazı sürtüşmeler yaratabilir ve tüm veri üreten ekiplerin veri üreticisi olma konusunda yüksek bir olgunluğa ulaşmasını sağlamak zordur. Bu, bu işlevler arası ekiplerdeki farklı veri yetkinlikleri ve özel veri ekiplerinin olmamasıyla açıklanabilir.

Acast, merkezi olmayan çözümü uygulayarak, ekiplerini gelişen iş ihtiyaçlarına uyum sağlayacak şekilde uyarlayarak ölçeklenebilirlik sorununu etkili bir şekilde çözdü. Bu yaklaşım yüksek düzeyde ayrıştırma ve hizalama sağlar. Ayrıca, yukarı akış kaynağının kolayca bilinmesi ve belirli SLA'larla kolayca erişilebilmesi nedeniyle sorunları tespit etmek ve çözmek için gereken süreyi önemli ölçüde azaltarak sahipliği güçlendirdiler. Veri desteği sorgularının hacminde %50'nin üzerinde bir azalma görüldü, çünkü iş kullanıcıları daha hızlı içgörü elde etme olanağına sahip oldu. Özellikle, daha önce yalnızca aşağı yöndeki istekleri karşılamak için kopyalanan onlarca terabaytlık yedek depolama alanını başarıyla ortadan kaldırdılar. Bu başarı, hesaplar arası okumanın uygulanmasıyla mümkün oldu ve bu işlem hatlarına yönelik ilgili geliştirme ve bakım maliyetlerinin ortadan kaldırılmasına yol açtı.

Sonuç

Acast, Ters Conway Manevrası yasasını kullandı ve ölçeklenebilirliğe, yüksek sahipliğe ve self servis veri tüketimine olanak tanıyan bir veri ağı mimarisi oluşturmak için her işlevler arası ürün ekibinin kendi AWS hesabına sahip olduğu AWS hizmetlerinden yararlandı. Bu, veri sahipliği ve operasyonlara nasıl yaklaşıldığı, mühendislik ilkelerinin karşılanması açısından şirket için iyi çalışıyor ve veri ağının kasıtlı bir amaç yerine bir etki olarak ortaya çıkmasına neden oluyor. Diğer kuruluşlar için istenen veri ağı farklı görünebilir ve yaklaşımın başka öğrenmeleri olabilir.

Sonuç olarak, bir AWS'de modern veri mimarisi performanstan ödün vermeden düşük maliyetle veri ürünlerini ve veri ağı altyapısını verimli bir şekilde oluşturmanıza olanak tanır.

Aşağıda, AWS'de istediğiniz veri ağını tasarlamak için kullanabileceğiniz bazı AWS hizmetleri örnekleri verilmiştir:

Yazarlar Hakkında

Claudia Chitu Veri stratejisti ve Analytics alanında etkili bir liderdir. Veri girişimlerini kuruluşun genel stratejik hedefleriyle uyumlu hale getirmeye odaklanarak, verileri uzun vadeli planlama ve sürdürülebilir büyüme için yol gösterici bir güç olarak kullanıyor.

Spyridon Dozu Acast'te Bilgi Güvenliği Uzmanıdır. Spyridon, şirketin ve kullanıcıların verilerini koruyacak şekilde hizmetlerinin güvenli bir şekilde tasarlanması, uygulanması ve işletilmesi konusunda kuruluşa destek olur.

Srikant Das Amazon Web Services'te Hızlandırma Laboratuvarı Çözümleri Mimarıdır. Güvenilir, ölçeklenebilir ve verimli çözümler oluşturmaktan keyif aldığı Büyük Veri analitiği ve Veri Mühendisliği alanında 13 yılı aşkın deneyime sahiptir. İş dışında seyahat etmekten ve deneyimlerini sosyal medyada blog yazmaktan hoşlanıyor.

• SEO Destekli İçerik ve Halkla İlişkiler Dağıtımı. Bugün Gücünüzü Artırın.
• PlatoData.Network Dikey Üretken Yapay Zeka. Kendine güç ver. Buradan Erişin.
• PlatoAiStream. Web3 Zekası. Bilgi Genişletildi. Buradan Erişin.
• PlatoESG. karbon, temiz teknoloji, Enerji, Çevre, Güneş, Atık Yönetimi. Buradan Erişin.
• PlatoSağlık. Biyoteknoloji ve Klinik Araştırmalar Zekası. Buradan Erişin.
• Kaynak: https://aws.amazon.com/blogs/big-data/design-a-data-mesh-on-aws-that-reflects-the-envisioned-organization/