Recomendaciones para Cloud Storage

Introducción

En esta página, se presenta un resumen de las recomendaciones tomadas de otras páginas en la documentación de Cloud Storage. Puedes usar las recomendaciones que aquí se enumeran como referencia rápida de lo que debes tener en cuenta cuando compilas una aplicación que usa Cloud Storage. Sigue estas recomendaciones cuando inicies una aplicación comercial.

Si recién empiezas a usar Cloud Storage, puede que esta página no sea el mejor punto de partida, ya que no se enseñan los conceptos básicos sobre cómo usar Cloud Storage. Si eres un usuario nuevo, te sugerimos que empieces con Guía de inicio rápido: usa GCP Console o Guía de inicio rápido: usa la herramienta de gsutil.

Nombres

  • El espacio de nombres del depósito es global y visible de forma pública. Cada nombre de depósito debe ser único en todo el espacio de nombres de Cloud Storage. Para obtener más información, consulta los Lineamientos para asignación de nombres de depósitos y de objetos.

  • Si necesitas muchos depósitos, usa GUID o un equivalente para los nombres de los depósitos, coloca una lógica de reintento en tu código a fin de controlar los conflictos con los nombres y mantén una lista para hacer referencias cruzadas de tus depósitos. Otra opción es usar depósitos con nombres de dominio y administrar los nombres como subdominios.

  • No uses ID de usuario, direcciones de correo electrónico, nombres o números de proyectos o cualquier otra información de identificación personal (PII) en los nombres de los depósitos, ya que cualquier persona puede buscar la existencia de un depósito. De manera similar, ten mucho cuidado con poner PII en los nombres de objetos, dado que estos nombres aparecen en las URL de los objetos.

  • Los nombres de los depósitos deben cumplir con las convenciones de nombres estándar de DNS, debido a que el nombre de un depósito puede aparecer en un registro DNS como parte de un redireccionamiento de CNAME. Para obtener detalles sobre los requisitos de nombres de los depósitos, consulta Requisitos para los nombres de depósitos.

  • Las barras diagonales en los objetos no tienen significado especial en Cloud Storage, ya que no hay compatibilidad nativa de directorio. Debido a esto, las estructuras anidadas en profundidad similares a directorios, como las que usan delimitadores de barras, están permitidas, pero no tendrán el rendimiento de un sistema de archivos nativo que enumera subdirectorios anidados de forma profunda.

  • Evita el uso de nombres de archivos secuenciales, como los nombres de archivos basados en marcas de tiempo, si subes muchos archivos en paralelo. Debido a que los archivos con nombres secuenciales se almacenan de forma consecutiva, es probable que lleguen al mismo servidor del backend, lo que significa que la capacidad de procesamiento se limitará. Para lograr una capacidad de procesamiento óptima, puedes agregar el hash del número de secuencia como parte del nombre del archivo para que no sea secuencial. Para obtener más información, consulta Lineamientos de distribución de acceso y porcentaje de solicitudes.

Tráfico

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

    • 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 picos de tráfico. Si hay clientes de tu aplicación que realizan actualizaciones, distribúyelos a lo largo del día.

  • Si bien Cloud Storage no tiene un límite superior en el porcentaje de solicitudes, para lograr el mejor rendimiento cuando escalas los porcentajes altos de solicitudes, 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 diseña tu aplicación según corresponda.

  • Si recibes un error, usa la retirada exponencial para evitar problemas debido a los picos de tráfico grandes.

  • 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 depósitos nuevos.

Regiones y opciones de almacenamiento de datos

  • Los datos que se entreguen a una velocidad elevada con alta disponibilidad deben usar la clase Standard Storage. Esta clase proporciona la mejor disponibilidad con la compensación de un precio más alto.

  • Los datos a los que se accederá con poca frecuencia y que pueden tolerar una disponibilidad un poco menor se pueden almacenar con las clases Nearline Storage o Coldline Storage.

  • Almacena tus datos en la región más cercana a los usuarios de tu aplicación. Por ejemplo, para los datos de la UE, puedes elegir un depósito en la UE y, para los datos de EE.UU., puedes elegir un depósito en EE.UU. Para obtener más información, consulta Ubicaciones de depósitos.

  • Ten en cuenta los requisitos de cumplimiento cuando elijas una ubicación para los datos del usuario. ¿Existen requisitos legales relacionados con las ubicaciones en las que tus usuarios proporcionarán datos?

