storage

Site web média et presse : Le stockage et l’espace disque

Question matutinal

Si je reformule les deux interrogations  du matin je poserais la question suivante : Quel est l’impact financier le plus important du stockage (news et archive) pour un site web de presse ou média. Est-ce l’espace disque pour le stockage lui même ou la bande passante pour exploiter ce qui à été stocké ?

Je n’ai pas le temps ni l’envie de faire des statistiques, des benchmarck ou de compiler des données. Je vais donc donner mon humble avis en me basant sur mes souvenirs de Prisma-Presse, sur mon actualité chez Mondadori et plus largement sur mon expérience.

L’espace disque

L’espace disque brut en 2014 n’est plus un problème. Je parle bien d’espace disque brut, c’est à dire le disque lui même et pas forcément les moyens de l’exploiter.

Sur Amazon Web Service, qui de par sa position de leader donne la température, 13To de disque magnétique de performance moyen coût légèrement moins de 800$ HT par mois. Chez OVH, leader en France, un NAS incluant les moyens de partager l’espace disque et de l’administrer (cif / nfs / etc) c’est 1000€ HT par mois

13To c’est à peu moins d’un tiers de l’espace disque total nécessaire à un groupe presse de la taille de Prisma Presse ou Mondadori pour faire fonctionner l’ensemble des services.

On vois que les coûts d’espace disque brut sans être négligeable ne sont pas insurmontable.

La bande passante

La bande passante en 2014 n’est pas un problème sauf ponctuellement et encore.

Si ont rependre comme référence Amazon Web Service , OVH ou d’autre (ikoula, Oxalid, iliad etc..) vous aurez à votre disposition des gros tuyaux capable de compenser le pire des complexes phalliques du plus minable des machistes. Bref de l’énorme.

Sur Amazon Web Service, sans optimisation des coûts, 10Go de transfert vers l’internet par jour vous coûtera  35$ par mois. C’est un peu près le volume de donnée pour trois sites web féminin majeur français (je ne cite personne)

Ponctuellement, un scoop, un buzz, un événement peux engendrer une surcharge à l’entré du tuyau :

  • Si vous êtes encore dans une infrastructure dédier et cantonné dans un data center en général la couche firewall et / ou répartiteur de charge est taillé pour assurer à 120 ou 130% de consommation courante.  Payé 30% de plus de capacité et ne pas l’utiliser 99% temps est, financièrement, une sécurité suffisamment coûteuse pour la plupart des dirigeants.  Donc, 24h ou 48h par ans, un scoop tombe et engendre un pic d’audience. Malgré le cache http et les CDN vous n’avez pas la qualité de service optimum et ça râle à l’édito. Vous rappeler le prix du service up a 100% quel que soit les conditions, tout le monde tousse et on passe à la question suivante.
  • Et encore si êtes dans un vrai cloud type IaaS (et pas juste de la virtualisation) vous avez la capacité d’être élastique, agile et réactif. Vous augmenterez votre capacité le temps de la tempête médiatique. Cela peux coûter un peu, mais cela dure juste le temps de la vague.

Il est ou le vrai coût du stockage ?

Le vrais coût du stockage est dans le stack applicatif utilisant le stockage, c.a.d votre site web.

Si votre développement ne sais que écrire ou lire dans un répertoire sans la moindre intelligence vous ne pourrez jamais tirer parti des systèmes de stockages qu’invente les acteurs de l’hébergement web, du cloud et des évolutions en général.

Une stack applicatif capable de changer de backend de storage pour passer d’un disque, à un NAS, puis à du AWS S3 cela a un coût bien supérieur au volume de disque ou à la BP brute. C’est du travail d’architecte web et de développeur, du jus de cerveaux qui à un coût. Soit ponctuellement par un grand big bang pour changer de paradigme de stockage, soit en continu.

Une stack applicatif applicative qui n’est pas économe des ressources de stockage. Qui ne prend pas en compte son propre auto-nettoyage. Qui ne vide pas automatiquement la poubelle, ne supprime pas les versions obsolètes. Un stack applicative de ce type va entasser. En dernier lieu plus personne ne maîtrise, personne ne veut prendre le risque de supprimer du contenu et c’est l’explosion du stockage.

Un autre partie, très souvent négligé, c’est les opérations d’exploitation et de sysadmin. Plus votre stockage augmentent et reste monolithique (cf: lire et écrire dans un répertoire)  plus sa manipulation  devient problématique. Déplacement, duplication, backup, restaurations, migration, synchronisation prendrons un temps précieux et tuerons toute réactivité.

La également votre  stack applicatif doit être capable d’adresser les objets stocker de façon répartie et modulaire (sharding, hachage, migration continue etc.), un peu sur disque et beaucoup dans le cloud. Et nous en revenons au jus de cerveaux et au code.

