Recomendaciones para Google 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 Comienza a usar GCP Console o Comienza a usar la herramienta gsutil.

Nombres

  • El espacio de nombres del depósito es global y tiene visibilidad pública. Cada nombre de depósito debe ser único en todo el espacio de nombres de Cloud Storage. Si deseas obtener más información, consulta las Indicaciones para nombrar depósitos y objetos.

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

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

  • 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 los nombres de depósitos, consulta Requisitos de 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 de forma profunda, como las estructuras 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 Guías sobre el porcentaje de solicitudes y la distribución de acceso.

Tráfico

  • 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é. La especificación de los metadatos de Cache-Control en los objetos beneficiará la latencia de lectura en objetos en caliente o de acceso frecuente. Consulta Observa y edita metadatos para obtener instrucciones sobre cómo configurar 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 de solicitudes altos, sigue las Guías sobre el porcentaje de solicitudes y la distribución de acceso.

  • 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 entregarán a una velocidad elevada con alta disponibilidad deben usar las clases Multi-Regional Storage o Regional Storage. Estas clases proporcionan 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 una 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 de la UE y, para los datos de EE.UU., puedes elegir un depósito de EE.UU. Para obtener más información, consulta Ubicaciones de los depósitos.

  • Ten en cuenta los requisitos de cumplimiento cuando elijas una ubicación para los datos del usuario. ¿Existen requisitos legales en torno a las ubicaciones en 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 tokens 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 la solución de problemas, asegúrate de limpiar o revocar cualquier credencial que aparezca como parte del resultado.

  • Usa siempre TLS (HTTPS) para transportar tus datos cuando puedas. Esto garantiza que tus credenciales y tus datos estarán protegidos mientras transportas 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 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, antes de la versión 3.2, Python no tenía compatibilidad integrada o completa para la validación de certificados del servidor y debías usar bibliotecas de wrapper de terceros a fin de asegurarte de que tu aplicación validará certificados del servidor. El complemento de boto incluye un código que valida certificados del servidor de forma predeterminada.

  • Cuando las aplicaciones ya no necesitan acceso a tus datos, debes revocar sus credenciales de autenticación. Para los servicios y las API de Google, puedes hacerlo si accedes a tus Permisos de la Cuenta de Google, 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, considera 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 suficientemente aleatorio como para que terceros no autorizados no 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 a tu depósito mysecretproject-prodbucket, nómbralo 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 una gran cantidad de usuarios. Esto escala mejor y, también, 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 depósitos y objetos son independientes entre sí, lo que significa que las LCA en un depósito no afectan a las LCA en los objetos dentro de ese depósito. Es posible que un usuario que no tiene permisos de acceso a un depósito tenga permisos para acceder a un objeto dentro del depósito. Por ejemplo, puedes crear un depósito de tal manera 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 otorgue a GroupB permiso de READ en el objeto. GroupB podrá leer el objeto, pero no podrá ver el contenido 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 dueño 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 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.

Subida 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 el tráfico de carga, te recomendamos establecer tiempos de espera de una extensión razonable. Para una experiencia del usuario final óptima, 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 recibió 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 en Cloud Storage para iniciar una carga reanudable, debes usar las 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 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ó. Eso reduce el tráfico entre regiones que surge 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 la cantidad de 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 (que es cierto para muchos navegadores) o cuando tus clientes no pueden transmitir bytes en una sola 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 content-encoding: gzip y content-type que esté comprimido, ya que puede generar comportamiento inesperado.

Borrado 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:

Lista 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 de forma definitiva del sistema de almacenamiento subyacente de inmediato, por lo tanto, 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 operaciones de eliminación recientes. Por ejemplo, si tratas 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 lista de objetos a fin de generar la solicitud de enumeración siguiente, en lugar de reiniciarla desde el principio para cada solicitud. Cuando reinicias tu enumeración desde el principio, cada solicitud debe omitir todos los objetos que se borraron, lo que hace que la enumeración de objetos sea más lenta. Si borraste muchos objetos con un prefijo determinado, trata de evitar las listas de objetos con ese prefijo justo después de las operaciones de eliminación.

Hosting del sitio 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 que el contenido en storage.googleapis.com pueda acceder. 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 todos los storage.googleapis.com.

¿Te sirvió esta página? Envíanos tu opinión:

Enviar comentarios sobre…

¿Necesitas ayuda? Visita nuestra página de asistencia.