Vi använder mcrouter för horisontell skalning av memcached

Utveckling av högbelastade projekt på vilket språk som helst kräver en speciell metodik och användning av speciella verktyg, men när det handlar om applikationer i PHP kan situationen förvärras så mycket att man exempelvis måste utveckla en egen applikationsserver. I denna anteckning kommer vi att prata om en bekant smärta med distribuerad lagring av sessioner och cachning av data i memcached samt hur vi löste dessa problem i ett "projet" av vård.

Huvudpersonen är en PHP-applikation baserad på ramverket Symfony 2.3, vilket inte ingår i företagsplanerna att uppdatera. Förutom den helt standardmässiga sessionlagringen användes i detta projekt politiken "cachning av allt" i memcached: svar på frågor till databasen och API-servrar, olika flaggor, lås för synkronisering av kodens utförande och mycket mer. I en sådan situation blir ett fel i memcached fatalt för applikationens funktion. Dessutom leder förlust av cache till allvarliga konsekvenser: databasen börjar braka, API-tjänsterna blockerar förfrågningar, etc. Stabilisering av situationen kan ta många minuter, och under denna tid kommer tjänsten att vara extremt seg eller till och med bli otillgänglig.

Vi behövde säkerställa möjligheten till horisontell skalning av applikationen med minimala insatser, dvs. med minimiändringar i källkoden och fullständig bevarande av funktionaliteten. Att göra cachen inte bara felfri, utan också att minimera förluster av data från den.

Vad är fel med memcached själv?

Generellt sett stödjer memcached-tillägget för PHP "ur lådan" distribuerad lagring av data och sessioner. Mekanismen för konsekvent hashning av nycklar gör det möjligt att jämnt fördela data över många servrar genom att entydigt adressera varje specifik nyckel till en viss server i gruppen, och de inbyggda failover-mekanismerna säkerställer hög tillgänglighet för cache-tjänsten (men tyvärr, inte för datan).

Sessionlagring fungerar något bättre: det går att ställa in memcached.sess_number_of_replicas, vilket innebär att data kommer att sparas på flera servrar, och i händelse av att en instans av memcached går ner kommer datan att hämtas från andra. Men om servern kommer tillbaka utan data (som ofta händer efter en omstart), kommer en del nycklar att omfördelas till dess fördel. Faktum är att detta skulle innebära förlust av sessionsdata, eftersom det inte finns någon möjlighet att "gå" till en annan replik vid en miss.

De standardverktyg som biblioteket erbjuder är främst inriktade på horisontell skalerbarhet: de tillåter att öka cacheminnet till gigantiska storlekar och ge åtkomst till det från kod som körs på olika servrar. Men i vår situation överstiger den mängd data som lagras inte några få gigabyte, och prestandan hos en eller två noder är mer än tillräcklig. Därmed skulle den enda användbara funktionen vara att säkerställa tillgång till memcached så länge minst en instans av cacheminnet är i drift. Även denna möjlighet kunde man dock inte utnyttja… Här bör man påminna om ramverkets ålder som användes i projektet, vilket gjorde det omöjligt att få applikationen att fungera med en serverpool. Vi får heller inte glömma förlusten av sessionsdata: den massiva utloggningen av användare fick kunden att bli nervös.

I idealfallet krävdes replikering av poster i memcached och att kringgå repliker vid en miss eller ett fel. För att genomföra denna strategi hjälpte oss mcrouter.

mcrouter

Detta är en router för memcached, utvecklad av Facebook för att lösa deras problem. Den stöder det textbaserade protokollet för memcached, som möjliggör att skala memcached-installationer till orimliga storlekar. En detaljerad beskrivning av mcrouter kan hittas i denna tillkännagivande. Förutom andra omfattande funktionaliteter kan den göra det vi behöver:

• replikera poster;
• falla tillbaka på andra servrar i gruppen vid uppkomst av fel.

Låt oss sätta igång!

Konfiguration av mcrouter

Jag går direkt till konfigurationen:

