İkiz Trafiğin Birden Bir Şekilde İşlendiği
Hoşgeldin
Çoğu mimari diyagramlar, trafiğin sadece bir yönde gittiğini gösteriyor: üstte bir müşteri, alttaki sunucu, trafiğin aşağıya doğru gittiği bir ok.
Giriş: Dışarıdan müşterileriniz hizmetlerinize bu yoldan ulaşıyor. Ağın kenarında duran bir ters proxy, TLS sona erdirir, istekleri yönlendirir ve erişim politikasını uygular.
Çıkış: Hizmetleriniz dışarıdaki hizmetlere bu yoldan ulaşıyor. Bir ödeme işleticisinin API'sine çağrıda bulunmak, bir webhook hedefine erişmek, bir ortakla ileti göndermek. Sıklıkla, bir forward proxy veya NAT gateway ile bir allowlist üzerinden geçer.
Çoğu mimari, hem giriş hem de çıkış trafiğini işleyebilen tek bir kutu ile başlıyor. Bu işe yarar, yeterli iç hizmet mevcut olana kadar ve önemli bir ayrılmazlık öğreten başarısız modunu öğrenene kadar.
Bu dersi bitene kadar anlamanız gerekenler:
- Neden giriş ve çıkış, farklı trafik modelleri temsil eder ve farklı ölçeklendirme eksenleri ve farklı başarısızlik modları ile farklıdır
- Saçıverme NAT ve bir proxy'nun kendine bağlanmaya çalıştığı neden
- Mimari çatallaşma: Bir kutu diğerine ayrılır ve her birinin ardından özel olarak sahip olduğu
- Güvenlik izolasyonu kazanılanlar: Her taraf, gerçek izinli arkadaşlara kapanır
- Tek kutu tasariminiz, bölünmenin gerekli olduğu eşiği aştığında nasıl tanımlayacağınız
Neden Yönlere Farklı Araçlar Gerekir
Bir Ağ Sınırında İki Farklı Yük
Giriş trafiği özellikleri:
- Dış taraftan başlatılır (genel internet)
- Hafifletme, kullanıcı tabanınızla orantılıdır
- TLS sona erdirme, istek yönlendirmesi, kaynak başına sınırlama
- Derin koruma endişeleri: DDoS, kötüye kullanım, tarayıcı
- Public IP'nin, herkesin bağlantılardan kabul etmesi gerekiyor
Çıkış trafiği özellikleri:
- Hizmetlerin kendi hizmetleri tarafından başlatılır (bilinen ve küçük bir set)
- Hafifletme, hizmetler arası ve dış-API çağrı örüntüleriyle orantılıdır
- Uygulama-IP allowlisting uzak uç noktalar (sizin bir sabit çıkış IP'si vardır ve ortaklar buna güveniyor)
- Derin koruma endişesi: veri kaçaklaması, iç hizmetlerin dışa çağırma ile zarar görmesi
- Birdel reject bağlantılarını kabul etmeli
Ana asimetri: giriş (ingress) dünya trafiklerini kabul eder; çıkış (egress) sadece kendi hizmetlerinizi kabul eder. Bu iki rolü aynı makinede bulunduğunda, bu makine aynı anda dünya (giriş için) ve hizmetlerinizi (çıkış için) sadece ulaşılabilir olmalıdır. Birbiriyle çelişkili olan firewall kuralları, birini karşılar.
Gelişme yolları: Bir proje hem bir IP ve hem de bir araç arkasında saklanabilir, çünkü hacim küçük ve ortak IP allowlist kısa olacaktır. Projenin büyümesi, iki rol arasındaki gerginliği artırır ve bir gün özel bir hata modu (hairpin NAT) projeyi bölmeye zorlar.
The Bug That Forces the Split
Temiz bir Outage Hikayesi
Bir gerçek yapısal ayırımı düşünün. Üretimde sürükleyici filolar. Aşağıda isimler değiştirilmiştir; ancak takımın gerçek dünyada karşılaştığı şekli aynıdır.
Bir organizasyon, 203.0.113.5 adresinde tek bir proxy sunucusu çalıştırır. Bu proxy, giriş (kullanıcılar için port 443) ve çıkış (iç hizmetlerin dışa çağırma için port 1080 SOCKS5) için sorumludur. İç hizmetler, bu SOCKS5 proxy'da 203.0.113.5:1080 üzerinde tüm dışa yönlü trafiği yönlendirmek için özel alt ağlarda barınırlar.
203.0.113.5 adresinde barınan bir hizmet olan api.example.com hizmetleri vardır. api.example.com DNS, 203.0.113.5'e yönlendirir.
Şimdi farklı bir iç hizmetin api.example.com'u çağırması gerekiyor.
1. İç hizmet api.example.com'ü çözümler → 203.0.113.5
2. İç hizmet, egress proxy'da SOCKS5 egress proxy'da 203.0.113.5:1080'a gönderir
3. Proxy, kendi kendine 203.0.113.5:443'e bağlantısı kurmaya çalışır
4. Bağlantı reddedildi. Paket, aynı NAT içinde yeniden girmek zorunda kalacaktı ve çoğu ağ tabanlısı bunu reddeder. Proxy, kendi itself üzerinden kendine üzerinden public IP üzerinden bağlanamaz.
Bu saç tel NAT: bir paket, NAT'ten çıkarak aynı NAT'a geri girmesi gereken bir paket. Routing katmanında özel saç tel desteği olmadan, paket kaybolur.
Neden Geç Kalmış Oluyor
Projenin yaşamının erken dönemlerinde, her iç hizmeti ya diğer iç hizmetlere özel bir sunucu adı (internal-api.local) tarafından (internal-api.local) ya da kendi organizasyonunun public hizmetlerine geri dönmeden çağrı yapmıyordu. Saç tel yolu o dönemde mevcut değildi.
Öte yandan, yeni bir özellik sayesinde hizmet A, api.example.com'ı (public bir sunucu adı) çağırması gerekiyordu. Saç tel yolu etkinleşti. Bağlantı reddedildi. Servis durdu.
Sarma yarasını düzeltici bir düzeltiyle (force the resolver to give api.example.com'un özel IP'sini yerine public) çözüldü. Kök neden: tek bir kutu çok fazla işi yapıyordu.
Mimari Çatal
Bir Kutudan İkiye
Temiz düzelti: proxy'yi iki makinaya ayırın.
Giriş sunucusu (public IP 203.0.113.5):
- Caddy / ters proxy portlarda 80, 443
- Public DNS kayıtları burada yönlendirilir
- api.example.com, app.example.com vb. barındırır
Çıkış sunucusu (farklı public IP 203.0.113.99):
- SOCKS5 / forward proxy port 1080
- Gelen bağlantılar sadece iç alt ağ IP'lerine kısıtlıdır
- İç hizmetler bu adres üzerinden tüm çıkışlarını yönlendirir
Bu ne satın alır:
1. Saç tel çözülmüştür. İç bir hizmet api.example.com'u çağırarak, 203.0.113.99 (çıkış, egress) üzerinden normal olarak 203.0.113.5 (giriş, farklı bir IP) bağlanır. NAT döngüsü ortadan kalkıyor çünkü iki IP farklı makinelerde yaşamaktadır.
2. Güvenlik izolasyonu. Egress sunucusunun firewall'ı küçük bir iç IP kümesine kapanır. Giriş sunucusunun firewall'ı dünya üzerinde açık kalır. İki farklı kural seti, her birini temiz bir şekilde ifade eder.
3. Bağlantılı ölçeklendirme. Giriş bant genişliği kullanıcılarla orantılı olarak büyür; egress bant genişliği iç hizmet aktivitesiyle büyür. Birini diğerini dokunmadan güncelleyin.
4. Bağlantısız izolasyon. Yanlış yapılandırılmış egress, public site'i bozulma. Public site'e karşı bir DDoS, egress bant genişliği tükenmesi.
5. Açık bir mental model. Her makine bir görevi yerine getiriyor. Mühendisler, girişe (ingress) ve çıkışa (egress) yönelik endişeleri ayrı ayrı düşünmeden akıllarında düşünürler.
İki Eksen, İki Büyütme Kararı
Bağımsız Ölçeklendirme
Bölünmeden önce, hem yönde büyüme aynı makineyi etkilemiyordu. Bölünmenin ardından her yönde kendi sağlama işlemini gerçekleştirebilirdi.
Giriş Ölçeklendirme: kullanıcılarla orantılı olarak büyür. Kapasite kararları genel olarak yüz yüze olan katman (daha fazla ters proxy kopyası, daha büyük VM'ler, ön yüzü olan CDN) üzerinde yer alırdı. Kullanıcı trafiği zirve sırasında karşılaştırılabilir band genişliği bütçesi hesaplanır.
Çıkış Ölçeklendirme: iç hizmet-external API çağrı hacmine orantılı olarak büyür. Sıklıkla webhook teslimatı, ödeme işleticileri çağrıları veya üçüncü taraf veri çekme işlemleri tarafından etkilenir. İç çağrı örüntüleri karşılaştırılabilir band genişliği bütçesi hesaplanır.
Bağımsız Hata Adımları: public girişe (ingress) karşı bir DDoS saldırısı artık çıkış (egress) bant genişliğini tüketmez (o ödeme işleticileri çağrıları ve üçüncü taraf veri çekme işlemleri geçer). Bir egress proxy çökmesi artık yüz yüze olan siteyi düşürmez (kullanıcılar siteye ulaşabilir; sadece iç dışa yönelik çağrılar başarısız olur).
Farklı SLO'lar: giriş (ingress) kullanılabilirliği kullanıcılar için önemli (görünür site kesintisi) ; çıkış (egress) kullanılabilirliği operatörler için önemli (arka uç hatalar daha uzun süre tespit edilirse). Her taraf kendi SLO'sunu taşıyabilir.
Çoklu Egress Sunucuları
Egress rolünün kendi makinesi olduktan sonra, bir sonraki açık hareket, HA (yük paylaşımı) için birkaç egress makinesi çalıştırmaktır. Her yeni iç hizmet, egress sunucuya (ki bu, yük dengelişen havuzlara karşılık gelir) yerine bir tek IP'ye işaret eder.
Dağıtılmış sistemlerin geri kalan dersi gibi: bir katman stateless hale getirildi ve kendi rolü olduysa, ucuzca çoğalabilir.
Yeni Bir Ortak Entegrasyonu
Örgütünüz giriş/gçiş (ingress/egress) bölünmesini tasarımı gereği çalıştırıyor. Egress sunucusu, izin verilen üç mevcut ortak API (bir ödeme işleticisi, bir SMS gateway ve bir e-posta sağlayıcısı) ile izin verilmiş public IP (203.0.113.99) sahiptir.
Ürünti eklemek isteyen bir ürün ekibi: Dünya çapında müşteri uç noktalarına geri çağrı yapan bir webhook teslim sistemi. Hacim öngörü: Dakika başına 10.000 çağrı, 30.000'e kadar patlamalar.
Bir Hizmet için Ağ Sınırları Tasarla
Senden
Sızış ve çıkışın farklı araçlar gerektiğini öğendin, gerçek flotlar için gerçek bir ayrım gerektiğine karar verdi ve ağın bölünmesinin ardından bağımsız ölçeklendirme, güvenlik izolasyonu ve başarısızlık izolaması sağladı.
Tüm dörtünü uygula.
Orta ölçekli bir SaaS şirketi, kullanıcıları için üç ürün alt alanını (app, api, admin) çalıştırmaktadır. Ayrıca, dört dış entegrasyon (Stripe, Twilio, SendGrid, müşteri-webhook sistemi) vardır. Bugüne kadar, her şey tek bir proxy makinesi arkasında yaşamaktadır ve tek bir IP üzerinde. İç hizmetler api.example.com den internal çağrılar yapmaya çalıştığında, iç hizmetlerin hairpin hatası yaşadığını ve sürekli olarak hairpin hatalarının düzeltilmesi gerektiğini öğrenmektedirler.
Bu Kursun Sonrasında Nereye Gideceği
Bu Kursun Sonrasında Nereye Gideceği
Distributed Systems'de en temiz ayrım-refaktörünü gördün: bir kutu ikiye ayrılır, her biri açık bir rol üstlenir ve sistem, ölçeklendirme, güvenlik ve başarısızlık izolasyonu avantajları kazanır.
Sonraki ders (cs_distsys_failure_modes_and_blast_radius) başarısızlık izolasyonu mantığını uzatıyor. DNS-SERVFAIL postmortemini okuyacak, kademeli başarısızlık kalıbını tanımlayarak ve sistemlere değil insanlara yönelik olmayan kolluksuz eylem maddeleri yazarak.
Komşu ders: geometry_of_ingress_egress_separation bölümüni ikili bir graf olarak yeniden sunar ve kesik kenarlıklar, ağ bölümleri ve bir ağ sınırine neyi anlatan graf teorisi incelemeleriyle keşfedin.
Müthiş iş çıkardın. İleri.