Archivo

Posts Tagged ‘menéame’

Cuando el problema del hardware se convierte en sólo de software

mayo 12, 2010 23 comentarios

Disclaimer: No pensaba escribir este apunte porque me parece que es publicidad gratuita a Amazon (y sus servicios AWS), que ya es una empresa de las gordas y dominantes en el mercado… y no me regalaron, ni me regalarán, ni una triste pegatina. Pero lo escribo para compartir experiencia, y que conste en acta que no recibiremos ni unas gracias por este apunte.

Hace un tiempo escribí cómo montamos Menéame a Amazon AWS, y cómo decidimos cambiar de Apache+lighttpd a NGinx, ahora llevamos casi cinco meses de funcionamiento en Amazon AWS y la experiencia no podría haber sido más satisfactoria (aunque con pequeños problemas, relatados al final).

Ejemplos de cambios en servidores

Creo que lo últimos cambios que hicimos son ejemplos claros de las ventajas de no tener que lidiar con hardware y limitarnos a solucionar problemas de software (que siempre tiene solución, si sabes programar).

Nuestra intención era migrar los servidores a Ubuntu Lucid en cuando esta saliese por tres razones fundamentales: es LTS (soporte a largo plazo), el PHP 5.3 que trae soporta conexiones persistentes a MySQL usando las nuevas librerías mysqli (que son las que usamos, más eficientes y elegantes que la anterior) y el arranque es mucho más rápido (importante para las instancias web que se crean dinámicamente según la carga –con el AutoScaler–).

El primer paso fue migrar las instancias webs, para ello tuve que arrancar un instancia con la nueva imagen (AMI) oficial de Ubuntu Lucid para Amazon, instalar los paquetes necesarios (básicamente NGInx y php5), configurarlas (fundamentalmente el NFS y el servicio SMTP), generar una nueva AMI y cambiar la configuración del AutroScaler (dos líneas de comandos). Todo eso me llevó unos dos horas de trabajo y ya teníamos la Lucid con 0 segundos de interrupción (diría que con 0 conexiones fallidas)… a un coste de 0.18€ por las dos horas de instancia adicionales.

El segundo paso fue más gordo, migrar el servidor secundario (aws1) que hace de slave del MySQL (para backups e indexación del Sphinx), de buscador (el Sphynx), DNS secundario y backups diarios a S3. Esta instancia estaba antes como “normal”, es decir sin almacenamiento persistente (EBS, o Elastic Block Storage), la idea era ponerla con EBS dado la complejidad de los servicios que presta. Pues la sorpresa fue que Canonical ya genera imágenes oficiales de Ubuntu preparadas para EBS (antes era un proceso manual un poco tedioso, es espectacular el servicio de Canonical sobre Amazon EC2 y la smejoras que introducen).

Este cambio también llevó poco tiempo, menos de dos horas para preparar todo (lo que más tiempo llevó fue la preparación del slave de MySql) y un par de horas más de pruebas. Cuando estuvo preparada lo único que hubo que hacer fue cambiar la IP fija (Elastic IP) para la nueva instancia, et voilà. Cero segundos de interrupción, a un coste de unos 0.36€.

Hace sólo uno días me decidí a optimizar la gestión de cache de imágenes (miniaturas y avatares). Estas se guardan en S3, pero como el coste de conexión es demasiado elevado para ficheros pequeños no tiene sentido –y es extremadamente caro– servirlas desde S3, así que se guarda una copia cache (que se genera/regenera automáticamente a partir de los originales en S3) en un disco montado por NFS. El servidor de NFS lo hacía la misma instancia que el servidor central de base de datos (aws0), la idea era moverlo a aws1 y así descargar el tráfico de red para ganar unos microsegundos con las conexiones de mysql y distribuir mejor el NFS del código fuente PHP (que sigue en aws0) con las imágenes estáticas (que además pueden tener más tiempo de cache NFS, configurable con los parámetros acregmin, aregmax, acdirmin, acdirmax o actimeo).

Lo único que hubo que hacer es generar una nueva AMI para las instancias web con el nuevo punto de montaje (es menor de media hora de trabajo, a 0.09€ la hora o fracción), forzar al arranque con las nuevas instancias y cuando todas ya eran la nueva cambiar un enlace simbólico en aws0 para apuntar el cache al nuevo directorio. Et voilà. Funciona así ahora, ganamos unos pocos microsegundos, con cero segundos de interrupción.

Situación general

Aquí tenéis la carga de aws0 (servidor de base de datos). Veréis que la carga es baja, muy estable y predecible.

Carga 24hs de aws0

Esta es la carga de aws1, los picos son de la indexación del Sphinx para las búsquedas (casi 7 millones de comentarios, casi 1 millón de enlaces y más de 100.000 notas):

Carga aws1

Carga 24hs de aws1

El siguiente es el estado de las instancias a estas horas (0 hs del miércoles). Se puede ver las dos instancias EBS (aws0 la large, aws1 la small) y las cuatro instancias de servidores web en marcha.

Instancias EC2

Y este es el gráfico de carga de un día de una instancia web.

Carga 24hs de una instancia web

Nota: me hice un pequeño script para poder monitorizar al minuto el estado de las instancias webs desde mi teléfono, es públicamente accesible: m.meneame.net/ec2.php

Rendimiento general

Una de las grandes dudas (y pegas) que teníamos para migrar a Amazon es que al estar situado en Dublin aumenta la ditancia, el número de saltos por routers y quizás las latencias introducidas por las redes virtuales, firewalls y balanceadores de carga. De hecho sólo el ping hacia una instancia casi triplica lo que teníamos en España (Ferca, luego Acens), pasó de 20 y pico milisegundos a unos 60 a EC2 Dublin.

Sin embargo creo que nadie se quejará de la velocidad de acceso y visualización de Menéame.

Tiene mucho que ver las optimizaciones que hemos hecho, como la separación de imágenes estáticas en dominio independiente, mejoras en el código, en las consultas a la base de datos, ajuste del NGInx, php-fastcgi, compresión del HTML, y cache de PHP (XCache). Pero también ayuda a que los balanceadores de carga (usan varios para cada “dominio”) de Amazon funcionan muy bien, tienen conexiones persistentes y unos firewall muy bien configurados que no sólo lo hacen ir rápido, sino que es de un rendimiento predecible que evita que haya conexiones más lentas que son las que más dan la impresión de “lentitud”.

En este sentido estamos también muy satisfechos. Sí, tienes que ir con cuidado porque no tiene sentido sobredimensionar el “hardware virtual” –además creo que no se ganaría casi nada– para solventar los problemas del software o mal diseño de base de datos, pero una vez hallados y solucionados los pocos cuellos de botella, funciona todo como una seda.

Servicios y costes

