{"id":39304,"date":"2019-10-31T22:29:40","date_gmt":"2019-10-31T19:29:40","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-seti\/"},"modified":"2019-10-31T22:29:40","modified_gmt":"2019-10-31T19:29:40","slug":"kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-seti","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-seti","title":{"rendered":"C\u00f3mo AWS \"cocina\" sus servicios el\u00e1sticos. Escalado de la red","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>La escala de la red de Amazon Web Services consiste en 69 zonas en todo el mundo, distribuidas en 22 regiones: EE. UU., Europa, Asia, \u00c1frica y Australia. En cada zona hay hasta 8 centros de datos (CD). En cada CD hay miles o cientos de miles de servidores. La red est\u00e1 dise\u00f1ada para considerar todos los escenarios poco probables de interrupci\u00f3n. Por ejemplo, todas las regiones est\u00e1n aisladas entre s\u00ed, y las zonas de disponibilidad est\u00e1n separadas por distancias de varios kil\u00f3metros. Incluso si se cortara un cable, el sistema cambiar\u00eda a canales de respaldo, y la p\u00e9rdida de informaci\u00f3n ser\u00eda de solo unos pocos paquetes de datos. Sobre otros principios en los que se basa la red y su funcionamiento, hablar\u00e1 Vasili Pantyukhin.<\/p>\n<p><img decoding=\"async\" alt=\"C\u00f3mo AWS &quot;cocina&quot; sus servicios el\u00e1sticos. Escalado de la red\" src=\"\/wp-content\/uploads\/2019\/10\/4cc9672442cd7bf744ffced6471be040.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Vasili Pantiukhyn<\/b> empec\u00e9 como administrador de Unix en empresas .ru, estuve 6 a\u00f1os trabajando con grandes equipos de Sun Microsystems, y durante 11 a\u00f1os promov\u00ed la centralidad de los datos en EMC. Evolucion\u00e9 naturalmente hacia las nubes privadas y luego hice la transici\u00f3n a las p\u00fablicas. Actualmente, como arquitecto de Amazon Web Services, ofrezco consejos t\u00e9cnicos para ayudar a vivir y desarrollarse en la nube de AWS.<\/p>\n<p>En la parte anterior de la trilog\u00eda sobre la arquitectura de AWS, Vasili profundiz\u00f3 en la estructura de los servidores f\u00edsicos y la escalabilidad de la base de datos. Las tarjetas Nitro, el hipervisor personalizado basado en KVM, la base de datos Amazon Aurora: sobre todo esto se habla en el material \"<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/oleg-bunin\/blog\/471686\/\">C\u00f3mo AWS \"cocina\" sus servicios el\u00e1sticos. Escalado de servidores y bases de datos<\/a><\/noindex>\". L\u00e9elo para sumergirte en el contexto, o mira la <noindex><a rel=\"nofollow\" href=\"https:\/\/youtu.be\/S3f6nWJxBvk\">grabaci\u00f3n en video<\/a><\/noindex> de la presentaci\u00f3n.<\/p>\n<p>En esta parte se hablar\u00e1 de la escalabilidad de la red, uno de los sistemas m\u00e1s complejos en AWS. La evoluci\u00f3n de una red plana a la Virtual Private Cloud y su estructura, los servicios internos Blackfoot y HyperPlane, el problema del vecino ruidoso, y al final, la escala de la red, el backbone y los cables f\u00edsicos. Todo esto est\u00e1 bajo el siguiente enlace.<\/p>\n<p><i>Descargo de responsabilidad: todo lo que sigue es la opini\u00f3n personal de Vasili y puede no coincidir con la postura de Amazon Web Services.<\/i><br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Escalabilidad de red<\/h2>\n<p>\nAWS se lanz\u00f3 en 2006. Su red era bastante primitiva, con una estructura plana. El rango de direcciones privadas era compartido por todos los inquilinos de la nube. Al iniciar una nueva m\u00e1quina virtual, accidentalmente obten\u00edas una direcci\u00f3n IP disponible de este rango.<\/p>\n<p><img decoding=\"async\" alt=\"C\u00f3mo AWS &quot;cocina&quot; sus servicios el\u00e1sticos. Escalado de la red\" src=\"\/wp-content\/uploads\/2019\/10\/dde10b64891861582bc56510adb0fb56.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEste enfoque era f\u00e1cil de implementar, pero limitaba fundamentalmente el uso de la nube. En particular, era bastante dif\u00edcil desarrollar soluciones h\u00edbridas que combinaran redes privadas en tierra y en AWS. El problema m\u00e1s com\u00fan era la intersecci\u00f3n de los rangos de direcciones IP.<\/p>\n<p><img decoding=\"async\" alt=\"C\u00f3mo AWS &quot;cocina&quot; sus servicios el\u00e1sticos. Escalado de la red\" src=\"\/wp-content\/uploads\/2019\/10\/8e95325862ae0438d3b1edef45c692b0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Virtual Private Cloud<\/h3>\n<p>\nLa nube se ha vuelto popular. Ha llegado el momento de considerar la escalabilidad y la posibilidad de su uso por decenas de millones de inquilinos. La red plana se ha convertido en el principal obst\u00e1culo. Por eso, hemos pensado en c\u00f3mo aislar a los usuarios unos de otros a nivel de red, para que puedan elegir rangos de IP por s\u00ed mismos.<\/p>\n<p><img decoding=\"async\" alt=\"C\u00f3mo AWS &quot;cocina&quot; sus servicios el\u00e1sticos. Escalado de la red\" src=\"\/wp-content\/uploads\/2019\/10\/e082da6a68a889e3091c75dd3aa912ec.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u00bfQu\u00e9 es lo primero que se te viene a la mente cuando piensas en aislamiento de red? Por supuesto, <b>VLAN<\/b> y <b>VRF \u2014 Enrutamiento y Conmutaci\u00f3n Virtual<\/b>.<\/p>\n<p>Desafortunadamente, esto no funcion\u00f3. El ID de VLAN son solo 12 bits, lo que nos da solo 4096 segmentos aislados. Incluso en los conmutadores m\u00e1s grandes, se pueden utilizar un m\u00e1ximo de 1-2 mil VRF. La combinaci\u00f3n de VRF y VLAN nos da solo unos pocos millones de subredes. Esto definitivamente no es suficiente para decenas de millones de inquilinos, cada uno de los cuales debe tener la posibilidad de utilizar varias subredes.<\/p>\n<p>Adem\u00e1s, simplemente no podemos permitirnos comprar la cantidad requerida de grandes equipos, por ejemplo, de Cisco o Juniper. Hay dos razones: es extremadamente caro y no queremos depender de su pol\u00edtica de desarrollo y parches.<\/p>\n<blockquote><p>La conclusi\u00f3n es clara: hay que elaborar nuestra propia soluci\u00f3n.<\/p><\/blockquote>\n<p>\nEn 2009, anunciamos <b>VPC<\/b> \u2014 <b>Virtual Private Cloud<\/b>. El nombre se ha arraigado y ahora muchos proveedores de nube tambi\u00e9n lo utilizan.<\/p>\n<p>VPC es una red virtual <b>SDN<\/b> (Red Definida por Software). Decidimos no inventar protocolos espec\u00edficos en los niveles L2 y L3. La red funciona con Ethernet e IP est\u00e1ndar. Para la transmisi\u00f3n por la red, el tr\u00e1fico de las m\u00e1quinas virtuales se encapsula en una envoltura de nuestro propio protocolo. En \u00e9l se especifica el ID que pertenece al inquilino de la VPC.<\/p>\n<p><img decoding=\"async\" alt=\"C\u00f3mo AWS &quot;cocina&quot; sus servicios el\u00e1sticos. Escalado de la red\" src=\"\/wp-content\/uploads\/2019\/10\/63c6226b5dcecbf4376547c3c1605fef.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSuena simple. Sin embargo, es necesario resolver varias tareas t\u00e9cnicas serias. Por ejemplo, d\u00f3nde y c\u00f3mo almacenar los datos sobre la mapeo de direcciones MAC\/IP virtuales, ID de VPC y las correspondientes MAC\/IP f\u00edsicas. A escala de AWS, se trata de una enorme tabla que debe funcionar con m\u00ednimos retrasos al acceder. Esto est\u00e1 a cargo de <b>el servicio de mapeo<\/b>, que se distribuye en toda la red en una capa delgada.<\/p>\n<p>En las m\u00e1quinas de nueva generaci\u00f3n, la encapsulaci\u00f3n se realiza mediante tarjetas Nitro a nivel de hardware. En las instancias m\u00e1s antiguas, la encapsulaci\u00f3n y la desencapsulaci\u00f3n son procesos software.\u00a0<\/p>\n<p><img decoding=\"async\" alt=\"C\u00f3mo AWS &quot;cocina&quot; sus servicios el\u00e1sticos. Escalado de la red\" src=\"\/wp-content\/uploads\/2019\/10\/d17738749f273d94e943723f7b2a6b5a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVeamos c\u00f3mo funciona esto en t\u00e9rminos generales. Comencemos con el nivel L2. Supongamos que tenemos una m\u00e1quina virtual con IP 10.0.0.2 en un servidor f\u00edsico 192.168.0.3. Esta env\u00eda datos a la m\u00e1quina virtual 10.0.0.3, que reside en 192.168.1.4. Se genera una solicitud ARP que llega a la tarjeta Nitro de red. Para simplificar, asumimos que ambas m\u00e1quinas virtuales est\u00e1n en el mismo VPC \"azul\".<\/p>\n<p><img decoding=\"async\" alt=\"C\u00f3mo AWS &quot;cocina&quot; sus servicios el\u00e1sticos. Escalado de la red\" src=\"\/wp-content\/uploads\/2019\/10\/d260113b0502cecc328919dd5c3b69ac.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa tarjeta reemplaza la direcci\u00f3n de origen por la suya y reenv\u00eda el marco ARP al servicio de mapeo.<\/p>\n<p><img decoding=\"async\" alt=\"C\u00f3mo AWS &quot;cocina&quot; sus servicios el\u00e1sticos. Escalado de la red\" src=\"\/wp-content\/uploads\/2019\/10\/812d7693bc54afc24f6e763fdb91180e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEl servicio de mapeo devuelve la informaci\u00f3n necesaria para la transmisi\u00f3n a trav\u00e9s de la red f\u00edsica L2.<\/p>\n<p><img decoding=\"async\" alt=\"C\u00f3mo AWS &quot;cocina&quot; sus servicios el\u00e1sticos. Escalado de la red\" src=\"\/wp-content\/uploads\/2019\/10\/b21fd6edb95ef2e990db813074c7907c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa tarjeta Nitro, en la respuesta ARP, reemplaza la MAC en la red f\u00edsica por la direcci\u00f3n en el VPC.<\/p>\n<p><img decoding=\"async\" alt=\"C\u00f3mo AWS &quot;cocina&quot; sus servicios el\u00e1sticos. Escalado de la red\" src=\"\/wp-content\/uploads\/2019\/10\/6e6931c7fe92d5cf2584c5bf9b2b3fdb.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAl transmitir datos, encapsulamos las MAC y IP l\u00f3gicas en un envoltorio VPC. Todo esto se env\u00eda por la red f\u00edsica utilizando las IP correspondientes de las tarjetas Nitro de origen y destino.<\/p>\n<p><img decoding=\"async\" alt=\"C\u00f3mo AWS &quot;cocina&quot; sus servicios el\u00e1sticos. Escalado de la red\" src=\"\/wp-content\/uploads\/2019\/10\/e786d7f88e1fea1557590f2b2bd6e88f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa m\u00e1quina f\u00edsica, a la que se destina el paquete, realiza una verificaci\u00f3n. Esto es necesario para evitar la suplantaci\u00f3n de direcciones. La m\u00e1quina env\u00eda una solicitud especial al servicio de mapeo y pregunta: \"Desde la m\u00e1quina f\u00edsica 192.168.0.3 he recibido un paquete que est\u00e1 destinado a 10.0.0.3 en el VPC 'azul'. \u00bfEs leg\u00edtimo?\"\u00a0<\/p>\n<p><img decoding=\"async\" alt=\"C\u00f3mo AWS &quot;cocina&quot; sus servicios el\u00e1sticos. Escalado de la red\" src=\"\/wp-content\/uploads\/2019\/10\/cedf4d7e77936e4cc8f873defefbe37f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEl servicio de mapeo verifica su tabla de ubicaci\u00f3n de recursos y permite o deniega el paso del paquete. En todas las nuevas instancias, se ha implementado una validaci\u00f3n adicional en las tarjetas Nitro. No se puede eludir, ni siquiera te\u00f3ricamente. Por lo tanto, el spoofing de recursos en otro VPC no funcionar\u00e1.<\/p>\n<p><img decoding=\"async\" alt=\"C\u00f3mo AWS &quot;cocina&quot; sus servicios el\u00e1sticos. Escalado de la red\" src=\"\/wp-content\/uploads\/2019\/10\/3e6bc5a80a7d36785299f6a3fbb19d92.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLuego, los datos se env\u00edan a la m\u00e1quina virtual para la que est\u00e1n destinados.\u00a0<\/p>\n<p><img decoding=\"async\" alt=\"C\u00f3mo AWS &quot;cocina&quot; sus servicios el\u00e1sticos. Escalado de la red\" src=\"\/wp-content\/uploads\/2019\/10\/19884070ad3b2b7b2835e2c3c182949a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEl servicio de mapeo tambi\u00e9n funciona como un enrutador l\u00f3gico para la transmisi\u00f3n de datos entre m\u00e1quinas virtuales en diferentes subredes. Conceptualmente, es todo bastante simple; no entrar\u00e9 en detalles.<\/p>\n<p><img decoding=\"async\" alt=\"C\u00f3mo AWS &quot;cocina&quot; sus servicios el\u00e1sticos. Escalado de la red\" src=\"\/wp-content\/uploads\/2019\/10\/9d592d738d02bbcf6bfcbda2812f8f0c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAs\u00ed que, al enviar cada paquete, los servidores consultan al servicio de mapeo. \u00bfC\u00f3mo lidiar con las inevitables latencias? <b>Mediante el almacenamiento en cach\u00e9.<\/b>, por supuesto.<\/p>\n<p>Lo maravilloso es que no es necesario almacenar en cach\u00e9 toda la enorme tabla. En el servidor f\u00edsico residen m\u00e1quinas virtuales de una cantidad relativamente peque\u00f1a de VPC. Solo es necesario almacenar en cach\u00e9 la informaci\u00f3n sobre esos VPC. La transmisi\u00f3n de datos a otros VPC en la configuraci\u00f3n \"predeterminada\" sigue sin ser leg\u00edtima. Si se utiliza una funcionalidad como VPC-peering, la informaci\u00f3n sobre los VPC correspondientes se carga adicionalmente en la cach\u00e9.\u00a0<\/p>\n<p><img decoding=\"async\" alt=\"C\u00f3mo AWS &quot;cocina&quot; sus servicios el\u00e1sticos. Escalado de la red\" src=\"\/wp-content\/uploads\/2019\/10\/5ac44d8854bff3c7738724ee9dda0c57.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHemos comprendido la transmisi\u00f3n de datos en el VPC.<\/p>\n<h3>Blackfoot<\/h3>\n<p>\n\u00bfC\u00f3mo manejar situaciones en las que el tr\u00e1fico necesita ser transmitido externamente, como a Internet o a trav\u00e9s de una VPN hacia la tierra? Aqu\u00ed es donde nos ayuda <b>Blackfoot<\/b> un servicio interno de AWS. Ha sido desarrollado por nuestro equipo de Sud\u00e1frica. Por eso, el servicio lleva el nombre de un ping\u00fcino que vive en Sud\u00e1frica.<\/p>\n<p><img decoding=\"async\" alt=\"C\u00f3mo AWS &quot;cocina&quot; sus servicios el\u00e1sticos. Escalado de la red\" src=\"\/wp-content\/uploads\/2019\/10\/dc6f233224d130df42adf522602167c6.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nBlackfoot desacapsula el tr\u00e1fico y hace lo que es necesario. Los datos se env\u00edan a Internet tal como est\u00e1n.<\/p>\n<p><img decoding=\"async\" alt=\"C\u00f3mo AWS &quot;cocina&quot; sus servicios el\u00e1sticos. Escalado de la red\" src=\"\/wp-content\/uploads\/2019\/10\/b6a51230202355b27de9730fbc18bd7f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLos datos se desacapsulan y se vuelven a encapsular en una envoltura IPsec al usar la VPN.<\/p>\n<p><img decoding=\"async\" alt=\"C\u00f3mo AWS &quot;cocina&quot; sus servicios el\u00e1sticos. Escalado de la red\" src=\"\/wp-content\/uploads\/2019\/10\/ef76780a9be99d72c5763a41274f4224.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAl utilizar Direct Connect, el tr\u00e1fico se etiqueta y se transmite en el VLAN correspondiente.<\/p>\n<p><img decoding=\"async\" alt=\"C\u00f3mo AWS &quot;cocina&quot; sus servicios el\u00e1sticos. Escalado de la red\" src=\"\/wp-content\/uploads\/2019\/10\/89adc2616e0bf97355a2c638720fd791.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>HyperPlane<\/h3>\n<p>\nEs un servicio interno de control de flujo. Muchos servicios de red requieren controlar <b>el estado del flujo de datos<\/b>. Por ejemplo, al usar NAT, el control de flujo debe garantizar que cada par \u00abIP: puerto de destino\u00bb tenga un puerto de salida \u00fanico. En el caso del balanceador de carga <b>NLB<\/b> \u2014 <b>Balanceador de Carga de Red<\/b>, el flujo de datos siempre debe dirigirse a la misma m\u00e1quina virtual objetivo. Los Grupos de Seguridad son un firewall con estado. Supervisan el tr\u00e1fico entrante y abren puertos impl\u00edcitamente para el flujo de paquetes salientes.<\/p>\n<p><img decoding=\"async\" alt=\"C\u00f3mo AWS &quot;cocina&quot; sus servicios el\u00e1sticos. Escalado de la red\" src=\"\/wp-content\/uploads\/2019\/10\/da1ad8e7179ebffbe786348db25f0a95.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEn la nube de AWS, los requisitos de latencia de transmisi\u00f3n son extremadamente altos. Por lo tanto, <b>HyperPlane<\/b> es cr\u00edtico para el funcionamiento de toda la red.<\/p>\n<p><img decoding=\"async\" alt=\"C\u00f3mo AWS &quot;cocina&quot; sus servicios el\u00e1sticos. Escalado de la red\" src=\"\/wp-content\/uploads\/2019\/10\/eb73570e579c6e0b05727029345e559a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHyperplane se basa en m\u00e1quinas virtuales EC2. Aqu\u00ed no hay magia, solo astucia. La astucia radica en que estas son m\u00e1quinas virtuales con mucha RAM. Las operaciones son transaccionales y se realizan exclusivamente en memoria. Esto permite lograr latencias de solo decenas de microsegundos. Trabajar con disco arruinar\u00eda todo el rendimiento.\u00a0<\/p>\n<p>Hyperplane es un sistema distribuido compuesto por una gran cantidad de estas m\u00e1quinas EC2. Cada m\u00e1quina virtual tiene un ancho de banda de 5 GB\/s. A nivel de toda la red regional, esto da incre\u00edbles terabits de capacidad y permite procesar <b>millones de conexiones por segundo<\/b>.<\/p>\n<p>HyperPlane solo trabaja con flujos. La encapsulaci\u00f3n de paquetes en VPC es completamente transparente para \u00e9l. Una posible vulnerabilidad en este servicio interno a\u00fan no permitir\u00e1 romper la aislamiento del VPC. La seguridad es responsabilidad de los niveles inferiores.<\/p>\n<h3>Vecino ruidoso<\/h3>\n<p>\nTambi\u00e9n hay otro problema <b>del vecino ruidoso<\/b> \u2014 <b>vecino ruidoso<\/b>. Supongamos que tenemos 8 nodos. Estos nodos manejan el tr\u00e1fico de todos los usuarios de la nube. Parece que todo est\u00e1 bien y la carga deber\u00eda distribuirse uniformemente entre todos los nodos. Los nodos son muy potentes y es dif\u00edcil sobrecargarlos.<\/p>\n<p>Pero estamos construyendo nuestra arquitectura teniendo incluso en cuenta escenarios poco probables.\u00a0<\/p>\n<blockquote><p>Una baja probabilidad no significa imposibilidad.<\/p><\/blockquote>\n<p>\nPodemos imaginar una situaci\u00f3n en la que uno o varios usuarios generen una carga excesiva. Todos los nodos de HyperPlane est\u00e1n involucrados en manejar esta carga y otros usuarios podr\u00edan sentir una disminuci\u00f3n en el rendimiento. Esto socava el concepto de la nube, donde los inquilinos no deber\u00edan influir entre s\u00ed.<\/p>\n<p><img decoding=\"async\" alt=\"C\u00f3mo AWS &quot;cocina&quot; sus servicios el\u00e1sticos. Escalado de la red\" src=\"\/wp-content\/uploads\/2019\/10\/8508878637dc3d4c0b0b565e08d73e52.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u00bfC\u00f3mo resolver el problema del vecino ruidoso? Lo primero que se me ocurre es el sharding. Nuestros 8 nodos se dividen l\u00f3gicamente en 4 shards de 2 nodos cada uno. Ahora, el vecino ruidoso solo afectar\u00e1 a una cuarta parte de todos los usuarios, pero de manera significativa.<\/p>\n<p><img decoding=\"async\" alt=\"C\u00f3mo AWS &quot;cocina&quot; sus servicios el\u00e1sticos. Escalado de la red\" src=\"\/wp-content\/uploads\/2019\/10\/33e10c10b246ee8ddeb171ac44372c56.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHag\u00e1moslo de otra manera. Asignaremos solo 3 nodos a cada usuario.\u00a0<\/p>\n<p><img decoding=\"async\" alt=\"C\u00f3mo AWS &quot;cocina&quot; sus servicios el\u00e1sticos. Escalado de la red\" src=\"\/wp-content\/uploads\/2019\/10\/1afa7337b8418740b9ef5860be9d3a82.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa clave est\u00e1 en asignar nodos a diferentes usuarios aleatoriamente. En la imagen de abajo, el usuario azul se superpone en nodos con uno de los otros dos usuarios: el verde y el naranja.<\/p>\n<p><img decoding=\"async\" alt=\"C\u00f3mo AWS &quot;cocina&quot; sus servicios el\u00e1sticos. Escalado de la red\" src=\"\/wp-content\/uploads\/2019\/10\/e0fd896db825b390bd66d2055707464d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCon 8 nodos y 3 usuarios, la probabilidad de que el vecino ruidoso se superponga con uno de los usuarios es del 54%. Es con esta probabilidad que el usuario azul influir\u00e1 en otros inquilinos. Adem\u00e1s, ser\u00e1 solo con una parte de su carga. En nuestro ejemplo, esta influencia ser\u00e1 perceptible solo para un tercio de todos los usuarios. Ya es un buen resultado.<\/p>\n<p>N\u00famero de usuarios que se superpondr\u00e1n<\/p>\n<p>Probabilidad en porcentaje<\/p>\n<p>0<\/p>\n<p>18%<\/p>\n<p>1<\/p>\n<p>54%<\/p>\n<p>2<\/p>\n<p>26%<\/p>\n<p>3<\/p>\n<p>2%<\/p>\n<p>Acercando la situaci\u00f3n a la realidad: tomemos 100 nodos y 5 usuarios en 5 nodos. En este caso, la probabilidad de que ninguno de los nodos se superponga es del 77%.\u00a0<\/p>\n<p>N\u00famero de usuarios que se superpondr\u00e1n<\/p>\n<p>Probabilidad en porcentaje<\/p>\n<p>0<\/p>\n<p>77%<\/p>\n<p>1<\/p>\n<p>21%<\/p>\n<p>2<\/p>\n<p>1,8%<\/p>\n<p>3<\/p>\n<p>0,06%<\/p>\n<p>4<\/p>\n<p>0,0006%<\/p>\n<p>5<\/p>\n<p>0,00000013%<\/p>\n<p>En la situaci\u00f3n real, con una gran cantidad de nodos de HyperPlane y usuarios, la influencia potencial del vecino ruidoso sobre otros usuarios es m\u00ednima. Este m\u00e9todo se llama <b>shuffle sharding<\/b> \u2014 <b>. Minimiza el efecto negativo de la falla de nodos.<\/b>Sobre HyperPlane se han construido muchos servicios: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.<\/p>\n<p>Escalas de la red<\/p>\n<h3>Escalabilidad de la red<\/h3>\n<p>\nAhora hablemos de la magnitud de la red misma. A octubre de 2019, AWS ofrece sus servicios en <b>22 regiones<\/b>, y se han planeado otras 9.<\/p>\n<ul>\n<li>Cada regi\u00f3n contiene varias zonas de disponibilidad \u2014 Availability Zone. En total, hay 69 en el mundo.\n<\/li>\n<li>Cada AZ consiste en Centros de Datos. En total, no hay m\u00e1s de 8.\n<\/li>\n<li>En los CED se ubica una gran cantidad de servidores; en algunos, hasta 300,000.\n<\/li>\n<\/ul>\n<p>\nAhora promediemos todo esto, multipliquemos y obtendremos una cifra impresionante que refleja <b>la magnitud de la nube de Amazon<\/b>.<\/p>\n<p>Entre las zonas de disponibilidad y los CED hay numerosos canales \u00f3pticos. En nuestra mayor regi\u00f3n, solo para la conexi\u00f3n entre AZ y los centros de conexi\u00f3n con otras regiones (Transit Centers) hay 388 canales. En total, esto da un impresionante <b>5000 Tbps<\/b>.<\/p>\n<p><img decoding=\"async\" alt=\"C\u00f3mo AWS &quot;cocina&quot; sus servicios el\u00e1sticos. Escalado de la red\" src=\"\/wp-content\/uploads\/2019\/10\/2d9faa9275665bc1d3c6fbb49235fac4.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa red Backbone de AWS est\u00e1 construida espec\u00edficamente para la nube y optimizada para trabajar con ella. La construimos en canales de <b>100 Gbps<\/b>. Los controlamos completamente, exceptuando las regiones en China. El tr\u00e1fico no se comparte con las cargas de otras empresas.<\/p>\n<p><img decoding=\"async\" alt=\"C\u00f3mo AWS &quot;cocina&quot; sus servicios el\u00e1sticos. Escalado de la red\" src=\"\/wp-content\/uploads\/2019\/10\/3359c6ade7215527f40ee3b54a0b700e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPor supuesto, no somos el \u00fanico proveedor de nube con una red backbone privada. Cada vez m\u00e1s grandes empresas est\u00e1n siguiendo este camino. Esto es confirmado por investigadores independientes, como los de <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.telegeography.com\/telegeographys-content-providers-submarine-cable-holdings-list\">Telegeography<\/a><\/noindex>.<\/p>\n<p><img decoding=\"async\" alt=\"C\u00f3mo AWS &quot;cocina&quot; sus servicios el\u00e1sticos. Escalado de la red\" src=\"\/wp-content\/uploads\/2019\/10\/b7aa723241783d131881caf5db73f7e6.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEn el gr\u00e1fico se puede ver que la participaci\u00f3n de los proveedores de contenido y de la nube est\u00e1 creciendo. Debido a esto, la participaci\u00f3n del tr\u00e1fico de Internet de los proveedores de backbone est\u00e1 disminuyendo constantemente.<\/p>\n<p>Voy a explicar por qu\u00e9 est\u00e1 sucediendo esto. Anteriormente, la mayor\u00eda de los servicios web estaban disponibles y se consum\u00edan directamente desde Internet. Ahora, cada vez m\u00e1s servidores est\u00e1n ubicados en la nube y son accesibles a trav\u00e9s de <b>CDN<\/b> \u2014 <b>Content Distribution Network<\/b>. Para acceder al recurso, el usuario navega por Internet solo hasta el PoP de CDN m\u00e1s cercano \u2014 <b>Point of Presence<\/b>. La mayor\u00eda de las veces, est\u00e1 cerca. Luego, sale de Internet p\u00fablico y por backbone privado vuela a trav\u00e9s del Atl\u00e1ntico, por ejemplo, y llega directamente al recurso.<\/p>\n<p>Es interesante c\u00f3mo cambiar\u00e1 Internet dentro de 10 a\u00f1os si esta tendencia se mantiene.<\/p>\n<h3>Canales f\u00edsicos<\/h3>\n<p>\nLos cient\u00edficos a\u00fan no han encontrado c\u00f3mo aumentar la velocidad de la luz en el universo, pero han avanzado mucho en los m\u00e9todos para transmitirla a trav\u00e9s de fibra \u00f3ptica. Ahora utilizamos cables con 6912 fibras. Esto ayuda a optimizar significativamente el costo de su instalaci\u00f3n.<\/p>\n<p>En algunas regiones, nos vemos obligados a utilizar cables especiales. Por ejemplo, en la regi\u00f3n de S\u00eddney utilizamos cables con un recubrimiento especial contra termitas.\u00a0<\/p>\n<p><img decoding=\"async\" alt=\"C\u00f3mo AWS &quot;cocina&quot; sus servicios el\u00e1sticos. Escalado de la red\" src=\"\/wp-content\/uploads\/2019\/10\/738bec49680ba7a31237862f0834942a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNo hay garant\u00eda contra los problemas, y a veces nuestros canales se da\u00f1an. En la foto de la derecha se pueden ver los cables \u00f3pticos en una de las regiones de Estados Unidos que fueron cortados por los constructores. Como resultado del accidente, solo se perdieron 13 paquetes de datos, lo cual es sorprendente. Una vez m\u00e1s, \u00a1solo 13! El sistema se conmut\u00f3 literalmente a los canales de respaldo en un instante: la escala funciona.<\/p>\n<p>Hemos recorrido r\u00e1pidamente algunos servicios y tecnolog\u00edas de la nube de Amazon. Espero que al menos haya adquirido una idea del alcance de las tareas que nuestros ingenieros deben resolver. Personalmente, esto me fascina mucho.\u00a0<\/p>\n<blockquote><p>Esta es la parte final de la trilog\u00eda de Vasiliy Pantiukhin sobre la estructura de AWS. En <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/oleg-bunin\/blog\/471686\/\">primera<\/a><\/noindex> esta parte se describen la optimizaci\u00f3n de servidores y la escalabilidad de bases de datos, y en <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/oleg-bunin\/blog\/464305\/\">el segundo<\/a><\/noindex> \u2014 funciones serverless y Firecracker.<\/p>\n<p>En <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/moscow\/2019\">HighLoad++.<\/a><\/noindex> en noviembre, Vasiliy Pantiukhin compartir\u00e1 nuevos detalles sobre la estructura de Amazon. \u00c9l <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/moscow\/2019\/abstracts\/5977\">contar\u00e1<\/a><\/noindex> hablar\u00e1 sobre las causas de fallos y el dise\u00f1o de sistemas distribuidos en Amazon. El 24 de octubre todav\u00eda se puede <noindex><a rel=\"nofollow\" href=\"https:\/\/conf.ontico.ru\/conference\/join\/hl2019.html\">reservar<\/a><\/noindex> obtener un boleto a buen precio, y pagarlo despu\u00e9s. \u00a1Lo esperamos en HighLoad++, venga y hablemos!<\/p><\/blockquote>\n<p>Fuente: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/oleg-bunin\/blog\/471688\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041c\u0430\u0441\u0448\u0442\u0430\u0431 \u0441\u0435\u0442\u0438 Amazon Web Services \u2014\u00a0\u044d\u0442\u043e 69 \u0437\u043e\u043d \u043f\u043e \u0432\u0441\u0435\u043c\u0443 \u043c\u0438\u0440\u0443 \u0432 22 \u0440\u0435\u0433\u0438\u043e\u043d\u0430\u0445: \u0421\u0428\u0410, \u0415\u0432\u0440\u043e\u043f\u0430, \u0410\u0437\u0438\u044f, \u0410\u0444\u0440\u0438\u043a\u0430 \u0438 \u0410\u0432\u0441\u0442\u0440\u0430\u043b\u0438\u044f. \u0412 \u043a\u0430\u0436\u0434\u043e\u0439 \u0437\u043e\u043d\u0435 \u043d\u0430\u0445\u043e\u0434\u0438\u0442\u0441\u044f \u0434\u043e 8 \u0426\u041e\u0414 \u2014 \u0426\u0435\u043d\u0442\u0440\u043e\u0432 \u041e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0414\u0430\u043d\u043d\u044b\u0445. \u0412 \u043a\u0430\u0436\u0434\u043e\u043c \u0426\u041e\u0414 \u0442\u044b\u0441\u044f\u0447\u0438 \u0438\u043b\u0438 \u0441\u043e\u0442\u043d\u0438 \u0442\u044b\u0441\u044f\u0447 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432. \u0421\u0435\u0442\u044c \u043f\u043e\u0441\u0442\u0440\u043e\u0435\u043d\u0430 \u0442\u0430\u043a, \u0447\u0442\u043e \u0432\u0441\u0435 \u043c\u0430\u043b\u043e\u0432\u0435\u0440\u043e\u044f\u0442\u043d\u044b\u0435 \u0441\u0446\u0435\u043d\u0430\u0440\u0438\u0438 \u043f\u0435\u0440\u0435\u0431\u043e\u0435\u0432 \u0432 \u0440\u0430\u0431\u043e\u0442\u0435 \u043f\u0440\u0438\u043d\u0438\u043c\u0430\u044e\u0442\u0441\u044f \u0432 \u0440\u0430\u0441\u0447\u0435\u0442. \u041d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u0432\u0441\u0435 \u0440\u0435\u0433\u0438\u043e\u043d\u044b [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":39305,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-39304","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041c\u0430\u0441\u0448\u0442\u0430\u0431 \u0441\u0435\u0442\u0438 Amazon Web Services \u2014 \u044d\u0442\u043e 69 \u0437\u043e\u043d \u043f\u043e \u0432\u0441\u0435\u043c\u0443 \u043c\u0438\u0440\u0443 \u0432 22 \u0440\u0435\u0433\u0438\u043e\u043d\u0430\u0445: \u0421\u0428\u0410, \u0415\u0432\u0440\u043e\u043f\u0430, \u0410\u0437\u0438\u044f, \u0410\u0444\u0440\u0438\u043a\u0430 \u0438 \u0410\u0432\u0441\u0442\u0440\u0430\u043b\u0438\u044f. \u0412 \u043a\u0430\u0436\u0434\u043e\u0439 \u0437\u043e\u043d\u0435 \u043d\u0430\u0445\u043e\u0434\u0438\u0442\u0441\u044f \u0434\u043e 8 \u0426\u041e\u0414 \u2014 \u0426\u0435\u043d\u0442\u0440\u043e\u0432 \u041e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0414\u0430\u043d\u043d\u044b\u0445.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-seti\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"es_ES\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041a\u0430\u043a AWS \u00ab\u0432\u0430\u0440\u0438\u0442\u00bb \u0441\u0432\u043e\u0438 \u044d\u043b\u0430\u0441\u0442\u0438\u0447\u043d\u044b\u0435 \u0441\u0435\u0440\u0432\u0438\u0441\u044b. \u041c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u0441\u0435\u0442\u0438 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041c\u0430\u0441\u0448\u0442\u0430\u0431 \u0441\u0435\u0442\u0438 Amazon Web Services \u2014 \u044d\u0442\u043e 69 \u0437\u043e\u043d \u043f\u043e \u0432\u0441\u0435\u043c\u0443 \u043c\u0438\u0440\u0443 \u0432 22 \u0440\u0435\u0433\u0438\u043e\u043d\u0430\u0445: \u0421\u0428\u0410, \u0415\u0432\u0440\u043e\u043f\u0430, \u0410\u0437\u0438\u044f, \u0410\u0444\u0440\u0438\u043a\u0430 \u0438 \u0410\u0432\u0441\u0442\u0440\u0430\u043b\u0438\u044f. \u0412 \u043a\u0430\u0436\u0434\u043e\u0439 \u0437\u043e\u043d\u0435 \u043d\u0430\u0445\u043e\u0434\u0438\u0442\u0441\u044f \u0434\u043e 8 \u0426\u041e\u0414 \u2014 \u0426\u0435\u043d\u0442\u0440\u043e\u0432 \u041e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0414\u0430\u043d\u043d\u044b\u0445.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-seti\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:29:40+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:29:40+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47 C\u00f3mo AWS \"cocina\" sus servicios el\u00e1sticos. Escalado de red | ProHoster","description":"La escala de la red Amazon Web Services es de 69 zonas en todo el mundo en 22 regiones: EE.UU., Europa, Asia, \u00c1frica y Australia. En cada zona hay hasta 8 centros de datos.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-seti","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u0430\u043a AWS \u00ab\u0432\u0430\u0440\u0438\u0442\u00bb \u0441\u0432\u043e\u0438 \u044d\u043b\u0430\u0441\u0442\u0438\u0447\u043d\u044b\u0435 \u0441\u0435\u0440\u0432\u0438\u0441\u044b. \u041c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u0441\u0435\u0442\u0438 | ProHoster","og:description":"\u041c\u0430\u0441\u0448\u0442\u0430\u0431 \u0441\u0435\u0442\u0438 Amazon Web Services \u2014 \u044d\u0442\u043e 69 \u0437\u043e\u043d \u043f\u043e \u0432\u0441\u0435\u043c\u0443 \u043c\u0438\u0440\u0443 \u0432 22 \u0440\u0435\u0433\u0438\u043e\u043d\u0430\u0445: \u0421\u0428\u0410, \u0415\u0432\u0440\u043e\u043f\u0430, \u0410\u0437\u0438\u044f, \u0410\u0444\u0440\u0438\u043a\u0430 \u0438 \u0410\u0432\u0441\u0442\u0440\u0430\u043b\u0438\u044f. \u0412 \u043a\u0430\u0436\u0434\u043e\u0439 \u0437\u043e\u043d\u0435 \u043d\u0430\u0445\u043e\u0434\u0438\u0442\u0441\u044f \u0434\u043e 8 \u0426\u041e\u0414 \u2014 \u0426\u0435\u043d\u0442\u0440\u043e\u0432 \u041e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0414\u0430\u043d\u043d\u044b\u0445.","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-seti","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:29:40+00:00","article:modified_time":"2019-10-31T19:29:40+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"39304","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 01:37:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 00:52:26","updated":"2026-01-24 01:37:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/39304","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=39304"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/39304\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/39305"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=39304"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=39304"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=39304"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}