un — Giriş ve Çıkış Ayrılması

un

konuk

1 / ?

derslere geri dön

İki Trafiği Yön, Bir Kutu

Hoşgeldin

Çoğu mimari diyagram, trafiğin sadece bir yönde gittiğini gösterer: üstte client, altta server, ok aşağıya doğru yön gösterir. Gerçeklik, trafiğin her iki yönde gittiğini gösterir.

Giriş: Dışarıdan client'lar hizmetlerinize bu yoldan ulaşır. Networkinizin kenarında hizmetinizin istemcilerinize TLS sona erdiren, istekleri yönlendiren ve erişim politikasını uygulayan bir geri proxy bulunur.

Çıkış: Hizmetleriniz dışarıdaki hizmetlere bu yoldan ulaşır. Ödeme işlemcisine API çağrısı yapmak, webhook hedefine ulaşmak, bir ortak'a istekte bulunmak. Sıklıkla, bir forward proxy veya NAT gateway ile izin listesi üzerinden geçer.

Çok sayıda mimari, her ikisini de ele alan tek bir kutu ile başlar. Bir süreliğine çalışır, ancak başarısız olma günü gelir ve sadece yeterli iç hizmet mevcut olduğunda ortaya çıkar. Bu, ayrılmış konulara ilişkin önemli bir dersi öğretir.

Bu dersin sonunda anlamanız gerekenler:

- Neden giriş ve çıkış, farklı ölçeklendirme eksenleri ve farklı başarım modları temsil eder

- Hairpin NAT ve bir proxy'nin kendini bağlamanın neden başarısız olduğu

- Mimari ayrım: bir kutu iki kutuya dönüşür ve her birinin tek başına sahip olduğu şeyler

- Güvenlik izolasyonu kazanımları: her taraf, gerçek izin verdiği ortaklara kapanır

- Tek kutu tasariminizde, bölünmenin gerekli olduğu noktayı nasıl belirleyeceğiniz

Neden Yönler Farklı Araçlara İhtiyaç Duyar

İki Farklı Yük, Birden Network Sınırında

Giriş trafiği özelliklerine göre:

- Dışarıdan partiler tarafından başlatılır (genel internet)

- Cinsiyeti kullanıcı tabanınızla orantılı olarak büyür

- TLS sona erdirmenin, istek yönlendirmenin, kaynak başına sınırlama uygulanması

- Derin koruma endişeleri: DDoS, kötüye kullanım, tarayıcı

- Public IP'nin herkes tarafından kabul etmesi gerekir

Çıkış trafiği özelliklerine göre:

- Hizmetlerin kendi başlarına (bilinen ve küçük bir set) başlatır

- Cinsiyeti hizmetler-arası ve dış-API çağrılarına göre büyür

