Docker + Nginx Sunucusu İle Load Balancing Operasyonu

Merhaba,

Önceki Load Balancing(Yük Dengeleme) ve Load Balancer(Yük Dengeleyici) Nedir? ve Docker + Ocelot Kütüphanesi İle Load Balancing Operasyonu başlıklı yazılarımızda load balancing ve load balancer üzerine hasbelkader irdelemelerde bulunmuştuk. Bu içeriğimizde ise load balancing operasyonu için oldukça elverişli olan, kurulumu basit lakin işlevsel açıdan oldukça etkili Nginx teknolojisi üzerinden incelemede bulunuyor olacağız. İlk olarak Nginx’in ne olduğundan bahsedecek, ardından Nginx sunucunun Windows ve Docker ortamlarında nasıl ayağa kaldırıldığına değinecek ve nihai olarak load balancing operasyonunu tüm detaylarıyla pratikte ele alıyor olacağız. O halde buyrun başlayalım…

Nginx Nedir?

2002 yılında Igor Sysoev tarafından geliştirilmiş olan Nginx; kitlesel uygulamalar için yüksek eş zamanlı çalışma kabiliyeti, yüksek performans ve düşük hafıza kullanımına odaklanılarak tasarlanmış bir web sunucusudur. Load balancing’in dışında HTTP cache, Microservice ve güvenlik konularına da çözümler getirmektedir.

Nginx, genellikle yazılımlardaki yükleri dağıtabilmek için load balancing operasyonlarında tercih edilmektedir lakin tek yaptığı hizmet bu değildir…

Nginx Kurulumu

Nginx; Unix, Linux, Mac OS X, Solaris, Windows vs. gibi işletim sistemlerinde kurularak çalıştırılabildiği gibi Docker gibi sanallaştırma ortamlarında da ayağa kaldırılarak rahatlıkla kullanılabilir. İşletim sistemlerinde kurulmuş yahut sanallaştırma ortamlarında ayağa kaldırılmış Nginx sunucusunda load balancing operasyonunu icra edebilmek için ilgili sunucu içerisindeki nginx.conf isimli dosya üzerinde gerekli ayarlamaların yapılması gerekmektedir. Bu dosyanın nerede olduğu, hangi ayarların ne şekilde yapılacağı vs. tüm teferruatıyla bu içeriğimizin sonraki satırlarında inceleneceğinden dolayı şimdilik oralara temas etmemeksizin öncelikle konumuz olan kuruluma odaklanarak devam edelim.

Windows Kurulumu ve Windows Platformunda Load Balancing

Nginx’i Windows platformuna fiziksel olarak kurmak ve çalıştırmak istiyorsanız eğer nginx.org/en/download.html adresinden indirebilir ve direkt olarak çalıştırabilirsiniz. İlgili adrese girildiğinde
yandaki görseldeki gibi Mainline version altındaki ilgili linke tıklayarak Nginx’in en sonuncu kararlı sürümüne dair .exe uzantılı dosyasını edinebilirsiniz. Bu dosya sayesinde kurulum yapmaya gerek duymaksızın direkt sunucuyu çalıştırabilirsiniz.
(Not : Bu içeriğin klavyeye alındığı tarihten sonraki sürümler doğal olarak değişiklik gösterebilir.)

Linke tıklayıp, ilgili sunucu dosyalarını indirdiğinizi varsayarsak eğer ilgili .zip dosyasını açtığınızda içerisindeki klasörlerin ve dosyaların aşağıdaki gibi olduğunu göreceksiniz;
Burada dikkat ederseniz gelen 6 klasörden ‘conf’u ve ‘nginx.exe’ dosyasını vurgulamış bulunmaktayız.

‘conf’ klasörü; içerisinde Nginx sunucusuna dair gerekli konfigürasyonları barındıran bir klasördür. Bu konfigürasyonlarda sonraki satırlarda göreceğimiz load balancing operasyonlarını yapılandırmaktayız. Misal olarak bu yapılandırmalar; Nginx sunucusunun hangi portta ayağa kalkacağı, Nginx’e gelen isteklerin hangi sunuculara yönlendirileceği vs. olacaktır.

