DigitalOcean Kubernetes Üzerinde Slinky Kurulum Rehberi

DigitalOcean Kubernetes Üzerinde Slinky Kurulum Rehberi

DigitalOcean Kubernetes (DOKS) üzerinde Skip Protocol’ün yüksek performanslı oracle çözümü Slinky’yi adım adım kurun, DeFi verilerini anında optimize edin.

Merkeziyetsiz finans (DeFi) ekosisteminde, milisaniyelerin bile büyük önemi vardır. Blokzincir ağlarında çalışan akıllı sözleşmeler ve doğrulayıcı (validator) düğümler, dış dünyadaki fiyat verilerine güvenli ve son derece hızlı bir şekilde erişmek zorundadır. Geleneksel oracle çözümleri genellikle yüksek gecikme süreleri (latency) ve yüksek işlem ücretleri (gas fees) nedeniyle modern finansal uygulamaların hızına yetişememektedir. İşte tam bu noktada, Skip Protocol tarafından geliştirilen Slinky devreye giriyor. Slinky, özellikle Cosmos SDK tabanlı zincirler için tasarlanmış, doğrulayıcı düğümlerle doğrudan entegre çalışan ve milisaniye düzeyinde veri güncelliği sunan yeni nesil bir oracle yan uygulamasıdır (sidecar).

Bu makalede, bulut altyapısı sağlayıcıları arasında sadeliği ve performansı ile öne çıkan DigitalOcean Kubernetes Service (DOKS) üzerinde Slinky oracle altyapısını sıfırdan nasıl kuracağınızı, yapılandıracağınızı ve optimize edeceğinizi öğreneceksiniz. Hazırladığımız bu uygulamalı rehber sayesinde, Kubernetes ekosisteminin sunduğu esneklikle Slinky’yi dakikalar içinde canlıya alabileceksiniz.

Slinky Nedir ve Kubernetes Ekosisteminde Neden Önemlidir?

Slinky, veri sağlayıcılardan (merkezi ve merkeziyetsiz borsalar) doğrudan fiyat bilgilerini çeken ve bu bilgileri consensus (mutabakat) aşamasında doğrudan blok üreticilerine sunan yüksek performanslı bir oracle sistemidir. Geleneksel oracle mimarilerinde veriler zincir üstüne belirli aralıklarla yazılırken, Slinky her blok teklifinde (block proposal) en güncel fiyatın mutabakata dahil edilmesini sağlar. Bu durum, özellikle arbitraj fırsatlarının değerlendirilmesi ve tasfiye (liquidation) işlemlerinin hatasız gerçekleşmesi açısından kritik bir öneme sahiptir.

Öncelikle, Slinky’nin mimari yapısını anlamak, onu Kubernetes üzerinde neden ve nasıl konumlandıracağımızı belirlememize yardımcı olur. Slinky iki ana bileşenden oluşur:

• Slinky Sidecar (Yan Uygulama): Doğrulayıcı düğümün hemen yanında çalışan, veri kaynaklarından gRPC ve WebSocket protokolleri aracılığıyla veri toplayan hafif bir Go uygulamasıdır.
• Oracle Market Map: Hangi varlıkların, hangi kaynaklardan ve ne kadar sıklıkla çekileceğini belirleyen dinamik bir konfigürasyon haritasıdır.

Bununla birlikte, bu sistemi Kubernetes üzerinde çalıştırmak, operasyonel mükemmellik sağlar. Kubernetes’in sunduğu kendi kendini iyileştirme (self-healing) özelliği sayesinde, Slinky podlarından biri çöktüğünde sistem otomatik olarak yeni bir pod başlatır. Ayrıca, DigitalOcean Kubernetes’in sunduğu ölçeklenebilirlik ve düşük ağ gecikmesi, veri sağlayıcılara erişim hızınızı maksimuma çıkarır. Sonuç olarak, yüksek erişilebilirlik gerektiren oracle operasyonları için Kubernetes kaçınılmaz bir standart haline gelmektedir.

DigitalOcean Kubernetes (DOKS) Kurulumu ve Hazırlık Aşamaları

Slinky dağıtımına başlamadan önce, DigitalOcean üzerinde aktif bir Kubernetes kümesine ve gerekli yönetim araçlarına ihtiyacımız var. Bu bölümde, kurulum için gerekli olan ortam hazırlıklarını adım adım gerçekleştireceğiz.

İlk olarak, yerel bilgisayarınızda DigitalOcean CLI aracı olan doctl ve Kubernetes yönetim aracı olan kubectl kurulu olmalıdır. Eğer kurulu değilse, işletim sisteminize uygun paket yöneticisini kullanarak bu araçları yükleyebilirsiniz. Ardından, DigitalOcean hesabınızla CLI aracını yetkilendirmeniz gerekir:

