שאלות נפוצות על ארכיטקטורה ועבודה של VKontakte

ההיסטוריה של יצירת VKontakte נמצאת בוויקיפדיה; היא סופרה על ידי פאבל עצמו. נראה שכולם כבר מכירים אותה. על הפנים, הארכיטקטורה והמבנה של האתר ב-HighLoad++ Pavel אמר לי עוד ב-2010. שרתים רבים דלפו מאז ולכן נעדכן את המידע: ננתח אותו, נוציא את החלק הפנימי, נשקול אותו ונסתכל על מכשיר ה-VK מנקודת מבט טכנית.

אלכסיי אקולוביץ' (אטרקטוס) מפתח אחורי בצוות VKontakte. תמלול דוח זה הוא תשובה קולקטיבית לשאלות נפוצות על תפעול הפלטפורמה, התשתית, השרתים והאינטראקציה ביניהם, אך לא על פיתוח, כלומר על ברזל. בנפרד, על מסדי נתונים ומה יש ל-VK במקום, על איסוף יומנים ומעקב אחר הפרויקט כולו. פרטים מתחת לחתוך.

כבר יותר מארבע שנים שאני עוסק בכל מיני משימות הקשורות ל-backend.

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

במהלך תקופה זו, היה לי יד במרכיבים רבים של האתר. אני רוצה לחלוק את החוויה הזו.

ארכיטקטורה כללית

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

שרת קדמי

השרת הקדמי מקבל בקשות באמצעות HTTPS, RTMP ו-WSS.

HTTPS - אלו הן בקשות לגרסאות האינטרנט הראשיות והנייד של האתר: vk.com ו-m.vk.com, ולקוחות רשמיים ובלתי רשמיים אחרים של ה-API שלנו: לקוחות ניידים, שליחים. יש לנו קבלת פנים RTMP-תנועה לשידורים חיים עם שרתים קדמיים נפרדים ו WSS- חיבורים עבור Streaming API.

עבור HTTPS ו-WSS בשרתים זה שווה nginx. עבור שידורי RTMP, עברנו לאחרונה לפתרון משלנו קייב, אבל זה מעבר לתחום הדוח. לצורך סובלנות תקלות, שרתים אלו מפרסמים כתובות IP נפוצות ופועלים בקבוצות כך שאם יש בעיה באחד השרתים, בקשות המשתמש לא יאבדו. עבור HTTPS ו-WSS, אותם שרתים מצפינים תעבורה על מנת לקחת חלק מעומס המעבד על עצמם.

לא נדבר יותר על WSS ו-RTMP, אלא רק על בקשות HTTPS סטנדרטיות, המשויכות בדרך כלל לפרויקט אינטרנטי.

קצה אחורי

מאחורי החזית יש בדרך כלל שרתי אחורי. הם מעבדים בקשות שהשרת הקדמי מקבל מלקוחות.

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

חלוקת עומסים

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

איסוף מדדים ואיזון מחדש

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

יש לנו אלפי שרתים כאלה. כל שרת פיזי מפעיל קבוצת kPHP כדי למחזר את כל הליבות (מכיוון ש-kPHP הוא פתיל יחיד).

שרת תוכן

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

יש לנו עשרות אלפי שרתים פיזיים המאחסנים קבצים. משתמשים אוהבים להעלות קבצים, ואנחנו אוהבים לאחסן ולשתף אותם. חלק מהשרתים הללו סגורים על ידי שרתי pu/pp מיוחדים.

pu/pp

אם פתחת את לשונית הרשת ב-VK, ראית את pu/pp.

מה זה pu/pp? אם נסגור שרת אחד אחרי השני, אז יש שתי אפשרויות להעלות ולהוריד קובץ לשרת שנסגר: ישירות דרך http://cs100500.userapi.com/path או דרך שרת ביניים - http://pu.vk.com/c100500/path.

Pu הוא השם ההיסטורי להעלאת תמונות, ו-pp הוא פרוקסי תמונה. כלומר, שרת אחד מיועד להעלאת תמונות, ואחר הוא להעלאה. כעת לא רק תמונות נטענות, אלא השם נשמר.

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

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

חוסן על כתובות IP משותפות. מבחינת סבילות לתקלות, הסכימה פועלת אותו הדבר – למספר שרתים פיזיים יש IP פיזי משותף, והחומרה שלפניהם בוחרת לאן לשלוח את הבקשה. אני אדבר על אפשרויות אחרות מאוחר יותר.

