მაკროუტერის გამოყენება მემქეშის ჰორიზონტალურად გასადიდებლად

ნებისმიერ ენაზე მაღალი დატვირთვის პროექტების შემუშავება მოითხოვს განსაკუთრებულ მიდგომას და სპეციალური ხელსაწყოების გამოყენებას, მაგრამ როდესაც საქმე ეხება PHP-ში აპლიკაციებს, სიტუაცია შეიძლება იმდენად გამწვავდეს, რომ თქვენ უნდა განავითაროთ, მაგალითად, საკუთარი აპლიკაციის სერვერი. ამ ჩანაწერში ვისაუბრებთ ნაცნობ ტკივილზე განაწილებული სესიის შენახვაზე და მონაცემთა ქეშირებაზე memcached-ში და იმაზე, თუ როგორ გადავჭრით ეს პრობლემები ერთ „პარლატის“ პროექტში.

შემთხვევის გმირი არის PHP აპლიკაცია, რომელიც დაფუძნებულია symfony 2.3 ჩარჩოზე, რომელიც საერთოდ არ შედის განახლების ბიზნეს გეგმებში. სესიის საკმაოდ სტანდარტული შენახვის გარდა, ამ პროექტმა სრულად გამოიყენა "ყველაფრის ქეშირების" პოლიტიკა memcached-ში: მონაცემთა ბაზის და API სერვერების მოთხოვნებზე პასუხები, სხვადასხვა დროშები, საკეტები კოდის შესრულების სინქრონიზაციისთვის და მრავალი სხვა. ასეთ სიტუაციაში, მემქეშის დაშლა ფატალური ხდება აპლიკაციის მუშაობისთვის. გარდა ამისა, ქეშის დაკარგვა იწვევს სერიოზულ შედეგებს: DBMS იწყებს აფეთქებას ნაკერებზე, API სერვისები იწყებენ მოთხოვნების აკრძალვას და ა.შ. სიტუაციის სტაბილიზაციას შესაძლოა ათობით წუთი დასჭირდეს და ამ დროის განმავლობაში სერვისი საშინლად ნელი ან სრულიად მიუწვდომელი იქნება.

ჩვენ გვჭირდებოდა უზრუნველყოფა აპლიკაციის ჰორიზონტალური მასშტაბის შესაძლებლობა მცირე ძალისხმევით, ე.ი. საწყის კოდში მინიმალური ცვლილებებით და სრული ფუნქციონალური შენარჩუნებით. გააკეთეთ ქეში არა მხოლოდ წარუმატებლობისადმი მდგრადი, არამედ შეეცადეთ მინიმუმამდე დაიყვანოთ მისგან მონაცემების დაკარგვა.

რისი ბრალია თავად მემქეში?

ზოგადად, PHP-ის memcached გაფართოება მხარს უჭერს განაწილებულ მონაცემებს და სესიის შენახვას ყუთიდან. გასაღების თანმიმდევრული ჰეშირების მექანიზმი საშუალებას გაძლევთ თანაბრად მოათავსოთ მონაცემები ბევრ სერვერზე, ცალსახად მიმართოთ თითოეულ კონკრეტულ კლავიშს ჯგუფის კონკრეტულ სერვერზე, ხოლო ჩაშენებული failover ინსტრუმენტები უზრუნველყოფს ქეშირების სერვისის მაღალ ხელმისაწვდომობას (მაგრამ, სამწუხაროდ, მონაცემები არ არის).

სესიების შენახვასთან დაკავშირებით ყველაფერი ცოტათი უკეთესია: შეგიძლიათ კონფიგურაცია memcached.sess_number_of_replicas, რის შედეგადაც მონაცემები ერთდროულად რამდენიმე სერვერზე შეინახება და ერთი მემქეშის ინსტანციის წარუმატებლობის შემთხვევაში მონაცემები გადაეცემა სხვებისგან. თუმცა, თუ სერვერი ინტერნეტში დაბრუნდება მონაცემთა გარეშე (როგორც ჩვეულებრივ ხდება გადატვირთვის შემდეგ), ზოგიერთი გასაღები გადანაწილდება მის სასარგებლოდ. სინამდვილეში ეს ნიშნავს სესიის მონაცემების დაკარგვა, რადგან არ არსებობს გზა სხვა რეპლიკაზე "წასვლის" შემთხვევაში გამოტოვების შემთხვევაში.

