בדף הזה נסקור את דפוסי הארכיטקטורה הנפוצים ביותר לפריסה באירוח בצד הלקוח, ונתאר את השיטות המומלצות להטמעה שלהם. כדי להשתמש בדף הזה בצורה יעילה, כדאי להכיר את המושגים והשיטות שקשורים לארכיטקטורת מערכות.
אסטרטגיה של תהליך העבודה
אחרי שמזהים שאירוח עצמי הוא אפשרות מעשית להטמעה של Looker, השלב הבא הוא לפרט את האסטרטגיה שתופעל על ידי הפריסה.
- עורכים הערכה. זיהוי רשימת מועמדים של תהליכי עבודה מתוכננים וקיימים.
- רשימת דפוסי ארכיטקטורה רלוונטיים. מתחילים בתהליכי העבודה המועמדים שזוהו ומזהים דפוסי ארכיטקטורה רלוונטיים.
- קובעים סדר עדיפויות ובוחרים את תבנית הארכיטקטורה האופטימלית. התאמת דפוס הארכיטקטורה למשימות ולתוצאות החשובות ביותר.
- הגדרת רכיבי הארכיטקטורה ופריסת אפליקציית Looker. מטמיעים את המארח, את התלויות בצד שלישי ואת טופולוגיית הרשת שנדרשים כדי ליצור חיבורים מאובטחים של לקוחות.
אפשרויות ארכיטקטורה
מכונה וירטואלית ייעודית
אפשרות אחת היא להריץ את Looker כמופע יחיד במכונה וירטואלית (VM) ייעודית. מופע יחיד יכול לשרת עומסי עבודה תובעניים על ידי שינוי גודל אנכי של המארח והגדלת ברירות המחדל של מאגרי השרשורים. עם זאת, תקורה העיבוד של ניהול ערימת Java גדולה גורמת לכך שההגדלה האנכית כפופה לחוק התפוקה השולית הפוחתת. בדרך כלל, זה מתאים לעומסי עבודה קטנים עד בינוניים. בתרשים הבא מוצגות ההגדרות שמוגדרות כברירת מחדל וההגדרות האופציונליות בין מופע Looker שפועל במכונה וירטואלית ייעודית, המאגרים המקומיים והמרוחקים, שרתי ה-SMTP ומקורות הנתונים שמודגשים בקטעים יתרונות ושיטות מומלצות של האפשרות הזו.
יתרונות
- קל להטמיע ולתחזק מכונה וירטואלית ייעודית.
- מסד הנתונים הפנימי מתארח באפליקציית Looker.
- אפשר להגדיר את הרכיבים של מודלים של Looker, מאגר Git, שרת SMTP ומסד נתונים של קצה עורפי באופן מקומי או מרחוק.
- אתם יכולים להחליף את שרת ה-SMTP שמוגדר כברירת מחדל ב-Looker בשרת משלכם כדי לקבל התראות באימייל ולתזמן משימות.
שיטות מומלצות
- כברירת מחדל, Looker יכול ליצור repositories של Git לפרויקט. מומלץ להגדיר מאגר Git מרוחק לצורך יתירות.
-
כברירת מחדל, Looker מתחיל עם מסד נתונים של HyperSQL בזיכרון. מסד הנתונים הזה נוח וקל משקל, אבל עלולות להיות בו בעיות בביצועים כשיש בו שימוש רב. מומלץ להשתמש במסד נתונים של MySQL לפריסות גדולות יותר. מומלץ לבצע העברה למסד נתונים מרוחק של MySQL ברגע שגודל הקובץ
~/looker/.db/looker.scriptמגיע ל-600MB. - הפריסה של Looker תצטרך לעבור אימות מול שירות הרישוי של Looker. נדרשת תנועה יוצאת ביציאה 443.
- אפשר להרחיב פריסה ייעודית של מכונה וירטואלית באופן אנכי על ידי הגדלת המשאבים הזמינים ומאגרי השרשורים של Looker. עם זאת, הגדלת ה-RAM כפופה לחוק התפוקה השולית הפוחתת ברגע שהיא מגיעה ל-64GB, כי אירועי מנגנון איסוף הם חד-הברגה ועוצרים את כל השרשורים האחרים כדי לבצע אותם. צמתים עם 16 מעבדים ו-64GB של RAM הם איזון טוב בין מחיר לביצועים.
- מומלץ שפריסת האחסון תכלול 2 פעולות קלט/פלט (IOPS) לשנייה לכל GB.
אשכול של מכונות וירטואליות
הפעלת Looker כאשכול של מופעים בכמה מכונות וירטואליות היא דפוס גמיש שמאפשר מעבר אוטומטי לשירות חלופי ויתירות. מדרגיות אופקית מאפשרת תפוקה מוגברת מבלי להיתקל בתפיסת ערימה גדולה ועלויות איסוף אשפה מוגזמות. לצמתים יש אפשרות להקצאת עומס עבודה, שמאפשרת להתאים כמה אפשרויות פריסה לדרישות עסקיות שונות. פריסות של אשכולות מחייבות לפחות אדמין מערכת אחד שמכיר מערכות לינוקס ויכול לנהל את חלקי הרכיבים.
אשכול רגיל
ברוב הפריסות הרגילות, מספיק להשתמש באשכול של צמתי שירות זהים. כל הצמתים באשכול מוגדרים באותו אופן ונמצאים כולם באותו מאגר של איזון עומסים. אף אחד מהצמתים בהגדרה הזו לא יהיה סביר יותר או פחות שישמש לבקשות של משתמשי Looker, למשימת עיבוד, למשימה מתוזמנת, לבקשת API וכו'.
הגדרה כזו מתאימה כשרוב הבקשות מגיעות ישירות ממשתמש Looker שמריץ שאילתות ומבצע אינטראקציות עם Looker. הוא מתחיל להתפרק כשמספר גדול של בקשות מגיע ממתזמן, ממעבד או ממקור אחר. במקרה כזה, כדאי להקצות צמתים מסוימים של שירות לטיפול במשימות כמו תזמון ועיבוד.
לדוגמה, משתמשים בדרך כלל מתזמנים את מסירת הנתונים ליום שני בבוקר. משתמש שמנסה להריץ שאילתות ב-Looker בבוקר יום שני עלול להיתקל בבעיות בביצועים בזמן ש-Looker מטפל בבקשות המתוזמנות שהצטברו. הגדלת מספר צמתי השירות מאפשרת לאשכול לספק שיפור יחסי בנפח התפוקה בכל היכולות של Looker.
הדיאגרמה הבאה מתארת איך בקשות ל-Looker שמוגשות על ידי המשתמש, אפליקציות וסקריפטים מתחלקות באופן שווה בין מופע Looker מקובץ.
יתרונות
- קלאסטר רגיל ממקסם את התפוקה הכללית עם הגדרה מינימלית של טופולוגיית הקלאסטר.
- הביצועים של מכונת Java וירטואלית יורדים כשהזיכרון המוקצה מגיע ל-64GB. לכן, הרחבה אופקית מניבה תוצאות טובות יותר מהרחבה אנכית.
- הגדרת אשכול מבטיחה יתירות של השירות ומעבר לגיבוי במקרה של כשל.
שיטות מומלצות
- כל צומת Looker צריך להיות מאוחסן במכונה וירטואלית ייעודית משלו.
- מאזן העומסים, שהוא נקודת הכניסה לאשכול, צריך להיות מאזן עומסים ברמה 4. צריך להגדיר לו זמן קצוב לתפוגה ארוך (3,600 שניות), לצייד אותו באישור SSL חתום ולהגדיר העברה ליציאה אחרת מ-443 (HTTPS) ל-9999 (היציאה שבה שרת Looker מאזין).
- מומלץ שהפריסה תכלול אחסון עם 2 פעולות קלט/פלט בשנייה (IOPS) לכל GB.
פיתוח/העברה לבדיקה/ייצור
בתרחישי שימוש שבהם חשוב להבטיח זמינות מקסימלית של התוכן למשתמשי הקצה, מומלץ להשתמש בסביבות Looker נפרדות כדי להפריד בין עבודת הפיתוח לבין עבודת הניתוח. הארכיטקטורה הזו שומרת על סביבת ייצור יציבה ככל האפשר, כי שינויים בסביבת הייצור מוגבלים על ידי סביבות פיתוח ובדיקה מבודדות.
כדי ליהנות מהיתרונות האלה, צריך להגדיר את הסביבות המקושרות ולאמץ מחזור פרסום חזק. פריסה של Dev/Staging/Prod דורשת גם צוות של מפתחים שמכירים את Looker API ואת Git לניהול תהליכי עבודה.
בתרשים הבא מוצג זרימת התוכן בין מפתחי LookML שמפתחים תוכן במופע הפיתוח, בודקי בקרת איכות (QA) שבודקים את התוכן במופע בקרת האיכות, ומשתמשים, אפליקציות וסקריפטים שצורכים את התוכן במופע הייצור.
יתרונות
- אימות של LookML ותוכן מתבצע בסביבה שאינה סביבת ייצור, כדי להבטיח שכל שינוי בלוגיקה של המודל ייבדק ביסודיות לפני שהוא מגיע למשתמשי הייצור.
- אפשר לבדוק תכונות שחלות על כל המופע, כמו תכונות בגרסת טרום-השקה או פרוטוקולי אימות, בנפרד לפני שמפעילים אותן בסביבת הייצור.
- אפשר לבדוק קבוצות נתונים ומדיניות שמירה במטמון בסביבה שאינה סביבת ייצור.
- בדיקות במצב הפקה ב-Looker מופרדות מסביבות הפקה שאחראיות על הצגת תוכן למשתמשי קצה.
- אפשר לבדוק את הגרסאות של Looker בסביבה שאינה סביבת ייצור, וכך יש מספיק זמן לבדוק תכונות חדשות, שינויים בתהליכי העבודה ובעיות לפני שמעדכנים את סביבת הייצור.
שיטות מומלצות
- לבצע את הפעילויות השונות שמתרחשות בו-זמנית לפחות בשלושה מקרים נפרדים:
- מופע פיתוח: מפתחים משתמשים בסביבת הפיתוח כדי לבצע קומיטים של קוד, לערוך ניסויים, לתקן באגים ולבצע טעויות בצורה בטוחה.
- מופע QA: נקרא גם סביבת בדיקה או העברה לבמה. כאן המפתחים מריצים בדיקות ידניות ואוטומטיות. סביבת בקרת האיכות מורכבת ויכולה לצרוך הרבה משאבים.
- מופע ייצור: כאן נוצר ערך ללקוחות או לעסק. סביבת הייצור היא סביבה שגלויות בה הרבה פעולות, ולכן היא צריכה להיות נקייה משגיאות.
- שמירה על תהליך עבודה של מחזור הפצה מתועד וניתן לחזרה.
- אם יש צורך לשרת נפחים גדולים של מפתחים ובודקי QA, אפשר לאגד את מופעי הפיתוח ו/או ה-QA. בין אם מדובר במכונה וירטואלית עצמאית או באוסף של מכונות וירטואליות, המופעים של הפיתוח והבדיקה כפופים לאותם שיקולים ארכיטקטוניים שהוצגו קודם בקטעים הרלוונטיים.
תפוקה גבוהה של קביעת פגישות
בתרחישי שימוש שבהם נדרשת תפוקה גבוהה של מסירת נתונים מתוזמנת ומסירות בזמן ואמינות, מומלץ שההגדרה תכלול אשכול עם מאגר של צמתים שמוקדשים אך ורק לתזמון. ההגדרה הזו תעזור לשמור על מהירות התגובה של האתרים והאפליקציות המוטמעות. כדי ליהנות מהיתרונות האלה, צריך להגדיר צמתים עם אפשרויות הפעלה מותאמות אישית וכללי איזון עומסים מתאימים, כפי שמתואר בתרשים הבא ומפורט בקטעים יתרונות ושיטות מומלצות של האפשרות הזו.
יתרונות
- הקצאת צמתים לפונקציה ספציפית מאפשרת להקצות משאבים לתזמון מפיתוח ולפונקציות ניתוח אד-הוק.
- המשתמשים יכולים לפתח LookML ולנתח תוכן בלי להשתמש במחזורי עיבוד מהצמתים שאחראים על אספקת נתונים מתוזמנת.
- תנועת משתמשים גבוהה שמנותבת לצמתים הרגילים לא מפריעה לעומסי עבודה מתוזמנים שמטופלים על ידי צמתים לתזמון.
שיטות מומלצות
- כל צומת Looker צריך להיות מאוחסן במכונה וירטואלית ייעודית משלו.
- מאזן העומסים, שהוא נקודת הכניסה לאשכול, צריך להיות מאזן עומסים ברמה 4. צריך להגדיר לו זמן קצוב לתפוגה ארוך (3,600 שניות), להשתמש באישור SSL חתום ולהגדיר העברה ליציאה אחרת מ-443 (HTTPS) ל-9999 (היציאה שבה שרת Looker מאזין).
- אל תכללו צמתים של מתזמן בכללי איזון העומסים, כדי שהם לא ישרתו תנועה של משתמשי קצה ובקשות פנימיות ל-API.
- מומלץ שהפריסה תכלול אחסון עם 2 פעולות קלט/פלט בשנייה (IOPS) לכל GB.
תפוקת עיבוד גבוהה
בתרחישי שימוש שבהם נדרשת תפוקה גבוהה של עיבוד דוחות, מומלץ להגדיר אשכול עם מאגר של צמתים שמוקדשים רק לעיבוד. רינדור של קובץ PDF או של תמונה בפורמט PNG או JPEG הוא פעולה שדורשת יחסית הרבה משאבים ב-Looker. רינדור יכול לצרוך הרבה זיכרון ומעבד, וכשמערכת Linux נמצאת במצב של עומס זיכרון, היא עשויה להפסיק תהליך שפועל. מכיוון שאי אפשר לקבוע מראש את השימוש בזיכרון של עבודת רינדור, הפעלת עבודת רינדור עלולה לגרום להפסקת התהליך של Looker. הגדרת צמתים ייעודיים לעיבוד תאפשר לכם לבצע אופטימיזציה של משימות העיבוד, וגם לשמור על מהירות התגובה של האפליקציה האינטראקטיבית והמוטמעת.
כדי ליהנות מהיתרונות האלה, צריך להגדיר צמתים עם אפשרויות הפעלה מותאמות אישית וכללי איזון עומסים מתאימים, כפי שמתואר בתרשים הבא ומוסבר בקטעים יתרונות ושיטות מומלצות בנושא האפשרות הזו. בנוסף, יכול להיות שצמתים של עיבוד תמונה ידרשו יותר משאבי מארח מצמתים רגילים, כי שירות העיבוד של Looker תלוי בתהליכי Chromium של צד שלישי שמשתפים זמן CPU וזיכרון.
יתרונות
- הקצאת צמתים לפונקציה ספציפית מאפשרת להפריד בין משאבים לעיבוד נתונים מפונקציות פיתוח וניתוח אד-הוק.
- המשתמשים יכולים לפתח LookML ולעיין בתוכן בלי להשתמש במחזורי העיבוד של הצמתים שאחראים על עיבוד קובצי PNG ו-PDF.
- תנועת משתמשים גבוהה שמנותבת לצמתים הרגילים לא מפריעה לעומסי עבודה של רינדור שמטופלים על ידי צמתים של רינדור.
שיטות מומלצות
- כל צומת Looker צריך להיות מאוחסן במכונה וירטואלית ייעודית משלו.
- מאזן העומסים, שהוא נקודת הכניסה לאשכול, צריך להיות מאזן עומסים ברמה 4. צריך להגדיר לו זמן קצוב לתפוגה ארוך (3,600 שניות), להשתמש באישור SSL חתום ולהגדיר העברה ליציאה אחרת מ-443 (HTTPS) ל-9999 (היציאה שבה שרת Looker מאזין).
- משמיטים צמתי עיבוד מכללי איזון העומסים, כדי שהם לא ישרתו תנועה של משתמשי קצה ובקשות פנימיות ל-API.
- מקצים יחסית פחות זיכרון ל-Java בצמתי העיבוד כדי לתת לתהליכים של Chromium מאגר זיכרון גדול יותר. במקום להקצות 60% מהזיכרון ל-Java, מקצים 40-50%.
- הסיכון למחסור בזיכרון הופחת בצמתים שאינם צמתי עיבוד, ולכן אפשר להגדיל את כמות הזיכרון שמוקצה ל-Looker. במקום 60% שמוגדרים כברירת מחדל, כדאי להגדיר מספר גבוה יותר כמו 80%.
- מומלץ שהפריסה תכלול אחסון עם 2 פעולות קלט/פלט בשנייה (IOPS) לכל GB.