איך להרחיב את Elasticsearch כדי לפתור את בעיות הקיימות בגודל

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

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

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

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

הבנת ארכיטקטורת Elasticsearch לצורך קידומת

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

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

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

בעיקרון, האשכול Elasticsearch שלנו כלל מספר צמתים עבור המקרה של Swoo ושלושה צמתים ייעודיים למאסטר. כל צומת פעל על מעבד בן 8 ליבות עם 16 ג"ב RAM, בעיקר במטרה לאינדוקס בזמן אמת וחיפושים מיידיים של אירועי המשחקים המתרחשים. מכיוון שאנו עובדים בריבוי משתמשים גבוה, אנו צריכים להקדיש רוחב פס רשת משמעותי מאוד כדי להבטיח שהות מינימלית בין הצמתים.

תכנון אסטרטגיית ההתרחבות שלך

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

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

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

טכניקות גידול במהות

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

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

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

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

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

פתרונות מתקדמים להתרחבות

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

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

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

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

תובנות תיאורטיות והמרות ביצוע

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

גישה תיאורטית נוספת להרחבת ה-Elasticsearch היא מושג המקומיות של הנתונים. ניתן להריץ שאילתות רק נגד הצומת המקומי שמארח את הנתונים הרלוונטיים באמצעות פרמטר השאילתה preference=local. מינימיזציה זו על תקשורת בין צמתים ומורידה את לטנציות השאילתה. מאפיין הבחירה ברפליקה המותאמת של Elasticsearch מנסה לאופטימז את ביצוע השאילתות על ידי בחירת הצמת הטוב ביותר בתנאים הנוכחיים. עם זאת, זה לא בהכרח מביא לביצוע הכי יעיל של שאילתה.

הגל הראשון של כשלים שחווינו בסביבתנו מתייחס ללחץ גבוה על ה- JVM heap. שרתי Elasticsearch פעלו בהתחלה עם הקצאות heap מינימליות – תוצאתן הייתה מחזורי איסוף אשפה תדירים מאוד תחת עומס שאילתות גבוה. פתרנו זאת על ידי כיוון ה- JVM, בעיקר על ידי התאמת הקצאת ה- heap המינימלית והמקסימלית ל-8 ג'יגה-בייט, מה שנתן ל- Elasticsearch מספיק מקום לעיבוד שאילתות בלי לטעות את ה- heap.

גלגולים נפולים נפוצים ופתרונות

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

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

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

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

• כיוון מחדש של פרמטרי JVM. הגדרנו את Xms ו-Xmx ל-8 ג'יגה-בייט בכל שרת Elasticsearch, מוצאים איזון בין זיכרון המערכת הזמין ודרישות ה-heap.
• אופטימיזציה של הפצת השארדים. אינדקסים גדולים חולקו לשארדים בגודל קטן יותר כדי למנוע נקודות חמות וכדי להתרחק מכך קיימת מעליות של שארדים לאינדקסים הפעילים ביותר. זה הבטיח שתעבורת השאילתות תופצה באופן אחיד בכל האשכול.
• אפשרות למערכת מטמון עם זמן חי קצר. החלטנו על חלון מטמון של שנייה על שאילתות סטטיות נפוצות בדף הבית ושמרנו על זהות בזמן אמת זאת הביאה להפחתת העומס על Elasticsearch עבור בקשות חוזרות בלי לאבד את התגובה בזמן אמת.
• ניטור ושינויים רצופים. השתמשנו ב-Kibana, עם מספר לוחות בקרה מותאמים אישית לצפייה בזמן אמת של בריאות השארדים, ביצועי ה-JVM ואיחורי השאילתות. בהתבסס על המדדים הללו, בוצעו כיוונים מדויקים באופן רציף.

תוכניות עתידיות או הרחבות בטכנולוגיות

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

מסקנה

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

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