¿Estás usando AWSDBProxy? ¿Hay un impacto en el rendimiento al escalar?

Question

Después de un voto negativo, me di cuenta humildemente de que mi publicación era una enorme queja . Así que lo edité y resumí esto a la pregunta que realmente me gustaría saber. Pido disculpas por mis comentarios descarados antes de esta edición;)

Parece que los únicos tutoriales que hablan sobre el uso de SimpleDB de Amazon en un sitio de rails están usando AWSDBProxy ... Personalmente, encuentro esto contra-intuitivo para escalar, considerando el diseño del servidor de un sitio típico de Rails a continuación (usando AWSDBProxy):

Plugin aquí: http://agilewebdevelopment.com/plugins/aws_sdb_proxy

Imagen aquí: http://www.freeimagehosting.net/uploads/91be4e0617.png

Como puede ver, incluso si agregamos más mestizos, tenemos dos problemas.

1. Tenemos un único punto de falla mucho menos estable que nuestro equilibrador de carga
2. Tenemos que forzar toda nuestra información a través de este servidor WEBrick

La solución es, por supuesto, agregar más AWSDBProxies ... pero ¿por qué no simplemente usar el siguiente código en say, una clase, omitiendo el proxy por completo?

service = AwsSdb::Service.new(Logger.new(nil),
                                CONFIG['aws_access_key_id'],
                                CONFIG['aws_secret_access_key'])
service.query(domain, query)

Entonces, a lo que me refiero es si estás usando AWSDBProxy, ¿cuáles son tus justificaciones para ello? Y si realmente lo está utilizando, ¿cuál es su rendimiento? Si tiene números concretos, ¡esto sería aún más apreciado!

¡Gracias!

Answer 1

No lo estoy usando, ni he oído hablar de él, pero esto es lo que creo que son razones razonables.

1. Está ejecutando su servidor de aplicaciones principal en EC2, por lo que la posibilidad de FALLO de Internet realmente no lo afecta más de una vez.
2. Ejecutas un proxy en cada uno de tus servidores de aplicaciones. Por lo tanto, la conexión que se está cayendo no es peor que las conexiones a la base de datos que se está cayendo.
3. Porque se puede hacer. Esta es una razón tan buena como cualquier otra en un proyecto de código abierto. A veces se necesita construir una cosa antes de saber si dicha cosa es una buena / mala idea.
4. No tiene los niveles de tráfico para necesitar un equilibrador de carga. Luego, su diagrama se reduce a una línea, si no una sola máquina.