Amazon CloudWatch – מעונן חלקית

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

סקרתי בו את הדו"ח EC2 – מחשוב ענן אלסטי, שהוא הראשון מבין חמשת הדו"חות המומלצים באמצעות CloudWatch.

במאמר זה אסקור את שני הדו"חות הבאים:

RDS (ר"ת Amazon Relational Database Service) – שירותי אמזון לבסיסי נתונים רלטיביים

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

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

●    שימוש בדיסק (Disk Usage) – כשהתשתית והאפליקציה גדלות ומתפתחות, אך טבעי לצפות שגם מסדי הנתונים יתרחבו. מסדי נתונים יכולים לעמוד על בין 5 ג'יגה-בייט ל-3 טרה-בייט, כך שהידיעה על ניצול השימוש לעומת מה שקנה הארגון, כמה היישום שלו צורך ומהו קצב הגדילה מאפשרת בצורה חסכונית לקנות מקום לפי שימוש ולהרחיב לפני שמסדי הנתונים תופסים ניצול מרבי של מקום בדיסק.

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

●    Read/Write Latency and Throughput – זהו מדד המציין מהי תפוקת הקריאה או הכתיבה הממוצעת במסד הנתונים של היישום. מדובר בדו"ח ברמת על שמדווח על השימוש באתר ותוך כמה זמן לוקח ליישום להחזיר שאילתות מתוך מסד הנתונים. הוא מספק מדידה ראשונית במסד הנתונים עצמו ויש להסתכל על המדידות ולבחון אותן ביחס ל-RDS.

ELB (ר"ת Elastic Load Balancer) – איזון עומסים בצורה אלסטית

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

●    Request Count – דו"ח שבפשטות וביעילות מספק תובנה מהו עומס התנועה שמקבלת מערכת העומסים, ומציג את מספר הבקשות שה-ELS קיבל והעביר למופעי EC2 – ומעבר לו. צפייה בדו"ח ובמגמה עוזרת להבין אם יש צורך להוסיף עוד מופעים של EC2 בצורה אוטומטית, בכדי לייצר איזון בעומסים ברמה של Auto Scale.

●    Latency, זמני תגובה – דו"ח שמראה את זמני התגובה של ה-ELB, המהווה אינדיקטור חזק לרמת הביצועים של היישום ומודד כמה זמן ובקשות Backend של היישום יזדקקו עד העיבוד. הוא מאפשר הבנה מעמיקה יותר על בעיות ביצועים שנובעות מהקוד.

●    Requests by Code – יש שתי רמות של בקשות קוד על ידי הקוד של ה-ELB וה-Backend, כאשר בקשות ELB נספרות כמה פעמים. מערכת איזון העומסים Load Balancer בעצמה מחזירה הודעות שגיאת קוד 4xx או 5xx, שמצביעות על בעיות באיזון עצמו או על עליות חדות בבקשות ELB ויכולת גיבוי ה-EC2. בקשות קוד על ידי ה-Backend מצביעות על שפיות מופע EC2, שיכולה להצביע על בעיית קוד או חוסר זמינות של היישום והמערכת.

בחלק הבא של המאמר אסקור את שני הדו"חות האחרונים ואסכם את השימוש ב-AWS CloudWatch.

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