AWS CDK 101 - Flux Dynamodb déclenchant un deleteItem par lot le jour

AWS CDK 101 – Flux Dynamodb déclenchant un deleteItem par lot le jour

🔰 Débutants qui découvrent AWS CDK, veuillez consulter mes articles précédents un par un dans cette série.

Si au cas où vous auriez manqué mon article précédent, retrouvez-le avec les liens ci-dessous.

🔁 Message précédent original sur 🔗 Dev Post

🔁 Republié le post précédent à 🔗 dev à @aravindvcyber

Dans cet article, affinons mon article précédent qui montrait l’utilisation d’un lot de flux dynamodb pour supprimer des éléments d’une autre table. Ici, nous convertissons la simple action deleteItem en une action batchWrite, ce qui présente de grands avantages.

Avantages dans cette approche 💦

Comme indiqué précédemment dans l’article précédent, nous essayons de rendre cette configuration de nettoyage aussi efficace que possible.
Cette intégration est entièrement asynchrone et ne bloque pas le flux de processus existant, et elle utilise le moins d’appels d’API et de ressources, comme indiqué ci-dessous.
Impliquer batchWrite nous fait effectuer une opération de suppression sur une taille de bloc maximale de 25.
Étant donné qu’une seule demande est utilisée à la place de 25 appels, les scénarios de limitation des demandes d’écriture peuvent également être évités lorsque nous avons des capacités provisionnées plus petites.
D’ici là, vous devez également vérifier le UnprocessedItems pour réessayer toutes les clés ayant échoué si elles sont renvoyées dans le pire des cas.
Dans un résumé incluant l’article précédent, nous sommes maintenant en mesure d’effectuer un batch get stream object avec une taille de 100 max qui à son tour effectue une écriture batch de 25 max à la fois.
Moins d’invocations de gestionnaire et moins d’appels d’API dynamodb.

Planification et construction 🚣

Comme déjà mentionné, nous allons optimiser le précédent deleteItem fonction d’assistance et convertir notre invocation de flux en une action batchWrite sur la table dynamodb avec des morceaux de 25 max.

En commençant par réfracteur mon précédent lambda un peu pour atteindre les objectifs d’optimisation des effets souhaités.

Ici, vous constaterez peut-être que nous ciblons un nom d’événement à INSERTde même, nous pouvons avoir un contrôle plus précis sur le résultat souhaité lors de ces appels de flux, comme indiqué ci-dessous.

Importations nécessaires 💮

Les importations ci-dessous sont utilisées dans cet article.

import { DynamoDBStreams } from "aws-sdk";
import {
  DeleteItemInput,
  BatchWriteItemInput,
  WriteRequest,
} from "aws-sdk/clients/dynamodb";

Nouvelle logique de fonction de gestionnaire ⚓️

Ici, nous avons optimisé le gestionnaire lambda comme suit, cela implique la création d’un keyMap à partir des données de flux, et en les découpant davantage en morceaux d’un maximum de 25 pour effectuer batchWrite opération invoquant notre méthode d’assistance.

exports.created = async function (event: any) {
  console.log("Received stream:", JSON.stringify(event, undefined, 2));

  const keyMap: any[] = [];
  event.Records.map((Record: DynamoDBStreams.Record) => {
    console.log(JSON.stringify(Record, undefined, 2));
    if (Record.eventName === "INSERT") {
      keyMap.push(Record.dynamodb?.Keys);
    }
  });

  const chunkList = [...chunks(keyMap, 25)];
  await Promise.all(
    chunkList.map(async (chunk: any[]) => {
      const results = await batchDeleteDbItems(chunk);
      Object.entries(results).forEach((entry) => {
        console.log(JSON.stringify(entry, undefined, 2));
      });
    })
  );
};

Fonction d’assistance dynamodb deleteItem 💐

Fonction d’assistance simple pour effectuer deleteItem à partir d’une table dynamodb.

Ici, nous utilisons la liste de clés pour générer une collection de WriteRequest de Delete agir comme suit.

const batchDeleteDbItems: any = async (keys: any) => {
  console.log("Deleting: ", { keys });

  const writeItems: WriteRequest[] = [];
  keys.map((key: any) => {
    const writeItem: WriteRequest = {
      DeleteRequest: {
        Key: {
          ...key,
        },
      },
    };
    writeItems.push(writeItem);
  });
  const params: BatchWriteItemInput = {
    RequestItems: {
      stgMessagesTable: writeItems,
    },
    ReturnConsumedCapacity: "TOTAL",
    ReturnItemCollectionMetrics: "SIZE",
  };

  console.log("deleteItem: ", JSON.stringify(params, undefined, 2));

  return await dynamo.batchWriteItem(params).promise();
};