הנקודה השנויה במחלוקת היא שבמקרה זה הלקוח שומר על פחות קשרים. אם יש אותו IP עבור מספר מכונות - עם אותו מארח: pu.vk.com או pp.vk.com, לדפדפן הלקוח יש הגבלה על מספר הבקשות בו-זמנית למארח אחד. אבל בתקופה של HTTP/2 בכל מקום, אני מאמין שזה כבר לא כל כך רלוונטי.

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

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

שמש

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

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

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

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

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

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

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

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

שמש מבפנים

פרוקסי הפוך ב-nginx, שמור במטמון ב-RAM או בדיסקים מהירים של Optane/NVMe. דוגמא: http://sun4-2.userapi.com/c100500/path - קישור ל"שמש", שנמצאת באזור הרביעי, קבוצת השרתים השנייה. זה סוגר את קובץ הנתיב, שנמצא פיזית על שרת 100500.

סליק

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

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

זהו שמירה במטמון של תוכן מולטימדיה; לא מאוחסנים כאן נתוני משתמש - רק מוזיקה, וידאו, תמונות.

כדי לקבוע את אזור המשתמש, אנו אנו אוספים קידומות רשת BGP שהוכרזו באזורים. במקרה של fallback, עלינו גם לנתח את מסד הנתונים של geoip אם לא הצלחנו למצוא את ה-IP לפי קידומות. אנו קובעים את האזור לפי ה-IP של המשתמש. בקוד נוכל להסתכל על אזור אחד או יותר של המשתמש - אותן נקודות שהוא הכי קרוב אליהן מבחינה גיאוגרפית.

איך זה עובד?

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

במקביל, שדים - שירותים באזורים - מגיעים מדי פעם ל-API ואומרים: "אני מטמון כזה וכזה, תן לי רשימה של הקבצים הכי פופולריים באזור שלי שעדיין לא אצלי. ” ה-API מספק חבורה של קבצים ממוינים לפי דירוג, הדמון מוריד אותם, לוקח אותם לאזורים ומשם את הקבצים. זה ההבדל המהותי בין pu/pp ל-Sun ממטמונים: הם נותנים את הקובץ דרך עצמם מיד, גם אם הקובץ הזה לא נמצא במטמון, והמטמון קודם כל מוריד לעצמו את הקובץ, ואז מתחיל להחזיר אותו.

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

אבל יש בעיות - שרתי מטמון אינם גומי. עבור תוכן סופר פופולרי, לפעמים אין מספיק רשת לשרת נפרד. שרתי המטמון שלנו הם 40-50 Gbit/s, אבל יש תוכן שסותם לגמרי ערוץ כזה. אנו מתקדמים לקראת יישום אחסון של יותר מעותק אחד של קבצים פופולריים באזור. אני מקווה שנוכל ליישם את זה עד סוף השנה.

הסתכלנו על הארכיטקטורה הכללית.

• שרתים קדמיים שמקבלים בקשות.
• Backends כי תהליך בקשות.
• מחסנים סגורים על ידי שני סוגים של פרוקסי.
• מטמונים אזוריים.

מה חסר בתרשים הזה? כמובן, מאגרי המידע שבהם אנו מאחסנים נתונים.

מסדי נתונים או מנועים

אנחנו קוראים להם לא מסדי נתונים, אלא מנועים - מנועים, כי למעשה אין לנו מסדי נתונים במובן המקובל.

זהו אמצעי הכרחי.. זה קרה בגלל שבשנים 2008-2009, כאשר ל-VK הייתה צמיחה נפיצה בפופולריות, הפרויקט עבד כולו על MySQL ו-Memcache והיו בעיות. MySQL אהב לקרוס ולהשחית קבצים, ולאחר מכן הוא לא התאושש, ו-Memcache ירד בהדרגה בביצועים והיה צריך להפעיל אותו מחדש.

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

הפתרון הצליח. הייתה הזדמנות לעשות זאת, כמו גם הכרח קיצוני, מכיוון שדרכים אחרות של קנה מידה לא היו קיימות באותה תקופה. לא היו חבורה של מסדי נתונים, NoSQL עדיין לא היה קיים, היו רק MySQL, Memcache, PostrgreSQL - וזהו.

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

סוגי מנועים

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

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

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

