AWS Solutions Architect · Урок

Сценарии высокой производительности и оптимизации затрат

Отвечайте на ситуационные вопросы о стратегиях кэширования, оптимизации запросов к озеру данных, выборе Reserved и Spot и архитектурах с репликами для чтения.

«Сценарии высокой производительности и оптимизации затрат» — бесплатный урок AWS Solutions Architect на CoddyKit. Это урок 3 из 4. Ты можешь прочитать весь урок бесплатно ниже — а потом практиковать его прямо в браузере с встроенным редактором кода и ИИ-репетитором 24/7. Это часть пути обучения AWS Solutions Architect, и твой прогресс синхронизируется между веб-версией и приложением CoddyKit. Курс AWS Solutions Architect содержит 4 уроков всего.

Сценарий 1: кэширование для снижения нагрузки на базу данных

Сценарий: База данных RDS MySQL новостного сайта обслуживает 90% операций чтения содержимого статей, которое изменяется не чаще одного раза в час. Средняя загрузка CPU базы данных составляет 80%, расходы растут, а задержка каждого запроса равна 200 мс. Решение: Добавьте кластер ElastiCache Redis перед RDS, используя шаблон ленивой загрузки (кэширования в обход). Приложение сначала проверяет кэш: при попадании в кэш возвращайте кэшированную статью менее чем за 1 мс. При промахе выполните запрос к RDS, верните результат и запишите его в кэш с TTL в 1 час. Ожидаемый результат: доля попаданий в кэш 90%, загрузка CPU RDS ниже 20%, задержка кэшированных ответов менее 5 мс.

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

Сценарий 2: CloudFront для доставки статических ресурсов