{
 "pools": {
   "pool00": {
     "servers": [
       "mc-0.mc:11211",
       "mc-1.mc:11211",
       "mc-2.mc:11211"
   },
   "pool01": {
     "servers": [
       "mc-1.mc:11211",
       "mc-2.mc:11211",
       "mc-0.mc:11211"
   },
   "pool02": {
     "servers": [
       "mc-2.mc:11211",
       "mc-0.mc:11211",
       "mc-1.mc:11211"
 },
 "route": {
   "type": "OperationSelectorRoute",
   "default_policy": "AllMajorityRoute|Pool|pool00",
   "operation_policies": {
     "get": {
       "type": "RandomRoute",
       "children": [
         "MissFailoverRoute|Pool|pool02",
         "MissFailoverRoute|Pool|pool00",
         "MissFailoverRoute|Pool|pool01"
       ]
     }
   }
 }
}

Varför tre pooler? Varför upprepas servrar? Låt oss titta på hur det fungerar.

• I denna konfiguration väljer mcrouter vägen för att skicka begäran baserat på begärningens typ. Det informeras av typen OperationSelectorRoute.
• GET-begärningar går till hanteraren RandomRoute, som slumpmässigt väljer en pool eller väg bland objekten i arrayen children. Varje element i denna array är i sin tur en hanterare MissFailoverRoute, som skannar var och en av servrarna i poolen tills den får ett svar med data, vilket kommer att returneras till klienten.
• Om vi hade använt enbart MissFailoverRoute en pool med tre servrar skulle alla begärningar först gå till den första instansen av memcached, medan de andra skulle mottaga begärningar endast om datan saknas. Denna metod skulle ha lett till en överbelastning av den första servern i listan, vilket är anledningen till att vi beslutade att skapa tre pooler med adresser i olika sekvenser och välja dem slumpmässigt.
• Alla andra begärningar (det vill säga skrivningar) hanteras med hjälp av AllMajorityRoute. Denna hanterare skickar begärningar till alla servrar i poolen och väntar på svar från minst N/2 + 1 av dem. Vi var tvungna att avstå från att använda AllSyncRoute för skrivoperationer eftersom denna metod kräver ett positivt svar från alla servergrupperna — annars returnerar den SERVER_ERROR. Även om mcrouter då lägger datan i tillgängliga cacheminnen, kommer den anropande PHP-funktionen att returnera ett fel och generera ett meddelande. AllMajorityRoute är inte lika strikt och tillåter att upp till hälften av noderna sätts ur drift utan ovanstående problem.

Den största nackdelen med detta system är att om det verkligen inte finns någon data i cachen, kommer varje begäran från klienten praktiskt taget att utföra N begärningar till memcached — till med allt servrarna i poolen. Vi kan minska antalet servrar i poolerna, till exempel till två: genom att offra lagringspålitlighet, får vi en...bästa resultatet (subjektiv åsikt).högre hastighet och mindre belastning från förfrågningar till saknade nycklar.

NB: Nyttiga länkar för att studera mcrouter kan också vara dokumentationen i wiki och projektets issues (inklusive stängda), som representerar en verklig guldgruva av olika konfigurationer.

Bygga och köra mcrouter

Applikationen (och memcached själv) körs i Kubernetes — därför är mcrouter också där. För att bygga containern använder vi werf, konfigurationen kommer att se ut som följer:

NB: Listorna som ges i artikeln är publicerade i repositoryt flant/mcrouter.

configVersion: 1
project: mcrouter
deploy:
 namespace: '[[ env ]]'
 helmRelease: '[[ project ]]-[[ env ]]'
---
image: mcrouter
from: ubuntu:16.04
mount:
- from: tmp_dir
 to: /var/lib/apt/lists
- from: build_dir
 to: /var/cache/apt
ansible:
 beforeInstall:
 - name: Installera förutsättningar
   apt:
     name: [ 'apt-transport-https', 'tzdata', 'locales' ]
     update_cache: yes
 - name: Lägg till mcrouter APT-nyckel
   apt_key:
     url: https://facebook.github.io/mcrouter/debrepo/xenial/PUBLIC.KEY
 - name: Lägg till mcrouter Repo
   apt_repository:
     repo: deb https://facebook.github.io/mcrouter/debrepo/xenial xenial contrib
     filename: mcrouter
     update_cache: yes
 - name: Ställ in tidszon
   timezone:
     name: "Europe/Moscow"
 - name: Se till att en lokalversion finns
   locale_gen:
     name: en_US.UTF-8
     state: present
 install:
 - name: Installera mcrouter
   apt:
     name: [ 'mcrouter' ]

(werf.yaml)

… och skriver ner Helm-chart. Intressant — här är endast konfiggeneratorn baserat på antal repliker (om någon har ett mer kortfattat och elegant alternativ — dela med er i kommentarerna):

{{- $count := (pluck .Values.global.env .Values.memcached.replicas | first | default .Values.memcached.replicas._default | int) -}}
{{- $pools := dict -}}
{{- $servers := list -}}
{{- /* Fyller matrisen med två kopior av servrar: "0 1 2 0 1 2" */ -}}
{{- range until 2 -}}
 {{- range $i, $_ := until $count -}}
 {{- $servers = append $servers (printf "mc-%d.mc:11211" $i) -}}
 {{- end -}}
{{- end -}}
{{- /* Genom att vrida på matrisen får vi N skivor: "[0 1 2] [1 2 0] [2 0 1]" */ -}}
{{- range $i, $_ := until $count -}}
 {{- $pool := dict "servers" (slice $servers $i (add $i $count)) -}}
 {{- $_ := set $pools (printf "MissFailoverRoute|Pool|poold" $i) $pool -}}
{{- end -}}
---
apiVersion: v1
kind: ConfigMap
metadata:
 name: mcrouter
data:
 config.json: |
 {
 "pools": {{- $pools | toJson | replace "MissFailoverRoute|Pool|" "" -}},
 "route": {
 "type": "OperationSelectorRoute",
 "default_policy": "AllMajorityRoute|Pool|pool00",
 "operation_policies": {
 "get": {
 "type": "RandomRoute",
 "children": {{- keys $pools | toJson }}
 }
 }
 }
 }

(10-mcrouter.yaml)

Rullas ut i testmiljö och kontrolleras:

# php -a
Interactive mode enabled

php > # Проверяем запись и чтение
php > $m = new Memcached();
php > $m->addServer('mcrouter', 11211);
php > var_dump($m->set('test', 'value'));
bool(true)
php > var_dump($m->get('test'));
string(5) "value"
php > # Работает! Тестируем работу сессий:
php > ini_set('session.save_handler', 'memcached');
php > ini_set('session.save_path', 'mcrouter:11211');
php > var_dump(session_start());
PHP Warning:  Uncaught Error: Failed to create session ID: memcached (path: mcrouter:11211) in php shell code:1
Stack trace:
#0 php shell code(1): session_start()
#1 {main}
  thrown in php shell code on line 1
php > # Не заводится… Попробуем задать session_id:
php > session_id("zzz");
php > var_dump(session_start());
PHP Warning:  session_start(): Cannot send session cookie - headers already sent by (output started at php shell code:1) in php shell code on line 1
PHP Warning:  session_start(): Failed to write session lock: UNKNOWN READ FAILURE in php shell code on line 1
PHP Warning:  session_start(): Failed to write session lock: UNKNOWN READ FAILURE in php shell code on line 1
PHP Warning:  session_start(): Failed to write session lock: UNKNOWN READ FAILURE in php shell code on line 1
PHP Warning:  session_start(): Failed to write session lock: UNKNOWN READ FAILURE in php shell code on line 1
PHP Warning:  session_start(): Failed to write session lock: UNKNOWN READ FAILURE in php shell code on line 1
PHP Warning:  session_start(): Failed to write session lock: UNKNOWN READ FAILURE in php shell code on line 1
PHP Warning:  session_start(): Unable to clear session lock record in php shell code on line 1
PHP Warning:  session_start(): Failed to read session data: memcached (path: mcrouter:11211) in php shell code on line 1
bool(false)
php >

Sökning på felmeddelandet gav inget resultat, men med förfrågan «mcrouter php» fanns den äldsta öppna frågan in kärnan av projektet — bristen på stöd för memcached:s binära protokoll.

NB: ASCII-protokol i memcached är långsammare än det binära, och de inbyggda verktygen för konsekvent hashning av nycklar fungerar endast med det binära protokollet. Men det skapar inga problem för det specifika fallet.

Saken är biff: det är bara att växla till ASCII-protokollet så fungerar allt igen.... Men i detta fall spelade vanan att söka svar i dokumentationen på php.net oss ett elakt spratt. Du kommer inte att hitta det rätta svaret där... om du inte bläddrar till slutet, där i sektionen «User contributed notes» finns det ett korrekt och orättvist nedröstat svar.

Ja, det rätta namnet på alternativet är memcached.sess_binary_protocol. Det måste stängas av, efter vilket sessionerna börjar fungera. Det återstår bara att placera containern med mcrouter i podden med PHP!

Slutsats

Således lyckades vi, genom enbart infrastrukturella förändringar, lösa den ställda uppgiften: frågan om failover i memcached är löst, pålitligheten av cachelagring har ökat. Förutom de uppenbara fördelarna för applikationen har det gett utrymme för manövrering vid arbetet med plattformen: när alla komponenter har reserv gör det livet lättare för administratören. Ja, denna metod har sina nackdelar, kan se ut som ett "krångligt" tillvägagångssätt, men om det sparar pengar, döljer problemet och inte orsakar nya - varför inte?

P.S.

Läs även i vår blogg:

• «Praktik med dapp» (exempelvis symfony-demo): del 1 (bygga enkla applikationer) och del 2 (distribuera Docker-bilder i Kubernetes med hjälp av Helm);
• «Från livet med Kubernetes: Hur HTTP-servern i Spanien inte gillade».

Källa: habr.com