הגדרת OpenSearch: היכן החיפוש נשבר לאחר המיגרציה
הדבר הראשון שנשבר בעת העברת אשכול החיפוש הוא לא החיפוש עצמו, אלא האמון בו: תוצאות החיפוש מתחילות להחזיר מוצרים של אתמול, הפילטרים מוצאים דברים לא נכונים, וחלק מהמסמכים נעלמים מהתוצאות.
הסיבה כמעט תמיד אחת — חוסר סנכרון של האינדקסים: העברת הנתונים מתבצעת בנפרד מהעברת ההגדרות, והאשכול חי במשך זמן מה עם מחצית מהכללים. אם לא שמים לב לכך מיד, הפער מספיק לעבור לפרודקשן ולצוף כבר אצל משתמשים חיים.
התקלה הטיפוסית השנייה היא ירידה במהירות תוצאות החיפוש לאחר המעבר. באשכול הישן השרדים היו מסודרים בהתאם לפרופיל השאילתות האמיתי, ואילו בחדש הם פוזרו "כברירת מחדל": אגרגציות כבדות מתחילות להתחרות בשאילתות ממוקדות, וזמן התגובה גדל פי כמה על אותה חומרה.
בנפרד צפים מיפויים לא תואמים של שדות: במקום שבו קודם היה keyword להתאמה מדויקת, מתגלה text עם פיצול למילים — ומיון לפי מחיר או מק"ט מפסיק לעבוד כראוי.
השכבה השלישית — אנלייזרים ושרשראות נרמול שאבדו. מורפולוגיה רוסית, מילים נרדפות, טיפול בשגיאות כתיב ומילות עצירה חיים בקונפיגורציה של האשכול, ולא בנתונים, ובעת מיגרציה מ-Elasticsearch קל לא להעביר אותם.
כלפי חוץ החיפוש עובד, אבל "кроссовки" מפסיק למצוא "кроссовок", ומותגים עם מקף נופלים מהפילטרים. בדיוק בשלב הזה הלקוח לרוב מגלה שהעבירו נתונים, ולא את לוגיקת החיפוש.
אנחנו מתחילים בספירת מלאי: מתעדים את המיפויים, האנלייזרים ותבניות האינדקס האמיתיים, משווים אותם לקונפיגורציה היעד, ורק לאחר מכן מתכננים את ההעברה. לאחר מכן — מעבר מבוקר עם בדיקה על תעבורה בצל. להלן נפרט כיצד כל אחד מהכשלים הללו נסגר בשלב הגדרת OpenSearch.
מה נותן קלאסטר חיפוש מוגדר נכון
זמן התגובה מפסיק להיות תלוי בנפח הנתונים
הגדרה נכונה של שרדינג ורפליקות — זה כאשר החיפוש מחזיר תוצאה תוך עשרות מילישניות גם כאשר הקטלוג גדל פי כמה. אנו מתאימים את מספר השרדים לנפח האמיתי ולפרופיל השאילתות, ולא "כברירת מחדל": חלוקה שגויה היא הסיבה הנפוצה ביותר לכך שהקלאסטר מתחיל להאט ללא סיבה נראית לעין. בנפרד אנו מגדירים מטמון (cache) לפילטרים ולאגרגציות, כדי ששאילתות חוזרות לא יחושבו מחדש.
אינדוקס מחדש מתבצע בצורה צפויה וללא השבתה
שינוי מיפוי או מבנה מסמך לא צריך להפוך לסיוט לילי עם עצירת החיפוש. אנו מגדירים אליאסים ומעבירים את התעבורה לאינדקס החדש באופן אטומי — הישן נשאר זמין עד לרגע שהחדש מוכן. טעינה מקבילה באמצעות פעולות bulk עם גודל מנה מותאם שומרת על עומס אחיד על הקלאסטר, ולא בפיקים.
הקלאסטר שורד כשל של צומת ללא אובדן נתונים
רפליקות והגדרות פיזור השרדים מספקות עמידות בפני כשלים: כאשר צומת נופל, החיפוש ממשיך לעבוד, והנתונים משוחזרים אוטומטית. אנו בודקים זאת בכוונה — מכבים צומת בסביבת בדיקה ובוחנים כיצד הקלאסטר מפזר מחדש את העומס. שלמות האינדקסים מאומתת על ידי השוואת מספר המסמכים לפני ואחרי הכשל.
שלמות האינדקסים נמצאת תחת שליטה
אנו מגדירים בדיקות מצב של הקלאסטר והתראות על סטטוס "צהוב" ו"אדום", כדי שדגרדציה לא תישאר unnoticed. צילומים (snapshots) קבועים של האינדקסים מספקים נקודת שחזור, ולא תקווה למזל. כתוצאה מכך החיפוש עובד ביציבות, והצוות לומד על הבעיה לפני המשתמשים.
אפשרויות פריסה: ענן, שרתים עצמאיים, היברידי
בחירת הפלטפורמה קובעת לא רק את השהיית הבקשות, אלא גם מי אחראי לכשל של שרד בשעה שלוש לפנות בוקר. להלן שלושה מודלים של פריסת אשכול חיפוש והמגבלות האמיתיות שלהם מבחינת עומס, תחזוקה ועלות בעלות.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| חיפוש מנוהל בענן | אין צוות תפעול פנימי, העומס צפוי, נדרש אתחול מהיר | פחות שליטה על הגרסה ועל פרמטרי JVM-кучи, עליית התשלום עם הגדלת מספר הצמתים ונפח האינדקסים, תלות בספק |
| אשכול עצמאי על שרתים (on-premise) | הנתונים אינם אמורים לצאת מהמתחם, פרופיל עומס יציב, קיימים מהנדסים | הוצאות הון על חומרה וגיבוי, אתם מטפלים בעצמכם בעדכונים, גיבויים, ניטור והחלפת דיסקים |
| תצורה היברידית | נתונים ובקשות חמים בענן, ארכיון ואינדקסים רגישים — במתחם שלכם | רשת וסנכרון snapshots מורכבים יותר, נדרש שכבה אחודה לניתוב בקשות וניטור משותף |
מה באמת משנה את התמונה
חיפוש מנוהל מסיר מהצוות את השגרה: עדכוני אבטחה, שכפול, snapshots לאחסון אובייקטים — בצד הספק. משלמים על כך בפחות חופש בכיוונון עדין של שרדינג ובתקרה לגודל האשכול.
On-premise נותן שליטה מלאה על פריסת האינדקסים, גודל ה-heap ומדיניות מחזור חיים, אך דורש תורנות ומלאי חומרה לשיא. ההיברידי מכסה את שני התרחישים, אם בונים נכון את השכפול בין המתחמים.
אנו פורסים אשכול בהתאם לפרופיל עומס ספציפי ומתעדים במסמכים מה עובר לספק ומה נשאר על הצוות שלכם.
שלבי יישום והגדרה של OpenSearch
העבודה מתבצעת בשלבים עוקבים: כל שלב נשען על התוצרים של השלב הקודם, ולכן דילוג על כל צעד עולה לפני השטח כבר בעומס או בפרודקשן. להלן הסדר שבו אנו מובילים את הפרויקט מהאודיט ועד להעברת הקלאסטר לצוות שלכם.
- אודיט של קלאסטר החיפוש. אנו מתעדים את המצב הנוכחי: אילו אינדקסים ואליאסים קיימים, כיצד בנויים המיפויים, היכן מצטברים שדות שאינם בשימוש, כיצד מפוזרים השארדים והרפליקות בין הצמתים, ואילו שאילתות יוצרות את עיקר העומס. בפלט — מפת צווארי בקבוק ורשימה של מה שמועבר כפי שהוא ומה שמעוצב מחדש.
- תכנון סכמת האינדקסים. אנו מפרסים את הנתונים בין אינדקסים ואליאסים כך שאינדוקס מחדש והחלפת הגדרות לא ידרשו עצירת החיפוש. מגדירים תבניות, מחזור חיים של אינדקסים ומדיניות שמירה — נתונים ישנים עוברים לפי לוח זמנים, והחמים נשארים מהירים.
- הגדרת מנתחים. אנו בונים שרשראות טוקניזציה ופילטרים בהתאם לשפה ולאופי השאילתות: צורות מילים, מילים נרדפות, שגיאות כתיב, מורפולוגיה. בודקים על ביטויי חיפוש אמיתיים מהלוגים, ולא על נתונים סינתטיים, — אחרת המנתח עובד יפה בבדיקה ומתפרק בתעבורה חיה.
- העברת נתונים ושאילתות. מעבירים אינדקסים ומשכתבים שאילתות ואגרגציות שאינן תואמות, תוך השוואת הפלט שורה אחר שורה. אי-התאמות מתעדים לפני המעבר, ולא אחריו.
- בדיקת עומס. מריצים פרופיל של תעבורה אמיתית עם שיאים: בודקים זמן תגובה באחוזונים, התנהגות בעת כשל של צומת, ומהירות התאוששות של שארדים. בוחרים את מספר השארדים והרפליקות לפי המצב בפועל, ולא לפי נוסחה מהתיעוד.
- פריסה וניטור. מגדירים את הקלאסטר בפרודקשן, אוספים מטריקות על השהיות, כשלים וצריכת משאבים, ומקימים התראות על דרדור.
- העברה לתפעול. מוסרים נהלים, סכמות והוראות לפעולות שגרתיות — הצוות שלכם ממשיך לנהל את הקלאסטר בעצמו.
תארו את המשימה שלכם — נחזור עם הערכה ותוכנית לפי השלבים האלה.
הרשאות גישה, תפקידים והפרדת זכויות
ב-OpenSearch הפרדת הזכויות בנויה על שלוש רמות: הרשאות ברמת האשכול, הרשאות על אינדקסים והרשאות על מסמכים. תפקיד הוא אוסף הרשאות בעל שם שמוקצה למשתמש או לחשבון שירות. הרשאות ברמת האשכול אחראיות על ניהול האשכול עצמו: תמונות מצב, הגדרות, ניטור.
הרשאות ברמת האינדקס — על קריאה, כתיבה, מחיקה וניהול של אינדקסים או תבניות ספציפיים. הפרדה זו מאפשרת להעניק לשירות כתיבה רק לאינדקס שלו ולא לאפשר לו לשנות את מצב האשכול.
תבניות הרשאות לאינדקסים מוגדרות באמצעות מסכות: logs-app-* עבור האפליקציה, logs-search-* עבור שירות החיפוש. מסכה מכסה קבוצת אינדקסים שלמה בבת אחת, כולל עתידיים — אין צורך לכתוב מחדש את התפקיד עם כל אינדקס חדש.
בתרחישים מרובי דיירים הזכויות מצטמצמות עד לרמת המסמכים באמצעות שאילתת סינון: המשתמש רואה רק את הרשומות שלו, למרות שמבחינה פיזית הכול נמצא באינדקס אחד.
ביקורת הפעולות מופעלת ברמת האשכול וכותבת אירועי גישה לאינדקס נפרד. ליומן נכנסים: מי, מתי, לאיזה אינדקס פנה ובאיזו תוצאה. זה נותן בסיס לחקירת אירועים ולאימות עמידה בדרישות — נראית לא רק העובדה של סירוב, אלא גם ניסיונות לעקוף הרשאות.
בנפרד מוגדרים תפקידי שירות: עבור תמונות מצב, עבור ניטור, עבור שכפול בין אשכולות. אותם מקצים לא לאנשים, אלא לחשבונות שירות עם תוקף מוגבל. רוטציה של חשבונות כאלה מתבצעת לפי לוח זמנים, ולא ידנית — אחרת ההרשאות מועתקות בין צוותים ומפסיקות להגביל דבר.
הניסיון מלמד: בלי מודל תפקידים מפורש האשכול הופך במהירות ל"כולם רואים הכול". אנחנו מתחילים במיפוי השירותים, עבור כל אחד מתעדים את מערך ההרשאות המינימלי הנדרש, ורק לאחר מכן מפעילים ביקורת — אחרת היומן יתמלא ברעש מהרשאות מיותרות.
מה הלקוח מקבל לאחר הגדרת האשכול
לאחר הגדרת האשכול הלקוח מקבל לא "חיפוש עובד", אלא סט שלם של ארטיפקטים שלפיהם ניתן להפעיל את המערכת, להרחיב אותה ולהעביר אותה לצוות אחר בלעדינו. להלן מה בדיוק נשאר במאגר ובמסמכים.
- תצורת האשכול — קבצי הגדרות של צמתים ותפקידים, פרמטרים של שרדינג ורפליקציה, מדיניות פיזור השרדים בין אזורי זמינות. הפריסה משוחזרת מתוך קבצים אלה, ולא "לפי הזיכרון של המהנדס".
- סכמת האינדקסים — תיאור האינדקסים, התבניות שלהם והקשרים ביניהם: אילו שדות מנותחים, אילו נשמרים כפי שהם, היכן מיושמים מילים נרדפות וכללי ניתוח טקסט. הסכמה מתעדת מדוע החיפוש מוצא את הנדרש, ולא רק "ככה זה הוגדר".
- מדיניות מחזור חיים — כללים לרוטציה של אינדקסים ותמונות מצב: כמה נתונים מחזיקים בשכבה החמה, מתי מעבירים לשכבה הקרה, באיזו תדירות נלקחים גיבויים וכמה שומרים. המרשם מפסיק לגדול ללא בקרה, והיכולת לחזור למצב קודם נשמרת.
- נוהל תחזוקה — סדר העבודות המתוכננות: עדכון צמתים ללא השבתה, בדיקת בריאות האשכול, תגובה להתמלאות הדיסק ולעלייה בהשהיות השאילתות. איתו התורן מבין מה לעשות, בלי להתקשר למפתח.
- ניטור והתראות — סט מדדים למצב האשכול וספים שמהם נשלח אות: השהיית חיפוש, תור שאילתות, מצב השרדים, מקום פנוי. הבעיה נראית לפני שהמשתמש מבחין בה.
- תיעוד החיפוש — מפת האינדקסים, מילון השדות, דוגמאות לשאילתות טיפוסיות וניתוח של תקלות נפוצות. מהנדס חדש נכנס לפרויקט לפיו, ולא לפי התכתבות.
- נוהל הגירה — תוכנית שלב-אחר-שלב למעבר ממנוע החיפוש הקודם: סדר המיתוג, בדיקת שלמות הנתונים, נקודת החזרה. ההגירה מתבצעת בלי לעצור את השירות למשתמשים.
הסט הזה הוא התוצאה של ההגדרה: את האשכול ניתן לפתח, להרחיב ולתחזק בכוחות הצוות שלכם. תארו את המשימה שלכם — נחזור עם הערכה ותוכנית עבודה.
במה שונה התצורה של OpenSearch מ-Elasticsearch?
רשמית OpenSearch הוא פורק של Elasticsearch, וה-API הבסיסי של חיפוש ואינדוקס תואם: שאילתות _search, _bulk, מיפויים ומנתחים מועברים ללא כתיבה מחדש. אבל תאימות אינה משמעה זהות, וההבדלים בולטים דווקא ברמת התצורה, ולא ברמת קוד האפליקציה.
ההבדל המרכזי הוא מודל הרישוי והרכב התוספים. ב-OpenSearch security, alerting, anomaly detection, SQL ו-dashboards כלולים באספקה ומוגדרים כברירת מחדל, בעוד שב-Elasticsearch חלק מהיכולות הללו נמצאות במנוי בתשלום נפרד.
עבור התצורה המשמעות היא: תפקידים, הרשאות על אינדקסים ומדיניות גישה מתוארים באותם קבצים, אך מופעלים כברירת מחדל, ויש להגביל אותם באופן מודע, ולא לרכוש אותם בנפרד.
השני — ניהול האשכול. הגדרות של שרדינג, רפליקציה ומדיניות lifecycle מוגדרות בתחביר דומה, אך שמות הפרמטרים וההתנהגות של חלק מהתוספים נפרדו לאחר פיצול הפרויקטים.
העברה ישירה של elasticsearch.yml ותבניות אינדקס «כפי שהם» מייצרת פערים שקטים: חלק מהאפשרויות מתעלמות מהן, וחלק משנות את התנהגות הסגמנטים ומהירות המיזוגים.
בעת מיגרציה אנחנו מעבירים לא קבצים, אלא את המשמעות של ההגדרות: משווים מיפויים ומנתחים, בונים מחדש תבניות אינדקס, בודקים את פעולתם של תוספי החיפוש ורק לאחר מכן מעבירים את התעבורה. כך העברת ההגדרות אינה הופכת להפתעה בפרודקשן.
מקרה בוחן: העברת חיפוש ללא השבתת השירות
הפרויקט — מרקטפלייס עם קטלוג של כמה מיליוני מוצרים: החיפוש והפאסטים התבססו על Elasticsearch, ואשכול של כמה צמתים פעל תחת עומס מתמיד. האינדוקס בשיא חפף לתעבורת הבוקר, ובשעות אלו החיפוש החל להחזיר תשובות באיחור, וחלק מהשאילתות עברו לזמן קצוב.
כאב נפרד — עדכון המיפוי: אינדוקס מחדש של הקטלוג ארך שעות, וכל אותו זמן היה צורך להחזיק שני אינדקסים ולהחליף אליאס ידנית.
מה עשינו
פרסנו אשכול יעד במקביל לאשכול הפעיל והגדרנו שכפול כך ששניהם יחזיקו מערך נתונים זהה. את האינדוקס העברנו דרך תור: תחילה כותבים לאשכול הנוכחי, ואחר כך מנגנים את אותם אירועים לאשכול החדש — פערים מתגלים באמצעות השוואה לפי סכומי ביקורת של מסמכים.
את התעבורה החלפנו לא בבת אחת, אלא במנות: תחילה אחוז קטן של שאילתות קריאה, לאחר מכן מחצית, ולבסוף כל הזרימה. בכל שלב השווינו מדדי חיפוש — שיעור השאילתות האיטיות, זמן התגובה ועומס על האשכול.
מה השתנה
ההחלפה ארכה דקות ועברה ללא השבתה: המשתמשים לא הבחינו בהחלפת המנוע. שיעור השאילתות החורגות מזמן התגובה היעד ירד בערך פי שלושה, והעומס בשיא על האשכול הפסיק להיתקע בתקרה — חלק מהקריאה עבר לרפליקות.
זמן ההתאוששות לאחר כשל בצומת הצטמצם מעשרות דקות ליחידות: הרפליקות עולות אוטומטית, ואין צורך בהתערבות ידנית.
את החזרה לאחור תכננו מראש — האשכול הישן נשאר פעיל עד סוף הניטור, וניתן היה לחזור אליו באותה החלפה של מנות תעבורה.
נדון במשימה שלכם להגדרת חיפוש
הגדרת חיפוש היא משימה שבה מחיר הטעות נראה מיד: מיפוי שגוי או סכימת שרדינג לא מוצלחת מתגלים לא על אינדקס בדיקה, אלא על תעבורה חיה, כאשר אינדוקס מחדש אורך שעות.
לכן אנחנו מתחילים לא מהקונפיגורציה, אלא מניתוח התרחיש שלכם: אילו נתונים ובאיזה נפח מאונדקסים, אילו שאילתות קריטיות מבחינת מהירות, האם נדרשת תמיכה במורפולוגיה ובמילים נרדפות, וכיצד בנויה התוצאה היום.
כדי שהשיחה תהיה עניינית, שלחו את הנתונים הראשוניים — לפיהם המהנדסים שלנו יבנו תוכנית עבודה והערכת הגדרה:
- סטאק החיפוש הנוכחי וגרסת הענף (Elasticsearch או OpenSearch), נפח האינדקסים והגידול היומי בנתונים;
- רשימת שאילתות טיפוסיות עם דוגמאות ודרישות לזמן תגובה;
- סכימת הקלאסטר: מספר צמתים, תפקידים, מרווח משאבים, קיום רפליקות;
- כיצד בנויה טעינת הנתונים — מקורות, תדירות עדכון, האם נדרש אינדוקס מחדש אינקרמנטלי;
- דרישות לדירוג: בוסטים לפי שדות, מילים נרדפות, מילות עצירה, השלמה אוטומטית;
- מגבלות גישה, גיבוי וחלונות תחזוקה;
- מה כבר ניסיתם והיכן עצרתם, אם המיגרציה או ההגדרה תקועה.
לפי הנתונים האלה נחזור עם תוכנית: שלבים, סדר העברת התעבורה, נקודות rollback, הרכב העבודה למיגרציה מ-Elasticsearch ולפריסה. ייעוץ מהנדס בשלב הזה הוא לא שיחה כללית, אלא ניתוח של סכימת האינדקסים שלכם וצווארי הבקבוק של התוצאה. תארו את המשימה בפורמט נוח — נחזור עם הערכה ותוכנית עבודה.