Сценарий: Пользователи в Азиатско-Тихоокеанском регионе загружают веб-приложение, размещённое на EC2 в us-east-1, за 2–4 секунды. Приложение обслуживает крупные статические ресурсы (изображения, JS, CSS). Решение: Разместите дистрибутив CloudFront перед ALB. Настройте поведение кэша для пути /static/* с длительным TTL (например, 1 неделя), чтобы статические файлы кэшировались в пограничных местоположениях CloudFront рядом с пользователями в Азии. Динамические запросы API обходят кэширование с TTL=0. Пользователи в Азии загружают статические ресурсы из пограничного местоположения в Сингапуре или Токио менее чем за 100 мс вместо ожидания обмена запросами с 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}
}'

Сценарий 3: подбор размера с помощью Compute Optimizer

Сценарий: Компания располагает 500 экземплярами EC2, многие из которых были выделены 3 года назад с большими типами экземпляров. Счёт AWS высок, но компания не знает, какие экземпляры имеют избыточную конфигурацию. Решение: Включите AWS Compute Optimizer (бесплатный сервис, использующий метрики CloudWatch за 14 дней). Compute Optimizer анализирует фактическую загрузку CPU, памяти, сети и диска каждого экземпляра и предоставляет рекомендации по подбору оптимального размера. Для экземпляра t3.xlarge со средней загрузкой CPU 8% будет рекомендовано уменьшение размера до t3.small. Применение рекомендаций для 500 экземпляров обычно снижает расходы на EC2 на 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

Сценарий 4: экземпляры Spot для пакетной обработки

Сценарий: Геномная компания каждую ночь запускает пакетные задания длительностью 8 часов, которые можно повторить после прерывания. Использование EC2 On-Demand для этих заданий обходится в 10 000 долларов в месяц. Решение: Используйте экземпляры EC2 Spot для парка пакетной обработки. Экземпляры Spot — это неиспользуемая ёмкость EC2, доступная со скидкой до 90%. Для пакетных заданий, устойчивых к прерываниям, используйте AWS Batch, который автоматически повторно ставит в очередь прерванные задания Spot и использует смешанный парк (Spot + минимальный резерв On-Demand). Ожидаемая экономия: снижение расходов на вычисления на 70–90% — с 10 000 до 1 000–3 000 долларов в месяц.

# 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

Сценарий 5: DynamoDB On-Demand для переменного трафика

Сценарий: Таблица лидеров игры использует DynamoDB с выделенной пропускной способностью. Во время запусков игр трафик возрастает в 50 раз, и таблица ограничивает запросы. Вне запусков пропускная способность почти не используется — выделенная ёмкость расходуется впустую. Решение: Переключите DynamoDB в режим ёмкости On-Demand. On-Demand мгновенно масштабируется до любой пропускной способности без ручного планирования ёмкости и взимает плату за запросы, а не за выделенные единицы. Вы платите только за выполненные запросы — между запусками нет расходов на простаивающую ёмкость. On-Demand предусматривает немного более высокую стоимость запроса, зато гарантирует отсутствие ограничений запросов и не требует управления ёмкостью.

# 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'

Сценарий 6: S3 Intelligent-Tiering для непредсказуемого доступа

Сценарий: Компания хранит миллионы изображений, созданных пользователями, в S3 Standard. Схемы доступа непредсказуемы: к одним изображениям обращаются ежедневно, к другим — не обращаются месяцами. Компания хочет снизить затраты на хранение, не управляя политиками жизненного цикла вручную. Решение: Использовать S3 Intelligent-Tiering. Сервис автоматически перемещает объекты между уровнями в зависимости от схем доступа: Frequent Access (Standard), Infrequent Access (30 и более дней без обращений), Archive Instant Access (90 и более дней) и Archive Access (90 и более дней, подключается по желанию). В Intelligent-Tiering плата за извлечение данных не взимается. Плата за мониторинг составляет $0.0025 за 1 000 объектов в месяц — для больших наборов данных это практически незаметная сумма.

# 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"
      }]
    }]
  }'

Сценарий 7: Компромисс между Athena и Redshift

Сценарий: Стартап хочет выполнять запросы к таблицам озера данных в S3. В неделю выполняется около 10 нерегулярных запросов. Поставщик предлагает Amazon Redshift с кластером dc2.large. Решение для стартапа: Начать с Amazon Athena: нулевая стоимость инфраструктуры, оплата только за просканированные данные (около $5/ТБ). Десять запросов в неделю к хорошо секционированным данным Parquet могут стоить менее $5 в месяц. Непрерывная работа Redshift dc2.large стоит около $180 в месяц. Redshift становится экономически выгодным только при высокой параллельности запросов (50 и более запросов в день) или необходимости получать ответы менее чем за секунду. Ключевые слова «нерегулярные запросы по требованию» однозначно указывают на 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

Сценарий 8: Выбор типа тома EBS

Сценарий: Серверу реляционной базы данных требуется 64 000 IOPS при стабильной низкой задержке. Текущий том gp3 EBS достиг предельного значения IOPS. Решение: Перейти на io2 Block Express (тип тома EBS, предназначенный для баз данных с интенсивными операциями ввода-вывода). io2 Block Express поддерживает до 256 000 IOPS на том и задержку менее миллисекунды. Он дороже gp3 ($0.125/ГБ + $0.065 за выделенный IOPS в месяц), но это единственный вариант EBS, отвечающий требованиям 64 000 и более IOPS. Для критичных к задержке нагрузок баз данных, где предельных 16 000 IOPS для gp3 недостаточно, io2 — единственный подходящий вариант 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

Сценарий 9: Reserved Instances для стабильных нагрузок

Сценарий: Компания непрерывно использует 20 экземпляров r6i.4xlarge EC2 для рабочего приложения и не ожидает изменения требований в течение 3 лет. Текущие расходы на экземпляры On-Demand составляют $80 000 в год. Решение: Приобрести 3-летние Standard Reserved Instances (или Compute Savings Plans) с оплатой All Upfront для получения максимальной скидки. Standard Reserved Instances дают скидку до 72% по сравнению с On-Demand. Экземпляры работают круглосуточно и без выходных при предсказуемой нагрузке — это классический случай для Reserved Instances. Ожидаемое снижение затрат: $80 000 × 0.72 = $22 400 в год вместо $80 000 в год за On-Demand, то есть экономия составит $57 600 в год.

# 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

Сценарий 10: Стоимость Lambda и EC2 при переменном трафике

Сценарий: Компания запускает REST API на экземпляре t3.micro EC2 стоимостью $8 в месяц. API получает 1 миллион запросов в месяц, каждый из которых обрабатывается за 100 мс. Команда спрашивает, будет ли Lambda дешевле. Анализ: Стоимость Lambda: 1 000 000 запросов × $0.0000002 = $0.20 (стоимость запросов) + 1 000 000 × 0.1 с × 128 МБ памяти × тариф = около $1.67 (стоимость вычислений) = около $1.87 в месяц. Для этого API с небольшим трафиком Lambda дешевле EC2. Когда трафик превысит примерно 40 миллионов запросов в месяц, EC2 станет дешевле. Используйте Lambda Cost Calculator, чтобы определить точку безубыточности для каждой нагрузки.

# 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)

Сценарий 11: Global Accelerator для динамических API

Сценарий: Глобальный API, обслуживающий пользователей в Европе, US и Азии, испытывает непостоянную задержку, поскольку трафик проходит по непредсказуемым маршрутам Интернета. Рассматривался CloudFront, но ответы API являются динамическими и не могут кэшироваться. Решение: Использовать AWS Global Accelerator. Он предоставляет глобально два статических anycast IP-адреса. Трафик пользователя входит в глобальную магистраль AWS через ближайшее пограничное расположение AWS и по частной сети AWS направляется к источнику в целевом Region, минуя перегруженный средний участок публичного Интернета. Global Accelerator сокращает время ответа динамического API на 20–60% и обеспечивает мгновенное переключение при сбое, если конечная точка Region становится недоступной.

# 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}]'

Быстрая проверка

Проверьте своё понимание концепций AWS Solutions Architect (SAA-C03) из этого урока.

Итоги урока

В этом уроке вы разобрали сценарии, охватывающие: ленивую загрузку ElastiCache для снижения загрузки CPU RDS с 80% до 20%, Spot Instances и AWS Batch для экономии 70–90% на пакетных заданиях, Athena для нерегулярных запросов по требованию и Redshift для аналитики с высокой параллельностью, а также S3 Intelligent-Tiering для непредсказуемых схем доступа без платы за извлечение данных. Далее вас ждёт итоговое испытание: небольшая смешанная по темам экзаменационная работа с ограничением времени, которая поможет оценить вашу готовность.

Часто задаваемые вопросы

Урок «Сценарии высокой производительности и оптимизации затрат» бесплатный?

Да — полный текст урока «Сценарии высокой производительности и оптимизации затрат» бесплатно доступен здесь в веб-версии. Чтобы практиковать его интерактивно (встроенный редактор кода и ИИ-репетитор 24/7) и разблокировать остальной курс AWS Solutions Architect, подпишись на CoddyKit PRO. Курс AWS Solutions Architect содержит 4 уроков всего.

Чему я научусь в уроке «Сценарии высокой производительности и оптимизации затрат»?

Отвечайте на ситуационные вопросы о стратегиях кэширования, оптимизации запросов к озеру данных, выборе Reserved и Spot и архитектурах с репликами для чтения. Ты практикуешь AWS Solutions Architect с помощью реального кода, который запускаешь прямо в браузере, и ИИ-репетитор 24/7 отвечает на твои вопросы во время урока.

Нужен ли мне опыт, чтобы начать AWS Solutions Architect?

Предыдущий опыт не требуется. AWS Solutions Architect на CoddyKit структурирован для всех уровней — от новичков до продвинутых, поэтому ты можешь начать отсюда или с самого начала и учиться в своем темпе. Это урок 3 из 4.

Сколько времени занимает урок «Сценарии высокой производительности и оптимизации затрат»?

Большинство уроков CoddyKit занимают около 5–10 минут. Каждый из них компактный и интерактивный, поэтому ты постоянно делаешь прогресс и продолжаешь с того же места в веб-версии и приложении.

Можно ли писать и запускать код в этом уроке AWS Solutions Architect?

Да. Каждый урок AWS Solutions Architect включает встроенный редактор кода, поэтому ты пишешь и запускаешь реальный код прямо в браузере и получаешь моментальную обратную связь от AI — локальная установка не требуется.

Все уроки этого курса

Сценарии безопасной архитектуры
Сценарии устойчивой архитектуры с высокой доступностью
Сценарии высокой производительности и оптимизации затрат
Полноценный мини-экзамен по всем разделам

← Назад к AWS Solutions Architect