הגדר את שירות Amazon OpenSearch לזמינות גבוהה | שירותי האינטרנט של אמזון

הגדר את שירות Amazon OpenSearch לזמינות גבוהה | שירותי האינטרנט של אמזון

חותמת זמן: 31 במאי 2023 12:56
צומת המקור: 2691649

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

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

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

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

תצורת אשכול

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

פריסה מרובה-AZ

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

מנהל אשכולות ייעודי (צמתי מאסטר)

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

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

ספירת מקרים גודל RAM של צומת מנהל אשכולות ספירת רסיסים מרבית נתמכת סוג מופע מינימלי מומלץ של מנהל אשכולות ייעודי
1-10 8 ג'יב 10,000 m5.large.search או m6g.large.search
11-30 16 ג'יב 30,000 c5.2xlarge.search או c6g.2xlarge.search
31-75 32 ג'יב 40,000 c5.4xlarge.search או c6g.4xlarge.search
76 - 125 64 ג'יב 75,000 r5.2xlarge.search או r6g.2xlarge.search
126 - 200 128 ג'יב 75,000 r5.4xlarge.search או r6g.4xlarge.search

אינדקסים ורסיסים

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

ניטור וניהול אשכולות

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

ניצול CPU

אתה משתמש במעבד שבדומיין שלך כדי להפעיל את עומס העבודה שלך. ככלל, עליך למקד ניצול מעבד ממוצע של 60% עבור כל צומת נתונים, עם שיאים של 80%, ולסבול קוצים קטנים עד 100%. כשחושבים על זמינות, ובמיוחד בהתחשב באי-זמינות של אזור מלא, ישנם שני תרחישים. אם יש לך שני אזורי זמינות, אז כל אזור מטפל ב-50% מהתנועה. אם אזור הופך ללא זמין, האזור השני ייקח את כל התעבורה הזו, ויכפיל את ניצול ה-CPU. במקרה זה, אתה צריך להיות בסביבות 30-40% ניצול מעבד ממוצע בכל אזור כדי לשמור על זמינות. אם אתה מפעיל שלושה אזורי זמינות, כל אזור לוקח 33% מהתנועה. אם אזור לא יהיה זמין, כל אחד מהאזורים האחר יקבל תנועה של כ-17%. במקרה זה, עליך למקד 50-60% ניצול מעבד ממוצע.

ניצול זיכרון

OpenSearch Service תומך בשני סוגים של איסוף אשפה. הראשון הוא איסוף אשפה G1 (G1GC), המשמש את צמתי OpenSearch Service, המופעל על ידי AWS Graviton 2. השני הוא Concurrent Mark Sweep (CMS), המשמש את כל הצמתים המופעלים על ידי מעבדים אחרים. מתוך כל הזיכרון שהוקצה לצומת, מחצית מהזיכרון (עד 32 GB) מוקצה לערמת Java, ושאר הזיכרון משמש משימות אחרות של מערכת ההפעלה, מטמון מערכת הקבצים וכן הלאה. כדי לשמור על זמינות עבור דומיין, אנו ממליצים לשמור על ניצול מקסימלי של JVM בסביבות 80% ב-CMS ו-95% ב-G1GC. כל דבר מעבר לזה ישפיע על הזמינות של הדומיין שלך ויהפוך את האשכול שלך לא בריא. אנו ממליצים גם להפעיל כוונון אוטומטי, המנטר באופן פעיל את ניצול הזיכרון ומפעיל את אוסף האשפה.

ניצול אחסון

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

AWS גם ממליצה לבחור ספירת רסיס ראשונית כך שכל רסיס יהיה בטווח גודל אופטימלי. אתה יכול לקבוע את גודל הרסיס האופטימלי באמצעות בדיקת הוכחת מושג עם הנתונים והתעבורה שלך. אנו משתמשים בגדלי רסיס ראשוני של 10–30 GB למקרי שימוש בחיפוש ובגדלים של 45–50 GB ראשיים עבור מקרי שימוש בניתוח יומנים כקו מנחה. מכיוון שרסיסים הם העובדים בדומיין שלך, הם אחראים ישירות לחלוקת עומס העבודה על פני צמתי הנתונים. אם הרסיסים שלך גדולים מדי, ייתכן שתראה לחץ בערימת ה-Java שלך מהצטברויות גדולות, ביצועי שאילתות גרועים יותר וביצועים גרועים יותר במשימות ברמת אשכול כמו איזון מחדש של רסיסים, תמונות מצב והגירות חמות לחום. אם הרסיסים שלך קטנים מדי, הם יכולים להציף את שטח ה-Java Heap של הדומיין, להחמיר את ביצועי השאילתות באמצעות רשתות פנימית מוגזמת, ולהפוך משימות ברמת האשכול לאט. כמו כן, אנו ממליצים לשמור את מספר הרסיסים לצומת פרופורציונלי לערימה הזמינה (מחצית מזיכרון ה-RAM של המופע עד 32 ג'יגה-בייט) - 25 רסיסים לכל ג'יגה-בייט של ערימת Java. זה מהווה מגבלה מעשית של 1,000 רסיסים בכל צומת נתונים בדומיין שלך.

סיכום

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

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

על המחברים

רוהין בהרגבה הוא מנהל מוצר אב בצוות שירות ה-OpenSearch של Amazon. התשוקה שלו ב-AWS היא לעזור ללקוחות למצוא את התמהיל הנכון של שירותי AWS כדי להשיג הצלחה עבור המטרות העסקיות שלהם.

פרשנט אגראוול הוא ארכיטקט פתרונות חיפוש מומחה ב-Amazon OpenSearch Service. הוא עובד בשיתוף פעולה הדוק עם לקוחות כדי לעזור להם להעביר את עומסי העבודה שלהם לענן ועוזר ללקוחות קיימים לכוונן את האשכולות שלהם כדי להשיג ביצועים טובים יותר ולחסוך בעלויות. לפני שהצטרף ל-AWS, הוא עזר ללקוחות שונים להשתמש ב-OpenSearch ו-Elasticsearch עבור מקרי השימוש שלהם בחיפוש ובניתוח יומנים. כשלא עובד, אתה יכול למצוא אותו מטייל וחוקר מקומות חדשים. בקיצור, הוא אוהב לעשות Eat → Travel → Repeat.

בול זמן:

עוד מ AWS Big Data