0Pricing
Cloud & IT Cert Prep · Lekcja

Scenariusze wysokiej wydajności i optymalizacji kosztów

Odpowiadać na pytania scenariuszowe dotyczące strategii buforowania, optymalizacji zapytań jeziora danych, kompromisów Reserved i Spot oraz architektur replik odczytu.

Scenariusze wysokiej wydajności i optymalizacji kosztów to bezpłatna lekcja Cloud & IT Cert Prep na CoddyKit. To lekcja 3 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Cloud & IT Cert Prep, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Cloud & IT Cert Prep zawiera 4 lekcji w sumie.

Scenariusz 1: Buforowanie w celu zmniejszenia obciążenia bazy danych

Scenariusz: Baza danych RDS MySQL witryny z wiadomościami obsługuje 90% ruchu odczytu dotyczącego treści artykułów, które zmieniają się najwyżej raz na godzinę. Średnie użycie procesora bazy wynosi 80%, koszty rosną, a czas odpowiedzi na zapytanie wynosi 200 ms. Rozwiązanie: Należy dodać klaster ElastiCache Redis przed RDS, korzystając ze wzorca lazy loading (cache-aside). Aplikacja najpierw sprawdza pamięć podręczną — w przypadku trafienia zwraca zapisany artykuł w czasie <1 ms. W przypadku braku trafienia odpytuje RDS, zwraca wynik i zapisuje go w pamięci podręcznej z TTL wynoszącym 1 godzinę. Oczekiwany rezultat: współczynnik trafień w pamięci podręcznej na poziomie 90%, spadek użycia procesora RDS poniżej 20% oraz skrócenie czasu odpowiedzi do poniżej 5 ms dla odpowiedzi z pamięci podręcznej.

import boto3, json

elasticache = boto3.client('elasticache')
redis_client = None  # assume redis-py client connected to ElastiCache endpoint

def get_article(article_id):
    cache_key = 'article:' + str(article_id)
    # Check cache first
    cached = redis_client.get(cache_key)
    if cached:
        return json.loads(cached)  # cache hit: <1ms
    # Cache miss: query RDS
    article = rds_query('SELECT * FROM articles WHERE id = %s', article_id)
    # Write to cache with 1-hour TTL
    redis_client.setex(cache_key, 3600, json.dumps(article))
    return article

Scenariusz 2: CloudFront do dostarczania zasobów statycznych

