בדיקות והבטחת איכותMenu

Amazon CloudWatch - מעונן חלקית - חלק ב'

כיצד נכון לנטר את יישום האינטרנט של חברות מבוססות תשתיות ענן Amazon כחלק מתהליכי ה DevOps בארגון?

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

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

במאמר הזה אסקור 2 הדוחות הבאים-

 הדוח השני בסדרה הוא-

 Amazon Relational Database Service (RDS)- שירותי Amazon לבסיסי נתונים רלטיביים

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

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

• שימוש בדיסק Disk Usage – כשהתשתית והאפליקציה גדלה ומתפתחת, זה טבעי לצפות שגם מסדי הנתונים יתרחבו אף הם. מסדי נתונים יכולים לעלות בין 5GB  ל 3TB כך שהידיעה על ניצול השימוש לעומת מה שקנינו וכמה היישום שלנו צורך ומה קצב הגדילה, מאפשרת בצורה חסכונית לקנות מקום לפי שימוש ויכולת הרחבה לפני שמסדי הנתונים תופסים ניצול מרבי של מקום בדיסק.

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

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

הדוח השלישי הוא -

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

מוצר 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 הן ברמה המתודולוגית והן ברמת היישום.

 

עוד בנושא...

עוד פרסומים בנושא אשר עשויים לעניין אותך