‘nginx.exe’ dosyası; Nginx sunucusunu kuruluma gerek duymamaksızın ayağa kaldırmamızı sağlayan .exe dosyasıdır.

Windows Ortamında nginx.conf Dosyasının Yapılandırılması
Windows ortamında Nginx’i çalıştırabilmek ve sunucularımıza load balancing operasyonunu gerçekleştirebilmek için ilk olarak ‘conf’ klasörü içerisindeki ‘nginx.conf’ dosyasını açıp, yapılandırmamız gerekmektedir. İlgili dosyayı açtığınızda aşağıdaki gibi bir kod yığınıyla karşılaşacaksınız.

Evet, biliyorum… Kod çok küçük ve okunamamaktadır 🙂
Zaten okunabilir olmasına da gerek yoktur. Haa isterseniz kodu kopyalayıp bir not defterinde istediğiniz büyüklükte görebilirsiniz. Lakin söylediğim gibi buna gerek yoktur. Çünkü buradaki niyetim, mevcudiyetteki kodun ne kadar kompleks ve karmaşık olsa dahi nasıl bir şey olduğunu sizlere göstermektir. Yapılması gereken bu dosyanın içerisinde aşağıdaki gibi bir konfigürasyondur. (Dikkat ederseniz aşağıdaki kod orjinaline nazaran sadeleştirilmiştir. Kopyalayıp direkt ilgili dosya içerisine yapıştırarak kullanabilirsiniz.)

worker_processes 1;

events {
    worker_connections 1024;
}

http {
    include mime.types;
    default_type application/octet-stream;
    sendfile on;
    keepalive_timeout 65;

    upstream servers {
        server 127.0.0.1:1071;
        server 127.0.0.1:1072;
    }

    server {
        listen 8080;
        server_name localhost;

        location / {
            proxy_pass http://servers;
        }

        error_page 500 502 503 504 /50x.html;
        location = /50x.html {
            root html;
        }
    }
}

Yukarıdaki kodu izah etmemiz gerekirse eğer; 13 ile 16. satırlar arasında ‘servers’(başka isimde verilebilir) adında bir upstream tanımlanmıştır. Bu upstream, load balancing işleminin yapılacağı sunucuları tutmaktadır. Örnekte de görüldüğü üzere yönlendirmenin yapılacağı sunucu bilgileri server komutu eşliğinde bildirilmiştir ve her bir bildiriden sonra ; operatörü kullanılmaktadır. Burada elimizdeki sunucu sayısı kadar adres bildirimi yapabilmekteyiz.

Yönlendirmeleri karşılayacak olan sunucuları tanımladıktan sonra 22. satırdaki location / içerisine proxy_pass http://servers;(servers tanımlanan upstream’den gelmektedir) komutuyla localhost:8080 portuna gelecek olan tüm http isteklerini(/) karşılamakta ve ilgili sunuculara kullanılan algoritma eşliğinde yönlendirme yapılmaktadır. Tabi hangi load balancing algoritmasının kullanıldığına sonraki satırlarda değiniyor olacağız.

Nginx sunucusunun 80 portunda ayağa kalkacağını ise 19. satırdaki listen 8080; komutu belirlemektedir.

Değinilen bu konfigürasyonların dışında diğerleri pek mühim arz etmemektedir. Kısaca özet geçmek gerekirse bir Nginx konfigürasyonu için temelde upstream ile birlikte location yapılandırması yeterli olacaktır.

Tüm bu işlemleri yaptıktan sonra ‘nginx.conf’ dosyasını kaydedip, ‘nginx.exe’ dosyası üzerinden Nginx sunucusunu çalıştırabilirsiniz. İlgili dosyaya tıkladıktan sonra sunucunun ayağa kalkıp kalkmadığını anlayabilmek için ‘Task Manager’ üzerinden yandaki gibi kontrol edebilirsiniz.

Artık localhost:8080 url’ine gelen tüm istekler ‘servers’ isimli upstream’de belirtilen sunuculara yönlendirilecek ve böylece yük dengeleme sağlanmış olacaktır.

İşte… Windows platformunda Nginx bu şekilde ayağa kaldırılmakta ve gösterildiği gibi yapılandırmaları oluşturulmaktadır. Şimdi sıra Docker ortamında Nginx kurulumunu ve yapılandırmasını incelemeye gelmiştir.

