Conceptos de Implementación¶

Cuando implementas una aplicaciónFastAPI, o en realidad, cualquier tipo de API web, hay varios conceptos que probablemente te importen, y al entenderlos, puedes encontrar laforma más adecuada deimplementar tu aplicación.

Algunos de los conceptos importantes son:

• Seguridad - HTTPS
• Ejecución al iniciar
• Reinicios
• Replicación (la cantidad de procesos en ejecución)
• Memoria
• Pasos previos antes de iniciar

Veremos cómo afectan estasimplementaciones.

Al final, el objetivo principal es poderservir a tus clientes de API de una manera que seasegura, paraevitar interrupciones, y usar losrecursos de cómputo (por ejemplo, servidores remotos/máquinas virtuales) de la manera más eficiente posible. 🚀

Te contaré un poquito más sobre estosconceptos aquí, y eso, con suerte, te dará laintuición que necesitarías para decidir cómo implementar tu API en diferentes entornos, posiblemente incluso en aquellosfuturos que aún no existen.

Al considerar estos conceptos, podrásevaluar y diseñar la mejor manera de implementartus propias APIs.

En los próximos capítulos, te daré másrecetas concretas para implementar aplicaciones de FastAPI.

Pero por ahora, revisemos estas importantesideas conceptuales. Estos conceptos también se aplican a cualquier otro tipo de API web. 💡

Seguridad - HTTPS¶

En elcapítulo anterior sobre HTTPS aprendimos sobre cómo HTTPS proporciona cifrado para tu API.

También vimos que HTTPS es normalmente proporcionado por un componenteexterno a tu servidor de aplicaciones, unProxy de Terminación TLS.

Y debe haber algo encargado derenovar los certificados HTTPS, podría ser el mismo componente o algo diferente.

Herramientas de Ejemplo para HTTPS¶

Algunas de las herramientas que podrías usar como Proxy de Terminación TLS son:

• Traefik
  • Maneja automáticamente las renovaciones de certificados ✨
• Caddy
  • Maneja automáticamente las renovaciones de certificados ✨
• Nginx
  • Con un componente externo como Certbot para las renovaciones de certificados
• HAProxy
  • Con un componente externo como Certbot para las renovaciones de certificados
• Kubernetes con un Controlador de Ingress como Nginx
  • Con un componente externo como cert-manager para las renovaciones de certificados
• Manejado internamente por un proveedor de nube como parte de sus servicios (lee abajo 👇)

Otra opción es que podrías usar unservicio de nube que haga más del trabajo, incluyendo configurar HTTPS. Podría tener algunas restricciones o cobrarte más, etc. Pero en ese caso, no tendrías que configurar un Proxy de Terminación TLS tú mismo.

Te mostraré algunos ejemplos concretos en los próximos capítulos.

Luego, los siguientes conceptos a considerar son todos acerca del programa que ejecuta tu API real (por ejemplo, Uvicorn).

Programa y Proceso¶

Hablaremos mucho sobre el "proceso" en ejecución, así que es útil tener claridad sobre lo que significa y cuál es la diferencia con la palabra "programa".

Qué es un Programa¶

La palabraprograma se usa comúnmente para describir muchas cosas:

• Elcódigo que escribes, losarchivos Python.
• Elarchivo que puede serejecutado por el sistema operativo, por ejemplo:python,python.exe ouvicorn.
• Un programa específico mientras está siendoejecutado en el sistema operativo, usando la CPU y almacenando cosas en la memoria. Esto también se llamaproceso.

Qué es un Proceso¶

La palabraproceso se usa normalmente de una manera más específica, refiriéndose solo a lo que está ejecutándose en el sistema operativo (como en el último punto anterior):

• Un programa específico mientras está siendoejecutado en el sistema operativo.
  • Esto no se refiere al archivo, ni al código, se refiereespecíficamente a lo que está siendoejecutado y gestionado por el sistema operativo.
• Cualquier programa, cualquier código,solo puede hacer cosas cuando está siendoejecutado. Así que, cuando hay unproceso en ejecución.
• El proceso puede serterminado (o "matado") por ti, o por el sistema operativo. En ese punto, deja de ejecutarse/ser ejecutado, y ya no puedehacer cosas.
• Cada aplicación que tienes en ejecución en tu computadora tiene algún proceso detrás, cada programa en ejecución, cada ventana, etc. Y normalmente hay muchos procesos ejecutándoseal mismo tiempo mientras una computadora está encendida.
• Puede habermúltiples procesos delmismo programa ejecutándose al mismo tiempo.

