מדריך ל-Azure App Service Plans: כיצד שכבות התמחור מגבילות תכונות ומשאבים

By Mirko Peters · 2026-10-21

גלו כיצד תוכניות Azure App Service ושכבות התמחור מגבילות תכונות, מנהלות משאבי מחשוב ומשפיעות על יכולת ההרחבה של אפליקציות אינטרנט וממשקי API.

Automatically translated with AI from the original post. Read the English original

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

עיקרי הדברים

• תוכנית Azure App Service היא חבילה של משאבי מחשוב שקובעת את מערכת ההפעלה, האזור, גודל המכונה, מספר המופעים ושכבת התמחור שלכם.
• שכבות התמחור פועלות כמנגנוני שער לתכונות ולא כשדרוגי גודל פשוטים, וחוסמות מאחורי דרגות מסוימות דומיינים מותאמים אישית, אישורי SSL, חריצי פריסה והרחבה אוטומטית.
• כל האפליקציות שנפרסו באותה תוכנית App Service חולקות בדיוק את אותו מאגר מחשוב בסיסי, ומתרחבות יחד ובו-זמנית.
• שכבות Free ו-Shared מטילות מגבלות קשיחות של דקות CPU יומיות וחסרות יכולות חיוניות כמו 'Always On', ולכן הן מתאימות רק להיכרות בסיסית עם המוצר.
• עומסי ייצור דורשים שכבת Basic ומעלה כדי לקבל מכונות ייעודיות, תמיכה בדומיינים מותאמים אישית והגנה מפני פסקי זמן של אפליקציה במצב לא פעיל.

אנטומיה של תוכנית App Service

כאשר מתחילים לפרוס אפליקציות אינטרנט וממשקי REST API בענן של Microsoft, האובייקט הראשון שיוצרים הוא תוכנית App Service. מפתחים רבים טועים לחשוב שהם רוכשים פשוט אירוח לאפליקציית אינטרנט אחת. בפועל, התוכנית היא המוצר המרכזי שרוכשים. היא פועלת כמאגר משותף של מכונות וירטואליות, וקובעת בבת אחת חמש החלטות יסוד: מערכת ההפעלה, האזור שבו נמצא הקוד, גודל הפיזי של המכונות, מספר המופעים הפעילים ושכבת התמחור.

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

שכבות תמחור כמנגנוני שער לתכונות

מתחילים רבים בענן רואים בסולם התמחור של Azure App Service, הנע מ-Free ו-Shared ועד Basic, Standard, Premium ו-Isolated, מדריך גודל פשוט שבו משלמים יותר עבור מכונה מהירה יותר. עם זאת, Microsoft מתייחסת לשכבות האלה בעיקר כאל מנגנוני שער לתכונות. מעבר לשכבה גבוהה יותר אינו רק מקצה זיכרון או עוצמת עיבוד נוספים; הוא גם משחרר באופן פעיל את היכולות שהארכיטקטורה שלכם צריכה כדי לפעול באופן מקצועי.

לדוגמה, שכבת Free מגבילה אתכם לאפליקציה אחת בכל תוכנית, מציבה תקרה של שישים או 240 דקות מעבד יומיות, מקצה גיגה-בייט אחד של זיכרון, וחוסמת לחלוטין שמות דומיין מותאמים אישית. האפליקציה שלכם חייבת להתגורר בכתובת ברירת המחדל azurewebsites.net. יתרה מכך, תכונות כמו חריצי פריסה, הרחבה אוטומטית וההגדרה הקריטית 'Always On', שמונעת מאפליקציות ווב לא פעילות להיכבות ולסבול מהפעלה קרה, נעולות מאחורי שכבות גבוהות יותר במערכת השכבות.

הבנת המלכודות של שכבות Free ו-Shared

שכבות Free ו-Shared תוכננו במפורש כהתנסות ולא כסביבת ייצור פונקציונלית. שישים או 240 דקות מעבד יומיות נשמעות נדיבות לאב טיפוס, אבל דף ווב עמוס או זרימת Power Automate אגרסיבית שפונה ל-REST API שלכם עלולים לנצל את התקציב הזה תוך שעות ספורות. יתרה מכך, שכבות התחתונות הללו אינן תומכות בהרחבה אופקית למספר מופעים, ולכן עומס מקבילי גבוה יגרום מיד להגבלת קצב (throttling) ולכשלי בקשות.

מעבר לשכבות מחשוב ייעודיות

כדי לבנות משהו עמיד ללקוח או לצוות פנימי, שכבת Basic היא הרף הפונקציונלי המינימלי המוחלט. Basic מציגה מכונות וירטואליות ייעודיות, שילוב דומיין מותאם אישית, תעודות TLS/SSL מנוהלות והגדרת 'Always On' למתג. ככל שמטפסים לשכבות Standard ו-Premium, נפתחות יכולות ארגוניות מתקדמות כמו חריצי פריסה לגרסאות ללא השבתה וכללי הרחבה אופקית אוטומטית.

הרחבה אנכית מול הרחבה אופקית

ניהול ביצועים ושיאי תעבורה דורש הבנה של ההבדל המהותי בין הרחבה אנכית להרחבה אופקית ב-Azure App Service. בלבול בין שני המושגים הוא מקור תדיר לבלבול ארכיטקטוני ולחשבונות ענן מנופחים.

הרחבה אנכית (Scale up) פירושה צמיחה אנכית: העברת תוכנית ה-App Service למכונה גדולה יותר או לשכבת תמחור גבוהה יותר, כדי לקבל עוצמת עיבוד גולמית רבה יותר ותכונות פלטפורמה נוספות. הרחבה אופקית (Scale out) פירושה צמיחה אופקית: הוספת עותקים זהים נוספים של מכונות הווירטואליות מאחורי אותה נקודת קצה, כך שבקשות HTTP נכנסות מתפזרות באופן שווה על פני מאגר גדול יותר.

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

סיכום

שליטה ב-Azure App Service דורשת לראות מעבר לפשטות של העלאת קוד, ולהבין את הכלכלה שמאחורי התוכניות והשכבות. כשמבינים שהתוכנית קובעת את התחרות על משאבים, את הגישה לתכונות ואת מגבלות ההרחבה, אפשר לתכנן ארכיטקטורות ענן עמידות שמתרחבות בחן וללא הפתעות בחיוב. בין אם מדובר בכלי פנימי, בצד שרת לאפליקציית מובייל או ב-APIs עבור Power Platform, בחירת השכבה הנכונה מהיום הראשון חוסכת שעות של refactoring בהמשך. האזינו לפרק המלא של M365 FM Podcast כדי לשמוע את הדיון המלא שלנו על הימנעות ממלכודות של מתחילים, ניהול חריצי פריסה ואופטימיזציה של סביבת הענן שלכם ב-Microsoft.

שאלות נפוצות

מהי תוכנית App Service של Azure?

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

מדוע תכונות מוגבלות לפי שכבות תמחור?

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

האם מספר אפליקציות יכולות לחלוק את אותה תוכנית App Service?

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

מה ההבדל בין הרחבה אנכית להרחבה אופקית?

הרחבה אנכית (Scale up) פירושה מעבר לגודל מכונה גדול יותר או לשכבת תמחור גבוהה יותר לקבלת עוצמה ותכונות נוספות, ואילו הרחבה אופקית (Scale out) מוסיפה עותקים זהים נוספים של האפליקציה שלכם כדי להתמודד עם נפחי תעבורה גבוהים יותר.