Nginx HTTP Proxying, Yük Dengeleme, Arabelleğe Alma ve Önbelleğe Alma: Genel Bir Bakış

Pranay Kapgate2021-07-28 · 21 min read

Nginx HTTP Proxying, Yük Dengeleme, Arabelleğe Alma ve Önbelleğe Alma: Genel Bir Bakış

Giriş

Nginx aynı zamanda ters proxy, e-posta proxy'si, yük dengeleyici ve HTTP önbelleği olarak da kullanılan yüksek performanslı bir web sunucusudur. Nginx ücretsiz ve açık kaynaklıdır; bu da herkesin onu indirip kendi sunucu ortamında kullanmasına olanak tanır.

Nginx'i web siteleri sunmak için zaten kullanmış olabilirsiniz. Bu eğitimde, Nginx'in diğer yeteneklerini tartışacağız. HTTP proxying yeteneği, Nginx'in istekleri işlenmek üzere arka uç HTTP sunucularına iletmesini sağlar. Bu özellikle birden fazla arka uç sunucusu kurabilirsiniz. İstemci isteklerindeki artışları karşılamak için altyapınızı gerektiği gibi ölçeklendirmenize olanak tanır.

Eğitimde ilerledikçe, Nginx yük dengeleme özelliklerini, arabelleğe alma, ve önbelleğe alma yanıtlarını kullanarak altyapınızı ölçeklendirmenin yanı sıra istemciler için daha iyi bir deneyim sunmayı öğreneceksiniz. Hadi başlayalım!

Her şeyden önce, Nginx'i kullanmaya başlamak için Ubuntu sunucunuza Nginx'i nasıl kuracağınıza dair eğitimimize.

Proxying Hakkında Genel Bilgiler

Web sunucuları hakkındaki bilginiz yalnızca web sitesi isteklerini işlemek ve web sayfaları sunmaktan ibaretse, neden isteklere proxy uygulamamız gerektiğini merak ediyor olabilirsiniz. Aşağıda bunun arkasındaki nedenleri açıklayacağız.

İstekleri Nginx'ten diğer sunuculara proxy ile yönlendirmenin bir nedeni, altyapınızın ölçeklenebilirliğini desteklemektir. Nginx varsayılan olarak birçok bağlantıyı eşzamanlı olarak işler. Bu, onu istemciler için ilk temas noktası olmak için mükemmel kılar. Ardından, istemci isteklerinin gerçek işlenmesini gerçekleştirmek için istekleri çeşitli arka uç sunucularına iletebilir. Yükü dağıtan şey budur. Dolayısıyla, altyapınızı mümkün olduğunca ölçeklendirmenizi sağlar. Ayrıca, diğer sunucular istekleri sunmaya devam ederken bazı sunucuları bakım için devre dışı bırakmanıza olanak tanır.

İstekleri diğer sunuculara proxy ile yönlendirmek istemenizin ikinci nedeni, canlı üretim ortamlarında doğrudan istemcilerden gelen istekleri işlemek için uygun olmayan uygulama sunucuları kullanıyor olmanızdır. Web sunucuları da dahil olmak üzere çeşitli çerçeveler, Nginx gibi yüksek performans için uygun değildir. Nginx'in giriş noktası olmasına izin vermek ve istekleri bu düşük performanslı sunuculara proxy ile yönlendirmek, kullanıcılarınızın daha iyi bir deneyim yaşamasını sağlayabilir. Ek olarak, uygulamanız için artırılmış güvenlik garanti edebilir.

Nginx'te istekleri proxy ile yönlendirme işlemi, Nginx sunucusundan gelen bir isteğin işlenmesi ve gerçek işleme için diğer arka uç sunucularına iletilmesini içerir. Diğer arka uç sunucuları isteği işledikten sonra sonucu Nginx'e geri iletir. Nginx daha sonra sonucu istemciye bir yanıt olarak gönderir. Bu durumdaki istemci bir web tarayıcısı veya hatta bir mobil web uygulamasıdır. Diğer arka uç sunucuları, internette genel olarak erişilemeyen yerel sunucular, uzak sunucular veya hatta Nginx sunucu blokları yapılandırmalarındaki diğer sanal sunucular olabilir. Nginx'in istekleri proxy ile yönlendirdiği bu diğer sunucular upstream sunucular.

Nginx, aşağıdakiler de dahil olmak üzere çeşitli protokolleri kullanarak iletişim kuran sunuculara istekleri proxy ile yönlendirebilir: HTTP(S), Memcached, SCGI, FastCGI, ve uWSGI. Her protokol türü için yönerge setleri vardır. Bu eğitim için odak noktamız HTTP protokolüdür. Nginx, istekleri ve mesaj bileşenlerini upstream sunucusunun yorumlayabileceği ve işleyebileceği bir biçime dönüştürür.

Temel Bir HTTP Proxy Geçişini Analiz Etme

En basit proxy türü, bir isteğin HTTP üzerinden iletişim kuran tek bir sunucuya iletilmesini içerir. Bu proxy türü genellikle "proxy pass" olarak adlandırılır ve Nginx yapılandırma dosyalarındaki uygun şekilde adlandırılmış proxy_pass yönergesi tarafından işlenir.

