Recomendaciones para Cloud Storage

En esta página, se incluye un índice de prácticas recomendadas para Cloud Storage. Puedes usar la información recopilada aquí como referencia rápida de lo que debes tener en cuenta cuando compiles una aplicación que use Cloud Storage.

Si recién empiezas a usar Cloud Storage, es posible que esta página no sea el mejor sitio para comenzar, ya que no incluye los conceptos básicos sobre cómo usar Cloud Storage. Si eres un usuario nuevo, te sugerimos que comiences con la guía de inicio rápido sobre cómo usar Console o la guía de inicio rápido sobre cómo usar la herramienta de gsutil.

Nombre

Consulta los temas Asignación de nombres de buckets y Asignación de nombres de objetos para conocer los requisitos y las consideraciones relacionadas con el nombre.

Tráfico

  • Asegúrate de usar una biblioteca HTTPS que valide los certificados del servidor. Si tu aplicación no usa la validación del certificado del servidor, puede ser vulnerable a los ataques de intermediarios o a otros tipos de ataques.

  • Realiza una estimación aproximada de la cantidad de tráfico que se enviará a Cloud Storage. En particular, ten en cuenta esta información:

    • Las operaciones por segundo. ¿Cuántas operaciones por segundo esperas que realicen los depósitos y los objetos? ¿y para las operaciones de creación, actualización y eliminación?

    • El ancho de banda. ¿Cuántos datos se enviarán y durante cuánto tiempo?

    • El control de caché. Especificar los metadatos Cache-Control en los objetos beneficiará la latencia de lectura en los objetos activos o de acceso frecuente. Consulta Visualiza y edita metadatos para obtener instrucciones sobre la configuración de metadatos de objetos como Cache-Control.

  • Diseña tu aplicación para minimizar los aumentos repentinos en el tráfico. Si hay clientes de tu aplicación que realizan actualizaciones, distribúyelos a lo largo del día.

  • Para mejorar el rendimiento de los objetos que pueden almacenarse en caché públicamente, los datos de proxy se transfieren a través de una aplicación de App Engine que se encuentra en la misma ubicación que tu bucket.

  • Para mejorar el rendimiento cuando escalas al mejor rendimiento, sigue los Lineamientos de distribución de acceso y porcentaje de solicitudes.

  • Ten en cuenta que existen límites de frecuencia para ciertas operaciones y límites de ancho de banda para ciertos tipos de salida, y diseña tu aplicación según corresponda.

  • Si recibes un error, haz lo siguiente:

    • Usa la retirada exponencial como parte de tu estrategia de reintento para evitar problemas debido a grandes aumentos de actividad en el tráfico.

    • Vuelve a intentarlo con una conexión nueva y, quizás, una resolución nueva del nombre de dominio. Esto ayuda a evitar la "persistencia del servidor", en la que un reintento trata de pasar por la misma ruta y llega al mismo componente en mal estado que la solicitud inicial.

  • Si tu aplicación es sensible a la latencia, usa solicitudes encubiertas. Las solicitudes encubiertas te permiten volver a intentarlo más rápido y reducir la latencia final. Lo hacen sin reducir el plazo de solicitud, lo que podría provocar que las solicitudes agoten el tiempo de espera de manera prematura. Para obtener más información, consulta The Tail at Scale.

  • Comprende el nivel de rendimiento que los clientes esperan de tu aplicación. Esta información te ayudará a elegir una opción de almacenamiento y una región cuando crees nuevos buckets.

Opciones de almacenamiento de datos y ubicaciones

Consulta los temas Clase de almacenamiento y Ubicación del bucket para obtener información sobre cómo almacenar mejor tus datos.

