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

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

הדו"ח הרביעי והמומלץ הוא Dynamo

Dynamo הוא שירות של אמזון (Amazon) לבסיסי נתונים NoSQL/ יש למדוד CPU ברמת היישום ולא ברמת בסיס הנתונים הבודד. להלן הפרמטרים שיש לפקח עליהם:

•    Read/Write Capacity Units – קיבולת צריכה של יחידות קריאה וכתיבה.

ה-Dynamo מתנהג כמו תוכנה כשירות (SaaS), כאשר הדאגה היחידה של מנהלי האופרציה (Devops) היא למדוד את יחידת הקיבולת/יכולת של הקריאה והכתיבה לבסיס הנתונים.

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

•    Throttled Requests – דו"ח שמציג:
o    כמה בקשות קריאה וכתיבה יש ב-Backlog בכל תקופה.
o    מאפשר לצפות באמצעות הסעיף הקודם את כמות הקריאות והכתיבות, וכך להגדיל את הקיבולת של מספר הקריאות והכתיבות לתקופה.
o    ברמת היישום – ניתן לראות באמצעותו כמה בקשות היישום שולח ל-Dynamo ובכך לווסת את הכמות, בכדי לא לגרום לביצועים להיעשות גרועים יותר.

•    Successful Request Latency – חביון בקשה מוצלח – מודד בפרק זמן מסוים את כמות הבקשות המוצלחות וכמה זמן בממוצע לוקח להן לחזור. מדד זה מעיד על השפיות והמהירות של בסיס הנתונים כאשר הוא לא חנוק. כך Dynamo מבצע בקרה על העבודה היומית שנעשית על ידי היישום.

הדו"ח האחרון הוא שירות התור SQS (ר"ת Amazon Simple Queue Service)

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

על כן, נחוץ לפקח על הפרמטרים הבאים:

•    Approximate Number of Messages Visible – מספר משוער של הודעות גלויות. הודעה גלויה היא כל הודעה שנוצרה על ידי משאב בסביבה מבוזרת וטרם נקראה על ידי משאב הצרכן. הדו"ח מתאר את מספר ההודעות בשלב הראשון בתהליך.

•    Approximate Number of Messages Not Visible – מדד המספק מספר משוער של הודעות שאינן גלויות. מדובר בכל הודעה שנוצרה על ידי משאב בסביבה מבוזרת, נקראה על ידי משאב הצרכן ואושרה על ידו, אך משאב הצרכן טרם מחק אותה מהתור.

•    Approximate Number of Messages Delayed – מספר משוער של הודעות מושהות. לפעמים אנחנו מעצבים את המערכת כך שתוכל לעכב הודעות לפרק זמן מסוים לאחר שנשלחו אך לפני שנמסרו למשאב צרכני. CloudWatch עוקב אחריהן ומגדיר אותן כהודעות מושהות.

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

AWS CloudWatch מהווה, אפוא, נקודת זינוק מצוינת להבטיח שהיישום הפרוש בענן של אמזון פועל כראוי ומנוטר על פני הרמות השונות. הדו"חות שניתן להפיק ממנו מאפשרים לגלות – ובהקדם – בעיות ביצועים ברמות השונות. בשילוב של Agents ,CollectID ו-CloudWatch ניתן להפיק דו"חות עם מדדים שונים, ששומרים על שפיות המערכת.

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

באמצעות ה-Dashboard תוכלו להגדיר התראות מובנות על בעיה מסוימת, באמצעות התראות שיישלחו אליכם ישירות מהמערכת, ולבצע פעולות מסוימות בהתאם למדדים שבחרתם להגדיר, עם סף גבוה או נמוך.

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