Odpowiedź.

Odporną architekturę należy stosować w celu zapewnienia nieprzerwanej pracy systemów IT nawet w przypadku awarii poszczególnych komponentów. Główną zasadą jest eliminacja pojedynczego punktu awarii poprzez redundancję (redundancy), rozkład obciążenia (load balancing) i automatyczne przywracanie (failover).

Klasyczny układ systemu odpornego na awarie obejmuje klastry serwerów, replikowane bazy danych, load balancery i systemy monitorowania. W przypadku dużych systemów stosuje się geograficzną rozproszoność — umieszczanie replik w różnych centrach danych.

Przykład konfiguracji nginx z kilkoma upstream:

upstream backend {
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
    least_conn;
}
server {
    listen 80;
    server_name example.com;
    location / {
        proxy_pass http://backend;
    }
}

Kluczowe cechy:

• Użycie klastrów z automatycznym wykrywaniem awarii
• Rozkład ruchu oraz ręczne/automatyczne przenoszenie obciążenia
• Obowiązkowe monitorowanie i alertowanie dla szybkiego przywracania

Pytania z haczykiem.

Jeśli baza danych jest replikowana, czy zawsze można zagwarantować spójność danych między replikami?

Nie, spójność zależy od wybranego modelu replikacji (strong/ eventual consistency). Na przykład, w przypadku eventual consistency opóźnienia synchronizacji mogą prowadzić do pojawienia się "przestarzałych" danych na niektórych replikach.

Czy load balancer może samodzielnie naprawić problem z dostępnością backendu?

Nie, load balancer może jedynie wykluczyć niedziałający serwer z puli, ale nie może go naprawić. W celu automatycznego przywracania stosuje się dodatkowe usługi (na przykład systemy orkiestracji, takie jak Kubernetes).

Czy wystarczy po prostu skonfigurować klaster serwerów dla odporności na awarie?

Nie, ważne jest również monitorowanie odporności infrastruktury sieciowej, przechowywania i innych komponentów stosu. Błędy w planowaniu jakiejkolwiek części mogą zagrozić całemu systemowi.