# Obliczenia w chmurze wyjaśnione: 11 koncepcji architektury, które musisz znać (Masterclass 4K).

Published: 2026-09-15

Większość inżynierów oprogramowania próbuje nauczyć się architektury chmury, zapamiętując setki akronimów produktów dostawców z AWS, GCP i Azure. Ale inżynieria chmury w świecie rzeczywistym opiera się na jedenastu fundamentalnych prymitywach architektonicznych. W tej odświeżonej wersji masterclass w 4K Niko przedstawia kompletny plan przedsiębiorstwa: od skalowania pionowego i poziomego oraz równoważenia obciążenia warstwy 7 po dynamiczne automatyczne skalowanie, wykonywanie mikro-VM bezserwerowych, asynchroniczne odsprzęganie sterowane zdarzeniami, orkiestrację kontenerów, czterofilarową hierarchię pamięci masowej, krytyczną różnicę między wysoką dostępnością a 11 dziewiątkami trwałości, deklaratywną infrastrukturę jako kod oraz sieci Virtual Private Cloud. Opanuj te jedenaście koncepcji, a będziesz mógł zaprojektować dowolny backend w środowisku produkcyjnym. Werdykt: SHIP IT.

Canonical: https://thedailydiff.dev/pl/video/2026-09-14-cloud-computing-explained-4k/

## Co obejmuje ten film

- - Ściana Architektury i Główny Plan
- - 01. Skalowanie pionowe vs. poziome
- - 02. Architektura równoważenia obciążenia (L4 vs. L7 i sprawdzenia zdrowia)
- - 03. Automatyczne skalowanie i elastyczność
- - 04. Bezserwerowe (FaaS i Firecracker MicroVMs)

## Rozdziały

- 0:00 - Ściana Architektury i Główny Plan
- 0:57 - 01. Skalowanie pionowe vs. poziome
- 2:17 - 02. Architektura równoważenia obciążenia (L4 vs. L7 i sprawdzenia zdrowia)
- 3:45 - 03. Automatyczne skalowanie i elastyczność
- 4:50 - 04. Bezserwerowe (FaaS i Firecracker MicroVMs)
- 6:05 - 05. Architektura sterowana zdarzeniami (EDA i odsprzęganie)
- 7:13 - 06. Orkiestracja kontenerów (Docker i Kubernetes)
- 8:16 - 07. 4 Filary przechowywania w chmurze (S3, EBS, bazy danych i Redis)
- 9:44 - 08. Wysoka dostępność i dziewiątki (przełączanie awaryjne w wielu AZ)
- 10:53 - 09. Trwałość vs. Dostępność (Dlaczego 11 dziewiątek to nie uptime)
- 12:14 - 10. Infrastruktura jako kod (Terraform vs. Console Drift)
- 13:20 - 11. Sieci w chmurze (VPC, podsieci, NAT i grupy bezpieczeństwa)
- 14:26 - 12. Kompletny plan przedsiębiorstwa i werdykt

## Przetłumaczona transkrypcja

Przetłumaczono z oryginalnej narracji angielskiej. Dostępne audio i napisy są kontrolowane przez YouTube.

### - Ściana Architektury i Główny Plan

0:00 Każdy inżynier oprogramowania w końcu napotyka ścianę architektury chmury. Budujesz aplikację na swoim laptopie, wypuszczasz ją na produkcję, i w momencie, gdy pojawiają się prawdziwi użytkownicy, serwery się zawieszają, połączenia z bazą danych się wyczerpują, a Twój rachunek AWS wygląda jak numer telefonu. Większość programistów próbuje rozwiązać inżynierię chmury, zapamiętując trzysta różnych akronimów produktów AWS. Ale prawdziwe obliczenia w chmurze nie polegają na zapamiętywaniu katalogów dostawców: są zbudowane na jedenastu fundamentalnych prymitywach architektonicznych.