proxy_pass yönergesi location blokları içinde görünür. Ayrıca bir location bağlamı bloklarında ve limit_except bağlamlarında da yer alır. Bir istek, içinde proxy_pass yönergesi bulunan bir konumla eşleştiğinde, istek yönergenin belirttiği URL'ye gider. Aşağıda bir yapılandırma parçacığı örneği verilmiştir:

listen 80;
location / {
proxy_pass http://127.0.0.1:3000;
}

listen 80;

location / {

proxy_pass http://127.0.0.1:3000;

}

proxy_pass_conf

Yukarıdaki örnekte, port 80'e gelen istekler localhost:3000'e gidecektir:

nginx default page

Yukarıdaki ekran görüntüsü, localhost'a ulaşmaya çalıştığınızda varsayılan Nginx sayfasını göstermektedir. Nginx sunucusunu proxy pass yönergesi yürürlükteyken yeniden başlattıktan sonra tüm istekler port 3000'e gidecektir. Aşağıdaki görselde görebileceğiniz gibi 3000 portunda çalışan bir demo uygulaması bulunmaktadır ve port belirtmeden doğrudan localhost üzerinden ulaşabilirsiniz:

localhost after applying proy pass

Bir sonraki örnekte, proxy_pass tanımındaki sunucunun sonunda hiçbir URI belirtilmemiştir. Bu kalıba uyan tanımlar için, istemcinin talep ettiği URI, yukarı akış (upstream) sunucusuna olduğu gibi aktarılacaktır.

location /match/url/here {
    proxy_pass http://example.com;
}

location /eşleşme/url/burada {

proxy_pass http://example.com;

}

Örneğin, bu blok /match/url/here için bir isteği işlediğinde, istek URI'si http://example.com/match/url/here olarak example.com sunucusuna gidecektir.

Aşağıda alternatif bir yapılandırma parçacığı örneği verilmiştir:

location /match/url/here {
proxy_pass http://example.com/new/url/prefix;
}

location /eşleşme/url/burada {

proxy_pass http://example.com/new/url/prefix;

}

Yukarıdaki kod parçacığında görebileceğiniz gibi, proxy sunucusunun sonunda new/url/prefix olarak bir URI bölümü tanımladık. proxy_pass tanımında bir URI tanımladığınızda, isteğin konum (location) tanımıyla eşleşen kısmı, işlenmek üzere yukarı akış sunucusuna giderken bu URI ile değiştirilir.

Örneğin, Nginx sunucusundaki /match/url/here isteği, yukarı akış sunucusuna http://example.com/new/url/here olarak aktarılır. /match/url kısmı /new/url ile değiştirilir. Bu noktayı aklınızda bulundurun.

Bazı durumlarda, URI'lerin yukarıdaki gibi aktarılması mümkün değildir. Bu gibi durumlarda Nginx, proxy_pass tanımının sonundaki URI'yi yoksayar. Sonuç olarak, istemciden gelen orijinal URI veya diğer yönergelerin değiştirdiği URI yukarı akış sunucusuna aktarılır.

Buna bir örnek, düzenli ifadelerin (regular expressions) konumla eşleştiği durumdur. Nginx, URI'nin hangi kısmının ifadeyle eşleştiğini belirleyemeyebilir. Bu nedenle, orijinal istemci isteği URI'sini gönderir. Bu durum, istemci URI'sinin aynı blok içinde yeniden yazılmasına ve işlenmesine neden olur. Böyle bir durumda, yeniden yazılan URI aktarılır.

Nginx Üstbilgileri (Headers) Nasıl İşler?

Üstbilgiler, bir sunucunun bir isteği nasıl işlediği konusunda çok önemlidir. Bazı üstbilgiler kimlik doğrulama bilgileri içerebilir. Bu nedenle, Nginx proxy işleminin üstbilgileri nasıl işleyeceğini anlamalıyız. Nginx'ten yukarı akış sunucusuna giden proxy isteği, doğrudan istemciden gelenden farklı görünecektir. Bu farklılıkların bazıları, proxy isteğiyle birlikte giden üstbilgilerin bir sonucudur.

Bir isteğin proxy ile iletilmesi sırasında Nginx, istemciden aldığı istek üstbilgilerinde ayarlamalar yapacaktır. Bu ayarlamalardan bazıları şunlardır:

Tüm boş üstbilgilerden kurtulmak. Boş üstbilgiler isteği yalnızca şişirir, bu nedenle bunları yukarı akış sunucusuna aktarmanın bir anlamı yoktur.
Alt çizgi içeren tüm üstbilgiler varsayılan olarak geçersiz kabul edilir, bu nedenle istekten kaldırılır. Bu davranışı değiştirmek ve Nginx'in alt çizgili üstbilgileri geçerli olarak yorumlamasına izin vermek istiyorsanız, underscores_in_headers yönergesini “on” olarak belirtebilirsiniz. Bunu yapmazsanız, istemciden gelen bu tür üstbilgiler yukarı akış sunucusuna asla ulaşmayacaktır.
“Host” üstbilgisi, $proxy_host değişkeni tarafından belirtilen değerle yeniden yazılır. Bu, proxy_pass yönergesi tarafından belirtilen yukarı akış sunucusunun IP adresi veya adı ve port numarasıdır.
“Connection” üstbilgisi değeri “close” olarak değişir. Connection üstbilgisi, iki taraf arasında kurulan belirli bir bağlantı hakkında bilgi tutar. Nginx değerini close olarak ayarladığında, yukarı akış sunucusuna orijinal istek yanıtlandıktan sonra bağlantının kapanacağını belirtir, bu nedenle bunun kalıcı bir bağlantı olmasını beklememelidir.