Nginx’i Dockerize Etmek ve Docker İle Load Balancing

Nginx’i dockerize ederken Windows’ta ki kurulumuna istinaden ‘nginx.conf’ dosyasına image oluştururken müdahale etmemiz gerekmektedir. Bunun için yine yukarıda oluşturduğumuz gibi aşağıdaki içerikte bir ‘nginx.conf’ dosyası oluşturunuz.

worker_processes 1;
 
events {
    worker_connections 1024;
}
 
http {
    include mime.types;
    default_type application/octet-stream;
    sendfile on;
    keepalive_timeout 65;
 
    upstream servers {
        server 192.168.0.12:1071;
        server 192.168.0.12:1072;
    }
 
    server {
        listen 80;
        server_name localhost;
 
        location / {
            proxy_pass http://servers;
        }
 
        error_page 500 502 503 504 /50x.html;
        location = /50x.html {
            root html;
        }
    }
}

Burada dikkat ederseniz eğer upstream içerisindeki server bilgilerini 127.0.0.1 olarak değil, remote ip olarak vermiş bulunmaktayız. Bunun nedeni localhost’a karşılık gelecek olan 127.0.0.1 adresini Docker container’ın kendi içerisinde aramasıdır. Halbuki bizler örneklendirme için ana bilgisayarımızın local adresini bildirmek istiyoruz. Böyle bir durumda 127.0.0.1’i verememekteyiz. Aksi taktirde 502 Bad Gateway hatasıyla karşılacağız. Haliyle bu duruma ana makinanın remote ip’sini ya da varsa DNS adını kullanarak çözüm getirmekteyiz. Tabi ki de gerçek operasyonlarda uzak bir sunucunun adresi bildirileceğinden dolayı buradaki detay pek önem arz etmeyecektir. Ama dediğim gibi local üzerinde örnek mahiyetinde çalışıyorsanız eğer Docker içerisinde remote ip ile ana bilgisayarı ifade etmek elzemdir.

127.0.0.1	Remote Ip
Daha detaylı bilgi için https://stackoverflow.com/questions/38346847/nginx-docker-container-502-bad-gateway-response/47663730#47663730 adresindeki yorumu okumanızı tavsiye ederim.

Remote IP adresini nereden bulacağız? diye sorarsanız eğer Network kısmından aşağıdaki görselde olduğu gibi ‘Properties’ -> ‘IPv4 address’ kısmından erişebilirsiniz.

Velhasıl, devam edersek eğer bu ‘nginx.conf’ dosyasının bulunduğu dizine bir Dockerfile dosyası oluşturunuz ve içerisine aşağıdaki talimatları giriniz.

FROM nginx:latest
COPY nginx.conf /etc/nginx/nginx.conf
EXPOSE 80

Dikkat ederseniz Docker’da ayağa kaldırılacak olan ‘nginx’ image’ının içerisindeki /etc/nginx/nginx.conf klasörü, yukarıda geliştirdiğimiz mevcut nginx.conf klasörü ile değiştirmekteyiz. Haliyle böylece artık bizim verdiğimiz yapılandırmalara göre ilgili sunucu çalışacak ve yük dengeleme sağlanmış olacaktır. Bu işlemin ardından ilgili dizine powershell yahut cmd ile girerek aşağıdaki docker cli komutlarını çalıştırınız.

Ve tüm bu işlemlerden sonra artık localhost/example adresine sırasıyla istek gönderiniz ve yük dengelemenin gerçekleştirildiğini gözleyiniz.

Nginx – Load Balancing Detayları

Şimdiye kadar Windows ve Docker ortamlarında Nginx’in kurulumunu ve load balancing operasyonlarının nasıl yapıldığını tam teferruatlı ele almış bulunmaktayız. Bundan sonra ise artık algoritma seçimi, sunucu ağırlığı ayarlama, sunucu yavaş başlatma yapılanması, session kalıcılığı, healt check vs. gibi teferruatların nasıl yapıldığını ele alıyor olacağız.

Load Balancing Algoritma Seçimi

