Aurora Serverless RDS Multi-AZ: Архітектура баз даних

Вступ

Вибір правильної архітектури бази даних є критичним для продуктивності, масштабованості та економічної ефективності застосунку. AWS надає чотири основні сервіси баз даних, кожен оптимізований для різних випадків використання: Amazon RDS для керованих реляційних баз даних, Amazon Aurora для хмарної продуктивності, ElastiCache для кешування з субмілісекундними затримками та DynamoDB для безсерверного NoSQL масштабу.

Цей посібник досліджує архітектуру, конфігурацію та production шаблони для кожного сервісу. Ми розглянемо Multi-AZ розгортання RDS з автоматичним failover, архітектуру сховища Aurora та безсерверне масштабування, режими кластерів ElastiCache для Redis та Memcached, а також дизайн partition key DynamoDB з Global Secondary Indexes.

Серія AWS Developer Certification

📚 Переглянути повний посібник AWS Developer Certification - Опануйте всі 7 частин з нашим комплексним шляхом навчання.

Це Частина II (Поточна стаття) нашого комплексного 7-частинного посібника для AWS розробників:

1. Частина I: IAM EC2 та Auto Scaling
2. Частина II: RDS Aurora та DynamoDB (Поточна стаття)
3. Частина III: SQS SNS та Kinesis
4. Частина IV: Lambda API Gateway
5. Частина V: ECS Fargate та IaC
6. Частина VI: Cognito KMS Security
7. Частина VII: CodePipeline та Monitoring

← Частина I: IAM EC2 та Auto Scaling | Частина III: SQS SNS та Kinesis →

Amazon RDS (Relational Database Service)

Архітектура та режими розгортання RDS

RDS керує інфраструктурою реляційних баз даних — резервними копіями, патчингом, реплікацією та failover — поки ви контролюєте дизайн схеми та запити.

Опції розгортання:

Сховище та резервне копіювання RDS

Типи сховища:

Автоматичні резервні копії:

• Щоденні знімки під час вікна резервного копіювання
• Журнали транзакцій кожні 5 хвилин для point-in-time recovery (PITR)
• Утримання: 0-35 днів

Безпека:

• Шифрування: AES-256 через KMS (має бути увімкнено при створенні)
• Ізоляція мережі: Приватні підмережі, security groups
• IAM автентифікація БД: На основі токенів (15-хв валідність)

Amazon Aurora

Архітектура Aurora

Aurora відокремлює обчислення від сховища, забезпечуючи незалежне масштабування та failover менше ніж за 10 секунд.

Ключові функції:

1. 6-стороння реплікація через 3 AZ (може втратити 2 копії без впливу на запис)
2. Самовідновлювальне сховище - автоматичне виправлення дискових збоїв
3. Backtrack - перемотування БД назад без відновлення (тільки PostgreSQL)
4. Global Database - <1 секунди міжрегіональної реплікації
5. Aurora Serverless v2 - автомасштабування від 0.5 до 128 ACU

Aurora Serverless v2

resource "aws_rds_cluster" "aurora_serverless" {
  cluster_identifier = "aurora-serverless-cluster"
  engine             = "aurora-postgresql"
  engine_mode        = "provisioned"
  engine_version     = "15.4"
  database_name      = "myapp"

  serverlessv2_scaling_configuration {
    max_capacity = 16.0  # 16 ACUs = 32 GB RAM
    min_capacity = 0.5   # 0.5 ACU = 1 GB RAM
  }

  backup_retention_period = 7
  deletion_protection     = true
}

Коли використовувати:

• Змінні/непередбачувані робочі навантаження
• Dev/test середовища (зменшення масштабу в неробочі години)
• Мультитенантний SaaS (масштабування на тенанта)

Економія коштів: 60-80% проти provisioned для змінних навантажень

Amazon ElastiCache

Архітектура ElastiCache

ElastiCache надає керовані Redis та Memcached для кешування, сховища сесій та аналітики реального часу.

Redis vs Memcached

Стратегія кешування

Lazy Loading (Cache-Aside):

import redis
import json

redis_client = redis.Redis(
    host='redis-cluster.abc123.cfg.use1.cache.amazonaws.com',
    port=6379,
    ssl=True,
    password='auth-token',
    decode_responses=True
)

