Abordar inconsistencias de peticiones PUT de S3 en Transloadit
Amazon S3 es genial. Salvo cuando no lo es. Cuando lo usas mucho (hasta ahora hemos almacenado alrededor de un millón de objetos de clientes), empiezas a ver cosas extrañas que se parecen más a una «locura eventual» que a una «consistencia eventual».
Una de las cosas que aprendimos de inmediato es que no se puede confiar en los códigos de error de
S3. A veces verás un 403 Permission Denied, pero cuando ejecutas exactamente la misma
petición otra vez, funciona de milagro y de repente. Por esa razón, en general tienes que reintentar
en caso de que recibas un mensaje de error. Solo si un determinado error ocurre varias veces
deberías empezar a prestar atención. Actualmente reintentamos hasta 6 veces con tiempos de espera
crecientes.
Lo último con lo que nos topamos es que tampoco hay que confiar en las confirmaciones de S3 para las peticiones PUT. Los síntomas que vimos fueron que algunas de las URL de S3 que devolvíamos a nuestros clientes simplemente no funcionaban. Reproducir esto ha sido un reto enorme. En un momento dado pudimos ver el problema tras ~25 PUT, y otra vez no ocurrió nada después de 2500 PUT (10 GB en total). Así que todavía existe una mínima posibilidad de que haya un fallo en algún punto de nuestro sistema, pero a estas alturas estamos bastante convencidos de que se trata de un problema de Amazon que ocurre con poca frecuencia.
Bienvenido a la tierra de la locura. Cuando trabajas con un sistema de consistencia eventual, donde «eventualmente» a veces puede significar «nunca», ¿cómo verificas el éxito de una operación de escritura? Puedes, por supuesto, revisar el bucket para ver si el objeto existe después de cada escritura, pero ¿qué pasa si no existe? ¿Cuándo se convierte esto en una condición de error? Es más, cuando el objeto sí existe, ¿qué significa eso? Es seguro asumir que esto significa que al menos un cliente puede ver el objeto, pero no que haya terminado de replicarse y esté por tanto disponible para todos los clientes.
Aunque no hay una respuesta perfecta, hemos decidido verificar la presencia de un archivo almacenado con hasta once comprobaciones a lo largo de un periodo de dos minutos. Si el archivo no existe para entonces, reintentaremos el Job hasta seis veces. Aunque esto dista mucho de ser ideal, probablemente reducirá la probabilidad de que entreguemos URL de S3 inválidas a un nivel similar al de ganar un premio decente en la lotería.
Otra cosa que nos pareció interesante es que el modelo de consistencia de S3 no es el mismo en todas las regiones. Mientras que «US Default» emplea el modelo tradicional de «consistencia eventual», todas las demás regiones ofrecen consistencia «read-after-write». Aunque resulta increíblemente confuso desde el punto de vista del cliente, la razón de esto parece ser que «US Default» se extiende desde la costa este hasta la oeste, por lo que la velocidad de la luz se interpone a la hora de ofrecer las mismas garantías.
Estamos en proceso de recopilar mejores datos sobre nuestra experiencia con S3, que compartiremos en el futuro. Sin duda, S3 nos funciona muy bien la mayor parte del tiempo, y si resulta que lo estábamos usando mal, también lo comentaremos.