Tietokantojen herättäminen ilman kuolleita yhteyksiä

Mythexissä julkaistut sovellukset ja niiden tietokannat menevät lepotilaan, kun kukaan ei käytä niitä. Kun sovellus heräsi, se saattoi pitää ensimmäistä pyyntöä 10–12 sekuntia, koska se yritti käyttää uudelleen tietokantayhteyksiä, jotka olivat kuolleet kaiken nukkuessa. Annamme nyt Spring Boot -sovelluksille tietokanta-asetukset, jotka kestävät lepotilan, ja ohjeistamme agenttia rakentamaan sovellukset kaikilla pinoilla samalla tavalla. Isännöintialustalla ensimmäinen pyyntö heräämisen jälkeen eteni 12,7 sekunnista 2,3 sekuntiin.

Miksi sovellukset ja tietokannat nukkuvat

Julkaistu Mythex-sovellus toimii koneella, joka pysähtyy muutaman minuutin käyttämättömyyden jälkeen, ja sen tietokanta on palvelimeton Postgres, joka nukkuu viisi minuuttia käyttämättömänä ja herää seuraavaan kyselyyn. Tämä pitää hiljaisen sovelluksen halpana: maksat siitä, mitä tietokanta todella käytti, ja nukkuva sovellus ei kuluta laskentaa. Kirjoitimme laskutuspuolesta artikkelissa tietokantojen laskuttaminen sen mukaan, mitä ne todella käyttävät.

Ongelma on se, että kaksi nukkuu erikseen eivätkä ne ole samaa mieltä siitä, mikä yhteys on.

Oire: hidas ensimmäinen käynti

Useimmat palvelinsovellukset pitävät yllä yhteysallasta: joukon avoimia tietokantayhteyksiä, jotka ovat valmiina, jotta jokainen pyyntö ei maksa uuden yhteyden avaamisen kustannuksia. Se on oikea suunnittelu sovellukselle, joka on aina päällä.

Näin nukkuminen vaikuttaa:

1. Sovellus on käynnissä, ja sen altaassa on muutama käyttämätön yhteys.
2. Kukaan ei käy. Sovelluksen kone pysähtyy, jäätyneenä altaineen ehjänä.
3. Tietokanta menee lepotilaan ja pudottaa oman päänsä jokaisesta yhteydestä.
4. Kävijä saapuu. Sovellus herää juuri sellaisena kuin oli, ja se pitää yhä yhteyksiä, joista tietokanta ei enää tiedä.
5. Allas antaa yhden noista yhteyksistä. Sen täytyy selvittää, että se on kuollut, kokeilemalla ja odottamalla, ennen kuin se luopuu siitä.

Spring Boot -sovelluksessa kuolleiden yhteyksien validointi esti ensimmäistä pyyntöä noin 10 sekuntia, ennen kuin se epäonnistui virheellä "Connection is not available". Kävijälle sivusto vain jäätyi, ja sitten ehkä näytti virheen.

Miksi Spring-sovellukset kärsivät eniten

Spring Boot on suosittu Java-kehys, ja se käyttää oletuksena yhteysallasta nimeltä HikariCP. Spring voi määrittää altaan asetuksista, mukaan lukien kuinka monta käyttämätöntä yhteyttä pidetään yllä.

Mythex antaa kuitenkin jokaiselle sovellukselle tietokantansa yhtenä DATABASE_URL-muuttujana muodossa postgresql://user:pass@host/db. Spring ei lue tätä muotoa suoraan. Joten Mythexillä rakennetut Spring-sovellukset rakensivat oman altaansa koodissa jäsentämällä tämän URL:n, ja käsin rakennettu allas ohittaa kaikki Springin spring.datasource.*-asetukset. Vaikka joku olisi tiennyt oikeat allasasetukset, ei ollut paikkaa, jossa ne olisivat vaikuttaneet.

Korjaus, osa 1: asetukset, joita Spring voi käyttää

Kun projektilla on tietokanta, sille annetaan nyt myös ympäristömuuttujat, jotka Spring lukee suoraan:

