AWS, Cloudflare, Vercel, Supabase, headless CMS : qu'est-ce qui persiste ?
Bonjour, je suis Otsuka, CTO chez Liberogic.
Dans l'article précédent, nous avons clarifié les différences entre les journaux d'accès, les journaux d'application et les journaux d'audit.
Cette fois, nous examinerons plus concrètement quels types de journaux sont disponibles dans les services que nous utilisons régulièrement : AWS, Cloudflare, Vercel, Supabase et headless CMS.
Il ne s'agit pas de faire une comparaison détaillée des tarifs et des fonctionnalités de chaque service.
Chaque service a des caractéristiques très différentes en termes de ce qui est conservé « par défaut » et de ce qu'on peut « vérifier ultérieurement ». Nous allons clarifier ces points de manière générale.
Services | Journaux principalement disponibles | Approche de la conservation à long terme | Points à noter |
|---|---|---|---|
AWS | Exécution, accès, opérations de gestion | Combiner CloudWatch et S3 | Configuration requise par service |
Cloudflare | Exécution des Workers, exceptions, etc. | Transfert vers R2 ou services externes | La distribution statique est distincte des journaux d'exécution |
Vercel | Functions, déploiement, journaux d'exécution | Transfert externe via Log Drains, etc. | La plage de conservation dépend de votre plan |
Supabase | Base de données, API, authentification, opérations d'administration | Transfert externe via Log Drains, etc. | Les opérations spécifiques à l'application nécessitent une implémentation distincte |
Headless CMS | Mise à jour de contenu, opérations de gestion | Utilisation de l'historique et des fonctionnalités d'audit du service | Les opérations ciblées et les plans diffèrent |
Datadog／Sentry | Journaux consolidés, informations d'erreur | Conçu en fonction de l'utilisation et du volume de stockage | La simple implémentation ne suffit pas pour un journal d'audit |
Même avec la même « fonctionnalité de journalisation », les opérations ciblées et les périodes de conservation diffèrent.
De plus, le fait qu'une information soit affichée sur l'écran d'administration et le fait qu'elle soit conservée à long terme à des fins d'audit sont deux choses différentes.
AWS dispose de tous les outils nécessaires, mais une configuration est requise
AWS offre une gamme complète de services liés à la journalisation.
Par exemple, les journaux d'exécution de services comme Lambda ou API Gateway sont collectés dans CloudWatch Logs. Les opérations effectuées via la console de gestion AWS ou l'API sont enregistrées dans CloudTrail.
En résumé,
- CloudWatch Logs : consulter le fonctionnement des applications et services AWS
- CloudTrail : voir qui a fait quoi dans votre environnement AWS
- S3 : conserver les journaux à long terme
telle est la répartition des rôles.
Puisque la recherche, la surveillance, les notifications et la conservation à long terme peuvent être assemblées au sein d'AWS, cette architecture s'adapte facilement aux systèmes soumis à des exigences d'audit strictes.
Cependant, il n'est pas vrai que « tout est automatiquement conservé parce que vous utilisez AWS ».
Vous devez configurer l'enregistrement des journaux pour chaque service utilisé et déterminer la période de conservation et la destination du stockage. Étant donné cette flexibilité, une conception appropriée est essentielle.
Cloudflare sépare les investigations à court terme de la sauvegarde externe
Avec Cloudflare Workers, vous pouvez consulter le contenu produit par console.log() et les erreurs dans Workers Logs.
C'est très pratique pour vérifier le développement en cours ou enquêter sur les problèmes récents, mais pour conserver un audit à long terme, il est préférable de ne pas se limiter à l'écran de journal standard.
Pour les journaux nécessitant une conservation à long terme, nous envisageons une architecture qui envoie les données vers R2 ou des services externes de gestion des journaux en utilisant Logpush.
De plus, lorsqu'un site Web statique est servi via Cloudflare Pages ou Workers, tous les accès ne sont pas nécessairement enregistrés dans les journaux d'exécution de Worker.
Le site s'affiche normalement, il est facile de penser « bien sûr, il y aura aussi des journaux d'accès », mais la distribution de fichiers statiques et l'exécution de Worker sont deux choses différentes.
Bien que Cloudflare rend relativement facile la création d'une architecture compacte, il est nécessaire de comprendre quels traitements passent où pour concevoir les journaux en conséquence.
Vercel facilite la vérification des journaux Next.js
Avec Vercel, vous pouvez consulter les journaux générés par les Functions et Server Actions de Next.js directement depuis le tableau de bord.
Comme le déploiement et les journaux d'exécution sont au même endroit, c'est facile à comprendre pour les développeurs et l'environnement facilite les enquêtes quotidiennes sur les erreurs.
En revanche, la période pendant laquelle vous pouvez consulter les journaux et la portée du transfert externe dépendent de votre plan.
Si vous souhaitez conserver les journaux pendant une longue période, vous devez mettre en place un mécanisme distinct, comme l'utilisation de Drains pour envoyer les données vers une destination de stockage externe.
Chez Vercel comme ailleurs, l'affichage des logs dans la console d'administration et leur conservation à long terme à des fins d'audit sont deux choses différentes.
Il est nécessaire de vérifier ces deux éléments séparément.
Supabase génère de nombreux logs au-delà du simple stockage de données
Supabase est un service centré sur PostgreSQL, mais il comprend en réalité bien plus qu'une simple base de données : l'authentification, l'API, le stockage, les Edge Functions et d'autres fonctionnalités.
Comme chacun de ces logs est accessible depuis la console d'administration, il est facile de suivre l'ensemble du comportement de l'application.
Il existe également des logs d'authentification et des logs d'audit pour suivre les opérations effectuées dans la console d'administration de Supabase.
Cependant, il est important de noter ici aussi que les opérations d'administration de Supabase et les opérations au sein de votre application sont deux choses distinctes.
Par exemple, bien que Supabase puisse enregistrer « qui a modifié les paramètres du projet Supabase », votre application doit enregistrer de son côté « qui a modifié les informations clients dans votre console d'administration ».
Vérifier l'historique des opérations du headless CMS
Les headless CMS comme microCMS, Kuroco et NILTO offrent l'historique des mises à jour de contenu et les logs des opérations de la console d'administration.
Les enregistrements de qui a mis à jour un article, quand il a été publié, ou quand des paramètres et permissions ont été modifiés sont importants en tant que journaux d'audit pour la gestion de sites web.
Cependant, les opérations enregistrées, la période vérifiable et les forfaits disponibles varient selon le service.
Bien qu'il soit possible de vérifier l'historique des mises à jour de contenu, toutes les opérations d'administration ne sont pas nécessairement conservées en tant que journaux d'audit.
De plus, le CMS enregistre fondamentalement les opérations internes du CMS. Les accès au site web publié et les erreurs qui se produisent côté frontend doivent être vérifiés dans l'environnement d'hébergement.
Dans les projets de headless CMS, il est plus clair de considérer le CMS, le frontend, l'hébergement et l'API comme un seul système.
Lors de l'ajout de Datadog ou Sentry
Si les journaux sont dispersés sur plusieurs services, chaque défaillance nécessite d'ouvrir chaque interface d'administration pour enquêter.
Consolider les journaux dans un service de gestion des journaux comme Datadog permet de rechercher les journaux de plusieurs environnements ensemble et de détecter et signaler les anomalies.
Sentry est également très utilisé, mais ce service excelle à identifier l'emplacement et la portée des erreurs.
Les deux sont pratiques, mais leur implémentation ne garantit pas automatiquement un journal d'audit complet.
L'application doit déterminer ce qu'elle enregistre, et conserver tous les journaux à long terme augmente les coûts en fonction du volume de données.
Méthode de stockage | Cas d'utilisation appropriés | Caractéristiques |
|---|---|---|
Console d'administration · Service de gestion des journaux | Investigations d'incidents quotidiennes | Recherche rapide possible, mais les coûts augmentent avec le volume de stockage |
Stockage type R2 ou S3 | Archivage à long terme pour audits et traçabilité | Économique à conserver, mais nécessite une extraction lors des investigations |
En pratique, il est judicieux de séparer les journaux que vous consultez régulièrement de ceux que vous conservez pour la prévention.
Impossible de déterminer quel service est le meilleur
On ne peut pas conclure qu'AWS ou Cloudflare est le meilleur en comparant uniquement les journaux.
Ce qui importe, c'est de déterminer ce qui doit être enregistré pour votre projet.
- Enquêter sur les erreurs de service
- Conserver l'historique des actions administrateur
- Vérifier l'historique des mises à jour du CMS
- Suivre les modifications d'authentification et de permissions
- Conserver les données à long terme à des fins d'audit
Une fois que vous savez ce dont vous avez besoin, vous pouvez identifier les fonctionnalités standard de chaque service qui peuvent répondre à vos besoins et les domaines qui nécessitent des mécanismes supplémentaires.
Nous non plus, nous ne mettons pas en place une infrastructure de journalisation de grande taille dès le départ. Nous concevons la configuration en fonction des besoins et du budget du projet.
La prochaine fois, nous verrons comment, lorsque ces services sont combinés, l'application génère les journaux appropriés et les stocke au bon endroit. Nous nous concentrerons sur des aspects plus proches de la pratique réelle.
Bon, à bientôt.
Le pilier du département technique de Liberogic. Dès qu'il entend « J'aimerais bien avoir ça, ce serait pratique », il se met au travail avec sa créativité naturelle et ajoute de la valeur en un rien de temps. Avec ses excellentes compétences en communication et ses nombreux fans parmi nos clients, c'est un trésor de l'entreprise — et passionné par les chats.
Shō Ōtsuka
Directeur technique / Ingénieur en chef / Représentant de Neko-Ana LLC / Étonnamment jeune d'apparence