def get_user(user_id):
    cache_key = f"user:{user_id}"

    # Спочатку спробувати кеш
    cached_data = redis_client.get(cache_key)
    if cached_data:
        return json.loads(cached_data)

    # Промах кешу - витягнути з БД
    user = db.query("SELECT * FROM users WHERE id = %s", user_id)

    # Зберегти в кеші на 1 годину
    redis_client.setex(cache_key, 3600, json.dumps(user))
    return user

Найкращі практики TTL:

• Короткий TTL (60s): Дані, що часто змінюються (залишки на складі)
• Середній TTL (1 година): Напівстатичні дані (профілі користувачів)
• Довгий TTL (24 години): Рідко змінювані дані (категорії)
• Додайте jitter (±5 хв) для запобігання thundering herd

Amazon DynamoDB

Архітектура DynamoDB

DynamoDB — це повністю керована безсерверна NoSQL база даних з продуктивністю в односекундні мілісекунди.

Основні концепції:

• Partition Key (PK): Визначає розподіл даних
• Sort Key (SK): Опційний, дозволяє запити діапазону
• GSI: Альтернативні partition/sort keys для різних шаблонів запитів
• LSI: Альтернативний sort key (має бути визначений при створенні таблиці)

Приклад Single-Table дизайну

resource "aws_dynamodb_table" "ecommerce" {
  name         = "ecommerce-single-table"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "PK"
  range_key    = "SK"

  attribute {
    name = "PK"
    type = "S"
  }

  attribute {
    name = "SK"
    type = "S"
  }

  attribute {
    name = "GSI1PK"
    type = "S"
  }

  global_secondary_index {
    name            = "GSI1"
    hash_key        = "GSI1PK"
    projection_type = "ALL"
  }

  point_in_time_recovery {
    enabled = true
  }
}

Модель даних:

Приклади запитів:

import boto3
from boto3.dynamodb.conditions import Key

table = boto3.resource('dynamodb').Table('ecommerce-single-table')

# Отримати профіль користувача
response = table.get_item(Key={'PK': 'USER#123', 'SK': '#METADATA'})

# Отримати всі замовлення користувача
response = table.query(
    KeyConditionExpression=Key('PK').eq('USER#123') &
                          Key('SK').begins_with('ORDER#')
)

# Знайти користувача за email (використовуючи GSI)
response = table.query(
    IndexName='GSI1',
    KeyConditionExpression=Key('GSI1PK').eq('EMAIL#alice@example.com')
)

Режими потужності

Одиниці потужності:

• 1 WCU = 1 запис/сек елемента ≤1 KB
• 1 RCU = 1 строго консистентне читання/сек ≤4 KB (або 2 евентуально консистентних)

Production найкращі практики

Вибір бази даних

Критерії рішення:

• Реляційні дані + складні join'и → RDS PostgreSQL/MySQL або Aurora
• Екстремальна продуктивність + автомасштабування → Aurora Serverless v2
• Гнучка схема + прості запити → DynamoDB
• Субмілісекундне кешування → ElastiCache Redis
• Сховище сесій з персистентністю → ElastiCache Redis
• Простий кеш, багатопотоковий → ElastiCache Memcached

Оптимізація витрат

1. RDS: Reserved Instances (40% економії), gp3 сховище (30% дешевше ніж gp2)
2. Aurora: Serverless v2 для змінних навантажень (60-80% економії)
3. DynamoDB: On-Demand для стрибкоподібного трафіку, Provisioned для стабільних навантажень
4. ElastiCache: Правильний розмір вузлів на основі метрик використання пам'яті

Основи моніторингу

Критичні метрики для моніторингу:

RDS/Aurora:

• CPUUtilization (>70% протягом 5 хв)
• FreeableMemory (<1 GB)
• DatabaseConnections (>80% max)

ElastiCache:

