Akamai/Linode hosting: Türkiye’den kullanım için teknik rehber

Linode (Akamai) altyapısı; geliştiricilerin kontrolü elinde tutabildiği VPS/VDS benzeri modelleriyle bilinir. Türkiye’den erişimde başarı, sadece sağlayıcının hızından değil; doğru ağ tasarımı, TLS (HTTPS) kurulumu, DNS yönlendirmesi, önbellekleme ve izleme gibi operasyonel seçimlerden etkilenir. Bu rehberde, Akamai/Linode sunucusunu Türkiye’den kullanırken erişim hızı, stabilite ve hata ayıklama için uygulanabilir adımları, ölçüm yöntemleriyle birlikte vereceğiz.

1) Türkiye’den erişimde asıl belirleyiciler: yol (route), DNS ve önbellek

Türkiye’den ABD/Avrupa dışındaki bir bölgeye istek attığınızda gecikme (latency) kaçınılmaz olarak artar. Bu durum, web uygulamanızın kullanıcı deneyimini doğrudan etkiler; özellikle ilk istek (TTFB) ve yeni bağlantılar.

Aşağıdaki üç unsur, çoğu projede “en çok fark yaratan” gruptur:

Network yol tasarımı: Trafik hangi POP/ISP üzerinden gidiyor? (Traceroute ve gerçek kullanıcı ölçümü gerekir.)
DNS çözümleme ve kayıt doğruluğu: Yanlış TTL veya gecikmeli yanıt, bağlantı kurma süresini uzatır.
Önbellek katmanları: Uygulama katmanında sayfa/HTML önbelleği, reverse proxy önbelleği ve gerektiğinde CDN katmanı.

Nereden başlamalısınız? (Hız testiyle değil, hedefle)

“Linode hızlı mı?” sorusunu yanıtlamadan önce şu soruyu netleştirin: Kullanıcılarınız için kritik performans metrikleri neler?

Çok sayıda küçük API çağrısı mı yapıyorsunuz? (TLS handshake ve bağlantı yeniden kullanımı önem kazanır.)
Tek sayfa uygulama (SPA) mı? (Statik içerik önbelleği çok kritik olur.)
Dinamik e-ticaret sayfaları mı? (Uygulama önbelleği + ürün görsel/asset CDN’i fark yaratır.)

Bu çerçeve olmadan “hangi plan daha hızlı?” sorusu çoğunlukla yanlış ölçülür.

2) Linode bölgesi seçimi: Avrupa yakınlığı tek başına yeterli değil

Linode’da (Akamai) bölge seçimi, Türkiye’ye giden yolun uzamasını etkiler. Ancak sadece “Avrupa seçtim, yeter” yaklaşımı hatalıdır. Aynı Avrupa bölgesi içinde bile farklı saatlerde farklı rota davranışı görülebilir.

Bölge seçerken net kontrol listesi

Aşağıdaki adımları uygulayın:

Hedef kitlenizi netleştirin: Türkiye’de hangi şehirler önde? (Özellikle operasyon ekibinizin “kullanıcı şikayeti” aldığı yerler.)
Her aday bölge için: - Aynı endpoint üzerinden gerçek HTTP istekleri yapın. - TLS handshake süresini ayırın. - İlk bayt (TTFB) ve içerik tamamlanma süresini karşılaştırın.
Aynı gün içinde en az 2 farklı saat bandında test edin (ör. 12:00–14:00 ve 20:00–22:00).

Uygulama: baseline ölçüm komutları

Sunucuya bağlanma testinde sadece ping’e güvenmeyin; web performansı ping değil HTTP zamanlarına göre şekillenir.

İstek süresi (örnek):
curl -w "time_connect=%{time_connect} time_appconnect=%{time_appconnect} time_starttransfer=%{time_starttransfer} total=%{time_total}\n" -o /dev/null -s https://ornek-domain.com/
Gerekirse bağlantı yolunu görmek için traceroute (Linux):
traceroute -T -p 443 ornek-domain.com

Bu ölçümler “latency yüksek ama nereden?” sorusuna cevap üretir: DNS mi, TLS mi, yoksa sunucu yanıt süresi mi?

