CoStar, Amazon EKS Kaynaklarını optimize etmek için Karpenter’ı nasıl kullanıyor?

Orijinal makale: Link (Muhammed Karakas, Josh Manner ve Peter Ildefonso)

Giriş

CoStar, ticari gayrimenkul verilerinde pazar lideri olarak biliniyor, ancak aynı zamanda Jeff Goldblum’un reklamını yaptığı apartments.com da dahil olmak üzere önemli müstakil ev ve daire kiralama web sitelerini de yönetiyor. CoStar’ın geleneksel ticari gayrimenkul müşterileri, kritik iş kararlarını almak için büyük ve karmaşık verileri kullanan son derece bilgili kullanıcılardır. Müşterilerin 130 milyar metrekarelik alana sahip 6 milyon mülkten hangisini kiralayacağını analiz etmesine ve karar vermesine başarıyla yardımcı olmak, CoStar’ı veri ve analitik teknolojisinde lider haline getirmiştir. CoStar, daire ve müstakil ev kiralama web sitelerinin yeni neslini oluşturmaya başladığında, kullanıcı profilinin ve müşteri taleplerinin uzun süredir devam eden ticari gayrimenkul müşterilerinden önemli farklılıkları olduğu farketti. CoStar’ın yeni müşteri kitlesine aynı karar verme kabiliyetlerini sunması gerekiyordu, ancak çok daha fazla müşteri ve veri için. Bu, CoStar’ın yüz milyonlarca mülke erişen milyonlarca kullanıcıya aynı değeri sunmak için gereken hız ve esneklik için eski veri merkezlerinden AWS‘e geçişini başlattı.

Zorluklar

CoStar’ın en büyük zorluğu her zaman yüzlerce kaynaktan veri toplamak, bu verileri önemli öngörülerle zenginleştirmek ve bu verileri anlamlı ve kullanıcı dostu bir sistemde sunmak olmuştur. CoStar Suite’in ticari gayrimenkul, daire ve müstakil ev bölümlerinin tümü, farklı zamanlarda ve farklı veri hacimleriyle güncellenen farklı veri kaynaklarına sahiptir. Bu veri alımını ve veri kaynaklarına yapılan güncellemeleri destekleyen sistemler hızlı, doğru ve uygun maliyetli olabilmeleri için ölçeklenebilir olmalıdır. Bu sistemlerin çoğu eski veri merkezlerinden CoStar’ın AWS ortamına taşınma sürecinde olduğundan, mühendislik desteğinin büyük ölçüde tekrarlanmasını önlemek için paralel ve birlikte çalışabilir sistemler üzerinde çalıştırılmaları gerekiyordu. Bu ihtiyaçların tümü, Kubernetes’i şirket içinde ve AWS’te çalıştırmaya ve kullanımdaki artış ve azalmalar için konteyner kümelerinde ölçeklendirme yeteneklerine gereksinim olduğunu gösteriyordu. Aylar süren başarılı test ve üretimin ardından CoStar, şirket içi Kubernetes yönetimini mümkün olduğunca paralel tutmaya devam ederken mühendislik yığınını daha da optimize etmeye karar verdi.

Kubernetes küme mimarisinde, kontrol düzlemi (control plane) ve bileşenleri, küme işlemlerini (örneğin, konteyner zamanlama, uygulama kullanılabilirliğini yönetme ve diğer önemli görevlerin yanı sıra küme verilerini depolama) ve konteynere alınmış uygulama iş yüklerini çalıştıran bölmeleri (pods) barındırmak için çalışan düğümleri (worker nodes) yönetmekten sorumludur. Amazon Esnek Kubernetes Hizmeti (Amazon EKS), AWS üzerinde Kubernetes kontrol düzleminin kullanılabilirliğini ve ölçeklenebilirliğini yöneten bir Kubernetes hizmetidir. Çalışan düğümler (worker nodes) için müşteriler, Kubernetes bölme (pod) iş yüklerini Amazon Elastic Compute Cloud (Amazon EC2) ve AWS Fargate‘in herhangi bir kombinasyonunda planlama seçeneğine sahiptir. Bu yazıda CoStar’ın Karpenter otomatik ölçeklendirme çözümünü kullanarak çalışan düğümler için Amazon EC2 bulut sunucularını nasıl hazırladığına odaklanacağız.

