CDN Nedir? İçeriği Kullanıcıya Yaklaştırmanın En Pratik Yolu

Bir web sitesinin hızlı açılması çoğu zaman yalnızca uygulama kodunun iyi yazılmasıyla ilgili değildir. Kullanıcının isteği hangi sunucuya gidiyor, o sunucu kullanıcıya ne kadar uzak, içerik daha önce bir yerde saklanmış mı gibi sorular da performansı doğrudan etkiler. Bu yazıda CDN kavramını, yani Content Delivery Network yapısını, öncesindeki caching fikriyle birlikte sade bir şekilde öğreneceksin.

Web isteği normalde nasıl çalışır?

Bir kullanıcı tarayıcıya bir web adresi yazdığında ilk adım genellikle DNS çözümlemesidir. DNS, yani Domain Name System. Yani şöyle düşün: kullanıcı example.com gibi okunabilir bir adres yazar, DNS ise bunun hangi IP adresine karşılık geldiğini bulur.

IP adresi öğrenildikten sonra tarayıcı o adresteki sunucuya bağlanır. Sunucu da HTML, CSS, JavaScript, görsel veya video gibi dosyaları kullanıcıya döner. Eğer her kullanıcı her dosya için doğrudan ana sunucuya gitmek zorunda kalırsa, sistem hem yavaşlar hem de maliyet artar.

sequenceDiagram
    participant Kullanıcı as "Kullanıcı Tarayıcısı"
    participant DNS as "DNS Sunucusu"
    participant Origin as "Ana Sunucu"

    Kullanıcı->>DNS: "Alan adının IP adresini sorar"
    DNS-->>Kullanıcı: "IP adresini döner"
    Kullanıcı->>Origin: "Web sayfasını ister"
    Origin-->>Kullanıcı: "HTML, CSS, JS ve medya dosyalarını döner"

Bu diyagram, CDN kullanılmadan önceki temel web isteği akışını gösterir. Kullanıcı önce adresi çözer, sonra doğrudan ana sunucuya bağlanır.

Caching neden gerekli?

Caching, sık kullanılan veriyi daha hızlı erişilebilecek bir yerde saklama fikridir. Bunu şöyle hayal edebilirsin: Her seferinde depoya gidip aynı dosyayı almak yerine, çok istenen dosyaları masanın üstünde tutarsın.

Web sistemlerinde bu “masa üstü” bazen bellek olabilir, bazen yerel disk olabilir, bazen de kullanıcıya yakın başka bir sunucu olabilir. Amaç aynıdır: Aynı içeriği tekrar tekrar üretmek veya uzak bir yerden okumak yerine, daha yakındaki kopyayı hızlıca döndürmek.

flowchart TD
    A["Kullanıcı içerik ister"] --> B{"İçerik cache içinde var mı?"}
    B -->|"Evet"| C["Cache içeriği hızlıca döner"]
    B -->|"Hayır"| D["Ana sunucudan içerik alınır"]
    D --> E["İçerik cache'e kaydedilir"]
    E --> F["Kullanıcıya cevap döner"]

Bu akış, cache kullanımının temel mantığını anlatır. İçerik cache içinde varsa ana sunucuya gitmeye gerek kalmaz; yoksa önce ana kaynaktan alınır, sonra sonraki istekler için saklanır.

Tek sunucu neden yetmez?

Aslında küçük bir sistemde tek sunucu yeterli görünebilir. Fakat kullanıcılar farklı ülkelerden bağlanmaya başladığında işler değişir. Sunucu fiziksel olarak bir bölgede durur; kullanıcı ise dünyanın başka bir yerinde olabilir. Aradaki mesafe arttıkça ağ gecikmesi, yani latency artar.

Latency, isteğin gidip cevabın dönmesi için geçen süredir. Yani şöyle düşün: Aynı şehirdeki bir mağazadan ürün almakla başka kıtadaki bir mağazadan ürün beklemek aynı şey değildir. İnternette de fiziksel mesafe tamamen yok olmaz; kablolar, yönlendiriciler ve ağ geçişleri hâlâ işin içindedir.

flowchart LR
    subgraph "Kullanıcılar"
        U1["Avrupa'daki kullanıcı"]
        U2["Asya'daki kullanıcı"]
        U3["Amerika'daki kullanıcı"]
    end

    Origin["Tek ana sunucu"]

    U1 -->|"Orta gecikme"| Origin
    U2 -->|"Düşük veya yüksek olabilir"| Origin
    U3 -->|"Yüksek gecikme"| Origin