אשכולות

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

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

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

פרוקסי RPC

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

למתכנתים לא אכפת בכלל כמה, איפה ומה זה עולה - הם פשוט הולכים לאשכול. זה מאפשר לנו הרבה. בעת קבלת בקשה, ה-proxy מפנה את הבקשה, ביודעו לאן - הוא קובע זאת בעצמו.

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

יישומים ספציפיים

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

עבור MySQL, שעדיין יש לנו פה ושם, אנו משתמשים ב-db-proxy, ועבור ClickHouse - בית חתולים.

זה עובד בדרך כלל ככה. יש שרת מסויים, הוא מריץ kPHP, Go, Python - באופן כללי, כל קוד שיכול להשתמש בפרוטוקול ה-RPC שלנו. הקוד פועל באופן מקומי על פרוקסי RPC - כל שרת בו נמצא הקוד מפעיל פרוקסי מקומי משלו. לפי בקשה, מיופה הכוח מבין לאן לפנות.

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

דוגמה ל-TL-scheme שלפיה פועלים כל המנועים.

memcache.not_found                                = memcache.Value;
memcache.strvalue	value:string flags:int = memcache.Value;
memcache.addOrIncr key:string flags:int delay:int value:long = memcache.Value;

tasks.task
    fields_mask:#
    flags:int
    tag:%(Vector int)
    data:string
    id:fields_mask.0?long
    retries:fields_mask.1?int
    scheduled_time:fields_mask.2?int
    deadline:fields_mask.3?int
    = tasks.Task;
 
tasks.addTask type_name:string queue_id:%(Vector int) task:%tasks.Task = Long;

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

RPC על TL על TCP/UDP... UDP?

יש לנו פרוטוקול RPC לביצוע בקשות מנוע שפועל על גבי סכימת TL. כל זה עובד על חיבור TCP/UDP. TCP מובן, אבל למה אנחנו צריכים UDP לעתים קרובות?

UDP עוזר למנוע את הבעיה של מספר עצום של חיבורים בין שרתים. אם לכל שרת יש פרוקסי RPC ובאופן כללי הוא יכול לעבור לכל מנוע, אז יש עשרות אלפי חיבורי TCP לכל שרת. יש עומס, אבל הוא חסר תועלת. במקרה של UDP בעיה זו לא קיימת.

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

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

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

אחסון נתונים מתמשך

מנועים כותבים בלוגים. בינלוג הוא קובץ שבסופו מתווסף אירוע לשינוי מצב או נתונים. בפתרונות שונים זה נקרא אחרת: יומן בינארי, וול, AOF, אבל העיקרון זהה.

כדי למנוע מהמנוע לקרוא מחדש את כל ה-binlog במשך שנים רבות בעת הפעלה מחדש, כותבים המנועים תמונות - מצב נוכחי. אם צריך, הם קוראים ממנו קודם, ואחר כך מסיימים לקרוא מהבינלוג. כל ה-binlogs נכתבים באותו פורמט בינארי - לפי סכימת TL, כך שמנהלי מערכת יכולים לנהל אותם באופן שווה באמצעות הכלים שלהם. אין צורך כזה בצילומי מצב. יש כותרת כללית שמציינת של מי תמונת המצב היא int, קסם של המנוע ואיזה גוף לא חשוב לאף אחד. זו בעיה במנוע שרשם את תמונת המצב.

אתאר במהירות את עקרון הפעולה. יש שרת שעליו פועל המנוע. הוא פותח בלוג חדש ריק לכתיבה וכותב אירוע לשינוי בו.

בשלב מסוים, או שהוא מחליט לצלם תמונה בעצמו, או שהוא מקבל אות. השרת יוצר קובץ חדש, כותב לתוכו את כל מצבו, מוסיף את גודל הבינלוג הנוכחי - offset - לסוף הקובץ, וממשיך לכתוב. לא נוצר בינלוג חדש.

בשלב מסוים, כשהמנוע יתניע מחדש, יהיו גם binlog וגם תמונת מצב על הדיסק. המנוע קורא את כל תמונת המצב ומעלה את מצבו בנקודה מסוימת.

קורא את המיקום שהיה בזמן יצירת תמונת המצב ואת גודל ה-binlog.

קורא את סוף ה-binlog כדי לקבל את המצב הנוכחי וממשיך לכתוב אירועים נוספים. זוהי תכנית פשוטה; כל המנועים שלנו פועלים לפיה.