- Kaynak-IP allowlisting uzak uç noktalar (sizin bir sabit dışa dönük IP'si var, ortaklar bunu güveniyor)

- Derin savunma endişeleri: veri kaçaklaması, iç hizmetlerin dışa çağrıda olduğu zaman komplozed hizmetler

- Başka hizmetlerinizi kabul etmeyi reddetmelidir

Ana asimetri: giriş trafiği dünyadan kabul eder; çıkış trafiği sadece kendi hizmetlerinizi kabul eder. Bir makineyi aynı anda dünyadan (giriş için) ve kendi hizmetlerinizden (çıkış için) erişilebilir olması gerektiği anlamına gelir. Bir makinayı hem giriş hem de çıkış kuralları karşılar, ancak diğerini engellemeye çalışır.

Kalkınma yolları: küçük bir proje hem bir IP hem de bir araç arkada bir arada saklayabilir, çünkü hacim küçük ve ortak-IP-allowlist kısa. Projenin büyümesi, iki rol arasındaki sürtünmenin artması ve sonunda bir özel hata modu (hairpin NAT) bölünmeye zorlar.

Giriş ve çıkış: farklı kaynaklar, farklı hedefler, farklı gereklilikler

Bir küçük startup, her şeyi (giriş geri proxy, çıkış forward proxy / NAT, iç hizmetler) tek bir VM üzerinde ve tek bir public IP ile çalıştırır. Bu hala yeterli olduğu izlenimi verir. Büyüdükçe bu tasarım üzerinde hangi iki özel başarım modunu veya operasyonel sıkıntılarını yaşayacaklarını ve her birini, altta yatan nedeni açıklayarak belirtin.

Hata Nedeniyle Oluşan Bölünme

Temizlenmiş Bir Durdurma Öyküsü

Bir gerçek mimari bölünme senaryosunu düşünün. Üretimde filolarda yaşanan şekli tam olarak koruyan gerçek adlar aşağıda değiştirilmiştir.

Bir organizasyon, 203.0.113.5 adresinde tek bir proxy sunucusu çalıştırır. Giriş (kullanıcılar için 443 numaralı kapı) ve çıkış (iç hizmetlerin dışa çağırması için 1080 numaralı SOCKS5 için) içerebilir. İç hizmetler özel alt ağlarda çalıştırılır ve tüm dışa dönük trafiği bu SOCKS5 proxy'sına 203.0.113.5:1080 adresine yönlendirir.

203.0.113.5 adresinde aynı proxy sunucusunun arkasında bulunan hizmetlerden biri api.example.comdur. Public DNS, api.example.com'u 203.0.113.5 adresine yönlendirir.

Şimdi farklı bir iç hizmetin api.example.com'u çağırması gerekiyor. Dışa dönük yol:

1. İç hizmet api.example.com'u 203.0.113.5 adresine yönlendirir

2. İç hizmet, SOCKS5 dışa dönük proxy'ya 203.0.113.5:1080 adresine gönderir

3. Proxy, kendisini 203.0.113.5:443 adresine bağlamaya çalışır

4. Bağlantı reddedildi. Paket aynı NAT'ten çıkıp tekrar girmesi gerekiyor, ancak çoğu ağ kütüphanesi bunu reddeder. Proxy, kendi public IP'si üzerinden kendisini bağlayamaz.

Bu saç teli NAT: bir paket, NAT'tan çıkarak aynı NAT'a ulaşmak için tekrar girmesi gereken bir pakettir. Yönlendirme katmanında özel saç teli desteği olmadan, paket kaybolur.

Neden Erken Görünür

Projenin erken aşamasında, her iç hizmet ya da diğer iç hizmetlere özel hostname ('internal-api.local') üzerinden iletişim kuruyordu ya da kendi organizasyonunun public hizmetlerine geri dönmemeye karar verdi. Saç teli yol, o dönemde mevcut değildi.

Sonra yeni bir özellik gerektiğinde hizmet A, api.example.com'a (public hostname) çağrıya ihtiyaç duydu. Saç teli yol etkin hale geldi. Bağlantı reddedildi. Servis durdu.

Onarıcı patch, semptomu düzeltti (force resolver'ı public IP yerine özel IP vermesini sağladı). Kök neden: tek bir kutu çok fazla işi yapıyordu.

Saç teli NAT: paket çıkarak aynı NAT'a tekrar giremez

Mimari Bölünme

Bir Kutu İkiye Dönüşüyor

Temiz bir çözüm: proxy'yi iki makineye ayırarak.

Giriş sunucusu (public IP 203.0.113.5):

- Caddy / geri dönüştürücü, 80 ve 443 numaralı porta

- Public DNS kayıtları buraya yönlendirilir

- api.example.com, app.example.com gibi api.example.com'u barındırır

Çıkış sunucusu (farklı public IP 203.0.113.99):

- SOCKS5 / ileri proxy, 1080 numaralı porta

- Gelen bağlantılara sadece iç alt ağı IP'lerine kısıtlama

- İç hizmetler tüm çıkışları bu adres üzerinden yönlendirir

Bu ne sağlar:

1. Saç telini çözmüş oldu. İç hizmetin api.example.com çağrısı, 203.0.113.99 (çıkış) üzerinden normal bir şekilde 203.0.113.5 (giriş) adresine bağlanır. NAT döngüsü ortadan kalkıyor çünkü iki IP farklı makinelerde bulunuyor.

2. Güvenlik izolasyonu. Çıkış sunucusunun firewall'ı, küçük bir dizi iç IP'ye kısıtlama yapabilir. Giriş sunucusunun firewall'ı dünya üzerinde açık kalır. İki farklı kural seti, her biri temiz bir şekilde bir görevi ifade eder.

3. Bağlantısız ölçeklendirme. Giriş bant genişliği kullanıcılarla orantılı olarak büyür; çıkış bant genişliği iç hizmet aktivitesine göre büyür. Birini diğerinden bağımsız bir şekilde güncelleyin.

4. Hata izolasyonu. Yanlış yapılandırılmış çıkış, public siteyi bozmadığı gibi, public siteye karşı bir DDoS, çıkış bant genişliğini tüketmez.

5. Açık bir mental model. Her makine bir görevi yerine getirir. Mühendisler, egress concerning hakkında düşünürken egress hakkında düşünmezler ve vice versa.

Bölünme sonrası, bir iç hizmet hala `api.example.com`'a çağrıya ihtiyaç duyar. İç hizmet api arka uçuna giden yeni paket yolunu adım adım geçirin. İçerik: iç hizmetin ilk olarak hangi IP'ye bağlanacağını, o makinenin isteği neyle işleyeceğini, hangi IP'ye sonraki bağlantıyı kuracağını ve yanıtın nereye gittiğini belirtin.

İki Eksen, İki Büyüme Kararı

Bağımsız Büyüme

Bölünmeden önce, her iki yönde de büyüme aynı makineyi zorluyordu. Bölünmenin ardından, her yönde kendi tahsisatı vardı.

Giriş boyutlandırma: kullanıcılarla orantılı olarak büyür. Kapasite kararları genel olarak yüzey katmanında (daha fazla ters proxy klonu, daha büyük VM'ler, ön yüzeye CDN) bulunur. Bandwidth bütçesi, kullanıcı trafiği olan zirve karşılaştırılır.

Çıkış boyutlandırma: iç hizmet-extern API çağrı hacmine göre büyür. Sıklıkla, webhook teslimatı, ödeme işlemcisi çağrıları veya üçüncü taraf veri çekmeleri tarafından kontrol edilir. Bandwidth bütçesi, iç çağrı modellerine göre hesaplanır.

Bağımsızlık: bir DDoS saldırısı, genel giriş üzerinde gerçekleşirse, egress bandwidth artık etkilenmez (o ödeme işlemcisi çağrıları geçer). Bir egress proxy çökmesi, genel siteyi düşürmez (kullanıcılar siteye ulaşmaya devam eder; sadece iç dışa yönlendirme çağrıları başarısız olur).

Farklı SLO'lar: giriş kullanılabilirliği kullanıcılar için önemli (görünür site kesintisi); çıkış kullanılabilirliği operatörler için önemli (aranızda daha uzun süre tespit edilebilir arka plan başarısızlıkları). Her taraf kendi SLO'sunu taşıyabilir.

Çıkış Sunucuları

Egress rolünün kendi makinesi olduğu anda, yük dengeli bir yükleyici arkasında birkaç egress makinesi çalıştırmanın sonraki açık hareketi olur. Her yeni iç hizmet, egress hostname'a (yük dengeli havuzun çözünmesine) değil, tek bir IP'ye noktalanır.

Distributed sistemler dersi gibi: bir katman stateless hale getirildi ve kendi rolüne sahip olduğunda, ucuzca katlanır.

Yeni Bir Ortak Entegrasyonu

Sizin organizasyonunuz, egress split'ını tasarlandığı şekilde uygulamaktadır. Egress sunucusu, üç mevcut partner API (bir ödeme işlemcisi, bir SMS gateway, bir e-posta sağlayıcısı) ile izin listelenmiş olan statik bir genel IP (203.0.113.99) sahiptir.

Bir ürün ekibi, dördüncü entegrasyonu eklemek istiyor: dünya çapında müşteri uç noktalarına geri çağrılan bir webhook teslim sistemi. Hacim öngörü: dakikada 10.000 çağrı, 30.000'e kadar patlamalar.

Karar verin: Bu yeni entegrasyon, mevcut egress sunucusunda mı yer almalıdır veya ayrı bir çıkış yoluna mı ihtiyaç duymalıdır? Bandwidth, bağımsız olma ve mevcut ortak allowlistlerin her iki durumda da güncellenmesi gerekip gerekmediği konusunda düşünün.

Bir Hizmetin Büyümesi İçin Bir Ağ Sınırı Tasarla

Sentetik

Sizin öğrendiğiniz şey, ingress ve egress'in farklı araçlar gerektirdiği, gerçek flotlar için gerçek bir hataya neden olan hairpin NAT başarısızlığı ve gerçek flotlara yerleştirildikten sonra bağımsız ölçeklendirme, güvenlik izolasyonu ve başarım izolamasının biriktirilmesi.

Dört tümünü uygulayın.

Orta boyutta bir SaaS şirketi, kullanıcıları için üç ürün alt alanını (app, api, admin) çalıştırır ve ayrıca dört dış entegrasyon (Stripe, Twilio, SendGrid, müşteri-webhook sistemi) bulunur. Şu anda her şey bir tek proxy makinesi üzerinde bir IP adresinde yaşamaktadır. İç hizmetlerin api.example.com'ye çağrı yapmayı denediğinde iç hizmetler için hairpin hatası bildirimleri almaya başladılar. Kalıcı bir çözüm tasarlamak istiyorlar.

Bu şirket için bir ingress / egress mimarisi önerin. Adres: ne kadar makine kullanılması gerekiyor, hangileri hangi rolleri üstleniyor, her alt alanın DNS'ninin nereye işaret ettiği, hangi dış entegrasyonların bir egress yolunu paylaşmalı ve hangi onesi ayrılmış olmalı, ve yeni tasarım eski olanından sağlayamayan bir somut izleme konusunun.

Bu Kursun Sonrasında Nereye Gidiyor

Şu anda dağıtılmış sistemler içinde en temiz ayrışım-refaktörlerden birini gördünüz: bir kutu ikiye dönüştü, her biri açık bir rolle ve sistem, ölçeklendirme, güvenlik ve başarım izolasyonu avantajları elde etti.

Sonraki ders (cs_distsys_failure_modes_and_blast_radius) başarım izolasyonu mantığını genişletir. Sanal DNS-SERVFAIL post mortem okuyup, kaskad başarısızlık kalıplamasını tanımlayın ve insanların hedefi değil, sistemleri hedef alan suçsuz blameless eylemler yazın.

Eğitim arkadaşı: geometry_of_ingress_egress_separation bölümü, bölümü iki kenarlı bir graf olarak yeniden sunar ve kesik kenarlar, ağ bölümleri ve graf teorisi ile bir ağ sınırı hakkında ne söylediğini inceleyin.

Mükemmel iş çıkardın. İleriye doğru.