• SPRING_DATASOURCE_URL, SPRING_DATASOURCE_USERNAME ja SPRING_DATASOURCE_PASSWORD, muunnettuna DATABASE_URL:stä (SSL vaaditaan, ellei URL sano toisin).
• Allasasetukset, jotka selviävät lepotilasta:

Kun käyttämättömiä yhteyksiä ei pidetä auki, herännyt sovellus avaa yhden uuden yhteyden sen sijaan, että kahlaisi kuolleiden läpi.

Kun nämä muuttujat ovat olemassa, Spring määrittää altaan itse ja asetukset tulevat voimaan. Projektin itse asettamat arvot voittavat aina; me täytämme vain puuttuvat. Muut kuin Spring-sovellukset jättävät nämä muuttujat huomiotta.

Yksityiskohta, joka melkein teki siitä tyhjän

Spring kartoittaa ympäristömuuttujat asetuksiinsa säännöllä, jonka helposti rikkoo. Asetus minimum-idle pitää kirjoittaa muodossa SPRING_DATASOURCE_HIKARI_MINIMUMIDLE: viivat pudotetaan pois ja sanat yhdistetään. Kirjoitettuna SPRING_DATASOURCE_HIKARI_MINIMUM_IDLE, mikä näyttää luonnollisemmalta, se kartoittuu eri, olemattomaan asetukseen (minimum.idle) ja jää hiljaa huomiotta.

Tällainen virhe läpäisee jokaisen katselmoinnin ja ei tee mitään tuotannossa. Siksi testi tarkistaa sekä, että arvot on asetettu, että yksikään muuttuja ei käytä alaviivoilla erotettua muotoa.

Korjaus, osa 2: kaikki muut pinot

Spring ei ole ainoa kehys, jolla on allas, eikä voi esikonfiguroida jokaista kirjastoa jokaisella kielellä. Mythex-agentti, joka kirjoittaa sovelluksesi, saa nyt pysyvän ohjeen mille tahansa pinolle: julkaistut sovellukset ja niiden tietokannat menevät lepotilaan käyttämättömänä, joten avoin tietokantayhteys voi olla kuollut seuraavalla pyynnöllä. Sen pitää:

• pitää auki nolla käyttämätöntä tietokantayhteyttä tai tarkistaa jokainen ennen käyttöä,
• yrittää uudelleen kerran yhteysvirheen sattuessa, ja
• käyttää alustan ympäristöön antamia tietokanta-asetuksia sen sijaan, että rakentaisi oman altaan jäsentämällä DATABASE_URL:n.

Viimeinen kohta sulkee silmukan osan 1 kanssa: sovellus, joka on rakennettu alustan tarjoamien asetusten varaan, saa lepotilaa kestävän määrityksen automaattisesti.

Tulos

Mitattuna alustalla, jolla ajamme julkaistuja sovelluksia, ensimmäinen pyyntö heräämisen jälkeen eteni 12,7 sekunnista 2,3 sekuntiin.

Mitä tästä opimme

• Jokaisen lepotilaan menevän kerroksen täytyy olla samaa mieltä siitä, mikä säilyy. Jäätynyt sovellus ja nukkuva tietokanta tekivät kumpikin järkevän valinnan. Yhdessä sovellus heräsi tilan kanssa, joka ei enää pitänyt paikkaansa.
• Aina päällä olevien palvelimien oletukset eivät sovi sovelluksille, jotka skaalautuvat nollaan. Yhteyksien pitäminen lämpiminä on hyvä idea, kunnes kaikki niiden ympärillä on kylmää.
• Anna kehyksille niiden data niiden omassa muodossa. Yksi URL oli meille yksinkertainen, mutta se pakotti jokaisen Spring-sovelluksen käsin rakentamaan altaan, joka ohitti sen oman määrityksen.
• Testaa, että asetus on kirjoitettu niin kuin kehys sen lukee. Oikea arvo väärällä nimellä ei tee mitään, hiljaa.

Jos olet uusi tietokantojen toiminnassa Mythexissä, katso tietokantadokumentaatio ja selitys mikä Postgres on.