Si revisas el "administrador de tareas" o "monitor del sistema" (o herramientas similares) en tu sistema operativo, podrás ver muchos de esos procesos en ejecución.

Y, por ejemplo, probablemente verás que hay múltiples procesos ejecutando el mismo programa del navegador (Firefox, Chrome, Edge, etc.). Normalmente ejecutan un proceso por pestaña, además de algunos otros procesos extra.

Ahora que conocemos la diferencia entre los términosproceso yprograma, sigamos hablando sobre implementaciones.

Ejecución al Iniciar¶

En la mayoría de los casos, cuando creas una API web, quieres que estésiempre en ejecución, ininterrumpida, para que tus clientes puedan acceder a ella en cualquier momento. Esto, por supuesto, a menos que tengas una razón específica para que se ejecute solo en ciertas situaciones, pero la mayoría de las veces quieres que esté constantemente en ejecución ydisponible.

En un Servidor Remoto¶

Cuando configuras un servidor remoto (un servidor en la nube, una máquina virtual, etc.) lo más sencillo que puedes hacer es usarfastapi run (que utiliza Uvicorn) o algo similar, manualmente, de la misma manera que lo haces al desarrollar localmente.

Y funcionará y será útildurante el desarrollo.

Pero si pierdes la conexión con el servidor, elproceso en ejecución probablemente morirá.

Y si el servidor se reinicia (por ejemplo, después de actualizaciones o migraciones del proveedor de la nube) probablementeno lo notarás. Y debido a eso, ni siquiera sabrás que tienes que reiniciar el proceso manualmente. Así, tu API simplemente quedará muerta. 😱

Ejecutar Automáticamente al Iniciar¶

En general, probablemente querrás que el programa del servidor (por ejemplo, Uvicorn) se inicie automáticamente al arrancar el servidor, y sin necesidad de ningunaintervención humana, para tener siempre un proceso en ejecución con tu API (por ejemplo, Uvicorn ejecutando tu aplicación FastAPI).

Programa Separado¶

Para lograr esto, normalmente tendrás unprograma separado que se asegurará de que tu aplicación se ejecute al iniciarse. Y en muchos casos, también se asegurará de que otros componentes o aplicaciones se ejecuten, por ejemplo, una base de datos.

Herramientas de Ejemplo para Ejecutar al Iniciar¶

Algunos ejemplos de las herramientas que pueden hacer este trabajo son:

• Docker
• Kubernetes
• Docker Compose
• Docker en Modo Swarm
• Systemd
• Supervisor
• Manejado internamente por un proveedor de nube como parte de sus servicios
• Otros...

Te daré más ejemplos concretos en los próximos capítulos.

Reinicios¶

De manera similar a asegurarte de que tu aplicación se ejecute al iniciar, probablemente también quieras asegurarte de que sereinicie después de fallos.

Cometemos Errores¶

Nosotros, como humanos, cometemoserrores, todo el tiempo. El software casisiempre tienebugs ocultos en diferentes lugares. 🐛

Y nosotros, como desarrolladores, seguimos mejorando el código a medida que encontramos esos bugs y a medida que implementamos nuevas funcionalidades (posiblemente agregando nuevos bugs también 😅).

Errores Pequeños Manejados Automáticamente¶

Al construir APIs web con FastAPI, si hay un error en nuestro código, FastAPI normalmente lo contiene al request único que desencadenó el error. 🛡

El cliente obtendrá un500 Internal Server Error para ese request, pero la aplicación continuará funcionando para los siguientes requests en lugar de simplemente colapsar por completo.

Errores Mayores - Colapsos¶

Sin embargo, puede haber casos en los que escribamos algún código quecolapse toda la aplicación haciendo que Uvicorn y Python colapsen. 💥

Y aún así, probablemente no querrías que la aplicación quede muerta porque hubo un error en un lugar, probablemente querrás quesiga ejecutándose al menos para laspath operations que no estén rotas.

Reiniciar Después del Colapso¶

Pero en esos casos con errores realmente malos que colapsan elproceso en ejecución, querrías un componente externo encargado dereiniciar el proceso, al menos un par de veces...

Probablemente querrías que la cosa encargada de reiniciar tu aplicación sea uncomponente externo, porque para ese punto, la misma aplicación con Uvicorn y Python ya colapsó, así que no hay nada en el mismo código de la misma aplicación que pueda hacer algo al respecto.

Herramientas de Ejemplo para Reiniciar Automáticamente¶

