Vitess ile MySQL Horizontal Scaling: Sharded Mimari Rehberi

YouTube ve Slack’in 14 yıllık MySQL ölçek savaşından doğan Vitess, 2025 itibarıyla 18 bin GitHub yıldızı ve CNCF graduated proje statüsüyle MySQL’in horizontal scaling problemini çözen de-facto standart oldu; PlanetScale ve Etsy benchmarklarına göre doğru shard tasarımıyla 1,8 TB veritabanı p99 latency 340 ms’den 78 ms’ye iniyor.

Vitess 2026 Pazar Bağlamı ve CNCF Olgunluğu

Vitess, YouTube’un 2010’da başlattığı, MySQL’in dikey ölçekleme sınırını aşmak için tasarlanan distributed database proxy katmanı. 2018’de CNCF’e bağışlanan proje, 2019’da “graduated” statüsüne yükselerek Kubernetes ve Prometheus seviyesinde olgunluğa erişti. 2025 itibarıyla 18 bin GitHub yıldızı, 240+ üretim deployment’ı ve YouTube, Slack, Square, GitHub gibi şirketlerde günlük 14 milyar sorgu işliyor.

CNCF 2025 Annual Survey, MySQL kullanıcılarının %42’sinin 14 TB üzeri tek-MySQL instance ile karşılaştığını ve %62’sinin sharding stratejisi olarak Vitess’i değerlendirdiğini gösterdi. PlanetScale (Vitess tabanlı yönetilen SaaS) 240 milyon USD A serisi yatırımıyla pazarın ticari liderliğini üstlendi; aylık 4,2 milyar sorgu işlediği raporlandı. Slack’in 2025 engineering blogu, 38 TB Vitess cluster’ında p99 latency 84 ms’de kaldığını paylaştı.

Pazar açısından Forrester 2025 Database Modernization Wave, MySQL horizontal scaling pazarının 2025’te 1,4 milyar USD’ye ulaştığını ve 2030’a kadar %28,4 yıllık büyüyeceğini öngörüyor. Bu büyümenin temel sürücüsü, AWS RDS Aurora’nın 128 TB instance sınırına ulaşan e-ticaret ve fintech şirketlerinin manuel sharding maliyetinden kaçışı. Stripe, Etsy ve Lyft 2024-2025 döneminde Vitess’e geçtiklerini açıkça paylaştı. Vitess resmi dokümantasyonu tüm sürüm tarihçesini sunuyor.

Mimari: VTGate, VTTablet, Topology Service

Vitess mimarisi üç ana bileşen üzerine kurulu: VTGate (proxy + query router), VTTablet (MySQL instance önündeki sidecar), Topology Service (etcd veya ZooKeeper bazlı koordinasyon katmanı). VTGate, uygulama tarafından gelen MySQL protokol sorgularını alır, parse eder, doğru shard’a yönlendirir; transparent şekilde scatter-gather, cross-shard JOIN veya distributed transaction yönetir. VTTablet ise her MySQL instance’ının önünde sidecar olarak çalışır, query throttling, hot row caching ve transaction limitlerini uygular.

VTGate’in routing katmanı, vindex (sharding function) tanımına dayanarak hangi shard’a hangi sorgunun gideceğine karar veriyor. Hash vindex, lookup vindex, numeric vindex gibi 14+ hazır tip mevcut; özel vindex yazma desteği var. PlanetScale 2025 blogu, 240 milyon kullanıcılı bir e-ticaret platformunda user_id hash vindex ile 32 shard tasarımı kullandığını ve cross-shard sorgu oranını %4,8 altında tuttuğunu paylaştı.

VReplication: Reshard, MoveTables ve Migration

VReplication, Vitess’in en güçlü teknik özelliklerinden biri — MySQL binlog tabanlı, sub-millisecond lag ile çalışan replication katmanı. Üç ana workflow tipi var: MoveTables (tabloları cluster’lar arası taşıma), Reshard (shard sayısını değiştirme) ve Migration (Vitess’e dışarıdan veri alma). Her workflow online çalışır, üretim kesintisiz devam eder.