Seguridad, LCA y control de acceso

  • La primera y principal precaución es: nunca compartas tus credenciales. Cada usuario debe tener credenciales distintas.

  • Cuando imprimes los detalles del protocolo HTTP, tus credenciales de autenticación, como los token de OAuth 2.0, se pueden ver en los encabezados. Si necesitas publicar los detalles del protocolo en una pizarra de mensajes o debes proporcionar los detalles del protocolo HTTP para solucionar problemas, asegúrate de limpiar o revocar cualquier credencial que aparezca como parte del resultado.

  • Siempre que puedas, usa TLS (HTTPS) para transportar tus datos. Esto garantiza que tus credenciales y tus datos estarán protegidos cuando transportes datos a través de la red. Por ejemplo, para acceder a la API de Cloud Storage, debes usar https://storage.googleapis.com.

  • Asegúrate de usar una biblioteca HTTPS que valide los certificados del servidor. La falta de validación de certificados del servidor hace que tu aplicación sea vulnerable a los ataques de intermediarios o a otros tipos de ataques. Ten en cuenta que las bibliotecas HTTPS que se envían con ciertos lenguajes de implementación de uso común no verifican los certificados del servidor de forma predeterminada. Por ejemplo, las versiones de Python anteriores a la 3.2 no tienen compatibilidad integrada o completa para la validación de certificados del servidor, por lo que debes usar bibliotecas de wrapper de terceros a fin de asegurarte de que tu aplicación validará los certificados del servidor. El complemento de boto incluye un código que valida los certificados del servidor de forma predeterminada.

  • Cuando las aplicaciones ya no necesitan acceso a tus datos, debes revocar sus credenciales de autenticación. En los servicios y las API de Google, puedes hacerlo si accedes a los Permisos de tu Cuenta de Google y haces clic en las aplicaciones innecesarias y, luego, en Quitar acceso.

  • Asegúrate de almacenar tus credenciales de forma segura. Esto se puede hacer de maneras diferentes según tu entorno y la ubicación en que almacenas tus credenciales. Por ejemplo, si almacenas tus credenciales en un archivo de configuración, asegúrate de establecer los permisos adecuados en ese archivo para evitar acceso no deseado. Si usas Google App Engine, se recomienda usar StorageByKeyName para almacenar tus credenciales.

  • 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 depósito 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 depósito llamado mybucket-gtbytul3 es lo bastante aleatorio como para evitar que terceros no autorizados puedan adivinarlo o enumerar otros nombres de depósitos 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 depósito 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 los grupos en preferencia para 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 necesitas 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 depósitos y objetos son independientes entre sí, lo que significa que las LCA de un depósito no afectan a las LCA de los objetos dentro de ese depósito. Es posible que un usuario que no cuenta con permisos para un depósito tenga permisos para un objeto dentro del depósito. Por ejemplo, puedes crear un depósito de tal forma que solo se otorgue permiso a GroupA para enumerar los objetos del depósito, pero luego puedes subir un objeto en ese depósito que permita que GroupB acceda al READ del objeto. El GroupB podrá leer el objeto, pero no podrá ver los contenidos del depósito o realizar tareas relacionadas con el depósito.

  • 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 depósito 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 propietario del depósito es responsable de forma legal y financiera del contenido almacenado en su depósito.

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

  • Si usas gsutil, consulta estas recomendaciones adicionales.

Carga 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á una retroalimentación positiva indeseada 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 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 envían solicitudes POST a Cloud Storage para iniciar una carga reanudable, entonces debes usar las instancias de Compute Engine en las mismas ubicaciones que tus depósitos de Cloud Storage. Luego puedes usar un servicio de IP de ubicación geográfica para seleccionar la región de Compute Engine a la que enrutas las solicitudes de los clientes, lo que ayudará a mantener 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. Evitar la fragmentación quita los costos de latencia fijos y mejora la capacidad de procesamiento, además de reducir las QPS en Cloud Storage.

    Las situaciones en las que deberías considerar realizar cargas en fragmentos incluyen los momentos en que tus datos de origen se generan de forma dinámica, cuando tus clientes tienen limitaciones de tamaño de solicitudes (lo que sucede en muchos navegadores) o cuando tus clientes no pueden transmitir bytes en una única solicitud sin cargar primero la solicitud completa en la memoria. Si tus clientes reciben un error, pueden consultar el servidor para desplazar la confirmación y reanudar la carga de los bytes restantes de ese desplazamiento.

  • Si es posible, 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

Si te preocupa que el software de tu aplicación o los usuarios puedan borrar o reemplazar objetos por error en algún momento, Cloud Storage tiene las características siguientes que te ayudan a proteger tus datos:

Enumeración de objetos

Si acabas de borrar muchos objetos de tu depósito, la enumeración de objetos podría volverse muy lenta por un tiempo. Esto se debe a que los registros borrados no se borran definitivamente del sistema de almacenamiento subyacente de inmediato, por lo que la enumeración de objetos debe omitir los registros borrados cuando busca los objetos para mostrar.

Por último, los registros borrados se quitan del sistema de almacenamiento subyacente y el rendimiento de la enumeración de objetos vuelve a la normalidad. Este proceso suele tardar algunas horas, pero en algunos casos, puede tardar unos días.

Debes diseñar tu carga de trabajo para evitar enumerar un rango de objetos con muchas eliminaciones recientes. Por ejemplo, si tratas de borrar objetos de un depósito mediante su enumeración y eliminación, debes usar el token de la página que muestra la respuesta de la enumeración de objetos a fin de generar la próxima solicitud de enumeración, en lugar de reiniciarla desde el principio para cada solicitud. Cuando reinicias la enumeración desde el principio, cada solicitud debe omitir todos los objetos que se acaban de borrar, lo que hace que la enumeración de objetos sea más lenta. Si borraste muchos objetos con un prefijo determinado, trata de no enumerar objetos con ese prefijo justo después de las operaciones de eliminación.

Hosting de sitios web

En el tema Uso compartido de recursos multiorigen (CORS), se describe cómo permitir que las secuencias de comandos alojadas en otros sitios web accedan a los recursos estáticos almacenados en un depósito de Cloud Storage. La situación inversa se da cuando permites que las secuencias de comandos alojadas en Cloud Storage accedan a los recursos estáticos alojados en un sitio web externo a Cloud Storage. En esta última situación, el sitio web entrega encabezados de CORS para permitir el acceso al contenido en storage.googleapis.com. Se recomienda que dediques un depósito específico para el acceso a estos datos. Por ejemplo, es mejor que el sitio web entregue el encabezado de CORS Access-Control-Allow-Origin: https://mybucket.storage.googleapis.com, en lugar de Access-Control-Allow-Origin: https://storage.googleapis.com. Este método evita que tu sitio exponga de forma involuntaria los recursos estáticos a todo storage.googleapis.com.

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...

Si necesitas ayuda, visita nuestra página de asistencia.