✕ סגור 
צור קשר
תודה על ההתעניינות .

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form

שימוש ב-Serverless ו-DevOps יכול להיות משמעותי עבורכם

IsraelClouds
|
קלה
|
Dec 1, 2018
alt="facebook"alt="linkedin"להרשמה לניוזלטר

המעבר לשימוש ב-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? הירשמו עכשיו לניוזלטר שלנו ותמיד תישארו בעניינים > להרשמה

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
בואו נעבוד ביחד
support@israelclouds.com
צרו קשר