0:34 W tej masterclass przejdziemy przez cały plan przedsiębiorstwa: od skalowania i równoważenia obciążenia po rozwiązania bezserwerowe, odsprzęganie sterowane zdarzeniami, hierarchie pamięci masowej i sieci w chmurze. Opanuj te jedenaście koncepcji, a będziesz mógł zaprojektować dowolny backend na AWS, GCP lub Azure. To jest The Daily Diff, od podszewki.

### - 01. Skalowanie pionowe vs. poziome

0:57 Koncepcja numer jeden: Skalowanie. Gdy Twoja aplikacja doświadcza wzrostu ruchu, masz dwa fundamentalnie różne sposoby obsługi obciążenia: skalowanie pionowe lub skalowanie poziome. Skalowanie pionowe, czyli skalowanie w górę, oznacza wzięcie Twojej istniejącej maszyny i dodanie większej liczby zasobów: uaktualnienie z czterech rdzeni procesora do trzydziestu dwóch, lub zamianę trzydziestu dwóch gigabajtów RAM na sto dwadzieścia osiem. Skalowanie pionowe nie wymaga żadnych zmian architektonicznych: Twój kod

1:28 i baza danych pozostają dokładnie takie same. Ale osiąga brutalny sufit sprzętowy. Żadna pojedyncza maszyna na świecie nie ma dziesięciu tysięcy rdzeni procesora, a instancje najwyższego poziomu wiążą się z wykładniczą premią cenową. Skalowanie poziome, czyli skalowanie na zewnątrz, oznacza utrzymywanie serwerów małych i w cenie towarowej, ale uruchamianie wielu instancji równolegle za routerem. Jeśli jedna instancja się zawiesi, pozostałe węzły absorbują ruch z zerowym przestojem. Złotą zasadą skalowania poziomego jest

2:01 bezstanowość: serwery aplikacji nie mogą przechowywać sesji użytkowników, przesłanych plików ani stanu na swoich lokalnych dyskach. Stan musi znajdować się w zewnętrznej bazie danych lub pamięci podręcznej, umożliwiając każdemu węzłowi obsługę dowolnego żądania użytkownika.

### - 02. Architektura równoważenia obciążenia (L4 vs. L7 i sprawdzenia zdrowia)

2:17 Koncepcja numer dwa: Równoważenie obciążenia. Skalowanie poziome brzmi świetnie na papierze, ale wprowadza natychmiastowy problem: gdy dziesięć tysięcy użytkowników wchodzi na Twoją nazwę domeny, który konkretny serwer otrzymuje ich ruch? Balancer obciążenia działa jako odwrotny proxy, znajdujący się między publicznym internetem a Twoim prywatnym klastrem backendowym. Przyjmuje przychodzące połączenia TCP lub HTTP i rozdziela żądania między zdrowe instancje.

2:47 Balancery obciążenia działają na dwóch podstawowych warstwach sieciowych. Layer 4 Network Load Balancers działają na warstwie transportowej, kierując surowe pakiety TCP i UDP na podstawie adresu IP i portu z opóźnieniem mikrosekundowym i milionami żądań na sekundę. Layer 7 Application Load Balancers sprawdzają sam protokół HTTP: odczytują ścieżki URL, nagłówki żądań, ciasteczka i metody HTTP. Umożliwia to routing oparty na ścieżkach: wysyłanie żądań /api do klastra backendu i żądań /static do

3:25 magazynu obiektów. Co najważniejsze, balancery obciążenia wykonują aktywne sprawdzenia zdrowia. Co kilka sekund balancer pinga punkt końcowy zdrowia na każdej instancji. Jeśli instancja rzuci trzy kolejne błędy pięćsetne lub nie odpowie, zostanie automatycznie usunięta z puli z zerową liczbą odrzuconych żądań.

### - 03. Automatyczne skalowanie i elastyczność

