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

• I/O – קצבי הקריאה/כתיבה לדיסק (פיזי או וירטואלי) מוגבלים וככל שיש יותר פעולות כאלו, כך גם התור לקבלת השרות מהמערכת גדל ומשפיע ישירות על הביצועים. פעולות I/O קשורות קשר ישיר לכתיבה (כגון שמירת קבצים שהועלו על ידי משתמשים) או קריאה (פתיחת קובץ קוד, תמונה וכו’) של האפליקציה וכשיש עומס I/O, האפליקציה סובלת.
  למי שיש נסיון עם AWS, בטח כבר מודע לבעיות ה – I/O הקשות של סביבה זו (אפילו בעמוס מאד נמוך) וכמו רבים מחפש פתרון לבעיה זו, שבשלב זה לא ממש קיים (יש מספר פתרונות חלקיים לבעיה, אך כולם מייקרים מאד את השרות הבסיסי של AWS ולא מאפשרים להגיע לקצבים באמת מהירים, להם אנחנו רגילים מעולם החומרה הפיזית).
• גישה ל – DataBase – לפני מספר שנים, כשאפליקציות Web רצו בעיקר על סביבות פיזיות, לרובן בעיות I/O לא ממש הפריעו (לפחות עד שהגיעו Web2.0, רשתות חברתיות ואתרי שיתוף למינהם). לעומת זאת מהיום שבו העלתי את אפליקציית ה – Web הראשונה שלי לאויר, לפני הרבה מאד שנים, הייתי עסוק באיך לשפר את ביצועי האפליקציה ולא היה רכיב יותר חשוב להתרכז בו מבסיס הנתונים של האפליקציה.
  יש המון שיטות וכלים לשיפור ביצועי DB. זה מתחיל ממבנה הנתונים, אינדקסים, שאילתות יעילות יותר, עובר דרך קונפיגורציה של שרת ה – DB (הן ברמת התוכנה וכמובן חומרה, הרבה חומרה) אבל כמעט תמיד, במקרים בהם יש צורך בביצועים גבוהים מבלי לשרוף אין סוף דולרים על שרתי על, הסיפור נגמר ב – Caching (מטמון בעברית אבל זאת הפעם האחרונה שאני הולך להשתמש בזה!).

כאמור, למשתמשי AWS אין חיים קלים בכל מה שקשור ל – I/O וגם בחזית ה – DB (עם קשר ישיר לבעיית ה – I/O של המערכת, מכיוון שביצועי DB מאד תלויים ב – I/O) יש לא מעט בעיות והמון משתמשים מתוסכלים. אמזון כרגיל מקשיבים למשתמשים ומכריזים היום על שרות חדש (עדיין ב – Beta), הפונה למשתמשים שביצועי האפליקציה שלהם יקרים להם ועד היום סבלו קשות או נמנעו משרותי AWS. לשרות החדש קוראים ElastiCache אבל לפני שנדבר על השרות החדש, עוד קצת רקע.

DataBase Caching

הרעיון מאחורי DB Caching הוא פשוט. במקום לגשת ל – DB, שהוא משאב יקר יחסית (ברוב המקרים מדובר בשימוש במשאבי רשת על מנת לגשת לשרת, שרות I/O על מנת לקרוא/לכתוב נתונים ועוד מספר לא מבוטל של פעולות “יקרות”) הנתונים שמורים חלקית וזמנית במקום שהגישה אליו “זולה” ומהירה יותר.
קחו לדוגמא עמוד רישום לשירות דמיוני, שכולל את ארץ המגורים של הנרשם. גם אם רשימת הארצות נמצאת בבסיס הנתונים, איזו סיבה יש לי לקרוא את הרשימה ישירות מתוך ה – DB, כל פעם שיש משתמש חדש שרוצה להירשם? הרי הרשימה הזאת היא סטטית כמעט לחלוטין, אפשר לשמור אותה כקובץ על הדיסק ולעדכן אותה פעם בשבוע (רק בשביל הדוגמא). גישה לקובץ טקסט על הדיסק מהירה פי כמה וכמה מכל שאילתא פשוטה ל – DB על מנת לשלוף את רשימת הנתונים. אמנם זאת דוגמא מאד פשוטה (אך יעילה) אבל גם הפתרונות היותר מתוחכמים עובדים על אותו עיקרון של הורדת מספר הגישות ל – DB עצמו על מנת לשפר ביצועים.