Çalışan düğümleri sağlamanın varsayılan yöntemi, Amazon EC2 Auto Scaling gruplarını kullanarak Amazon EC2 bulut sunucularının sağlanmasını ve yaşam döngüsü yönetimini otomatikleştiren Amazon EKS tarafından yönetilen düğüm gruplarından yararlanmaktır. Amazon EC2 bulut sunucularının dinamik olarak ayarlanması için Amazon EKS tarafından yönetilen düğüm grubu işlevi, Cluster Autoscaler çözümü ile eşleştirilebilir. Bu otomatik ölçeklendirme çözümü, işlem kapasitesi için bekleyen bölmeleri (pods) ve az kullanılan çalışan düğümleri izler. Bölmeler yetersiz kaynaklar nedeniyle beklemede durumundayken Cluster Autoscaler, Amazon EC2 Auto Scaling grubundaki istenen sunucu sayısını artırarak yeni çalışan düğümler sağlar ve bu da bu bölmelerin zamanlanmasına ve çalıştırılmasına olanak tanır. Cluster Autoscaler, belirli faktörlere bağlı olarak az kullanılan veya kullanılmayan düğümleri sonlandırır.

CoStar’ın Amazon EKS’te çalışan iş yükleri için amaç, verimli bir kaynak olurken kullanılabilirliği ve performansı en üst düzeye çıkarmaktı. Cluster Autoscaler çözümü bir dereceye kadar dinamik bilgi işlem kaynağı sağlama ve maliyet verimliliği sağlarken, kullanımı zorlaştıran ve hatta kısıtlayan birçok husus ve sınırlamayı da beraberinde getirmektedir. Şöyle ki, belirli bir düğüm grubu için Amazon EC2 bulut sunucusu türleri, istenmeyen davranışları en aza indirmek için benzer Merkezi İşlem Birimi (CPU), Bellek ve Grafik İşlem Birimi (GPU) özelliklerine sahip olmalıdır. Bunun nedeni, bölmelerin zamanlamasını simüle etmek için düğüm grubu politikasında belirtilen ilk sunucu türünü kullanmasıdır. Politika daha yüksek özelliklere sahip ek sunucu türlerine sahipse, bölmeleri yalnızca ilk sunucu türünün boyutuna göre zamanlayacağından, ölçeklendirme sonrasında düğüm kaynakları boşa harcanabilir. Politika daha düşük özelliklere sahip ek sunucu türlerine sahipse, düğüm kaynak kısıtlamaları nedeniyle bölmeler bu düğümlerde zamanlanamayabilir. CoStar’ın çeşitli bölme kaynak gereksinimlerini karşılamak üzere sunucu boyutlarını çeşitlendirmek için, benzer şekilde belirlenmiş sunucu türlerine sahip birden fazla düğüm grubu oluşturmaları gerekiyordu. Ayrıca, Cluster Autoscaler yalnızca az kullanılan düğümleri kullanımdan kaldırır, ancak iş yüklerindeki değişikliklere yanıt olarak bunları daha ucuz sunucu türleriyle değiştirmez. Ek olarak, CoStar’ın durum bilgisi olmayan (stateless) iş yükleri için, talep üzerine daha fazla indirimler için Spot bilgi işlem kapasitesini tercih edebilmek, düğüm grupları ile uygulanması zahmetliydi.

Çözüme genel bakış

Neden Karpenter