სტანდარტული ბიბლიოთეკის ინსტრუმენტები ძირითადად მიმართულია ჰორიზონტალური სკალირება: ისინი საშუალებას გაძლევთ გაზარდოთ ქეში გიგანტურ ზომებამდე და უზრუნველყოთ მასზე წვდომა სხვადასხვა სერვერზე განთავსებული კოდიდან. თუმცა, ჩვენს სიტუაციაში, შენახული მონაცემების მოცულობა არ აღემატება რამდენიმე გიგაბაიტს და ერთი ან ორი კვანძის შესრულება სავსებით საკმარისია. შესაბამისად, ერთადერთი სასარგებლო სტანდარტული ხელსაწყოები შეიძლება იყოს მემქეშის ხელმისაწვდომობის უზრუნველსაყოფად, მინიმუმ ერთი ქეში ინსტანციის სამუშაო მდგომარეობაში შენარჩუნებისას. თუმცა ამ შესაძლებლობით სარგებლობაც კი ვერ მოხერხდა... აქ უნდა გავიხსენოთ პროექტში გამოყენებული ფრეიმერის სიძველე, რის გამოც შეუძლებელი გახდა აპლიკაციის სერვერების აუზთან მუშაობა. ასევე არ დავივიწყოთ სესიის მონაცემების დაკარგვა: მომხმარებელმა თვალი აარიდა მომხმარებელთა მასიური გამოსვლიდან.

იდეალურ შემთხვევაში საჭირო იყო ჩანაწერების რეპლიკაცია მემქეშირებულ და რეპლიკების გვერდის ავლით შეცდომის ან შეცდომის შემთხვევაში. დაგვეხმარა ამ სტრატეგიის განხორციელებაში მაკროუტერი.

მაკროუტერი

ეს არის memcached როუტერი, რომელიც შეიქმნა Facebook-ის მიერ მისი პრობლემების გადასაჭრელად. იგი მხარს უჭერს მემქეშირებულ ტექსტურ პროტოკოლს, რაც საშუალებას იძლევა მასშტაბური memcached ინსტალაციები გიჟური პროპორციებით. მაკროუტერის დეტალური აღწერა შეგიძლიათ იხილოთ აქ ამ განცხადებას. სხვათა შორის ფართო ფუნქციონირება მას შეუძლია გააკეთოს ის, რაც ჩვენ გვჭირდება:

• რეპლიკაციის ჩანაწერი;
• შეცდომის შემთხვევაში შეცვალეთ ჯგუფში სხვა სერვერებზე.

შეუდექით საქმეს!

მაკროუტერის კონფიგურაცია

პირდაპირ კონფიგურაციაზე გადავალ:

{
 "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"
       ]
     }
   }
 }
}

რატომ სამი აუზი? რატომ მეორდება სერვერები? მოდით გავარკვიოთ როგორ მუშაობს.