Cuando estábamos en Ferca/Acens teníamos dos servidores, uno muy potente (2 Quad Core) y otro menos (Duo). Teníamos un muy buen precio, unos 700€/mes todo incluido. Pero teníamos problemas muy difíciles de solucionar:

  • Aunque íbamos muy sobrados, en horas picos o eventos excepcionales el Apache nos saturaba ambas máquinas, como en las finales de la Copa de Europa de fútbol que tuvimos que alquilar temporalmente servidores en Amazon EC2, aunque con latencias muy altas a la base de datos –estaba replicada en Amazon, pero las actualziaciones iban al central en Ferca/Acens–.
  • No teníamos servicio de “backups externos” y cifrados.
  • Poner un balanceador de carga dedicado nos hubiese costado mucho dinero.
  • Teníamos problemas en poner más servidores conectados a la misma red privada (por que no había espacio en el rack, porque había que ir y poner un switch específico, porque obligaba a paradas… etc.).
  • Cada vez que necesitábamos algo puntual era un largo proceso de conversaciones y negociaciones, a tal punto que muchas de las cosas eran imposibles de contratar porque se escapaba a lo que considerábamos un presupuesto razonable.
  • Problemas constantes de “mala configuración” del firewall del CPD que nos bloqueaba conexiones (suponemos porque el número de conexiones era más elevada que la media considerada “normal”, aunque nunca lo supimos bien del todo).

Al momento que migramos a Amazon todos esos problemas se solucionaron:

  • Tenemos S3 para copias, backups y almacenamiento permanente.
  • Tenemos balanceador de carga de muy buena calidad, incluso configurable con “session stickiness”.
  • Podemos habilitar un CDN con los mismos costes que las conexiones S3 (no la usamos).
  • Podemos escalar automáticamente para dar buen servicio sin malgastar el dinero.
  • Disponemos de los servidores que nos hacen falta en no más de un par de minutos, a muy bajo coste.
  • Sistemas de discos (EBS) de muy alta fiabilidad.
  • Control de las IPs (Elastic IPs) y a qué servidor le asignas, puedes cambiarla en cualquier momento, e incluso puedes solicitar la resolución DNS inversa para cada una de ellas.
  • Sistema de seguridad/firewall muy potente, seguro y casi transparente de usar (por ejemplo, las instancias que están en un mismo grupo automáticamente tienen conectividad entre ellas). Al mismo tiempo todas tus instancias están aisladas del resto de instancias.
  • Absolutamente todo es controlable con software (la consola web para la mayoría, para cosas muy específicas las líneas de comandos, el API disponible en varios lenguajes para los scripts de monitorización y control).
  • No tenemos que negociar nada con nadie, todos los servicios –para todo el mundo– están bien claros y especificados, y los precios no son negociables, por nadie.
  • En todo este tiempo no tuvimos ninguna incidencia (salvo problemas de conectividad Internet esporádicos con algunas regiones o ISPs, pero esto pasa con cualquier hosting).

Todos estos servicios disponibles, con la flexibilidad de usarlos como mejor te parezca nos permitió implementar nuevas funcionalidades en Menéame que antes se nos hacían cuesta arriba por la necesidad de tener más hardware [infrautilizado]:

  1. Buscador extendido a comentarios y notas (algo que hace tiempo pedían los usuarios).
  2. Almacenamiento de imágenes y avatares en S3 que generación automática de cache en nuestros discos, los que nos hizo olvidar del problema de almacenar y hacer backups de ficheros.
  3. Cambios en la infraestructura (como de Apache a lighttpd, luego a NGInx con fastcgi, versiones de Ubuntu, etc.) y programas o configuración sin tener que interrumpir el servicio: se hace de forma paralela y luego se hace el switch.
  4. Compramos tranquilidad: duermo mucho más tranquilo, y aunque España llegue a la final del mundial no tendré que preocuparme de buscar estresado y bajo presión una solución a la sobrecarga de la hora posterior del partido.

Todo el que llegó hasta aquí seguramente se pregunta, ¿cuánto nos cuesta todo este tinglado adicional? Aquí tenéis la “factura” del mes de abril, en dólares, haced la conversión a euros :-) [1]

Pagos Amazon abril 2010

Por eso suelo decir, ¿qué hacéis todavía lidiando con hardware y negociando interminablemente para tener un servicio de backup o de balanceo de carga?

Nota: Esto funciona porque Amazon AWS está muy bien diseñado y su servicio es de calidad constante y predecible. Sé que hay varios más, pero no conozco cómo funcionan.

Los problemas

