Verkon varmuus pettää, kun ohjauskerros pettää

Monipilvi ei aina tarkoita luotettavuutta

Monipilviarkkitehtuuri näyttää paperilla turvalliselta ratkaisulta. Kun sovellukset pyörivät useammalla eri alustalla, yhden palveluntarjoajan ongelmat eivät pitäisi kaataa koko palvelua. Moni yritys uskookin, että näin toimimalla ne välttyvät suurilta katkoksilta.

Railway testasi tätä asetelmaa käytännössä. Sen asiakkaiden sovellukset pyörivät sekä AWS:ssä että Google Cloudissa, ja osittain myös yhtiön omalla laitteistolla. Redundanssi näytti olevan kunnossa.

Sitten tapahtui jotain odottamatonta. Google Cloudin automaattijärjestelmä sulki Railwayn tuotantotilin ilman varoitusta. Tilanne kesti kahdeksan tuntia, ja vaikka varsinaiset sovellukset jatkoivat toimintaansa, palvelu oli silti poikki.

Reititys riippuu yhdestä pisteestä

Suurin ongelma ei ollut sovellusten sijainnissa. Se oli siinä, miten liikenne ohjautui oikeaan paikkaan.

Jokainen pyyntö kulki ensin edge-proxyjen kautta. Nämä välittäjät tarvitsivat ajantasaista tietoa siitä, missä kukin sovellus sijaitsi. Tiedot tulivat Railwayn control planesta, joka oli kokonaan Google Cloudin varassa.

Kun tili suljettiin, control plane ei enää antanut tietoja. Proxyilla oli väliaikainen välimuisti, joka toimi noin 35 minuuttia. Sen jälkeen pyyntöjen reititys romahti. Käyttäjät saivat 404-virheitä, vaikka sovellukset itse olivat täysin kunnossa.

Seuraavat ongelmat seurasi nopeasti

Failed requests -määrä kasvoi niin paljon, että GitHub rajoitti Railwayn OAuth-liikenteen. Tämä ei ollut GitHubin ongelma – se yksinkertaisesti suojasi itseään. Silti se esti käyttäjien kirjautumisen ja estää myöhemmään myös uuden deployn.

Redundanssi vaatii enemmän kuin hajautetut sovellukset

Railwaylla sovellukset olivat hajautettuja,但 control plane ei ollut. Tämä on helppo unohtaa. Reititys, palveluiden löytäminen ja sovellusten ohjaus tarvitseivat kaikki samaa infrastruktuuria.

Monipilviarkkitehtuuri ei suojaa, jos näiden kriittisten osien redundanssia ei ole rakennettu samoin. Caching auttoi hetkellisesti, mutta se on vain väliaikainen mitta. True resilience vaatii hajautetun control planen.

Mitä tästä voi oppia

• Control plane -redundanssi vaatii erillisen huomion, sillä se ei jaasi sovellusten hajauttamisen kanssa.
• Cache toimii vain tehostajana,而不是 ratkaisuna.
• Yksi ongelma kaataa yleensä seuraavan, ja incindent response -prosessit ovat tärkeä osa resilienssiä.
• Cloud providerin automaattiset järjestelmät voivat kaataa palvelu,，所以 edellyttää suunnitelmallista kommunikointia ja escalation-protokollia.

Railway on nyt päättänyt hajauttaa control planensa myös AWS:ssä ja omalla laitteistolla. Tämä on tyypillistä tapausta, jossa ongelmat paljastavat todellisia single points of failure – ja yleinen muistutus, että monipilviarkkitehtuurin vaatii huomion myös luottamukseen ja orchestrationin redundanssiin.