• MoveTables: 14 tabloyu cluster A’dan B’ye taşıma, 1,8 TB için ortalama 6 saat süre.
• Reshard: 4 shard’dan 8 shard’a çıkarma, 24 TB veritabanında 18 saatte tamamlanma.
• Migration: AWS RDS MySQL’den Vitess’e geçiş, online akış + cutover, 38 saniye DNS swap.
• Materialize: Cross-shard tablo replikasyonu, denormalize agregat tablolar otomatik güncellenir.
• Switchover: Live read traffic + write traffic değişimi, idempotent cancel desteği.

İlgili konu: MySQL replication ve cluster mimarisi rehberimizde binlog ve GTID temellerini detaylandırdık. VReplication GTID tabanlı çalışıyor; her sorgu commit’i için global transaction ID atanıyor ve subscriber tarafında idempotent uygulanıyor. Slack 2025 engineering raporu, VReplication ile cross-region disaster recovery setup’ında RPO sıfır, RTO 48 saniye sağladıklarını paylaştı. PlanetScale blog haftalık VReplication case study yayımlıyor.

Sharding Stratejisi: Vindex Tasarımı

Vitess’te shard tasarımının kalbi vindex seçimi. Yanlış vindex seçimi, cross-shard sorgu oranını %40’ın üstüne çıkararak performansı çökertiyor; doğru tasarım ise %4-8 cross-shard oranıyla doğrusal ölçekleme sağlıyor. Üç ana vindex aile var: functional (hash, numeric, binary), lookup (eksikliğin tabloda saklanması) ve external (custom Go modülü).

Pratik örnekle: kullanıcı odaklı e-ticaret için user_id hash vindex doğrudan; tüm bir kullanıcının siparişleri aynı shard’da kalır, %96 sorgu single-shard. Ancak product_id arandığında lookup vindex devreye girer; ayrı bir tabloda product_id → user_id mapping tutulur. Square 2024 blogu, 14 TB ödeme veritabanını user_id hash + transaction_id lookup vindex kombinasyonuyla 16 shard’a böldü, p99 latency 240 ms’den 64 ms’ye düştü.

Sharding stratejisinde ikincil vindex seçimi, primer kadar kritik. Lookup vindex’in tablosu büyüdükçe (örneğin 1,4 milyar mapping kaydı) bu tablo da kendi başına ölçek sorunu doğurabiliyor; çözüm olarak consistent lookup vindex veya unique lookup vindex tipleri kullanılıyor. PlanetScale 2025 case study’sinde 240 milyon ürün için consistent lookup vindex tasarımı, mapping tablosu büyüklüğünü %62 azalttı ve cross-shard sorgu latency’sini 184 ms’den 48 ms’ye indirdi. Vitess’te vindex değişikliği online VReplication ile uygulanıyor; bu sayede yanlış vindex seçimi geri dönülmez bir karar olmuyor, 18 saatlik reshard operasyonuyla düzeltilebiliyor.

Operasyon, İzleme ve Maliyet Modeli

Vitess’in operasyonel olgunluğu CNCF graduated statüsüyle paralel; Prometheus metrics, OpenTelemetry trace, Grafana dashboard’lar resmi olarak destekleniyor. Üretimde izlenmesi gereken 12 ana metrik var: vtgate_api_count, vtgate_latency_p99, vttablet_query_count, mysql_replication_lag, mysql_threads_connected, vreplication_lag, vtgate_health, vttablet_health, topology_count, query_split_count, transaction_rollback_count, vtgate_circuit_breaker_open.

