Este documento describe las mejores prácticas recomendadas para usar la API de Compute Engine y está dirigido a usuarios que ya están familiarizados con ella. Si eres principiante, obtén información sobre los requisitos previos y el uso de la API de Compute Engine .
Seguir estas mejores prácticas puede ayudarle a ahorrar tiempo, evitar errores y mitigar los efectos de las cuotas de tarifas .
Usar bibliotecas cliente
Las bibliotecas cliente son la forma recomendada de acceder mediante programación a la API de Compute Engine. Las bibliotecas cliente proporcionan código que le permite acceder a la API a través de lenguajes de programación comunes, lo que puede ahorrarle tiempo y mejorar el rendimiento de su código.
Obtenga más información sobre las bibliotecas cliente de Compute Engine y las mejores prácticas de bibliotecas cliente .
Genere solicitudes REST utilizando la consola de la nube
Al crear un recurso, genere la solicitud REST utilizando las páginas de creación de recursos o las páginas de detalles en la consola de Google Cloud. El uso de una solicitud REST generada ahorra tiempo y ayuda a prevenir errores de sintaxis.
Aprenda a generar solicitudes REST .
Esperar a que se realicen las operaciones.
No dé por sentado que una operación (cualquier solicitud de API que cambie un recurso) esté completa o sea exitosa. En su lugar, utilice un método wait para que el recurso Operation verifique que la operación esté realizada. (No es necesario verificar una solicitud que no modifica recursos, como una solicitud de lectura que utiliza un verbo GET HTTP, porque la respuesta de la API ya indica si la solicitud fue exitosa. En consecuencia, la API de Compute Engine no devuelve recursos de Operation para estas solicitudes).
Siempre que una solicitud API se inicia con éxito, devuelve un código de estado HTTP 200 . Aunque recibir un 200 indica que el servidor recibió su solicitud de API con éxito, este código de estado no indica si la operación solicitada se completó con éxito o no. Por ejemplo, puede recibir un 200 , pero es posible que la operación aún no se haya completado o que haya fallado.
Cualquier solicitud para crear, actualizar o eliminar para una operación de larga duración devuelve un recurso Operation , que captura el estado de esa solicitud. Una operación se realiza cuando el campo status del recurso Operation está DONE . Para comprobar el estado, utilice el método wait que coincida con el alcance del recurso Operation devuelto:
- Para operaciones zonales, utilice
zoneOperations.wait. - Para operaciones regionales, utilice
regionOperations.wait. - Para operaciones globales, utilice
globalOperations.wait.
El método wait regresa cuando finaliza la operación o cuando la solicitud se acerca al plazo de 2 minutos. Cuando utilice el método wait , evite los sondeos breves, que son cuando sus clientes realizan solicitudes continuamente al servidor sin esperar una respuesta. Usar el método wait en un ciclo de reintento con retroceso exponencial para verificar el estado de su solicitud, en lugar de usar el método get con sondeo breve para el recurso Operation , ayuda a preservar sus cuotas de velocidad y reduce la latencia.
Para obtener más información y ejemplos de uso del método wait , consulte Manejo de respuestas de API .
Para comprobar el estado de una operación solicitada, consulte Comprobación del estado de la operación .
Mientras espera que se complete una operación, tenga en cuenta el período mínimo de retención de la operación , ya que las operaciones completadas podrían eliminarse de la base de datos después de este período.
Paginar resultados de la lista
Cuando utilice un método de lista (como un método *.list , un método *.aggregatedList o cualquier otro método que devuelva una lista), pagina los resultados siempre que sea posible para asegurarse de leer la respuesta completa. Si no pagina, solo puede recibir hasta los primeros 500 elementos según lo determinado por el parámetro de consulta maxResults .
Para obtener más información sobre la paginación en Google Cloud, consulte Paginación de listas . Para obtener detalles y ejemplos específicos, consulte la documentación de referencia del método de lista que desea utilizar, como instances.list .
También puede utilizar las bibliotecas cliente de la nube para manejar la paginación .
Utilice filtros de lista del lado del cliente para evitar errores de cuota
Cuando utiliza filtros con los métodos *.list o *.aggregatedList , incurre en cargos de cuota adicionales si hay más de 10.000 recursos filtrados de las solicitudes. Para obtener más información, consulte filtered_list_cost_overhead en Tarifar cuotas.
Si su proyecto excede esta cuota de tarifa, recibirá un error 403 con el motivo rateLimitExceeded . Para evitar este error, utilice filtros del lado del cliente para las solicitudes de lista.
Confíe en los códigos de error, no en los mensajes de error
Las API de Google deben utilizar los códigos de error canónicos definidos en google.rpc.Code , pero los mensajes de error pueden estar sujetos a cambios sin previo aviso. Los mensajes de error generalmente están destinados a que los lean los desarrolladores, no los programas.
Obtenga más información sobre los errores de API .
Minimice los reintentos del lado del cliente para preservar las cuotas de tarifas
Minimice el número de reintentos del lado del cliente para un proyecto para evitar errores rateLimitExceeded y maximizar la utilización de sus cuotas de tarifas . Las siguientes prácticas pueden ayudarle a conservar las cuotas de tarifas para sus proyectos:
- Evite las encuestas breves.
- Utilice el estallido con moderación y selectivamente.
- Realice siempre sus llamadas en un ciclo de reintento con retroceso exponencial.
- Utilice un limitador de tasa del lado del cliente.
- Divida sus aplicaciones en varios proyectos.
Evite las encuestas breves
Evite las encuestas breves, en las que sus clientes realizan solicitudes continuamente al servidor sin esperar una respuesta. Si realiza una encuesta corta, es más difícil detectar solicitudes incorrectas que cuentan para su cuota, incluso si no arrojan datos útiles.
En lugar de realizar un sondeo breve, debe esperar a que se realicen las operaciones .
Utilice el estallido con moderación y selectivamente
Utilice el estallido con moderación y selectivamente. Bursting es el acto de permitir que un cliente específico realice muchas solicitudes de API en poco tiempo. Por lo general, la ráfaga se realiza en respuesta a escenarios excepcionales, como casos en los que su aplicación necesita manejar más tráfico de lo habitual. La explosión agota rápidamente su cuota de tarifas, así que asegúrese de usarla solo cuando sea necesario.
Cuando sea necesario realizar ráfagas, utilice API por lotes dedicadas cuando sea posible, como la API de instancias masivas o grupos de instancias administrados .
Obtenga más información sobre las solicitudes por lotes .
Realice siempre sus llamadas en un ciclo de reintento con retroceso exponencial
Utilice el retroceso exponencial para espaciar progresivamente las solicitudes cuando se agote el tiempo de espera o cuando alcance su cuota de tarifa.
Cualquier ciclo de reintento debe tener un retroceso exponencial que garantice que los reintentos frecuentes no sobrecarguen su aplicación ni excedan sus cuotas de velocidad. De lo contrario, corre el riesgo de afectar negativamente a todos los demás sistemas del mismo proyecto.
Si necesita un ciclo de reintento para una operación que falló porque alcanzó la cuota de tasa, su estrategia de retroceso exponencial debería permitir suficiente tiempo entre reintentos para que se rellene el depósito de cuota (generalmente cada minuto).
Alternativamente, si necesita un ciclo de reintento cuando la espera de una operación alcanza el tiempo de espera, el intervalo máximo de su estrategia de retroceso exponencial no debe exceder el período de retención mínimo de la operación. De lo contrario, es posible que reciba un error de operación Not Found .
Para ver un ejemplo de implementación de retroceso exponencial, consulte el algoritmo de retroceso exponencial para la API de administración de acceso e identidad.
Utilice un limitador de tasa del lado del cliente
Utilice un limitador de tasa del lado del cliente. Un limitador de tarifas del lado del cliente establece un límite artificial para que el cliente en cuestión sólo pueda utilizar una determinada cantidad de cuota, lo que evita que un cliente consuma toda su cuota.
Divida sus aplicaciones en varios proyectos
Dividir sus aplicaciones en varios proyectos puede ayudar a minimizar la cantidad de solicitudes para sus depósitos de cuota. Dado que las cuotas se aplican a nivel de proyecto, puede dividir sus aplicaciones para que cada aplicación tenga su propio grupo de cuotas dedicado.
Resumen de la lista de verificación
La siguiente lista de verificación resume las mejores prácticas para usar la API de Compute Engine.
- Usar bibliotecas cliente
- Genere solicitudes REST utilizando la consola de la nube
- Esperar a que se realicen las operaciones.
- Paginar resultados de la lista
- Confíe en los códigos de error, no en los mensajes de error
- Minimice los reintentos del lado del cliente para preservar las cuotas de tasas de API
¿Qué sigue?
- Aprenda cómo mejorar el rendimiento al utilizar la API de Compute Engine .