Porównanie instancji chmurowych

Ten sam kształt w trzech chmurach i dlaczego to nie ta sama oferta

Wybór instancji bazy zwykle zaczyna się od kształtu — tyle vCPU, tyle pamięci — a kończy na tej nazwie z listy dostawcy, która jest najtańsza powyżej tego progu. To narzędzie robi takie wyszukanie jednocześnie w AWS RDS, Google Cloud SQL i Azure Flexible Server i dodaje liczbę, którą te listy pomijają: ile połączeń każda z nich naprawdę pozwoli ci otworzyć.

Jak to działa

• Bierze minimalną liczbę vCPU i minimalną pamięć i znajduje najmniejszą instancję spełniającą oba warunki, u każdego dostawcy.
• Pokazuje obok dwie większe opcje, żebyś zobaczył, ile zasobów kosztuje kolejny krok w górę.
• Wypisuje limit połączeń każdej instancji obok jej kształtu, policzony z reguły danego dostawcy.
• Wyraźnie oznacza najmniejsze dopasowanie, bo pierwszy wiersz w tabeli dostawcy rzadko jest tym, którego chcesz.

najmniejsze dopasowanie = minimum z instancji, gdzie
    vcpu >= twoje_minimum  ORAZ  pamięć >= twoje_minimum
  posortowane po vcpu, potem po pamięci

połączenia pochodzą z opublikowanej reguły każdego dostawcy,
a nie ze wspólnego standardu branżowego

Przykład z liczbami

Usługa wymagająca co najmniej 8 vCPU i 32 GiB, wyceniona w trzech chmurach.

1. AWS: db.m5.2xlarge — 8 vCPU, 32 GiB, około 3324 połączeń
2. Azure: B8ms — 8 vCPU, 32 GiB, 3437 połączeń
3. Google Cloud SQL: db-custom-8-53248 — 8 vCPU, 52 GiB, 600 połączeń
4. kształty w dwóch chmurach są niemal identyczne; limity połączeń nie są w ogóle

AWS i Azure trafiają w praktycznie identyczny sprzęt z praktycznie identycznym sufitem połączeń. Cloud SQL daje 20 GiB pamięci więcej i około jedną piątą połączeń. Jeśli twoja usługa jest ciężka od połączeń, a nie od pamięci, to jest cała decyzja.

Jak czytać wynik

• Cloud SQL przyjmuje dowolne niestandardowe kształty maszyn, więc najmniejsze dopasowanie pokazane dla Google jest najmniejszym w tym katalogu, a nie najmniejszym istniejącym. Kształt dokładnie 8 vCPU i 32 GiB jest tam dostępny; kolumna to sygnalizuje, a liczbę Google traktuj jako próbkę, nie wyczerpującą listę.
• Najmniejsze dopasowanie bywa instancją typu burstable, a to nie jest równoważnik. Seria B w Azure i klasa t w AWS zbierają kredyty CPU w bezczynności i dławią, gdy kredyty się skończą — w porządku dla bazy deweloperskiej albo skokowego narzędzia wewnętrznego, słabo dla czegokolwiek z trwałym poziomem obciążenia.
• Liczby vCPU nie są porównywalne między chmurami bez ostrożności. Instancje AWS Graviton liczą rdzenie fizyczne, a klasy x86 liczą wątki, więc 8 vCPU na Gravitonie i 8 vCPU na x86 to nie ta sama moc. W obrębie jednej chmury porównuj pewnie, między chmurami tylko z grubsza.
• To porównanie kształtu i sufitu połączeń, a nie ceny. Pojemność zarezerwowana, rabaty za zobowiązanie i plany oszczędnościowe przesuwają realny koszt wielokrotnie i przesuwają go inaczej w każdej chmurze, więc porównanie kształtów to początek decyzji, a nie jej koniec.
• Dla większości baz pamięć znaczy więcej niż vCPU, bo wyznacza i cache trzymający zapytania z dala od dysku, i — w AWS oraz Azure — sam sufit połączeń. Jeśli nie wiesz, który próg podnieść, podnieś pamięć.

Częste pytania

Dlaczego Google pokazuje więcej pamięci, niż prosiłem?

Bo ten katalog próbkuje popularne kształty Cloud SQL, a nie wylicza wszystkich możliwych, i najbliższy spróbkowany kształt powyżej twojego progu może go przestrzelić. Cloud SQL wspiera kształty niestandardowe, więc zwykle poprosisz o dokładnie taką pamięć, jaką chcesz — kolumnę Google traktuj orientacyjnie.

Czy najmniejsze dopasowanie to zawsze właściwy wybór?

To najtańsza rzecz przekraczająca twój próg, co jest właściwe tylko wtedy, gdy próg jest właściwy. Ustaw próg na podstawie zmierzonego zużycia plus zapasu na wzrost i na przełączenie awaryjne, a nie na obecnym szczycie — instancja dobrana dokładnie do dzisiejszego szczytu nie ma miejsca na jutrzejszy.

Dlaczego limity połączeń tak się różnią przy tej samej pamięci?

Bo ustalają je różne reguły o różnych intencjach. AWS i Azure wyprowadzają limit z pamięci i lądują w tym samym przedziale. Google ustala go z progów pamięci na dużo niższych wartościach, zakładając, że obciążenia z wieloma połączeniami używają poolera. Żadna z trzech nie jest błędna; są egzekwowane inaczej i to jest to, co ciebie dotyczy.