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

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

בואו ננסה לסנן את המידע ולרשום את הנוסחה הבסיסית. אנחנו הולכים להגדיל את אתר שיתוף התמונות החדש שלנו Graminsta צעד אחר צעד מ-1 ל-100 משתמשים.

בואו נרשום אילו פעולות ספציפיות צריך לבצע כאשר הקהל גדל ל-10, 100, 1000, 10 ו-000 אנשים.

משתמש אחד: מכונה אחת

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

• API
• מאגר מידע
• לקוח (יישום נייד עצמו או אתר אינטרנט)

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

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

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

בתיאוריה, נוכל לפרוס אותו בענן על מופע יחיד של DigitalOcean Droplet או AWS EC2, כפי שמוצג להלן:

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

10 משתמשים: העברת מסד הנתונים לרמה נפרדת

פיצול מסד הנתונים לשירותים מנוהלים כמו Amazon RDS או Digital Ocean Managed Database ישרת אותנו לאורך זמן. זה קצת יותר יקר מאשר אירוח עצמי במכונה בודדת או מופע EC2, אבל עם השירותים האלה אתה מקבל הרבה הרחבות שימושיות מהקופסה שיהיו שימושיים בעתיד: גיבוי רב אזורי, העתקים לקריאה, אוטומטי גיבויים ועוד.

כך נראית המערכת כעת:

100 משתמשים: העברת הלקוח לרמה נפרדת

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

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

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

כך נראית מערכת כזו:

1000 משתמשים: הוסף מאזן עומסים

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

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

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

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

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

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

הערה. כרגע המערכת שלנו דומה מאוד למה שחברות PaaS כמו Heroku או Elastic Beanstalk ב-AWS מציעות מהקופסה (בגלל זה הן כל כך פופולריות). Heroku שם את מסד הנתונים על מארח נפרד, מנהל מאזן עומסים בקנה מידה אוטומטי, ומאפשר לך לארח את לקוח האינטרנט בנפרד מה-API. זו סיבה מצוינת להשתמש ב-Heroku לפרויקטים או סטארטאפים בשלבים מוקדמים - אתה מקבל את כל השירותים הבסיסיים מהקופסה.

10 משתמשים: CDN

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

בשלב זה צריך להשתמש בשירות ענן לאחסון תוכן סטטי – תמונות, סרטונים ועוד הרבה יותר (AWS S3 או Digital Ocean Spaces). באופן כללי, ה-API שלנו צריך להימנע מטיפול בדברים כמו הגשת תמונות והעלאת תמונות לשרת.

יתרון נוסף של אירוח בענן הוא ה-CDN (AWS מכנה את התוסף הזה Cloudfront, אבל ספקי אחסון ענן רבים מציעים אותו מחוץ לקופסה). ה-CDN שומר באופן אוטומטי את התמונות שלנו במרכזי נתונים שונים ברחבי העולם.

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

100 משתמשים: שינוי קנה המידה של שכבת הנתונים

CDN עזר רבות: התנועה גדלה במלוא המהירות. בלוגר הווידאו המפורסם Mavid Mobrick פשוט נרשם אלינו ופרסם את ה"סיפור" שלו, כמו שאומרים. הודות למאזן העומס, השימוש במעבד והזיכרון בשרתי ה-API נשמר נמוך (פועלים עשרה מופעי API), אבל אנחנו מתחילים לקבל הרבה פסקי זמן בבקשות... מאיפה העיכובים האלה?

חופרים מעט במדדים, אנו רואים שה-CPU בשרת מסד הנתונים נטען ב-80-90%. אנחנו על הגבול.

קנה המידה של שכבת הנתונים הוא כנראה החלק הקשה ביותר במשוואה. שרתי API משרתים בקשות חסרות מצב, אז אנחנו פשוט מוסיפים עוד מופעי API. אף הרוב מסדי נתונים לא יכולים לעשות זאת. נדבר על מערכות פופולריות לניהול מסדי נתונים יחסי (PostgreSQL, MySQL וכו').

שמירה במטמון

אחת הדרכים הקלות ביותר להגביר את הביצועים של מסד הנתונים שלנו היא להציג רכיב חדש: שכבת המטמון. שיטת האחסון הנפוצה ביותר היא חנות רשומות מפתח-ערך בזיכרון, כגון Redis או Memcached. לרוב העננים יש גרסה מנוהלת של השירותים האלה: Elasticache ב-AWS ו-Memorystore ב-Google Cloud.

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

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

נשמור את התוצאות ממסד הנתונים ב-Redis לפי מפתח user:id עם תקופת תוקף של 30 שניות. עכשיו, כשמישהו נכנס לפרופיל של מובריק, אנחנו קודם כל בודקים את Redis, ואם הנתונים שם, אנחנו פשוט מעבירים אותם ישירות מרדיס. כעת בקשות לפרופיל הפופולרי ביותר באתר כמעט ואינן טוענות את מסד הנתונים שלנו.

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

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

קרא העתקים

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

הנה המערכת שלנו עכשיו:

השלבים הבאים

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

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

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

מקורות

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

הערות שוליים

1. למרות דומה מבחינת חלוקת עומסים על פני מספר מופעים, היישום הבסיסי של אשכול Redis שונה מאוד ממאזן עומסים. [לַחֲזוֹר]

מקור: www.habr.com