• Evictions (ненульове = потрібно більше пам'яті)
• CacheHitRate (<80% = неефективний)

DynamoDB:

• UserErrors (throttling)
• ConsumedReadCapacityUnits/ConsumedWriteCapacityUnits

Поради для іспиту

Ключові концепції:

1. RDS Multi-AZ = HA (синхронний), Read Replicas = масштабування (асинхронний)
2. Aurora Global Database = <1 сек реплікація між регіонами
3. DynamoDB Partition Key має мати високу кардинальність (уникайте гарячих партицій)
4. ElastiCache Cluster Mode = горизонтальне масштабування з шардами

Поширені сценарії:

• "Потрібна субмілісекундна затримка" → ElastiCache або DynamoDB з DAX
• "БД має пережити збій AZ" → RDS Multi-AZ або Aurora
• "Глобальний застосунок, низька затримка" → Aurora Global Database або DynamoDB Global Tables
• "Непередбачуваний трафік" → DynamoDB On-Demand або Aurora Serverless

Складні граничні випадки:

• Шифрування RDS не можна увімкнути після створення
• DynamoDB LSI має бути створений при створенні таблиці, GSI можна додати пізніше
• Aurora backtrack доступний тільки для PostgreSQL
• ElastiCache Redis AUTH token потрібен для шифрування при передачі

Висновок

Сервіси баз даних AWS надають спеціалізовані рішення для різних шаблонів робочих навантажень. RDS спрощує керовані реляційні бази даних з Multi-AZ HA, Aurora забезпечує хмарну продуктивність з безсерверним масштабуванням, ElastiCache надає субмілісекундне кешування, а DynamoDB пропонує безсерверний NoSQL необмеженого масштабу.

Обирайте RDS для традиційних SQL навантажень, Aurora для екстремальних потреб у продуктивності, ElastiCache для прискорення застосунків з великою кількістю читань, та DynamoDB для застосунків інтернет-масштабу з гнучкими схемами. Розуміння архітектур розгортання, режимів потужності та стратегій оптимізації витрат є важливим як для production систем, так і для іспиту AWS Certified Developer Associate.

Часті запитання

П: Чим відрізняється RDS Multi-AZ від Read Replicas?

RDS Multi-AZ забезпечує високу доступність з синхронною реплікацією в резервний інстанс у іншій зоні доступності для автоматичного відновлення після відмови. Read Replicas використовують асинхронну реплікацію для масштабування читань і можуть знаходитися в різних регіонах. Multi-AZ для надійності, Read Replicas для продуктивності.

П: Коли використовувати Aurora замість RDS?

Aurora надає до 5x продуктивність MySQL та 3x PostgreSQL з автоматичним масштабуванням сховища до 128TB та read replicas з затримкою менше 10мс. Використовуйте Aurora для високих навантажень, що вимагають масштабування сховища, глобальних баз даних або безсерверної потужності. RDS економічніший для невеликих стабільних робочих навантажень.

П: Як працює партиційний ключ DynamoDB?

Партиційний ключ визначає розподіл даних по фізичних партиціях DynamoDB за допомогою внутрішньої хеш-функції. Обирайте висококардинальні значення (user_id, session_id) для рівномірного розподілу. Гарячі партиції через нерівномірні ключі спричиняють обмеження. Складені ключі (partition_key + sort_key) дозволяють виконувати запити по діапазонах в межах партиції.

П: В чому різниця між Redis та Memcached в ElastiCache?

Redis підтримує складні структури даних (списки, набори, відсортовані набори), персистентність, реплікацію та транзакції. Memcached є простішим багатопотоковим механізмом кешу пар ключ-значення без персистентності. Використовуйте Redis для складних типів даних, відмовостійкості або pub/sub, Memcached для простого кешування з мультикор горизонтальним масштабуванням.

П: Що таке DynamoDB Global Secondary Index (GSI)?

GSI дозволяють виконувати запити до DynamoDB за атрибутами, відмінними від основного ключа, створюючи альтернативний ключ партиції/сортування. GSI є асинхронними (eventual consistency), споживають окрему RCU/WCU, і можуть проєктувати тільки підмножину атрибутів. Створюйте GSI для шаблонів доступу, відмінних від основного ключа таблиці.

П: Як працює Aurora Serverless автомасштабування?

Aurora Serverless автоматично запускає, вимикає та масштабує потужність бази даних на основі попиту застосунку, виміряного в Aurora Capacity Units (ACU). Ви встановлюєте мінімальну та максимальну потужність ACU; Aurora масштабує в межах діапазону. Ідеально для непередбачуваних робочих навантажень або розробки/тестування з оплатою за секунду без простою інфраструктури.

П: Які найкращі практики оптимізації витрат для DynamoDB?

Використовуйте On-Demand режим для непередбачуваного трафіку, Provisioned з Auto Scaling для стабільних робочих навантажень. Увімкніть ТТЛ для автоматичного видалення застарілих даних. Використовуйте DynamoDB Streams натомість безперервного сканування. Зберігайте великі атрибути в S3 з посиланнями в DynamoDB. Зарезервуйте потужність для прогнозованих базових навантажень зі значними знижками.