CoStar, farklı iş yükü talepleri için birden fazla düğüm grubunun yönetim yükü olmadan düğümleri sağlamanın daha verimli bir yoluna ihtiyaç duyuyordu. Bu ihtiyaç, açık kaynaklı Karpenter düğüm sağlama çözümü kullanılarak giderildi. Karpenter, planlanmamış bölmelere yanıt olarak çalışan düğüm kapasitesinin dinamik grupsuz olarak tedarik edilmesini sağlayan esnek, yüksek performanslı bir Kubernetes küme otomatik ölçekleyicisidir. Karpenter’ın grupsuz tasarımı sayesinde CoStar artık benzer şekilde belirlenmiş sunucu türlerini kullanmaya bağlı değildi. Karpenter, bekleyen bölmelerin toplam kaynak gereksinimlerini ve diğer zamanlama kısıtlamalarını (örneğin düğüm seçicileri, yakınlıklar, toleranslar ve topoloji yayılma kısıtlamaları) sürekli olarak değerlendirir ve Sağlayıcı Özel Kaynak Tanımında (Custom Resource Definitions – CRD) tanımlandığı şekilde optimum sunucu hesaplama kapasitesini sağlar. Bu ek esneklik sayesinde CoStar bünyesindeki farklı ekipler, uygulama ve ölçeklendirme ihtiyaçlarına göre kendi Sağlayıcı yapılandırmalarını kullanabiliyor. Ayrıca Karpenter, düğümlere ve Amazon EC2 Auto Scaling gruplarına ihtiyaç duymadan doğrudan Amazon EC2 Filo uygulama programlama arayüzünü (API) kullanarak düğümleri sağlar, bu da CoStar’ın performans hizmet düzeyi anlaşmalarını (SLA’ler) geliştiren daha hızlı tedarik etme ve yeniden deneme süreleri (yani dakikalara karşı milisaniyeler) sağlar. Ayrıca CoStar ekibi, Karpenter denetleyicisini AWS Fargate üzerinde çalıştırmayı tercih ederek yönetilen düğüm gruplarına olan ihtiyacı tamamen ortadan kaldırdı.

Aşağıdaki diyagram, Karpenter’ın planlanmamış bölmelerin toplam kaynak taleplerini nasıl gözlemlediğini, yeni düğümler başlatmak için kararlar aldığını ve altyapı maliyetlerini azaltmak için bunları nasıl sonlandırdığını göstermektedir:

CoStar ekibi, CoStar’ın durum bilgisi olmayan iş yükleri ve daha düşük ortamlar için maliyet etkinliği elde etmek amacıyla Karpenter sağlayıcısını Spot kapasiteyi tercih edecek ve yalnızca Spot kapasite yoksa isteğe bağlı (On-Demand) kapasite sağlayacak şekilde yapılandırdı. Karpenter, Spot kapasite için maliyeti dengeleyen ve yakın vadede kesinti olasılığını azaltan fiyat-kapasite-optimize edilmiş tahsis stratejisini kullanır. Üretim kümelerindeki durumsal iş yükleri için Karpenter sağlayıcısı, çoğu indirim elde etmek için Sunucu Tasarruf Planları (Compute Savings Plans) ve Rezerve Edilmiş Sunucuları (Reserved Instances) tarafından kapsanan, İsteğe bağlı (On-Demand) çalışan bir dizi hesaplama ve depolama için optimize edilmiş sunucu ailesi tanımlar. Daha fazla optimizasyon için CoStar, Karpenter’ın düğümlerin kullanımını izleyerek ve mevcut iş yüklerinin diğer düğümlerde çalışıp çalışamayacağını veya daha ucuz varyantlarla değiştirilip değiştirilemeyeceğini kontrol ederek küme maliyetlerini aktif olarak azaltmasına olanak tanıyan konsolidasyon özelliğini etkinleştirdi. Çalışan bölme sayısı, yapılandırılmış düğüm sona erme süreleri, daha düşük öncelikli bölmelerin kullanımı ve mevcut Bölme Bozulma Bütçeleri (Pod Disruption Budgets – PDB’ler) gibi birden fazla faktör değerlendirilerek, konsolidasyon eylemleri iş yükü kesintilerini en aza indirecek şekilde gerçekleştirilir.

Ön Koşullar

Bu yazıdaki örneği gerçekleştirmek için aşağıdakileri ayarlamanız gerekir:

• AWS’te bir Kubernetes kümesi sağlayın
• Küme otomatik ölçeklendirme için Karpenter’ı yükleyin
• Amazon Esnek Kubernetes Hizmeti (Amazon EKS) Node Viewer’ı yükleyin

İzlenecek yol

Bu bölümde, Karpenter’ın konsolidasyon yeteneğinin bir parçası olan değiştirme mekanizmasının basit bir gösterimini sunuyoruz. Aşağıdaki Karpenter Sağlayıcı ve düğüm şablonu yapılandırma kodu, isteğe bağlı kapasite türüne sahip bir dizi hesaplama için optimize edilmiş sunucu türünü kısıtlar:

apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  name: consolidation-replace
spec:
  providerRef:
    name: consolidation-enabled
  requirements:
    - key: "karpenter.sh/capacity-type" 
      operator: In
      values: ["on-demand"]
    - key: "karpenter.k8s.aws/instance-family"
      operator: In
      values: ["c4", "c5", "c5a", "c5n", "c6a", "c6i", "c6in"]
  consolidation:
    enabled: true
  labels:
    type: karpenter-node  
---
apiVersion: karpenter.k8s.aws/v1alpha1
kind: AWSNodeTemplate
metadata:
  name: consolidation-enabled
spec:
  subnetSelector:
    karpenter.sh/discovery: consolidation-subnet-example
  securityGroupSelector:
    karpenter.sh/discovery: consolidation-sg-example
  tags:
    app.kubernetes.io/created-by: consolidation-replace-example

Konsolidasyon davranışını göstermek için kullandığımız uygulama dağıtım bildirimi:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: consolidation-replace-deployment
  namespace: default
spec:
  replicas: 60
  selector:
    matchLabels:
      app: consolidation-replace-deployment
  template:
    metadata:
      labels:
        app: consolidation-replace-deployment
    spec:
      nodeSelector:
        type: karpenter-node
      containers:
        - name: consolidation-replace-container
          image: public.ecr.aws/eks-distro/kubernetes/pause:3.8
          resources:
            requests:
              memory: "128Mi"
              cpu: "500m"

Düğüm kullanımını görselleştirmek için eks-node-viewer aracını kullanarak, Karpenter’ın bir c6a.8xlarge sunucusu sağladığını, kaynak talebi gereksinimlerine göre dağıtımı çalıştırmak için en uygun olduğunu gözlemliyoruz (dört daemon bölme ile birlikte):

Mesai saatleri dışında trafik yükünün daha düşük olduğunu varsayalım. Bölme sayısını kaynak kullanımına göre dinamik olarak ölçeklendirmek için Horizontal Pod Autoscaler‘ı kullanabilirsiniz. Örneğimizde, trafik yüklerindeki azalmayı simüle etmek amacıyla kopya sayısını 30’a düşürmek için kubectl kullanıyoruz:

kubectl scale deployment consolidation-test --replicas 30

30 kopya ile genel kaynak gereksinimleri çok daha düşüktür. Karpenter, daha ucuz bir varyantla (bu durumda bir c6a.4xlarge ile) yedek bir düğüm sağlar ve aşağıdaki ekran görüntüsünde gösterildiği gibi orijinal düğümü kordon altına alır.

Bölmeler değiştirilen düğümde yeniden planlandıktan sonra önceki düğüm sonlandırılır.

Örneğimizden de görebileceğiniz gibi Karpenter, CoStar’a c6a.4xlarge’ı sağlayarak verimli bir şekilde ölçeklendirme ve kaynak gereksinimleri mesai saatleri dışında azaldıkça maliyeti optimize etme olanağı sağlıyor.

Temizleme

Ek operasyonel maliyetlere maruz kalmamak için, bu yazıdaki örnekler için oluşturduğunuz tüm AWS kaynaklarını silmeyi unutmayın.

Sonuç

Konteyner çözümlerimizi değerlendirirken AWS’te birçok kullanım durumu ve seçenek vardır. CoStar için Karpenter, geliştirme ve test ortamlarında çalıştırdıkları Amazon EC2 Spot Kapasitesini konsolide etti ve iş yüklerini etkin bir şekilde çalıştırmaya devam ederken, onları en düşük maliyetli sunucu türüne taşıdı. Geçişler sırasında pariteyi korumaya odaklanan, Kubernetes’te derin ve etkili yatırımlar kullanmaya devam eden ve maliyet optimizasyonuna odaklanmak için kanıtlanmış bir çözüm arayan müşteriler, Karpenter ile Amazon EKS’i düşünmelidir. Halihazırda Amazon EKS kullananlar için EKS Node Viewer aracı, düğüm verimliliğini ve Karpenter’ın yeteneklerinden yararlanıp yararlanamayacağınızı değerlendirmek için kullanılabilir. Bölmeleri daha az sayıda düğümde birleştirmeyi ve en etkili bulut sunucusu türlerini kullanmayı isteyen müşteriler, başlamak için Karpenter‘i keşfetmeye ve belgeleri kullanmaya başlamalıdır.