Bu yapı, tek bir sunucunun küresel kullanıcılar için neden ideal olmadığını gösterir. Sunucu bazı kullanıcılara yakın olabilir ama herkese aynı anda yakın olamaz.

CDN ne yapar?

CDN, yani Content Delivery Network. Bunu şöyle hayal edebilirsin: Ana sunucudaki statik içeriklerin kopyaları dünyanın farklı noktalarındaki küçük dağıtım merkezlerinde tutulur. Kullanıcı bir dosya istediğinde mümkünse kendisine en yakın CDN sunucusundan cevap alır.

Buradaki içerikler genellikle statik dosyalardır: görseller, videolar, CSS dosyaları, JavaScript paketleri, indirilebilir belgeler veya herkese aynı gösterilen HTML dosyaları. CDN bu dosyaları kullanıcıya yakın tuttuğu için sayfa daha hızlı açılır ve ana sunucunun yükü azalır.

flowchart TD
    subgraph "Kullanıcı Bölgeleri"
        A["Kullanıcı - Avrupa"]
        B["Kullanıcı - Asya"]
        C["Kullanıcı - Amerika"]
    end

    subgraph "CDN Edge Sunucuları"
        E1["Avrupa CDN noktası"]
        E2["Asya CDN noktası"]
        E3["Amerika CDN noktası"]
    end

    O["Ana Sunucu / Origin"]
    S["Dosya Deposu"]

    A --> E1
    B --> E2
    C --> E3

    E1 -.->|"Cache miss olursa"| O
    E2 -.->|"Cache miss olursa"| O
    E3 -.->|"Cache miss olursa"| O

    O --> S

Bu diyagramda CDN’in ana fikri görülüyor: Kullanıcı en yakın edge sunucusuna gider. İçerik orada yoksa CDN ana sunucudan alır, saklar ve sonraki isteklerde doğrudan kendisi döner.

CDN içindeki cache nasıl davranır?

CDN sunucuları da aslında birer sunucudur. IP adresleri vardır, istek alırlar, dosya saklarlar ve cevap üretirler. Farkları, ana uygulama mantığını çalıştırmak yerine çoğunlukla içerik dağıtımına odaklanmalarıdır.

Bir CDN noktası istenen dosyayı kendi üzerinde bulursa buna cache hit denir. Cache hit, yani şöyle düşün: aradığın dosya zaten yakındaki raftadır. Eğer dosya yoksa cache miss olur; CDN ana kaynağa gider, dosyayı alır ve kendi üzerinde tutar.

stateDiagram-v2
    [*] --> IstekGeldi

    state "İstek Geldi" as IstekGeldi
    state "Cache Hit" as CacheHit
    state "Cache Miss" as CacheMiss
    state "Origin'den Dosya Al" as OrigindenDosyaAl
    state "CDN'e Kaydet" as CDNeKaydet
    state "CDN Cevap Döner" as CDNCevapDoner

    IstekGeldi --> CacheHit: Dosya CDN'de var
    IstekGeldi --> CacheMiss: Dosya CDN'de yok

    CacheHit --> CDNCevapDoner
    CacheMiss --> OrigindenDosyaAl
    OrigindenDosyaAl --> CDNeKaydet
    CDNeKaydet --> CDNCevapDoner
    CDNCevapDoner --> [*]

Bu durum diyagramı, CDN’in bir isteğe nasıl karar verdiğini gösterir. En iyi senaryoda kullanıcıya cevap doğrudan CDN’den gelir; kötü senaryoda bile içerik bir kez alınır ve sonraki kullanıcılar için hazır bekler.

CDN sadece hız için mi kullanılır?

CDN’in en görünür faydası hızdır ama tek faydası bu değildir. Ana sunucuya daha az istek gittiği için altyapı maliyeti düşebilir. Trafik dünyanın farklı noktalarına yayıldığı için sistem daha dayanıklı hale gelir.

Bir diğer önemli konu da bölgesel kurallar ve içerik politikalarıdır. Bazı içerikler yalnızca belirli ülkelerde gösterilebilir. CDN sağlayıcıları genellikle bu tür bölgesel kuralları uygulamak için hazır özellikler sunar. Böylece her şirket kendi başına karmaşık bir dağıtım ve kural motoru yazmak zorunda kalmaz.