Önceki yazılarımızdan Load Balancing(Yük Dengeleme) ve Load Balancer(Yük Dengeleyici) Nedir? başlıklı içeriğimizde load balancing’in çalışmasına dair temel algoritmalardan bahsetmiştik. Nginx, bu algoritmalar eşliğinde şahsına münhasır özelleştirmelerde bulunduğu farklı algoritmalarla gelmektedir. Şimdi gelin bu algoritmaların nasıl kullanıldığını tekrar hatırlayarak ve öğrenerek inceleyelim…

• Round Robin : Sunucu ağırlıkları dikkate alarak gelen isteği sunucular arasında eşit olarak dağıtır. Varsayılan olarak kullanılan yöntemdir.

  upstream servers {
     server backend1.example.com;
     server backend2.example.com;
  }
  

• Least Connections : Gelen isteği az sayıda etkin bağlantıya sahip sunucuya gönderir. least_conn etiketiyle ifade edilir.

  upstream servers {
      least_conn;
      server backend1.example.com;
      server backend2.example.com;
  }
  

• IP Hash : Aynı adresten gelen istekleri aynı sunucuya yönlendirir. ip_hash etiketiyle ifade edilir.

  upstream servers {
      ip_hash;
      server backend1.example.com;
      server backend2.example.com;
  }
  

  
  Eğer ki sunuculardan herhangi birinin yük dengeleme rotasyonunun geçici olarak kaldırılması gerekiyorsa down komutu kullanılabilir.

  upstream servers {
      server backend1.example.com;
      server backend2.example.com;
      server backend3.example.com down;
  }
  

  Bu sunucuya gönderilecek istekler otomatik olarak gruptaki bir sonraki sunucuya yönlendirilir.

• Generic Hash : İsteğin gönderileceği sunucu herhangi bir metin dizesi, değişken yahut kombinasyonel bir değerle belirlenmektedir. hash $request_uri consistent etiketiyle ifade edilir.

  upstream servers {
      hash $request_uri consistent;
      server backend1.example.com;
      server backend2.example.com;
  }
  

• Least Time : Gelen isteği en düşük ortalama gecikme değerine sahip olan sunucuya yönlendirir. least_time etiketiyle birlikte header, last_byte ve last_byte inflight olmak üzere üç parametreyle ifade edilir.

  header, sunucudan ilk bayrı alma zamanını ifade eder.

  upstream servers {
      least_time header;
      server backend1.example.com;
      server backend2.example.com;
  }
  

  last_byte, sunucudan tam yanıt alma zamanını ifade eder.

  upstream servers {
      least_time last_byte;
      server backend1.example.com;
      server backend2.example.com;
  }
  

  last_byte inflight, eksik istekleri dikkate alarak sunucudan tam yanıt alma zamanını ifade eder.

  upstream servers {
      least_time last_byte inflight;
      server backend1.example.com;
      server backend2.example.com;
  }
  

• Random : Gelen istek rastgele bir sunucuya yönlendirilir. random etiketiyle ifade edilir.

  least_conn, en az aktif bağlantı sayısını ifade eder.
  least_time=header, sunucudan yanıt başlığını almak için en düşük ortalama süreyi ifade eder.
  least_time=last_byte, sunucudan tam yanıt almak için en düşük ortalama süreyi ifade eder.

  Eğer ki two parametresi belirtilirse, öncelikle rastgele iki sunucu dikkate alınır ve ardından yukarıdaki yöntemlerden hangisi kullanılıyorsa ona göre birisini seçer ve isteği yönlendirir.

  upstream servers {
      random two least_time=last_byte;
      server backend1.example.com;
      server backend2.example.com;
      server backend3.example.com;
      server backend4.example.com;
  }
  

  Rastgele dağılım herhangi bir hesap gerektirmemesinden ötürü bir miktar hızlı çalışmaktadır.

Sunucu Ağırlıkları/Server Weights

Nginx, Round Robin yöntemi eşliğinde gelen istekleri sunucular arasındaki ağırlıklarına göre dağıtabilmektedir. weight parametresi sunucu ağırlıklarını belirlemede kullanılmaktadır.

upstream servers {
    server backend1.example.com weight=5;
    server backend2.example.com;
    server 192.0.0.1 backup;
}