3:45 Koncepcja numer trzy: Autoskalowanie. Jeśli Twoja aplikacja internetowa potrzebuje dwóch serwerów o trzeciej nad ranem, ale dwudziestu serwerów podczas południowego uruchomienia, ręczne klikanie przycisków w konsoli chmurowej jest gwarantowaną drogą do przestojów i bankructwa. Autoskalowanie zapewnia dynamiczną elastyczność horyzontalnym pulom serwerów. Grupa Auto Scaling monitoruje metryki wydajności, takie jak średnie wykorzystanie procesora, I/O sieciowe lub głębokość zaległości w kolejce. Gdy średnie wykorzystanie procesora przekroczy zdefiniowany próg — powiedzmy,

4:19 siedemdziesiąt procent przez trzy kolejne minuty — autoskaler automatycznie uruchamia nowe maszyny wirtualne, rejestruje je w Twoim balancerze obciążenia, i zaczyna kierować ruch. Równie ważne jest skalowanie w dół: gdy fala ruchu opada, autoskaler kończy nadmiarowe instancje, dzięki czemu przestajesz płacić za bezczynne zasoby obliczeniowe. Aby zapobiec niestabilności — gdzie serwery są szybko tworzone i niszczone w niekończącym się cyklu — architekci chmury konfigurują okresy chłodzenia. Koncepcja numer cztery: Bezserwerowość.

### - 04. Bezserwerowe (FaaS i Firecracker MicroVMs)

4:53 Przez lata zespoły marketingowe promowały bezserwerowość jako magiczny kod działający w chmurze. W rzeczywistości bezserwerowość nadal używa serwerów — ale nie jesteś ich właścicielem, nie łatasz ich ani nie płacisz za nie, gdy żaden kod nie działa. Z Function-as-a-Service, takim jak AWS Lambda lub Google Cloud Functions, piszesz samodzielną funkcję obsługującą. Gdy wystąpi żądanie HTTP, przesłanie pliku S3 lub zmiana w bazie danych, środowisko wykonawcze chmury uruchamia efemeryczną

5:23 mikrowirtualną maszynę, taką jak Firecracker, w mniej niż pięć milisekund. Twój kod wykonuje się, zwraca odpowiedź i wyłącza się. Jeśli nikt nie odwiedzi Twojej witryny przez trzy miesiące, Twój rachunek za zasoby obliczeniowe wynosi dokładnie zero dolarów i zero centów. Jeśli milion użytkowników wejdzie na nią jednocześnie, dostawca uruchomi milion równoczesnych mikro-VM. Kompromisy inżynieryjne są realne: opóźnienie zimnego startu przy uruchamianiu świeżych środowisk wykonawczych, twarde piętnastominutowe ograniczenie wykonania na Lambdzie i ścisła bezstanowość.

5:55 Bezserwerowość jest bezkonkurencyjna dla potoków zdarzeń i sporadycznych API, ale słaba dla trwałych WebSockets lub wielogodzinnych zadań szkoleniowych.

### - 05. Architektura sterowana zdarzeniami (EDA i odsprzęganie)

6:05 Koncepcja numer pięć: Architektura sterowana zdarzeniami, czyli EDA. W tradycyjnych architekturach usługi komunikują się synchronicznie. Twoja usługa realizacji zamówienia wywołuje płatność, płatność wywołuje inwentarz, inwentarz wywołuje oszustwo, a oszustwo wywołuje e-mail. Tworzy to synchroniczną kaskadę zagłady. Jeśli dostawca poczty e-mail innej firmy doświadczy czkawki sieciowej i potrzebuje dziesięciu sekund na odpowiedź, całe żądanie realizacji zamówienia klienta wygasa z błędem. W architekturze sterowanej zdarzeniami usługi są całkowicie odsprzężone.

6:37 Gdy klient kliknie kup, usługa realizacji zamówienia nie wywołuje usług podrzędnych. Po prostu publikuje zdarzenie o nazwie OrderPlaced do centralnej magistrali zdarzeń, takiej jak Amazon EventBridge lub temat SNS. Realizacja zamówienia kończy się w pięćdziesiąt milisekund. Pracownicy podrzędni do płatności, odliczenia z inwentarza i potwierdzeń e-mail pobierają wiadomości niezależnie z własnych dedykowanych kolejek SQS. Jeśli usługa e-mail przestanie działać na godzinę, wiadomości bezpiecznie czekają buforowane w kolejce bez ani jednego pominiętego zamówienia.

