Pokémon GO

Pokémon GO: Un vistazo a las dificultades técnicas de su lanzamiento. ¿Contenedores?

Con la llegada a las tiendas virtuales de Android e iOs del fenómeno Pokémon GO, todo aquel pokemaníaco (o curioso) ha visto cómo los servidores se han mantenido cerrados a ratos, y han ido experimentando numerosas irregularidades los primeros días de servicio como el cierre de los servidores a todo aquel que no estuviera en las primeras regiones de lanzamiento, como Australia y Nueva Zelanda.

Esta vez no se trata de Niantic, sino que nos informa uno de los pobres ingenieros a cargo de los servicios en la nube de Google (Google Cloud Services) que se encargaban de proveer varios de los servicios (¡más de 12!) de los que hace uso la compañía de John Hanke. Toda esta información se ofrece para promocionar la presentación de un nuevo servicio por parte del gigante norteamericano, del cual se ha beneficiado su propia spin-off de forma temprana. Se trata del Google Customer Reliability Engineering (que podría traducirse como la ingeniería confiable de Google para el cliente), en que un grupo de técnicos de Google se integra en el equipo de desarrollo del cliente para responsabilizarse de la confiabilidad de ciertas aplicaciones especiales en la nube.

Como explicación sencilla, el principal problema de Pokémon GO en su lanzamiento fue la enorme demanda de tráfico de datos que tuvo. Tanto fue así que superó en 50 veces la estimación de uso normal que dieron; y en 10 veces la estima pesimista de uso de datos. Google ofrece este gráfico para visualizar el horror que supuso el lanzamiento del título:

Uso de datos de Pokémon GO
En palabras de cierto presentador de noticias: «Terrible, apocalíptico»

No hizo falta más que un cuarto de hora para que la avalancha de usuarios en los primeros minutos de la existencia de Pokémon GO superara con creces las previsiones de tráfico de Niantic y Google. Y eso no era lo peor: el lanzamiento de la aplicación en EEUU estaba al caer, por lo que la compañía de Alphabet tuvo que asignar muchos más recursos a fin de que el lanzamiento no tuviera complicaciones.

Las vicisitudes en el lanzamiento de la aplicación no terminaban ahí. Por motivos de flexibilidad en el consumo de recursos (que ya hemos visto era necesario), Pokémon GO utilizaba un motor específico proporcionado por Google que permite que la aplicación del servidor se ejecute en un «contenedor», llevado por una serie de servidores físicos en la nube (llamados nodos). De cara al lanzamiento nipón tuvieron que mejorar el sistema que tenían para equilibrar la carga en los nodos, de forma que admitiera varios miles de nodos adicionales, conexiones más rápidas, mejor control y una mayor eficiencia en general, cosa que impactó positivamente en el rendimiento de la aplicación para el usuario. El ingeniero de Google que redactó la entrada compara esta hazaña con cambiar los motores de un avión en pleno vuelo. El gigante de Silicon Valley ha sido también responsable en gran parte de que el servicio no sufriera grandes complicaciones, aportando varias decenas de miles de procesadores y su red privada para asegurar la estabilidad del servicio.

Todo eso ha permitido, junto a la eliminación de uso de herramientas de terceros, que el uso de los recursos disminuyera drásticamente, como puede observarse en el gráfico que Niantic ya aportó hace tiempo:

1608-06 Pokémon GO Niantic recursos servidores
El uso de recursos de geolocalización disminuyó drásticamente al revocar el acceso a apps no oficiales

El resto ya es historia: lograron lanzar en Japón sin problemas y están terminando de desplegar sus servicios en el resto del mundo. Pokémon GO ya se encuentra recientemente disponible en 11 nuevos países (5 y 6 más);  y además han recuperado el trono en cuanto a dinero recaudado en la App Store de EEUU.

 

Pokémon GO, ¿en un contenedor? ¿Como los de los barcos?

Más o menos. Este es el único término difícil de explicar por lo técnico que es, por lo que conviene sacarlo del texto principal y tratar de desarrollarlo aparte: Pokémon GO, además de los servicios en la nube de Google, desarrolla su aplicación servidor en un contenedor provisto por una tercera empresa: Kubernetes (también inicialmente creada por la compañía del famoso buscador).

Las aplicaciones en la nube normalmente se hacen virtualizando un sistema operativo, haciendo que se tenga como un ordenador virtual dentro de un ordenador físico anfitrión; y el ordenador virtual puede no tener el mismo sistema operativo que el anfitrión. Lo que ocurre es que en este caso el anfitrión no es un único computador físico sino una nube de servidores. Un contenedor se beneficia también del concepto de la nube, pero de una forma distinta: el sistema operativo ya se proporciona en la propia infraestructura y el desarrollador solo tiene que encargarse de incluir en ese contenedor las librerías (u otras aplicaciones previas) que necesita, así como su propia aplicación. Así, el contenedor lo puede ejecutar un único nodo si es pequeño (o un nodo puede ejecutar varios contenedores pequeños), o serán varios nodos los que ejecuten una aplicación, como es el hecho de Pokémon GO. La imagen a continuación lo ilustra (es de Docker, otra compañía que se dedica a lo mismo, pero consideramos que es más didáctica que la que ofrece Kubernetes):

Comparación entre virtualizar y usar contenedores
Un contenedor reduce ampliamente el uso de recursos y mejora la eficiencia

Y no solo eso: gracias a que el software en que se ejecutan los servidores de Kubernetes es software libre (de libre acceso, revisión y uso) y a que Pokémon GO ha sido de largo el proyecto más ambicioso que se ha alojado en sus servidores, el equipo de desarrollo de la aplicación móvil ha sido capaz de detectar y solucionar numerosos bugs en la plataforma.

Podríamos concluir de esto que el sucesor espiritual de Ingress ha sido beneficioso para todos: Google, Niantic, Kubernetes, Nintendo (a través de The Pokémon Company), y otros que hayan metido mano. Y por supuesto, los usuarios de la fiebre que ha desatado.

Mostrar Comentarios (0)