Lynes Trust Center

Vår molninfrastruktur utnyttjar skalbarhet, flernivåredundans och felalternativ över Amazon Web Services i Stockholmsregionen i Sverige för att minska latens, bibehålla tillförlitlighet och skalbarhet. AWS-datacenter har designats och optimerats för att hantera verksamhetskritiska applikationer, och har flera nivåer av redundans inbyggda.

Lynes Infrastruktur är byggd på ett sätt som i ett katastrofläge möjliggör att hela tjänsten på relativt kort tid kan sättas upp från grunden i nya datacenter.

Strukturellt är lynes applikation baserad på en avancerad arkitektur med hundratals så kallade mikrotjänster (eng. micro services). Varje sådan tjänstetyp är tillståndslös, vilket möjliggör att tjänsten har flera kopior som snurrar parallellt. Detta ger en stabil form av redundans som innebär att om en kopia kraschar finns det ersättare som kan ta över under tiden som den kraschade kopian automatiskt startas upp på nytt. En annan konsekvens av denna arkitektur är att den kraschade tjänsten bara påverkar en liten del av applikationen som helhet, oftast en viss funktion, medan allt annat fungerar precis som vanligt. Effekten av en sådan enskild tjänstekrasch blir alltså att endast ett fåtal slutanvändare drabbas av en knappt märkbar temporär störning på en viss funktion.

Vissa kritiska tjänstetyper har inbyggd autoskalning, vilket innebär att antal kopior automatiskt anpassas efter befintlig last, med en garanterad miniminivå då lasten är som lägst. Detta ger en trygghet ifall lasten av någon anledning skulle öka på ett oväntat sätt.

Det finns två oberoende dedikerade fiberanslutningar till varje mobiloperatör som går via en underleverantör som driftar Session Border Controllers på två olika fysiska platser (geografisk redundans). Detta innebär att vi har redundanta anslutningar till alla mobiloperatörer.

Operatörsanslutningarna arbetar med Round-Robin teknik vilket innebär att ca 50% av samtalen automatiskt går via den ena anslutningen och resterande på den andra anslutningen. Dessutom är båda anslutningarna alltid skalade på ett sådant sätt att om den ena går ner så kan den andra ta 100% av samtalen.

Vi söker ständigt efter sätt att förbättra produkt- och plattformsprestanda genom att övervaka nyckel-prestandamätare, såsom CPU, systembelastning, minnesanvändning, databasbelastning, ljudkvalitetsnivå (genomsnittlig MOS), osv.

För vidareutveckling av Lynes plattform används fyra olika tjänstemiljöer. Utöver driftmiljön som används av slutanvändare, finns även två så kallade Staging miljöer, som används för testning och verifiering av nya funktioner och ändringar. Varje utvecklare har också en egen utvecklingsmiljö.

Innan någon form av ändring av applikation går live på driftmiljön har ändringen testats och kvalitetssäkrats i staging-miljöerna. För testning och verifiering används både automatiska enhets- och systemtester kompletterat med manuella tester.

Innan kod går vidare från en utvecklingsmiljö till staging-miljöerna måste den granskas och godkännas i en granskningsprocess av minst två olika utvecklare. Utöver den rent funktionella granskningen ingår det i processen att utvärdera ändringen utifrån ett skalbarhetsperspektiv.

De flesta tjänstetyper kan uppgraderas i full drift och helt obemärkt för slutanvändaren. Vad det gäller uppgraderingar som berör ändringar i appens användargränssnitt så kan det göras med versionshantering, vilket möjliggör en stegvis övergång till en ny version. På detta vis kan den nya versionen verifieras och kvalitetssäkras av lynes internt innan den “skjuts ut” på alla slutanvändare.

Vad det gäller telefoni-servrarna uppgraderas dessa genom att nya instanser som kör den nya koden startas upp, medan de gamla instanserna sätts i så kallad drain mode, och först töms på pågående samtal för att sedan stängas ner.

Systemet övervakas kontinuerligt med automatlarm för avvikelser över specifika tröskelvärden gällande t.ex. resursförbrukning av CPU, minne, bandbredd, disk, etc. Larmen är nivåindelade för att underlätta uppföljning och bearbetning.

Lynes har året om teknisk personal i beredskap för eventuella incidenter. Automatiska larm av kritisk nivå triggar samtal till jourtelefoner som ligger utanför växeln. Om larmet går finns det etablerade rutiner för felsökning och eskalering.

Internt sker regelbundna genomgångar av rutiner och processer. Det hålls också oförvarnade “brandövningar”.

Efter varje form av incident görs en gedigen analys av vad som hänt, och hur vi kan undvika att det händer igen. Kortsiktiga åtgärder implementeras och driftsätts direkt, medan mer långsiktiga åtgärder planeras in i prioritetsordning. Även eventuella processförbättringar diskuteras och implementeras.

I grunden används WebRTC för app-samtal och konferenser, vilket innebär tillhörande kryptering av ljudströmmar från klient till server och från server till klient. Signaleringen använder standard TLS (minst v1.2 och v1.3 där det är tillgängligt). För media används SRTP med DTLS för nyckelhantering.

Alla samtal från app är alltså krypterade från klient till server (och från server till mottagande klient för internsamtal), men avkrypteras i ett mellansteg av mottagande server för att möjliggöra inspelning, transcoding, etc.

Chattmeddelanden är krypterade ”in transit” och ”at rest”, vilket innebär att de skickas i krypterad form och att de lagras i krypterad form. Detta är ej att förväxla med E2EE (end-to-end-encryption) eftersom data efter transport avkrypteras av mottagande server, för att sedan krypteras på nytt för lagring. Användning av chatt för lagring av lösenord, etc, rekommenderas ej. Anledningen till att chattmeddelanden avkrypteras av server i ett mellansteg är för att möjliggöra notiser, sökning, integrationer med andra system, etc.

Data från anslutna konton från externa leverantörer såsom Office 365 och G Suite mellanlagras ej i databas av appen utan hämtas i realtid via den externa leverantörens API:er. Redan hämtad data kan cachas i den aktuella sessionen på användarens klient för snabbare visning. Utloggning rensar all data lagrad i cache.

Funktion finns för att kunna PIN-kodsskydda access till att besvara enkäter som extra säkerhet. Det går också att kräva autentisering med Bank-ID för enkätsvar. Användarbaserad tillgång till enkätresultat i lynes-appen kan styras med det inbyggda rollbaserade behörighetssystemet.

JWT används som teknik för åtkomstkontroll. Alla RPCer skickar med en JWT-token för kontroll.

All innehållsdata såsom chattmeddelanden, ljudfiler och enkäter lagras i krypterad form.

Backuper tas av innehåll i samtliga databaser dagligen, och lagras på AWS i Sverige. Backuper lagras i 30 dagar och tas sedan bort.

Om du har några frågor är du välkommen att kontakta oss på:

lynes Technologies Sweden AB

Drottning Kristinas Esplanad 12

170 67 Solna

Email: hello(a)lynes.io