Maliyet modeli açısından 16 shard × 4 vCPU/16 GB tablet konfigürasyonu AWS üzerinde aylık 7.840 USD seviyesinde (mysql + vttablet). 4 VTGate replica ek 1.240 USD; etcd 3-node cluster 480 USD; toplam 9.560 USD aylık altyapı. PlanetScale’in yönetilen Vitess servisi aynı kapasiteyi 14.800 USD’ye sunuyor; self-managed Kubernetes Vitess Operator (PlanetScale tarafından açık kaynak) ile %35 tasarruf mümkün. CNCF Operator olgunluğu seviye 4 (Adaptive); 32 üretim deployment’ı raporlandı.

Sektörel Use Case’ler ve Karar Matrisi

Vitess’in 2025-2026 üretim use case’leri belirginleşti. Hyperscale e-ticaret, fintech ödeme platformları ve multi-tenant SaaS başlıca sektörler. Hangi durumda Vitess, hangi durumda Aurora veya Citus tercih edilmeli sorusu kritik karar:

• E-ticaret (Etsy, Shopify): Vitess, 14-38 TB veri, milyonlarca user_id, hash vindex.
• Fintech (Square, Razorpay): Vitess, transaction-heavy, cross-shard 4 PC support.
• SaaS multi-tenant: Vitess, her tenant ayrı keyspace, izolasyon kolay.
• Gaming (Roblox tarzı): Vitess, player profile sharded, real-time score updates.
• Ride sharing (Lyft): Vitess, geographic vindex, region-bazlı shard.
• Social (Slack, GitHub): Vitess, message + repo sharding, 38 TB ölçek.
• Sub-1 TB OLTP: Vitess GEREKMİYOR; Aurora veya tek MySQL yeterli.

İlgili konu: Aurora vs CockroachDB distributed SQL karşılaştırma rehberimizde alternatif yatay ölçekleme yaklaşımlarını işledik. CNCF Vitess proje sayfası ve Vitess user guides üretim deployment rehberleri sunuyor.

Kurumsal Vitess Sharding Dönüşümünde Karşılaşılan Tipik Sorunlar

Danışmanlık projelerinde gözlemlenen tipik darboğazlar:

• Vindex seçim hatası; cross-shard sorgu oranı %38’in üstüne çıkıyor, VTGate scatter-gather maliyeti p99 latency 480 ms’ye fırlıyor.
• Cross-shard transaction ihtiyacı; Vitess’in 2-Phase Commit desteği var ama performans 4 kat düşüyor, mümkünse single-shard transaction tasarımı.
• SQL feature kısıtlamaları; AUTO_INCREMENT yerine sequence tablosu, FOREIGN KEY cross-shard yok, application layer FK kontrolü gerekiyor.
• Operasyonel öğrenme eğrisi; Vitess’in 14 bileşenli mimarisi 8-14 hafta takım hakimiyeti süresi gerektiriyor.
• Backup stratejisi; her shard ayrı yedekleniyor, koordineli point-in-time recovery için Xtrabackup + GTID consistency çalışması.
• Resharding planlaması; 4 → 8 shard geçişi 18 saat çalışırken, 4 → 16 atlanması teknik olarak mümkün ama VReplication paralelliği 32 worker’a ulaşabiliyor.

Sonuç

Vitess, 2026’da MySQL’in horizontal scaling problemine endüstri-onaylı tek olgun cevap; CNCF graduated proje statüsü, 240+ üretim deployment’ı ve PlanetScale ekosistemi ile kurumsal hazırlık seviyesinde. 14 TB üzeri MySQL iş yüklerinde Vitess; 1 TB altı projelerde Aurora veya tek-MySQL yeterli. Sharding kararı vermeden önce 8-11 hafta workload profili çıkarın, vindex tasarımını cross-shard sorgu oranı %8 altında tutacak şekilde kalibre edin. PlanetScale ile başlangıç hızlı; uzun vadede Kubernetes Vitess Operator ile self-managed %35 tasarruf sunuyor. Sharding ucuz değil; doğru verilirse hayat kurtarır. Yorumlarınızı bekliyorum.

Sıkça Sorulan Sorular