Näkymätön moottori nykyaikaisen SaaS:n takana Kun käyttäjä napsauttaa SaaS-tuotteen kirjautumista tai pyytää tiettyjä tietoja, he odottavat reaaliaikaista reagointia ja luotettavuutta. Tämän yksinkertaisen vuorovaikutuksen takana on hienostunut backend, joka on suunniteltu skaalaamaan, itsehoitoon ja jakamaan kuormitusta mikropalvelujen tähdistöön. Mutta kun yhä useammat startup-yritykset omaksuvat pilvipohjaisia malleja ja konttipalvelut tulevat selkärankaan, yksi haaste ilmenee toistuvasti: miten voimme älykkäästi tasapainottaa liikennettä niin, että se ei vain jakaudu tasaisesti, vaan reititetään terveellisimpiin, nopeimpiin ja luotettavimpiin palvelun päätepisteisiin? Tämä on paljon monimutkaisempaa kuin klassinen pyöreä-robin reititys. Kuten kuka tahansa, joka käyttää tuotantojärjestelmiä, on oppinut, naiivi liikenteen jakelu johtaa kaskadeihin, kun yksi palvelu menee epäterveelliseksi, tai pullonkauloihin, kun uudet versiot eivät ole valmiita tuotantoon. Tässä artikkelissa jaan yksityiskohtaisen backend-arkkitehtuurin pilvipohjaiselle SaaS: lle GCP: llä keskittyen Dockerisoitujen Python-mikrosivustojen kuormien tasapainottaminen – Cloud Load Balancing, GKE/Cloud Run, hallittu VPC, vankka IAM ja alkuperäiset havainnointiominaisuudet. Älykäs 1. Ongelmakonteksti: Miksi naiivi kuormien tasapainottaminen epäonnistuu tuotannossa Uusi Billing pod -versio käynnistää, että se kestää 30 sekuntia lämmittääkseen tietokannan yhteyspohjan. Tai ehkä pod on jumissa käsittelemään erän vientiä koskevaa tehtävää, jolloin viive nousee 5x normaaliksi. Ehkä on muistin vuoto, joka hitaasti heikentää suorituskykyä tuntien aikana. Klassiset kuormituksen tasapainottajat jatkavat käyttäjien reitittämistä näihin vaikeuksiin, koska teknisesti ne vastaavat edelleen perusterveystarkastuksiin. Jopa sisäänrakennetuilla Kubernetes-valmiustunnisteilla oletusarvoisella GCP-hallitulla kuorman tasapainotuslaitteella ei aina ole riittävästi terveystietoja välttääkseen hitaita tai epäonnistuvia päätepisteitä välittömästi. Laite voi tarkistaa 10 sekunnin välein, mutta pod voi epäonnistua dramaattisesti väliintulossa. Mitä tarvitsemme, on älykäs kuorman tasapainotus, jota ohjaavat yksityiskohtaiset terveyssignaalit, valmiusportit, reaaliaikaiset mittarit ja nopea epäonnistumisen havaitseminen. Arkkitehtuuri, jonka aiot käydä läpi, vastaa juuri näihin haasteisiin, jotka on otettu vuosien tuotannon SaaS-alustojen käyttämisestä Google Cloudissa. 2. Älykäs kuorman tasapainottaminen Ennen kuin kirjoitan yhden kappaleen koodia tai tarjoan infrastruktuuria, olen oppinut, että on tärkeää olla tarkka siitä, mitä "älykäs" todella tarkoittaa tässä yhteydessä. liian usein tiimit hyppäävät suoraan toteutukseen määrittelemättä onnistumiskriteerejä, vain kuukausia myöhemmin löytää, että niiden kuormien tasapainottamisstrategialla on hienovaraisia mutta kriittisiä aukkoja. Älykäs kuormituksen tasapainottaminen tarkoittaa, että järjestelmä lähettää liikennettä vain terveille, eläville ja aidosti reagoiville podsille - ei vain podsille, jotka eivät ole vielä kaatuneet. Se tarkoittaa erottamista teknisesti käynnissä olevien säiliöiden ja niiden välillä, jotka ovat todella valmiita käsittelemään tuotantoliikennettä. Olen nähnyt liikaa tapauksia, joissa pod läpäisee terveystarkastuksensa, mutta käynnistää edelleen tietokantojen yhteydet tai lämmittää välimuistia, mikä johtaa ensimmäisten käyttäjien ajoituksiin. Yksinkertaisen terveyden lisäksi älykkään reitityksen on otettava huomioon reaaliaikaiset suorituskyvyn ominaisuudet. Pod voi olla terve, mutta tällä hetkellä kokee suuren latenssin roskapostin keräämisen tai resurssien ristiriidan vuoksi. Kuormituksen tasapainottajan tulisi mieluummin käyttää päätepisteitä, joissa on alhaisemmat, vakaammat reagointiajat. Kun pod alkaa näyttää suuria virhetasoja tai hidastumisia, järjestelmä tarvitsee palautteen kierroksen väliaikaisesti sen ympärille, vaikka perinteiset terveystarkastukset osoittaisivat sen edelleen toimivaksi. Arkkitehtuurin on myös pelattava hyvin joustavalla skaalautumisella. Kun pohjat kääntyvät ylös ja alas vastauksena liikennemalleihin, kuormituksen tasapainottajan on integroitava sujuvasti uusi kapasiteetti tyhjentämällä liikennettä lopetukseen ajoitetuista pohjista. Ja kriittisesti, kaikki tämä tarvitsee havaittavuutta, joka on rakennettu ensimmäisestä päivästä lähtien. Ilman lokeja, jälkiä ja mittareita, jotka palaavat reitityspäätöksiin, lennät sokeasti. 3. Cloud-Native Backend -arkkitehtuurin suunnittelu 3.1 Mikrosivustojen suunnittelu (Python, Docker) Olen havainnut, että liian monet mikropalvelut käsittelevät terveystarkastuksia jälkikäteen, toteuttaen ne yksinkertaisella "palautus 200 OK" -menetelmällä, joka kertoo kuorman tasapainottajalle mitään hyödyllistä. Tässä on Python-pohjainen laskutuspalvelu, joka osoittaa mallin, jota käytän tuotannossa. Huomaa, miten se erottaa terveyden (onko prosessi elossa?) valmiudesta (onko se valmis palvelemaan liikennettä?): # billing_service.py from flask import Flask, jsonify import random import time app = Flask(__name__) @app.route("/healthz") def health(): # Report healthy 95% of the time, failure 5% if random.random() < 0.95: return "OK", 200 else: return "Unhealthy", 500 @app.route("/readyz") def ready(): # Simulate readiness delay on startup if time.time() - START_TIME < 10: return "Not Ready", 503 return "Ready", 200 @app.route("/pay", methods=["POST"]) def pay(): # Simulate payment processing latency latency = random.uniform(0.05, 1.5) time.sleep(latency) return jsonify({"status": "success", "latency": latency}) if __name__ == "__main__": global START_TIME START_TIME = time.time() app.run(host='0.0.0.0', port=8080) Tällainen eriyttäminen ja kuvastaa sitä, mitä olen toteuttanut kymmeniin tuotantopalveluihin. Terveydenhuollon päätepiste kertoo Kubernetesille, pitäisikö prosessi käynnistää uudelleen – ehkä se on tukkeutunut tai sen tiedostojen kuvaajat ovat tyhjentyneet. Valmiuspäätepiste osoittaa, saako pod tuotantoliikennettä. Niiden kriittisten ensimmäisten sekuntien aikana käynnistyksen jälkeen, kun palvelu luo tietokannan yhteyksiä, lämmittää välimuistia tai ladata Configuration Secret Managerilta, valmius palauttaa 503. Kuorman tasapainottaja osaa odottaa. /healthz /readyz Todellisessa tuotantokoodissa valmiustarkistuksesi tarkistaisi todelliset riippuvuudet. Voisitko pingata tietokannan? Onko Redis reagoiva? Oletko ladannut ML-mallisi muistiin? Erityisesti laskutuspalvelua varten voit tarkistaa, onko Stripe SDK:n aloittaminen suoritettu tai onko petosten havaitsemista koskevat säännöt ladattu onnistuneesti. Terveystarkistuksen satunnaisuus tässä simuloi tuotannossa kohtaamasi keskeytykselliset epäonnistumiset - verkkohyppyjä, väliaikaisia resurssien uupumuksia tai ulkoisia riippuvuuksien hiccupeja. 3.2 Säilytys: Dockerfile Esimerkki Kun palvelusi paljastaa tilansa asianmukaisesti, sen pakkaaminen pilvipohjaiseen käyttöönottoon muuttuu yksinkertaiseksi. # Dockerfile FROM python:3.11-slim WORKDIR /app COPY billing_service.py . RUN pip install flask EXPOSE 8080 CMD ["python", "billing_service.py"] Tuotannossa haluat parantaa tätä monivaiheisilla rakenteilla minimoidaksesi kuvan koon, toimimalla ei-root-käyttäjänä turvallisuuden varmistamiseksi ja mahdollisesti käyttämällä requirements.txt-muotoa riippuvuuden hallintaan. Mutta ydinmalli on edelleen: ohut pohjakuva, vähäiset kerrokset, selkeä syöttökohta. Olen havainnut, että säiliön käynnistysajan optimointi on yksi älykkään kuormituksen tasapainottamisen suurimmista vipuvaikutuksista, koska nopeammat käynnistykset merkitsevät vähemmän aikaa "valmis" tilassa ja sujuvampaa skaalausta. 3.3 GCP Resource Provisioning: Rakentaminen ja käyttöönotto Kun palvelusi on säilytetty, seuraava askel on saada se GCP: n esineiden rekisteriin ja klusteriin. Rakenna tämä tyypillisesti toistettavissa olevaksi putkiksi, mutta tässä on manuaalinen työnkulku ymmärtääksesi, mitä kappaleen alla tapahtuu: # Build, tag, and push Docker image to GCP Artifact Registry gcloud artifacts repositories create python-services --repository-format=docker --location=us-central1 docker build -t us-central1-docker.pkg.dev/${PROJECT_ID}/python-services/billing-service:v1 . gcloud auth configure-docker us-central1-docker.pkg.dev docker push us-central1-docker.pkg.dev/${PROJECT_ID}/python-services/billing-service:v1 Artifact-rekisteri antaa sinulle haavoittuvuuden skannauksen laatikon ulkopuolelle, paremman IAM-integraation ja alueelliset replikaatiovaihtoehdot, jotka tulevat kriittisiksi, kun käytät monen alueen palveluja.Olen siirtänyt useita tuotantojärjestelmiä Container-rekisteristä Artifact-rekisteriin, ja parempi turvallisuusasenne yksin oikeutti ponnistelun. Nyt tulee käyttöönottokokoonpano, jossa älykäs kuorman tasapainottaminen todella alkaa muotoutua: # k8s/billing-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: billing-service spec: replicas: 3 selector: matchLabels: app: billing-service template: metadata: labels: app: billing-service spec: containers: - name: billing-service image: us-central1-docker.pkg.dev/YOUR_PROJECT/python-services/billing-service:v1 ports: - containerPort: 8080 livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 5 periodSeconds: 5 readinessProbe: httpGet: path: /readyz port: 8080 initialDelaySeconds: 5 periodSeconds: 5 Huomioi koelaitteen kokoonpano. Tarkistan terveyden 5 sekunnin välein, mikä tuotannossa voi olla liian aggressiivista palvelun ominaisuuksista riippuen. Sinun täytyy säätää nämä arvot todellisen käyttäytymisen perusteella. Jos terveystarkastukset itsestään tulevat kuormituksen lähteeksi, pidentää aikaa. Jos tarvitset nopeampaa epäonnistumisen havaitsemista, lyhennä sitä – mutta valmistaudu enemmän vääriin myönteisiin ohimenevien ongelmien aikana. Sillä Asetus on kriittinen ja usein väärin määritetty. Aseta se liian lyhyeksi, ja pods epäonnistuu terveystarkastuksissa normaalin käynnistyksen aikana, mikä luo uudelleenkäynnistysnopeuden. Aseta se liian kauan, ja tuhlaat aikaa ennen kuin liikenne voi virrata äskettäin skaalatuille podsille. Aloitan yleensä arvolla 2x havaittu käynnistysaika kehityksessä, sitten säädän tuotannon mittausten perusteella. initialDelaySeconds Käynnistä palvelu ja paljasta se näillä komentoilla: kubectl apply -f k8s/billing-deployment.yaml kubectl expose deployment billing-service --type=LoadBalancer --port 80 --target-port 8080 Tämä luo automaattisesti GCP Load Balancerin käyttöönoton edessä, mikä tuo meidät seuraavaan älykkyyskerrokseen. 3.4 GCP-kuorman tasapainotin älykkäillä terveystarkastuksilla Kun luot LoadBalancer-tyyppisen Kubernetes-palvelun, GCP tarjoaa HTTP(S) Load Balancerin, joka integroituu syvästi GKE-klusterisi kanssa. Todellinen teho tulee mahdollistamalla konttien alkuperäisen kuorman tasapainottaminen Network Endpoint Groups (NEG) -ryhmien kautta. Tämä mahdollistaa GCP-kuorman tasapainottajan reitittää suoraan pod-IP-osoitteisiin sen sijaan, että kulkisi kuubaproxy- ja iptablen kautta, mikä vähentää latenssia ja parantaa terveystarkastuksen tarkkuutta: # k8s/billing-service.yaml apiVersion: v1 kind: Service metadata: name: billing-service annotations: cloud.google.com/neg: '{"ingress": true}' # Enables container-native load balancing spec: type: LoadBalancer ports: - port: 80 targetPort: 8080 selector: app: billing-service Tämä yksittäinen merkintä - —muuttaa kuorman tasapainottamisarkkitehtuuria. Olen mitannut 20-30% viiveen parannuksia tuotannossa vain NEG:ien avulla, koska poistat verkon hyppäämisen ja iptables-käsittelyn. Tärkeämpää tarkoituksessamme on, että se antaa GCP-kuorman tasapainottajalle suoran näkyvyyden pod-terveyteen. Kun valmiustesti epäonnistuu, backend poistetaan välittömästi kuorman tasapainottajan kierrosta. Ei lopullista johdonmukaisuutta, ei viivettä odottaa, että päätepisteet päivittyvät. cloud.google.com/neg Kun se on otettu käyttöön, voit hienosäätää terveystarkastuskäyttäytymistä GCP-konsolin tai gcloud-komentojen kautta. Tuotannossa säädän tavallisesti terveystarkastusaikaa tasapainottamaan nopean epäonnistumisen havaitsemisen ja ylipääsyn välillä. Määrittelen myös epäterveellisen kynnyksen - kuinka monta peräkkäistä epäonnistumista ennen taustaosan poistamista - sen perusteella, mieluummin käytettävissä (toleroi ohimeneviä epäonnistumisia) tai luotettavuus (häiritse nopeasti). Laskutuspalvelun käsittelymaksujen osalta käännyn aggressiiviseen epäonnistumisen havaitsemiseen, koska osittaiset epäonnistumiset voivat tarkoittaa kaatuneita liiketoimia. 4. Käyttövalmiuden, skaalautumisen ja joustavuuden käyttöönotto 4.1 Mahdollistaa horisontaalisen Pod Autoscaling Älykäs kuormituksen tasapainottaminen ei tarkoita pelkästään tehokasta reititystä olemassa oleviin taustapisteisiin – se tarkoittaa sitä, että sinulla on aina käytettävissä oikea määrä terveitä taustapisteitä. Oikean terveystarkastuksen ja autoscalingin yhdistämisen kauneus on se, että uudet podit tulevat kuormituksen tasapainotin pyörimiseen vasta, kun ne ovat todella valmiita. Ei ole kilpailuolosuhteita, joissa liikenne osuu podiin, joka on vielä aloittelemassa. kubectl autoscale deployment billing-service --cpu-percent=70 --min=3 --max=10 Olen tuskallisen kokemuksen kautta oppinut, että vähimmäismäärän määrittäminen on yhtä tärkeää kuin enimmäismäärän määrittäminen. Kun tuotannossa on alle 3 kopiota, yksittäinen podin epäonnistuminen tai käyttöönotto edustaa merkittävää prosenttiosuutta kapasiteetistasi, mikä johtaa kaskadiseen ylikuormitukseen. 70 prosentin kynnysarvo on konservatiivinen, mikä on mieluummin rahoitustapahtumien käsittelyyn tarkoitettuja palveluja. Vähemmän kriittisiä palveluja varten voit työntää 80-85%: iin resurssien tehokkuuden maksimoimiseksi. Mutta tässä on se, mikä on tärkeää: automaattisen skaalautumisen yhdistäminen lukemisen todennäköisyyksiin tarkoittaa, että liikenneruuhkia käsitellään hienovaraisesti. Uudet podsit kiertävät, aloittavat asianmukaisesti (suljettu liikenteestä valmiuden mukaan) ja liittyvät sitten saumattomasti kuorman tasapainopolttoaineeseen, kun se on valmis. Kehittyneemmissä asetuksissa olen laajentanut tätä käyttämään räätälöityjä mittareita - skaalausta pyynnön jonotiheyden tai P95-latauksen perusteella eikä pelkästään CPU: n sijaan. GCP mahdollistaa tämän Custom Metrics API: n kautta, jolloin sovelluksesi voi viedä liiketoiminnan logiikka-tietoisia mittareita, jotka ohjaavat skaalauspäätöksiä. 4.2 Fine-Grained Traffic Split turvallisten käyttöönottojen varmistamiseksi Jopa älykkäillä terveystarkastuksilla ja automaattisella skaalautumisella uuden koodin käyttöönotto on edelleen tuotannon suurimpia riskejä aiheuttava toiminta. Virhe, joka tekee siitä ohitetun, voi viedä pois koko palvelun, jos se levitetään kaikkiin nappeihin samanaikaisesti.Tämä on paikka, jossa liikenteen jakautuminen ja kanavien käyttöönototot ovat ratkaisevia, ja jossa GKE: n integrointi GCP-kuormituksen tasapainottamiseen todella loistaa. Käytän useimmiten mallia, joka on kanarialaisten käyttöönotto prosenttiosuusperusteisella liikenteen jakautumisella. Käytät uutta versiota pienelle määrälle podsia säilyttäen vakaan version ja vaihdat sitten vähitellen liikennettä havaittujen terveysmetriikoiden perusteella. # k8s/billing-deployment-canary.yaml apiVersion: apps/v1 kind: Deployment metadata: name: billing-service-canary spec: replicas: 1 selector: matchLabels: app: billing-service version: canary template: metadata: labels: app: billing-service version: canary spec: containers: - name: billing-service image: us-central1-docker.pkg.dev/YOUR_PROJECT/python-services/billing-service:v2 ports: - containerPort: 8080 livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 5 periodSeconds: 5 readinessProbe: httpGet: path: /readyz port: 8080 initialDelaySeconds: 5 periodSeconds: 5 Palveluvalintasi sisältää molemmat ja Aluksi, vain 1 kanarian kopio verrattuna 3 vakaaseen kopioon, noin 25% liikenteestä osuu uuteen versioon. Voit seurata virhetasoja, viiveitä ja liiketoimintamittareita. Jos kaikki näyttää terveeltä tunnin kuluttua, voit lisätä kanarian kopioita 2, sitten 3, sitten lopulta edistää sitä vakaaksi, kun poistat vanhan version käytöstä. stable canary Mikä tekee tästä tehokkaan, on se, miten se vuorovaikutuksessa terveystarkastusten kanssa. Jos Canary-versiossasi on kriittinen vika, joka aiheuttaa sen epäonnistumisen valmiustarkastuksissa, se ei koskaan saa tuotantoliikennettä ensimmäisessä paikassa. Siirtäminen päättyy, pod käynnistyy, mutta kuorman tasapainottaja jatkaa reititystä sen ympärillä. Vielä kehittyneempiä käyttöönottoja varten GCP:n liikennejohtaja mahdollistaa tarkan liikenteen jakautumisen prosenttiosuudet, otsikkopohjaisen reitityksen tiettyjen skenaarioiden testaamiseksi ja integroinnin palveluverkkoominaisuuksiin.Yhdessä tuotantojärjestelmässä, jossa työskentelin, reititimme sisäisen työntekijöiden liikenteen kanariin versioihin pitämällä koko asiakastiedon vakaana, mikä antaa meille todellisen testin ilman asiakassuhdetta. 5. Havaittavuus: Terveyden, viiveen ja epäonnistumisten seuranta 5.1 Kirjautuminen ja seuranta Cloud Operations Suite -ohjelmalla Tässä on epämukava totuus kuormituksen tasapainottamisesta: voit rakentaa maailman hienostuneimman reitityslogian, mutta ilman havaittavuutta olet sokea siitä, toimiiko se todella. Tällöin GCP:n Cloud Operations Suite tulee välttämättömäksi. Integraatio GKE:n kanssa on riittävän syvä, jotta saat pod-tason mittauksia, säiliöpäiväkirjoja ja hajautettuja jälkiä minimaalisella konfiguraatiolla. Laskutuspalvelua varten vien useita mittariluokkia. Ensinnäkin perusasiat - pyyntölaskenta, virhetaso, viivästysprosenttiilit. Nämä virtaavat automaattisesti GCP: n hallitseman Prometheuksen kautta, jos altistut niille oikeassa muodossa. Toiseksi terveystarkastuksen tulokset ajan myötä, mikä auttaa tunnistamaan epäonnistumisten kuvioita. Onko pod epäonnistunut terveystarkastuksissa joka aamu klo 2 tietokannan ylläpidon aikana? Se on signaali terveystarkastuksen logiikan säätämiseksi tai ylläpidon ikkunoiden säätämiseksi. Kolmanneksi, ja mikä tärkeintä, räätälöidyt liiketoiminnan mittaukset, jotka edustavat todellista palvelun terveyttä käyttäjän näkökulmasta. Laskutuksessa tämä voi olla maksujen onnistumisprosentti, palautusten käsittelyaika tai petosten havaitsemisen viive.Nämä mittaukset ilmoittavat automaattisesta skaalautumisesta, hälytyksestä ja lopulta kuormien tasapainottamisesta. Tässä on, miten voit viedä mukautettuja mittareita käyttämällä OpenTelemetryä Flask-palvelusta: # Export Flask metrics (latency, errors) using OpenTelemetry from opentelemetry import metrics from opentelemetry.exporter.cloud_monitoring import CloudMonitoringMetricsExporter from opentelemetry.sdk.metrics import MeterProvider from opentelemetry.sdk.metrics.export import PeriodicExportingMetricReader exporter = CloudMonitoringMetricsExporter() meter_provider = MeterProvider( metric_readers=[PeriodicExportingMetricReader(exporter, export_interval_millis=5000)] ) metrics.set_meter_provider(meter_provider) meter = metrics.get_meter(__name__) payment_latency = meter.create_histogram( "billing.payment.latency", unit="ms", description="Payment processing latency" ) # In your endpoint: @app.route("/pay", methods=["POST"]) def pay(): start = time.time() # ... process payment ... duration_ms = (time.time() - start) * 1000 payment_latency.record(duration_ms) return jsonify({"status": "success"}) Näillä mittareilla, jotka virtaavat pilvipalveluun, SRE-tiimisi voi tehdä tietoon perustuvia päätöksiä. Milloin sinun pitäisi skaalata? Milloin kanariini on todella turvallisempi kuin vakaa versio? Mitkä podit ovat johdonmukaisesti hitaampia kuin heidän ikäisensä? Olen rakentanut ohjauspaneeleja, jotka osoittavat per-pod latenssin jakautumiset, mikä tekee siitä välittömästi ilmeisen, kun yksi pod on heikentynyt. Toinen tärkeä osa on jäljittäminen. Cloud Trace -integraatio GKE: n kanssa tarkoittaa, että voit seurata kuorman tasapainottajan pyyntöä laskutuspalvelun kautta ja maksuprosessoreille lähetettäviin jäljellä oleviin puheluihin. Kun P95-viive nousee, voit määrittää, onko kyseessä koodi, tietokantakysely tai ulkoiset API-puhelut. Tämä näkyvyyden syvyys muuttaa vianmäärityksen arvauksesta tietopohjaiseen tutkimukseen. 5.2 Varoitukset epäonnistumisista ja viivästymisen heikkenemisestä Määritän hälytyskäytännöt, jotka käsittelevät eri signaalityyppejä asianmukaisesti – jotkut vaativat välittömiä sivuja, toiset vain luovat lippuja tutkimiseen työaikana. Laskutuspalvelun kannalta kriittisiin hälytyksiin kuuluvat virhetasot, jotka ylittävät yhden prosentin, jotka kestävät yli 5 minuuttia, tai maksujen käsittelyn epäonnistuminen kaikissa yrityksissä 2 minuutin ikkunassa. Nämä sivut on kutsuttu, koska ne edustavat välitöntä asiakasvaikutusta. Keskisuurten vakavuuksien hälytykset saattavat syttyä, kun P95: n viive ylittää 1 sekunnin, tai kun pod epäonnistuu terveystarkastuksissa yli 3 kertaa 10 minuutissa. Nämä luovat lippuja, mutta eivät sivuja - ne osoittavat heikentyneen suorituskyvyn, joka tarvitsee tutkimusta, mutta ei vielä kriittistä. Avain on yhdistää hälytykset automatisoituihin vastauksiin aina, kun se on mahdollista. Kun virhetaso nousee kanarianpohjilla, palauta käyttöönotto automaattisesti. Kun automaattinen skaalaus maksimoi kapasiteetin, ilmoita soittamisen insinöörille selvittääksesi, tarvitsetko lisää rajoituksia tai optimoida suorituskykyä. Kun pod epäonnistuu jatkuvasti terveystarkastuksissa käynnistyksen jälkeen, tappaa se ja anna Kubernetesin ajoittaa uudelleen - ehkä se laskeutui heikentyneelle solmulle. Olen rakentanut automaation näiden hälytysten ympärille käyttämällä Cloud Functions -toimintoja, jotka on käynnistetty Cloud Monitoringin Pub/Sub -viestien avulla. Toiminto voi skaalata käyttöönottoja, käynnistää pods-liikennettä uudelleen tai jopa tyhjentää liikennettä koko klusterista, jos mittarit osoittavat vyöhyketason epäonnistumisen. 6. Turvallinen verkostoituminen, IAM ja palvelun käyttöoikeus 6.1 Sisäisen liikenteen rajoittaminen VPC:llä Älykäs kuormien tasapainottaminen ei ole pelkästään reititystehokkuudesta vaan myös turvallisuudesta. Tuotannon SaaS-järjestelmät tarvitsevat syvällistä puolustusta, jossa yhden palvelun vaarantaminen ei anna pääsyä koko infrastruktuuriin. Käytän tuotannon GKE-klustereita yksityisinä klustereina, mikä tarkoittaa, että solmuilla ei ole julkisia IP-osoitteita eikä niihin voi päästä internetistä paitsi kuormituksen tasapainottajan kautta.Klusterissa käytän Kubernetes NetworkPolicies -käytäntöjä, jotta voin valvoa, mitkä palvelut voivat kommunikoida: # k8s/network-policy.yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: billing-allow-internal spec: podSelector: matchLabels: app: billing-service policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: app: api-gateway Tämä käytäntö varmistaa, että vain merkityt voi käynnistää yhteyksiä laskutuspalveluihin.Jos hyökkääjä vaarantaa ilmoituspalvelusi, he eivät voi suoraan käyttää laskutusta.Heidän pitäisi kiertää porttia, joka on voimakkaammin valvottu ja lukittu. app: api-gateway Olen nähnyt tapauksia, joissa verkkopolitiikat estävät sivuliikkeen siirtymisen säiliön pakenemisen haavoittuvuuden jälkeen. Hyökkääjä sai pod-yhteyden, mutta ei päässyt mihinkään arvokkaisiin palveluihin, koska verkkopolitiikat estävät liikennettä. Rajoittamalla, mitkä palvelut voivat tavoittaa backendisi, varmistat, että kaikki ulkoiset liikennevirrat kulkevat kuorman tasapainottajan kautta, jossa se on terveystarkastusten, hinnan rajoittamisen ja havaittavuuden alainen. Sisäiset palvelupuhelut saattavat ohittaa kuorman tasapainottajan tehokkuuden vuoksi, mutta niihin sovelletaan edelleen verkkopolitiikkoja ja palvelun verkon valvontaa, jos käytät Istiaa tai vastaavaa. 6.2 IAM Controls: vähiten etuoikeutettu Verkkopolitiikat käsittelevät verkkotason käyttöoikeuksia, mutta IAM hallitsee, mitä todennetut palvelut voivat tehdä. Konfiguroin jokaisen mikrosivuston omalla Kubernetes-palvelutilillä, joka on kartoitettu tiettyyn GCP-palvelutiliin Workload Identity -palvelun kautta. Laskutuspalvelu tarvitsee pääsyn Cloud SQL:ään tapahtumatietueisiin ja Pub/Sub -palveluun maksutapahtumien julkaisemiseen, mutta ei mitään muuta. Tämä vähiten etuoikeutta koskeva periaate on pelastanut minut useita kertoja. Eräässä tapauksessa riippuvuuden haavoittuvuus mahdollisti mielivaltaisen koodin suorittamisen ilmoituspalvelussa. Koska palvelun IAM-oikeudet oli tiukasti rajoitettu lähettämään vain sähköposteja SendGridin kautta, hyökkääjä ei voinut käyttää asiakkaan maksutietoja, ei voinut muuttaa infrastruktuuria, ei voinut edes luetella, mitä muita palveluja oli olemassa. Kun yhdistetään älykkään kuorman tasapainottamiseen ja terveystarkastuksiin, IAM-ohjaimet varmistavat, että vaikka vaarantunut pod läpäisee terveystarkastukset ja saa liikennettä, vahinko, jota se voi tehdä, on minimoitu. 7. Tuotantoskenaario: Todellisen epäonnistumisen käsittely Teoria on tyydyttävä, mutta tärkeää on, miten tämä arkkitehtuuri toimii, kun asiat menevät pieleen. Tässä on skenaario, jonka olen kokenut, nimien muuttuessa: Käytät uutta laskutuspalvelun versiota v2.1.4, joka sisältää optimoinnin erän käsittelyyn. Muutos näyttää hyvältä näyttämöllä. Käytät sitä kanariina 10 prosenttiin tuotantoliikenteestä. Muutamassa minuutissa P95: n viive pyyntöihin, jotka iskevät Canary Podiin, hyppää 200 ms: stä 3 sekuntiin. Virhetaso nousee 0,1%: sta 2%. Vanhassa arkkitehtuurissa tämä tarkoittaisi, että 10 prosentilla käyttäjistäsi on kauhea kokemus, ja kilpailisit rullaamaan takaisin manuaalisesti, kun tukitiimisi kenttiä vihaisia lippuja. Sen sijaan tässä on, mitä älykkään kuormituksen tasapainottamisen kanssa tapahtuu: Canary podin valmiustesti alkaa epäonnistua, koska olet määrittänyt sen tarkistamaan paitsi "onko prosessi elossa", mutta "viimeaikaiset pyynnöt ovat onnistuneesti suorittaneet." Kolmen peräkkäisen epäonnistumisen jälkeen Kubernetes merkitsee podin valmiiksi. GCP-kuormituksen tasapainotin lopettaa välittömästi uuden liikenteen reitityksen siihen, vaikka pod on edelleen käynnissä. Pilvipalvelu havaitsee mallin – terveystarkastukset epäonnistuvat, viive on eristetty v2.1.4:een. Hälytys syttyy Slack-kanavalle. Automaattinen palautuspolitiikkasi käynnistyy, koska kanari ylitti epäonnistumisen kynnysarvot. Kahden minuutin kuluessa alkuperäisestä käyttöönotosta kanari poistetaan ja palaat täysin v2.1.3:een. Kun he tarkastelevat Cloud Tracen jälkiä, he huomaavat, että optimoinnissa on otettu käyttöön tietokantakysely, joka lukitsee taulukot erän aikana, estää vuorovaikutteiset pyynnöt. Tämä on älykkään kuormituksen tasapainottamisen lupaus - ei se, että järjestelmät eivät koskaan epäonnistu, vaan että ne epäonnistuvat hienosti, sisältävät räjähdyksen säteen ja tarjoavat tarvittavan näkyvyyden ongelmien ratkaisemiseksi ilman draamaa. 8. Yleiset ansoja ja parhaita käytäntöjä Jopa kuvatulla arkkitehtuurilla on epäonnistumistapoja, joihin olen törmännyt, jotka kannattaa nimenomaisesti soittaa. Yleisin virhe, jonka näen, on, että joukkueet toteuttavat terveys- ja valmiustutkimuksia, jotka tarkistavat vääriä asioita. Testi saattaa tarkistaa, että Flask vastaa, mutta ei sitä, onko tietokannan yhteyspohja tyhjentynyt. Se voi palauttaa 200 OK, kun taustakuvat ovat tukossa. Tehokkaat tutkimukset tarkistavat, voiko palvelu todella täyttää tarkoituksensa, ei vain sitä, onko prosessi käynnissä. Erittäin aggressiivinen tarkistus (joka sekunti) voi ylittää sovelluksesi koelaukaisulla, varsinkin jos terveystarkastus itsessään on kallista. Mutta hyvin konservatiivinen tarkistus (joka 30 sekunti) tarkoittaa, että epäonnistuneen podin havaitseminen ja sen poistaminen kierrosta voi kestää yli minuutin. Olen havainnut, että 5-10 sekunnin välein useimmilla palveluilla on hyvä tasapaino, mutta sinun on mitattava omassa ympäristössäsi. Epäonnistunut versus epäonnistunut päätös on hienovarainen, mutta kriittinen. Kun kuorman tasapainolla on useita epäterveellisiä taustaviivoja, sen pitäisi jatkaa reititystä niihin (epäonnistunut) tai hylätä liikenne kokonaan (epäonnistunut suljettu)? Oikea vastaus riippuu palvelustasi. Laskutusjärjestelmässä mieluummin epäonnistunut - parempi palauttaa 503 ja saada asiakkaat uudelleen kuin käsittelemään maksuja väärin. Suositusmoottorille epäonnistunut avaaminen voi olla parempi - näyttää hieman pysyviä suosituksia on parempi kuin näyttää mitään. Olen aina kannattanut epäonnistumisskenaarioiden testaamista tuotannossa työkaluilla, kuten kaaostekniikalla. Varmista, että liikenne epäonnistuu sujuvasti terveille podsille. Käytä verkkopolitiikkaa simuloidaksesi latenssin tai paketin menetyksen. Injektoi vikoja kanarian käyttöönottoihisi tarkoituksellisesti tarkistaaksesi, että seuranta tarttuu niihin. Jokaisella tuotantopalvelulla, jota käytän, on säännöllisiä kaaoskokeita, koska luottamus, jota ne tarjoavat, on korvaamaton. kubectl delete pod Lopuksi kuormitustesti ei ole neuvoteltavissa. Käytä työkaluja, kuten Locust tai k6, simuloidaksesi realistisia liikennemalleja ja tarkistaaksesi, että automaattinen skaalaus reagoi asianmukaisesti, että terveystarkastukset pysyvät luotettavina kuormituksen aikana ja että suorituskykyä koskevat oletukset pysyvät. 9. Johtopäätökset ja lopulliset ajatukset Nykyaikainen SaaS backend on sekä hajautettu järjestelmä että elävä organismi - sopeutuminen, itsensä parantaminen ja skaalautuminen kysynnän mukaan. Mitä olen kuvattu tässä artikkelissa, ei ole vain teoreettinen arkkitehtuuri; se on malli, jonka olen hienostanut kymmeniä tuotantojärjestelmiä, jotka on vahvistettu tapahtumien kautta, jotka vaihtelevat pienistä häiriöistä yhtiön uhkaaviin keskeytyksiin. Todellinen oivallus, joka vei vuosia sisäistää, on, että älykäs kuormien tasapainottaminen ei ole ominaisuus, jota lisäät lopussa.Se on hyvä arkkitehtuurin kehittyvä ominaisuus: palvelut, jotka rehellisesti raportoivat niiden tilasta, infrastruktuuri, joka kunnioittaa näitä signaaleja, ja havaittavuus, joka sulkee palautetta. GKE:n, Cloud Load Balancingin ja Cloud Operationsin syvä integrointi tarkoittaa sitä, että et kytke eri työkaluja yhteen – työskentelet yhtenäisen alustan kanssa, jossa terveystarkastukset virtaavat luonnollisesti reitityspäätöksiin, missä mittarit ilmoittavat automaattisesta skaalautumisesta ja jossa epäonnistumisten räjähdysnopeus on luonnollisesti sisällytetty. Joukkueet, jotka onnistuvat tällaisten arkkitehtuurien kanssa, ovat niitä, jotka pakkomielteisesti tarkkailevat järjestelmiään tuotannossa, jotka kohtelevat jokaista tapahtumaa oppimismahdollisuutena ja jotka toistavat väsymättä liikenteenhallintastrategioitaan. Jos otat yhden asian tästä artikkelista, olkoon se seuraava: älykäs kuormien tasapainottaminen on sellaisten järjestelmien rakentamista, jotka epäonnistuvat loistavasti ja parantuvat automaattisesti, antaen sinulle hengitysalueen ratkaista ongelmia harkitusti pikemminkin kuin kauhistuttavasti. Jakamani mallit ovat taistelutestejä, mutta ne eivät ole määräyksiä. SaaS:lläsi on erilaisia rajoituksia, erilaisia epäonnistumistapoja, erilaisia liiketoiminnan vaatimuksia. Mukauta näitä käsitteitä asiayhteyteen, mittaa, mikä on tärkeää palveluillesi, ja rakenna havaittavuus, jonka avulla voit iteroida luottavaisesti. Näin kehittyt naiivisesta kuormien tasapainottamisesta aidosti älykkääseen liikenteenhallintaan – yksi tuotantotapahtuma kerrallaan.