Yukarıda özetlenen proxy isteği üstbilgisi ayarlamalarından çıkarabileceğimiz bazı noktalar şunlardır:

Eğer bir başlığın upstream sunucusuna iletilmesini istemiyorsanız, bunu boş bir dizeye ayarlamak başlığı istekten tamamen kaldıracaktır.
Upstream sunucunuzdaki uygulama standart dışı başlıkları işleyecekse, başlıkların alt çizgi içermediğinden emin olun. İsteğe bağlı olarak, yapılandırmanızda underscores_in_headers yönergesini “on” olarak ayarlayabilirsiniz (IP adresi/port kombinasyonu için varsayılan sunucu bildirimi bağlamında veya HTTP bağlamında geçerlidir). Bunu yapmak, başlıkların geçersiz olarak işaretlenmemesini ve dolayısıyla upstream sunucusuna gerçekten iletilmesini sağlayacaktır.
“Host” başlığı, çoğu proxy durumunda oldukça önemlidir. Varsayılan olarak, proxy_pass belirtiminden alınan alan adını veya IP adresini ve portu içeren bir değişken olan $proxy_host değerine ayarlanır. Bu adres varsayılan olarak seçilir ve doğrudan bağlantı bilgilerinden çekilir. Nginx'in upstream sunucusunun yanıt vereceğini garanti ettiği tek adres budur.

Aşağıda “Host” başlığı için en yaygın değerler yer almaktadır:

$host – öncelik sırasına göre istek satırının kendisinden alınan ana bilgisayar adına, istemci isteğindeki “Host” başlığına veya istekle eşleşen sunucu adına ayarlanan bir değişkendir.
$http_host – “Host” başlığını istemci isteğindeki “Host” başlığına ayarlayan bir değişkendir. İstemcinin isteğindeki başlıklar Nginx için her zaman değişken olarak mevcuttur. Bu değişkenler bir $http_ öneki ile başlar ve ardından küçük harfle başlık adı gelir. $http_host değişkeni çoğunlukla sorunsuz çalışacak olsa da, istemci isteğinde geçerli bir “Host” başlığı bulunmadığında iletimin başarısız olmasına neden olabilir.
$proxy_host – “Host” başlığını proxy_pass belirtiminden alınan alan adı veya IP adresi ve port kombinasyonuna ayarlayan bir değişkendir. Bu, Nginx açısından varsayılan davranıştır ve bu nedenle güvenli kabul edilir. Ancak, sunucunun isteği doğru şekilde işlemesi için ihtiyaç duyduğu şey olmayabilir.

Çoğu yapılandırma, “Host” başlığının $host değişkenine ayarlanmasını içerecektir. Son derece esnektir ve upstream sunucusuna doğru şekilde doldurulmuş başlıklar sağlayacaktır.

Başlıkları Ayarlama ve Değiştirme

proxy_set_header yönergesi, proxy bağlantıları için başlıkları ayarlamamıza veya değiştirmemize olanak tanır. Daha önce tartışılan “Host” başlığında, proxy'lenmiş isteklerde yaygın olan ek başlıkları değiştirmek ve eklemek için aşağıdakileri yapabiliriz:

location /match/here {
proxy_set_header HOST $host;
proxy_set_header X-Forwarded-Proto $schema;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_pass http://example.com/new/prefix;
}

location /eşleşme/burada {

proxy_set_header HOST $host;

proxy_set_header X-Forwarded-Proto $schema;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_pass http://example.com/new/prefix;

}

Yukarıdaki yapılandırma parçacığında, “Host” başlığını, talep edilen orijinal ana bilgisayar hakkında bilgi içeren $host değişkenine ayarlıyoruz. X-Forwarded-Proto başlığını ise istemciden gelen orijinal isteğin şeması (bu bir HTTP veya HTTPS isteği olabilir) hakkındaki bilgilerle ayarlıyoruz.

İstemcinin gerçek IP adresini X-Real-IP'ye iletiyoruz. Bu, upstream sunucusunun istemcinin IP kaynağına göre uygun kararlar almasını veya günlükleri kaydetmesini sağlar. X-Forwarded-For başlığı, istemcinin bu noktaya ulaşmadan önce üzerinden proxy ile geçtiği sunuculara ait tüm IP adreslerinin bir listesini içerir. Yukarıdaki kod parçacığında bunu $proxy_add_x_forwarded_for değişkenine ayarlıyoruz. Bu değişken, istemciden alınan orijinal X-Forwarded-For başlığının değerini alacak ve sonuna Nginx proxy sunucusunun IP adresini ekleyecektir.

proxy_set_header yönergelerine birden fazla konumda (location) başvurulmasını istiyorsanız, bunları server veya http bağlamına taşıyabilirsiniz. Aşağıdaki yapılandırma parçacığını inceleyin:

proxy_set_header HOST $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

location /match/here {
proxy_pass http://example.com/new/prefix;
}

location /different/match {
proxy_pass http://example.com;
}

proxy_set_header HOST $host;

proxy_set_header X-Forwarded-Proto $scheme;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

location /match/here {

proxy_pass http://example.com/new/prefix;

}

location /different/match {

proxy_pass http://example.com;

}