En la mayoría de los casos, la misma herramienta que se utiliza paraejecutar el programa al iniciar también se utiliza para manejar reinicios automáticos.

Por ejemplo, esto podría ser manejado por:

• Docker
• Kubernetes
• Docker Compose
• Docker en Modo Swarm
• Systemd
• Supervisor
• Manejado internamente por un proveedor de nube como parte de sus servicios
• Otros...

Replicación - Procesos y Memoria¶

Con una aplicación FastAPI, usando un programa servidor como el comandofastapi que ejecuta Uvicorn, ejecutarlo una vez enun proceso puede servir a múltiples clientes concurrentemente.

Pero en muchos casos, querrás ejecutar varios worker processes al mismo tiempo.

Múltiples Procesos - Workers¶

Si tienes más clientes de los que un solo proceso puede manejar (por ejemplo, si la máquina virtual no es muy grande) y tienesmúltiples núcleos en la CPU del servidor, entonces podrías tenermúltiples procesos ejecutando la misma aplicación al mismo tiempo, y distribuir todas las requests entre ellos.

Cuando ejecutasmúltiples procesos del mismo programa de API, comúnmente se les llamaworkers.

Worker Processes y Puertos¶

Recuerda de la documentaciónSobre HTTPS que solo un proceso puede estar escuchando en una combinación de puerto y dirección IP en un servidor.

Esto sigue siendo cierto.

Así que, para poder tenermúltiples procesos al mismo tiempo, tiene que haber unsolo proceso escuchando en un puerto que luego transmita la comunicación a cada worker process de alguna forma.

Memoria por Proceso¶

Ahora, cuando el programa carga cosas en memoria, por ejemplo, un modelo de Machine Learning en una variable, o el contenido de un archivo grande en una variable, todo esoconsume un poco de la memoria (RAM) del servidor.

Y múltiples procesos normalmenteno comparten ninguna memoria. Esto significa que cada proceso en ejecución tiene sus propias cosas, variables y memoria. Y si estás consumiendo una gran cantidad de memoria en tu código,cada proceso consumirá una cantidad equivalente de memoria.

Memoria del Servidor¶

Por ejemplo, si tu código carga un modelo de Machine Learning con1 GB de tamaño, cuando ejecutas un proceso con tu API, consumirá al menos 1 GB de RAM. Y si inicias4 procesos (4 workers), cada uno consumirá 1 GB de RAM. Así que, en total, tu API consumirá4 GB de RAM.

Y si tu servidor remoto o máquina virtual solo tiene 3 GB de RAM, intentar cargar más de 4 GB de RAM causará problemas. 🚨

Múltiples Procesos - Un Ejemplo¶

En este ejemplo, hay unProceso Administrador que inicia y controla dosWorker Processes.

Este Proceso Administrador probablemente sería el que escuche en elpuerto en la IP. Y transmitirá toda la comunicación a los worker processes.

Esos worker processes serían los que ejecutan tu aplicación, realizarían los cálculos principales para recibir unrequest y devolver unresponse, y cargarían cualquier cosa que pongas en variables en RAM.

Y por supuesto, la misma máquina probablemente tendríaotros procesos ejecutándose también, aparte de tu aplicación.

Un detalle interesante es que el porcentaje deCPU utilizado por cada proceso puedevariar mucho con el tiempo, pero lamemoria (RAM) normalmente permanece más o menosestable.

Si tienes una API que hace una cantidad comparable de cálculos cada vez y tienes muchos clientes, entonces lautilización de CPU probablementetambién sea estable (en lugar de constantemente subir y bajar rápidamente).

Ejemplos de Herramientas y Estrategias de Replicación¶

Puede haber varios enfoques para lograr esto, y te contaré más sobre estrategias específicas en los próximos capítulos, por ejemplo, al hablar sobre Docker y contenedores.

La principal restricción a considerar es que tiene que haber uncomponente único manejando elpuerto en laIP pública. Y luego debe tener una forma detransmitir la comunicación a losprocesos/workers replicados.

Aquí hay algunas combinaciones y estrategias posibles:

• Uvicorn con--workers
  • Un administrador de procesos de Uvicornescucharía en laIP ypuerto, y iniciaríamúltiples worker processes de Uvicorn.
• Kubernetes y otros sistemas decontenedor distribuidos
  • Algo en la capa deKubernetes escucharía en laIP ypuerto. La replicación sería al tenermúltiples contenedores, cada uno conun proceso de Uvicorn ejecutándose.