flowchart LR
    User["Kullanıcı"] --> Region{"Kullanıcının bölgesi nedir?"}

    Region -->|"Türkiye"| TR["Türkiye CDN noktası"]
    Region -->|"Almanya"| DE["Almanya CDN noktası"]
    Region -->|"ABD"| US["ABD CDN noktası"]

    TR --> P1{"İçerik bu bölgede yayınlanabilir mi?"}
    DE --> P2{"İçerik bu bölgede yayınlanabilir mi?"}
    US --> P3{"İçerik bu bölgede yayınlanabilir mi?"}

    P1 -->|"Evet"| C1["İçerik sunulur"]
    P1 -->|"Hayır"| R1["Erişim reddedilir"]

    P2 -->|"Evet"| C2["İçerik sunulur"]
    P2 -->|"Hayır"| R2["Erişim reddedilir"]

    P3 -->|"Evet"| C3["İçerik sunulur"]
    P3 -->|"Hayır"| R3["Erişim reddedilir"]

Bu diyagram, CDN’in bölgesel kararlar için de kullanılabileceğini gösterir. Kullanıcıya yakınlık kadar, kullanıcının bulunduğu bölgeye göre doğru içeriği sunmak da önemlidir.

CloudFront ve S3 örneği

Amazon CloudFront yaygın kullanılan CDN servislerinden biridir. Amazon S3 ise dosya depolamak için kullanılan bir object storage servisidir. Bunu şöyle hayal edebilirsin: S3 dosyaların ana deposudur, CloudFront ise bu dosyaları kullanıcılara yakın noktalardan dağıtan katmandır.

Bir web uygulaması görsellerini, videolarını veya statik dosyalarını S3’e koyabilir. CloudFront da bu dosyaları edge noktalarında cache’leyerek daha hızlı servis edebilir. Benzer CDN çözümleri Google Cloud ve Azure tarafında da bulunur.

flowchart TD
    Dev["Geliştirici veya sistem dosya yükler"] --> S3["Amazon S3"]
    S3 --> CF["Amazon CloudFront"]

    subgraph "Kullanıcıya yakın CDN noktaları"
        E1["Edge noktası 1"]
        E2["Edge noktası 2"]
        E3["Edge noktası 3"]
    end

    CF --> E1
    CF --> E2
    CF --> E3

    User["Kullanıcı"] --> E2

Bu yapı, S3 ve CloudFront’un birlikte nasıl çalışabileceğini anlatır. Dosyalar merkezi olarak S3’te durur, CloudFront ise onları kullanıcılara daha yakın noktalardan ulaştırır.

CDN kullanırken neyi CDN’e koymalısın?

Her şeyi CDN’e koymak doğru yaklaşım değildir. CDN özellikle sık erişilen ve herkese aynı ya da benzer şekilde sunulan içerikler için güçlüdür. Görseller, videolar, font dosyaları, CSS ve JavaScript paketleri bunun iyi örnekleridir.

Kişiye özel, sürekli değişen veya hassas verilerde daha dikkatli olmak gerekir. Çünkü cache yanlış ayarlanırsa bir kullanıcının görmemesi gereken veri başka bir kullanıcıya gösterilebilir. Bu yüzden CDN kullanırken cache süresi, invalidation yani cache temizleme, erişim kuralları ve bölgesel politikalar iyi tasarlanmalıdır.

Özet

CDN, web içeriğini kullanıcılara daha yakın noktalarda saklayarak hem performansı artıran hem de ana sistemin yükünü azaltan bir dağıtım katmanıdır. Temelinde caching fikri vardır: sık istenen dosyayı tekrar tekrar uzak bir sunucudan almak yerine, yakındaki bir kopyadan sunmak. Bu sayede sayfalar daha hızlı açılır, altyapı daha verimli çalışır ve bölgesel içerik kuralları daha kolay yönetilebilir. Modern web sistemlerinde CloudFront, S3, Google Cloud ve Azure gibi servislerle CDN kullanmak artık oldukça standart bir mimari tercihtir.

Bu yazı What is a CDN (Content Delivery Network)? videosundan ilham alınarak yazılmıştır.

Kaynakça

• https://www.youtube.com/watch?v=b4_6thkYZXs&list=PLMCXHnjXnTnvo6alSjVkgxV-VH6EPyvoX&index=13