שימוש ב-mcrouter כדי לשנות את קנה המידה של memcached אופקית

פיתוח פרויקטים בעלי עומס גבוה בכל שפה דורש גישה מיוחדת ושימוש בכלים מיוחדים, אך כשמדובר ביישומי PHP, המצב יכול להחמיר עד כדי כך שתצטרכו לפתח, למשל, שרת יישומים משלובפוסט זה נדבר על הקושי המוכר של אחסון סשנים מבוזר ואחסון נתונים במטמון ב-memcached וכיצד פתרנו בעיות אלו בפרויקט "מחלקה" אחד.

גיבור האירוע הוא אפליקציית PHP המבוססת על framework symfony 2.3, אותה החברה אינה מתכננת לעדכן. בנוסף לאחסון הסטנדרטי למדי של סשנים, פרויקט זה ניצל באופן מלא את... מדיניות "אחסון הכל במטמון" ב-memcached: תגובות לבקשות למסד הנתונים ולשרתי ה-API, דגלים שונים, נעילות לסנכרון ביצוע קוד ועוד. במצב כזה, כשל ב-memcached הופך לקטלני עבור האפליקציה. בנוסף, אובדן המטמון מוביל לתוצאות חמורות: ה-DBMS מתחיל להיסדק בתפרים, שירותי API - בקשות חסימה וכו'. ייצוב המצב יכול לקחת עשרות דקות, ובמהלך זמן זה השירות יהיה איטי להחריד או יהפוך ללא זמין לחלוטין.

היינו צריכים לספק היכולת להגדיל את האפליקציה בצורה אופקית במאמץ מועט, כלומר עם שינויים מינימליים בקוד המקור ושמירה מלאה על הפונקציונליות. הפוך את המטמון לא רק עמיד בפני כשלים, אלא גם נסה למזער את אובדן הנתונים ממנו.

מה הבעיה עם memcached עצמו?

באופן כללי, ההרחבה memcached עבור PHP תומכת באחסון מבוזר של נתונים וסשנים ישירות מהקופסה. מנגנון הגיבוב העקבי של מפתחות מאפשר פיזור שווה של נתונים על פני שרתים רבים, תוך הפניה ייחודית של כל מפתח ספציפי לשרת ספציפי מהקבוצה, וכלי הגיבוי המובנים מבטיחים זמינות גבוהה של שירות המטמון (אך, למרבה הצער, אין נתונים).

המצב קצת יותר טוב עם אחסון סשנים: ניתן להגדיר memcached.sess_number_of_replicas, כתוצאה מכך הנתונים יישמרו במספר שרתים בו זמנית, ובמקרה של כשל של שרת memcach אחד, הנתונים יוחזרו משרתים אחרים. עם זאת, אם השרת יחזור לפעולה ללא נתונים (כפי שקורה בדרך כלל לאחר הפעלה מחדש), חלק מהמפתחות יחולקו מחדש לטובתו. למעשה, משמעות הדבר היא אובדן נתוני סשן, מכיוון שאין אפשרות "ללכת" לעותק אחר במקרה של החמצה.

כלי הספרייה הסטנדרטיים מכוונים בעיקר ל אופקי קנה מידה: הם מאפשרים לך להגדיל את המטמון לגדלים עצומים ולספק גישה אליו מקוד הממוקם בשרתים שונים. עם זאת, במצבנו, נפח הנתונים המאוחסנים אינו עולה על כמה ג'יגה-בייט, והביצועים של צומת אחד או שניים מספיקים בהחלט. לפיכך, הדבר השימושי היחיד שהכלים הסטנדרטיים יכלו לעשות הוא להבטיח את זמינות ה-memcached תוך שמירה על לפחות מופע אחד של המטמון תקין. עם זאת, לא הצלחנו לנצל אפילו הזדמנות זו... כאן עלינו לזכור את עתיקותה של המסגרת בה נעשה שימוש בפרויקט, ולכן לא ניתן היה לגרום לאפליקציה לעבוד עם מאגר שרתים. בואו לא נשכח את אובדן נתוני ההפעלה: עינו של הלקוח רטטה מהיציאה המונית של משתמשים.

באופן אידיאלי, זה היה נדרש שכפול כתיבה במטמון memcach ומעבר רפליקות במקרה של החמצה או טעות. עזרו לנו ליישם אסטרטגיה זו על ידי מקראוטר.

מקראוטר

זהו נתב memcached שפותח על ידי פייסבוק כדי לפתור את הבעיות שלהם. הוא תומך בפרוטוקול טקסט memcached, המאפשר התקנות memcached בקנה מידה לגדלים מטורפים. תיאור מפורט של mcrouter ניתן למצוא ב בהודעה זובין היתר פונקציונליות רחבה הוא יכול לעשות את מה שאנחנו צריכים:

• שכפול רשומה;
• ליצור גיבוי לשרתים אחרים בקבוצה במקרה של שגיאה.

בואו נתחיל לעבוד!

תצורת mcrouter

אני אעבור ישר לקונפיגורציה:

{
 "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 בוחר את הנתיב שאליו תישלח הבקשה בהתבסס על פקודת request. זה מה שהטיפוס אומר לו. OperationSelectorRoute.
• בקשות GET מועברות למטפל RandomRoute, אשר בוחר באופן אקראי מאגר או נתיב מבין האובייקטים במערך childrenכל אלמנט במערך זה הוא בתורו מטפל MissFailoverRoute, אשר יעבור דרך כל שרת במאגר עד שיקבל תגובה עם נתונים, אשר יוחזרו ללקוח.
• אם היינו משתמשים אך ורק MissFailoverRoute עם מאגר של שלושה שרתים, כל הבקשות יגיעו תחילה למופע הראשון במטמון, והשאר יקבלו בקשות על בסיס שיורי כאשר אין נתונים. גישה זו תוביל ל עומס יתר על השרת הראשון ברשימה, לכן הוחלט ליצור שלושה מאגרי כתובות ברצפים שונים ולבחור אותם באופן אקראי.
• כל שאר הבקשות (וזו רשומה) מעובדות באמצעות AllMajorityRouteמטפל זה שולח בקשות לכל השרתים במאגר וממתין לתגובות מלפחות N/2 + 1 מהם. משימוש AllSyncRoute עבור פעולות כתיבה היה צורך לנטוש אותה, מכיוון ששיטה זו דורשת תגובה חיובית מ כל שרתי קבוצה - אחרת זה יחזור SERVER_ERRORלמרות ש-mcrouter יעביר את הנתונים למטמונים זמינים, פונקציית ה-PHP הקוראת יחזיר שגיאה ולייצר התראה. AllMajorityRoute אינו כה קפדני ומאפשר לך להוציא משימוש עד מחצית מהיחידות ללא הבעיות שתוארו לעיל.

החיסרון העיקרי הסכימה היא שאם באמת אין נתונים במטמון, אז עבור כל בקשה מהלקוח, N בקשות ל-memcached יבוצעו בפועל - מה ש... כל שרתים במאגר. ניתן להפחית את מספר השרתים במאגרים, לדוגמה, לשניים: תוך פגיעה באמינות האחסון, נקבל bоמהירות גבוהה יותר ופחות עומס מבקשות למפתחות חסרים.

NBקישורים שימושיים ללימוד mcrouter עשויים להיות גם כן תיעוד בוויקי и בעיות בפרויקט (כולל סגורים), המייצגים אוצר בלום שלם של תצורות שונות.

בנייה והפעלת mcrouter

האפליקציה שלנו (וה-memcached עצמו) פועלת ב-Kubernetes - בהתאם לכך, גם mcrouter ממוקם שם. הרכבת מיכלים אנו משתמשים werf, שהקונפיגורציה שלו תיראה כך:

NBרשימות המופיעות במאמר מתפרסמות במאגר פלנט/מקראוטר.

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"בחזית הפרויקט עמדה הבעיה הישנה ביותר שלא נפתרה - חוסר תמיכה פרוטוקול בינארי memcached.

NBפרוטוקול ASCII ב-memcached איטי יותר מהפרוטוקול הבינארי, והאמצעים הסטנדרטיים לגיבוב עקבי של מפתחות עובדים רק עם הפרוטוקול הבינארי. אבל זה לא יוצר בעיות במקרה ספציפי.

הטריק כבר בפנים: כל מה שנותר הוא לעבור לפרוטוקול ASCII והכל יעבוד.... עם זאת, במקרה הזה, ההרגל לחפש תשובות ב תיעוד ב-php.net שיחק בדיחה אכזרית. לא תמצא שם את התשובה הנכונה... אלא אם כן, כמובן, תגללו עד הסוף, היכן שבקטע "הערות שנתרמו על ידי המשתמש" יהיה נאמן ו תשובה שלא הוגנת.

כן, השם הנכון של האפשרות הוא memcached.sess_binary_protocolיש להשבית אותו, ולאחר מכן הסשנים יתחילו לעבוד. כל שנותר הוא לשים את הקונטיינר עם mcrouter בפוד עם PHP!

מסקנה

לפיכך, הצלחנו לפתור את המשימה באמצעות שינויים בתשתית בלבד: הבעיה עם סבילות התקלות ב-memcached נפתרה, אמינות אחסון המטמון הוגדלה. בנוסף ליתרונות הברורים עבור האפליקציה, הדבר נתן מרחב תמרון בעבודה על הפלטפורמה: כאשר לכל הרכיבים יש עתודה, חיי המנהל פשוטים מאוד. כן, לשיטה הזו יש חסרונות, היא אולי נראית כמו "קביים", אבל אם היא חוסכת כסף, קוברת את הבעיות ולא גורמת לבעיות חדשות - למה לא?

נ.ב.

קרא גם בבלוג שלנו:

• "תרגול עם דאפ" (באמצעות symfony-demo כדוגמה): חלק 1 (בניית יישומים פשוטים) и חלק 2 (פריסת תמונות Docker ל-Kubernetes באמצעות Helm);
• «מהחיים עם Kubernetes: איך שרת ה-HTTP לא העדיף את הספרדים".

מקור: www.habr.com