Proxy Bağlantılarını Yük Dengelemek için bir Upstream Bağlamı Tanımlama

Bu noktaya kadar, tek bir arka uç (backend) upstream sunucusuna nasıl basit bir http proxy yapılacağını anladınız. Neyse ki Nginx ile, istekleri işlenmek üzere ileteceğiniz arka uç sunucu havuzları tanımlayarak bu tür bir yapılandırmayı ölçeklendirebilirsiniz.

Nginx, bir sunucu havuzu tanımlamak için kullanılan upstream adında bir yönerge (directive) sağlar. Yönergenin yapılandırması içinde, yalnızca bir istemcinin isteğini işleyebilecek kapasitedeki sunucuları belirtmelisiniz. Bir proxy sunucusu olarak Nginx, altyapının minimum çabayla ölçeklendirilmesini sağlar. upstream yönergesi, Nginx yapılandırmanızın http bağlamı (context) içinde belirtilmelidir.

İşte upstream yönergesini gösteren bir örnek:

upstream several_backend_hosts {
server host1.example.com;
server host2.example.com;
server host3.example.com;
}

server {
listen 80;
server_name example.com;

location /proxy-me {
proxy_pass http://several_backend_hosts;
}
}

upstream several_backend_hosts {

server host1.example.com;

server host2.example.com;

server host3.example.com;

}