### - 06. Orkiestracja kontenerów (Docker i Kubernetes)

7:13 Koncepcja numer sześć: Orkiestracja kontenerów. Docker rozwiązał problem pakowania: owija Twój kod aplikacji, biblioteki systemowe, konfigurację i środowisko wykonawcze w niezmienny obraz, który działa identycznie na Twoim MacBooku i w chmurze. Ale spakowanie kontenera jest łatwe. Uruchomienie pięciuset kontenerów na pięćdziesięciu fizycznych maszynach wirtualnych to moment, w którym inżynieria się załamuje. Dlatego istnieją orkiestratorzy kontenerów, tacy jak Kubernetes i AWS ECS.

7:41 Orkiestrator zapewnia płaszczyznę kontroli: serwer API, magazyn stanu etcd i inteligentny harmonogram. Deklarujesz swój pożądany stan: chcę dziesięć replik mojej usługi autoryzacji z dwoma gigabajtami RAM każda. Harmonogram sprawdza klaster, umieszcza pody na węzłach z wolną pamięcią, konfiguruje wewnętrzne sieci i ciągle uzgadnia rzeczywistość. Jeśli węzeł ulegnie awarii sprzętowej, Kubernetes wykrywa stratę i natychmiast przenosi wszystkie przemieszczone pody na

### - 07. 4 Filary przechowywania w chmurze (S3, EBS, bazy danych i Redis)

8:16 zdrowe węzły. Koncepcja numer siedem: Hierarchia przechowywania w chmurze. Początkujący często traktują przechowywanie w chmurze jako pojedynczy kubeł, do którego wrzucają pliki. W architekturze produkcyjnej przechowywanie jest podzielone na cztery różne filary, oparte na wzorcach dostępu i opóźnieniach. Pierwszym jest przechowywanie obiektowe, takie jak Amazon S3 lub Google Cloud Storage. Dostęp do plików uzyskuje się za pośrednictwem interfejsów API HTTP REST, używając prostych wywołań PUT i GET. Oferuje nieskończoną pojemność poziomą za dwa centy za gigabajt miesięcznie,

8:49 czyniąc go idealnym do wideo, przesłanych przez użytkowników plików, logów i kopii zapasowych. Drugim jest przechowywanie blokowe, takie jak Amazon EBS. Są to wirtualne dyski twarde zamontowane bezpośrednio do konkretnej maszyny wirtualnej za pomocą szybkich połączeń. Formatują się na standardowe systemy plików, takie jak ext4, obsługując szybki losowy dostęp do odczytu i zapisu wymagany przez silniki baz danych. Trzecim są zarządzane bazy danych: silniki relacyjne, takie jak PostgreSQL na RDS, zapewniające transakcje ACID i złożone złączenia,

9:21 oraz silniki NoSQL, takie jak DynamoDB, zapewniające jednocyfrowe milisekundowe opóźnienia w ogromnej skali. A czwartym są pamięci podręczne w pamięci RAM, takie jak Redis. Odczytywanie danych z pamięci RAM zajmuje mikrosekundy, a nie milisekundy. Pamięci podręczne znajdują się przed Twoją bazą danych, chroniąc ją przed powtarzającym się ruchem odczytu i zarządzając nietrwałymi tokenami sesji użytkowników.

### - 08. Wysoka dostępność i dziewiątki (przełączanie awaryjne w wielu AZ)

9:44 Koncepcja numer osiem: Wysoka dostępność, czyli HA. Dostępność odpowiada na jedno pytanie: przez jaki procent czasu Twoja aplikacja jest operacyjna i dostępna dla użytkowników? W umowach enterprise dostępność jest mierzona w dziewiątkach. Dwie dziewiątki, czyli dziewięćdziesiąt dziewięć procent dostępności, pozwala na ponad trzy i pół dnia przestojów rocznie. Cztery dziewiątki zmniejszają dozwolony czas przestoju do pięćdziesięciu dwóch minut, a pięć dziewiątek dopuszcza zaledwie pięć minut całkowitego przestoju rocznie.

