Matematyka opóźnień: co narzuca fizyka
Światło w próżni porusza się z prędkością 299 792 km/s. Światło w kablu światłowodowym porusza się z prędkością ok. 2/3 tej wartości — ok. 200 000 km/s, czyli ok. 5 ms na 1 000 km w jedną stronę. Round-trip time (RTT) to dwukrotność: ok. 10 ms na 1 000 km kabla. Realne trasy światłowodowe to zwykle 1,3-2x odległość po wielkim kole, więc do tego należy doliczyć dodatkowe opóźnienie wynikające z realiów routingu.
Światło zwalnia w szkle ze względu na współczynnik załamania. Współczynnik załamania światłowodu jednomodowego wynosi ok. 1,467, więc prędkość światła w światłowodzie to c/1,467 ≈ 204 300 km/s. Daje to opóźnienie jednokierunkowe ok. 4,9 ms na 1 000 km światłowodu i round-trip 9,8 ms. To twardy fizyczny próg — żaden inżynierski wysiłek dostawcy nie pobije prędkości światła. Bardziej praktyczna reguła kciuka do planowania produkcyjnego: budżetować 1 ms na 100 km w jedną stronę plus 1-2 ms narzutu na przełączanie i routing na każdy przeskok sieciowy. Długodystansowe kable podmorskie są dobrze zaprojektowane i zbliżają się do teoretycznego minimum (Londyn-Nowy Jork to ok. 70 ms RTT, blisko granicy 5 500 km wielkiego koła). Trasy ostatniej mili i wewnątrzmiejskie często wynoszą 5-15 ms ze względu na przeskoki przez routery i geometrię peeringu ISP, a nie odległość.
Realne szacunki RTT między głównymi miastami
Przybliżone czasy round-trip (pełny RTT) między głównymi hubami hostingu w 2026 r.: Londyn-Amsterdam ok. 10 ms, Londyn-Frankfurt ok. 15 ms, Londyn-Nowy Jork ok. 70 ms, Nowy Jork-San Francisco ok. 70 ms, Frankfurt-Singapur ok. 160 ms, Londyn-Sydney ok. 250 ms, Tokio-San Francisco ok. 100 ms. To typowe wartości najlepszego przypadku światłowodowego mierzone TCP-do-TCP między peerami w centrach danych.
Te liczby pochodzą z publicznych danych peeringowych ogłaszanych przez główne IXP-y (LINX, AMS-IX, DE-CIX, KINX) i wielkoskalowych atlasów opóźnień (RIPE Atlas, WonderNetwork, Cloudping). Realny RTT zmienia się o 10-30% w zależności od pory dnia, relacji peeringowych między dostawcą a ISP użytkownika oraz konkretnej trasy kabla podmorskiego. Powyższe liczby są typowe, nie gwarantowane, i zakładają, że oba końce znajdują się w centrach danych z tranzytem wielo-Tbps. Domowe połączenia ostatniej mili dodają kolejne 5-30 ms na próg między centrami danych.
| Z | Do | Odległość (wielkie koło) | Typowy RTT |
|---|---|---|---|
| Londyn | Amsterdam | 360 km | ok. 10 ms |
| Londyn | Frankfurt | 640 km | ok. 15 ms |
| Londyn | Paryż | 340 km | ok. 10 ms |
| Frankfurt | Warszawa | 900 km | ok. 20 ms |
| Londyn | Nowy Jork | 5 570 km | ok. 70 ms |
| Nowy Jork | Miami | 1 760 km | ok. 30 ms |
| Nowy Jork | San Francisco | 4 140 km | ok. 70 ms |
| San Francisco | Tokio | 8 280 km | ok. 100 ms |
| Frankfurt | Singapur | 10 290 km | ok. 160 ms |
| Londyn | Sydney | 16 990 km | ok. 250 ms |
| Frankfurt | Mumbaj | 6 580 km | ok. 110 ms |
| São Paulo | Miami | 6 580 km | ok. 120 ms |
Rezydencja danych: RODO/GDPR, CLOUD Act i reszta
Dane osobowe z UE/EOG podlegają RODO/GDPR (Rozporządzenie (UE) 2016/679), które ogranicza transfery poza EOG bez konkretnych zabezpieczeń. Amerykański CLOUD Act (2018) pozwala władzom USA wymusić na dostawcach z siedzibą w USA ujawnienie danych niezależnie od miejsca ich fizycznego przechowywania. Rosja i Chiny mają własne reżimy lokalizacji danych. Należy wybrać region centrum danych zgodny zarówno z jurysdykcjami użytkowników, jak i ze zobowiązaniami umownymi.
RODO/GDPR (obowiązuje od maja 2018 r.) traktuje wszelkie dane osobowe rezydentów UE lub EOG — imię, e-mail, adres IP, dane behawioralne — jako regulowane niezależnie od siedziby administratora. Transfery transgraniczne wymagają decyzji o adekwatności, Standardowych Klauzul Umownych lub Wiążących Reguł Korporacyjnych. Odstępstwa z art. 49 są wąskie. Wyrok Schrems II (Trybunał Sprawiedliwości UE, lipiec 2020 r.) uchylił Privacy Shield i znacznie zaostrzył zabezpieczenia transferowe. Amerykański CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018 r.) pozwala federalnym władzom USA wymusić na każdym dostawcy z siedzibą w USA wydanie przechowywanych danych, nawet jeśli dane znajdują się na serwerze we Frankfurcie. Tworzy to napięcie dla europejskich klientów korzystających z dostawców hostingu z siedzibą w USA, niezależnie od tego, w którym centrum danych fizycznie żyją ich dane. Rosyjska Ustawa Federalna nr 242-FZ wymaga, by dane osobowe rosyjskich obywateli były początkowo przetwarzane na serwerach fizycznie znajdujących się w Rosji. Chińska PIPL (Personal Information Protection Law, obowiązuje od listopada 2021 r.) wymaga lokalizacji dla operatorów krytycznej infrastruktury informacyjnej i dla podmiotów przetwarzających duże wolumeny danych. Żaden z tych reżimów nie obchodzi, gdzie działają serwery aplikacji; wszystkie obchodzi, gdzie dane osobowe są przechowywane i przetwarzane.
Kiedy wieloregionowość ma sens
Wieloregionowość jest uzasadniona, gdy są geograficznie rozproszeni użytkownicy z wymaganiem opóźnień poniżej 100 ms, gdy są regulacyjne obowiązki rezydencji danych w wielu jurysdykcjach lub gdy ryzyko przestoju jednoregionowego jest nieakceptowalne. Rzadko jest uzasadniona przy projektach hobbystycznych, SaaS z niskim ruchem i użytkownikami w jednym regionie lub obciążeniach, w których złożoność inżynierska przeważa nad korzyściami z opóźnień.
Wieloregionowość dodaje trzy konkretne koszty. Po pierwsze, złożoność inżynierską: replikacja danych (z eventual consistency lub globalnie synchroniczna), logika routingu (geo-DNS, anycast, failover regionalny) i obserwowalność między regionami pomnażają powierzchnię operacyjną. Po drugie, koszt infrastruktury: co najmniej podwójna moc obliczeniowa i pamięć masowa plus opłaty za tranzyt między regionami pobierane przez dostawców chmury za GB. Po trzecie, kompromisy spójności: synchroniczne globalne zapisy są fizycznie ograniczone tą samą matematyką opóźnień z poprzedniej sekcji, więc większość projektów wieloregionowych akceptuje jakąś formę eventual consistency. Uzasadnienia wartym tego kosztu: realni użytkownicy rozproszeni między kontynentami, gdzie ponad 200 ms opóźnień zabija konwersję, wymagania odzyskiwania po awarii z RTO poniżej sekundy, zobowiązania regulacyjne, by jednocześnie utrzymywać dane UE w UE i dane USA w USA, lub wymagania wysokiej dostępności active-active, w których awaria pojedynczego centrum danych musi być niewidoczna. Większość obciążeń produkcyjnych tego nie potrzebuje; wiele projektów przeskakuje do wieloregionowości zbyt wcześnie.
Drzewo decyzyjne: jak wybrać region
Krok 1: zidentyfikować, gdzie mieszka 80% użytkowników (analityka, logi CDN, oczekiwany rynek docelowy). Krok 2: wybrać najbliższy region hostingu. Krok 3: sprawdzić, czy jurysdykcja prawna pasuje do zobowiązań rezydencji danych. Krok 4: dodać drugi region tylko wtedy, gdy krok 1 ujawni drugą grupę użytkowników w odległości ponad 100 ms RTT od pierwszej, lub gdy wymagają tego potrzeby HA/DR.
Trzeba przejść przez to drzewo uczciwie. Dla typowego SaaS skupionego na Europie z użytkownikami głównie w Niemczech, Francji, Wielkiej Brytanii i Holandii pojedyncze zachodnioeuropejskie centrum danych (Frankfurt, Amsterdam lub Londyn) utrzymuje każdego użytkownika poniżej 30 ms RTT i czysto spełnia RODO/GDPR. Dla skoncentrowanego na USA produktu B2B z użytkownikami od Bostonu po Los Angeles pojedyncze centrum danych w US East (Ashburn, NYC) utrzymuje użytkowników wschodniego wybrzeża poniżej 20 ms, a zachodniego poniżej 80 ms — źle dla gier, dobrze dla większości SaaS. Dla naprawdę globalnych produktów (aplikacji webowych z użytkownikami na każdym kontynencie) region podstawowy plus CDN z globalną obecnością brzegową zwykle pobija prowadzenie active-active w trzech centrach danych. Dla produktów z twardymi wymaganiami rezydencji danych w wielu jurysdykcjach (oddzielnymi planami danych dla UE i tylko USA) wieloregionowość staje się obowiązkowa niezależnie od opóźnień.
Skróty zgodności: certyfikaty, które naprawdę coś znaczą
Warto szukać ISO/IEC 27001 (zarządzanie bezpieczeństwem informacji), SOC 2 Type II (kontrole operacyjne audytowane w czasie, a nie w pojedynczym momencie) i PCI DSS Level 1 (dane płatnicze), jeśli mają zastosowanie. Dla klientów z UE warto szukać wyraźnych umów o przetwarzaniu danych według RODO (DPA) i jasnej listy podmiotów podprzetwarzających. Ogólny marketing „bezpieczeństwo klasy korporacyjnej” bez nazwanych certyfikatów jest w zasadzie bez znaczenia.
Trzy certyfikaty mają realną wagę. ISO/IEC 27001:2022 to międzynarodowy standard systemów zarządzania bezpieczeństwem informacji i wymaga niezależnego audytu oraz bieżących audytów nadzorczych. SOC 2 Type II audytuje kontrole organizacji w oknie obserwacji 6-12 miesięcy, co odróżnia go od Type I (punktowego). PCI DSS ma zastosowanie, gdy obsługuje się karty płatnicze; Level 1 jest dla organizacji przetwarzających ponad 6 mln transakcji rocznie. Dla europejskich klientów DPA według RODO to wiążący umownie aneks o przetwarzaniu danych, który dokładnie wymienia, co dostawca może i czego nie może robić z danymi. Poza tym warto szukać raportów przejrzystości (jak często dostawca otrzymuje żądania organów ścigania?), opublikowanej listy podmiotów podprzetwarzających (osób trzecich dotykających danych) oraz jasnych gwarancji usuwania danych po zakończeniu umowy. Ogólne frazy w stylu „bezpieczeństwo klasy bankowej” lub „szyfrowanie klasy wojskowej” nic nie mówią — leżący u podstaw algorytm AES-256 jest wszędzie taki sam.