Cloud Run או Fargate: אפס שרתים פעילים עולה בזמן תגובה

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

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

מה משתנה כשאין תעבורה

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

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

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

התפרצות חושפת שני זמני המתנה שונים

ההשוואה שפרסמה 72Technologies מתארת שני שירותי API דומים ב-Node.js, אצל לקוחות שונים עם דפוסי תנועה דומים. הכותבים מדווחים על התנעה קרה של כ-700 מילישניות עד 1.5 שניות ב-Cloud Run, ועל 45–90 שניות מהתפרצות ועד שמשימת Fargate נוספת נכנסה לשירות מאחורי מאזן עומסים. אלה מדדים שונים: הראשון מתאר בקשה שפוגשת מופע קר, והשני את זמן הרחבת הקיבולת של שירות שכבר פועל. הם אינם מבחן מבוקר של אותו יישום באותם תנאים, ולכן אינם הבטחת ביצועים לשירות אחר.

ההבדל חשוב במיוחד כשהעומס עולה מהר ונמשך מעט זמן. משימת Fargate שכבר רצה יכולה לטפל בתחילת ההתפרצות, אבל רק עד גבול הקיבולת שלה; משימות חדשות עשויות להגיע אחרי שחלק מהשיא חלף. Cloud Run יכול לפתוח מופעים נוספים בתגובה לבקשות, אך פתיחה מהירה מגדילה גם את מספר החיבורים שהיישום יוצר למסד נתונים או לשירות חיצוני. מספר המופעים המרבי וערך ה-concurrency צריכים להתאים גם לקיבולת של אותן מערכות.

מה בדיוק נכנס למחיר

לצורך דוגמה מותנית נחשב חודש של 30 ימים, קונטיינר Linux/x86 עם vCPU אחד ו-2 GiB זיכרון, ללא הנחת התחייבות. מחירון Fargate נותן בדוגמת צפון וירג'יניה 0.000011244 דולר לשניית vCPU ועוד 0.000001235 דולר לשניית GiB זיכרון. החיוב מתחיל בהורדת תמונת הקונטיינר, מסתיים עם סיום המשימה, מעוגל לשנייה וכולל מינימום של דקה. אחסון זמני נוסף, כתובת IPv4 ציבורית ותעבורה עשויים להוסיף חיוב.

מחירון Cloud Run משייך את אזור תל אביב לדרגת המחיר הראשונה: בחיוב לפי בקשות, זמן פעיל עולה 0.000024 דולר לשניית vCPU, זיכרון פעיל עולה 0.0000025 דולר לשניית GiB, ומיליון בקשות עולות 0.40 דולר לפני השכבה החינמית. השכבה כוללת זיכוי חודשי המחושב ברמת חשבון החיוב; לפי מחירי הדרגה הראשונה הוא שקול ל-180 אלף שניות vCPU פעילות, ל-360 אלף שניות GiB ולשני מיליון בקשות. כמה בקשות יכולות לחלוק מופע באמצעות concurrency, ותעבורה יוצאת מחויבת בנפרד.

אלה מחירים מאזורים שונים: צפון וירג'יניה ב-AWS ותל אביב ב-Google Cloud. החישוב מדגים כיצד דפוס העומס משפיע על החיוב, ולא קובע איזו פלטפורמה זולה יותר לפריסה בישראל. הוא מניח בקשה אחת בכל פעם לכל מופע, בלי זמן התנעה, כיבוי, עיגול נוסף של בקשות קצרות או שימוש אחר בשכבה החינמית. אם היישום מטפל בבקשות במקביל על אותו מופע, מספר שניות המופע ב-Cloud Run עשוי לרדת.

שלושה דפוסי עומס באותו חישוב

• שירות דליל: נניח 100 אלף בקשות בחודש, שכל אחת מעסיקה מופע במשך 0.2 שניות, ללא חפיפה. מתקבלות 20 אלף שניות מופע. רכיבי העיבוד והבקשות ב-Cloud Run עולים כ-0.62 דולר לפני השכבה החינמית, ואפס בדוגמה שבה כל הזיכוי פנוי. משימת Fargate אחת שפועלת במשך כל 720 שעות החודש עולה כ-35.55 דולר ברכיבי המעבד והזיכרון. ההפרש מלווה באפשרות שהבקשה הראשונה אחרי שקט תמתין להתנעה.
• התפרצויות קצרות: נניח עשר התפרצויות בחודש, כל אחת בת עשר דקות, בקצב של עשר בקשות בשנייה ובמשך טיפול של שנייה לבקשה. מתקבלות 60 אלף שניות מופע ב-Cloud Run, בעלות של כ-1.76 דולר לפני הזיכוי ואפס אחריו בדוגמה. ב-Fargate, משימה אחת הפועלת כל החודש ועוד תשע משימות שפועלות רק במשך ההתפרצויות עולות יחד כ-36.29 דולר בעיבוד. זהו גבול חישובי שמניח שהמשימות הנוספות מוכנות ברגע שההתפרצות מתחילה; המתנה לעלייתן משנה את זמן התגובה ואת כמות הבקשות שיוכלו לשרת בשיא.
• עומס רציף: נניח בקשה בכל שנייה לאורך כל החודש, כשכל בקשה מעסיקה מופע לשנייה. 2.592 מיליון שניות המופע והבקשות עולות ב-Cloud Run כ-76.20 דולר לפני השכבה החינמית וכ-70.18 דולר אחריה, אם הזיכוי כולו פנוי. משימת Fargate יחידה הפועלת ברציפות עולה כ-35.55 דולר ברכיבי המעבד והזיכרון. כאן אין שעות אפס שמעניקות יתרון לחיוב לפי שימוש, אך התוצאה תלויה במשך העיבוד וביכולת לחלוק מופע בין בקשות.

תעבורה ותפעול יכולים להפוך את ההפרש

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

המורכבות התפעולית שונה אף היא. ב-Cloud Run, ההתאמה לביקוש היא חלק מהשירות, אבל בחירת מינימום ומקסימום מופעים ו-concurrency קובעת כמה עבודה תגיע לכל מופע וכמה חיבורים ייפתחו למערכות שמאחוריו. ב-Fargate במסגרת ECS צריך להגדיר את מספר המשימות, את מדדי ההרחבה והצמצום ואת הדרך שבה התעבורה מגיעה למשימות מוכנות. ככל שהשירות חייב להגיב מיד אחרי שעות שקטות, כך עולה ערכה של קיבולת שמורה בשתי האפשרויות.

איך לבחור לפי השירות המיועד

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

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