LCA y control de acceso

  • Las solicitudes de Cloud Storage se refieren a los depósitos y los objetos por sus nombres. Como resultado, a pesar de que las LCA evitarán que terceros no autorizados operen en objetos o depósitos, un tercero puede intentar ejecutar solicitudes con nombres de objetos o depósitos y determinar su existencia, si observa las respuestas de error. Debido a esto, puede que se filtre la información en los nombres de objetos o depósitos. Si te preocupa la privacidad de los nombres de tu bucket o de tu objeto, debes tomar las siguientes precauciones adecuadas:

    • Elegir nombres de depósitos y de objetos que sean difíciles de adivinar. Por ejemplo, un bucket llamado mybucket-gtbytul3 es lo bastante aleatorio como para evitar que terceros no autorizados puedan adivinarlo o enumerar otros nombres de bucket s a partir de él.

    • Evitar el uso de información sensible como parte de los nombres de objetos o depósitos. Por ejemplo, en lugar de nombrar tu bucket mysecretproject-prodbucket, asígnale el nombre somemeaninglesscodename-prod. En algunas aplicaciones, es posible que desees mantener los metadatos sensibles en encabezados personalizados de Cloud Storage , como x-goog-meta, en lugar de codificar los metadatos en los nombres de los objetos.

  • Usa grupos en lugar de enumerar de forma explícita grandes cantidades de usuarios. Esto escala mejor y proporciona una forma muy eficiente de actualizar el control de acceso para una gran cantidad de objetos a la vez. Por último, es más barato, ya que no es necesario realizar una solicitud por objeto para cambiar las LCA.

  • Antes de agregar objetos a un depósito, verifica que las LCA de objetos predeterminadas se configuren de acuerdo con tus requisitos. Esto puede ahorrarte mucho tiempo de actualización de las LCA para objetos individuales.

  • Las LCA de los bucket s y objetos son independientes entre sí, lo que significa que las LCA de un bucket no afectan a las LCA de los objetos dentro de ese bucket. Es posible que un usuario que no cuenta con permisos para un bucket tenga permisos para un objeto dentro del bucket. Por ejemplo, puedes crear un bucket de tal forma que solo se otorgue permiso a GroupA para enumerar los objetos del bucket, pero luego puedes subir un objeto en ese bucket que permita que GroupB acceda al READ del objeto. El GroupB podrá leer el objeto, pero no podrá ver los contenidos del bucket o realizar tareas relacionadas con el bucket.

  • El sistema de control de acceso de Cloud Storage incluye la capacidad de especificar que los objetos se puedan leer de forma pública. Asegúrate de que deseas que los objetos que escribes con este permiso sean públicos. Una vez que se “publican”, los datos en Internet se pueden copiar en muchos lugares, por lo que es imposible recuperar el control de lectura sobre un objeto escrito con este permiso.

  • El sistema de control de acceso de Cloud Storage incluye la capacidad de especificar que los depósitos se puedan escribir de forma pública. Si bien configurar un bucket de esta manera puede ser conveniente para varios objetivos, recomendamos no usar este permiso, ya que se puede abusar de él con el fin de distribuir contenido ilegal, virus y otros tipos de software malicioso. El dueño del bucket es responsable de forma legal y financiera del contenido almacenado en su bucket.

    Si necesitas que el contenido esté disponible de forma segura para los usuarios que no tienen Cuentas de Google, recomendamos que uses URL firmadas. Por ejemplo, con las URL firmadas, puedes proporcionar un vínculo a un objeto y los clientes de tu aplicación no necesitarán autenticarse con Cloud Storage para acceder al objeto. Cuando creas una URL firmada, controlas el tipo (de lectura, escritura y borrado) y la duración del acceso.

  • Si usas gsutil, consulta estas recomendaciones adicionales.

Cargas de datos

  • Si usas devoluciones de llamadas XMLHttpRequest (XHR) para obtener actualizaciones de progreso, no cierres y vuelvas a abrir la conexión si detectas que el progreso se detuvo. Si lo haces, se creará un bucle de reacción positivo indeseado cuando haya congestión en la red. Cuando la red está congestionada, las devoluciones de llamada XHR se pueden atrasar detrás de la actividad de confirmación (ACK y NACK) de la transmisión de la carga. Si se cierra y se vuelve a abrir la conexión cuando esto sucede, se usa más capacidad de la red en el preciso momento en el que menos lo puedes permitir.

  • Para subir tráfico, recomendamos configurar tiempos de espera de una duración razonable. Para asegurar una experiencia óptima del usuario final, puedes establecer un cronómetro del lado del cliente que actualice la ventana del estado del cliente con un mensaje (p. ej., “congestión de la red”) cuando tu aplicación no haya recibido una devolución de llamada XHR durante mucho tiempo. No cierres la conexión y vuelvas a intentarlo cuando esto suceda.

  • Si usas instancias de Compute Engine con procesos que POST a Cloud Storage para iniciar una carga reanudable, entonces debes usar instancias de Compute Engine en las mismas ubicaciones que tus depósitos de Cloud Storage. Puedes usar un servicio de IP geográfico para seleccionar la región de Compute Engine a la que enrutarás las solicitudes de los clientes, lo que te ayuda a tener el tráfico ubicado en una región geográfica.

  • Para las cargas reanudables, la sesión reanudable debe permanecer en la región en la que se creó. Esto reduce el tráfico entre regiones que se genera cuando se escribe o se lee el estado de la sesión, lo que mejora el rendimiento de la carga reanudable.

  • Si es posible, evita dividir una transferencia en fragmentos más pequeños y, en su lugar, sube todo el contenido en un solo fragmento. Sin la fragmentación, se quitan los costos de latencia y los cargos de operación agregados por las consultas de desplazamiento persistente de cada fragmento, y se mejora la capacidad de procesamiento. Sin embargo, debes considerar subir el contenido en fragmentos en los siguientes casos:

    • Tus datos de origen se generan de forma dinámica y quieres limitar la cantidad que necesitas almacenar en búfer del cliente, en caso de que falle la carga.
    • Tus clientes tienen limitaciones de tamaño de solicitudes, como es el caso de muchos navegadores.

    Si tus clientes reciben un error, pueden consultar el servidor por el desplazamiento persistente y reanudar la carga de los bytes restantes de ese desplazamiento.

  • Una forma fácil y conveniente de reducir el ancho de banda necesario para cada solicitud es habilitar la compresión gzip. Aunque esto requiere un tiempo de CPU adicional para descomprimir los resultados, la compensación con los costos de la red suele hacer que valga la pena.

    Por lo general, un objeto que se subió en formato gzip se puede también entregar en formato gzip. Sin embargo, evita subir contenido que tenga un content-encoding: gzip o un content-type comprimido, ya que esto puede provocar un comportamiento inesperado.

Eliminación de datos

Consulta Borra objetos para obtener lineamientos y consideraciones sobre cómo borrar datos. También puedes usar las funciones para controlar los ciclos de vida de los datos a fin de evitar que el software o los usuarios de la aplicación borren los datos de forma errónea.