Por supuesto no todos fueron ventajas, tuvimos algunos problemas:

  1. La infraestructura del balanceador de carga es sofisticada, no es sólo un “cacharro” con una IP, son balanceadores distribuidos y se selecciona el mejor dependiendo desde la zona de conexión y el estado de la infraestructura de Amazon. Eso hace que cuando asignas un balanceador no te dan una dirección IP, sino un hostname que debes usarlo como CNAME. Eso impide que puedas usar una zona de primer nivel –el estándar de DNS no lo admite–por ello tuvimos que migrar el web de meneame.net a http://www.meneame.net (con la consiguiente penalización que sufrimos de Google, una caída de visitas –menos del 10% de visitas vienen de Google por búsquedas que no sean “meneame”–, hasta en el PageRank –creo que bajó hasta 6, no sé cómo está ahora–, supongo que con el tiempo y las redirecciones permanentes se recuperará, afortunadamente no nos afectó tanto ya que creo nunca superamos el 12-15% de visitas desde Google).
  2. Como Amazon sufrió abusos de spammers que alquilaban instancias sólo para envíos masivos de emails. La misma Amazon dió de alta todas sus direcciones IP en las organizaciones de listas negras e impedía enviar más de unos pocos correos desde sus instancias. Aunque puedes solicitar la apertura, seguían apareciendo las IPs en Spamhaus, lo que nos impidió enviar correos directamente. Ahora creo que ya lo han cambiado [2] (incluso ya resuelven la inversa de Elastic IP al dominio quele indiques, porbado por ejemplo la inversa de 79.125.22.108). Nosotros hemos tenido que hacerlo vía SMTPAuth.com que funciona muy bien, por lo que todavía no hemos pensado en hacerlo desde nuestros servidores (también tenemos cuenta en SendGrid.com, hablan muy bien de ellos y ofrecen hasta gráficas y estadísticas de quiénes leen los correos o los clics de los receptores).
  3. Desde el servidor web detrás del balanceador no son visibles directamente las IP de los navegadores (es crítico para el control de abusos del Menéame), sino a través de la cabecera HTTP X-Forwarded-For. Afortunadamente en Menéame ya hacíamos control de proxies para permitir votos desde ordenadores detrás de los proxies transparentes de Telefónica y de los teléfonos con conexión IP que salen por proxies (como todos los de Vodafone). Así que sólo usamos la misma función, pero simplificada para que sea más rápida:
  4. function check_ip_behind_load_balancer() {
        // It's similar to behind_proxy but faster and only takes in account
        // the last IP in the list.
        // Used to get the real IP behind a load balancer like Amazon ELB
        // WARN: does not check for valid IP, it must be a trusted proxy/load balancer
        if ($_SERVER["HTTP_X_FORWARDED_FOR"]) {
            $ips = preg_split('/[, ]/', $_SERVER["HTTP_X_FORWARDED_FOR"],
                                             -1, PREG_SPLIT_NO_EMPTY);
            $ip = array_pop($ips);
            if ($ip) return $ip;
        }
        return $_SERVER["REMOTE_ADDR"];
    }
    
  5. En el caso de servidores web seguros (SSL) el problema anterior es más difícil de solucionar. Como la conexión es cifrada el balanceador no puede agregar cabeceras HTTP, por lo que es imposible averiguar la IP desde el servidor. Aquí hay tres opciones: 1) no preocuparte de la IP, 2) dejar el servidor seguro fuera del balanceador, 3) buscar otro método. Como en Menéame se necesita la IP para control y soy un purista de arquitecturas –todos o ninguno– me decidí por la tercera. Cuando se necesita pasar por conexión segura se hace un formulario desde el servidor normal donde se incluye la IP de origen más un hash para controlar que no se manipula. Así el servidor seguro siempre recibe la IP –verificable– como un campo oculto del formulario (y esta es la razón que no se “salta” directamente al servidor seguro sino desde el “action” en un formulario).
  6. Los umbrales y reglas del AutoScaler funcionan bien, salvo para el escalado hacia abajo. Las reglas se definen con un umbral bajo y uno alto. Si la carga seleccionada (en nuestro caso uso de CPU) supera el umbral alto, cre nuevas instancias, si es inferior al bajo mata instancias. El problema es el siguiente, en nuestro caso el bajo es 30% y el alto 75%. Supongamos que hay cuatro instancias al 40% (carga total = 160%), el autoescalador no decrementará hasta llegar al 30% aunque si quita una queda muy por debajo del 75% (con tres quedaría en 53% cada una). Así no se optimiza muy bien el uso de recursos, ni los costes. Amazon dice que introducirá “reglas de usuarios”, mientras tanto yo lo solucioné con un script bastante simple que hace esos cálculos. Si la carga total con una instancia menos es inferior a un “umbral intermedio” (60% en nuestro caso) y hay más de dos instancias en marcha, entonces ordena al AutoScaler que baje termine una instancia. Estos cálculos son visibles en m.meneame.net/ec2.php, esos valores son generados por este script adicional de control de escalado.
  7. No dan factura oficial, hasta ahora no hemos tenido problemas con ellas, al menos Benjamí, nuestras contables ni Hacienda no se quejaron todavía, creo ;-)

Esos son los seis problemas fundamentales que hemos tenido, salvo el sexto, los demás son todos solucionables con un poco de programación.

[1] Tenemos tres instancias “reservadas”, es decir se paga una cantidad por adelantado (uno o tres años) y se obtienen muchos mejores precios. El ahorro anual es exactamente el 30% sobre el precio de lista.

[2] Acabo de confirmarlo (12/mayo), ya no aparecen nuestras IPs en las listas de Spamhaus.

Categorías:desarrollo, internet, menéame Etiquetas: , , ,

El karma y la Ley de Benford

abril 25, 2010 16 comentarios

Hoy acabé de leer The Drunkard’s Walk: How Randomness Rules Our Lives (libro duro en algunas partes, pero muy bueno), uno de los temas que toca el libro es la Ley de Benford. Ésta aparece en determinadas series resultado de operaciones acumulativas (especialmente los datos financieros), los primeros dígitos de los números resultates no siguen una distribución uniforme.

La distribución es aproximadamente la siguiente para números de base 10:

d p
1 30.10%
2 17.60%
3 12.50%
4 9.70%
5 7.90%
6 6.70%
7 5.80%
8 5.10%
9 4.60%

La gráfica (de la Wikipedia) queda:

Lo interesante de esta ley es que se usa para auditorías financieras e incluso es admisible como prueba en casis criminales en EEUU. Se basa en que los “balances” financieros (o evolución de precios de la bolsa, subastas en eBayincluso número de enlaces en Delicious) deben seguir esta ley, pero cuando se estafa manipulando los resultados se tiende a poner números aleatorios. Un ejemplo muy mencionado es que se usó para detectar el fraude de un emprendedor, Kevin Lawrence, que se gastó fraudulentamente 91 millones de dólares de sus inversores, también se la mencionó como evidencia de fraude es las lecciones de Irán en 2009, y la usaron para analizar las declaraciones de renta de Clinton (que las pasó correctamente).

Como me llamó la atención, me pregunté si el karma del Menéame seguiría la Ley de Benford. Si fuese así la usaría como evidencia que no hay fraude (y si no me callaría la boca :roll:).

Claramente no podía usar el karma de las noticias publicadas, ya que el karma de publicación es aproximadamente el mismo para todas (más o menos 500-550 de media) y éste se deja de incrementar una vez se publicó. Así que lo hice con todas las noticias que quedaron en pendientes.

La tabla resultante es la siguiente (nota: hay algunos ceros, en los primeros meses no se insertaba el voto del autor automáticamente, y otras que con la suma de positivos y negativos quedan en cero):

d Total p
0 4070 0.7
1 178254 32
2 95631 17.2
3 60085 10.8
4 47170 8.5
5 40710 7.3
6 38589 6.9
7 34191 6.1
8 30738 5.5
9 27251 4.9

Cumple casi a la perfección con la Ley de Benford ideal:

Categorías:ciencia, menéame, pijadas Etiquetas: ,

Los presuntos emails en nombre de Ramoncín®

enero 13, 2010 44 comentarios


El lunes pasado, entre las 14:01h y las 16:56h del lunes 11 de enero recibí en mi dirección personal 29 correos electrónicos enviados por Jonathan P. exigiendo que eliminemos comentarios que nos dejaban en “situación de ilegalidad” [sic].

Aquí la copia literal (sólo se eliminó un nombre de personal) de todos los correos que recibí (en el blog de Menéame se hizo un breve comunicado para aclarar la situación según las recomendaciones de los abogados).

Esto es lo que exigían:

[...]

1.-  Les requerimos fehacientemente para que en un plazo no superior a 24 horas procedan a la eliminación total de los mencionados comentarios, pues en caso contrario nos veríamos obligados a ejercitar en nombre de nuestro cliente, cuantas acciones en derecho nos asistan en defensa de sus intereses, dada la grave vulneración del honor de mi representado que supone dicho contenido, pudiendo hallarnos frente a un posible delito de injurias e incluso de calumnias (Artículo: 208 C.P.),    con agravante de medio y publicidad (Art 209 C.P),  del cual serían Ustedes completamente co-responsables al reproducirlos en su medio Web, en caso de no retirarlos tras el presente requerimiento.