3) TLS/HTTPS kurulumu: Türkiye’den erişimde handshake optimizasyonu

Türkiye’den uzaktaki bir sunucuya bağlanırken TLS handshake süresi, toplam yanıt süresinin önemli bir parçası olabilir. Doğru sertifika + doğru konfigürasyonla bu etki azaltılır.

Net TLS yapılandırma hedefleri

Güvenilir CA zinciri: Sertifikanın tam zincirle servis edildiğinden emin olun.
Yeterli anahtar/şifre paketi seçimi: Eski/uyumsuz cipher’lar bazı istemcilerde handshake’i uzatır.
Keep-Alive ve HTTP/2/HTTP/3 stratejisi: Aynı kullanıcı birden çok istek attığında bağlantı yeniden kullanımı önemlidir.

Pratik kontrol noktaları

TLS sürümünü doğrulayın: modern istemcilerde TLS 1.2+ / TLS 1.3 kullanılmalıdır.
Sertifika zinciri hatalarını tarayıcı konsolundan ve openssl s_client testlerinden yakalayın.
“Sürekli 90 gün” gibi operasyonel konularda (sertifika yenileme otomasyonu) net süreç kurun; ani süresi dolmalar kullanıcı erişimini doğrudan keser.

Not: Burada amaç “en yeni özellikleri açalım” değil; Türkiye’den gelen istemcilerde stabil ve hızlı handshake sağlamak.

4) DNS ve kayıtlar: TTL, A/AAAA ve yönlendirme hatası performansa yazar

DNS, bağlantı kurulmadan önceki gecikmenin en sık gözden kaçan kaynağıdır. Türkiye’deki ISP/operatörlerin DNS cache davranışları da fark yaratır.

DNS’te en sık yapılan hatalar

Yüksek TTL ile taşınma gecikmesi: Sistem değişince 24–48 saat güncelleme farkı oluşur.
Yanlış A/AAAA: IPv6 açık ama yanlış/eksik kayıtlar yüzünden istemci bağlantıyı denemeyi uzatır.
CNAME zinciri: Birden fazla CNAME hop’u; bazı resolver’larda gecikmeye sebep olur.

Net öneriler

En azından uygulama endpoint’iniz için A/AAAA kayıtlarını doğrulayın.
Yeni kurulumlarda TTL’i geçişe uygun tutun (ör. değişiklik bekleniyorsa daha düşük TTL planlayın).
MX ve TXT gibi e-posta kayıtları ayrı yönetilmelidir; uygulama DNS’i ile karışması erişimi etkiler.

5) Önbellek ve CDN stratejisi: “CDN şart mı?” sorusunu metrikle yanıtlayın

CDN (Content Delivery Network) kullanımı Türkiye’den erişimde sıklıkla ciddi hız getirir; ancak her senaryoda aynı sonucu vermez. Akamai ekosistemiyle (veya dış CDN ile) kurabileceğiniz yapı, statik içerik ve dinamik yanıtlar için farklı tasarlanmalıdır.

Senaryoya göre karar tablosu

Durum	Hangi içerik baskın?	En yüksek etki sağlayan katman	Hedef metrik
SPA / blog	HTML + JS/CSS + görseller	Statik asset önbelleği (CDN) + gzip/brotli	TTFB ve asset download süresi
API + mobil uygulama	Küçük JSON yanıtları	Keep-Alive + doğru cache-control	total istek süresi
E-ticaret	Ürün sayfaları + görseller	Uygulama önbelleği + görsel CDN	LCP/İlk yükleme
Admin paneli	Dinamik içerik az	Reverse proxy + uygulama seviyesinde cache	kullanıcı aksiyon yanıt süresi

Reverse proxy ile temel kazanımlar

Linode üzerinde Nginx/Apache tarafında: - sık kullanılan sayfalar için cache stratejisi, - sık güncellenmeyen içerik için ETag/Last-Modified uyumu, - sıkıştırma (gzip veya br) kullanımı, - istekleri optimize eden başlıklar (ör. Cache-Control) hedeflenmelidir.

6) İzleme (monitoring) ve hata ayıklama: Türkiye kaynaklı sorunları bölümlere ayırın

