AWS CDK 101 - Flux Dynamodb déclenchant le lot deleteObjects S3

AWS CDK 101 – Flux Dynamodb déclenchant le lot deleteObjects S3

🔰 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, ajoutons une intégration simple utilisant des flux dynamodb pour effectuer des suppressions par lots d’objets dans S3 que nous avons créés dans nos articles précédents, et comprenons en quoi elle est plus performante qu’un seul appel d’objet de suppression S3.

Avantages dans cette approche 💦

Comme TTL dans dynamodb, nous avons des règles de cycle de vie qui vous permettent de supprimer les objets, mais cette approche illustrée ci-dessous est destinée à une architecture plus déterministe et événementielle où vous avez besoin d’un post-traitement lors du nettoyage de ces enregistrements.
Bien qu’un seul objet de suppression soit également bon, lorsque nous avons un grand nombre d’enregistrements les uns après les autres, cela créera trop d’appels d’API et de surcharge en latence.
Les objets de suppression par lots nous aident à réduire le nombre de demandes d’API externes.
Réduction des pertes d’heures de calcul dues aux E/S externes dans une instance de mémoire lourde pendant les temps d’inactivité.
Évitez d’être limité si nous avons atteint le débit défini pour le préfixe s3 à de très rares occasions
Et il est également possible que lambda expire si nous ne sommes pas prêts à l’augmenter
deleteObject ne fournit pas de réponse complète pour les buckets non versionnés, alors que deleteObjects fournit également une réponse soignée avec les erreurs.

Méthodes de cycle de vie du spoiler pour faire expirer automatiquement les éléments 🍁

Oui, tout comme TTL dans dynamodb, nous pourrions utiliser les méthodes de cycle de vie pour expirer automatiquement ou faire passer des objets vers d’autres classes de stockage dans s3. Mais bon, cette pensée est la meilleure stratégie à faire de cette manière. Chaque fois, nous finirons par avoir une fenêtre beaucoup plus longue qui est nécessaire et nous l’oublierons et nous nous attendrons à ce qu’elle se nettoie. Mais dans les deux derniers articles et celui-ci, nous essayons de notre mieux de configurer un moyen plus événementiel pour effectuer ce nettoyage une fois que nous avons fini de traiter le message.

Cela peut également être utilisé comme dernière option pour supprimer automatiquement certains artefacts orphelins après une période définie. Mais il a des objectifs différents et nous pourrons les couvrir peut-être dans un article ultérieur.

const stgMsgBucket = new s3.Bucket(this, 'stg-msg-bucket',{
      bucketName: envParams.bucket.BucketName,
      encryption: s3.BucketEncryption.S3_MANAGED,
      removalPolicy: RemovalPolicy.RETAIN,
      lifecycleRules: [{
        expiration: Duration.days(1),
        prefix: "uploads",
        id: "stg-msg-bucket-uploads-expiry-rule"
      }]
});

putItem renvoie également un lors de la création de l’objet ☎️

Activation des flux dynamodb dans notre table stgMessages 💽

Ce sera la table source censée générer les flux dynamodb. Mais la différence ici est que nous ne ciblerons que les flux générés lorsque des éléments sont supprimés. Nous allons donc essayer de supprimer le même élément clé des compartiments s3 que nous avons initialement créés.

const stgMessages = new dynamodb.Table(this, "stgMessagesTable", {
      tableName: process.env.stgMessagesTable,
      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,
});

Fonction de gestionnaire dans notre pile 📌

Ici, nous avons défini une fonction de gestionnaire que nous utiliserons dans notre référence pour accorder des privilèges et configurer la source de l’événement, comme indiqué ci-dessous.

const stgMessageStreamFunc = new lambda.Function(this, "stgMessageStreamFunc", {
      runtime: lambda.Runtime.NODEJS_14_X,
      code: lambda.Code.fromAsset("lambda"),
      handler: "stg-message-stream.deleted",
      logRetention: logs.RetentionDays.ONE_MONTH,
      tracing: Tracing.ACTIVE,
      layers: [nodejsUtils,nodejsXray],
      environment: {
        STAGING_MESSAGES_BUCKET_NAME: stgMsgBucket.bucketName,
      },  
});

stgMessageStreamFunc.applyRemovalPolicy(RemovalPolicy.DESTROY);

Accorder le privilège deleteObject à la fonction de gestionnaire 📯


stgMsgBucket.grantDelete(stgMessageStreamFunc);

Configuration de nos flux dynamodb en fonction de gestionnaire 🔧


stgMessageStreamFunc.addEventSource(new DynamoEventSource(stgMessages, {
      startingPosition: lambda.StartingPosition.LATEST,
      batchSize:100,
      maxBatchingWindow: Duration.seconds(60)
}))

Pour cela créons un nouveau fichier lambda/stg-message-stream.ts avec un nom de méthode d’exportation deleted

Notez que cela ne ciblera que les eventName comme REMOVE. Cela nous aidera avec les clés des éléments de table qui sont supprimés et nous pourrions les supprimer en utilisant notre gestionnaire comme suit de deux manières.

Gestionnaire de suppression d’objet unique 🎺

Ici, nous utiliserons d’abord la suppression d’un seul objet et le comparerons avec la suppression d’un objet par lots, comme indiqué ci-dessous.

