SQLite’nin 200 Kullanıcıyı Yormadan Taşımasının Sırrı

Bir Go uygulaması geliştirirken, performansın kullanıcı sayısı arttıkça düştüğünü fark etmek hiç de şaşırtıcı değil. Ancak, Autentico 2.0 adlı OAuth 2.0 ve OpenID Connect kimlik sağlayıcısının geliştiricileri için bu durum, beklenmedik bir dersle sonuçlandı. Sistemin 200 eş zamanlı kullanıcı altında nasıl sorunsuz çalışmaya devam ettiğini ve hangi tekniklerin performansı kurtardığını birlikte inceleyelim.

Kritik Performans Testinin Ardındaki Gerçekler

Autentico 2.0’yi piyasaya sürmeden önce ekip, k6 aracını kullanarak yoğunluk testi yaptı. Testlerde, 100 eş zamanlı kullanıcıdan oluşan bir senaryo oluşturuldu. Her kullanıcı, tam bir PKCE yetkilendirme kodu akışı gerçekleştirdi ve bu süreç beş HTTP isteği, dört-beş SQLite yazma işlemi ile bcrypt parola doğrulaması içeriyordu. Testler, eski bir i5 dizüstü bilgisayarı üzerinde çalıştırıldığında sonuçlar kabul edilebilir düzeydeydi; ancak performans, beklenenin çok altında kaldı.

Profil analizi, bcrypt.CompareHashAndPassword fonksiyonunun CPU zamanının %90’ından fazlasını tükettiğini ortaya çıkardı. Parolaları korumak amacıyla tasarlanan bcrypt’nin kasıtlı olarak yavaş çalışması, sistemin tekli darboğazı haline gelmişti. SQLite yazmaları mikro saniyeler içinde tamamlanırken, JWT imzalama neredeyse hiç zaman almıyordu. Kısacası, bcrypt her çekirdeği dolduruyordu.

Darboğazı İzole Etmek ve Ölçeklendirmek

Ekip ilk olarak bcrypt’nin yavaşlığının kaçınılmaz olduğunu düşündü. Sonuçta, bcrypt’nin amacı hesaplama maliyetini artırarak parola güvenliğini sağlamaktı. Ancak, tek bir yavaş fonksiyonun tüm sistemi felç edebilmesi, ilginç bir soruyu gündeme getirdi: Sadece bu darboğaçı izole edip ölçeklendirebilir miyiz?

Çözüm arayışında birçok yol denenmesine rağmen, hepsi başarısız oldu. CQRS (Komut Sorgu Sorumluluğu Ayrımı) ve LiteFS kullanılarak SQLite replikasyonu denenmiş, ancak bu da genel bir ölçeklendirme sorununa odaklanmıştı. PostgreSQL’e geçiş de gündeme geldi, ancak bcrypt darboğazı her sunucuda devam edecekti. Ayrıca, bcrypt işini ayrı süreçlerle çalıştırmak, IPC (ara süreç iletişimi) ek yükü getirirken performansı iyileştirmedi.

Sonunda, ekip tüm sistemi dağıtmak yerine sadece en yavaş bileşeni ölçeklendirme fikrine odaklandı. Bu yaklaşımın sonucu, Verifico adlı özel bir uzaktan çalışan hizmet oldu. Autentico, veritabanını yöneten ve diğer tüm işlemleri yerine getiren tek bir örnek olarak kalırken, parola doğrulaması gerektiğinde sistem, hash ve düz metni HTTP üzerinden bir çalışana gönderiyordu. Bu çalışanlar, durum bilgisi olmayan hafif hizmetler olarak çalışırken, minimum donanım üzerinde çalışabiliyordu. Hizmet, çalışanlar arasında dönüşümlü yük dengelemesi kullanıyordu ve çalışanlar müsait değilse yerel bcrypt’ye otomatik olarak geri dönüyordu.

Güvenlik ve Performans Dengesi

Verifico’nun tasarımında güvenlik de göz önünde bulunduruldu. Özel bir ağ üzerinden paylaşılan bir gizli anahtar kullanılarak, mTLS’nin operasyonel yükü veya yeniden icat edilmiş bir TLS alternatifi olan AES şifrelemesinin riskleri önlendi. Parola zaten kamuya açık internet üzerinden Autentico’ya ulaştığı için, VPC içinde bir ek hop (adım) eklemek, riski ihmal edilebilir düzeyde artırdı.