Modifications mineures de la définition de la table dynamodb 🍊

J’ai mis en évidence les changements nécessaires, nous devons effectuer la génération de flux dynamodb pour notre table.

Plus important encore, je n’ai demandé que des clés, qui contiendront toutes les données nécessaires dont nous avons besoin ici.

D’ailleurs dans cet article, nous essayons d’optimiser autant que possible pour le moins d’encombrement.

const messages = new dynamodb.Table(this, "MessagesTable", {
      tableName: process.env.messagesTable,
      sortKey: { name: "createdAt", type: dynamodb.AttributeType.NUMBER },
      partitionKey: { name: "messageId", type: dynamodb.AttributeType.STRING },
      encryption: dynamodb.TableEncryption.AWS_MANAGED,
      readCapacity: 5,
      writeCapacity: 5,
      stream: dynamodb.StreamViewType.KEYS_ONLY
});

Exemple de flux dynamodb avec un enregistrement 🥣

J’ai partagé l’objet de flux dynamodb utilisé comme charge utile pour appeler notre gestionnaire lambda ci-dessous.

{
  "eventID": "961320567faf6d890d6498a08fd1f34c",
  "eventName": "INSERT",
  "eventVersion": "1.1",
  "eventSource": "aws:dynamodb",
  "awsRegion": "ap-south-1",
  "dynamodb": {
    "ApproximateCreationDateTime": 1652637075,
    "Keys": {
      "createdAt": {
        "N": "1652637067000"
      },
      "messageId": {
        "S": "615f1e20-8261-4492-bb69-c281d3ea3382"
      }
    },
    "SequenceNumber": "36634400000000018872472773",
    "SizeBytes": 61,
    "StreamViewType": "KEYS_ONLY"
  },
  "eventSourceARN": "arn:aws:dynamodb:ap-south-1:57*****7078*****55:table/MessagesTable/stream/2022-05-15T17:48:27.902"
}

Journal de la console pendant l’exécution 🍿

Enfin, après l’exécution, nous pourrions trouver la charge utile JSON ci-dessus que nous avons reçue dans le event objet et qui est ensuite utilisé pour supprimer par lots de notre table intermédiaire. Vous pouvez trouver les résultats ci-dessous dans les journaux de surveillance du cloud.

Ici, un simple test de charge k6 est effectué pendant une période de 15s avec 10 cibles et nous pouvons obtenir 27 requêtes dont 25 sont réussies. les 2 ont échoué en raison de la limite de débit de notre passerelle API.

Journaux Cloudwatch avec 25 enregistrements de clés ⛲️

Résultat BatchWrite ⛲️

Visualisation de la latence impliquée 🚁

Ici, nous prenons en compte 25 puts réussis, 25 requêtes get et un seul lot supprime des fonctions de gestionnaire distinctes. Bien que chaque demande soit d’un type différent, le facteur commun impliqué dans l’utilisation des appels d’API dynamodb sur le réseau est l’endroit où il y a d’autres frais généraux comme la latence.

Requêtes PutItem

Demandes GetItem

Demandes de suppression d’éléments par lots

Ainsi batchWrite ou batchGet est beaucoup plus efficace en évitant la latence, et nous avons donc essayé batchWrite pour la suppression des données indésirables. Quant à nous, j’apprends que 25 est la limite maximale pour la collection de requêtes d’écriture par lots.

Aussi, il est indispensable de vérifierUnprocessedItems dans le résultat de l’opération batchWrite peut être inspecté et il est recommandé de vérifier et de réessayer l’échec une fois, lorsque nous avons des exceptions dues à la capacité ou d’autres échecs dus à la taille du message.

Dans le prochain article, nous montrerons comment nous utiliserons une approche similaire pour supprimer l’objet de S3, que nous avons précédemment créé.

Nous ajouterons plus de connexions à notre pile et la rendrons plus utilisable dans les prochains articles en créant de nouvelles constructions, alors pensez à suivre et à vous abonner à ma newsletter.

⏭ Nous avons notre prochain article en serverless, consultez

🎉 Merci pour votre soutien ! 🙏

Ce serait formidable si vous aimez ☕ Achetez-moi un café, pour aider à stimuler mes efforts.

🔁 Message original sur 🔗 Dev Post

🔁 Republié à 🔗 dev à @aravindvcyber

🌺 AWS CDK 101 – 🚂 Flux Dynamodb déclenchant un batch deleteItem sur une autre table dynamodb @hashnode

En savoir plus sur ma pagehttps://t.co/CuYxnKr0Ig#TheHashnodeWriteathon #aws #awscdk #dynamodb #manuscrit #thwcloud-informatique https://t.co/b3sOi0UmBu

— Aravind V (@Aravind_V7) 15 mai 2022