• Servicios en la Nube que manejan esto por ti
  • El servicio en la nube probablementemanejará la replicación por ti. Posiblemente te permitiría definirun proceso para ejecutar, o unaimagen de contenedor para usar, en cualquier caso, lo más probable es que seríaun solo proceso de Uvicorn, y el servicio en la nube se encargaría de replicarlo.

Pasos Previos Antes de Iniciar¶

Hay muchos casos en los que quieres realizar algunos pasosantes de iniciar tu aplicación.

Por ejemplo, podrías querer ejecutarmigraciones de base de datos.

Pero en la mayoría de los casos, querrás realizar estos pasos solouna vez.

Así que, querrás tener unúnico proceso para realizar esospasos previos, antes de iniciar la aplicación.

Y tendrás que asegurarte de que sea un único proceso ejecutando esos pasos previos incluso si después, iniciasmúltiples procesos (múltiples workers) para la propia aplicación. Si esos pasos fueran ejecutados pormúltiples procesos,duplicarían el trabajo al ejecutarlo enparalelo, y si los pasos fueran algo delicado como una migración de base de datos, podrían causar conflictos entre sí.

Por supuesto, hay algunos casos en los que no hay problema en ejecutar los pasos previos múltiples veces, en ese caso, es mucho más fácil de manejar.

Ejemplos de Estrategias para Pasos Previos¶

Estodependerá mucho de la forma en queimplementarás tu sistema, y probablemente estará conectado con la forma en que inicias programas, manejas reinicios, etc.

Aquí hay algunas ideas posibles:

• Un "Contenedor de Inicio" en Kubernetes que se ejecuta antes de tu contenedor de aplicación
• Un script de bash que ejecuta los pasos previos y luego inicia tu aplicación
  • Aún necesitarías una forma de iniciar/reiniciarese script de bash, detectar errores, etc.

Utilización de Recursos¶

Tu(s) servidor(es) es(son) unrecurso que puedes consumir outilizar, con tus programas, el tiempo de cómputo en las CPUs y la memoria RAM disponible.

¿Cuánto de los recursos del sistema quieres consumir/utilizar? Podría ser fácil pensar "no mucho", pero en realidad, probablemente querrás consumirlo más posible sin colapsar.

Si estás pagando por 3 servidores pero solo estás usando un poquito de su RAM y CPU, probablemente estésdesperdiciando dinero 💸, y probablementedesperdiciando la energía eléctrica del servidor 🌎, etc.

En ese caso, podría ser mejor tener solo 2 servidores y usar un mayor porcentaje de sus recursos (CPU, memoria, disco, ancho de banda de red, etc.).

Por otro lado, si tienes 2 servidores y estás usando100% de su CPU y RAM, en algún momento un proceso pedirá más memoria y el servidor tendrá que usar el disco como "memoria" (lo cual puede ser miles de veces más lento), o inclusocolapsar. O un proceso podría necesitar hacer algún cálculo y tendría que esperar hasta que la CPU esté libre de nuevo.

En este caso, sería mejor obtenerun servidor extra y ejecutar algunos procesos en él para que todos tengansuficiente RAM y tiempo de CPU.

También existe la posibilidad de que, por alguna razón, tengas unpico de uso de tu API. Tal vez se volvió viral, o tal vez otros servicios o bots comienzan a usarla. Y podrías querer tener recursos extra para estar a salvo en esos casos.

Podrías establecer unnúmero arbitrario para alcanzar, por ejemplo, algoentre 50% a 90% de utilización de recursos. El punto es que esas son probablemente las principales cosas que querrás medir y usar para ajustar tus implementaciones.

Puedes usar herramientas simples comohtop para ver la CPU y RAM utilizadas en tu servidor o la cantidad utilizada por cada proceso. O puedes usar herramientas de monitoreo más complejas, que pueden estar distribuidas a través de servidores, etc.

Resumen¶

Has estado leyendo aquí algunos de los conceptos principales que probablemente necesitarás tener en mente al decidir cómo implementar tu aplicación:

• Seguridad - HTTPS
• Ejecución al iniciar
• Reinicios
• Replicación (la cantidad de procesos en ejecución)
• Memoria
• Pasos previos antes de iniciar

Comprender estas ideas y cómo aplicarlas debería darte la intuición necesaria para tomar decisiones al configurar y ajustar tus implementaciones. 🤓

En las próximas secciones, te daré más ejemplos concretos de posibles estrategias que puedes seguir. 🚀