Yukarıdaki yapılanmada backend1.example.com 5, diğer iki sunucu varsayılan(1) ağırlığa sahiptir. Bu demek oluyor ki, gelen 6 isteğin 5’i backend1.example.com‘a, 1’i ise backend2.example.com‘a gidecektir. Dikkat ederseniz 192.0.0.1 sunucusu ise backup ile işaretlenmiştir. Böylece diğer iki sunucu kullanılmadığı sürece istek alamayacak hale getirilmiştir.

Sunucu Yavaş Başlatma/Server Slow-Start

Sunucu yavaş başlatma özelliği, yakın zamanda onarılan bir sunucunun zaman aşımına uğramaksızın çalışmasını sağlayacak olan bir özelliktir. slow_start etiketi ile aşağıdaki gibi ayarlanabilmektedir.

upstream servers {
    server backend1.example.com slow_start=30s;
    server backend2.example.com;
    server 192.0.0.1 backup;
}

Oturum Kalıcılığını Etkinleştirme/Enabling Session Persistence

Nginx, gelen istekleri kullanıcı oturumlarını tanımladığı aynı sunuculara yönlendirerek session kalıcılığını sağlayabilmektedir. sticky etiketi eşliğinde sticky cookie, sticky route ve sticky learn olmak üzere üç farklı kalıcılık yöntemini destekler.

sticky cookie, gelen ilk isteğe bir oturum tanımlama bilgisi ekler ve böylece sunucuyu tanımlar. İstemci, yapacağı bir sonraki istekte tanımlama bilgisi içerir ve isteği eşleşen sunucuya yönlendirir.

upstream servers {
    server backend1.example.com;
    server backend2.example.com;
    sticky cookie srv_id expires=1h domain=.example.com path=/;
}

Yukarıdaki örneği incelerseniz eğer; srv_id parametresi, tanımlama bilgisinin adını belirlemektedir. expires parametresi, tarayıcının cookie’yi tutma süresini belirlemektedir. domain parametresi, tanımlama bilgisinin ayarlandığı etki alanını tanımlamaktadır. Opsiyoneldir. path parametresi ise tanımlama bilgisinin yolunu tutar. Bu en basit session kalıcılık yöntemidir.

sticky route, gelen ilk istek alındığında client’a bir rota verilir. Sonraki tüm istekler, route parametresiyle karşılaştırılarak eşleşen sunucuya yönlendirilir.

upstream servers {
    server backend1.example.com route=a;
    server backend2.example.com route=b;
    sticky route $route_cookie $route_uri;
}

sticky learn, gelen istek neticesinde yanıtları inceleyerek hangi sunucuya yönlendirileceğini öğrenen yöntemdir.

upstream servers {
   server backend1.example.com;
   server backend2.example.com;
   sticky learn
       create=$upstream_cookie_examplecookie
       lookup=$cookie_examplecookie
       zone=client_sessions:1m
       timeout=1h;
}

Bağlantı Sayısını Sınırlama

Gelen isteklerin yönlendirileceği sunucuların bağlantı sayılarını sınırlayabilmekteyiz. Bu işlem için max_conns etiketi kullanılmaktadır.

upstream servers {
    server backend1.example.com max_conns=3;
    server backend2.example.com;
    queue 100 timeout=70;
}

max_conns değeri dolduğu taktirde queue değeri kadar sıraya alınır. queue, isteklerle dolduğu taktirde veya istek neticesinde sunucu seçimi timeout değeri kadar zaman aşımına uğrarsa client’a bir hata gönderilir.

Healt Check

Nginx, yük dengelemenin yapılacağı sunucuları sürekli olarak test edebilir ve gelen isteği başarısız yahut sıkıntılı sunuculara yönlendirmeden boşa gitmeyecek şekilde işleyebilmektedir.

upstream servers {
    server backend1.example.com;
    server backend2.example.com max_fails=3 fail_timeout=30s;
}

