Etablere Redis i infrastruktur som backing for IDistributedCache

[elsand]

I forbindelse med eksterne oppslag mot bl.a. ressursregisteret, skal det etableres Redis gjennom Azure Cache for Redis.

Alle steder der IDistributedCache benyttes, skal Redis være backing.

### Tasks
- [x] Legge til Redis i IAC
- [x] Generere connection strings som legges i keyvault og settings
- [x] Bruke StackExchange.Redis som backing for IDistributedCache

[arealmaas]

Satt opp redis-resource i Azure nå. Skal teste managed identity som er måte å autentisere mot Redis. Ser ut som det er en av de få tjenestene som ikke tar imot credentials fra Azure Credentials, men heller krever en principalId https://github.com/Azure/Microsoft.Azure.StackExchangeRedis/issues/17

... men jobbes med, og ser ut til at vi må sende med token credentials til å begynne med her.

Edit: ser ut til å være en pull request som forhåpentligvis kommer inn snart så vi slipper workaround https://github.com/Azure/Microsoft.Azure.StackExchangeRedis/pull/43

[arealmaas]

Tok en sync med @oskogstad om bruk av in-memory og Redis, og om vi skal bruke begge deler i samme miljø. Ref comment: https://github.com/digdir/dialogporten/pull/527/files#r1516954307

... 
Tror ideen var å ha begge?
Først sjekkes in-memory, så Redis, så hente fra whatever remote source

Vi snakket om at logikken som skal til for å bruke både in-memory og Redis kan bli ganske kompleks. Særlig når man må ta høyde for expiration med mer. Spørsmålet er om ms gained ved å bruke begge outweigher vanskeligheter med debugging, vanskeligere å skalere tjenesten (mindre kontroll på minnebruk) og implementasjonskompleksitet.

Vi kan potensielt diskutere dette i refinement? Vi eventuelt lage en ny task på å forbedre cachen, men inntil videre løse det ved å kun bruke den ene eller den andre. Altså, at vi enten bruker in-memory eller Redis.

[elsand]

Tenker vi tar en runde på dette i refinement. Se også #40 som diskuterer ett av behovene vi har for dette. Et annet behov jeg ser vi vil kunne få er å ha en oversikt over distinkte ressurser som alle dialogene tilhørende en gitt party refererer, som vil være viktig informasjon å kunne sende over til autorisasjonslkomponenten ifm tilgangskontroll på søke-API-et for å redusere mengden jobb den må utføre. Dette er altså informasjon vi vil ha behov for ifm autorisasjon på svært sentrale endepunkter som vil være under tung last.

En Redis-cache som holdes varm uavhengig av innkommende requests løser brorparten av problemet, og unngår at requests fra brukere blokkeres eller fører til cache stampede ved expiration og ny deploy/nye replikas, så vi tenker vi begynner der. ("Holde varm"-funksjonaliteten må dog være noe vi ikke gjør oss avhengig av, det må fremdeles være en standard read-through slik at requests for ressurser som av en eller annen grunn ikke finnes i cache ikke feiler).

Tanken bak en flernivås cache er at det å skulle ta på seg en 3-6(?) ms request overhead i alle disse tilfellene nok vil kunne være uhensiktsmessig dyrt (i flere forstander) og dermed noe vi må kunne unngå på sikt. Å ha en minnebasert "nivå 1" cache vil begrense trafikken fra Redis til noe kontrollerbart per replika (uavhengig av antall tråder). Jeg er ikke spesielt bekymret for minnebruken her, jeg ser ikke for meg at vi blir noen gang å bikke mer enn et knippe MB per replika. Håndtering av TTL-verdier på tvers av cahenivåene er hakket mer komplisert, men håndterbart. Jeg tror det skal være mulig å lage en custom IDistributedCache-implementasjon som wrapper både Redis og en minnebasert-cache).

[elsand]

https://github.com/ZiggyCreatures/FusionCache ser interessant ut, og adresserer mange (alle?) av de problemstillingene som nevnes over og i #40 . Er kanskje noe vi bør vurdere?

[arealmaas]

Måtte reverte til å bruke connection strings rett og slett fordi vi brukte feil Redis-bibliotek ( https://github.com/Azure/Microsoft.Azure.StackExchangeRedis). Managed Identity er ikke støttet i Microsoft.Extensions.Caching.StackExchangeRedis

Ref denne her: https://github.com/dotnet/aspnetcore/issues/54414#issuecomment-1989156098

Ser ut til at det finnes en løsning, men spørs om det er verdt å implementere eller om vi skal holde på connection stringen som løsning for nå.