Memcached

אחד הכלים הפופולריים לשיפור ביצועים באפליקציות Web בשנים האחרונות הוא Memcached. הרעיון של Memcached הוא לשמור בזיכרון (מכאן Mem), שהוא משאב מאד מהיר ויחסית זול, נתונים להם זקוקה האפליקציה ולאפשר למפתח לעדכן ולנהל נתונים אלו בקלות יחסית, בעזרת APIs פשוטים הנתמכים בשפות תיכנות רבות. אפליקציות מודרניות עושות כיום שימוש מסיבי ב – Memcached על מנת להחליף פונקציונליות כגון שמירת Sessions, שהיתה שמורה ל – DB לאורך השנים. נכון שלא מדובר על כלי המיועד אך ורק ל –  DataBase Caching אבל מפתחים רבים עושים בו שימוש על מנת ליצור שכבת Cache לנתונים להם זקוקה האפליקציה. בנוסף לאפשרות לתכנת ממשקים בין האפליקציה ל – Memcached, מספר לא מבוטל של אפליקציות מגיעות היום עם Memcached Plugins מובנים, המאפשרים שימוש בכלי זה ללא כתיבת שורת קוד אחת וביצועים פנומנליים.
למי שלא מכיר את Memcached אני מאד ממליץ לקרוא עליו. הוא יחסית פשוט לאינטגרציה ומכיל עוד מספר תכונות, שלא ניכנס אליהן כאן, שהופכות אותו למועמד רציני לכל אפליקציה עם פוטנציאל עומס גדול.

ElastiCache

אז למה אני מספר לכם את כל זה? כי המוצר החדש של AWS הוא למעשה Memcached ארוז כשרות, למשתמשי הענן של אמזון. האמת שאין הרבה מה לפרט מעבר לזה. השרות החדש יעבוד בדיוק כמו כל התקנה אחרת של Memcached, זאת על מנת לאפשר מעבר פשוט לשרות והוא כולל את כל ה – Goodies שאמזון מציעה בשרותי ה – AWS האחרים שלה:

• תשלום על פי שימוש – אתה בוחר את גודל מכונת ה – Cache שלך מתוך מבחר של 7 סוגים (החל מ – 1.3GB של זיכרון ועד 64GB, אם בא לכם לטעון את כל בסיס הנתונים שלכם לזיכרון). התשלום הוא על מכונה (Node) ותעבורת נתונים.
• יכולת גדילה – בעזרת כלים פשוטים אפשר להוסיף Caching Nodes על מנת להתמודד עם עומסים גבוהים.
• התאשוששות מאסון – אמזון מנטרים את השרות ובמקרה של קריסה יעלו מכונות חדשות אוטומטית.

כאמור השרות הושק  ב – Beta והוא זמין, נכון להיום, בחווה אחת בלבד של אמזון (US East). אמנם לא מדובר בשיפור ביצועים ישיר של שרותי ה – RDS של אמזון, אבל בהחלט מדובר בכלי שיאפשר ליותר אפליקציות להנות משרותי AWS מבלי לוותר על ביצועים.

אם הייתי צריך להמר על הפיתוח המשמעותי הבא עליו אמזון עובדים היום, הייתי הולך על Storage  מהיר, על מנת לפתור את בעיות ה – I/O מהן סובלות המערכות שלהם. רק תדמינו פתרון Storage עם קצבים להם אנחנו רגילים ממערכות Netapp, IBM או EMC בעולם הפיזי, כחלק מהשרות של AWS. אני ממש מחכה לזה.