doctl auth init

Yetkilendirme işleminin ardından, DOKS üzerinde Slinky’nin performans gereksinimlerini karşılayabilecek minimum 3 düğümlü (node) bir Kubernetes kümesi oluşturalım. Slinky, ağ yoğunluğu yüksek bir uygulama olduğu için CPU optimize edilmiş sunucu tiplerini seçmek performansı olumlu etkileyecektir. Aşağıdaki komut ile kümemizi oluşturabiliriz:

doctl kubernetes cluster create slinky-cluster \
  --region fra1 \
  --node-pool "name=slinky-pool;size=g-2vcpu-8gb;count=3;auto-scale=true;min-nodes=3;max-nodes=5"

Kümenin oluşturulması birkaç dakika sürebilir. Kurulum tamamlandıktan sonra, Kubernetes yapılandırma dosyasını (kubeconfig) yerel sistemimize entegre etmek için şu komutu çalıştırıyoruz:

doctl kubernetes cluster kubeconfig save slinky-cluster

Bu işlemin ardından, kümenizin durumunu doğrulamak için düğümleri listeleyebilirsiniz. Düğümlerin “Ready” durumunda olduğunu görmek, kurulumun başarıyla tamamlandığını gösterir:

kubectl get nodes

Slinky Oracle Bileşenleri ve Mimarisi Nasıl Çalışır?

Slinky’nin Kubernetes üzerindeki çalışma mantığını kavramak, olası hata durumlarında sorun giderme (troubleshooting) sürecini büyük ölçüde kolaylaştırır. Slinky, veri sağlayıcılardan aldığı ham verileri işleyerek doğrulayıcı düğüme gRPC protokolü üzerinden sunar. Bu süreç son derece optimize edilmiştir ve minimum kaynak tüketimiyle çalışacak şekilde tasarlanmıştır.

Aşağıdaki tabloda, Slinky mimarisinin temel bileşenlerini, üstlendikleri rolleri ve kullandıkları varsayılan port yapılandırmalarını inceleyebilirsiniz:

Öte yandan, Slinky’yi Kubernetes üzerinde konumlandırırken iki farklı tasarım modeli uygulayabiliriz. Birinci modelde, Slinky uygulamasını doğrulayıcı düğümün (validator pod) içerisinde bir “sidecar” konteyner olarak çalıştırırız. Bu model, iki konteyner arasındaki ağ gecikmesini sıfıra indirdiği için en yüksek performansı sunar. İkinci modelde ise Slinky’yi bağımsız bir servis (Deployment) olarak dağıtırız. Bu model ise birden fazla doğrulayıcı düğümün veya uygulamanın aynı oracle servisinden yararlanmasını sağlayarak kaynak tasarrufu sunar. Bu rehberde, yönetimi daha esnek olan bağımsız servis modelini ele alacağız.

Adım Adım Slinky Dağıtımı: Kubernetes YAML Dosyalarının Hazırlanması

Kubernetes üzerinde Slinky’yi ayağa kaldırmak için öncelikle bir yapılandırma dosyasına (ConfigMap) ve ardından uygulamanın kendisini yönetecek bir Deployment dosyasına ihtiyacımız var. Bu bölümde, gerekli tanımlamaları yaparak Slinky’yi canlıya alacağız.

İlk adım olarak, Slinky’nin hangi borsalardan hangi pariteleri çekeceğini belirleyen slinky-config.yaml adında bir ConfigMap oluşturalım. Bu konfigürasyon, Slinky’nin kalbidir ve fiyat güncellemelerinin sıklığını belirler:

apiVersion: v1
kind: ConfigMap
metadata:
  name: slinky-config
  namespace: default
data:
  oracle.json: |
    {
      "prometheus_config": {
        "enabled": true,
        "port": "8080"
      },
      "providers": {
        "binance_api": {
          "name": "binance_api",
          "api_url": "https://api.binance.com",
          "interval_ms": 500
        },
        "coinbase_api": {
          "name": "coinbase_api",
          "api_url": "https://api.coinbase.com",
          "interval_ms": 1000
        }
      },
      "markets": [
        {
          "ticker": "BTC/USD",
          "providers": ["binance_api", "coinbase_api"]
        },
        {
          "ticker": "ETH/USD",
          "providers": ["binance_api", "coinbase_api"]
        }
      ]
    }

Bu ConfigMap dosyasını Kubernetes kümemize uygulamak için şu komutu çalıştırıyoruz:

kubectl apply -f slinky-config.yaml