exports.deleted = async function (event: any) {
  console.log("Received stream:", JSON.stringify(event, undefined, 2));
  const bucketName = process.env.STAGING_MESSAGES_BUCKET_NAME || "";
  const result = Promise.all(
    await event.Records.map(async (Record: DynamoDBStreams.Record) => {
      console.log(JSON.stringify(Record, undefined, 2));
      if (Record.eventName === "REMOVE") {
        const key = `uploads/${Record.dynamodb?.Keys?.messageId.S}.json`;
        console.log("keyId: ", key);
        const bucketParams: DeleteObjectRequest = {
          Bucket: bucketName,
          Key: key,
        };
        try {
          console.log("Deleting : ", bucketParams);
          const deleteObjectOutput: DeleteObjectOutput = await s3
            .deleteObject(bucketParams)
            .promise();
          console.log("Deleted : ", bucketParams);
          Object.entries(deleteObjectOutput).forEach((item) =>
            console.log({ item })
          );
          console.log(await s3.deleteObject(bucketParams).promise());
        } catch (err) {
          console.log("Error", err);
        }
      }
    })
  );
  Object.entries(result).forEach((item) => console.log({ item }));
};

Supprimez une seule transaction deleteObject 👜

Il ne faut pas plus d’une seconde pour supprimer l’objet s3 la plupart du temps, le fait que je veux souligner ici est la façon dont la surcharge est répartie entre les différentes couches.

Et cela devrait expliquer comment nous utilisons un lot de 100 flux maximum à traiter à partir du même gestionnaire. Les frais généraux sont simplement partagés et entièrement divulgués, nos couches de surveillance sont également intégrées en tant que couches et elles ont des frais généraux.

Enfin, découvrons la véritable répartition ci-dessous. Vous pouvez donc voir qu’il faut environ 50 ms à 300 ms pour terminer une seule demande d’API de suppression d’objet s3, comme indiqué ci-dessous.

Effets secondaires notables 🌂

Si nous ne les regroupons pas de manière appropriée, nous nous retrouverons dans les efforts négatifs ci-dessous et quelques objets peuvent être orphelins si nous ne réessayons pas.

perdre les heures de calcul en raison d’E/S externes
peut-être étranglé si nous avons atteint le débit défini pour le préfixe s3 en de rares occasions
Et il est également possible que lambda expire si nous ne sommes pas prêts à l’augmenter

Analyse du temps pris single delete 🍝

Vous pouvez constater que dans ces traces newrelic, la demande d’API est effectuée plusieurs fois l’une après l’autre.

Vous pouvez dire que je peux les faire en parallèle, nous finirons également par limiter la requête API au préfixe s3 lorsque nous créons trop de requêtes parallèles lorsque nous en exécutons plusieurs à la fois dans le pire des cas.

Gestionnaire de suppression d’objets par lots 🍝

Puisque nous sommes conscients des points ci-dessus, effectuons une demande par lots maintenant et voyons le redressement.


exports.deleted = async function (event: any) {
  console.log("Received stream:", JSON.stringify(event, undefined, 2));
  const bucketName = process.env.STAGING_MESSAGES_BUCKET_NAME || "";
  const keyMap: any[] = [];
  const result = Promise.all(
    await event.Records.map((Record: DynamoDBStreams.Record) => {
      console.log(JSON.stringify(Record, undefined, 2));
      if (Record.eventName === "REMOVE") {
        const key = `uploads/${Record.dynamodb?.Keys?.messageId.S}.json`;
        console.log("keyId: ", key);
        keyMap.push(key);
      }
    })
  );
  if (keyMap.length > 0) {
    const bulkParams: DeleteObjectsRequest = {
      Bucket: bucketName,
      Delete: {
        Objects: [],
        Quiet: false,
      },
    };
    keyMap.map((key) => {
      const object: ObjectIdentifier = {
        Key: key,
      };
      bulkParams.Delete?.Objects?.push(object);
    });
    try {
      console.log("Deleting Batch : ", bulkParams);
      const deleteObjectsOutput: DeleteObjectsOutput = await s3
        .deleteObjects(bulkParams)
        .promise();
      console.log("Deleted Batch : ", bulkParams);
      Object.entries(deleteObjectsOutput).forEach((item) =>
        console.log({ item })
      );
    } catch (err) {
      console.log("Error", err);
    }
  }
  Object.entries(result).forEach((item) => console.log({ item }));
};

Exemple de lot généré à partir de mon test k6 🚀

Ici, dans cet exemple, 26 éléments sont pris dans un seul lot. Mais notez que la taille de notre lot est de 100, mais il est également possible que nos articles fassent également partie de 2 séries successives, en fonction de la fenêtre d’interrogation que nous avons définie sur les années 60.

Analyse du temps pris pour une suppression unique ✈️

L’appel de suppression par lots S3 peut prendre plus de temps que la suppression unique, mais le point à noter ici sera que nous pouvons éviter la surcharge et la latence impliquées de manière exponentielle lorsque nous évoluons cela, disons jusqu’à 1000 objets.

Suppression des autres couches de surveillance entraînant des frais généraux

Ceci conclut cet article.

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 batch deleteObjects S3
@hashnode

En savoir plus sur ma pagehttps://t.co/CuYxnKI3Kg#TheHashnodeWriteathon #manuscrit #awscdk #aws #sans serveur #thwcloud-informatique https://t.co/3aoXjnp6lk

— Aravind V (@Aravind_V7) 21 mai 2022