server {

listen 80;

server_name example.com;

location /proxy-me {

proxy_pass http://several_backend_hosts;

}

Yukarıdaki yapılandırma kod parçacığında, several_backend_hosts adında bir upstream bağlamı tanımladık. Tanımlanan bağlam adı artık proxy geçişlerinde (proxy passes) kullanılabilir. Örnekte gösterildiği gibi normal bir alan adıymış gibi kullanılabilir. server bloğu içinde, example.com/proxy-me/… adresine yapılan tüm istekleri upstream yönergesini kullanarak tanımladığımız havuza, bu durumda several_backend_hosts havuzuna iletiyoruz. Gelen istekleri işlemek için havuz içinden yapılandırılabilir bir algoritma uygulanarak bir ana bilgisayar (host) seçilir. Varsayılan olarak seçim, bir round-robin (döngüsel) süreci takip eder – her istek sırayla farklı bir ana bilgisayara yönlendirilir.

Upstream Dengeleme Algoritması Nasıl Değiştirilir

Yukarıda vurgulandığı gibi, seçim süreci bir round-robin sürecini takip eder. Bu bölümde, upstream havuzu tarafından kullanılan dengeleme algoritmasını nasıl değiştirebileceğimizi göreceiz. Algoritmayı değiştirmek için, aşağıda tanımlandığı gibi upstream bağlamı içine diğer yönergeleri veya bayrakları dahil edersiniz:

(round-robin) – başka bir upstream dengeleme yönergesi belirtilmemişse, varsayılan olarak, upstream bağlamında tanımlanan her sunucuya istekler sırayla iletilir.
least_conn – bu yönerge, upstream'e en az sayıda aktif bağlantıya sahip arka uç sunucusunu seçmesini söyler. Bu, bir arka uç sunucusuna olan bağlantıların bir süre devam edebileceği durumlar için geçerlidir.
hash – bu yönerge memcached proxying için yaygındır. Bağlantılar, rastgele sağlanan bir hash anahtarının değerine göre arka uç sunucularına iletilir. Hash anahtarının değeri değişkenler, metin veya her ikisinin birleşimi olabilir. hash, hash için kullanılacak anahtar olarak işlev görmesi için kullanıcılardan girdi gerektiren tek dengeleme yöntemidir.
ip_hash – bu yönerge, upstream'e istekleri istemcinin IP adresine göre farklı sunuculara dağıtmasını söyler. IP adresinin ilk üç okteti, bir isteği hangi sunucunun işlemesi gerektiğini belirleyen anahtardır. Bu yönergenin bir avantajı, istemcilerin her seferinde aynı sunucuyu alma eğiliminde olmaları, dolayısıyla oturum tutarlılığının sağlanmasıdır.

İşte dengeleme algoritması yönergesini upstream bağlamına nasıl ekleyebileceğimize dair bir örnek:

upstream several_backend_hosts {

least_conn;

server host1.example.com;
server host2.example.com;
server host3.example.com;
}

upstream several_backend_hosts {

least_conn;

server host1.example.com;

server host2.example.com;

server host3.example.com;

}

Yukarıdaki kod parçacığında Nginx, gelen bir isteği işlemek için en az bağlantıya sahip sunuculardan herhangi birini seçecektir. ip_hash yönergesi de aynı sözdizimini takip eder. Hash yönergesi için, hash işlemi gerçekleştirmek üzere kendi seçeceğiniz bir anahtar sağlamanız gerekir, işte bir örnek:

upstream several_backend_hosts {

hash $remote_addr$remote_port consistent;

server host1.example.com;
server host2.example.com;
server host3.example.com;
}

upstream several_backend_hosts {

hash $remote_addr$remote_port consistent;

server host1.example.com;

server host2.example.com;

server host3.example.com;

}

Burada kullanılan hash, istemcinin IP adresi ve portunun bir sonucu olacaktır. İsteğe bağlı consistent parametresi, ketama tutarlı hash algoritmasını uygular. Bu, upstream sunucularınızı değiştirmeniz durumunda önbelleğiniz üzerindeki etkinin minimum düzeyde olmasını sağlar.

Dengeleme için Sunucu Ağırlığı Nasıl Belirlenir

Varsayılan olarak, arka uç (backend) sunucularını tanımladığınızda, her sunucu eşit olarak ağırlıklandırılır. Buradaki varsayım, her sunucunun aynı miktarda yükü kaldırabilecek kaynaklara ve yeteneklere sahip olduğudur; elbette bu, upstream bağlamında belirttiğiniz dengeleme algoritması göz önünde bulundurularak yapılır. Bu varsayılan davranışı değiştirmek için, tanımlama sırasında her sunucuya alternatif bir ağırlık (weight) atayabilirsiniz. Bir örneği inceleyelim:

upstream backend_hosts {
server host1.example.com weight=2;
server host2.example.com;
server host3.example.com;
}

upstream backend_hosts {

server host1.example.com weight=2;

server host2.example.com;

server host3.example.com;

}

Bu örnekte, host1.example.com diğer iki sunucunun iki katı kadar trafik alacaktır. Her sunucu için ağırlık varsayılan olarak birdir.

Arabellekler (Buffers) ile Arka Uç Sunucularını Rahatlatma

Sunucu yapılandırmanızda proxy işlemeyi yapılandırırken, sürece daha fazla sunucu eklemenin performans üzerindeki etkisinden endişe duyabilirsiniz. Neyse ki Nginx, bu performans sorunlarını hafifletmeye yardımcı olabilecek arabellek oluşturma (buffering) ve önbelleğe alma (caching) özellikleriyle birlikte gelir.

Başka bir sunucuya proxy uygulanırken iki farklı bağlantının hızı, istemcinin deneyimini kesinlikle etkileyecektir:

İlk bağlantı, istemciden Nginx proxy'sine olan bağlantıdır.
İkinci bağlantı ise Nginx proxy'sinden arka uç (backend) upstream sunucusuna olan bağlantıdır.

Nginx, gerektiğinde bağlantılardan herhangi birini optimize etmeye yardımcı olmak için davranışını ayarlayabilir.

Arabellekleri kaldırırsak, upstream arka ucundan gelen veriler Nginx proxy'sinde hemen istemciye iletilmeye başlar. İstemcilerinizin hızlı olduğunu biliyorsanız, verilerin istemciye yeterince hızlı ulaşmasını sağlamak için arabellek oluşturmayı tamamen kapatabilirsiniz. Arabellekler açık olduğunda, Nginx proxy arka uç upstream sunucusundan alınan yanıt verilerini geçici olarak depolar. Ardından, verileri hızlarına bağlı olarak istemciye gönderir. Nginx yanıtı arabelleklerine aldıktan sonra, arka uç sunucusuyla olan bağlantıyı kapatabilir. Daha sonra verileri, istemcinin desteklediği bir hızda istemciye dağıtır. Aynı zamanda, arka uç sunucusunun gelen diğer istekleri işlemeye devam etmesine olanak tanır.

Varsayılan olarak Nginx'te arabellek oluşturma açık olacaktır. Bunun nedeni istemcilerin bağlantı hızlarını bilemememizdir. İstemciler daha yavaş olabilecek farklı bağlantılara sahip olma eğilimindedir. Aşağıda, Nginx'in arabellek oluşturma davranışını ayarlamak için belirtebileceğimiz çeşitli yönergeleri tanımlayacağız. Yönergeler http, server veya location bağlamlarında tanımlanabilir, ancak boyutlandırma yönergelerinin istek başına yapılandırıldığını unutmamalısınız. Bu nedenle, bunları kesinlikle gerekli olanın ötesinde artırmak, çok fazla gelen istemci isteği olduğunda sunucunuzun performansını etkileyebilir. İşte yönergeler:

proxy_buffering – belirli bir bağlam ve alt bağlamlar için arabelleğe almanın (buffering) etkin olup olmadığını kontrol eden yönergedir. proxy_buffering için varsayılan yapılandırma “on” (açık) şeklindedir.
proxy_buffer_size – bir arka uç sunucusundan gelen yanıtta bulunan başlıkları (headers) depolamak için arabellek boyutunu belirten yönergedir. Başlıklar, arka uç sunucusundan gelen yanıtın ilk kısmını oluşturur. Bu başlıkların arabelleğe alınması, yanıtın geri kalanından ayrıdır. Varsayılan olarak, bu arabelleğin ayarlanan boyutu proxy_buffers ile aynıdır. Ancak, başlık bilgisi küçükse, boyutu daha düşük bir değere ayarlayabilirsiniz.
proxy_buffers – proxy'lenmiş yanıtlar için arabelleklerin sayısını (ilk parametre) ve boyutunu (ikinci parametre) kontrol eden yönergedir. Varsayılan yapılandırma, bir bellek sayfasına (4k veya 8k) eşit boyutta 8 arabellek belirtir. Arabellek sayısını artırarak daha fazla bilginin arabelleğe alınmasına izin verebilirsiniz.
proxy_max_temp_file_size – diskteki geçici bir dosya için istek başına maksimum boyutu belirten yönergedir. Geçici dosyalar, kaynak (upstream) yanıtı bir arabelleğe sığmayacak kadar büyük olduğunda oluşturulur.
proxy_busy_buffers_size – “istemciye hazır” (client-ready) ve dolayısıyla meşgul olarak geçebilecek arabelleklerin maksimum boyutunu belirten yönergedir. Bir istemci aynı anda yalnızca bir arabellekten veri okuyabilir. Ancak arabellekler, istemciye toplu olarak gönderilmek üzere bir kuyrukta bekler. Bu yönergeyi değiştirerek bu durumda olmasına izin verilen arabellek alanının boyutunu belirtebilirsiniz.
proxy_temp_file_write_size – arka uç kaynak sunucusundan gelen yanıt yapılandırılmış arabelleklere sığmayacak kadar büyük olduğunda, Nginx'in geçici dosyaya tek seferde yazacağı veri miktarını belirten yönergedir.
proxy_temp_path – kaynak arka uç sunucusundan gelen yanıt yapılandırılmış arabelleklere sığmayacak kadar büyük olduğunda, Nginx'in geçici dosyaları diskte depolayacağı konumun yolunu belirten yönergedir.

Nginx, arabelleğe alma davranışını ince ayar yapabilmeniz için size birkaç yönerge sunarak son derece özelleştirilebilir bir yapı sağlar. Çoğu durumda varsayılan değerler gayet iyi çalışacaktır. Aynı zamanda, özel uygulamanız için bu değerlerden bazılarını ayarlayabileceğinizi bilmek iyidir. Çoğunlukla proxy_buffers ve proxy_buffer_size yönergelerini ayarlamak isteyeceksiniz.

Aşağıda, her bir kaynak (upstream) isteği için kullanılabilir proxy arabelleklerinin sayısını artıran bir örnek verilmiştir. Bunu yaparken, başlıkları depolayan arabelleğin boyutunu azaltır:

server {
proxy_buffering on;
proxy_buffer_size 1k;
proxy_buffers 24 4k;
proxy_busy_buffers_size 8k;
proxy_max_temp_file_size 2048m;
proxy_temp_file_write_size 32k;

location / {
proxy_pass http://example.com;
}
}

server {

proxy_buffering on;

proxy_buffer_size 1k;

proxy_buffers 24 4k;

proxy_busy_buffers_size 8k;

proxy_max_temp_file_size 2048m;

proxy_temp_file_write_size 32k;

location / {

proxy_pass http://example.com;

}

Arabelleğe almayı tamamen kapatarak hızlı istemcilere nasıl daha hızlı veri sunabileceğinizi görelim. İstemciniz yeterince hızlı değilse, Nginx otomatik olarak arabellekleri kullanacaktır. Ancak, arabellek havuzlarını beklemek yerine verileri önce istemciye boşaltacaktır (flush). Bu yapılandırmanın bir dezavantajı vardır. Bu yapılandırma, istemci tüm yanıt verilerini alana kadar yavaş istemciler için kaynak sunucu bağlantısının açık kalmasına neden olur. Arabelleğe alma “off” (kapalı) olarak ayarlanırsa, yalnızca proxy_buffer_size yönergesi tarafından tanımlanan arabellek kullanılır. İşte arabelleğe almayı nasıl kapatacağınızı gösteren bir kod parçası:

server {

proxy_buffering off;
proxy_buffer_size 4k;

location / {
proxy_pass http://example.com;
}
}

server {

proxy_buffering off;

proxy_buffer_size 4k;

location / {

proxy_pass http://example.com;

}

Yüksek Derecede Erişilebilir (HA) Altyapı Yapılandırma (İsteğe bağlı kurulum)

Nginx proxy yapılandırmasına yedekli bir yük dengeleyici seti ekleyerek daha sağlam ve dolayısıyla yüksek düzeyde kullanılabilir olmasını sağlayabilirsiniz. Yüksek kullanılabilirlik (HA) kurulumu, tek bir hata noktası olmayan bir altyapıdır. Yük dengeleyiciler bu yapılandırmanın bir parçasıdır. Birden fazla yük dengeleyici ile, bir yük dengeleyici arızalandığında veya bakım için çevrimdışı olduğunda olası kesintileri önleyebilirsiniz.

Yanıt Sürelerini Kısaltmak İçin Nginx Proxy Önbelleğe Alma Nasıl Uygulanır

Önceki bölümde, arka uç sunucularını daha fazla isteği işlemek üzere serbest bırakmak için arabelleğe almanın nasıl kullanılacağını tartışmıştık. Nginx, arka uçtan gelen yanıt verilerini önbelleğe almamızı sağlayan başka bir özellikle birlikte gelir. Gelen tüm istekler için yukarı akışa (upstream) bağlanma ihtiyacını tamamen ortadan kaldırır.

Proxy Önbelleği Uygulama

proxy_cache_path yönergesi, proxy'lenmiş içeriği depolamak için kullanılacak disk üzerinde bir alan belirterek bir önbellek kurmamızı sağlar. proxy_cache_path yönergesi http bağlamında tanımlanır.

Aşağıdaki yapılandırma kodu parçacığı, bir önbelleğe alma sistemini nasıl uygulayabileceğinize dair bir örnektir:

http {
proxy_cache_path /var/lib/nginx/cache levels=1:2 keys_zone=backendcache:8m max_size=50m;
proxy_cache_key "$scheme$request_method$host$request_uri$is_args$args";
proxy_cache_valid 200 302 10m;
proxy_cache_valid 404 1m;
}

http {

proxy_cache_path /var/lib/nginx/cache levels=1:2 keys_zone=backendcache:8m max_size=50m;

proxy_cache_key "$scheme$request_method$host$request_uri$is_args$args";

proxy_cache_valid 200 302 10m;

proxy_cache_valid 404 1m;

}

Bu kod parçacığında, önbelleğimizi tutacak dosya sisteminde bir dizin tanımlamak için proxy_cache_path yönergesini kullandık. Bu durumda ayarladığımız dizin /var/lib/nginx/cache dizinidir. İstediğiniz bir dizin yolunu tanımlamakta özgürsünüz. Seçtiğiniz dizinleri doğru izinler ve sahiplikle oluşturmak için aşağıdaki komutları kullanın:

sudo mkdir -p /var/lib/nginx/cache
sudo chown www-data /var/lib/nginx/cache
sudo chmod 700 /var/lib/nginx/cache

sudo mkdir -p /var/lib/nginx/cache

sudo chown www-data /var/lib/nginx/cache

sudo chmod 700 /var/lib/nginx/cache

Kod parçacığında, levels= parametresi önbelleğin organizasyonunu belirtir. Nginx, bir anahtarın değerini (proxy_cache_key yönergesi kullanılarak belirtilen) karma hale getirerek (hashing) bir önbellek anahtarı oluşturacaktır. Belirttiğimiz seviyeler (1:2), tek karakterli bir dizin (yani karma değerin son karakteri) ve iki karakterli bir alt dizin (karma değerin sonundan sonraki iki karakterden alınan) oluşturulacağını gösterir. Çoğu durumda bu sizi ilgilendirmeyecektir. Ancak, bunun Nginx'in ilgili değerleri hızlı bir şekilde bulmasına nasıl yardımcı olduğunu bilmek iyidir.

keys_zone= parametresi bir önbellek bölgesi için ad tanımlar, bizim durumumuzda buna backendcache adını verdik. Burada ayrıca ne kadar meta veri depolamak istediğimizi de tanımlıyoruz. Bu örnekte, 8 MB anahtar depoluyoruz. Nginx, her megabayt için yaklaşık 8000 giriş depolayabilir. max_size parametresi, örneğimiz için 50MB olan gerçek önbelleğe alınmış verilerin maksimum boyutunu belirtir.

Kullanılan proxy_cache_key yönergesine de dikkat etmelisiniz. Bu yönerge, önbelleğe alınmış değerleri depolamak için kullanacağımız anahtarı belirtir. İsteğin önbellekte mevcut olup olmadığını kontrol etmek için de aynı anahtarı kullanacağız. Bu anahtarın şema (http veya https), HTTP istek yöntemi ve istenen ana bilgisayar (host) ile URI'nin birleşimi olacağını belirttik.

Ek olarak, proxy_cache_valid yönergesini kullandık. Bu yönerge, çeşitli durum kodları için birden fazla kez belirtilebilir. Durum koduna bağlı olarak değerlerin ne kadar süreyle saklanacağını belirlememize olanak tanır. Kod parçacığında, başarı kodları için 10 dakika ve 404 yanıtları için 1 dakika belirttik.

Önbellek bölgesini yapılandırdığımıza göre, bir sonraki adım Nginx'e önbelleği ne zaman kullanacağını söyleyerek yapılandırmayı yürürlüğe koymaktır. Aşağıda, bu önbelleğin kullanımını nasıl uygulayabileceğimizi gösteren bir yapılandırma parçacığı bulunmaktadır:

server {
location /proxy-me {
proxy_cache backendcache;
proxy_cache_bypass $http_cache_control;
add_header X-Proxy-Cache $upstream_cache_status;

proxy_pass http://backend;
}
}

server {

location /proxy-me {

proxy_cache backendcache;

proxy_cache_bypass $http_cache_control;

add_header X-Proxy-Cache $upstream_cache_status;

proxy_pass http://backend;

}

proxy_cache yönergesinde, bu bağlam için backendcache önbellek bölgesinin kullanılması gerektiğini belirttik. Önbellek yapılandırmasında farklı bir ad seçtiyseniz, onu değiştireceğiniz yer burasıdır. Her geçerli giriş için Nginx, isteği arka uç yukarı akış sunucusuna iletmeden önce önbelleği kontrol edecektir.

$http_cache_control değişkenini kullanmak için proxy_cache_bypass yönergesini tanımlıyoruz. Bu değişken, sunucuya önbelleğe alınmış bir yanıtla mı yoksa kaynağın yeni, önbelleğe alınmamış bir sürümüyle mi yanıt vermesi gerektiğini söyler. Bu yönergenin uygun şekilde ayarlanması, Nginx'in istemcilerden gelen çeşitli gelen istek türlerini doğru şekilde işlemesini sağlar.

X-Proxy-Cache adında ek bir başlık da belirtilmiştir. Bu başlık, $upstream_cache_status değişkeninin değerine sahiptir. Bize isteğin bir önbellek isabetiyle (cache hit) mi, önbellek kaçırmasıyla (cache miss) mı sonuçlandığı yoksa önbelleğin açıkça atlanıp atlanmadığı hakkında bilgi verir. Bu tür bilgiler istemci için yararlı olabilir ve uygulamaların hata ayıklaması sırasında kritik öneme sahiptir.

Önbelleğe Alma Sonuçları Hakkında Önemli Noktalar

Önbelleğe alma, proxy sunucunuzun performansını büyük ölçüde artıracak olsa da, önbelleğe almayı uygularken aşağıdakilere dikkat etmelisiniz:

Bir kullanıcının verilerinin başka bir kullanıcı tarafından görülmesi senaryolarını önlemek için, kullanıcının kişisel bilgileriyle ilgili hiçbir veri önbelleğe alınmamalıdır.

Arka uç sunucularınız, web sitenizin tüm dinamik öğelerini hesaba katmalıdır. Farklı amaçlara hizmet etmek için yanıtımızda belirtebileceğimiz birkaç Cache-Control başlığımız var. Bunları tartışalım:

no-cache – proxy'nin bir yanıt sunmadan önce arka uçta verilerin değişip değişmediğini kontrol etmesi gerektiğini belirtir. Bu, dinamik ve önemli veriler için geçerlidir. Her istekte bir ETag karma meta veri başlığı kontrol edilir ve arka uç aynı karma değeri döndürürse, önceki değer sunulur.
no-store – alınan hiçbir veri için önbelleğe alma yapılmayacağını belirtir, bu nedenle her istek yeni veriler için sunucuya gider. Hassas veriler için en güvenli yöntem budur.
private – hiçbir paylaşılan önbellek alanının verileri önbelleğe almaması gerektiğini belirtir. Bu başlığı, kullanıcının tarayıcısında önbelleğe almayı belirtmek için kullanabilirsiniz, ancak aynı zamanda proxy sunucusuna sonraki istekler için verileri geçersiz saymasını bildirebilirsiniz.
public – genel bir yanıt belirtir ve bağlantının herhangi bir noktasında önbelleğe almaya izin verir.

max-age başlığını kullanarak önbelleğin saniye cinsinden ne kadar sürmesini istediğinizi belirtebilirsiniz. Yukarıda tanımlanan çeşitli başlıklar, hassas verileri güvende tutarken, dinamik verileri taze tutarken ve en önemlisi sunucunuzun performansını artırırken önbelleğe almayı uygulamanıza yardımcı olabilir.

Arka uç sunucularınız Nginx sunucuları çalıştırıyorsa, sunucu blokları içinde bir önbelleğin ne kadar süreyle geçerli olması gerektiğini belirtebilirsiniz. Bunu, aşağıda gösterildiği gibi yapılandırmaya expires yönergesini ekleyerek yapabilirsiniz:

location / {
expires 59m;
}

location /check-me {
expires -1;
}

location / {

expires 59m;

}

location /check-me {

expires -1;

}

İlk blok içeriğin 59 dakika boyunca önbelleğe alınmasına izin verirken, ikinci blok önbelleğe alma olmadığını belirtir. Bu ayarlar Cache-Control başlıkları seçenekleri için geçerlidir, örneğin ikinci blok için “no-cache”.

Ek değerler ayarlamak için add-header yönergesini kullanabilirsiniz:

location /private {
expires -1;
add_header Cache-Control "no-store";
}

location /private {

expires -1;

add_header Cache-Control "no-store";

}

Sonuç

Bu eğitimde, Nginx'in güçlü özelliklerini öğrendik. Nginx hem bir web sunucusu hem de en önemlisi bir ters proxy'dir. Nginx'in tasarımı, binlerce eşzamanlı bağlantıyı işleyebilmesini sağlar. Bu, onu yük dengeleme için mükemmel kılar. Tasarımı sayesinde, istekleri işlenmek üzere diğer arka uç sunucularına yönlendirmek oldukça kolaydır.

Bu eğitimden edindiğiniz bilgilerle, Nginx'in esnekliği sayesinde karmaşık proxy'ler ve yük dengeleyiciler uygulayabilmelisiniz.

Nginx'i daha yakından tanımanızı sağlayacak ve blogumuzda bulabileceğiniz bazı kaynaklar şunlardır:

Keyifli Çalışmalar!

Pranay Kapgate

Yazar · CloudSigma

Preslav Dobrev, CloudSigma'da Kreatif Tasarımcı olarak görev yapmakta olup geleneksel ve yenilikçi pazarlama kanallarını kullanarak tutarlı bir kurumsal kimlik oluşturmaya odaklanmaktadır. Sanatsal vizyonu stratejik pazarlamayla harmanlayarak etkili marka anlatıları oluşturma konusunda oldukça yeteneklidir.

Nginx HTTP Proxying, Yük Dengeleme, Arabelleğe Alma ve Önbelleğe Alma: Genel Bir Bakış

Giriş

Proxying Hakkında Genel Bilgiler

Temel Bir HTTP Proxy Geçişini Analiz Etme

Nginx Üstbilgileri (Headers) Nasıl İşler?

Başlıkları Ayarlama ve Değiştirme

Proxy Bağlantılarını Yük Dengelemek için bir Upstream Bağlamı Tanımlama

Upstream Dengeleme Algoritması Nasıl Değiştirilir

Dengeleme için Sunucu Ağırlığı Nasıl Belirlenir

Arabellekler (Buffers) ile Arka Uç Sunucularını Rahatlatma

Yanıt Sürelerini Kısaltmak İçin Nginx Proxy Önbelleğe Alma Nasıl Uygulanır

Proxy Önbelleği Uygulama

Önbelleğe Alma Sonuçları Hakkında Önemli Noktalar

Sonuç

Pranay Kapgate

Yorumlar