המעבר לשימוש ב-Serverless ו-DevOps הוא תהליך שארגונים רבים מאד עוברים, ותוצאתו משפיעה על מיליוני עובדים במדינות רבות, וגם על מאות מיליוני משתמשי קצה. במאמר זה נסקור קייס סטאדי של חברת CitizenMe, שביצעה טרנספורמציה דיגיטלית. לחברה זו ישנם 200,000 לקוחות קצה ברחבי העולם, והיא עיבדה אינספור טרנזקציות מרגע הקמתה.
החברה משתמשת ב-AWS ובאפליקציות מובייל באופן אקסקלוסיבי עבור המוצרים והשירותים שהיא מציעה, ורוב הרכיבים בתשתית שלה נבנים ומתוחזקים בצורה פרטית על ידי צוות קטן של מפתחים וטסטרים.
המעבר לענן של AWS החל ב-2013, והארכיטקטורה של הפלטפורמה התבססה על EC2 ו-Elastic Beanstalk. עד אז, התשתיות והשירותים נבנו והוגדרו בצורה ידנית, מה שדרש מהצוות לבצע הפצות מבוססות גרסה באופן ידני ולעיתים רחוקות.
מיקוד
פרויקט המעבר התמקד במקור על ה-API של הפלטפורמה, אך במהרה המיקוד עבר גם לרכיבים האחרים, לרבות - שירותי רשת, אפליקציות רשת, שירותי דיווח והאתר עצמו.
הטרנספורמציה הובילה לשימוש ברכיבי ה-AWS Serverless הבאים:
• API Gateway
• CloudFront
• Lambda (Java, node.js, python)
• ECS Fargate/Docker (node.js)
• Application Load Balancer
• Aurora RDS for MySQL
• DynamoDB
• Quick Sight Business Intelligence & Reporting
• Cognito authentication
• AWS Auto Scaling
• CloudWatch Logs, Metrics, Alarms, Dashboards & Insights
• GuardDuty
• Trusted Advisor
• Web Application Firewall (WAF)
עם הזמן, המפתחים עברו ממתודה המבוססת על הפצת גרסאות ידנית, למתודה המבוססת על הפצה מחזורית, כזו שתשפר את יכולות הבדיקה, את האיכות ואת עמידות התוצרים. מתודה זו הובילה לאימוץ של AWS Code Pipeline עבור כל רכיב, כדי לבצע אוטומציה בהליך הפיתוח מה-Github Commit, זאת באמצעות הקמה ובדיקה של החשיפה הראשונה לסביבת הפרודקשן, באמצעות שילוח מתמשך בו כל Pipeline כלל שלבי פיתוח, טסטינג וייצור.
בכל שלבי התהליך, התקבל פידבק אשר יצר שיפורים נוספים והוביל לקוד ותיעודים איכותיים יותר, ונתגלו פרצות אבטחה תלויות קוד באמצעות שלדות כמו npm audit ו-Maven Dependency-Check.
בנוסף להליכים אלו נבחנו אזורים שאינם פונקציונאליים, כגון:
• שירותים ואפליקציות בג'אווה, ,node.js ופייתון עברו למודל של התחברות קונטקסטואלית, באמצעות שימוש ב-Thread Contexts של Java Apache Log4J 2. המידע שתועד כלל את ה-request ID של AWS, זמן ההתחלה והסיום (כולל זמן שימוש כולל), ניצול הזיכרון (גם לפי זמן התחלה וסיום) וה-call identifiers של ה-API. כך, ניתן היה לזהות ולטפל באינספור באגים ובעיות ביצועים ולבצע הליכים שיצמיחו את הארגון
• ביצוע סקיילינג אוטומטי של שירותי ECS Fargate שהתבסס על נתוני ה-CPU
• שימוש בערכים מותאמים אישית ב-CloudWatch עבור פרמטרים ספציפיים, שעזרו להבין את השימוש ברכיבים, הן מבחינת הקונטקסט הביצועי והן מבחינת הקונטקסט העסקי ברמת הנתונים (לדוגמא - פניות ל-API, תשלומים, התראות פוש, כשלים ועוד)
• התראות CloudWatch בכל הנוגע לכשלים ובעיות חיבור בלמבדה, כשל בבקשות ל-API Gateway והתראות לנתונים מותאמים אישית הקשורים לאופרציות חיוניות לארגון
• לוחות מחוונים של CloudWatch המרכזים את המידע העסקי והתפעולי החיוניים עבור אפליקציה או שירות,שניתן לשדר על מסך ציבורי
• שימוש ב-GuardDuty כדי לנתר ולהתריע על כל פעילות רשת , AWS או API חשודה
• דו"חות Trusted Advisor שמטרתם היא לסייע בזיהוי של בעיות הקשורות לעלויות, אבטחה, ביצועים, עמידות בפני תקלות, מגבלות בשירותים ועוד
• כל התראה נשלחה למחלקות הרלוונטיות באמצעות ערוצי סלאק כדי להתריע את המפתחים בזמן אמת
השפעה
התוצאות של כל אותם מהלכים ופעולות יצרו תמורות חיוביות רבות:
• המעבר ל-AWS Serverless הפחית את הנטל התפעולי עבור צוות הפיתוח ביותר מ-75%
• איכות האוטומציה, התיעוד, הנתונים וההתראות עלתה
• ארכיטקטורת צינורות המידע וה-Serverless העלימו את ההפסקות בהפצה
• הכנסת ה-DevOps הגבירה את המהירות של שינויים מסוימים בארגון פי 5
• זמן התגובה לבעיות השתפר לטיפול תוך מספר דקות או שעות, תלוי בדחיפות. בעבר זמן התגובה עמד על ימים ואף שבועות. חלק נכבד מהבעיות שאותרו, תוקנו וחזרו לסביבת הפרודקשן תוך פחות משעה.
• הפחתה ניכרת בכל הנוגע לבאגים חדשים בסביבת הפרודקשן, זאת בזכות העובדה שכל פיצ'ר ושינוי נמדדו בבידוד. כתוצאה מכך, פונקציית הטסט חיזקה את השקיפות הארגונית
• הפחתה של באגים קיימים בזכות מנגנוני תיעוד, פיקוח והתראה
• העלות התפעולית של AWS נשארה כמעט אותו דבר – זאת למרות שהארכיטקטורה הישנה שירתה 100,000 משתמשים בלבד, והחדשה הכפילה את מספרם
בנוסף לכך, נצפו שינויים נוספים בתרבות הארגונית: הצוות הטכני מתריע לארגון על בעיות במוצר לפני שמשתמשי הקצה עולים עליהן, ובכך שביעות הרצון שלהם עולה. יתרה מכך, לעסק ישנה הבנה טובה יותר בכל הנוגע לבקלוג ובעיות הקשורות ל-Data Pipelines, בשילוב של פרקטיקות אגיליות ושימוש ב-JIRA Board שהפכו לפשוטות יותר.
מאת: מערכת IsraelClouds
רוצים להתעדכן בתכנים נוספים בנושאי AWS? הירשמו עכשיו לניוזלטר שלנו ותמיד תישארו בעניינים > להרשמה
המעבר לשימוש ב-Serverless ו-DevOps הוא תהליך שארגונים רבים מאד עוברים, ותוצאתו משפיעה על מיליוני עובדים במדינות רבות, וגם על מאות מיליוני משתמשי קצה. במאמר זה נסקור קייס סטאדי של חברת CitizenMe, שביצעה טרנספורמציה דיגיטלית. לחברה זו ישנם 200,000 לקוחות קצה ברחבי העולם, והיא עיבדה אינספור טרנזקציות מרגע הקמתה.
החברה משתמשת ב-AWS ובאפליקציות מובייל באופן אקסקלוסיבי עבור המוצרים והשירותים שהיא מציעה, ורוב הרכיבים בתשתית שלה נבנים ומתוחזקים בצורה פרטית על ידי צוות קטן של מפתחים וטסטרים.
המעבר לענן של AWS החל ב-2013, והארכיטקטורה של הפלטפורמה התבססה על EC2 ו-Elastic Beanstalk. עד אז, התשתיות והשירותים נבנו והוגדרו בצורה ידנית, מה שדרש מהצוות לבצע הפצות מבוססות גרסה באופן ידני ולעיתים רחוקות.
מיקוד
פרויקט המעבר התמקד במקור על ה-API של הפלטפורמה, אך במהרה המיקוד עבר גם לרכיבים האחרים, לרבות - שירותי רשת, אפליקציות רשת, שירותי דיווח והאתר עצמו.
הטרנספורמציה הובילה לשימוש ברכיבי ה-AWS Serverless הבאים:
• API Gateway
• CloudFront
• Lambda (Java, node.js, python)
• ECS Fargate/Docker (node.js)
• Application Load Balancer
• Aurora RDS for MySQL
• DynamoDB
• Quick Sight Business Intelligence & Reporting
• Cognito authentication
• AWS Auto Scaling
• CloudWatch Logs, Metrics, Alarms, Dashboards & Insights
• GuardDuty
• Trusted Advisor
• Web Application Firewall (WAF)
עם הזמן, המפתחים עברו ממתודה המבוססת על הפצת גרסאות ידנית, למתודה המבוססת על הפצה מחזורית, כזו שתשפר את יכולות הבדיקה, את האיכות ואת עמידות התוצרים. מתודה זו הובילה לאימוץ של AWS Code Pipeline עבור כל רכיב, כדי לבצע אוטומציה בהליך הפיתוח מה-Github Commit, זאת באמצעות הקמה ובדיקה של החשיפה הראשונה לסביבת הפרודקשן, באמצעות שילוח מתמשך בו כל Pipeline כלל שלבי פיתוח, טסטינג וייצור.
בכל שלבי התהליך, התקבל פידבק אשר יצר שיפורים נוספים והוביל לקוד ותיעודים איכותיים יותר, ונתגלו פרצות אבטחה תלויות קוד באמצעות שלדות כמו npm audit ו-Maven Dependency-Check.
בנוסף להליכים אלו נבחנו אזורים שאינם פונקציונאליים, כגון:
• שירותים ואפליקציות בג'אווה, ,node.js ופייתון עברו למודל של התחברות קונטקסטואלית, באמצעות שימוש ב-Thread Contexts של Java Apache Log4J 2. המידע שתועד כלל את ה-request ID של AWS, זמן ההתחלה והסיום (כולל זמן שימוש כולל), ניצול הזיכרון (גם לפי זמן התחלה וסיום) וה-call identifiers של ה-API. כך, ניתן היה לזהות ולטפל באינספור באגים ובעיות ביצועים ולבצע הליכים שיצמיחו את הארגון
• ביצוע סקיילינג אוטומטי של שירותי ECS Fargate שהתבסס על נתוני ה-CPU
• שימוש בערכים מותאמים אישית ב-CloudWatch עבור פרמטרים ספציפיים, שעזרו להבין את השימוש ברכיבים, הן מבחינת הקונטקסט הביצועי והן מבחינת הקונטקסט העסקי ברמת הנתונים (לדוגמא - פניות ל-API, תשלומים, התראות פוש, כשלים ועוד)
• התראות CloudWatch בכל הנוגע לכשלים ובעיות חיבור בלמבדה, כשל בבקשות ל-API Gateway והתראות לנתונים מותאמים אישית הקשורים לאופרציות חיוניות לארגון
• לוחות מחוונים של CloudWatch המרכזים את המידע העסקי והתפעולי החיוניים עבור אפליקציה או שירות,שניתן לשדר על מסך ציבורי
• שימוש ב-GuardDuty כדי לנתר ולהתריע על כל פעילות רשת , AWS או API חשודה
• דו"חות Trusted Advisor שמטרתם היא לסייע בזיהוי של בעיות הקשורות לעלויות, אבטחה, ביצועים, עמידות בפני תקלות, מגבלות בשירותים ועוד
• כל התראה נשלחה למחלקות הרלוונטיות באמצעות ערוצי סלאק כדי להתריע את המפתחים בזמן אמת
השפעה
התוצאות של כל אותם מהלכים ופעולות יצרו תמורות חיוביות רבות:
• המעבר ל-AWS Serverless הפחית את הנטל התפעולי עבור צוות הפיתוח ביותר מ-75%
• איכות האוטומציה, התיעוד, הנתונים וההתראות עלתה
• ארכיטקטורת צינורות המידע וה-Serverless העלימו את ההפסקות בהפצה
• הכנסת ה-DevOps הגבירה את המהירות של שינויים מסוימים בארגון פי 5
• זמן התגובה לבעיות השתפר לטיפול תוך מספר דקות או שעות, תלוי בדחיפות. בעבר זמן התגובה עמד על ימים ואף שבועות. חלק נכבד מהבעיות שאותרו, תוקנו וחזרו לסביבת הפרודקשן תוך פחות משעה.
• הפחתה ניכרת בכל הנוגע לבאגים חדשים בסביבת הפרודקשן, זאת בזכות העובדה שכל פיצ'ר ושינוי נמדדו בבידוד. כתוצאה מכך, פונקציית הטסט חיזקה את השקיפות הארגונית
• הפחתה של באגים קיימים בזכות מנגנוני תיעוד, פיקוח והתראה
• העלות התפעולית של AWS נשארה כמעט אותו דבר – זאת למרות שהארכיטקטורה הישנה שירתה 100,000 משתמשים בלבד, והחדשה הכפילה את מספרם
בנוסף לכך, נצפו שינויים נוספים בתרבות הארגונית: הצוות הטכני מתריע לארגון על בעיות במוצר לפני שמשתמשי הקצה עולים עליהן, ובכך שביעות הרצון שלהם עולה. יתרה מכך, לעסק ישנה הבנה טובה יותר בכל הנוגע לבקלוג ובעיות הקשורות ל-Data Pipelines, בשילוב של פרקטיקות אגיליות ושימוש ב-JIRA Board שהפכו לפשוטות יותר.
מאת: מערכת IsraelClouds
רוצים להתעדכן בתכנים נוספים בנושאי AWS? הירשמו עכשיו לניוזלטר שלנו ותמיד תישארו בעניינים > להרשמה
לפרטים נוספים ויצירת קשר עם נציג אורקל
הודעתך לא התקבלה - נסה שוב מאוחר יותר