• ამ კონფიგურაციაში, mcrouter ირჩევს გზას, რომელზეც მოთხოვნა გაიგზავნება მოთხოვნის ბრძანების საფუძველზე. ბიჭი ამას ეუბნება მას OperationSelectorRoute.
• GET მოთხოვნები მიდის დამმუშავებელთან RandomRouteრომელიც შემთხვევით ირჩევს აუზს ან მარშრუტს მასივის ობიექტებს შორის children. ამ მასივის თითოეული ელემენტი თავის მხრივ არის დამმუშავებელი MissFailoverRoute, რომელიც გაივლის აუზში არსებულ თითოეულ სერვერს, სანამ არ მიიღებს პასუხს მონაცემებით, რომელიც დაუბრუნდება კლიენტს.
• თუ ექსკლუზიურად ვიყენებდით MissFailoverRoute სამი სერვერისგან შემდგარი ფონდით, მაშინ ყველა მოთხოვნა პირველად მიიღებდა პირველ მემქეშირებულ ინსტანციას, ხოლო დანარჩენები მიიღებდნენ მოთხოვნებს ნარჩენების საფუძველზე, როდესაც მონაცემები არ არის. ასეთი მიდგომა გამოიწვევს გადაჭარბებული დატვირთვა სიაში პირველ სერვერზე, ასე რომ, გადაწყდა, რომ გენერირება სამი აუზი მისამართებით სხვადასხვა თანმიმდევრობით და აერჩია ისინი შემთხვევით.
• ყველა სხვა მოთხოვნა (და ეს არის ჩანაწერი) მუშავდება გამოყენებით AllMajorityRoute. ეს დამმუშავებელი აგზავნის მოთხოვნებს აუზის ყველა სერვერზე და ელოდება პასუხებს მათგან მინიმუმ N/2 + 1-ისგან. ხმარებიდან AllSyncRoute ჩაწერის ოპერაციებისთვის უნდა მიტოვებულიყო, რადგან ეს მეთოდი მოითხოვს დადებით პასუხს ყველა სერვერები ჯგუფში - წინააღმდეგ შემთხვევაში ის დაბრუნდება SERVER_ERROR. მიუხედავად იმისა, რომ mcrouter დაამატებს მონაცემებს ხელმისაწვდომ ქეშებში, გამოძახების ფუნქცია PHP დააბრუნებს შეცდომას და გამოიმუშავებს შეტყობინებას. AllMajorityRoute არც თუ ისე მკაცრია და იძლევა საშუალებას, რომ ბლოკების ნახევარი ამოიღონ ექსპლუატაციიდან ზემოთ აღწერილი პრობლემების გარეშე.

მთავარი მინუსი ეს სქემა იმაში მდგომარეობს, რომ თუ ქეშში ნამდვილად არ არის მონაცემები, მაშინ კლიენტის ყოველი მოთხოვნისთვის N მოთხოვნა მემქეშის მიმართ რეალურად შესრულდება - ყველას სერვერები აუზში. ჩვენ შეგვიძლია შევამციროთ სერვერების რაოდენობა აუზებში, მაგალითად, ორამდე: შევიწიროთ შენახვის საიმედოობა, მივიღებთоუფრო მაღალი სიჩქარე და ნაკლები დატვირთვა მოთხოვნიდან გამოტოვებულ გასაღებებამდე.

NB: ასევე შეგიძლიათ იპოვოთ სასარგებლო ბმულები მაკროუტერის შესასწავლად დოკუმენტაცია ვიკიზე и პროექტის საკითხები (დახურულის ჩათვლით), წარმოადგენს სხვადასხვა კონფიგურაციის მთელ საწყობს.

მაკროუტერის აშენება და გაშვება

ჩვენი აპლიკაცია (და თავად memcached) მუშაობს Kubernetes-ში - შესაბამისად, იქვე მდებარეობს mcrouter. ამისთვის კონტეინერის შეკრება ჩვენ ვიყენებთ ვერფ, რომლის კონფიგურაცია ასე გამოიყურება:

NB: სტატიაში მოცემული ჩამონათვალი გამოქვეყნებულია საცავში 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: Install prerequisites
   apt:
     name: [ 'apt-transport-https', 'tzdata', 'locales' ]
     update_cache: yes
 - name: Add mcrouter APT key
   apt_key:
     url: https://facebook.github.io/mcrouter/debrepo/xenial/PUBLIC.KEY
 - name: Add mcrouter Repo
   apt_repository:
     repo: deb https://facebook.github.io/mcrouter/debrepo/xenial xenial contrib
     filename: mcrouter
     update_cache: yes
 - name: Set timezone
   timezone:
     name: "Europe/Moscow"
 - name: Ensure a locale exists
   locale_gen:
     name: en_US.UTF-8
     state: present
 install:
 - name: Install mcrouter
   apt:
     name: [ 'mcrouter' ]

(werf.yaml)