“Türkiye’den yavaş” şikayetinde tek bir noktaya odaklanmak yerine zinciri parçalara ayırın.

Log ve metrikleri bölümlere ayırın

DNS çözümleme süresi: Resolver zamanlaması
TLS handshake süresi: HTTP client ölçümü
Sunucu uygulama yanıt süresi: Application log’larda request süresi
Reverse proxy süresi: Nginx/Apache upstream zamanları
Hata oranı: 4xx/5xx ve timeout yüzdeleri

Net önerilen araç yaklaşımı

Uygulama tarafında (ör. Node/Python) request latency histogramları
Reverse proxy tarafında upstream time
Sistem tarafında CPU steal time / IO wait (performans düşüşlerini yakalamak için)

Türkiye’den gelen kullanıcıların şikayeti geldiyse, zaman farkı oluşturacak şekilde “aynı saatlerde” karşı test yapın. Bu sayede bölge/rota değişimini de yakalarsınız.

7) Performans düşüşlerinde tipik kök nedenler ve Linode üzerinde çözüm

Türkiye’den erişimde bazen sorun “sunucu yavaş” değildir; yapı değiştikçe gecikme artar.

En sık görülen 6 neden

Yetersiz vCPU/CPU limitleri: Özellikle PHP/Node uygulamalarında yoğun eşzamanlılıkta artar.
Disk IO darboğazı: Veritabanı ve cache storage etkilenir.
Aşırı küçük instance + burst kullanım: Ani trafik dalgalarında timeout.
Yanlış worker/process ayarları: Nginx worker sayısı veya uygulama concurrency ayarı.
Veritabanı sorgu problemi: Türkiye’den gelen trafik kadar değil, belirli sorgularda gecikme.
Sertifika yenileme/konfigürasyon hatası: Belirli istemcilerde handshake bozulur.

Net iyileştirme sırası

Uygulama log’unda yavaş endpoint’i bulun.
Reverse proxy upstream süresini kontrol edin.
Veritabanında en pahalı sorguları tespit edin.
Gerekirse önbellek katmanını devreye alın.
Hâlâ sürüyorsa instance ölçekleyin (vCPU/RAM) ve tekrar ölçün.

Bu sırayla ilerlemek, “önce büyütelim” yaklaşımına kıyasla daha hızlı ve daha ucuz sonuç verir.

8) Türkiye’ye yönelik güvenlik ve erişilebilirlik: doğru sorumluluk paylaşımı

Hosting sağlayıcısı güvenlikte bazı katmanları yönetir, siz ise uygulama ve ağ politikasından sorumlusunuz. Türkiye’den erişim söz konusu olduğunda erişilebilirlik (uptime) ve güvenli erişim birlikte düşünülür.

Net güvenlik kontrol listesi

Sunucuya giriş: sadece gerekli portlar, güvenli SSH ayarları (key tabanlı erişim)
Güvenlik güncellemeleri: işletim sistemi ve runtime düzenli güncellenmeli
TLS/sertifika yenileme otomasyonu: kesintisiz erişim için
Yedekleme (backup): düzenli, test edilmiş ve geri dönüş (restore) denemesi yapılmış olmalı
Log saklama: incident analiz için yeterli süre

Sonuç: Linode’u Türkiye’den kullanmak için “ölç → optimize → ölçekle” planı kurun

Akamai/Linode altyapısını Türkiye’den kullanırken en doğru yaklaşım, sağlayıcıyı tek başına “hız” etiketiyle değerlendirmek yerine; bölge seçimini ölçümle yapmak, TLS ve DNS konfigürasyonunu netleştirmek, önbellek/CDN kararını içerik tipine göre vermek ve izleme ile kök nedeni ayırmaktır. Aksiyon olarak, ilk günde üç şey yapın: (1) aday bölge/endpoint için HTTP ölçümü çıkarın, (2) TLS ve DNS kayıtlarını doğrulayın, (3) statik içerik ve dinamik yanıt için önbellek stratejisini netleştirip trafik geldikçe sonuçları karşılaştırın. Bu adımlar tamamlandığında “Türkiye’den kullanım” performansı somut metriklerle iyileşir.