Добавление кэша для поиска товаров

Введение

Приложение читает каталог из DynamoDB при каждом запросе. Добавьте узел Amazon ElastiCache с Valkey, чтобы повторно использовать данные товара. Докажите результат по источнику ответа и реальному числу обращений к базе.

Сначала пройдите AWS Foundations for Beginners и базовые операции с элементами в AWS DynamoDB for Beginners. Эта независимая среда предоставляет приложение, каталог и сеть. Выполняйте команды в Terminal, наблюдайте узел, записи и ответы в AWS View. AWS CLI уже настроен; личный аккаунт и ресурсы предыдущих работ не нужны.

Связь с сертификацией

Сертификация	Задача экзамена	Практика
Cloud Practitioner (CLF-C02)	Task 3.4	Отличать кэш в памяти от достоверных исходных данных и наблюдать поведение приложения.

Концептуальная схема лабораторной работы

Наблюдение за источником товаров

Кэш хранит повторно используемые данные в памяти. База остаётся источником достоверных данных: потеря копии в кэше не должна удалять запись каталога. Сначала изучите приложение без кэша.

Перейдите в каталог проекта и подтвердите настроенную идентификацию:

cd /home/labex/project
aws sts \
  get-caller-identity

ARN оканчивается на labex-ca01-operator и обозначает эту среду. Прочитайте товар 101 прямо из DynamoDB. S обозначает строки, N — числа:

aws dynamodb \
  get-item \
  --table-name product-catalog \
  --key '{"product_id":{"S":"101"}}' \
  --consistent-read

Travel mug стоит 20.00. Независимый товар 202, Notebook, должен остаться неизменным. HTTP-приложение возвращает JSON товара. Запросите его дважды:

curl -sS http://127.0.0.1:8080/api/products/101
curl -sS http://127.0.0.1:8080/api/products/101

Оба ответа содержат "served_from":"source". В AWS View счётчик чтений увеличился на два, а карточка ElastiCache пока не содержит кластера. Чтение означает реальный запрос к DynamoDB, а не измеренную стоимость AWS. Send request также отправляет настоящий запрос и может изменить счётчик. Сравнивайте его изменение, а не фиксированное итоговое значение. Пример AWS View до кэширования: запросы читают источник. Ваш счётчик может отличаться.

Создание узла Valkey

Amazon ElastiCache управляет механизмами кэширования в памяти. Valkey хранит значения по ключу; здесь ID товара определяет его копию. Используется один автономный узел. Предоставленная группа подсетей задаёт подготовленное размещение, а группа безопасности — сетевую конфигурацию. Проектирование правил рассматривается в курсе VPC.

Прочитайте сетевые идентификаторы этой новой среды:

cat resources.json

Сохраните и выведите ID группы безопасности. $(...) сохраняет вывод команды для следующей операции:

CACHE_GROUP_ID=$(jq -r .security_group_id resources.json)
echo "$CACHE_GROUP_ID"

Создайте небольшой кэш из одного узла с идентификатором product-cache. Механизм и количество узлов выбирают конфигурацию Valkey этого курса:

aws elasticache \
  create-cache-cluster \
  --cache-cluster-id product-cache \
  --engine valkey \
  --engine-version 7.2 \
  --cache-node-type cache.t3.micro \
  --num-cache-nodes 1 \
  --cache-subnet-group-name product-cache-network \
  --security-group-ids "$CACHE_GROUP_ID"

Наблюдайте CacheClusterStatus и запросите endpoint — адрес и порт подключения:

aws elasticache \
  describe-cache-clusters \
  --cache-cluster-id product-cache \
  --show-cache-node-info \
  --query 'CacheClusters[0].{Status:CacheClusterStatus,Nodes:CacheNodes}'

Продолжайте, когда кластер имеет статус available, а узел 0001 — endpoint. Если создание продолжается, немного подождите и повторите запрос. Сохраните и выведите реальный адрес:

CACHE_HOST=$(aws elasticache \
  describe-cache-clusters \
  --cache-cluster-id product-cache \
  --show-cache-node-info \
  --query 'CacheClusters[0].CacheNodes[0].Endpoint.Address' \
  --output text)
echo "$CACHE_HOST"

Проверьте соединение предоставленным клиентом Valkey:

valkey-cli -h "$CACHE_HOST" -p 6379 PING

PONG доказывает ответ механизма кэша, но пока не его использование приложением. AWS View показывает реальный узел и endpoint.

Подключение приложения и попадание в кэш

При cache-aside приложение сначала ищет product:101 в кэше. Отсутствующий ключ — промах: приложение читает DynamoDB и сохраняет товар. Последующее попадание возвращает копию без нового чтения базы.

app.json содержит обычные настройки. Измените режим и endpoint через jq, запишите временный файл и замените конфигурацию:

jq --arg host "$CACHE_HOST" \
  '.mode = "cache-aside" | .cache_host = $host' \
  app.json > app.next.json
mv app.next.json app.json

Проверьте новые настройки:

cat app.json

Они перечитываются при каждом запросе, перезапуск не нужен. ttl_seconds — срок жизни копии; следующая работа рассматривает истечение и актуальность. Запросите товар один раз:

curl -sS http://127.0.0.1:8080/api/products/101

Первый ответ содержит served_from: source, поскольку новый кэш пуст. Посмотрите счётчик в AWS View и повторите:

curl -sS http://127.0.0.1:8080/api/products/101

Теперь ответ содержит served_from: cache с теми же ID, названием и ценой; счётчик не растёт. Если AWS View уже запрашивал товар, первый запрос Terminal может попасть в кэш. Сравнивайте последовательные запросы после заполнения. Прочитайте реально сохранённое значение:

valkey-cli -h "$CACHE_HOST" -p 6379 GET product:101

JSON соответствует записи Travel mug. Это доказывает сокращение обращений к базе при повторных запросах, но не производственные задержки, ёмкость или доступность. Оставьте приложение и узел для проверки. Учебная среда временная; в настоящем аккаунте AWS удаляйте ненужные кэши, чтобы прекратить дальнейшие расходы. Пример AWS View после подключения: кэш возвращает ту же цену без нового чтения источника.

Итоги

Вы создали узел Valkey, подключили приложение и наблюдали промахи и попадания cache-aside. Копия совпадает с достоверными данными DynamoDB, а попадания обходятся без повторного чтения. Далее изучите актуальность с TTL и явной инвалидацией.

Подробнее см. в документации AWS: Поток данных cache-aside; Выбор конечной точки подключения к кэшу.