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

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

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

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

מה רע ב-memcached עצמו?

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

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

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

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

NB: ייתכן שתמצא גם קישורים שימושיים ללימוד 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 >

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

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

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

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

מסקנה

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

נ.ב.

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

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

מקור: www.habr.com