10:15 Aby osiągnąć wysoką dostępność, należy wyeliminować pojedyncze punkty awarii w domenach błędów. W chmurze oznacza to wdrożenie w wielu Strefach Dostępności. Strefa Dostępności to nie pojedyncza szafa: to jedno lub więcej oddzielnych, fizycznych centrów danych oddalonych o mile, z niezależnym zasilaniem i chłodzeniem. Uruchamiając aktywne instancje w Strefie A i Strefie B z synchroniczną replikacją bazy danych, uderzenie pioruna lub przecięcie światłowodu, które powoduje awarię całego obiektu fizycznego, skutkuje automatycznym przełączeniem awaryjnym.

10:50 w trzydzieści sekund bez żadnej interwencji człowieka.

### - 09. Trwałość vs. Dostępność (Dlaczego 11 dziewiątek to nie uptime)

10:53 Koncepcja numer dziewięć: Trwałość a Dostępność. To najczęstsza pułapka koncepcyjna w architekturze chmury podczas rozmów kwalifikacyjnych. Inżynierowie często używają tych słów zamiennie, ale mierzą one zupełnie inne właściwości. Dostępność mierzy czas działania: czy mogę wykonać wywołanie API, aby odczytać lub zapisać moje dane w tej chwili? Trwałość mierzy zachowanie: czy moje dane przetrwają bez trwałego uszkodzenia, korupcji lub zniszczenia przez dziesięć lat?

11:24 Spójrzmy na Amazon S3 Standard. Jego umowa o poziomie usług (SLA) oferuje dziewięćdziesiąt dziewięć przecinek dziewięć procent dostępności, co pozwala na około czterdzieści trzy minuty przestoju każdego miesiąca, gdzie żądanie API może zwrócić błąd pięćset. Ale S3 obiecuje jedenaście dziewiątek trwałości: dziewięćdziesiąt dziewięć przecinek dziewięć dziewięć dziewięć dziewięć dziewięć dziewięć dziewięć dziewięć dziewięć procent. Jeśli przechowujesz dziesięć milionów plików w S3, statystycznie możesz spodziewać się utraty średnio jednego pliku co dziesięć tysięcy lat.

11:56 średnio jednego pliku co dziesięć tysięcy lat. S3 osiąga to poprzez kodowanie korekcyjne obiektów i replikowanie fragmentów w co najmniej najmniej trzech geograficznie rozdzielonych centrach danych. Podczas poważnej regionalnej awarii sieci, S3 może być tymczasowo niedostępne, ale twoje dane nigdy nie są niszczone.

### - 10. Infrastruktura jako kod (Terraform vs. Console Drift)

12:14 Koncepcja numer dziesięć: Infrastruktura jako kod, czyli IaC. W początkowych dniach przetwarzania w chmurze inżynierowie logowali się do konsoli zarządzania AWS i ręcznie klikali, aby tworzyć maszyny wirtualne, konfigurować podsieci i przypisywać grupy zabezpieczeń. Branża nazywa to ClickOps, a w produkcji jest to absolutna katastrofa. Ręczne zmiany w konsoli nie mają ścieżki audytu, mechanizmu wycofywania i nieuchronnie powodują rozbieżności w konfiguracji między środowiskami przejściowymi a produkcyjnymi. narzędzi Infrastructure as Code, takich jak Terraform,

12:48 OpenTofu, Pulumi lub AWS CDK, definiujesz swoją całą architekturę chmury w deklaratywnych plikach konfiguracyjnych przechowywanych w Git. Każda zmiana otwartego portu lub repliki bazy danych przechodzi przez żądanie ściągnięcia (pull request) i recenzję (peer review). żądanie ściągnięcia (pull request) i recenzję (peer review). Uruchomienie terraform plan podgląda dokładny The Daily Diff API przed jakąkolwiek zmianą, a uruchomienie identycznej repliki twojego stosu produkcyjnego zajmuje cztery minuty zamiast czterech tygodni.

