הבעיה עם MySQL והפתרון של אמזון

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

יחסית, MySQL יודע להסתדר די טוב עם כל חומרה שתזרקו לו, החל מ-512 מגהבייט של זכרון ודיסק SATA מכני פשוט ועד מעבדי Xeon E7 עם ליבות מרובים, מאות ג'יגהבייטים של זכרון ודיסקים SSD מבוססים NVMe. תצטרכו כמובן להגדיר דברים מסויימים בקובץ my.cnf, אבל בד"כ איש סיסטם טוב ידע להסתדר עם זה.

הבעיות מתחילות כשאנחנו צריכים להתרחב מבחינת כמות שרתים מעבר לשרת יחיד. מכאן אנחנו עוברים לשיטות כמו Master/Slave, אנחנו יכולים להשתמש ב-Sharding ויש עוד כמה שיטות. לכשזה עובד – הדברים עובדים בצורה טובה… עד שקורה Crash, צריך להשתמש ב-mysqlbinlog והסיפור לוקח זמן. בעיות אחרות יכולות לקרות אם הסינכרון נופל היכן שהוא. שורת הקללות שאיש הסיסטם (או ה-DBA) יפלוט – תהיה ארוכה.

חברות שונות כשגודלות מחליטות מסיבות שונות לעבור לפתרונות מבוססים NoSQL, בין אם זה DynamoDB, או MongoDB ופתרונות אחרים ששם עניין ה-Scalability נבנה בצורה אחרת והוא יכול להתפרס על פני מאות Nodes ויותר ב-Data Centers שונים בעולם. אם תסתכלו כאן לדוגמא, תראו שחברות גדולות מאוד ומפורסמות משתמשות ב-MongoDB והן מרוצות, מאוד.

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

באמזון, חברת הענן הציבורי הגדול בעולם, החליטו בהתחלה להציע את שרות ה-RDS ואחת האופציות העיקריות שם היא MySQL מנוהל. אתה מגדיר בהתחלה אם אתה מעוניין ב-Instance יחיד קטן או שאתה מעוניין בשימוש מספר Availability Zones (כך שתהיה רפליקציה של ה-DATA באזורים שונים ב-Data Center), אתה מחליט על גודל מכונה, כמות אחסון וכמות IOPS (חישוב שאני אישית שונא) ואתה מקבל Instance של MySQL שאמזון מנהלים עבורך. מבחינת חברות שכבר שמות את האפליקציה שלהן בענן – זה פתרון טוב יותר מאשר סתם לשכור מספר Instances ולהתחיל לעשות את כל עבודת ה-MySQL ידנית, אבל עדיין, מבחינת השוואת ביצועים – Instance שאתה תרים על מכונה חזקה מאוד – יהיה יותר מהיר מ-RDS (אם כי כמובן אתה תפסיד הרבה מהפונקציונאליות של RDS ואתה תצטרך לבצע הרבה דברים ש-RDS מבצע לבד).

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

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

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

  • הוא בנוי מהרגע הראשון ל-High Availability. צריך Instance יחיד לבלוג שלך או שה-? חזור ל-RDS עם MySQL.
  • אין יותר הגדרות של Storage וה-Storage הוא אינו חלק מהמכונה. מעתה ה-Storage מנוהל ע"י אמזון והוא גודל דינמית לפי הצרכים של ה-DB שלך עד לגודל מפלצתי של 64TB!
  • היא מהיר הרבה יותר מ-MySQL – פי 3-5.
  • אתה יכול לבצע מיליוני טרנזאקציות בדקה מ-Instance ואם אתה צריך עוד רפליקות, אתה יכול להוסיף עד 15 רפליקות.
  • ה-DB נופל ברפליקה מסויימת? שכח מזה, Aurora מטפל ומנטר לבד הכל.
  • ה-DATA שלך שמור בלא פחות מ-3 עותקים ב-AZ, כך שאם יש לך Crash, השחזור הוא מיידי.
  • יש לך Snapshots ואתה יכול לבחור Snapshot ולהשתמש בה כ-DB עיקרי מיידית.
  • אין לך צורך לנהל כמעט שום דבר, גם עדכוני תוכנה מבוצעים מיידית בזמן שתגדיר במערכת
  • מכונות גדולות – אתה יכול להרים מכונה עם עד 244 ג'יגהבייט זכרון ו-32 ליבות.
  • אפשר תוך מספר קליקים לעבור מ-RDS עם MySQL ל-Aurora

ומה שהכי חשוב: Aurora תואם MySQL 5.6 בתצורת On the wire, כלומר האפליקציה שלך לכשתתחבר אל ה-Instance, תחשוב שמדובר ב-MySQL לכל דבר ועניין.

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

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

יש גם חסרונות:

  • אם גודל ה-Datasize שלך הוא די קטן (כמה אלפים) – Instance שתרים משלך עם 3000 IOPS ירוץ יותר מהר מ-Aurora (אם תשתמש ב-DB חלופי ותואם כמו Percona)
  • ה-Aurora עדיין לא מהיר ברוב המקרים בהשוואה ל-Percona גם ב-Datasize גדול (אתם מוזמנים לקרוא את המאמר שלהם כאן).
  • אם יש לך איש סיסטם בחברה, הוא יכול לבנות פתרון יותר טוב מ-Aurora  בין אם בשימוש Percona או גם MariaDB, עם אחסון בעל IOPS גבוה ובניית שרידות שמורכבת מ-AZ, כך שבשביל חברות כאלו – Aurora לא יתן הרבה.

הדבר היחיד שחסר בזה – איזה Free Tier לשחק איתו 🙂

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

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