Camiler.org'u Neden Tek VPS Üzerinde Çalıştırıyorum?

💡 Özet (TL;DR):

• Karar: Camiler.org için her işi ayrı bir yönetilen hizmete dağıtmak yerine, servisleri Docker ile ayırıp tek küçük VPS üzerinde çalıştırdım.
• Mimari: Redis aynı sayfaların ve sorguların tekrar tekrar üretilmesini azaltıyor. Cloudflare ise statik içerik ile görsel trafiğinin önemli bölümünü ana sunucuya ulaşmadan karşılıyor.
• Bedeli: Doğrudan altyapı faturası düşük kaldı, fakat sunucunun bakımı ve tek makineye bağlı olmanın getirdiği kesinti riski bende kaldı.

Camiler.org'u tek başıma geliştiriyorum. Projeye başladığımda kullandığım VPS'in aylık maliyeti yaklaşık 5 dolardı.

Bu bütçeyle her ihtiyaç için ayrı bir yönetilen hizmet kullanmak zaten anlamlı değildi. Fakat maliyet tek başına yeterli bir açıklama değil. Bir hizmet daha satın aldığınızda yalnızca yeni bir fatura eklemiyorsunuz. Yeni bir kontrol paneli, yeni bir bağımlılık ve sorun çıktığında bakmanız gereken yeni bir yer de ekliyorsunuz.

Camiler.org için kurduğum altyapının tek kişinin anlayabileceği kadar sade kalmasını istedim. Bir servis bozulduğunda nereden başlayacağımı, hangi verinin nerede tutulduğunu ve siteyi önbellek olmadan nasıl çalıştıracağımı bilmem gerekiyordu.

Bu yazıdaki kararlar buradan çıktı. Projenin arama ve içerik tarafını Google Maps ve OpenAI ile yaptığım programatik SEO deneyinde anlattım. Burada ise sitenin bugün nasıl ayakta kaldığını ve düşük altyapı faturasının karşılığında hangi sorumluluğu üstlendiğimi anlatacağım.

Sistemin kısa hali

Sistemin tamamı tek VPS üzerinde çalışıyor. Her servis kendi Docker konteynerinde.

Sayfa isteği:  Kullanıcı -> Cloudflare -> Traefik -> Nuxt -> Redis
API isteği:    Kullanıcı -> Cloudflare -> Traefik -> Fastify -> Redis / MariaDB
Görsel isteği: Kullanıcı -> Cloudflare önbelleği -> imgproxy -> Cloudflare R2
Dağıtım:       GitHub Actions -> özel registry -> dağıtım webhook'u -> konteynerler

Dışarıdan gelen istekleri önce Traefik karşılıyor. Hangi alan adının hangi konteynere gideceğini Docker etiketlerinden okuyarak belirliyor. Let’s Encrypt sertifikalarını yeniliyor ve Portainer ile phpMyAdmin gibi iç araçlara IP kısıtlaması uyguluyor.

Traefik'i tercih etmemin pratik nedeni buydu. Yeni bir servis eklediğimde ayrı bir reverse proxy dosyası hazırlayıp yeniden yüklemek yerine, yönlendirme kuralını konteynerin yanında tanımlayabiliyorum. Bu, tek başıma işlettiğim bir sistemde tekrar eden küçük işleri azaltıyor.

Elbette etiketi yanlış yazarsam Traefik beni kurtarmıyor. Hangi servisin internete açıldığını ve konteynerlerin hangi ağlara erişebildiğini yine benim kontrol etmem gerekiyor.

Küçük sunucuda önce tekrarlanan işi azalttım

Camiler.org'un ön yüzü Nuxt 3 ile SSR modunda çalışıyor. Aynı cami sayfasını her istekte yeniden oluşturmak, küçük bir VPS'in işlemcisini ve belleğini gereksiz yere kullanmak demekti.

Bu nedenle sayfanın ürettiği HTML'i Redis'e kaydeden bir middleware yazdım. HTML, bellekte daha az yer kaplaması için sıkıştırılıyor. ETag desteği, değişmemiş içeriğin yeniden gönderilmesini önlemeye yardımcı oluyor.

Burada yalnızca süreye bağlı bir önbellek yeterli değildi. Bir caminin bilgisi değiştiğinde o caminin sayfasıyla birlikte “yakındaki camiler” gibi ilişkili sayfaların da temizlenmesi gerekiyordu. Etiket tabanlı temizleme sistemi bu yüzden var.

Redis yanıt vermezse sitenin çalışmaya devam etmesini özellikle istedim. Böyle bir durumda sayfalar önbellekten gelmiyor ve sunucu daha fazla çalışıyor, fakat kalıcı veri kaybolmuyor. Redis burada hızlandırıcı. Verinin asıl sahibi değil.

Arka uçta Fastify, Prisma ve MariaDB kullanıyorum. Redis aynı zamanda sık kullanılan sorgu sonuçlarını ve oran sınırlama sayaçlarını tutuyor. Hazır rate limiter paketleri rota, kullanıcı, grup ve genel limitleri birlikte istediğim biçimde yönetmeyince küçük bir middleware yazdım.

Kendi middleware'imi yazmak bana istediğim kontrolü verdi. Bakım sorumluluğunu da verdi. Bir paketi kullanmamak, o işin ortadan kalktığı anlamına gelmiyor.

