İki Trafik Yönü, Tek Kutu
Hoş Geldiniz
Çoğu mimari diyagramda trafik tek yönde akar: istemci üstte, sunucu alttadır ve ok aşağıyı gösterir. Gerçekte ise trafik her iki yönde de akar.
Giriş (Ingress): Dışarıdaki istemciler hizmetlerinize bu yoldan erişir. Ağınızın kenarındaki bir ters proxy (reverse proxy) TLS oturumunu sonlandırır, istekleri yönlendirir ve erişim politikasını uygular.
Çıkış (Egress): Hizmetleriniz dışarıdaki hizmetlere bu yoldan erişir. Bir ödeme işleyicisinin API'sini çağırma, bir webhook hedefini alma veya bir ortağa istek gönderme gibi işlemler. Genellikle bir ileri proxy (forward proxy) veya izin listesi (allowlist) bulunan bir NAT geçidi üzerinden yapılır.
Birçok mimari, her iki yöndeki trafiği de tek bir kutu ile yönetmeye başlar. Bu, işe yaramaz hale gelene kadar çalışır. Hata modu ince bir yapıya sahiptir, yalnızca yeterli sayıda iç servis var olduktan sonra ortaya çıkar ve önemli bir endişelerden ayrılma (separation-of-concerns) dersi öğretir.
Bu dersin sonunda şunları anlayacaksınız:
- Neden giriş (ingress) ve çıkış (egress) trafiği, farklı ölçeklendirme eksenlerine ve farklı hata modlarına sahip temelden farklı trafik desenlerini temsil eder
- Hairpin NAT ve neden kendine bağlanmaya çalışan bir proxy başarısız olur
- Mimari çatlama: tek kutu iki kutuya dönüşür ve her birinin bundan sonra yalnızca kendisine ait olan sorumluluklar nelerdir
- Güvenlik izolasyonu kazançları: her taraf, yalnızca gerçekten izin verilen akranlarına (peers) kilitlenebilir
- Tek kutulu tasarımınızın, bölünmenin gerekli olduğu eşiği aştığını nasıl belirleyebilirsiniz
Neden Yönler Farklı Araçlar Gerektirir
Tek Bir Ağ Sınırında İki Farklı İş Yükü
Gelen (Ingress) trafik özellikleri:
- Dış taraflarca (genel internet) başlatılır
- Hacmi, kullanıcı tabanınızla birlikte ölçeklenir
- TLS sonlandırma, istek yönlendirme, kaynak başına hız sınırlama
- Derinlikli savunma endişeleri: DDoS, kötüye kullanım, kazıma (scraping)
- Halka açık IP, herkesin bağlantı kurmasını kabul etmelidir
Giden (Egress) trafik özellikleri:
- Kendi servisleriniz tarafından başlatılır (bilinen, küçük bir istemci kümesi)
- Hacim, servisler arası ve dış API çağrı kalıplarınızla ölçeklenir
- Uzak uç noktalar için kaynak IP beyaz listesi (partnerlerin güvendiği tek bir sabit giden IP'niz var)
- Derinlemesine savunma endişeleri: veri sızdırma, dışarıya çağrı yapan ele geçirilmiş dahili servisler
- Kendi servislerinizden gelen bağlantılar dışındaki herkesi reddetmelidir
Temel asimetri: Geliş (ingress) trafiği dünyadan kabul eder; gidiş (egress) trafiği yalnızca kendi servislerinizden kabul eder. Bunları aynı makineye koymak, o makinenin hem dünyadan erişilebilir olması (geliş için) hem de yalnızca kendi servislerinizden erişilebilir olması (gidiş için) gerektiği anlamına gelir. Birini sağlayan kurallar, diğerine karşı işe yarar.
Büyüme yolu: Küçük bir proje, hacim küçük olduğu ve partner IP beyaz listesi kısa olduğu için her ikisini de tek bir IP ve tek bir aracın arkasına gizleyebilir. Proje büyüdükçe, bu iki rol arasındaki sürtüşme artar ve bir gün belirli bir arıza modu (hairpin NAT) bu ayrımı zorunlu kılar.
Ayrımı Zorlayan Hata
Temizlenmiş Bir Kesinti Hikayesi
Üretim ortamlarındaki filolarda gerçekleşen gerçek bir mimari çatlağı hayal edin. Aşağıdaki isimler değiştirilmiştir; şekil, ekiplerin sahadan karşılaştığıyla birebir aynıdır.
Bir kuruluş, 203.0.113.5 adresinde tek bir proxy sunucusu çalıştırır. Bu sunucu, giriş trafiğini (kullanıcılar için 443 portu) ve çıkış trafiğini (dışarıya çağrı yapan iç servisler için 1080 portunda SOCKS5) işler. İç servisler özel alt ağlarda barınır ve tüm çıkış trafiğini 203.0.113.5:1080 adresindeki bu SOCKS5 proxy'si üzerinden yönlendirir.
Aynı 203.0.113.5 adresinin arkasında barındırılan servislerden biri api.example.com'dur. Halka açık DNS, api.example.com adresini 203.0.113.5 olarak çözer.
Şimdi farklı bir iç servisin api.example.com adresini çağırması gerekiyor. Çıkış yolu şu şekildedir:
1. İç servis api.example.com adresini 203.0.113.5 olarak çözer
2. İç servis isteği, 203.0.113.5:1080 adresindeki SOCKS5 çıkış proxy'si üzerinden gönderir
3. Proxy, kendisinden 203.0.113.5:443 adresine bir bağlantı açmaya çalışır
4. Bağlantı reddedildi. Paketin aynı NAT'tan çıkıp tekrar girmesi gerekecekti, ancak çoğu ağ yığını bunu reddeder. Vekil (proxy), kendi genel IP'si üzerinden kendisine bağlanamaz.
Bu, hairpin NAT'tır: bir NAT'tan çıkıp hedefine ulaşmak için aynı NAT'a yeniden girmesi gereken paket. Yönlendirme katmanında özel hairpin desteği olmadan paket düşer.
Neden Geç Belirir
Projenin başlarında, her iç servis ya diğer iç servislerle özel ana bilgisayar adları (internal-api.local) üzerinden konuşur ya da kendi organizasyonunun genel servislerine geri çağrı yapmazdı. Hairpin yolu basitçe mevcut değildi.
Sonra yeni bir özellik, A servisinin api.example.com (genel bir ana bilgisayar adı) adresini çağırmasını gerektirdi. Hairpin yolu aktifleşti. Bağlantı reddedildi. Kesinti.
Düzeltme, belirtiyi yamalıyordu (çözümlendiriciyi api.example.com için genel IP yerine özel IP'yi vermesi için zorlamak). Kök neden: tek bir kutu çok fazla iş yapıyordu.
Mimari Kesişim
Tek Kutu İkiye Ayrılır
Temiz çözüm: vekil sunucuyu (proxy) iki makineye ayırmak.
Giriş sunucusu (halka açık IP 203.0.113.5):
- 80 ve 443 portlarında Caddy / ters yönlendirici (reverse proxy)
- Halka açık DNS kayıtları buraya işaret eder
- api.example.com, app.example.com vb. alan adlarını barındırır
Çıkış sunucusu (farklı halka açık IP 203.0.113.99):
- 1080 portunda SOCKS5 / ileri yönlendirici (forward proxy)
- Güvenlik duvarı, gelen bağlantıları yalnızca iç alt ağ IP adreslerine kısıtlar
- İç hizmetler, tüm giden trafiği bu adres üzerinden yönlendirir
Bunun sağladıkları:
1. Hairpin sorunu çözüldü. api.example.com adresini çağıran bir iç hizmet, giden trafiği 203.0.113.99 (egress) üzerinden yönlendirir; bu adres de 203.0.113.5 (ingress, farklı bir IP) adresine normal şekilde bağlanır. İki IP farklı makinelerde barındırıldığı için NAT döngüsü ortadan kalkar.
2. Güvenlik izolasyonu. Egress sunucusunun güvenlik duvarı, küçük bir iç IP kümesine kilitlenebilir. Ingress sunucusunun güvenlik duvarı ise dünyaya açık kalır. İki ayrı kural seti, her biri bir rolü net bir şekilde ifade eder.
3. Bağımsız ölçeklendirme. Ingress bant genişliği kullanıcılarla; egress bant genişliği ise iç hizmet aktivitesiyle ölçeklenir. Birini diğerine dokunmadan yükseltin.
4. Arıza izolasyonu. Yanlış yapılandırılmış bir egress, artık genel siteyi bozmaz. Genel siteye yönelik bir DDoS saldırısı, artık egress bant genişliğini açığa çıkarmaz.
5. Daha net zihinsel model. Her makinenin tek bir işi var. Mühendisler, egress'i düşünmeden ingress endişeleri hakkında akıl yürütür ve bunun tersi de geçerlidir.
İki Eksen, İki Boyutlandırma Kararı
Bağımsız Ölçeklendirme
Ayrılımdan önce, her iki yöndeki büyüme de aynı makineyi zorluyordu. Ayrılımdan sonra, her yönün kendi tedarik etme (provisioning) altyapısı var.
Giriş (Ingress) boyutlandırması: Kullanıcı sayısı ile ölçeklenir. Kapasite kararları halka açık katmanda (daha fazla reverse proxy replikası, daha büyük VM'ler, ön tarafta CDN) yer alır. Bant genişliği bütçesi, zirve anındaki kullanıcı trafiğine göre hesaplanır.
Çıkış (Egress) boyutlandırması: Dahili servisten harici API'ye çağrı hacmi ile ölçeklenir. Genellikle webhook teslimatı, ödeme işlemcisi çağrıları veya üçüncü taraf veri çekme işlemleri tarafından baskılanır. Bant genişliği bütçesi, dahili çağrı desenlerine göre hesaplanır.
Arıza izolasyonu: Halka açık girişe (ingress) yönelik bir DDoS saldırısı artık çıkış (egress) bant genişliğini tüketmez (o ödeme işlemcisi çağrıları yine de geçer). Bir çıkış (egress) proxy çökmesi artık halka açık siteyi devre dışı bırakmaz (kullanıcılar siteye ulaşmaya devam eder; yalnızca dahili giden çağrılar başarısız olur).
Farklı SLO'lar: Giriş (ingress) kullanılabilirliği kullanıcılara önemlidir (görünür site kesintisi); çıkış (egress) kullanılabilirliği operatörlere önemlidir (tespit etmesi daha uzun sürebilen arka plan arızaları). Her taraf kendi SLO'sunu taşıyabilir.
Birden Fazla Çıkış (Egress) Sunucusu
Çıkış (egress) rolü kendi makinesi haline geldikten sonra, sonraki bariz adım, HA (Yüksek Erişilebilirlik) için bir yük dengeleyicinin arkasında birden fazla çıkış (egress) makinesi çalıştırmaktır. Her yeni dahili servis, tek bir IP adresine değil, çıkış (egress) ana bilgisayar adına (yük dengelemeli havuzun çözüldüğü adres) işaret eder.
Dağıtık sistemlerdeki diğer derslerle aynı: bir katman durumdan bağımsız (stateless) hale geldiğinde ve kendi rolüne sahip olduğunda, ucuz bir şekilde çoğaltılabilir.
Yeni Bir İş Ortağı Entegrasyonu
Örgütünüz, tasarlandığı gibi giriş/çıkış (ingress/egress) ayrımını yürütüyor. Çıkış sunucusunun sabit bir genel IP'si (203.0.113.99) var ve bu IP, üç mevcut iş ortağı API'siyle (bir ödeme işleyicisi, bir SMS geçişi, bir e-posta sağlayıcısı) izin listelenmiştir.
Bir ürün ekibi, dördüncü bir entegrasyon eklemek istiyor: dünya genelindeki müşteri uç noktalarına geri çağrı yapan bir webhook teslim sistemi. Hacim tahmini: dakikada 10.000 çağrı, 30.000'e kadar patlamalar (bursts).
Büyüyen Bir Hizmet İçin Ağ Sınırı Tasarlayın
Sentez
Giriş ve çıkış trafiğinin neden farklı araçlar gerektirdiğini, gerçek filolarda bu ayrımı zorunlu kılan hairpin NAT hatasını ve ayrım uygulandığında bağımsız ölçekleme, güvenlik izolasyonu ve hata izolasyonunun nasıl sağlandığını öğrendiniz.
Dördünü de uygulayın.
Orta ölçekli bir SaaS şirketi, kullanıcıları için üç ürün alt alan adı (app, api, admin) ve dört giden entegrasyon (Stripe, Twilio, SendGrid, bir müşteri-webhook sistemi) çalıştırıyor. Bugün her şey tek bir proxy makinesinin ve tek bir halka IP adresinin arkasında. İç servislerin api.example.com adresini çağırmaya çalıştığında aralıklı hairpin hataları raporları almaya başladılar. Kalıcı bir çözüm tasarlamak istiyorlar.
Bu Kursun Sıradaki Adımı
Bu Kursun Sıradaki Adımı
Dağıtık sistemlerde endişelerin ayrılması (separation-of-concerns) refactor'larından en temizlerinden birini gördünüz: tek bir kutu ikiye ayrıldı, her birinin net bir rolü var ve sistem bu süreçte ölçeklenebilirlik, güvenlik ve arıza izolasyonu avantajlarını da devraldı.
Bir sonraki ders (cs_distsys_failure_modes_and_blast_radius), hata izolasyonu çıkarımını genişletir. Yalıtılmış bir DNS-SERVFAIL sonradan inceleme raporunu okuyacak, kademeli hata kalıbını belirleyecek ve insanları değil sistemleri hedefleyen suçlamasız eylem maddeleri yazacaksınız.
Eşlikçi ders: geometry_of_ingress_egress_separation, bu ayrımı iki parçalı bir grafik olarak yeniden ele alır; kesme köşelerini, ağ bölünmelerini ve grafik teorisinin bir ağ sınırı hakkında size ne söylediğini keşfeder.
İyi iş. İleriye.