Tras lo detallado, les solicitamos las siguientes acciones:

- Eliminación de todos aquellos comentarios escritos bajo artículos que alberga su dominio o espacio web sobre nuestro cliente o marca que supongan una vulneración del honor de mi representado y su control posterior.

- Eliminación de metadatos y tags con referencia a los comentarios sobre mi representado que pudieran ayudar a la indexación de las páginas en los buscadores, en particular aquellos comentarios que supongan una vulneración del honor de mi representado.

- Todas aquellas acciones que de buena fe tenga a bien realizar para normalizar la situación de ilegalidad en la que Uds. están incurriendo.

- Así mismo le solicito que extienda este requerimiento en todos y cada uno de los espacios web donde Uds. estén incurriendo en actos similares en contra de nuestro cliente o marca .

Esperando que su buen juicio haga innecesaria cualquier otra acción, y esperando que entienda los motivos que le han llevado a nuestro cliente y titular de marca a solicitar la eliminación de dichos comentarios, aprovechamos la ocasión para saludarles.

[...]

Además, aunque hacen copy&paste de contenido externo, esto es lo que se atribuyen:

ATENCIÓN / Les comunicamos que la redacción del presente requerimiento tiene en si mismo propiedad Intelectual que nos corresponde en exclusiva;  y por tanto no les autorizamos  a su reproducción, distribución, comunicación pública ni transformación bajo ningún medio sin autorización previa.

Los correos fueron envíados desde una dirección 212.145.169.xxx localizada en Vigo, diferente a la ciudad del bufete (usaron sistemas de SalesForce.com para el envío masivo de los emails). El dominio de la dirección de correo del que enviaba era de redpoints.es.

Categorías:internet, legales, menéame Etiquetas: , ,

Cambiamos de Apache y lighttpd a nginx

enero 2, 2010 28 comentarios

Actualización: Britxardo me envió un esquema bien dibujado:

Cómo montamos Menéame en Amazon EC2

diciembre 30, 2009 81 comentarios

La primera vez que alquilamos servidores dedicados para Menéame fue en ThePlanet.com. Aunque funcionaba muy bien y no tuvimos problemas decidimos traerlos a España para mejorar el ping y apostar por hosting español. Así nos fuimos a Ferca, que nos atendieron muy bien y no tuvimos problemas hasta que fueron absorbidos por Acens. Allí cambió, a peor, con caidas frecuentes de la red, problemas con sus firewalls que bloqueaban conexiones, desaparición del servicio de emergencias, imposibilidad de ver nuestras estadísticas… y lo que colmó nuestra paciencia es que a pesar que nos cobraron religiosamente los meses de noviembre y diciembre no nos enviaron las facturas (aún esperamos respuesta).

El tema del hosting suele ser un dolor de cabeza, y si además necesitas una arquitectura sofisticada, o escalable debes sacar el talonario y prepararte a gastar dinero que desde mi punto de vista no tiene justificación. Como llevaba probando y “jugando” con Amazon EC2 desde hace tiempo decidí hacer pruebas. Después de horas de cálculadora y viendo que nos costaría sólo un poco más que Acens (pero menos que otras ofertas que recibimos) pero nos daría mucha más flexibilidad y fiabilidad decidimos hacer la migración.

La arquitectura básica es la que se muestra en la siguiente imagen (prohido reirse de mi dibujo a mano con la mejor voluntad y dedicación):

Actualización: Britxardo me envió un par de parches con los esquemas:

Tenemos dos servidores (instancias) permanentes, aws0 y aws1, y un número variable de instancias que sólo atienden a las peticiones web. Todos los servidores ejecutan Ubuntu Karmic, de las imágenes (AMI) oficiales de Ubuntu para EC2.

El kernel que se ejecuta en cada instancia debe ser compatible con el “anfitrión” de Amazon, Canonical tiene un convenio con Amazon para validar su kernel, que son mucho más modernos que otras distribuciones (estas imágenes –AMI– se encuentran en “Community AMIs” de EC2). También nos interesaba Ubuntu Karmic porque en la migración cambiaríamos el tipo de motor de la base de datos a MyISAM a InnoDB y la versión de InnoDB del MySQL 5.1 está muy mejorada con respecto a la 5.0 de la última Ubuntu LTS (08.04).

Servidor principal: aws0

Es el “servidor central”, del tamaño large (m1.large) de 64 bits, cuesta $ 0.38 por hora, con 7.5GB de RAM y además la imagen está montada y arranca de un EBS (Elastic Block Service, un “disco persistente” con mejor rendimiento). Además de las ventajas obvias de persistencia de datos permite que en cualquier momento detengamos la instancia y la volvamos a iniciar con otros parámetros, por ejemplo más CPU y memoria RAM.

Los servicios que da este servidor son:

  • Servidor MySQL: Aprovechando la migración hemos pasado a usar InnoDB y usar las transacciones/commit donde más hacían falta.
  • Servidor NIS y NFS: Todo el software del Menéame y las cuentas de usuario están exportadas por NFS que son usadas por aws1 y las instancias web. Para centralizar la gestión de cuentas usamos el NIS.
  • Servidor principal DNS: Es el primario de la zona meneame.net y notame.net.
  • Servidor memcache: Usado por todas las instancias web.
  • Servidor SVN para la gestión del software.
  • Servidor SSH
  • Servidor SMTP: Recibe todos los correos desde las otras instancias. Debido a las restricciones de Amazon EC2 para el correo saliente, todos los correos lo enviamos vía AuthSMTP (más adelante lo explicamos)

Teníamos muchas dudas de cómo se iba a comportar con carga real a la base de datos, y estamos gratamente sorprendidos, durante el funcionamiento normal no supera el 50% de uso de la CPU como se puede ver en la imagen (los picos de madrugadas son por el cálculo del karma y otras tareas como generación de “summaries”)

Mysql

Es fundamental la configuración mínimamente correcta del servidor MySQL, en caso de InnoDB es muy crítico el tamaño del buffer, como tenemos un total de 7.5 GB le asignamos 5 GB de RAM.

[mysqld]
default-character-set=utf8
server-id=1
set-variable=max_connections=1000
set-variable=query_cache_wlock_invalidate=True
table_cache=1024

innodb_buffer_pool_size = 5G
innodb_flush_method = O_DIRECT
innodb_flush_log_at_trx_commit = 0
innodb_additional_mem_pool_size = 16M
innodb_log_buffer_size = 8M
innodb_file_per_table = True