Görsel trafiğini VPS'in üzerinden aldım

Cami görsellerini farklı ekranlar için farklı boyut ve formatlarda sunmak gerekiyor. Her görselin bütün sürümlerini önceden üretip uygulamanın içinde saklamak istemedim.

Orijinal dosyaları Cloudflare R2'de tutuyorum. imgproxy, istenen boyut ve formattaki görseli gerektiğinde üretiyor. Benim yapılandırmamda Cloudflare bu çıktıyı edge önbelleğinde saklayabiliyor. Aynı görsel tekrar istendiğinde talep çoğu zaman VPS'e, imgproxy'ye veya R2'ye kadar ulaşmıyor.

Bu tercih küçük sunucunun hem işlemci hem de ağ yükünü azaltıyor. R2'nin S3 uyumlu olması da ileride başka bir sağlayıcıya veya MinIO'ya geçmek istersem kullanabileceğim bir yol bırakıyor.

Yine de “S3 uyumlu” demek, sağlayıcı değiştirmenin zahmetsiz olacağı anlamına gelmiyor. Dosyaları taşımak işin kolay tarafı olabilir. Erişim bilgilerini, önbellek kurallarını ve uygulamanın dosya akışını da yeniden düzenlemek gerekir.

Dağıtımı bilerek küçük tuttum

Ana branch'e bir değişiklik gönderdiğimde GitHub Actions ilgili Docker imajını oluşturuyor ve özel registry'ye yüklüyor. Ardından sunucudaki küçük bir webhook'u çağırıyor. Webhook da ilgili konteyneri yeni imajla yeniden başlatıyor.

Bu akışın iddialı bir tarafı yok. Manuel olarak sunucuya bağlanıp komut çalıştırma ihtiyacını ortadan kaldırıyor ve hangi adımın ne zaman çalıştığını görmemi sağlıyor. Tek kişinin işlettiği bu proje için ihtiyacım olan da buydu.

Portainer'ı konteynerlerin durumuna ve loglarına hızlıca bakmak için kullanıyorum. phpMyAdmin ise zaman zaman veri tabanını incelememi kolaylaştırıyor. İkisi de IP kısıtlamasının arkasında ve sitenin normal istek akışında yer almıyor.

Aylık fatura düşük, toplam maliyet o kadar basit değil

Tek küçük VPS üzerinde çalışmak, Camiler.org'un doğrudan altyapı faturasını düşük tutuyor. Buna bakıp yönetilen hizmetlerle aradaki farkın tamamını tasarruf saymak kolay.

Ama sunucuyu güncelleyen, konteynerleri izleyen, bozulan dağıtımı düzelten ve önbelleğin doğru temizlenip temizlenmediğine bakan kişi de benim. Yönetilen hizmete ödemediğim paranın bir bölümünü kendi zamanımla ödüyorum.

Tek VPS'in daha önemli bedeli ise kesinti riski. Servisler Docker ile birbirinden ayrılmış olsa da aynı makinede çalışıyor. Sunucuya ulaşamazsam Nuxt, Fastify, Redis ve MariaDB'nin ayrı konteynerlerde olması siteyi ayakta tutmuyor.

Bugün bu riski kabul edebiliyorum. Camiler.org gelir üretmiyor ve sistemi tek başıma işletiyorum. Bu koşullarda daha pahalı bir yüksek erişilebilirlik yapısı kurmanın karşılığı yok. Koşullar değişirse aynı mimariye bağlı kalmanın da bir anlamı olmaz.

Tek VPS'ten ne zaman vazgeçerim?

Kararı sunucunun dolmasını beklemeden yeniden değerlendireceğim birkaç açık durum var:

• Bir kesintinin maliyeti ikinci sunucu ve otomatik kurtarma maliyetinden daha yüksek hale gelirse
• Veri tabanı, görsel işleme veya SSR yükü diğer servislerin çalışmasını bozmaya başlarsa
• Altyapıyı birden fazla kişi veya ekip bağımsız biçimde yönetmek zorunda kalırsa
• Yedekleme, kurtarma, denetim veya mevzuat gereksinimleri mevcut yapıyı yetersiz bırakırsa
• Bakım için harcadığım zaman, yönetilen bir hizmetin ücretinden daha pahalı hale gelirse

Böyle bir noktada her şeyi baştan yazmak gerekmiyor. Veri tabanı, uygulama veya görsel işleme ayrı sunuculara taşınabilir. Cloudflare ve R2 kullanılmaya devam edebilir ya da değiştirilebilir. Docker kullanmamın asıl faydası da burada ortaya çıkıyor: Servisleri bugün aynı makinede çalıştırırken yarın ayırmak için makul bir yol bırakıyor.

Camiler.org'u tek VPS üzerinde çalıştırmak benim için teknik bir gösteri değil. Bugünkü ihtiyacı gereksiz fatura ve bakım yükü oluşturmadan karşılamanın yolu.

Şimdilik bu sistem işimi görüyor. Faturası düşük, sınırlarını biliyorum ve sorun çıktığında nereye bakacağımı biliyorum. Bu karar ancak kesinti riski, trafik yükü veya bakım maliyeti artık kabul edemeyeceğim bir seviyeye geldiğinde değişecek.