שכפול נתונים

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

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

במידת צורך קורא העתקכדי להפחית את עומס הקריאה של המעבד, פשוט מופעל מנוע הקריאה, שקורא את סוף ה-binlog ומבצע את הפקודות הללו באופן מקומי.

הפיגור כאן קטן מאוד, ואפשר לגלות עד כמה העתק מפגר אחרי המאסטר.

חלוקת נתונים בפרוקסי RPC

איך עובד הריסה? איך ה-proxy מבין לאיזה רסיסי אשכול לשלוח? הקוד לא אומר: "שלח עבור 15 רסיסים!" - לא, זה נעשה על ידי ה-proxy.

הסכימה הפשוטה ביותר היא firstint - המספר הראשון בבקשה.

get(photo100_500) => 100 % N.

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

זה שימושי כאשר אנו רוצים לקבל מיקום נתונים של ישות אחת. נניח ש-100 הוא מזהה משתמש או קבוצה, ואנו רוצים שכל הנתונים של ישות אחת יהיו ברסיס אחד עבור שאילתות מורכבות.

אם לא אכפת לנו איך הבקשות מפוזרות ברחבי האשכול, ישנה אפשרות נוספת - גיבוב את כל הרסיס.

hash(photo100_500) => 3539886280 % N

אנחנו מקבלים גם את ה-hash, את שאר החלוקה ואת מספר הרסיס.

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

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

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

יומנים

אנו כותבים יומנים בכמה דרכים. הברור והפשוט ביותר הוא לכתוב יומנים ל-memcache.

ring-buffer: prefix.idx = line

יש קידומת מפתח - שם היומן, שורה, ויש את הגודל של היומן הזה - מספר השורות. ניקח מספר אקראי מ-0 למספר השורות מינוס 1. המפתח ב-memcache הוא קידומת המשורשרת למספר האקראי הזה. אנו שומרים את שורת היומן ואת השעה הנוכחית לערך.

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

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

המנוע ישן מאוד, יש אשכולות שכבר בני 6-7 שנים. יש איתו בעיות שאנחנו מנסים לפתור, למשל, התחלנו להשתמש באופן פעיל ב-ClickHouse לאחסון יומנים.

איסוף יומנים בקליקהאוס

תרשים זה מראה כיצד אנו נכנסים לתוך המנועים שלנו.

יש קוד שעובר באופן מקומי דרך RPC ל-RPC-proxy, והוא מבין לאן ללכת למנוע. אם ברצוננו לכתוב יומנים ב-ClickHouse, עלינו לשנות שני חלקים בסכימה זו:

• להחליף מנוע כלשהו בקליקהאוס;
• להחליף את פרוקסי RPC, שאינו יכול לגשת ל-ClickHouse, בפתרון כלשהו שיכול, ובאמצעות RPC.

המנוע פשוט - אנחנו מחליפים אותו בשרת או באשכול שרתים עם ClickHouse.

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

לפעמים אנחנו לא רוצים ליישם את סכימת ה-RPC בפתרונות לא סטנדרטיים, למשל, ב-nginx. לכן, ל- KittenHouse יש את היכולת לקבל יומנים דרך UDP.

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

ניטור

יש לנו שני סוגים של יומנים: אלו שנאספו על ידי מנהלי מערכת בשרתים שלהם ואלו שנכתבו על ידי מפתחים מקוד. הם תואמים לשני סוגים של מדדים: מערכת ומוצר.

מדדי מערכת

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

מדדי מוצר

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

statlogsCountEvent   ( ‘stat_name’,            $key1, $key2, …)
statlogsUniqueCount ( ‘stat_name’, $uid,    $key1, $key2, …)
statlogsValuetEvent  ( ‘stat_name’, $value, $key1, $key2, …)

$stats = statlogsStatData($params)

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

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

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

במידת הצורך, נוכל לכתוב ישירות לאוספי יומנים.

אבל כתיבה מקוד ישירות לאספנים, תוך עקיפת stas-daemom, היא פתרון לא ניתן להרחבה מכיוון שהיא מגבירה את העומס על האספן. הפתרון מתאים רק אם מסיבה כלשהי איננו יכולים להעלות את ה-memcache stats-daemon במכונה, או שהוא קרס והלכנו ישירות.

