Neredeyse Her Web Hizmetinin Önünde Ne Var?
Hoş Geldiniz
Bir tarayıcıya example.com yazdığınızda, uygulamanın aslında çalıştığı makineye neredeyse hiç ulaşmazsınız. İsteği, uygulamanın çalıştığı makineye yönlendiren bir makineye ulaşırsınız. Bu yönlendirme makinesi bir isme sahiptir: ters vekil (reverse proxy).
Bu ders, bir ters vekilin ne yaptığını, neredeyse her herkese açık web hizmetinin neden bir ters vekilin arkasında gizlendiğini ve kenar katmanının (edge layer) aynı anda üstlendiği üç görevi öğretir.
Dersin sonunda şunları anlayacaksınız:
- İstemci, vekil ve kaynak arasındaki fark
- Neden bir kaynağın önündeki bir vekil, koruma sağlar, ölçeklenmeyi mümkün kılar ve parçaların kimse fark etmeden değiştirilmesine izin verir
- Bir ters vekilin aynı anda üstlendiği üç görev: kaynağı gizlemek, TLS'yi sonlandırmak ve yükü kopyalar arasında dağıtmak
- Bir isteğin tarayıcıdan vekile, oradan da üst akışa ve geriye, her duraklama ile nasıl yolculuk ettiğini
Dersin sonunda, vekil yerleşimi, kenar noktasındaki endişelerin ayrımı ve neden durum tutmayan bir vekil katmanının ucuz bir şekilde çoğaltılabildiği ancak tek bir kaynağın bu şekilde çoğaltılamadığı konusunda güvenle akıl yürütebileceksiniz.
İleri Vekil ve Ters Vekil
İki Vekil Yönü
Her iki tür vekil de iki taraf arasında durur ve trafiği iletir. Farkları, hangi tarafı temsil ettikleridir.
İleri yönlendirmeli vekil (Forward proxy): Bir grup istemcinin önünde durur. İstemciler vekil sunucudan haberdardır; dışarıdaki sunucu, istemci adresi yerine vekil sunucu adresini görür. Kurumsal çıkış (egress) vekilleri, içerik filtreleri ve SOCKS vekilleri bu modele uyar.
Ters yönlendirmeli vekil (Reverse proxy): Bir grup sunucunun önünde durur. Dış dünya (istemciler) vekil sunucu adresiyle iletişim kurar; istemciler, arkasında gerçek bir sunucu gizli olduğundan habersizdir. Neredeyse tüm halka açık web hizmetleri bir tane kullanır.
Akılda tutma ipucu (Mnemonic): İleri yönlendirmeli vekil, istemcileri sunuculardan gizler. Ters yönlendirmeli vekil, sunucuları istemcilerden gizler.
Yön neden önemli? Görev, hata modları ve güvenlik sınırı tamamen farklıdır. İleri yönlendirmeli vekil, kullanıcılarının kimlerle iletişim kurduğunu merak eder; ters yönlendirmeli vekil ise kimlerin sunucularıyla iletişim kurduğunu merak eder.
Her iki türden de aynı anda trafik gönderen bir istemci şu yolu izler: istemci -> ileri_vekil -> internet -> ters_vekil -> orijin.
Neden Bu Kadar Çok Şey Kenarda Yaşar
Kenar Katmanı Ücretini Hak Ediyor
Bir ters proxy aynı anda üç görevi üstlenir. Bunlardan herhangi biri tek başına katmanı haklı çıkarır; hepsini aynı anda tek bir adreste taşımak, neden neredeyse her üretim web mimarisinin ön yüzünde aynı şekle sahip olduğunu açıklar.
Görev 1: Orijini gizle. Proxy, herkese açık bir IP üzerinde yanıt verir. Arka uçlar, internetin erişemeyeceği özel IP'lerde oturur. Orijine saldırmak isteyen bir saldırgan, önce proxy'yi ele geçirmek zorundadır.
İş 2: TLS'yi sonlandır. Vekil, example.com için sertifikayı tutar ve gelen HTTPS isteklerini şifre çözer. Arka uçlar, vekille güvenilir bir ağ segmenti üzerinden düz HTTP (veya daha basit dahili TLS) konuşur. Sertifika rotasyonu, yenileme ve şifreleme politikası tek bir yerde toplanır.
İş 3: Yükü dağıt. Vekil, her isteği hangi arka ucun işleyeceğine karar verir. Tek bir vekilin arkasındaki arka uçlar bir havuz oluşturur; vekil, her istek için bir strateji (sırayla, en az bağlantılı, başlıkta hash) kullanarak bunlardan birini seçer. Kapasite eklemek, havuza bir arka uç eklemek demektir; her istemciye yeni bir adres bildirmek değildir.
Her iş küçük bir programdır. Birlikte, 'Python uygulamasının önündeki Caddy' gibi basit görünen bir katmanın, Python uygulamasının kendisinden neden daha fazla tasarım ağırlığı taşıdığını açıklarlar.
Üç İşin Tümüne Yönelik Tasarım
Ekip, tek bir VM üzerinde 8000 portunda dinleyen tek bir Python sürecinde çalışan küçük bir API çalıştırıyor. Trafik, tek bir VM'in yetişemeyeceği kadar büyüdü ve bir güvenlik incelemesi, VM'nin herkese açık bir IP'ye sahip olduğunu ve kendi TLS sertifikasını çalıştırdığını tespit etti.
Önüne bir ters vekil koymaya karar veriyorsunuz. Yerleşimi taslağını çizin: DNS nereye işaret ediyor, sertifika nerede yaşıyor, yük arka uçlara nasıl ulaşıyor ve orijinal VM'de ne değişiyor?
Kimse Fark Etmeden Bir Bileşeni Değiştirmek
Dolaylılık Özgürlük Sağlar
Eski bir bilgisayar bilimi atasözü der ki: Her sorun, bir dolaylı katman ekleyerek çözülebilir (çok fazla dolaylı katman sorunu hariç). Ters vekil (reverse proxy), dağıtık sistemlerdeki en faydalı dolaylı katmanlardan biridir.
Bunun size sağladıkları:
- Değiştirilebilir arka uçlar. Uygulamayı Python'dan Go'ya mı taşıyorsunuz? Bir veri merkezinden diğerine mi geçiyorsunuz? Sıfır kesintiyle yeni bir sürüm mü yayınlıyorsunuz? Bunların her biri, kararlı bir genel adresten (public address) gerçekleşir. Kullanıcılar için hiçbir şey değişmez.
- Bağımsız ölçekleme. Vekil katmanı, TLS katmanında bant genişliği ve CPU'ya göre ölçeklenir. Arka uç katmanı, uygulama iş yüküne göre ölçeklenir. Farklı makinelerde barındıkları için her biri kendi ekseninde büyür.
- Hata izolasyonu. Arka uçta kötü bir dağıtım, genel adresi devre dışı bırakmaz. Vekil ayakta kalır; bir düzeltme yaparsınız veya geri alırsınız; arka uç toparlandığında dünya yeniden bağlanır.
- Kesişen endişeler tek bir yerde. Hız sınırlama (rate limiting), coğrafi engelleme, istek günlüğü, başlık yeniden yazma, önbellekleme, yanıt sıkıştırma: tüm bunlar vekilde yaşar. Arka uç kodu uygulamaya odaklı kalır.
Vekil olmadan bu sorunların her biri uygulama sürecinin içinde yaşatılmalıdır. Vekil ile bunlar, tek bir ekibin sahip olduğu tek bir katmanda yaşar.
Maliyet: İşletilecek bir katman daha. Olgun ekipler, vekil katmanının kendisinin durum tutmayan (stateless) ve yatay olarak ölçeklenen bir yapıda çalışması nedeniyle bu maliyeti kabul eder; bir vekili iki vekille değiştirmek koordinasyon gerektirmez.
Aracıl Üzerinden Mavi/Yeşil Dağıtım
Ekip, API'nin 1. sürümünü, bir geri yönlendirme aracılının (reverse proxy) arkasındaki üç arka uç sanal makinesinde (mavi havuz) çalıştırıyor. Bir sorun oluşması durumunda otuz saniyeden kısa sürede geri alım yapma imkânına sahip olacak şekilde 2. sürümü dağıtmak istiyorsunuz.
Mavi havuzla yan yana olacak şekilde, 2. sürümü çalıştıran üç yeni arka uç sanal makine (yeşil havuz) başlatıyorsunuz, ancak henüz bu makinelere herhangi bir trafik yönlendirmiyorsunuz.
Tarayıcıdan Arka Uca ve Geriye
Bir İsteği Uçtan Uca Takip Edin
Arka uç havuzunun önündeki bir ters vekil (reverse proxy) üzerinden https://api.example.com/users/42 adresine yapılan tek bir HTTPS GET isteğini izleyin.
Hop 1: DNS çözümleme. Tarayıcı, api.example.com için çözümleyiciye (resolver) soru sorar. Çözümleyici, vekilin (proxy) genel IP adresini (örneğin 203.0.113.10) döndürür. Tarayıcı, 203.0.113.10:443 adresine bir TCP bağlantısı açar.
Hop 2: TLS el sıkışması. Vekil (proxy), api.example.com için sertifikasını sunar. Tarayıcı sertifikayı doğrular, iki taraf bir oturum anahtarı üzerinde anlaşmaya varır ve şifreli kanal açılır.
Hop 3: TLS içinde HTTP isteği. Tarayıcı GET /users/42 HTTP/1.1\nHost: api.example.com\n... gönderir. Vekil (proxy), istek baytlarını (bytes) şifreden çözer.
4. Adım: Arka uç seçimi. Vekil (proxy), api.example.com için üst akış havuzuna (upstream pool) danışır ve yük dengeleme stratejisini kullanarak bir arka uç (örneğin 10.0.0.21:8000) seçer.
5. Adım: Üst akış isteği. Vekil, 10.0.0.21:8000 adresine düz bir HTTP bağlantısı açar (veya yeniden kullanır) ve isteği iletir. Vekil, bu sırada başlıkları (headers) yeniden yazabilir: X-Forwarded-For: <client-ip> ekler, Host: başlığını doğru şekilde ayarlar ve Connection gibi atlayıştan atlayışa (hop-by-hop) geçen başlıkları kaldırır.
6. Adım: Arka uç işleme. Arka uç uygulaması isteği okur, veritabanına sorgu gönderir ve bir JSON yanıtı oluşturur.
7. Adım: Üst akış yanıtı. Arka uç, yanıtı vekile düz HTTP olarak geri gönderir.
8. Adım: Kenar (Edge) yanıtı. Vekil, yanıtı yeniden yazabilir veya sıkıştırabilir, bunu TLS oturumu üzerinden şifreleyerek tarayıcıya gönderir.
9. Adım: Bağlantı yaşam döngüsü. TLS oturumu genellikle bir sonraki istek için açık kalır (HTTP/2, birçok isteği tek bir bağlantı üzerinde çoklu işleme tabi tutar). Vekilden arka uca olan bağlantı genellikle yeniden kullanım için havuzlanır (pooling).
Her herkese açık web hizmeti, bu yapının bir varyantını izler. Adımları (hops) bilmek, gecikmenin (latency) nerede biriktiğini, loglamaların nereye ait olduğunu ve bir arızanın nerede gizlenebileceğini akıl yürütmenizi sağlar.
Zaman Nereye Gitti?
Bir kullanıcı API'nin yavaş hissettirdiğinden şikayet ediyor. Ölçüm yaptığınızda isteklerin uçtan uca 850 ms sürdüğünü görüyorsunuz. Arka uçtaki sunucu günlükleri, uygulamanın isteği 40 ms içinde işlediğini gösteriyor. Vekil (proxy) günlükleri ise vekilin kendi tarafındaki iş için (TLS el sıkışması + yönlendirme + yanıt yazma) 50 ms harcadığını gösteriyor.
Yeni Bir Servis İçin Minimal Bir Kenar Tasarlayın
Sentez
İleri ve geri yönlendiren vekiller (proxy) arasındaki farkı, bir geri yönlendiren vekilin aynı anda üstlendiği üç görevi, orijini gizlemenin her değişiklik gerektiğinde neden kâr sağladığını ve bir isteğin kenar üzerinden hop by hop (sıçrama sıçrama) nasıl aktığını öğrendiniz.
Şimdi bunu uygulayın.
Küçük bir ekip, notes.example.com adlı yeni bir servis başlatmayı planlıyor. Kullanıcılar kişisel notlarını okuyacak ve yazacak. Ekip, lansmanda iki arka uç sanal makinesi (VM) çalıştıracak ve önümüzdeki yıl içinde on'a ölçeklenmesini öngörüyor. Kullanıcılar için HTTPS, yeni sürümler için kademeli dağıtım ve arka uç IP adreslerinin kamuya ifşa edilmemesini istiyorlar.
Bu Ders Nereye Gidiyor
Bu Ders Nereye Gidiyor
Bu ders, kenar katmanının şeklini belirledi. Bu dersteki dört ders daha bunun üzerine inşa edilecek:
- Durumsuz Yatay Ölçeklendirme: Neden bir proxy katmanı (ve onun arkasındaki arka uçlar) ucuz bir şekilde çoğaltılabilir & ani artışlar altında kopya sayılarını boyutlandırmak için matematik.
- Giriş / Çıkış Ayrımı: Neden hem gelen hem de giden trafiği yöneten tek bir proxy kutusu sonunda şaşırtıcı şekillerde başarısız olur & katmanları nasıl ayırılır.
- Hata Modları ve Etki Alanı: Tek bir yapılandırma değişikliğinin nasıl bir kesintiye yol açtığı ve tekrarlanmasını önleyen suçsuzluk temelli eylem maddelerinin nasıl yazılacağı.
- Gözlemlenebilirlik ve Kapasite: Kullanıcılar fark etmeden bir şeylerin bozulduğunu anlaman için kenar noktasında (edge) neyin ölçülmesi gerektiği.
Her ders kendi başına geçerlidir. Bir arada ele alındıklarında, web ölçeğinde bir filonun işleyişine dair işe yarayan bir zihinsel model sunarlar.
Eşlikçi ders: geometry_of_proxies_and_origins, bu dersteki her şeyi yönlendirilmiş bir graf olarak yeniden ele alır ve graf teorisinin bir istek yoluna dair ne söylediğini keşfeder.
İyi iş. İlerleyelim.