Yukarıdaki örneği incelerseniz eğer; fail_timeout parametresi ile sunucunun kullanılamaz olarak işaretlenmesi için ne kadar sürelik başarısız girişimin gerçekleşmesi gerektiğini ve aynı zamanda sunucunun uygun değil olarak işaretlendiği süreyi ayarlamaktayız. Bu süre varsayılan olarak 10 saniyedir. Örnekte 30 saniye olarak yapılandırılmıştır. max_fails parametresi ise sunucunun kullanılamıyor olarak işaretlenmesi için gereken süre boyunca(fail_timeout) gerçekleşmesi gereken başarısız denemelerin sayısını ayarlamamızı sağlar. Yani yukarıdaki örneğin mealini yaparsak eğer; 30 saniye içerisinde 3 kez yanıt alınamazsa sunucu 30 saniye boyunca kullanılamaz olarak işaretlenir.

Eğer ki bir grupta tek bir sunucu varsa fail_timeout ve max_fails parametreleri yok sayılarak, o sunucunun hiçbir zaman kullanılamaz olarak işaretlenemeyeceği unutulmamalıdır.

Bu incelediğimiz sağlık kontrolüne Pasif Sağlık Kontrolü denmektedir. Yani gelen isteğin yönlendirilmesi neticesinde sunucudan alınan tepkiye göre bu kontroller yapılmış olacaktır. Birde ayriyeten Aktif Sağlık Kontrolü mevcuttur. Nginx, her sunucuya özel bir denetim isteği göndererek, önceden bir denetleme yapar ve sunucuların durumunu düzenli olarak kontrol eder. Yani bir isteğe bağlı olmaksızın aktiflik söz konusudur. Bunun için health_check etiketinin aşağıdaki gibi kullanılması yeterlidir :

server {
    location / {
        proxy_pass http://servers;
        health_check;
    }
}

Nginx, bu yapılandırma sayesinde varsayılan olarak her 5 saniyede bir gruptaki her bir sunucuya istek gönderir. İlgili sunucular sağlık kontrolünden geçip, 200 status code dönene kadar client’tan gelen istekleri karşılayamazlar.

Healt Check’e dair daha detaylı bilgi için şuradaki makaleyi okumanızı tavsiye ederim.

İstek Yapan Client’ın IP Değerine Erişmek

Load balancing süreçlerinde türlü ihtiyaçlar doğrultusunda sunucular üzerinde istek yapan client’ların IP değerlerine erişmemiz gerekebilmektedir. Halbuki load balancer’ların istek yapan client’ın IP adresi yerine kendi IP adreslerini ilgili sunuculara iletmek gibi kötü bir alışkanlıkları vardır. Uygulama sunucularının client’ların IP değerlerini öğrenmesi gerektiğinde HTTP Header’da X-Forwarded-For key’inin doldurulması gerekmektedir. Bunun için ise load balancer’lar üzerinde ilgili key’e karşılık aşağıdaki ayarın yapılması gerekmektedir.

        location / {
            proxy_pass https://servers;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }

Yukarıdaki örnekte görüldüğü üzere proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; komutu ile istek yapan client’ın bilgisinin X-Forwarded-For key’ine karşılık HTTP Header’da taşınması gerektiği bildirilmektedir. Bu yapılandırmanın akabinde yapılan istek neticesinde ilgili client’ın IP’sine aşağıdaki ekran görüntüsünde olduğu gibi HTTP Header üzerinden rahatlıkla erişebilmekteyiz.

Nihai olarak, uzun ve meşakkatli bir içerikle Nginx sunucusu üzerinden load balancing operasyonunun nasıl yapılabileceğini hemen hemen tüm detaylarıyla ele almış bulunmaktayız. Tabi ki de konuya dair bizlerin temas etmediği amma velakin ihtiyaç doğrultusunda ilgili sunucunun orjinal dökümanlarına göz atmamız gerekecek olan detaylarda mevcuttur. Ben deniz load balancing üzerine gelen yoğun talep üzerine faydalı ve yerinde bir içerik oluşturduğumu umuyorum. Umarım önümüzdeki süreçte bu konuda bir eğitim videosu çekip Youtube kanalımda da yayınlamayı hedefliyorum. Velhasıl, sıkılsanız dahi üşenmeden bu satırlara kadar okuyup eşlik ettiğiniz için teşekkür ederim 🙂

İlgilenenlerin faydalanması dileğiyle…
Sonraki yazılarımda görüşmek üzere…
İyi çalışmalar…