Daha sonra, Slinky konteynerini çalıştıracak olan Deployment ve bu servise dışarıdan veya küme içinden erişimi sağlayacak Service tanımlamalarını içeren slinky-deployment.yaml dosyasını hazırlayalım:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: slinky-oracle
  namespace: default
  labels:
    app: slinky-oracle
spec:
  replicas: 2
  selector:
    matchLabels:
      app: slinky-oracle
  template:
    metadata:
      labels:
        app: slinky-oracle
    spec:
      containers:
      - name: slinky
        image: ghcr.io/skip-mev/slinky:v1.0.0
        imagePullPolicy: IfNotPresent
        args:
        - "--config"
        - "/etc/slinky/oracle.json"
        ports:
        - containerPort: 8080
          name: metrics
        - containerPort: 9090
          name: grpc
        resources:
          limits:
            cpu: "1"
            memory: 1Gi
          requests:
            cpu: "500m"
            memory: 512Mi
        volumeMounts:
        - name: config-volume
          mountPath: /etc/slinky
      volumes:
      - name: config-volume
        configMap:
          name: slinky-config
---
apiVersion: v1
kind: Service
metadata:
  name: slinky-service
  namespace: default
spec:
  selector:
    app: slinky-oracle
  ports:
    - protocol: TCP
      port: 9090
      targetPort: 9090
      name: grpc
    - protocol: TCP
      port: 8080
      targetPort: 8080
      name: metrics
  type: ClusterIP

Hazırladığımız bu deployment dosyasını da kümemize uygulayarak podların ayağa kalkmasını sağlıyoruz:

kubectl apply -f slinky-deployment.yaml

Ek olarak, podların başarıyla çalışıp çalışmadığını kontrol etmek için pod listesini inceleyebiliriz:

kubectl get pods -l app=slinky-oracle

Gerçek Zamanlı Fiyat Verilerini Çekmek: Slinky Konfigürasyonu

Slinky’yi başarıyla çalıştırdıktan sonra, sistemin veri sağlayıcılardan (providers) gerçek zamanlı fiyat verilerini doğru bir şekilde çekip çekmediğini doğrulamamız gerekir. Bu aşama, oracle sisteminin güvenilirliği açısından hayati önem taşır.

Öncelikle, Slinky podunun loglarını inceleyerek veri akışını gözlemleyelim. Loglarda herhangi bir bağlantı hatası veya API erişim engeli olup olmadığını kontrol etmek için aşağıdaki komutu kullanabiliriz:

kubectl logs -l app=slinky-oracle --tail=50 -f

Eğer yapılandırma doğru yapıldıysa, loglarda veri sağlayıcılardan başarıyla fiyat çekildiğine ve gRPC sunucusunun aktif olarak istekleri dinlediğine dair çıktıları görmeniz gerekir. Örneğin, aşağıdaki gibi log satırları başarılı bir entegrasyona işaret eder:

{"level":"info","time":"2023-10-27T12:00:01Z","message":"successfully fetched prices for BTC/USD: 34250.50"}
{"level":"info","time":"2023-10-27T12:00:01Z","message":"successfully fetched prices for ETH/USD: 1810.20"}

Bununla birlikte, gRPC portunun (9090) düzgün yanıt verip vermediğini test etmek için küme içerisinden geçici bir test podu oluşturabilir ve gRPC sorguları gerçekleştirebiliriz. Bu sayede, ağ içi iletişimin (internal networking) kesintisiz çalıştığından emin oluruz. Sonuç olarak, bu adımları tamamladığınızda Slinky oracle sisteminiz tamamen işlevsel hale gelmiş olacaktır.

Gerçek Dünya Senaryosu: Bir DeFi Protokolü İçin Slinky Canlı Uygulaması

Slinky’nin gücünü daha iyi anlamak adına, gerçek bir kullanım senaryosunu (case study) ele alalım. DigitalOcean üzerinde çalışan ve Cosmos tabanlı bir blokzincirde işlem yapan “AuraFinance” adında bir merkeziyetsiz borç alma/verme (lending) protokolümüz olduğunu varsayalım.

AuraFinance, kullanıcıların teminat oranlarını anlık olarak izlemek zorundadır. Eğer Ethereum (ETH) fiyatı aniden düşerse ve oracle verisi sisteme geç ulaşırsa, protokol kötü niyetli borçlular nedeniyle zarara uğrayabilir (bad debt). Slinky öncesinde, AuraFinance fiyat güncellemelerini her 10 saniyede bir alıyordu ve bu durum ani piyasa hareketlerinde (flash crashes) büyük risk oluşturuyordu.

DOKS üzerinde Slinky entegrasyonu tamamlandıktan sonra süreç şu şekilde optimize edilmiştir:

