Le problème : le trafic média écrase l'origine
Quand les photos produit, les vidéos de couverture, les PDF et les uploads utilisateurs se trouvent sur le même serveur qui rend vos pages, chaque requête d'image entre en concurrence avec le vrai travail applicatif pour le CPU, les I/O disque et la bande passante. Une seule page populaire avec trente images multiplie le trafic par trente contre une origine unique, et un pic de trafic ou un gros téléchargement vidéo peut priver l'application des ressources dont elle a besoin pour répondre. Le stockage sur un serveur applicatif est aussi difficile à faire évoluer : vous finissez par manquer de disque, et les sauvegardes d'un système de fichiers volumineux deviennent lentes et fragiles. Séparer les octets de la logique est la première correction structurelle, et c'est ce que délivre ce scénario.
Comment cdn.com.tr résout ce problème : buckets plus cache edge
Vous stockez chaque fichier dans un bucket Object Storage compatible S3, ce qui vous offre une capacité pratiquement élastique et un endpoint que vos applications utilisent avec les outils S3 standard. Devant ce bucket, vous placez le CDN de cdn.com.tr, si bien que la diffusion réelle vers les navigateurs se fait depuis les sites edge, pas depuis le bucket et jamais depuis votre serveur applicatif. La première requête pour un fichier remplit le cache edge ; chaque requête suivante pour ce fichier est servie depuis l'edge sans retoucher l'Object Storage. Résultat : votre origine gère presque aucun trafic d'octets, votre couche de stockage évolue indépendamment du calcul, et les utilisateurs récupèrent les fichiers depuis un nœud edge proche plutôt que depuis un unique serveur distant.
Access keys, fichiers publics et fichiers privés
Chaque bucket est contrôlé par des paires access key et secret que vous créez, renouvelez et révoquez depuis le panel. Pour les médias publics comme les images de catalogue, diffusez via le domaine CDN et gardez le endpoint brut du bucket hors de votre code. Pour les contenus privés comme les téléchargements payants ou les sauvegardes internes, gardez les objets non publics et distribuez des URLs signées à courte durée de vie générées avec l'access key, afin qu'un lien expire au lieu de rester valide indéfiniment. Comme chaque intégration a sa propre clé, un outil d'upload compromis ou un prestataire qui part se règle par une révocation en un clic plutôt que par une réinitialisation de mot de passe à l'échelle de la plateforme.
Cache-control et purge sans s'auto-empoisonner le cache
Le cache n'est efficace que si les en-têtes définis sur vos objets le sont aussi. Donnez aux fichiers versionnés et durables un Cache-Control lointain avec immutable, et donnez aux fichiers qui changent réellement souvent un TTL plus court. Le schéma le plus propre reste les noms de fichiers hachés par contenu : quand une image change, son URL change, donc l'edge sert naturellement le nouveau fichier et vous ne luttez jamais contre un cache périmé. Quand vous devez écraser un fichier à la même URL — un changement de logo, un PDF corrigé — une purge ciblée depuis le panel ou cdnctl retire cet objet de tous les sites edge afin que la prochaine requête le retire du bucket. Cela garde les invalidations rares, précises et sûres.
Passer de quelques images à une bibliothèque média complète
La même configuration qui sert une poignée de logos passe à l'échelle pour un catalogue de centaines de milliers de photos produit, une bibliothèque de vidéo à la demande ou une archive tournante de sauvegardes nocturnes, car l'Object Storage grandit sans que vous ayez à provisionner des disques et l'edge absorbe le trafic de lecture. Les sites riches en médias voient les gains les plus nets : les pages deviennent plus légères et plus rapides à mesure que les images sont diffusées depuis des sites edge proches, et la bande passante d'origine — souvent la ressource la plus coûteuse et la plus fragile — chute nettement. Les sauvegardes trouvent aussi un logement propre, isolées dans leur propre bucket privé avec leur propre access key, à l'écart du chemin de diffusion public.
Là où ça s'intègre au reste de la plateforme
Ce scénario est délibérément centré sur le stockage et la diffusion, mais il se combine avec tout le reste du compte. Une application WordPress ou PHP peut déporter son dossier d'uploads vers un bucket tout en continuant à servir le site via le même edge. Une application container peut lier le bucket sous forme de variables d'environnement et lire ou écrire des objets directement. DNS et Auto SSL gèrent le domaine de diffusion, et purge, logs et status vous donnent la visibilité opérationnelle pour confirmer que les fichiers circulent bien depuis le cache et ne remontent pas silencieusement à l'origine à chaque requête.
Comment le mettre en place, étape par étape
Créer un bucket
Dans le panel, ouvrez Object Storage et créez un bucket pour vos médias (par exemple media-prod). Vous obtenez un endpoint compatible S3, une région et un nom de bucket. Gardez des buckets séparés pour les fichiers publics et les sauvegardes privées afin que leurs politiques d'accès ne se chevauchent jamais.
Générer une access key ciblée
Créez une paire access key / secret pour le bucket et collez-la dans votre outil d'upload, votre CMS ou votre SDK S3. Utilisez une clé par application afin de pouvoir faire tourner ou révoquer une seule intégration sans casser les autres. Les clés peuvent être renouvelées depuis le panel à tout moment en cas de fuite.
Uploader avec les bons en-têtes
Poussez les fichiers avec votre client S3 existant, aws-cli, ou un plugin, en définissant le Content-Type et un Cache-Control long (par exemple max-age=31536000, immutable) sur les fichiers qui ne changent jamais. Utilisez des noms de fichiers hachés par contenu comme logo.a1b2c3.png afin qu'une nouvelle version corresponde à une nouvelle URL et n'ait jamais besoin d'invalidation.
Placer le CDN devant
Attachez un domaine de diffusion (par exemple cdn.example.com) au CDN et faites pointer son origine vers le endpoint du bucket. Les requêtes atteignent désormais l'edge en premier, sont mises en cache sur plusieurs sites, et ne remontent vers l'Object Storage qu'au premier miss par fichier. Auto SSL émet automatiquement le certificat pour le domaine de diffusion.
Vérifier le comportement du cache
Chargez un fichier deux fois et vérifiez les en-têtes de réponse pour un HIT à la seconde requête. Confirmez que votre Cache-Control est respecté et que les types MIME image/vidéo sont corrects afin que les navigateurs et le cache edge les mettent en cache correctement.
Configurer la purge
Lorsque vous écrasez un fichier à la même URL, déclenchez une purge depuis le panel ou via cdnctl afin que l'edge supprime la copie périmée. Pour les fichiers versionnés par leur nom, vous en avez rarement besoin, c'est précisément pourquoi les noms hachés par contenu sont recommandés pour les médias à forte rotation.
Exemples de scénarios
Des milliers de photos produit vivent dans un bucket et sont diffusées depuis l'edge, si bien que les pages de liste et de détail restent rapides pendant les campagnes sans solliciter le serveur applicatif de la boutique.
La vidéo à la demande et les fichiers d'installation sont stockés une fois et diffusés depuis le cache, gardant la bande passante d'origine stable même quand un fichier devient soudainement viral.
Les sauvegardes nocturnes de base de données et de fichiers vont dans un bucket privé avec une access key dédiée, entièrement à l'écart du chemin de diffusion public et renouvelable à la demande.
Questions fréquentes
Le stockage est-il vraiment compatible S3 avec mes outils existants ?
Oui. Les buckets exposent un endpoint compatible S3, donc aws-cli, s3cmd, rclone et les SDK AWS fonctionnent en les pointant vers le endpoint avec votre access key et votre secret. La plupart des plugins d'upload de CMS et de frameworks compatibles S3 fonctionnent de la même façon.
Les utilisateurs accèdent-ils directement au bucket, ou au CDN ?
Pour la diffusion publique, vous pointez un domaine CDN vers le endpoint du bucket et publiez ce domaine dans votre code, afin que les utilisateurs atteignent toujours le cache edge. Le endpoint brut du bucket reste derrière le CDN et n'est pas ce que référencent vos pages.
Comment servir des fichiers privés sans rendre le bucket public ?
Gardez les objets privés et générez des URLs signées à courte durée de vie avec votre access key. Le lien accorde un accès limité dans le temps puis expire, ce qui est le bon schéma pour les téléchargements payants, les factures, ou tout ce qui ne doit pas rester public en permanence.
Si je remplace une image au même nom de fichier, pourquoi l'ancienne s'affiche-t-elle encore ?
Parce que l'edge a mis en cache la version précédente sous cette URL. Déclenchez une purge pour cet objet depuis le panel ou cdnctl, ou adoptez des noms de fichiers hachés par contenu afin que chaque nouvelle version ait une nouvelle URL et n'ait jamais besoin de purge.
Quel Cache-Control dois-je définir sur les médias ?
Les fichiers versionnés et durables doivent utiliser un max-age lointain avec immutable ; les fichiers qui changent fréquemment doivent utiliser un TTL plus court. Définir l'en-tête au moment de l'upload est ce qui permet à l'edge de conserver le fichier au lieu de le récupérer à nouveau depuis le bucket.
Puis-je révoquer l'accès si une clé fuite ?
Oui. Les access keys sont renouvelées et révoquées depuis le panel, intégration par intégration. Comme vous émettez une clé par application, révoquer une clé compromise n'affecte que cette intégration plutôt que tous les services qui lisent le bucket.