Mimari kata · K—06
BSS Modernizasyonu ve Gerçek Zamanlı Müşteri 360
Mimari kata · kurgusal bir problem tanımı üzerine tasarım çalışması
- Sektör
- Telekom
- Konu
- Karar
- Teknolojiler
- Debezium, Apache Kafka, Apache Flink, PostgreSQL, OpenSearch, Temporal, Unleash, Apache Iceberg, Trino, DataHub, Open Policy Agent, MLflow
Kısaca
Mainframe'e dokunmadan 14 sistemin değişiklik olaylarından Müşteri 360 kurmak, faturalamayı beş yılda kohort kohort emekli etmek.
Problem
20 milyon aboneli bir telekom operatörü, 25 yıllık bir mainframe uygulamasında faturalama yapıyor. Müşteri verisi 14 sistemde duruyor ve bir tarife değişikliğinin hepsine ulaşması üç gün sürüyor. Operatör gerçek zamanlı bir Müşteri 360 görünümü ve siparişleri saniyeler içinde yürüten bir self-servis uygulaması istiyor. Mainframe’i de büyük patlama olmadan beş yıl içinde emekli etmek istiyor. Mainframe ekibi en fazla %2 ek CPU yüküne izin veriyor ve şema değişikliğine izin vermiyor.
Yaklaşım
Her şeyi tek bir kısıt belirliyor: mainframe’de ek yük yok, şema değişikliği yok. Entegrasyon bu yüzden yalnızca değişiklik olaylarıyla yapılabiliyor. Tasarım okuma modelini önce olaylardan kuruyor, yeni alanları anti-corruption layer (ACL) arkasında büyütüyor ve her alanı çift modda çalıştırıyor. Bir alan ancak ölçülmüş bir uzlaştırma kapısından sonra geçiyor. Debezium, Db2’yi yakalama tabloları üzerinden okuyor. IMS ve VSAM sistemleri zaten ürettikleri MQ olaylarını kullanıyor.
Mimari
- Yakalama: Db2 için Debezium, uydu sistemler için diğer CDC konnektörleri, gece dosyası veren iki kaynak için dosya ve API adaptörleri.
- Omurga: Apicurio Registry’de Avro şemalarıyla Kafka; şemalar TM Forum modellerini kullanıyor.
- Okuma modeli: Flink ham değişiklik verisini kanonik modele eşliyor ve 14 akışı müşteri anahtarında birleştiriyor. Uygulamaları PostgreSQL ve OpenSearch besliyor (CQRS).
- Yeni alanlar: Temporal iş akışları TM Forum Open API’lerini sunuyor. Mainframe’e yazan tek yol ACL; zaten bildiği bir MQ işlemini üretiyor.
- Veri mesh ve churn: alan veri ürünleri için Iceberg, Trino ve DataHub. Churn skoru için Spark, MLflow ve SHAP.
Neden bu bileşenler
| İhtiyaç | Seçim | Neden |
|---|---|---|
| Mainframe değişiklik yakalama | Debezium Db2 konnektörü (Kafka Connect) | Db2 günlüğünü ASN yakalama tablolarıyla okumak ölçülebilir ve uygulama şemasına dokunmuyor. Tabloları doğrudan sorgulamak mainframe CPU’sunu yakar. ASN Capture’ın kendisi lisanslı bir IBM bileşeni. |
| Mainframe’e yazma yolu | Anti-corruption layer (ACL) servisi ve Kafka Connect IBM MQ hedefi | ACL, TM Forum siparişini mainframe’in zaten bildiği bir MQ işlemine çeviriyor; korelasyon kimliği ve göndermeden önce tekrar kaydıyla. Eski model yeni alanlara sızmıyor. |
| Kimlik çözümleme | CRM alanının sahip olduğu müşteri crosswalk tablosu ve ana veri eşleme kuralları | Aynı kişi 14 sistemde farklı kimliklerle yaşıyor. Ulusal kimlik ve sözleşme numarasıyla eşleme bir güven skoru veriyor. Eşik altı “olası eşleşme” olarak görünüyor, asla birleştirilmiyor. |
| Uydu sistemler | Debezium (PostgreSQL, Oracle, MySQL) ve dosya ile API adaptörleri | On iki kaynak günlüğünü açıyor; değişiklik yakalama en düşük yükü ve en iyi tazeliği veriyor. Gece dosyası veren iki kaynak kendi tazelik işaretini taşıyor. Hiçbir kaynak gerçek zamanlıymış gibi gösterilmiyor. |
| Olay omurgası | Apache Kafka (Strimzi) | Kalıcı, tekrar oynatılabilir, müşteri anahtarında sıralı bir log. Sıkıştırılmış kanonik topic’ler okuma modelini kaynağa dönmeden yeniden kurabiliyor. Redpanda, Business Source License nedeniyle elendi. |
| Şema yönetişimi | Apicurio Registry; Avro ve TM Forum şemaları | Kanonik ve iş olayı şemaları sürümleniyor; geriye uyumluluk CI’da zorunlu. Confluent Schema Registry, Community License nedeniyle elendi. |
| Okuma modeli üreticisi | Apache Flink | 14 akışı 20 milyon altın müşteri anahtarında durum bilgili birleştirmek tam Flink’in işi. Kafka’ya tam bir kez; PostgreSQL ve OpenSearch’e en az bir kez ve idempotent upsert. |
| Okuma modeli depoları | PostgreSQL (CloudNativePG) ve OpenSearch | Komut ve sorgu ayrımı: uygulama PostgreSQL’den tek belge okuyor, temsilci OpenSearch’te arıyor. Elasticsearch’ün SSPL ve AGPL çift lisans dönemi nedeniyle OpenSearch. |
| Sipariş iş akışları | Temporal | 10 saniyelik sipariş bir mainframe MQ adımı ve telafi içeriyor. Temporal durumu kalıcı tutuyor, yeniden deniyor, zaman aşımını görünür kılıyor. Camunda 8 kaynak-erişimli lisansa geçtiği için elendi. |
| Kohort yönlendirme | Unleash | Geçiş ve geri alma bir bayrak çevirmesi olmalı. Geçit ve iş akışı aynı bayrağı okuyor. LaunchDarkly ticari. Unleash’te SSO ve RBAC ücretli sürümde, kohortlar açık sürümde. |
| Veri mesh | Apache Iceberg (Ceph), Trino, DataHub | Veri ürünlerinin sahibi alan ekipleri; katalog, soy ağacı ve SLA DataHub’da. Merkez platformu ve standardı veriyor, veriyi değil. MinIO topluluk sürümü daraldığı için Ceph. |
| Churn modeli | Apache Spark, MLflow, SHAP, ONNX servisi | 20 milyon abone için günlük skor bir toplu iş; olay tetikli yeniden skorlama dışa aktarılmış ONNX modelinden geliyor. SHAP gerekçe kodları temsilciye açıklama veriyor. Takma adlı özellikler GDPR’a göre hâlâ kişisel veri. |
| Geçit, kimlik ve politika | Apache APISIX, Keycloak, Open Policy Agent | TM Forum Open API’leri tek geçitten; abone ve temsilci için OpenID Connect. OPA kullanım verisine amaç bazlı erişimi geçitte ve Trino’da uyguluyor. Kong OSS özellik çıkardığı için APISIX. |
| Sır ve anahtar yönetimi | OpenBao | Mainframe kimlik bilgileri yalnızca alım namespace’inde; takma ad anahtarı şirket içinde kalıyor. HashiCorp Vault, Business Source License nedeniyle elendi. |
| Gözlemlenebilirlik | OpenTelemetry, Prometheus, Grafana, Loki, Tempo | Mainframe CPU bütçesi, yakalama gecikmesi, sipariş adım izleri ve çift çalışma fark oranı tek panoda. Geçiş komitesinin tek girdisi bu pano. |
Kararlar ve ödünleşimler
- Çift çalışmada eski sistem gerçeğin kaynağı. Aksi kanıtlanana kadar farklar yeni sistemde hata sayılıyor; müşteri yine eski cevabı alıyor. Kapı bir sayı: toplamda %0,1’in altı ve para alanlarında sıfır fark, dört hafta boyunca. Bedeli, iki sistemi yıllarca birlikte işletmek. Bunu bir sigorta primi olarak görüyorum; başarısız bir büyük patlamadan ucuz.
- Özellik bayraklarıyla kohort bazlı geçiş. Önce çalışanlar, sonra %1, %10, %50 ve %100. Geri alma bir bayrak çevirmesi; iki sistem de işlemeye devam ettiği için veri tutarlı kalıyor. Başarısız kapı kohort büyümesini otomatik durduruyor. Bedeli kohort tasarımı; faturalamada kohort fatura dönemiyle hizalanmalı.
- MirrorMaker 2 yerine iki veri merkezine yayılmış tek Kafka kümesi. Diğer katalarda asenkron kopya yetiyor. Burada sipariş komutları ve uzlaştırma farkları iki sitede de onaylanmalı. 5 ms altı gidiş-dönüş süresi bunu mümkün kılıyor. Bedeli, üçüncü sitede bir tanık denetleyici. Asenkron kopyanın yettiği yerde MirrorMaker 2’de kalırdım.
- Yalnızca değişiklik olayları, hiç sorgu yok. Mainframe %2 CPU’ya izin veriyor, şema değişikliğine izin vermiyor. Bu yüzden 360 günlük yakalama ve mevcut MQ olaylarıyla kuruluyor; mainframe’e okuma yükü sıfır. Tazelik p99’da yaklaşık 60 saniye tahmin ediliyor, hedef beş dakika. Bedeli: IMS ve VSAM’de günlük erişimi yok, MQ olaylarına bağımlılar.
- Mainframe yazımında kör yeniden deneme yok. ACL, kalıcı MQ mesajını göndermeden önce korelasyon kimliğini kaydediyor. Zaman aşımında yeniden denemeden önce sipariş durumunu soruyor. Çift ücret ancak kör yeniden denemeyle olurdu; o yol yok. Bedeli, uygulamada zamanlayıcıyla görünen bir “beklemede” durumu.
- Amaç bazlı erişim. Kullanım öznitelikleri ayrı bir grupta duruyor. Okumak için amaç bildirmek gerekiyor; OPA geçitte ve Trino’da karar veriyor. Her okuma ekle-sil-yok bir tabloya ve aylık düzenleyici raporuna düşüyor. Bu bir politika belgesi değil, teknik bir kontrol. Bedeli: hukukun amaç listesini tanımlaması gerekiyor.
Yeniden ele alacaklarım
- Db2 for z/OS’ta ASN yakalama. İzinli mi, yakalama tabloları şema değişikliği sayılıyor mu? Sayılıyorsa Db2 de IMS ve VSAM’in yoluna düşer: MQ olayları ya da ticari günlük yakalama.
- IMS ve VSAM kapsamı. Mevcut MQ olayları 360 için yeterli alan taşıyor mu, yoksa ticari günlük yakalama şart mı?
- Mainframe sipariş süresi. Tarife değişikliği MQ işlemi 10 saniyelik bütçenin yarısından fazlasını harcıyorsa uygulamada tasarlanmış bir “beklemede” deneyimi gerekir.
- Çift çalışma eşiği. %0,1 ve para alanlarında sıfır fark varsaydım. Finans ve düzenleyicinin bir sayıyı kabul etmesi gerekiyor.
Sonuç notları (tasarım varsayımları, ölçüm değil)
Bu bir tasarım çalışmasıdır, gerçekleşmiş bir göç değildir. Çıktı: dört sayfalık diyagram seti, tek sayfalık beyaz tahta sürümü ve beş aşamalı strangler-fig akışını anlatan 16 sayfalık Türkçe PDF. 5 dakikalık tazelik hedefi bir gereksinimdir; tasarımın ölçülmüş bir sonucu yoktur.
Kaynaklar
- Mimari PDF (Türkçe, 16 sayfa).
- draw.io diyagramları (İngilizce etiketler): dört sayfalık set ve 30 dakikalık tek sayfa sürüm.
Bu konudaki gerçek projeler
P—07
Tamamlandı
Cloudera Büyük Veri ETL Aktarım (Offload) Programı
Yüksek yüklü 200+ ETL süreci, 15 düğümlü Cloudera kümesinde Spark, Hive ve Impala ile ELT olarak yeniden kuruldu: ortalama ~12 kat, en fazla 30 kat hız.
Rol
Program liderliği · Büyük Veri Yönetimi ve Veri Mimarisi Yöneticisi
P—09
Tamamlandı
İlk Veri Mühendisliği Ekibi, Hadoop Platformu ve Veri Gölü
Şirketin ilk veri mühendisliği ekibi, üretimde 15 düğümlü bir Cloudera CDH kümesi ve raporlama ile makine öğrenmesini besleyen çok kaynaklı veri gölü.
Rol
Ekibin ve platformun kurulması · Veri Mühendisliği Takım Lideri