join_buffer_size = 1M
sort_buffer_size = 1M
read_buffer_size = 1M
read_rnd_buffer_size = 2M
thread_cache_size = 64
thread_concurrency = 8
query_cache_size        = 96M
query_cache_limit = 16K
query_cache_type        = 2
tmp_table_size = 64M
max_heap_table_size = 64M
wait_timeout = 60

Servidor secundario y de backups: aws1

Esta es una instancia m1.small, de 32 bits, cuesta $0.095 por hora, con 1.7 GB de RAM, un sistema raiz de 10 GB y otro adicional (en /mnt) de 150 GB (ninguno de los dos es persistente)

  • Secundario DNS
  • Réplica en tiempo real de la base de datos (slave)
  • Sphinx para las búsquedas

Esta instancia ya la teníamos funcionando desde noviembre como secundario DNS, ahora simplemente la reaprovechamos para hacer más cosas. Las fundamental es la réplica en tiempo real de la base de datos, que nos sirve para hacer backups a discreción sin afectar al servicio web, también lo usamos para muchos scripts de control que son “pesados” en consultas (en MyISAM era imprescindible hacerlo así porque bloquea todos los updates, con el InnoDB ya no se nota, de todas formas seguimo usando el slave para estas tareas).

También estamos usando (no acabamos de configurar todo) el S3Sync para hacer backups diarios a S3. El S3Sync emula de alguna forma el tradicional rsync, pero para trabajar sobre el sistema de S3.

Réplicas con balanceo de carga y escalado automático

Decidimos poner todo el servicio web en un sistema que se autoescale automáticamente, no sólo por la cuestión de precios sino por la tranquilidad que en momentos de mucha carga no habrá problemas de saturación (como nos ocurrió durante la Eurocopa, que tuvimos que montar un servidor adicional en EC2, pero al hacer réplica en EEUU de un servidor en España no iba muy fino por las enormes latencias).

La decisión fue poner todos los servicios web en una misma imagen:

  • Apache con PHP para HTTP y HTTPS (puerto 80 y 443)
  • Lighttpd para los ficheros estáticos (puerto 81)

Desde hace tiempo usamos mnmstatic.net como dominio para los ficheros estáticos, esto mejora la carga desde el navegador y evita que el navegador envíe los cookies de meneame.net [*] cada vez que se baja una imagen, en las pruebas que habíamos hecho se ahorra hasta 14KB de tráfico de subida en cada página.

[*] No son sólo los nuestros, que son sólo dos, sino también todos los que definen vía javascript los medidores como Google Analytics, podéis verificarlo en vuestros navegadores.

Cada instancia al arrancarse monta por NFS el directorio donde tiene acceso a todo el software y las imágenes (estáticas y dinámicas). Esto se hace el el fstab, pero hay que tener cuidado con las opciones, fundamentalmente la opción bg para que que bloqueada al arranque, y otras para aumentar la eficiencia y tolerancia a errores.

# /etc/fstab: static file system information.
proc                       /proc  proc   defaults        0       0
/dev/sda3                  None   swap   defaults        0       0
/dev/sda1                  /      ext3   defaults        0       0
/dev/sda2                  /mnt   ext3   defaults        0       0
x.x.x.amazonaws.com:/home  /home  nfs    rw,bg,noatime,soft,nolock,intr,async,nodev,nocto,ac,actimeo=15 0 0

Balanceo (Load Balancer)

Como tenemos que balancear del puerto 80 dos tráficos diferentes (al Apache y al Lighttpd) tuvimos que definir  dos baleanceadores diferentes (web-balancer y static-balancer). Cada balanceador te da una dirección IP y nombre DNS. Uno de los balanceadores –web-balancer– redirecciona a los puertos 80 y 443 y el otro –static-balancer– redirecciona del puerto 80 al 81 del lighttpd.

Para cada una de las réplicas elegimos primero el tamaño pequeño (m1.small), pero el primer día de funcionamiento (el lunes) y a pesar que durante las fiestas el tráfico es bastante menor que lo habitual vimos que el AutoScaler creaba cinco  instancias para poder atender a la demanda, y durante las horas de menor tráfico no bajaba de dos. Me soprendió bastante, no esperaba que el consumo del Apache fuese tan elevado.

Me puse a estudiar y comparar con el vmstat, ví que las estadísticas del monitor de EC2 (CloudWatch) no se correspondían con estas. Investigando más me di cuenta del problema, el vmstat –al menos con el kernel de Ubuntu– no toma en cuenta la “capacidad” real de CPU asignada sino la del procesador. La asignada es un 40%  de la total de la CPU (fácil de comprobar, se pone un proceso que consuma el 100% de cpu –por ejemplo yes > /dev/null– y se mira la columna idle del vmstat, en este caso el idle indicaba 60%).

Entonces tenía que buscar una solución más barata, y encontré una solución muy buena, bonita, potente y barata, usar una instancia orientada a CPU para el Apache. EC2 ofrece este tipo de instancias, las High-CPU Instances. Con la c1.medium y por sólo el doble de precio ($0.19/hora) podía tener una máquina con la misma memoria y algo menos de prioridad de E/S (que es muy poca, sólo los logs del Apache) pero con 5 veces la capacidad de CPU.

Así que reconfiguré el AutoScaler para que cree las instancias del tipo c1.medium y problema solucionado: desde que lo pusimos en marcha no ha creado ninguna instancia adicional, nunca superó al 80% de CPU:

AutoScaler

La configuración del escalador automático es casi lo último que se hace, necesitas tener definido los balanceadores y la imagen (AMI) que se usará para arrancar las réplicas. A diferencia de lo anterior, que se puede crear y modificar con la consola web del Amazon AWS, todavía no existe esa opción para el AutoScaler (aunque seguro que la agregan en las próximas semanas).

Por ahora toca hacer con los scripts, se necesitan definir tres cosas que están mostradas en el código de abajo:

# Crea la configuración para lanzar las instancias
as-create-launch-config web01cpu --image-id ami-ami-d3fad1a7 --instance-type m1.small --group default,www

# Define el grupo de autoscale llamado web-group
# Se "conecta" a los dos balanceadores
# Después de tomar una decisión no hace nada durante 180 segundos
as-create-auto-scaling-group web-group --launch-configuration web01cpu  --availability-zones eu-west-1a  --min-size 1 --max-size 6 --load-balancers web-balancer,static-balancer --cooldown 180

# Define los parámetros para crear o destruir
# Crea cuando consume más del 80% de cpu durante dos minutos
# Destruye cuando baja del 30%
as-create-or-update-trigger web-trigger --auto-scaling-group web-group --namespace "AWS/EC2" --measure CPUUtilization --statistic Average --dimensions "AutoScalingGroupName=web-group" --period 60 --lower-threshold 30 --upper-threshold 80 --lower-breach-increment=-1 --upper-breach-increment 1 --breach-duration 120