### - 11. Sieci w chmurze (VPC, podsieci, NAT i grupy bezpieczeństwa)

13:20 Koncepcja numer jedenaście: Sieci w chmurze i wirtualne chmury prywatne. Kiedy wdrażasz serwery w chmurze, nie są one wystawione na surowy publiczny internet. Żyją w programowo zdefiniowanej izolowanej granicy zwanej VPC. Wewnątrz swojej VPC przydzielasz prywatną przestrzeń adresową IP, taką jak dziesięć-kropka-zero-kropka-zero-kropka-zero ukośnik szesnaście, i dzielisz ją na podsieci publiczne i prywatne. Podsieć publiczna ma bezpośrednią trasę do bramy internetowej (Internet Gateway).

13:51 Zawiera publicznie dostępne zasoby, takie jak równoważniki obciążenia aplikacji (Application Load Balancers) i bramy NAT Gateway. Jest to jedyna część twojej sieci, która posiada publiczne adresy IP. Twoje serwery aplikacji i bazy danych produkcyjnych znajdują się wyłącznie w podsieciach prywatnych bez publicznych adresów IP i zerowej liczby tras przychodzących z internetu. Kiedy twoje serwery zaplecza potrzebują pobrać aktualizacje bezpieczeństwa, ich ruch wychodzący kierowany jest przez bramę NAT w podsieci publicznej. Wokół każdej instancji znajdują się grupy zabezpieczeń (Security Groups): stanowe wirtualne zapory, które egzekwują zasadę najmniejszych uprawnień.

### - 12. Kompletny plan przedsiębiorstwa i werdykt

14:28 Twoja grupa zabezpieczeń bazy danych akceptuje połączenia tylko na porcie 5432 ściśle z grupy zabezpieczeń twoich serwerów aplikacji, czyniąc zewnętrzne włamania matematycznie niemożliwymi. Kiedy spojrzymy na to z szerszej perspektywy, te jedenaście prymitywów łączy się w jeden spójny system. Twój DNS kieruje do Load Balancera w podsieci publicznej, grupy autoskalowania obsługują skoki ruchu w wielu strefach dostępności (Availability Zones), szyny zdarzeń (event buses) rozdzielają pracowników zaplecza, a cały twój stos jest wdrażany z Git przy użyciu Infrastructure as Code.

15:02 Werdykt dzisiejszej lekcji mistrzowskiej: SHIP IT. Przestań zapamiętywać setki akronimów marketingowych chmury. Opanuj te jedenaście wzorców architektury, rozłącz swój stan, i buduj systemy, które nie mogą zawieść. Powiedz mi, która koncepcja chmury sprawiła ci największy ból głowy, kiedy dopiero zaczynałeś budować, w komentarzach. Aby pobrać kompletny arkusz oszustw architektury, zasubskrybuj biuletyn na the daily diff dot dev,

15:28 link poniżej. I to na tyle w The Daily Diff na dziś. Jestem Niko z Axrisi. Łącz odpowiedzialnie.

## Źródła

- [AWS Well-Architected Framework (Reliability & Performance Pillars)](https://aws.amazon.com/architecture/well-architected/) — aws.amazon.com
- [Kubernetes Architecture & Control Plane Concepts](https://kubernetes.io/docs/concepts/architecture/) — kubernetes.io
- [Martin Fowler: What is Event-Driven Architecture?](https://martinfowler.com/articles/201701-event-driven.html) — martinfowler.com
- [Amazon S3 Data Durability & Availability Technical Whitepaper](https://aws.amazon.com/s3/features/) — aws.amazon.com
- [HashiCorp: Declarative Infrastructure as Code with Terraform](https://www.terraform.io/) — www.terraform.io