... და დახაზეთ იგი ჩაფხუტის სქემა. საინტერესო ის არის, რომ არსებობს მხოლოდ კონფიგურაციის გენერატორი, რომელიც ეფუძნება რეპლიკების რაოდენობას (თუ ვინმეს გაქვთ უფრო ლაკონური და ელეგანტური ვარიანტი, გააზიარეთ კომენტარებში):

{{- $count := (pluck .Values.global.env .Values.memcached.replicas | first | default .Values.memcached.replicas._default | int) -}}
{{- $pools := dict -}}
{{- $servers := list -}}
{{- /* Заполняем  массив двумя копиями серверов: "0 1 2 0 1 2" */ -}}
{{- range until 2 -}}
 {{- range $i, $_ := until $count -}}
   {{- $servers = append $servers (printf "mc-%d.mc:11211" $i) -}}
 {{- end -}}
{{- end -}}
{{- /* Смещаясь по массиву, получаем N срезов: "[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|pool%02d" $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)

ჩვენ მას ვხსნით სატესტო გარემოში და ვამოწმებთ:

# 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 >

შეცდომის ტექსტის ძიებამ შედეგი არ მოიტანა, მაგრამ მოთხოვნამ ”მიკროუტერი php„წინა პლანზე იყო პროექტის უძველესი გადაუჭრელი პრობლემა - მხარდაჭერის ნაკლებობა მემქეშირებული ორობითი პროტოკოლი.

NB: ASCII პროტოკოლი memcached-ში უფრო ნელია, ვიდრე ორობითი და გასაღების თანმიმდევრული ჰეშირების სტანდარტული საშუალებები მუშაობს მხოლოდ ორობით პროტოკოლთან. მაგრამ ეს არ ქმნის პრობლემებს კონკრეტული შემთხვევისთვის.

ხრიკი ჩანთაშია: საკმარისია გადახვიდეთ ASCII პროტოკოლზე და ყველაფერი იმუშავებს.... თუმცა, ამ შემთხვევაში, პასუხების ძიების ჩვევა დოკუმენტაცია php.net-ზე სასტიკი ხუმრობა ითამაშა. თქვენ ვერ იპოვით სწორ პასუხს იქ... თუ, რა თქმა უნდა, არ გადაახვიეთ ბოლომდე, სადაც არის განყოფილება "მომხმარებლის მიერ შეტანილი შენიშვნები" ერთგული იქნება და უსამართლო პასუხი.

დიახ, სწორი ვარიანტის სახელია memcached.sess_binary_protocol. ის უნდა იყოს გამორთული, რის შემდეგაც სესიები დაიწყებს მუშაობას. რჩება მხოლოდ კონტეინერის mcrouter-ით ჩასმა პოდში PHP-ით!

დასკვნა

ამრიგად, მხოლოდ ინფრასტრუქტურული ცვლილებებით ჩვენ შევძელით პრობლემის გადაჭრა: მემქეშირებული შეცდომების ტოლერანტობის საკითხი მოგვარებულია და გაიზარდა ქეში შენახვის საიმედოობა. აპლიკაციისთვის აშკარა უპირატესობების გარდა, ამან მანევრირების ადგილი მისცა პლატფორმაზე მუშაობისას: როდესაც ყველა კომპონენტს აქვს რეზერვი, ადმინისტრატორის ცხოვრება მნიშვნელოვნად გამარტივებულია. დიახ, ამ მეთოდსაც აქვს თავისი ნაკლოვანებები, შეიძლება „ყავარჯენს“ ჰგავდეს, მაგრამ თუ ის დაზოგავს ფულს, დამარხავს პრობლემას და არ იწვევს ახალს - რატომაც არა?

PS

ასევე წაიკითხეთ ჩვენს ბლოგზე:

• "ივარჯიშეთ dapp-ით" (მაგალითად სიმფონი-დემო გამოყენებით): ნაწილი 1 (მარტივი აპლიკაციების შექმნა) и ნაწილი 2 (დოკერის სურათების განთავსება Kubernetes-ზე Helm-ის გამოყენებით);
• «Kubernetes-თან ცხოვრებიდან: როგორ არ ემხრობოდა HTTP სერვერი ესპანელებს".

წყარო: www.habr.com