Con todo lo comentado anteriormente, esta es la situación habitual de funcionamiento del Menéame:

Para mostrar el funcionamiento del escalador puse la CPU de la instancia web al 100% (ejecutando dos yes > /dev/null para poner al 100% cada una de las CPU) para obligar a crear otra instancia.

Aquí se puede ver como el trigger indica HighBreaching, es decir que se superó el límite superior

$ as-describe-triggers web-group --headers
TRIGGER  TRIGGER-NAME   GROUP      STATUS         NAMESPACE  MEASURE         STATISTIC  PERIOD
TRIGGER  web-trigger    web-group  HighBreaching  AWS/EC2    CPUUtilization  Average    60

Aquí se oberva como la “capacidad deseada” es de 2 y que inició la creación y arranque de una nueva instancia:

$ as-describe-auto-scaling-groups web-group --headers
AUTO-SCALING-GROUP  GROUP-NAME  LAUNCH-CONFIG  AVAILABILITY-ZONES  LOAD-BALANCERS                MIN-SIZE  MAX-SIZE  DESIRED-CAPACITY
AUTO-SCALING-GROUP  web-group   web01cpu       eu-west-1a          static-balancer,web-balancer  1         6         2
INSTANCE  INSTANCE-ID  AUTO-SCALING-GROUP  AVAILABILITY-ZONE  STATE
INSTANCE  i-04ef2c73   web-group           eu-west-1a         InService
INSTANCE  i-4e7dbe39   web-group           eu-west-1a         Pending

Finalmente las dos instancias ya están activas y accesibles:

$ as-describe-auto-scaling-groups web-group --headers
AUTO-SCALING-GROUP  GROUP-NAME  LAUNCH-CONFIG  AVAILABILITY-ZONES  LOAD-BALANCERS                MIN-SIZE  MAX-SIZE  DESIRED-CAPACITY
AUTO-SCALING-GROUP  web-group   web01cpu       eu-west-1a          static-balancer,web-balancer  1         6         2
INSTANCE  INSTANCE-ID  AUTO-SCALING-GROUP  AVAILABILITY-ZONE  STATE
INSTANCE  i-04ef2c73   web-group           eu-west-1a         InService
INSTANCE  i-4e7dbe39   web-group           eu-west-1a         InService

Así es como se ve en la consola:

Problemas encontrados

Tuvimos dos problemas fundamentales.

HTTP SSL detrás del balanceador

El primero es que las instancias sólo “ven” la IP privada del balanceador y envía una cabecera HTTP para indicar la original, esto no ocasionó gran problema porque el software del Menéame ya estaba preparado. Pero con el SSL (o HTTPS) la cosa es muy distinta, en estos caso la conexión entre el balanceador y la instancia no es vía HTTP, sino TCP (por razones obvias, la comunicación va cifrada) por lo que no se recibe nada de información de la IP del cliente.

Esto obligó a modificaciones y agregar campos de control en los formularios de registro y login vía el servidor seguro. No fue nada importante, pero me obligó a pensar bastante en una solución razonablemente segura (digo razonable porque seguro que se le pueden encontrar problemas si se le dedica tiempo).

Envío de correo por AuthSMTP

El segundo problema fue inesperado y el que nos retrasó la migración del día sábado al domingo. El viernes recibimos un email de Amazon indicándones que estábamos enviando correo saliente (nuestras pruebas de envío de validación de cuenta y recuperación de contraseña) y que nos iban a bloquear la salida. Además vimos que agregan automáticamente nuestras IPs al Spamhause.

Aunque te envían el URL de un formulario para pedir la autorización decían que hay que esperar por lo menos dos días hábiles (hoy nos enviaron un email diciendo que ya estudiaron el caso y nos autorizan, pero las IPs siguen apareciendo en Spamhause). Fue un momento de depresión, además ví que es un problema en Amazon por las medidas que tomaron para evitar spammers en su servicio.

Pero encontré una solución buena, bonita y barata: AuthSMTP.

Por un precio muy razonable ellos se encargan de enviar el correo de tus usuarios o todo el dominio. Funciona muy bien y muy rápido, te olvidas del problema que las IPs de tus servidores de correo aparezcas en esas demoníacas bases de datos de spammers.

En nuestro caso la configuración del Postfix de aws0 fue muy sencilla, sólo tuvimos que agregar las siguientes líneas al main.cf:

relayhost = mail.authsmtp.com:2525
smtp_connection_cache_destinations = mail.authsmtp.com
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = static:USUARIO:PASSWORD
smtp_sasl_security_options = noanonymous
default_destination_concurrency_limit = 4
soft_bounce = yes

Con esto se solucionó el problema más grave que encontramos y pudimos hacer la migración.

Costes mensuales

  • 1 m1.large: $ 273
  • 1 m1.small: $ 64.8
  • 1, 2 instancias c1.medium web de media (máxima): $ 164.16
  • 2 TB transferencia de datos: $ 340
  • 1 EBS de 50GB almacenamiento + aproximadamente 50 Mops= $ 11
  • 3 instancias medias medidas con Cloudwatch: $32.4
  • 2 Balanceadores: $40.32 + $16 de 2 TB de tráfico, $56.32

Coste total estimado: $ 941.68, al cambio actual del euro queda en 649 € mensuales

Fin

Sí, se pueden encontrar ofertas más baratas, y es un poco más de lo que pagamos a Acens (pero mucho menos que otras ofertas que recibimos), pero te olvidas de estar atado por una arquitectura, de tener que hacer engorrosas y largas negociaciones si necesitas un nuevo servidor, de abrir averías por la red (en Amazon está todo monitorizado y es público,  una caída afecta a muchos servidores, así que no tardan nada en resolver).

Y lo más importante, es el futuro, mucho más sofisticado, pero también más divertido (y creo que además más ecológico, el hardware está mucho mejor aprovechado) y como administrador de sistemas/programador/CTO tienes una libertad y flexibilidad impensable hace pocos años.

Como conclusión, por ahora muy positivo. Ya veremos como evoluciona, conociendo la historia de EC2 no dudo que agregarán cada vez más servicios y que bajarán los precios una vez al año.

PS: Son las cinco de la mañana, lo publico como está, disculpad los errores que haya, ya los corregiré luego.

La teoría de la portada

enero 11, 2009 20 comentarios

Este es uno de los momentos que suelo despotricar a los responsables de El País Digital por no permitir comentarios en sus artículos. Al menos cuando son de opinión y hablan de gente de carne y hueso que podrían responder en el mismo sitio (y creo que mejorarían mucho los artículos). Pero en fin, afortunadamente tengo un blog donde contestar, aunque no me lea ni mi familia.

Javier Sampedro en su artículo de El País Una portada que no podrá rechazar habla del Menéame y de Digg. Acaba con una curiosa como interesante teoría sobre el “porqué se vota a la noticia”:

Eso implica que la gente no manda las noticias que le interesan, ni vota por las que le gustan. Manda las que cree que les van a interesar a los demás, y vota por las que supone que les gustan a todo el mundo. Esa portada no es un promedio de lo que le interesa a cada lector. Es un compendio de sus prejuicios sobre los demás.

No estaré de acuerdo en generalizar así –sobre todo sin haber hecho una mínima encuesta– pero debo admitir que el caso se da, de hecho hay largos debates y flames sobre ello casi cada día. Lo que pasa es que nosotros le llamamos karmawhorismo.

Es interesante porque es novedoso, no dudo que en los periódicos serios como El País no se elige la portada pensando en que van a gustar más a sus lectores. Tampoco se escribe o elige tema, supongo, pensando en atraer o contentar a la audiencia. Esos prejuicios son cosas de eso que llaman 2.0 :roll:

Un par de matizaciones “técnicas”

Lo de “enterrar” no es originario de Digg, es de Menéame, las “descartadas” por los votos negativos. Al principio en Digg lo hacían manualmente vía los avisos de “reporte de problemas”. En Menéame a eso lo convertimos en un voto negativo para mover las noticias a otra cola secundaria y así dejar más visibles a las pendientes. Es el único objetivo, en Menéame las enterradas descartadas se pueden seguir votando, pueden volver a pendientes e incluso salir en portada, la única diferencia es que hace falta un clic más.

La otra matización. Supongo que en Digg hacen lo mismo que en Menéame, trabajar y mejorar los algoritmos para poder evitar controlar los “abusos” de grupos minoritarios (o “endogámicos”) pero muy activo que pueden llevar a portada los que les interesa a ellos, incluso a monopolizar la portada con las del gusto personal de una minoría usando trucos y tretas de las más variadas (no podemos pedir DNI en la boca para votar). La diferencia es que la filosofía de Digg (como de Reddit) es que esos algoritmos deben ser secretos para evitar que los puedan engañar.

A nosotros eso nos parece una chorrada error conceptual más importante que la “seguridad por oscuridad”. Por eso seguimos la filosofía del software libre y de los expertos de verdad en seguridad, lo mejor es que sean públicos, además de la transparencia y confianza mínima que tienes que ofrecer –obligada en nuestra cultura, no hubiésemos aceptado de la misma forma que aceptan a Digg los anglosajones– es la forma de detectar los errores y mejorarlos. No nos ha ido tan mal, pero cuesta trabajo. Aunque el código está disponible para controlar, debemos invertir esfuerzos en explicarlo de forma simple para los que no quieren mirar el código (todos menos unos pocos frikis).

Los algoritmos no definen tendencias ni temas, tampoco tenemos –ni creo que lo tenga Digg o Reddit– intención de usarlos para eso. Se trata simplemente de evitar el spam, el predominio de unos pocos y de asegurar un mínimo de “fair play”. A veces fallamos por defecto otras  por exceso, es lo que necesita corrección y mejora . Por ejemplo me enteré de ese artículo por los siguientes logs del servidor:

Jan 10 23:34:43 eli1 : Meneame, forbidden due to overflow to the same site (xxxxxx): http://www.elpais.com/articulo/panorama/portada/podra/rechazar/elpepusocdgm/20090111elpdmgpan_8/Tes
Jan 10 23:36:15 eli1 : Meneame, forbidden due to overflow to the same site (xxxxxx): http://www.elpais.com/articulo/panorama/portada/podra/rechazar/elpepusocdgm/20090111elpdmgpan_8/Tes
Jan 10 23:40:35 eli1 : Meneame, forbidden due to overflow to the same site (xxxxxx): http://www.elpais.com/articulo/panorama/portada/podra/rechazar/elpepusocdgm/20090111elpdmgpan_8/Tes
Jan 10 23:42:16 eli1 : Meneame, forbidden due to overflow to the same site (xxxxxx): http://www.elpais.com/articulo/panorama/portada/podra/rechazar/elpepusocdgm/20090111elpdmgpan_8/Tes
Jan 10 23:42:39 eli1 : Meneame, forbidden due to overflow to the same site (xxxxxx): http://www.elpais.com/articulo/panorama/portada/podra/rechazar/elpepusocdgm/20090111elpdmgpan_8/Tes
Jan 10 23:43:59 db2private : Meneame, forbidden due to overflow to the same site (yyyyyyy): http://www.elpais.com/articulo/panorama/portada/podra/rechazar/elpepusocdgm/20090111elpdmgpan_8/Tes
Jan 10 23:46:23 eli1 : Meneame, forbidden due to overflow to the same site (xxxxxx): http://www.elpais.com/articulo/panorama/portada/podra/rechazar/elpepusocdgm/20090111elpdmgpan_8/Tes
Jan 10 23:47:57 eli1 : Meneame, forbidden due to overflow to the same site (yyyyyyy): http://www.elpais.com/articulo/panorama/portada/podra/rechazar/elpepusocdgm/20090111elpdmgpan_8/Tes
Jan 10 23:49:11 eli1 : Meneame, forbidden due to overflow to the same site (yyyyyyy): http://www.elpais.com/articulo/panorama/portada/podra/rechazar/elpepusocdgm/20090111elpdmgpan_8/Tes
Jan 11 00:08:25 eli1 : Meneame, forbidden due to overflow to the same site (yyyyyyy): http://www.elpais.com/articulo/panorama/portada/podra/rechazar/elpepusocdgm/20090111elpdmgpan_8/Tes
Jan 11 00:09:31 eli1 : Meneame, forbidden due to overflow to the same site (yyyyyyy): http://www.elpais.com/articulo/panorama/portada/podra/rechazar/elpepusocdgm/20090111elpdmgpan_8/Tes
Jan 11 00:12:31 eli1 : Meneame, forbidden due to overflow to the same site (yyyyyyy): http://www.elpais.com/articulo/panorama/portada/podra/rechazar/elpepusocdgm/20090111elpdmgpan_8/Tes
Jan 11 00:13:39 eli1 : Meneame, forbidden due to overflow to the same site (yyyyyyy): http://www.elpais.com/articulo/panorama/portada/podra/rechazar/elpepusocdgm/20090111elpdmgpan_8/Tes
Jan 11 00:13:56 eli1 : Meneame, forbidden due to overflow to the same site (xxxxxx): http://www.elpais.com/articulo/panorama/portada/podra/rechazar/elpepusocdgm/20090111elpdmgpan_8/Tes

A veces los controles van en contra de nuestros propios intereses :-)

Nota: los xxxxxx e yyyyyyy reemplazan a los nombres de karmawhores usuarios que estaban intentando enviarla (finalmente lo han conseguido, pero no tocamos nada del “algoritmo”) :-). La hora es UTC.

