• Buradasın

    Trendyol Platform Teknolojileri ve Mikro Servis Entegrasyonları Sunumu

    youtube.com/watch?v=IkZpWL7zitQ

    Yapay zekadan makale özeti

    • Bu video, Trendyol'da platform ekibinde çalışan Batuhan ve Emre tarafından sunulan teknik bir konferans sunumudur. Konuşmacılar yaklaşık 3-3,5 yıldır Trendyol'da çalışmaktadır.
    • Sunum, Trendyol'un büyümesiyle ortaya çıkan teknik zorlukları ve platform ekibi tarafından geliştirilen çözümleri ele almaktadır. İçerik, platform ekibi ve stream team modeli, mikro servis entegrasyonu, Kubernetes platform ürünleri, config ve secret management, cache management, servis yetkilendirme (authorization) ve multiting webhook geliştirme gibi konuları kapsamaktadır. Sunum, teknik detaylar, kullanılan teknolojiler ve platform mimarisi hakkında kapsamlı bilgiler içermektedir.
    • Sunumda Consul, Vault, Istio, Envoy Proxy, Open Policy Agent (OPA), etcd ve bookkeeper gibi teknolojilerin kullanımı, sidecar pattern, opt-in model ve platform toolkit yaklaşımı gibi konular detaylı olarak anlatılmaktadır. Ayrıca, uygulamaların test süreçleri, multiting webhook'lar ve Kubernetes ortamında geliştirilen native çözümler de sunumun önemli bölümleridir. Sunum, katılımcıların sorularına cevap verilerek sona ermektedir.
    00:23Sunumun Tanıtımı
    • Batuhan ve Emre, Trendyol'da platform ve mikro servis entegrasyonları hakkında sunum yapacaklar.
    • Batuhan yaklaşık üç senedir Trendyol'da platform ekibinde Go uygulamaları ve Kubernetest teknolojileriyle ilgileniyor.
    • Emre yaklaşık üç buçuk senedir Trendyol'da çalışmakta ve şu anda platform ekibiyle birlikte Kubernetes üzerinde mikro servisler için geliştirme yapıyor.
    01:28Sunumun Amacı
    • Sunumda platform ekibi olarak uğraştıkları problem, çözüm yolları, implementasyon detayları ve Trendyol'da production'da yaygın olarak kullanmaya başladıkları ürünler tanıtılacak.
    • Sunumda mikro servisler için dinamik yapılandırma ve gizli bilgi yönetimi, önbellek yönetimi ve yetkilendirme süreçleri anlatılacak.
    • Sunum boyunca izleyiciler sorularını sorabilir ve vakit buldukça cevaplanacaktır.
    02:10Trendyol'un Büyüme Sorunları
    • Trendyol çok hızlı bir şekilde büyümekte olup, teknoloji takımı son bir senede 350 kişiden 600 kişiye çıkmış ve 35 takımdan 60 takıma büyüme kaydedilmiştir.
    • Artan taleplerle birlikte domainler küçük ekiplere bölünmüş veya yeni ürün domainleri için yeni ekipler oluşmuştur.
    • Trendyol'da geliştirilen ürünler (Trendyol Express, Trendyol Go Market teknolojileri) bazı şirketlere denk gelebiliyor.
    03:07Teknik Zorluklar ve Organizasyonel Yeniliğe Geçiş
    • Teknik zorluklar arasında anlık müşteri sayısının artması, veri miktarının artması ve mikro servis sayılarının artması bulunmaktadır.
    • Mikro servis dünyasında Kubernetes etrafında şekillenen birçok ürün bulunuyor ve bunların hepsini bir kişinin bilmesi, yönetmesi zor bir problem.
    • Trendyol, platform ve stream team modeli adı verilen bir yapıya geçerek organizasyon yapısında yeniliğe gitmiştir.
    04:20Platform ve Stream Team Modeli
    • Stream, business ihtiyaçlar doğrultusunda domain geliştirmesi yapan teknik ekiplerdir ve son kullanıcının kullandığı ürünleri geliştirmekten sorumlu.
    • Platform ekibi, CNCF ürünlerinin içerdiği konuları adresleyerek diğer takımları bu konularda yardımcı olan ekipdir.
    • Platform ekibi, infra tarafında çeşitli çözümler üreterek ortak sorunları çözmeye çalışmaktadır.
    05:12Platform Ekibinin Amacı
    • Platform ekibi, ekiplerin multidisi, multizone ve multi-cluster çalışabilmesini hedeflemektedir.
    • Platform ürünleri geliştirerek diğer ekiplerin bu hedeflerine ulaşmasında kolaylık sağlar.
    • Platform ekibi, domain ekiplerin otonomisini bozmamaya çalışır ve takımların otonomisini hiçbir şekilde etkilemez.
    06:00Mikro Servislerin Ortak İhtiyaçları
    • Bir mikro servis, rant time boyunca konfigürasyon yönetimi, gizli bilgi yönetimi, önbellek yönetimi, kimlik doğrulama hizmeti, keşif, yük dengeleme, kilit koleksiyon, izleme ve metriklerin dışa aktarılması gibi çeşitli ihtiyaçlar duyuyor.
    • Bu ihtiyaçlar aynı zamanda multi-DC şekilde çözülmelidir çünkü Trendyol artık dört data center'da çalışıyor.
    • Gelecek dönemde geliştiricilerin üretkenliğini artıran konulara ve geliştirici deneyimine de dokunulacaktır.
    07:17Çözüm Prensipleri
    • İlk prensip "toolkit yaklaşımı" olup, framework yaklaşımının zıttıdır; toolkit yaklaşımında kontrolü mümkün olduğunca uygulama tarafına bırakmak hedeflenir.
    • İkinci prensip "opt-in modeli" benimsenmektedir; bu sayede takımlar platform ürünlerinden hangisini kullanmak istiyorlarsa kendi isteklerine göre bunu enable edebilirler.
    • Üçüncü prensip, platform ve uygulamanın birbirinden bağımsız şekilde gelişebilmesidir; platform tarafında yapılan değişiklikler uygulama tarafında haberdar olmadan yapılabilir.
    08:51Global Kontrol Paneli ve Platform Toolkit
    • Trendyol.com'da yaklaşık her servis Kubernetes ortamlarında çalışıyor ve multi-cluster olarak dağıtılmış durumdadır.
    • Kübernetest'in kendi kontrol panelini kullanmak yerine dışarıda bir kontrol paneli kurgulanıp HD olarak çalışabilmesi sağlanmıştır.
    • Bu prensipler belirlenmesinin temel amacı, platform toolkit paternini geliştirmek için gerekli olan appstruction seviyesini belirlemektir.
    09:35Platform Toolkit'in Hedefleri
    • Platform toolkit ile hedeflenen en önemli konu, uygulamaya işletim sisteminin sağladığı aynı appstruction CV'sini sağlamaktır.
    • Appstruction primitiveleri olarak local file, localhost networking, environment variables, standart out ve operating system signs gibi unsurlar düşünülmektedir.
    • Mikro servislere lokal bir environment'ta çalışıyormuş illüzyonu sağlanır ve mikro servisler platform feature'larından herhangi birini kullanmak istediklerinde bunu bir annotation ile belirterek uygulamaya bağlı hale getirirler.
    10:45Platform Ürünlerinin Geliştirilmesi
    • Platform ürünleri data plane ve control plane olarak farklı şekillerde implemente edilebilir.
    • Data plane tarafında sidecar demons, Fluentd, CNN, CC plugin ve IBB filter'lar şeklinde implemente edilebilir.
    • Sidecar tercih edilmesinin en önemli nedeni, Kubernetes üzerindeki pod içerisindeki konteynerlerin aynı network namespace'de ve IPC namespace'i ile çalışabilmesi.
    12:27Control Plane ve Data Plane İletişimi
    • Control plane ve data plane arasında pull-based veya push-based iletişim yapılabilir.
    • Her bir platform ürünü ayrı cycle olarak geliştirilerek kaynak kullanımını daha iyi yönetmek mümkün hale getirildi.
    • Pod içerisinde birden fazla sidecar çalıştırmanın container runtime'a yük oluşturmadığı araştırılarak bulunmuştur.
    14:14Microservice Gereksinimlerinin Platformla Entegrasyonu
    • Config ve secret ihtiyaçları için Config Server ve Consul kullanılarak son kullanıcıyı haberdar etmeden implemente edildi.
    • Load balancing ve servis mesh için Istio tercih edildi, güvenlik otorization için OPA ve filtreler kullanıldı.
    • Servis-servis kimlik doğrulaması için mTLS kullanıldı, metrik export için Prometheus ve Grafana tercih edildi.
    16:05Kubernetes'in Kullanımı ve Extensibility
    • Trendyol'da çoğu servis Kubernetes ortamında multi-cluster şekilde çalışıyor.
    • Kubernetes'in güçlü yanlarından otomasyon, roolback, serbest discovery, load balancing, auto-scaling ve self-healing özellikleri faydalanılıyor.
    • Platform ürünlerinin geliştirilmesinde Kubernetes'in extend edilebilirlik özelliği ciddi anlamda kullanıldı.
    17:37Kubernetes Extension Point ve API Server
    • Kubernetes'in resmi dökümantasyonunda extension point'lar açıkça belirtilmiştir.
    • Platform ürünleri geliştirilirken API server'ın extend edilebilirliğine odaklanıldı.
    • Annotation tabanlı bir model kullanılarak ekipler platform feature'larını entegre etmek istediklerinde annotation'ları kullanarak bu feature'lara adapte olabiliyorlar.
    19:21Mutating Admission Webhook Kavramı
    • Mutating Admission Webhook, client'dan yapılan request'in üzerine mutation yapmamızı sağlayan bir kavramdır.
    • Istio teknolojisi bu kavramı kullanarak uygulamanın networkingini halledebilir ve namespace üzerindeki bir label ile kodunuza otomatik olarak enjekte edebilir.
    • Validating Admission Webhook ile API requestlerini validate edebilir, örneğin Trendyol'da sadece private registry'den imajların cluster'a deploy edilmesini kontrol edebilirsiniz.
    21:00Platform Tasarım Patterleri
    • Platform ekibi, uygulamaların lokal environment illüzyonunu sağlayarak dil bağımsız bir yapı sunmayı hedeflemektedir.
    • Uygulamalar sadece lokal file system'den dosya okuyacak kod yazmak zorundadır, dosya üzerindeki değişiklikleri dinleyip be injection'ları yapabilirler.
    • Trendyol'da Java, Scala, Go, Kotlin gibi çeşitli diller kullanılmakta olup, platform çözümleri dil bağımsızdır.
    24:27Pod Tasarım Patterleri
    • Pod tasarımı için Sidecar, Proxy ve Init konteyner gibi çeşitli patterler bulunmaktadır.
    • Init konteyner, bir pod içerisinde ilk başlaması gereken konteynırları ayarlamak için tercih edilmektedir.
    • Multi-konteyner pod design konusunda detaylı bilgi için internet araması yapılabilir.
    25:34Platform Portföyü ve Teknolojiler
    • Platform, multi-DC ve multi-cluster requirement'ları, config ve secret management gibi ihtiyaçları karşılamaktadır.
    • Cash management tarafında reverse proxy kullanılarak load balancer yükü sidecar üzerine iletildi.
    • Log ve metric tarafında Prometheus, Grafana ve Fluentd gibi teknolojiler kullanılarak centralize logging ve gözlemlenebilir envanter oluşturulmaktadır.
    27:30Konfigürasyon ve Secret Management Uygulaması
    • Ekipler konfigürasyon ve secret management sorumluluğunu üstleniyor, ancak sensitive dataların (secret) yönetimi tamamen security ekibinde kalıyor.
    • Ekipler artık kendi lokallerinde değil, Consül gibi bir platform üzerinden konsüllerine konfigürasyonlarını yollamalı durumda.
    • Consül'ün key value store özelliğinden faydalanarak non-sensitive dataları Consül üzerine kurguluyor, sensitive dataların yönetimi ise security ekibinin sorumluluğunda.
    29:54Platform Uygulamasının Yönettiği Tepki
    • Trendyoll Config Enjektör, bir mutating webplamentasyonu olarak çalışarak annotation'lar üzerinden config ve secret management özelliğini etkinleştiriyor.
    • Diplomat manifest içerisindeki annotation'lar, uygulamanın config ve secret management özelliğini kullanmasını sağlıyor.
    • Inject file director, inject file secret ve inject file config annotation'ları ile uygulama içerisindeki dosyaların nasıl doldurulacağı belirleniyor.
    31:31Consül Template ve Container Yapısı
    • Consül Template teknolojisi, tüm konfigürasyon sürecini otomatik hale getiriyor ve init container ile sidecar container yapılarını kullanıyor.
    • Init container, uygulama container ayağa kalkmadan önce konfigürasyon değerlerini hazırlıyor.
    • Sidecar container, reconslation loop çalıştırarak sistemdeki desire state'e ulaşmayı sağlıyor ve dosyaları güncel tutuyor.
    34:24Cash Management Platformu
    • Cash management platformu, etcd ve consul gibi teknolojileri kullanarak keş yönetimini sağlıyor.
    • Kubernetes cluster içerisindeki podlar, micro servis geliştiricilerinin belirttiği cash yönlendirmelerini gerçekleştiriyor.
    • İstio kullanılarak gelen requestler manipüle ediliyor, örneğin belirli trafikler aynı pod içerisindeki farklı porta yönlendiriliyor.
    37:00Performans Avantajları
    • Aynı pod içerisindeki konteynırlar aynı kod ve network namespace kullanarak iletişim kuruyorlar.
    • Bu iletişim, external bir yere istek atmaktan çok daha hızlı oluyor, bazen milisaniyeler bazında fark yaratıyor.
    37:28Cache Konteyneri ve Çalışma Prensibi
    • Cache konteyneri Go dili ile geliştirilmiş ve proxy tarafında bağlantıları kurarak gelen istekleri ana uygulamaya proxy eden bir kod bulunuyor.
    • Cache konteyneri multidisi şekilde yönetiliyor ve her bir konteyner farklı bir portla ayağa kalkabiliyor.
    • Ekipler "trendyol sayfa enjek turu" diyerek kendilerine cache konteyneri enjekte edebiliyor ve belirli güvenlik namespacelerini boşaltıyor.
    40:07Cache Türleri ve Tercih Edilen Yöntem
    • EM-Cache, uygulamanın in-memory şekilde cache tutması; CLI-Server Cache ise uygulamanın bir server ile haberleşerek cache tutmasıdır.
    • Proxy Cache, cache'in load balancer'lar üzerinde tutulmasıdır.
    • Tercih edilen ve gösterilen yöntemde, istek önce cache konteynerlerine gidiyor, eğer cache varsa cache konteynerlerinden dönüyor, yoksa uygulama konteynerine proxy edip response'u alıyor.
    42:26Servis Authorization ve Open Policy Agent
    • Trendyol'da geliştirilen diğer uygulamalar production seviyesinde denenmeye başlanmışken, servis authorization henüz geliştirme aşamasında.
    • Kubernetes üzerinde çalışan uygulamalarda, envoy proxy sidecar üzerinden gelen ve giden tüm istekler yönetiliyor.
    • Open Policy Agent (OPA), policy management tarafında popüler bir araç olup, envoy proxy ile native şekilde entegre edilmiş.
    45:04Network Authorization Rule'ları
    • Envoy proxy, gelen isteklerin authorization kararını OPA'ya soruyor.
    • Network authorization rule'ları, uygulamaların hangi network trafiğine izin vermesi gerektiği konusunda karar veren yapıdır.
    • Bu rule'lar security ekibi tarafından review edilerek onaylanıyor ve uygulamaya uygulanıyor.
    46:35Opa ve Bundle API Hakkında Bilgiler
    • Tek geliştirdikleri ürün, Opa'ya ait network rule'larının yüklenmesini sağlayan Opa spesifik bir management API olan Bundle API'dir.
    • Bu management API sayesinde network rule'ları security onayından ve review'dan geçtikten sonra dağıtık mimaride Opa Sidecar'larına yüklenebilir.
    • Bu native çözüm dışında teknoloji spesifik ilerleyen bir süreç daha çok ve adaptasyonu gitgide artacak.
    47:45Envoy Proxy ve Opa Entegrasyonu
    • Envoy Proxy, gelen istekleri ana konteynere girmeden önce Opa ile iletişime geçerek security aşamalarını sağlar.
    • Envoy tarafında Envoy Filter adı verilen yapı, belirtilen konfigürasyona göre external authentication/authorization servisine istekte bulunur.
    • Opa-Envoy entegrasyonunda, cluster bazında yapılan konfigürasyon yerine, sadece security kullanan uygulamaların kullanılabilmesi amacıyla manuel olarak konfigüre edilmiştir.
    49:22Uygulama Bazlı Konfigürasyon
    • Opa-Envoy örneklerinde gelen tüm istekler için bir Envoy filter tanımlanırken, Trendyol'da bu filtre uygulama bazında dinamik olarak editleniyor.
    • Uygulamaya göre belirli antasyon değerine sahip olan istekler, ilgili deployment üzerinde belirtilen uygulama konteyner portuna yönlendiriliyor.
    • Bu şekilde cluster'da sadece o uygulama için security isteklerinin ilgili yerlere yönlendirilmesi sağlanıyor.
    50:40Custom Resource ve Operatör Kullanımı
    • Kubernetes'ta Custom Resource (CR) kavramı, source definition ve extend edilebilir taraflar sağlar.
    • Opa için ruhları OPA dilinin olan Rego ile yazılır ve bu uygulamaların güvenli şekilde dahil edilmesi için OPA için ruh kaydı adı verilen bir CR oluşturulmuştur.
    • Operatör framework'ten faydalanılarak, network authorization rule'ları içindeki Rego polisleri sürekli güncelleniyor ve güvenlik ekipleri tarafından review süreçleri dahil ediliyor.
    52:50Otomatik Süreç ve Soru-Cevap
    • Artık tamamen Kubernetes ortamında güvenlik objeleri ile uğraşıyorlar ve harici hiçbir şey bilmesine veya OPA ile bağlanmasına gerek kalmıyor.
    • GitOps süreci ile yeni bir network rule komiteden geçirilerek deployment produ'ya çıkabilir ve gerekli değişiklikler review edildiğinde otomatik olarak uygulamaya yansımış oluyor.
    • Trendyol'da RabbitMQ genelinde yaygın olarak kullanılırken, platform ekibi özelinde RabbitMQ kullanılmamaktadır.
    55:09Multiting Webhook'ların Önemi
    • Geliştirilen uygulamalar multiting webhook'lar üzerinden geçiyor ve bu kritik bir noktadır çünkü API request'lerinin etcd'ye erken kaydedilmesi, node üzerinde ölçekleme sürecinin daha hızlı başlamasını sağlar.
    • Multiting webhook'lar, API server life cycle'ını mümkün olduğunca az etkileyerek, cash config ve güvenlik gibi özelliklerin otomatik olarak pod içerisinde eklenmesi sürecini yönetir.
    • Uygulamaların efektif olması için verimli ve etkili kod yazma ve test etme süreci önemlidir.
    56:33Test Süreci ve Önemi
    • Uygulamalar production'a gitmeden önce efemral clusterlar kurularak, multiting ve gerekli ayarlar yapılarak test edilir.
    • Security authorization ve cash gibi kritik alanlarda bir yanlışlık olursa neredeyse tüm network'i etkileyebilecek risk vardır.
    • Uygulamaların hem efektif hem de test edilebilir olması için Go dilinden ve client Go SDK'sından faydalanılmıştır.
    57:43Otomatik Test Süreci
    • Geliştirilen uygulamalar, ana uygulamanın yaşam döngüsünü bölmemeli ve her değişiklik komitedildiğinde otomatik testlerle kontrol edilir.
    • Her değişiklik için uyumlu versiyonlu clusterlar kurularak uygulama diplo edilip test senaryoları gerçekleştirildikten sonra production'a alınır.
    • Otomatik test süreci, yeni versiyonlarda uygulamanın uyumluluğunu, hataları ve değişiklikleri önden görebilmeyi sağlar.

    Yanıtı değerlendir

  • Yazeka sinir ağı makaleleri veya videoları özetliyor