לאחר מכן, אוספי יומנים ממזגים נתונים סטטיסטיים לתוך meowDB - זהו מסד הנתונים שלנו, שיכול לאחסן גם מדדים.

אז נוכל לבצע בחירות בינאריות של "קרוב ל-SQL" מהקוד.

הניסוי

בקיץ 2018 היה לנו האקתון פנימי, ועלה הרעיון לנסות להחליף את החלק האדום של הדיאגרמה במשהו שיכול לאחסן מדדים ב-ClickHouse. יש לנו יומנים על ClickHouse - למה לא לנסות את זה?

הייתה לנו תוכנית שכתבה יומנים דרך KittenHouse.

החלטנו הוסף עוד "*בית" לתרשים, שיקבל בדיוק את המדדים בפורמט כפי שהקוד שלנו כותב אותם דרך UDP. ואז *הבית הזה הופך אותם לתוספות, כמו יומנים, ש-KittenHouse מבינה. הוא יכול להעביר את היומנים האלה בצורה מושלמת ל-ClickHouse, שאמורה להיות מסוגלת לקרוא אותם.

הסכימה עם memcache, stats-daemon ו-logs-collectors מסד הנתונים מוחלפת בזו.

הסכימה עם memcache, stats-daemon ו-logs-collectors מסד הנתונים מוחלפת בזו.

• יש כאן שליחת קוד, שנכתבת באופן מקומי ב-StatsHouse.
• StatsHouse כותב מדדי UDP, שכבר הומרו לתוספות SQL, ל-KittenHouse באצווה.
• KittenHouse שולח אותם ל- ClickHouse.
• אם אנחנו רוצים לקרוא אותם, אז אנחנו קוראים אותם עוקפים את StatsHouse - ישירות מ-ClickHouse באמצעות SQL רגיל.

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

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

לפרוס

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

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

אנחנו גם פורסים הרבה kPHP ויש לו גם פיתוח משלו סילון לפי התרשים למעלה. מאז שרת HTTP בינארי, אז אנחנו לא יכולים לייצר diff - הבינארי השחרור שוקל מאות MB. לכן, יש כאן אפשרות נוספת - הגרסה כתובה binlog copyfast. עם כל בנייה היא גדלה, ובזמן החזרה היא גם עולה. גִרְסָה משוכפל לשרתים. קויפסטים מקומיים רואים שנכנסה גרסה חדשה ל-binlog, ועל ידי אותו שכפול רכילות הם לוקחים לעצמם את הגרסה העדכנית ביותר של הבינארי, מבלי לעייף את השרת הראשי שלנו, אלא לפזר בזהירות את העומס ברחבי הרשת. מה עוקב השקה מחודשת וחיננית עבור הגרסה החדשה.

עבור המנועים שלנו, שהם גם בעצם בינאריים, הסכימה דומה מאוד:

• ענף git master;
• בינארי ב deb;
• הגרסה נכתבת ל-binlog copyfast;
• משוכפל לשרתים;
• השרת שולף .dep טרי;
• dpkg -i;
• השקה מחדש חיננית לגרסה חדשה.

ההבדל הוא שהבינארי שלנו ארוז בארכיונים deb, וכאשר שואבים אותם dpkg -i מונחים על המערכת. מדוע kPHP נפרס כקובץ בינארי, ומנועים נפרסים כ-dpkg? זה קרה ככה. זה עובד - אל תיגע בזה.

קישורים שימושיים:

• דיווח מאת אנטון קירושקין "מנהל מערכת Vkontakte. אֵיך?" עם פרטים על copyfast ורכילות.
• דיווח של יורי נסרדינוב "כיצד VK מכניסה נתונים ל-CLickHouse מעשרות אלפי שרתים".
• הדיווח שלי "ארכיטקטורה של פרויקט צומח תוך שימוש בדוגמה של VKontakte", אבל מנקודת מבט של פיתוח, לא חומרה.

אלכסיי אקולוביץ' הוא אחד מאלה שמסייעים במסגרת ועדת התכנית PHP רוסיה ב-17 במאי יהפוך לאירוע הגדול ביותר עבור מפתחי PHP בתקופה האחרונה. תראה איזה מחשב מגניב יש לנו, מה רמקולים (שניים מהם מפתחים ליבת PHP!) - נראה כמו משהו שאי אפשר לפספס אם אתה כותב PHP.

מקור: www.habr.com