Segunda nota: JRMora le dedicó una viñeta al tema.

Categorías:menéame, personal Etiquetas: ,

Mentiras de gravedad variable, según la fuente

octubre 5, 2008 34 comentarios

La historia curiosa es más o menos la siguiente.

Ian Welsh, consultor y analista político escribe en su blog Fed to Congress: We’ll Just Print 630 billion dollars K? Thx Bye. donde comenta que la Reserva Federal amenazó justo antes de la votación con inyectar más dinero. Welsh especula que ésta imprimiría esos 630.000 millones de dólares. El blogger cita a una noticia de Bloomberg (que fue actualizada tres veces en un corto período de tiempo).

La noticia es enviada a Menéame y obtiene en total unos 600 votos: Justo después del perder la votación, la Reserva Federal anuncia que imprimirá 630,000 millones de dolares más.

Horas después Ignacio Escolar escribe Menea esta mentira donde critica que haya salido en portada del Menéame y que tenga tantos votos (creo que en ese momento tenía unos 400 y pico de votos). Aquí hay un pequeño error, ya que Escolar afirma que se debe a una mala traducción del inglés, cuando en realidad la traducción es correcta, aunque el signo de interrogación lo convierte en una clara especulación más que en noticia como daba a entender el envío en Menéame.

De todas formas es un error, no es lo mismo especulación que afirmación y Escolar tiene razón, toda la razón. De hecho su rectificación y crítica fue enviada al Menéame y tiene más de 2100 votos (casi cuatro veces que la “mentira” original) además de los 130 y pico comentarios.

El resultado es positivo, lo mires por donde lo mires. Un “periodista” más conocedor critica un error, se envía, se corrige, se discute, se envían trackbacks a la noticia original y la gente que la vea no solamente podrá contrastar en la fuente original, sino también en un blog y envío posterior al mismo Menéame.

Es lo que se espera de los “medios digitales” –en sentido laxo–.

Sin embargo cabe hacer un análisis al estilo de lo que hacen los mismos “periodistas de investigación” de los “medios serios”.

¿Es este el primer error del Menéame? No. ¿Es el último o el único? No. ¿Es el primer error de un blog “especializado”? No, no es el primero ni el último (aunque Michael Moore también piensa que sí pretenden imprimir). ¿Es tan importante o gordo el error para que un director de periódico se lo tome tan en serio y llegue a escribirlo en su blog e incluso discutir en los comentarios en el Menéame? No lo sé, pero llama la atención.

Y llama la atención por otros motivos, hay otras “mentiras meneadas” que también tuvieron muchos votos, más que los 600 de la impresión de billetes:

La noticia anterior es falsa, fruto de una especulación, sensacionalista y oportunista de libro.

También fue enviada al Menéame y su fuente original era un periódico “serio”, el artículo escrito por un periodista profesional y fue noticia de primera plana en el papel y digital. Ignacio Escolar pidió disculpas y explicó el error (también es viisble en los trackbaks en Menéame), sin embargo no criticó –o no le dió importancia– que haya salido en el Menéame y que haya tenido casi tres veces más votos que la erróneo de “imprimir” (versus “intercambiar” como dicen) billetes. Tampoco hubo rectificación en portada en los mismos “términos” que la noticia errónea original.

Sólo una pequeña disculpa con letras pequeñas, en la página cuatro (página de la izquierda) y echando balones fuera.

Pero hay otra noticia reciente e igual de errónea, del mismo periódico, también con muchos votos en Menéame:

A pesar que entrevistaron al alcalde en cuestión, el titular de la noticia es tan erróneo como amarillista de libro. Lo explica un comentario, Benjamí, que entrevistó al alcalde involucrado, da más detalles de por qué es erróneo (además ambos comentarios están resaltados por la cantidad de votos positivos).

Es decir, no es la primera vez, ni la última, que se publican noticias erróneas, tanto proviniendo de blogs como de “medios serios”.

Sin embargo en una Ignacio Escolar se “sorprende” y en otras dos no le ha dado la mínima importancia. ¿Cuáles son las diferencias? Que la primera surge de un blog, mientras que la segunda surgen del mismo periódico, el suyo y del que es director y responsable último de que esas cosas no ocurran.

Quiero aclarar que me gusta Público, es el único que compro y tengo los cuatro Mafaldas. Admiro el trabajo y trayectoria de Ignacio Escolar. Creo que es el mejor director que podrían haber elegido para montar un periódico que intente hacerse un espacio en la zona izquierda del espectro periodístico y que además atraiga a un público jóven, moderno y comprometido. Eso sin contar que es el único periódico que apuesta claramente por la cultura libre y se posiciona radicalmente en contra de los talibanes de la  “propiedad intelectual” o los maleducados sensibles y peseteros de la SGAE. Es decir, de lo mejor que tenemos en el ambiente periodístico español –según mis ideas, claro está–.

Sin embargo, y a pesar del peso e inercia de su curriculum, cayó en el mismo vicio que el periodismo carca. No sé si es porque cuando escribió ese apunte ya tenía puesto el traje caro para ir a la fiesta de Mediapro y tenía asumido el papel antes de tiempo, o que de asistir a tantos congresos y reuniones de la “periodistas” ya toma como ciertas las frases tan repetidas nuestro firme compromiso con la información y la verdad [...] al contrario de lo que ocurre en Internet, que no se verifica nada.

Que una persona gran conocedora de cómo funcionan los blogs (¿la conversación?) y antiguo crítico al “periodismo carca” como Ignacio Escolar haya cometido este desliz –supongo que es eso– demuestra el enorme tamaño del ombligo de los periodistas, tan grande que es capaz de distorsionar hasta los más experimentados: se escandalizan de los “meneos” por la especulación de un blog, en cambio los meneos las noticias falsas que publican periodistas profesionales en sus propios medios parecen pasar completamente desapercibidos, o “aprobados”.

Somos humanos, si se nos caen aviones a pesar que sus responsables están hipercapacitados, también es de esperar que ocurran estas cosas con los cotilleos y especulaciones informativas en medio de una crisis, o después de unas elecciones, o cuando se trata de la “temible” CMT. Pero a veces se echa en falta que los propios periodistas tengan un poco más de autocrítica y fomenten el mismo espíritu crítico en sus lectores, incluso cuando leen sus propias noticias.

Que de tanto mirar la paja en Internet [*] se les cuelan las vigas en sus papeles. Lo malo es que sus lectores están cada vez más confundidos, donde hay vigas sólo son capaces de ver orégano, donde hay algunas pajas sólo son capaces de ver mentiras y pederastas.

PS: muchos dicen que la gente vota cualquier noticia para ganar karma, si fuese cierto no quiero ni imaginar lo que serían capaces de hacer con las noticias si se jugasen la nómina o el cargo de director.

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 480 seguidores