Limites y Performance de Microsoft Azure Storage

La gran mayoría de las veces no es necesario conocer los límites de la tecnología con la cual estamos montando una solución, sobre todo porque ese límite es modificado con gran velocidad proporcionando cada vez una mayor capacidad y velocidad. Sin embargo, existen otros casos, en donde conocer estos límites es importante.

Les dejo aquí algunos datos que pueden ayudarnos a determinar algunas consideraciones de arquitectura.

En todos los casos, la tasa de requests y ancho de banda de la cuenta de Azure Storage depende del tamaño de los objetos almacenados, los patrones de acceso utilizados, y el tipo de carga que realiza la aplicación. Evite los picos repentinos de tráfico y garantizar que está bien distribuido en varias particiones.

Cuando una solicitud llega al límite de lo que una partición puede manejar, Azure Storage empezará a devolver códigos de error 503 (Servidor ocupado) o 500 (Timeout). Cuando esto ocurre, la aplicación debe utilizar una política de reintentos o distribuir la carga de mejor manera.

Región de estados unidos

Capacidad total de la cuenta Cantidad de Requests (Asumiendo 1K por objeto) Ancho de Banda para Storage Geo-Redundante Ancho de Banda para Storage Localmente Redundante
500 TB 20.000 entidades o mensajes por segundo Entrada: Hasta 10GB por segundo.

Salida: Hasta 20GB por segundo.

Entrada: Hasta 20GB por segundo.

Salida: Hasta 30GB por segundo.

Europa y Asia

Capacidad total de la cuenta Cantidad de Requests (Asumiendo 1K por objeto) Ancho de Banda para Storage Geo-Redundante Ancho de Banda para Storage Localmente Redundante
500 TB 20.000 entidades o mensajes por segundo Entrada: Hasta 5GB por segundo.

Salida: Hasta 10GB por segundo.

Entrada: Hasta 10GB por segundo.

Salida: Hasta 15GB por segundo.

Rendimiento para una partición de cada servicio de Storage

Un blob: Hasta 60MB o 500 request por segundo.

Una cola (Mensajes de 1K): Hasta 2000 mensajes por segundo.

Una tabla (Entidades de 1K): Hasta 2000 mensajes por segundo.

Cada objeto que se almacena en Azure Storage (Blobs, Mensajes y Entidades) se encuentra en un Partition Key, y se identifica por este mismo. El Partition Key determina cómo Azure Storage balancea la carga entre blobs, mensajes y entidades a través de servidores. El Partition Key es único dentro de la cuenta de almacenamiento y se utiliza para localizar un blob, mensaje, o entidad.

Para las tablas, todas las entidades con el mismo valor de Partition Key se agrupan en la misma partición y se almacenan en el mismo servidor de particiones. Este es un punto importante para el diseño de la aplicación. Su aplicación debe equilibrar la escalabilidad a través de múltiples particiones con las ventajas de agrupar datos en una sola partición. Una ventaja clave de tener entidades en una misma partición es la posibilidad de realizar operaciones atómicas en todas las entidades que pertenecen a dicha partición.

Los Partition Key afectan al balanceo de carga y escalabilidad para cada uno de los servicios.

Blobs: El Partition Key para un blob es nombre del contenedor + nombre blob. Esto significa que cada blob tiene su propia partición. Por lo tanto, los Blobs se puede distribuir a través de muchos servidores con el fin de escalar el acceso. Al mismo tiempo los blobs pueden ser agrupados lógicamente en contenedores (Containers) pero no hay implicaciones de particiones en esta agrupación.

Colas: El Partition Key de un mensaje es el nombre de la cola, por lo que todos los mensajes en una cola se agrupan en una sola partición y son atendidos por un solo servidor. Diferentes colas pueden ser tratadas por diferentes servidores para equilibrar la carga para. El que los mensajes se encuentren todos en un único servidor no implica que el mismo no tenga copias para respaldar los datos.

Tablas: para el caso de las entidades en una tabla existe la propiedad Partition Key que determina la partición donde se encontrará la misma. Distintas entidades dentro de una tabla se pueden encontrar en la misma partición. Una aplicación puede realizar operaciones atómicas sobre las entidades dentro de una misma partición, ya que se encuentran en el mismo servidor. Las entidades que están en la misma tabla, pero que pertenecen a diferentes particiones puede equilibrar la carga entre los distintos servidores, por lo que es posible tener una gran cantidad de entidades con una mayor escalabilidad.

Diferencias entre el emulador de Storage y Azure Storage Services

Por lo general cuando estamos desarrollando aplicaciones para la plataforma de Azure solemos utilizar muchas veces funcionalidad emulada en nuestro ambiente de desarrollo. En la mayoría de los casos esto es transparente y no requiere realizar ningún ajuste más que el cambio de configuración al pasarlo a un ambiente productivo en Azure. Sin embargo, es importante conoces que diferencia hay entre ambos ambientes, para ser conscientes si debemos tener alguna consideración particular para nuestro caso puntual.

  • La cuenta del emulador solo posee una key fija para la seguridad. Esta cuenta y la clave son las únicas credenciales autorizadas.

Account name: devstoreaccount1
Account key: Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==

Algunas aclaraciones:

La clave de autenticación soportada por el emulador tiene como finalidad probar la funcionalidad de autenticación a Storage de la aplicación. No posee ningún propósito de seguridad.

El emulador no es un servicio estable de almacenamiento escalable y no soporta demasiada concurrencia.

  • El esquema URI soportado por el emulador de almacenamiento es diferente del esquema URI de los servicios en Azure. El esquema URI desarrollo especifica el nombre de la cuenta como parte de la ruta de acceso jerárquica del URI, y no como parte del nombre de dominio.

 

  • El emulador solo soporta blobs de hasta 2 GB.

 

  • Una operación PUT sobre un Blob puede ser exitosa en el emulador y tener un lease activo, incluso si el ID del lease no se ha especificado.

 

  • Para las tablas los campos del tipo fecha tienen el mismo soporte que SQL 2005. Deben ser posteriores a 1 de Enero de 1753. La precisión de la fecha está limitada a la precisión de SQL 2005, o sea, 1/300 segundos.

 

  • El tamaño total del account name, table name, partition key y row key no puede exceder los 900 bytes en el emulador (la suma de los campos). La entidad en el emulador está limitada a un total de 1 M.

 

  • En las tablas del emulador, los campos de tipo Guid o Binary solo soportan operadores de igualdad y desigualdad como filtros de un query.

 

  • Al montar un disco en el emulador debe estar respaldado por un blob que esté guardado en el emulador. No es posible montar un disco en el emulador donde el blob se encuentre en una cuenta de Azure Storage.