מאגרי חיבורים
בנושא הזה מוסבר איך מאגרי חיבורים פועלים ב-Bigtable, מה ההשפעות של גודל מאגר החיבורים על אפליקציה שמשתמשת ב-Bigtable ומתי כדאי לשנות את הגדרות ברירת המחדל של מאגר החיבורים.
אחרי שתקראו את הדף הזה, אם תחליטו שאתם צריכים לשנות את הגודל של מאגר החיבורים, תוכלו לעבור אל הגדרת מאגרי חיבורים כדי ללמוד איך לקבוע את הגודל האופטימלי ואיך לשנות אותו. אפשר להגדיר את מספר החיבורים בכל מאגר רק בקוד, כשמשתמשים בספריות הלקוח של Go, C++ או Java ל-Cloud Bigtable.
איך מאגרי חיבורים פועלים
מאגר חיבורים, שנקרא גם מאגר ערוצים, הוא מטמון של חיבורים למסד נתונים שמשותפים ונעשה בהם שימוש חוזר כדי לשפר את זמן האחזור של החיבורים ואת הביצועים. החיבורים משמשים במערכת סדר סיבובי.
כשמשתמשים ב-Bigtable, יוצרים לקוח נתונים יחיד לכל תהליך של אפליקציה. לכל לקוח יש מאגר חיבורים אחד. כל מאגר חיבורים מכיל מספר מסוים של חיבורי gRPC, וכל אחד מהם יכול לטפל בעד 100 זרמים בו-זמנית. בקשות שנשלחות דרך החיבורים האלה עוברות דרך תוכנת הביניים של Google, שמעבירה אותן לטבלה שלכם. שכבת התוכנה (middleware) מורכבת מהרבה מופעים עם איזון עומסים, וכל בקשה מנותבת דרך מופע התוכנה עם הזמינות הכי גבוהה.
אפשר לחשוב על חיבור (או ערוץ) כמו על כביש מהיר עם עד 100 נתיבים, וכל נתיב (סטרימינג) יכול להכיל רק מכונית אחת (בקשה) בכל זמן נתון. המגבלה של 100 סטרימינג בו-זמני לכל חיבור gRPC נאכפת בשכבת התוכנה של Google, ואין אפשרות להגדיר מחדש את המספר הזה.
החיבור מתרענן אוטומטית פעם בשעה. בנוסף, אם לא מתקבלת בקשה בחיבור במשך חמש דקות, תוכנת הביניים מוחקת את החיבור באופן אוטומטי ולא יוצרת אותו מחדש עד שנדרש חיבור נוסף.
מאחורי הקלעים, לכל ערוץ יש ערוץ משנה אחד. לכל ערוץ משנה יש חיבור HTTP2 שמשתמש ב-TCP כדי להמיר בקשות לבייטים ולשלוח אותן דרך תוכנת הביניים ואז לטבלה. התהליך הזה מתבצע בצורה חלקה על ידי שירות Bigtable, ואין צורך להגדיר שום דבר כדי שהוא יקרה.
איך מאגרי חיבורים משפיעים על הביצועים
מומלץ שיהיו לכם מספיק חיבורי gRPC כדי לטפל בבקשות בלי להשתמש במאגר זמני. עם זאת, לא מומלץ ליצור כל כך הרבה חיבורים שייפסקו לעיתים קרובות בגלל חוסר שימוש.
אין מספיק חיבורים
אם במאגר החיבורים אין מספיק חיבורים לטיפול בתנועה, תוכנת הביניים מתחילה לשמור בזיכרון ולתור בקשות. החיץ הזה מאט את התנועה, מפחית את מספר הבקשות לשנייה ומגדיל את זמן האחזור כשהבקשות מצטברות.
יותר מדי חיבורים
אם במאגר יש יותר מדי חיבורים, כלומר חלק מהחיבורים לא פעילים, תוכנת הביניים מנתקת את החיבורים הלא פעילים. אחר כך, כשיגיעו בקשות חדשות שדורשות את החיבורים האלה, הם יתחדשו. המשמעות היא שכשתעבורת הנתונים גדלה, בקשות עלולות להיתקל באי מציאה במטמון בצד השרת, מה שגורם לעבודה נוספת ולזמן אחזור. אם זה קורה לעיתים קרובות בגלל שינויים ברמות התנועה, הפעילות הזו יכולה להופיע כעלייה חדה בערך השהייה בזנב בצד הלקוח.
מתי כדאי לשנות את הגדרות ברירת המחדל
גודל ברירת המחדל של מאגר החיבורים מתאים לרוב האפליקציות, וברוב המקרים אין צורך לשנות אותו. יכול להיות שלא תהיה לכם אפשרות לשנות את גודל מאגר החיבורים, בהתאם לספריית הלקוח שבה אתם משתמשים באפליקציה. אפשר להגדיר את מספר החיבורים בכל מאגר בקוד רק כשמשתמשים בספריות הלקוח של Go, C++ או Java בשביל Cloud Bigtable.
ככלל, במאגר חיבורים אידיאלי יש לפחות פי שניים חיבורים מהמספר שנדרש לרוויה מקסימלית. כך יש מקום לתנודות בתעבורה. לדוגמה, אם יש לכם 4 חיבורים וכל אחד מהם מטפל במספר המקסימלי האפשרי של בקשות (100), ואתם רוצים להקטין את מספר הבקשות לכל חיבור למספר שבין 10 ל-50, אז גודל מאגר החיבורים האידיאלי הוא לפחות כפול מזה, כלומר לפחות 8 חיבורים.
האותות שמעידים שכדאי לשקול לשנות את מספר החיבורים במאגר כוללים את האותות הבאים:
תפוקה נמוכה בשילוב עם עליות פתאומיות בזמן האחרון של טעינת דף בצד הלקוח
אם קצב העברת הנתונים האופייני שלכם נמוך יחסית, למשל פחות מבקשה אחת לשנייה לכל חיבור, ואתם מבחינים בחביון גבוה מדי פעם באפליקציה, יכול להיות שאתם לא שולחים מספיק תנועה כדי שהחיבורים יישארו פעילים. במקרה כזה, יכול להיות שתצטרכו להקטין את מספר החיבורים במאגר. במאמר הגדרת מאגרי חיבורים מוסבר איך לקבוע את המספר הנכון.
בקשות במאגר
אם אתם רואים שהבקשות מצטברות בצד הלקוח, יכול להיות שאתם שולחים יותר בקשות בו-זמניות ממה שמאגר החיבורים יכול לטפל בו. מחשבים את המספר האופטימלי, ואז משנים את הקוד אם צריך.
כדי לבדוק אם יש הצטברות של בקשות, אפשר להשתמש ב-OpenCensus כדי לראות את ההבדל בין המדדים grpc.io/client/started_rpcs ו-grpc.io/client/completed_rpcs.
סביבה וירטואלית
במקרים נדירים, לקוח Bigtable לא מצליח לזהות את מספר המעבדים שהאפליקציה פועלת עליהם, ומקצה חיבורים כאילו רק מעבד אחד נמצא בשימוש. לדוגמה, זה יכול לקרות כשמשתמשים במכונות וירטואליות של CPU ב-Kubernetes או ב-Docker. אם זה ברור, צריך להגדיר את מספר המאגרים בהתאם להנחיות על סמך QPS והשהיה של האפליקציה.