• Slinky, Binance ve Coinbase WebSocket bağlantıları üzerinden ETH fiyatını her 200 milisaniyede bir günceller.
• Doğrulayıcı düğümler, blok teklif ederken Slinky gRPC servisinden en güncel fiyatı çeker ve bunu doğrudan bloğun içine gömer.
• AuraFinance akıllı sözleşmeleri, her blok başında (yaklaşık 1-2 saniye) kesin ve manipüle edilemez fiyat verisine erişir.

Bu dönüşüm sayesinde AuraFinance, tasfiye işlemlerini milisaniyeler içinde gerçekleştirerek platform riskini sıfıra indirmiştir. Ayrıca, harici oracle sağlayıcılarına ödenen yüksek işlem ücretleri ortadan kalkmış, tüm veri akışı doğrulayıcıların kendi altyapısı üzerinden güvenli bir şekilde akmaya başlamıştır.

Performans Optimizasyonu ve İzleme (Monitoring) Yöntemleri

Slinky’yi üretim ortamında (production) çalıştırırken, yüksek erişilebilirlik ve düşük gecikme süresini garanti altına almak için bazı optimizasyonlar yapılması şarttır. Kubernetes ortamında bu durum kaynak yönetimi ve doğru izleme stratejileriyle sağlanır.

İlk olarak, CPU ve Bellek (Memory) limitlerini doğru ayarlamak gerekir. Slinky, yoğun ağ trafiği altında CPU tüketimini artırabilir. Bu nedenle, Kubernetes Deployment dosyasında belirttiğimiz resources alanını uygulamanızın yük testlerindeki davranışına göre optimize etmelisiniz. CPU “throttling” yaşanmaması için limit değerlerini esnek tutmak önemlidir.

İkinci olarak, Slinky’nin sunduğu Prometheus metriklerini kullanarak sistemi anlık olarak izlemeliyiz. Slinky, varsayılan olarak 8080 portundan metrik yayınlar. Kümenizde kurulu bir Prometheus ve Grafana altyapısı varsa, aşağıdaki metrikleri takip ederek sistem sağlığını izleyebilirsiniz:

• slinky_provider_request_duration_seconds: Veri sağlayıcılardan fiyat çekme süresi (gecikme analizi için kritik).
• slinky_provider_requests_failed_total: Başarısız olan API isteklerinin sayısı (sağlayıcı kesintilerini tespit etmek için).
• slinky_grpc_request_duration_seconds: Doğrulayıcı düğümün Slinky’ye yaptığı gRPC çağrılarının yanıt süresi.

Son olarak, DigitalOcean’ın sunduğu VPC (Virtual Private Cloud) özelliklerinden yararlanarak, doğrulayıcı düğüm ile Slinky podları arasındaki ağ trafiğini tamamen özel ağ (private network) üzerinde tutmalısınız. Bu yapılandırma, hem güvenliği artırır hem de genel internet üzerindeki olası gecikmelerden etkilenmenizi önler.

Sıkça Sorulan Sorular (SSS)

Slinky’yi validator podu ile aynı podda mı (sidecar) çalıştırmalıyım?

Evet, en düşük gecikme süresini (low latency) hedefliyorsanız, Slinky’yi validator podunuzun içerisinde ikinci bir konteyner (sidecar) olarak çalıştırmanız önerilir. Ancak, birden fazla düğüme hizmet verecekseniz bağımsız bir Kubernetes Service olarak konumlandırmak daha mantıklıdır.

DigitalOcean DOKS üzerinde Slinky çalıştırmanın maliyeti nedir?

Slinky son derece hafif bir uygulamadır. Bu rehberde kullandığımız 3 düğümlü DOKS kümesi (g-2vcpu-8gb düğüm tipi) aylık yaklaşık 120-150 USD civarında bir maliyete sahiptir. Slinky tek başına çok az kaynak tükettiği için mevcut validator altyapınızın üzerine ek bir ücret ödemeden de kurulabilir.

Slinky hangi veri kaynaklarını (providers) destekler?

Slinky; Binance, Coinbase, dYdX, OKX, Kraken ve Bybit gibi dünyanın en büyük merkezi borsalarının yanı sıra çeşitli merkeziyetsiz borsaların (DEX) API ve WebSocket bağlantılarını kutudan çıktığı haliyle desteklemektedir.

Ağ gecikmelerini azaltmak için hangi DigitalOcean bölgesini seçmeliyim?

Veri sağlayıcıların (borsaların) sunucularına en yakın olan bölgeleri seçmek gecikmeyi azaltır. Genellikle Frankfurt (fra1) veya New York (nyc3) bölgeleri, finansal veri sağlayıcılarının sunucularına yakınlığı nedeniyle en çok tercih edilen DOKS bölgeleridir.