Scenariusz: Użytkownicy w regionie Azji i Pacyfiku czekają 2–4 sekundy na załadowanie aplikacji webowej hostowanej na EC2 w us-east-1. Aplikacja dostarcza duże zasoby statyczne (obrazy, JS, CSS). Rozwiązanie: Należy umieścić dystrybucję CloudFront przed ALB. Należy skonfigurować zachowanie buforowania dla ścieżki /static/* z długim TTL (np. 1 tydzień), aby pliki statyczne były buforowane w brzegowych lokalizacjach CloudFront znajdujących się blisko użytkowników w Azji. Dynamiczne żądania API omijają buforowanie z TTL=0. Użytkownicy z Azji ładują zasoby statyczne z lokalizacji brzegowej w Singapurze lub Tokio w czasie poniżej 100 ms, zamiast czekać na wielokrotne podróże do us-east-1.

# CloudFront origin for ALB + separate behaviour for static assets
aws cloudfront create-distribution --distribution-config '{
  'Origins': {
    'Quantity': 1,
    'Items': [{
      'Id': 'alb-origin',
      'DomainName': 'my-alb.us-east-1.elb.amazonaws.com',
      'CustomOriginConfig': {"HTTPSPort": 443, "OriginProtocolPolicy": "https-only"}
    }]
  },
  'CacheBehaviors': {
    'Quantity': 1,
    'Items': [{
      'PathPattern': '/static/*',
      'DefaultTTL': 604800,
      'MaxTTL': 604800
    }]
  },
  'DefaultCacheBehavior': {"DefaultTTL": 0}
}'

Scenariusz 3: Dobór rozmiaru za pomocą Compute Optimizer

Scenariusz: Firma ma 500 instancji EC2, z których wiele zostało skonfigurowanych 3 lata temu z dużymi typami instancji. Rachunek AWS jest wysoki, ale firma nie wie, które instancje mają nadmiar przydzielonych zasobów. Rozwiązanie: Należy włączyć AWS Compute Optimizer (bezpłatny, korzysta z 14 dni metryk CloudWatch). Compute Optimizer analizuje rzeczywiste użycie procesora, pamięci, sieci i dysku każdej instancji oraz przedstawia zalecenia dotyczące doboru właściwego rozmiaru. Dla instancji t3.xlarge ze średnim użyciem procesora na poziomie 8% zalecane byłoby zmniejszenie rozmiaru do t3.small. Zastosowanie zaleceń dla 500 instancji zazwyczaj zmniejsza koszty EC2 o 20–40%.

# Enable Compute Optimizer at account level
aws compute-optimizer update-enrollment-status \
  --status Active

# Get EC2 instance recommendations
aws compute-optimizer get-ec2-instance-recommendations \
  --filters Name=Finding,Values=OVER_PROVISIONED \
  --query 'instanceRecommendations[*].{Instance: instanceArn, Current: currentInstanceType, Recommended: recommendationOptions[0].instanceType}' \
  --output table

Scenariusz 4: Instancje Spot do przetwarzania wsadowego

Scenariusz: Firma zajmująca się genomiką uruchamia nocne zadania wsadowe, które trwają 8 godzin i mogą zostać ponowione po przerwaniu. Koszt instancji EC2 On-Demand dla tych zadań wynosi 10 000 USD miesięcznie. Rozwiązanie: Należy użyć instancji EC2 Spot dla floty przetwarzania wsadowego. Instancje Spot to niewykorzystana pojemność EC2 dostępna z rabatem do 90%. W przypadku zadań wsadowych odpornych na przerwania należy użyć AWS Batch, który automatycznie ponownie umieszcza nieudane zadania Spot w kolejce i korzysta z mieszanej floty (Spot + minimalny plan awaryjny On-Demand). Oczekiwane oszczędności: zmniejszenie kosztów obliczeniowych o 70–90% — z 10 000 do 1 000–3 000 USD miesięcznie.

# AWS Batch compute environment with Spot instances
aws batch create-compute-environment \
  --compute-environment-name spot-genomics \
  --type MANAGED \
  --state ENABLED \
  --compute-resources '{
    "type": "SPOT",
    "bidPercentage": 60,
    "minvCpus": 0,
    "maxvCpus": 256,
    "instanceTypes": ["optimal"],
    "subnets": ["subnet-1a", "subnet-1b"],
    "securityGroupIds": ["sg-batch"],
    "instanceRole": "arn:aws:iam::123456789012:instance-profile/ecsInstanceRole",
    "spotIamFleetRole": "arn:aws:iam::123456789012:role/AmazonEC2SpotFleetRole"
  }' \
  --service-role arn:aws:iam::123456789012:role/AWSBatchServiceRole

Scenariusz 5: DynamoDB On-Demand dla zmiennego ruchu

Scenariusz: Tabela wyników gry korzysta z DynamoDB z przepustowością skonfigurowaną z góry. Podczas premier gier ruch wzrasta 50-krotnie, a tabela ogranicza żądania. Poza premierami przepustowość jest niemal zerowa — skonfigurowana pojemność jest niewykorzystywana. Rozwiązanie: Należy przełączyć DynamoDB na tryb pojemności On-Demand. On-Demand natychmiast skaluje się do dowolnej przepustowości bez ręcznego planowania pojemności i pobiera opłaty za żądanie, a nie za skonfigurowaną jednostkę przepustowości. Płatność obejmuje tylko wykonane żądania — między premierami nie ma kosztu bezczynnej pojemności. On-Demand oznacza nieco wyższy koszt pojedynczego żądania w zamian za gwarancję braku ograniczania żądań i brak konieczności zarządzania pojemnością.

# Switch existing DynamoDB table to On-Demand mode
aws dynamodb update-table \
  --table-name Leaderboard \
  --billing-mode PAY_PER_REQUEST

# Verify the change
aws dynamodb describe-table \
  --table-name Leaderboard \
  --query 'Table.BillingModeSummary.BillingMode'

Scenariusz 6: S3 Intelligent-Tiering dla nieprzewidywalnego dostępu

Scenariusz: Firma przechowuje miliony obrazów wygenerowanych przez użytkowników w S3 Standard. Wzorce dostępu są nieprzewidywalne — niektóre obrazy są otwierane codziennie, a do innych nikt nie odwołuje się przez wiele miesięcy. Firma chce obniżyć koszty przechowywania bez ręcznego zarządzania zasadami cyklu życia. Rozwiązanie: Należy użyć S3 Intelligent-Tiering. Usługa automatycznie przenosi obiekty między warstwami na podstawie wzorców dostępu: Frequent Access (Standard), Infrequent Access (brak dostępu przez co najmniej 30 dni), Archive Instant Access (co najmniej 90 dni) oraz Archive Access (co najmniej 90 dni, opcjonalna warstwa). W ramach Intelligent-Tiering nie ma opłat za pobieranie danych. Opłata za monitorowanie wynosi 0,0025 USD za 1000 obiektów miesięcznie — w przypadku dużych zbiorów danych jest pomijalna.

# Move objects to Intelligent-Tiering via lifecycle policy
aws s3api put-bucket-lifecycle-configuration \
  --bucket user-images-bucket \
  --lifecycle-configuration '{
    "Rules": [{
      "ID": "AutoTier",
      "Status": "Enabled",
      "Filter": {},
      "Transitions": [{
        "Days": 0,
        "StorageClass": "INTELLIGENT_TIERING"
      }]
    }]
  }'

Scenariusz 7: Kompromis między Athena a Redshift

Scenariusz: Startup chce wykonywać zapytania do tabel w jeziorze danych S3. Uruchamia około 10 zapytań ad hoc tygodniowo. Dostawca proponuje Amazon Redshift z klastrem dc2.large. Rozwiązanie dla startupu: Należy rozpocząć od Amazon Athena — bez kosztów infrastruktury i z opłatami wyłącznie za zeskanowane dane (około 5 USD/TB). 10 zapytań tygodniowo na dobrze partycjonowanych danych Parquet może kosztować mniej niż 5 USD miesięcznie. Klaster Redshift dc2.large kosztuje około 180 USD miesięcznie przy ciągłym działaniu. Redshift staje się opłacalny dopiero wtedy, gdy współbieżność zapytań jest wysoka (ponad 50 zapytań dziennie) lub wymagany jest czas odpowiedzi poniżej sekundy. Słowa kluczowe „ad hoc, infrequent” jednoznacznie wskazują na usługę Athena.

# Athena cost estimate for 10 queries/week:
# Assume each query scans 5 GB of Parquet data
# 10 queries x 5 GB = 50 GB / week = 200 GB / month
# Athena cost: 200 GB x $0.005/GB = $1.00 / month
#
# Redshift dc2.large cost: $0.25/hr x 24hr x 30days = $180/month
#
# For 10 queries/week -> Athena saves $179/month
# Breakeven: when queries scan >36 TB/month or concurrency >50/day -> use Redshift

Scenariusz 8: Wybór typu woluminu EBS

Scenariusz: Serwer relacyjnej bazy danych wymaga 64 000 IOPS przy stabilnie niskich opóźnieniach. Obecny wolumin gp3 EBS osiąga limit IOPS. Rozwiązanie: Należy przejść na io2 Block Express (typ woluminu EBS przeznaczony dla baz danych intensywnie korzystających z operacji wejścia-wyjścia). io2 Block Express obsługuje do 256 000 IOPS na wolumin i zapewnia opóźnienia poniżej milisekundy. Jest droższy niż gp3 (0,125 USD/GB + 0,065 USD za skonfigurowane IOPS miesięcznie), ale jest jedyną opcją EBS spełniającą wymaganie co najmniej 64 000 IOPS. W przypadku obciążeń baz danych, dla których opóźnienia mają krytyczne znaczenie, a limit 16 000 IOPS gp3 jest niewystarczający, io2 jest jedynym praktycznym wyborem EBS.

# Create io2 Block Express volume with 64,000 IOPS
aws ec2 create-volume \
  --volume-type io2 \
  --size 500 \
  --iops 64000 \
  --availability-zone us-east-1a \
  --encrypted

# EBS volume type IOPS limits summary:
# gp3: up to 16,000 IOPS (default 3,000, configurable)
# io1: up to 64,000 IOPS (on Nitro instances)
# io2 Block Express: up to 256,000 IOPS
# st1 (throughput HDD): no IOPS focus, max 500 MB/s throughput
# sc1 (cold HDD): lowest cost, 250 MB/s max, rarely accessed data

Scenariusz 9: Reserved Instances dla stabilnych obciążeń

Scenariusz: Firma stale uruchamia 20 instancji EC2 r6i.4xlarge na potrzeby aplikacji produkcyjnej i przez 3 lata nie przewiduje zmian wymagań. Obeczne koszty tych instancji w modelu On-Demand wynoszą 80 000 USD rocznie. Rozwiązanie: Należy kupić 3-year Standard Reserved Instances (lub skorzystać z Compute Savings Plans) z płatnością All Upfront, aby uzyskać maksymalną zniżkę. Standard Reserved Instances oferują do 72% zniżki względem modelu On-Demand. Instancje działają przez całą dobę, 7 dni w tygodniu, przy przewidywalnym obciążeniu — jest to klasyczny profil zastosowania Reserved Instances. Oczekiwane obniżenie kosztów: 80 000 USD × 0,72 = 22 400 USD rocznie zamiast 80 000 USD rocznie w modelu On-Demand, czyli oszczędność 57 600 USD rocznie.

# Reserved Instance purchase decision matrix:
# On-Demand:          No commitment, highest price, any workload
# 1-yr RI (All Up):   40% discount, 1-yr commitment, specific instance type
# 3-yr RI (All Up):   60-72% discount, 3-yr commitment, best for stable workloads
# Compute Savings Plan: 66% max discount, flexible instance family/size/Region
# EC2 Spot:           90% discount, interruptible, batch/stateless only
#
# Rule: if usage > 70% of the time for >1 year -> buy RI or Savings Plan
# Rule: if usage < 50% -> stick with On-Demand
# Rule: if usage pattern is steady 3yr -> 3yr RI All Upfront maximises savings

Scenariusz 10: Koszt Lambda a EC2 przy zmiennym ruchu

Scenariusz: Firma uruchamia interfejs REST API na instancji EC2 t3.micro, której koszt wynosi 8 USD miesięcznie. API otrzymuje 1 milion żądań miesięcznie, a każde z nich jest przetwarzane przez 100 ms. Zespół chce wiedzieć, czy Lambda byłaby tańsza. Analiza: Cennik Lambda: 1 000 000 żądań × 0,0000002 USD = 0,20 USD (koszt żądań) + 1 000 000 × 0,1 s × 128 MB pamięci × stawka = około 1,67 USD (koszt obliczeń), czyli około 1,87 USD miesięcznie. W przypadku tego interfejsu API o niewielkim ruchu Lambda jest tańsza niż EC2. Gdy ruch wzrośnie powyżej około 40 milionów żądań miesięcznie, EC2 stanie się tańsze. Należy użyć narzędzia Lambda Cost Calculator, aby wyznaczyć próg opłacalności dla danego obciążenia.

# Lambda vs EC2 cost rough break-even calculation:
# Lambda costs: $0.20 per 1M requests + $0.0000166667 per GB-second
# At 128 MB memory, 100ms duration:
#   GB-seconds per request = 0.128 GB x 0.1s = 0.0128 GB-s
#   Cost per request = $0.0000166667 x 0.0128 = $0.000000213 compute
#   + $0.0000002 request fee = $0.000000413 total per request
#
# EC2 t3.micro: $0.0104/hr x 720 hrs = $7.49/month
# Break-even: $7.49 / $0.000000413 = ~18 million requests/month
# Below 18M requests/month -> Lambda cheaper
# Above 18M requests/month -> EC2 cheaper (if utilisation is high)

Scenariusz 11: Global Accelerator dla dynamicznych interfejsów API

Scenariusz: Globalny interfejs API obsługujący użytkowników w Europie, Stanach Zjednoczonych i Azji charakteryzuje się niestabilnymi opóźnieniami, ponieważ ruch przebiega nieprzewidywalnymi trasami internetowymi. Rozważano CloudFront, ale odpowiedzi API są dynamiczne (nie można ich buforować). Rozwiązanie: Należy użyć AWS Global Accelerator. Usługa udostępnia globalnie dwa statyczne anycast IP addresses. Ruch użytkownika trafia do globalnej sieci szkieletowej AWS w najbliższej lokalizacji brzegowej AWS, a następnie jest przesyłany prywatną siecią AWS do źródła w docelowym Regionie — z pominięciem przeciążonego publicznego Internetu na odcinku pośrednim. Global Accelerator skraca czas odpowiedzi dynamicznego interfejsu API o 20–60% i zapewnia natychmiastowe przełączenie awaryjne, gdy punkt końcowy w Regionie przestaje działać poprawnie.

# Create a Global Accelerator for an ALB
aws globalaccelerator create-accelerator \
  --name my-api-accelerator \
  --ip-address-type IPV4 \
  --enabled

# Add a listener and endpoint group pointing to ALB
aws globalaccelerator create-listener \
  --accelerator-arn arn:aws:globalaccelerator::123:accelerator/abc \
  --protocol TCP \
  --port-ranges '[{"FromPort": 443, "ToPort": 443}]'

# Endpoint group in us-east-1 with ALB
aws globalaccelerator create-endpoint-group \
  --listener-arn arn:aws:globalaccelerator::123:listener/xyz \
  --endpoint-group-region us-east-1 \
  --endpoint-configurations '[{"EndpointId": "arn:aws:elasticloadbalancing:...", "Weight": 100}]'

Szybki sprawdzian

Sprawdź swoje zrozumienie zagadnień AWS Solutions Architect (SAA-C03) omawianych w tej lekcji.

Podsumowanie lekcji

W tej lekcji przeanalizowano scenariusze obejmujące: lazy loading w ElastiCache w celu zmniejszenia użycia procesora RDS z 80% do 20%, Spot Instances i AWS Batch pozwalające obniżyć koszty zadań wsadowych o 70–90%, Athena do rzadkich zapytań ad hoc w porównaniu z Redshift do analityki o wysokiej współbieżności oraz S3 Intelligent-Tiering dla nieprzewidywalnych wzorców dostępu bez opłat za pobieranie danych. Następna część to końcowy sprawdzian: krótkiego egzaminu z mieszanych dziedzin, przeprowadzanego na czas, który oceni Państwa gotowość.

Często zadawane pytania

Czy lekcja „Scenariusze wysokiej wydajności i optymalizacji kosztów” jest bezpłatna?

Tak — pełny tekst „Scenariusze wysokiej wydajności i optymalizacji kosztów” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Cloud & IT Cert Prep, przejdź na CoddyKit PRO. Kurs Cloud & IT Cert Prep zawiera 4 lekcji w sumie.

Co nauczysz się w „Scenariusze wysokiej wydajności i optymalizacji kosztów”?

Odpowiadać na pytania scenariuszowe dotyczące strategii buforowania, optymalizacji zapytań jeziora danych, kompromisów Reserved i Spot oraz architektur replik odczytu. Ćwiczysz Cloud & IT Cert Prep z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć Cloud & IT Cert Prep?

Nie wymagamy żadnego doświadczenia. Cloud & IT Cert Prep w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 3 z 4.

Ile czasu zajmuje lekcja „Scenariusze wysokiej wydajności i optymalizacji kosztów”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji Cloud & IT Cert Prep?

Tak. Każda lekcja Cloud & IT Cert Prep zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

  1. Scenariusze bezpiecznych architektur
  2. Scenariusze odpornych i wysoce dostępnych architektur
  3. Scenariusze wysokiej wydajności i optymalizacji kosztów
  4. Pełny mini-egzamin z mieszanych domen
← Powrót do Cloud & IT Cert Prep