Хранилище и базы данных — Примеры

Пример 1 — Хранилище сессий на объектном хранилище

Веб-приложение хранит сессию каждого пользователя как объект, перезаписываемый после каждого запроса. Записи небольшие, ключевые и частые, и два запроса в полёте могут перезаписать друг друга. Ниже — развёрнутое объявление. Замените его хранилищем, чей шаблон доступа соответствует небольшим обновлениям по ключу, и скажите, что происходит с читателями во время отказа.

resource "aws_s3_bucket" "sessions" {
  bucket = "<session-store-name>"
  # каждое изменение сессии перезаписывает объект целиком
}

Решение

resource "aws_db_instance" "sessions" {
  identifier     = "<session-store-id>"
  engine         = "<engine>"
  instance_class = "db.t3.small" # иллюстративно
  multi_az       = true
}

Сессии — это случайные небольшие чтения и записи по ключу пользователя, а именно под такой шаблон и построена база данных; объектное хранилище — пространство имён целых блобов, поэтому переименование или правка одного перезаписывает весь объект, и нет обновления на месте, чтобы сериализовать двух писателей. Резервный узел отвечает на чтения во время отказа, а это отдельное обещание от долговечности байтов. Обычная ошибка — обращаться с объектным хранилищем как с файловой системой, потому что оно дешёвое и уже есть.

Пример 2 — Резервная копия, которую никто не восстанавливал

Ночная задача копирует дамп базы в объектное хранилище со сроком действия тридцать дней, и никто ни разу не читал его обратно; процедура восстановления существует только как документ. Измените устройство так, чтобы сохранённая копия была заведомо читаемой, и скажите, чего стоит хранение, когда копию читают часто.

resource "aws_s3_bucket_lifecycle_configuration" "backups" {
  rule {
    id     = "expire-old-backups"
    status = "Enabled"
    expiration { days = 30 }
  }
  # версионирование выключено: перезапись заменяет единственную копию
}

Решение

# ежемесячная тренировка, выполняется против сохранённой копии, а не живого дампа
copy <retained-object> <drill-path>
list <drill-path>          # байты, права и ключ должны сработать все
restore <drill-database> --source <drill-path>
# оставьте две версии с более долгим сроком, затем прочитайте восстановленные строки

Резервная копия, которую никогда не восстанавливали, — это надежда: ключи шифрования, права и процедура должны сработать в момент, когда они понадобятся, и именно тренировка это доказывает. Хранение дёшево за гигабайт, а извлечение и передача — нет, поэтому копия, которую читают каждый месяц, относится к классу, который этого ожидает. Обычная ошибка — предполагать, что копия есть, раз её снял сервис.