Beklenmedik Bir Dönüş: Ryzen’in Gizli Darboğazı

Verifico’nun i5 üzerinde sağladığı iyileşmeler umut vericiydi. İki çekirdekle sınırlandırılan sunucu, giriş dışı uç noktaların saniyelerden milisaniyelere düştüğünü gösterdi. Çalışan sayısı arttıkça throughput doğrusal olarak yükseldi ve yaklaşık altı çekirdeğe ulaştığında sabitlendi.

Ancak, ekip aynı testleri 16 çekirdekli, daha hızlı tekli çekirdek performansına sahip bir Ryzen 7 masaüstü bilgisayarı üzerinde yaptığında hikaye değişti. Autentico’yu iki çekirdekle sınırlandırıp çalışan sayısını ikili olarak artırdıklarında (2+2, 2+4, 2+14’e kadar), throughput tüm konfigürasyonlarda yaklaşık 15.4 ila 14.7 iterasyon/saniye arasında sabit kaldı. Ortanca gecikme (p95) yaklaşık 3.6 saniye civarında seyretti. Ek çalışanlar hiçbir iyileşme sağlamadı.

Ryzen’in daha hızlı çekirdekleri bcrypt hash’lerini o kadar hızlı işliyordu ki, fonksiyon artık performans profilinde baskın olmaktan çıkmıştı. Gerçek darboğaz başka bir yere kaymıştı: Go’nun veritabanı bağlantı havuzuna.

Veritabanı Havuzunda Gizlenen Rekabet

Ryzen üzerinde yapılan profil analizi, Go blok profilinin yük altında her rekabet noktasının database/sql.(*DB).conn üzerinde yoğunlaştığını gösterdi. Gorutinler, bir veritabanı bağlantısı için sıraya giriyordu. Okuma işlemleri rekabetin %65’ini oluştururken, yazmalar %35’ini oluşturuyordu. En büyük suçlular, istemci kimliği aramaları, oturum oluşturma ve token üretimi gibi rutin ancak yoğun işlemlerdi. Bu işlemler bireysel olarak hızlı olsa da toplu olarak bağlantı havuzunu tüketiyordu.

WAL Modunun Sessiz Zaferi

Bu keşif, ekip için önemli bir ders oldu: Performans darboğazları her zaman beklenen yerde değildir. CPU kaynaklı bir kriz gibi görünen şey aslında veritabanı mimarisinin temel bir sınırlamasından kaynaklanıyordu. En etkili çözüm, bcrypt’i ölçeklendirmek yerine SQLite’nin eş zamanlı çalışma modelini optimize etmek oldu.

Ekip, veritabanını Write-Ahead Logging (WAL) moduna geçirerek çözümü buldu. WAL modu, okuyucular ve yazıcıların aynı anda çalışmasına izin vererek bağlantı havuzundaki rekabeti ortadan kaldırdı. Sonuç, giriş dışı uç noktaların milisaniyeler içinde tamamlandığı dikkat çekici bir performans artışıydı. Artık bcrypt darboğazı değil, veritabanı yapılandırması iyileştirilmişti.

Geleceğe Yönelik Dersler ve Uygulamalar

Autentico’nun hikayesi, performans sorunlarının sadece donanım ya da kod optimizasyonuyla değil, mimarinin yeniden düşünülmesiyle çözülebileceğini gösterdi. Bir fonksiyonun yavaşlığının tüm sistemi felç etmesine izin vermek yerine, darboğazları izole edip ölçeklendirmek mümkün. Ayrıca, SQLite’nin WAL modu gibi basit yapılandırmalar, büyük ölçeklendirme projelerine gerek kalmadan performansı önemli ölçüde artırabilir.

Geliştirici ekip, şimdi Autentico’nun yeni sürümü üzerinde çalışırken, bu dersleri gelecekteki projelerinde de uygulamayı planlıyor. Performansın sadece sayılarla değil, doğru mimari seçimlerle ilgili olduğu bir kez daha kanıtlandı.