Le stockage ne coûte plus grand chose. Le tuyau de bande passante, moyen d’origine pour utiliser le stockage ne coûte pas non plus beaucoup. Mais le moyen d’utiliser les différents stockages, voir plusieurs en même temps; de passer de l’un l’autre, de façon répartie et modulaire repose sur le code de votre application. Et ça c’est du jus de cerveau qui à un prix.

Autant du stockage brut doit être considéré comme un coût. Un peu comme de l’essence pour une voiture. Autant la création d’une voiture capable d’utiliser indifféremment carburant est un investissement. Même chose pour vos applications.

Baleine.Docker

Feedback du Paris meetup : Docker en Production

Dans cette présentation, Jérôme Petazzoni donne plusieurs réponses aux grandes questions classiques associées au déploiement avec Docker.

J’ai retenu :

Totalement béotien j’ai noté les éléments suivant que je vous invite explorer de votre coté :
  • run –net=host pour utiliser la pile réseau du host hébergeant le / les containers sans jouer avec les bridges. Attention les processus dans les containers peuvent ouvrir des ports < 1000 comme tout processus root. Cela permet également au container d’accéder aux services du réseau local comme D-bus. Cela peut conduire à des processus du container étant capable de faire des choses inattendues comme redémarrer votre ordinateur.
  • Pas de Docker Hub dédié, sur site, dans l’enceinte d’un réseau priver mais c’est une demande des grands comptes donc cela va arriver rapidement.
  • Plus généralement Docker rentrant dans une phase de maturité la roadmap de l’équipe va s’orienter vers la satisfaction des clients, ceux qui achète du service mais ..
  • Les contributions des utilisateurs sont très nombreuses. Plus de 100 contrib en permanence en backlog que l’équipe doit approuver. L’équipe ne néglige pas cet apport et reste concentrer pour valider correctement chaque contrib, grosse ou petite.
  • J’ai retenu que docker offre tout les outils pour subdiviser une machine virtuelle type AWS EC2 et en partager les ressources. Parfait pour créer des sansbox ou des préprod / dev à moindre coût.
  • Les links et les variables d’environnement sont ce qu’il a de plus facile à mettre en place pour du service discovery à froid. La limitation c’est que cela est innaplicable pour déplacer un container et lui faire découvrir son environnement à chaud.
  • Le service discovery via DNS ou /etc/hosts à encore de beau jour devant eux. C’est hyper old school mais maîtrisé
  • J’ai rien compris aux ambassadors, aux licornes montées par des chats armée de golden gun … rendez moi les barbus.
  • Puppet c’est bon pour les hôtes Docker moins pour les containers eux même
  • Puppet reste une solution d’orchestration du déploiement de vos container utilisable pour des infra sous la barres des 100 puppet clients. Au delà d’autre outils s’impose. Bref ne pas jeter puppet tout de suite mais je pressens que la zone de confort doit être réduite avec lui comme avec tout les CM dans le cas docker.
  • Mesos c’est très intéressant et j’aimerais vraiment explorer au moins d’un point de vue théorique l’assemblage Mesos, Marathon et Docker pour une infra scalable verticalement et horizontalement à chaud et dynamiquement.
  • Le monitoring et la mesure de la performance me semble être le grand far west … les règles restent à inventer. L’auto discovery de zabbix est peut-être une piste pour monitorer les applications en container depuis le host sous-jacent.

Mise à jour

Toujours pas possible d’utiliser docker nativement avec debian wheezy avec les repositorys classique, privilégier Ubuntu pour les adorateurs de .deb

Donc sur wheery c’est possible avec les backports.

PROPAGANDA : La Presse et le Native Advertising

Le business model de la presse, papier comme online, basé sur la publicité connais un nouvel avatar avec le Native Advertising. Seulement un tel type de publicité n’est pas sans poser des problèmes de déontologie puis d’audience une fois la crédibilité perdu. John Oliver illustre très bien la problématique avec humour

D’un point de vue citoyen quid de l’utilisation du Native Advertising par les groupes de pression et lobby afin d’influencer l’opinion ?

Le native advertising est à mettre en perspective avec l’utilisation de plus en plus massive d’AdBlocker par les internautes.

Karlesnine.com a 12 Ans

Mon blog à donc 12 ans aujourd’hui. Le 9 septembre 2002 j’inaugurais le nom de domaine karlesnine.com sur le webcenter de Lycos France dont j’étais alors responsables du service client.

vue de karlesnine.com par Web Archive le 9 septembre 2002
Vue de la première home page de karlesnine.com prise par Web Archive le 9 septembre 2002

Pour mémoire le webcenter de Lycos replaçait tripod en europe était le successeur des pages perso de Multimania. Elles même étant le fruit de la fusion de Mygale et de The (Virtual) Baguette.

Moi dans un t-shirt Mygale.org
Moi dans un t-shirt Mygale.org – Une pensé pour kotchaba – merci

 

Run linux since 1994 and this web site since 2002