Yksi taustajärjestelmä ei enää riittänyt laajenevalle terveys- ja ravitsemusalojen yritykselle. AI chatbot -liikenne, runsas puettavien laitteiden datan syöttö ja päivittäiset API-pyynnöt kilpailivat kaikki samoista resursseista — tehden järjestelmästä vaikeasti skaalattavan ja riskialttiin ottaa käyttöön. Uudelleenarkkitehdimme sen keskittyneiksi, itsenäisesti käyttöönotettaviksi palveluiksi, jotka on orkestroitu yhden API gatewayn taakse ja jotka toimivat AWS:ssä.
Haaste
- Yksi koodikanta hoitaa kaikki tehtävät. Yksi työnkulku sisälsi käyttäjähallinnan, AI chatbot -päätelmät, reseptit ja terveystiedon analytiikan. Piikki millä tahansa alueella heikensi koko alustaa, ja jokainen muutos tarkoitti koko järjestelmän uudelleenkäyttöönottoa.
- Erittäin erilaiset resurssiprofiilit. LLM-pohjaiset chatbot-pyynnöt ovat suoritin- ja muisti-intensiivisiä ja aaltoilevia; puettavien laitteiden datan syöttö on kirjoitusintensiivistä ja jatkuvaa; ydintason CRUD API:t ovat kevyitä ja jatkuvia. Yhden palvelimen mitoitus kaikille kolmelle tarkoitti, että joistakin työkuormista maksettiin liikaa ja muut kärsivät resurssipulasta.
- Itsenäinen skaalaus ja käyttöönotto. Tiimin piti skaalata AI-työkuormaa koskematta ydin-API:in ja julkaista muutoksia yhteen toimialueeseen vaarantamatta muita.
Yksi, turvallinen sisääntulopiste. Useista taustapalveluista huolimatta asiakkaat (mobiili, verkko, järjestelmänvalvoja) tarvitsivat yhden johdonmukaisen, todennetun rajapinnan, johon puhua – ilman, että sisäinen palvelutopologia vuotaisi ulkomaailmalle.
Ratkaisumme
Jaoimme alustan kolmeen keskittyneeseen NestJS-palveluun, jotka toimivat AWS Application Load Balancerin takana, ja pääpalvelin toimi API gatewayna ja orkestraattorina. Se hallitsee todennusta ja ydintoimialueita sekä delegioi erikoistuneen työn chatbot- ja terveysmikropalveluille todennetun RESTin kautta. Jaettu data- ja viestintäkerros pitää palvelut löyhästi kytkettyinä mutta johdonmukaisina.
Arkkitehtuuri
- Pääpalvelin (NestJS) – API gateway ja orkestraattori: todennus, käyttäjät, tavoitteet, reseptit, aikataulutus ja ilmoitukset. Kaikilla asiakkailla on yksi julkinen sisääntulopiste.
- Chatbot Microservice (NestJS) – AI-keskustelupalvelu, joka perustuu Azure OpenAIhin (GPT-4o) LangChainin/LangGraphin kautta, ja jossa on Elasticsearch-pohjainen RAG reseptien ja tiedonhakuun.
- Health Microservice (NestJS) – vastaanottaa ja yhdistää puettavien laitteiden ja manuaalisia terveystietoja (Apple Health, Health Connect) ja tarjoaa analytiikkaa.
- AWS ECS Fargate suorittaa kolmea kontitettua palvelua, joista jokaisella on oma CPU/muisti-mitoituksensa ja skaalauskäytäntönsä.
- Application Load Balancer lopettaa HTTPS-yhteydet ja reitittää liikenteen oikeaan palveluun polun perusteella.
- Jaettu datakerros – MongoDB Atlas (ensisijainen tallennustila), Redis (välimuisti/sessiot), Elasticsearch (haku), ActiveMQ (asynkroninen ilmoitusten toimitus).
Tärkeimmät ominaisuudet
1. Orkestraattorimalli. Pääpalvelin on ainoa asiakkaille altistettu palvelu. Se todentaa jokaisen pyynnön ja tekee sitten sisäisiä palvelujen välisiä kutsuja – joten taustajärjestelmän topologia pysyy yksityisenä ja asiakkaan integrointi pysyy yksinkertaisena.
2. Todennetut palvelujen väliset kutsut. Palvelujen välinen kommunikaatio tapahtuu RESTin kautta jaetun HTTP-asiakkaan avulla, ja se on suojattu palvelukohtaisilla bearer API-avaimilla:
// Pääpalvelin delegioi AI-pyynnön chatbot-mikropalvelulle const reply = await this.microserviceClient.post( this.chatbotApiKey, // palvelukohtainen bearer-avain `${this.chatbotUrl}/chat`, { user, question, sessionId, attachment }, ); |
3. Työkuormakohtainen riippumaton skaalaus. Jokainen palvelu on erillinen Fargate-tehtävämääritys omine mitoituksineen – muistiraskas chatbot-palvelu skaalautuu riippumattomasti kevyestä ydin-API:sta, joten AI-liikenteen piikit eivät koskaan nälkiinnytä päivittäisiä pyyntöjä.
4. Oikein mitoitettu AI-palvelu sisäänrakennetulla joustavuudella. Chatbot-palvelu kiertää useiden Azure OpenAI -avaimien välillä, siirtyen automaattisesti varajärjestelmään (failover) nopeusrajoitusten tai virheiden vuoksi – pitäen AI-ominaisuudet reagoivina kuormituksen alaisena.
5. Ilmoitukset asynkronisen viestinnän kautta. Koska ActiveMQ:n viivejonot erottavat aikaan perustuvat muistutukset ja kehotukset pyyntövirrasta, ilmoitusten toimitus ei koskaan estä tai hidasta ydin-API-liikennettä.
6. Toistettavat, eristetyt käyttöönotot. ECR:stä ECS:ään, jokainen palvelu toimitetaan omana Docker-kuvana. Muutos terveyspalveluun vain ottaa terveyspalvelun uudelleen käyttöön – nopeita, matalan riskin julkaisuja rullaavilla päivityksillä, jotka on terveystarkistettu.
7. Yksi johdonmukainen asiakassopimus. Mobiili (React Native) ja järjestelmänvalvojan hallintapaneeli kommunikoivat kaikki yhden kuormatasatun, HTTPS-sisääntulopisteen kanssa – sisäinen jako mikropalveluihin on niille näkymätön.
Tulokset
- Nykyään AI-chatbotien, terveystietojen ja ydin-API:en työkuormat skaalautuvat erikseen; mikään tehtävä ei voi heikentää muita.
- Jokainen palvelu otetaan käyttöön itsenäisesti, muuttaen riskialttiit koko alustan julkaisut nopeiksi, eristetyiksi päivityksiksi.
- Laskentateho on mitoitettu palvelukohtaisesti, mikä eliminoi "yksi koko sopii kaikille" -palvelimen ylivarauksen.
- Yksi turvallinen, kuormatasattu sisääntulopiste pitää asiakasintegraation yksinkertaisena samalla kun taustajärjestelmä pysyy yksityisenä ja modulaarisena.
Teknologiapino
NestJS · TypeScript · Node.js 20 · Azure OpenAI (GPT-4o) · LangChain · MongoDB Atlas · Redis · Elasticsearch · ActiveMQ · AWS ECS Fargate · Application Load Balancer · Amazon ECR · Docker
Muita blogeja
1. How We Scale Video Processing Workloads with AWS ECS
2. How We Use AWS ECR to Manage and Deploy Container Images
3. How We Use AWS EC2 for Workloads in High-Performance Video
