הסבר על IOPS
Latency
פרקי ההרצאה: הסבר על IOPS Latency
תמלול ההרצאה: הסבר על IOPS Latency
הטקסט המלא של הדקות הראשונות בהרצאה «הסבר על IOPS Latency» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
אז אנחנו ממשיכים עם הנושא של Storage Performance וכשאנחנו מדברים על Performance, על ביצועים, אנחנו צריכים לדבר על כמה פרמטרים שחוזרים על עצמם וצריך להבין אותם.
הדבר הראשון, המטריקס שקשורים ל-Storage זה בדרך כלל IOPs, אני אסביר מה זה, בלוק סייז, טרופוט, שגם לפעמים אנשים מבלבלים את זה עם בנווית' טרופוט ו-disk latency.
אלה הם המטריקס, הפרמטרים, המאפיינים שאתם צריכים להבין כשאתם באים לבחור סטורג' לאפליקציה מסוימת. כשאנחנו מדברים על אי-אופס, אי-אופס זה המצב שבו האפליקציה כותבת לדיסק או קוראת מהדיסק, ואי-אופס זה המספר פעמים שהאפליקציה צריכה לכתוב או לקרוא מהדיסק.
בלוק סייז זה הגודל של הבלוקים שהאפליקציה כותבת לדיסק. הבלוקים האלה בדרך כלל הם 4 קילו בייט, 8, 16K. זה בדרך כלל הבלוק סייז שאנחנו בוחרים עבור אפליקציה מסוימת בדיסק.
אתם צריכים לשאול את מי שביקש לכם להתקין את אותה אפליקציה, או מי שביקש לכם את הסטורג' לאותה אפליקציה, אתם צריכים לשאול אותו כמה אי-אופס האפליקציה שלך הולכת לדרוש, אותו דייטאבייס, אותו אפליקציה שרצה, כמה אי-אופס האפליקציה שלך דורשת.
איי-אופס יכול להיות באלפים, בדרך כלל זה באלפים, שלושת אלפים, ארבעת אלפים, חמש מאות, שבעת אלפים, שמונים אלף, בדרך כלל זה באלפים.
אפליקציה, לדוגמה, מקבלת הרבה משתמשים, הרבה משתמשים משתמשים באותה אפליקציה, והמשתמשים מבצעים המון פעולות, למשל מערכת בנקאית בדרך כלל תדרוש המון איי-אופס.
מי שגולש באתר אינטרנט, ברוב המקרים גלישה רגילה באיזשהו אתר, ברוב המקרים לא דורש, לא מייצר הרבה איופס. בלוק סייז זה כשהמערכת כותבת לדיסק באיזה גודל של בלוק המערכת כותבת, מה החתיכות של המידע שהמערכת שמה על הדיסק. יש לזה חשיבות מאוד מאוד מאוד גדולה.
איך יראה הפרופורמנט, הביצועים של המערכת? כלומר, אני יכול לשנות את הביצועים של המערכת על ידי שינוי של הבלוק סייז. טרופוט זה כמה מידע אני יכול לשים על אותו צינור, על אותו רשת, על אותו מנגנון שכותב את המידע לדיסק או קורא את המידע לדיסק.
ובסוף, בסוף, בסוף, המושג שכולם, מה שנקרא, חוששים מפניו או כולם רוצים לדעת מה יהיה התוצאה, זה הדבר שנקרא Disc Latency. Disc Latency, אני בא ושואל, כמה זמן לקח לאפליקציה לכתוב מידע ולקבל מידע מהדיסק?
טרופוט נמדד במגה בייט ולייטנסי נמדד במילי סקנד אוקיי מאוד מאוד חשוב להבין את הנושא הזה יש לנו את האי-אופס שבדרך כלל יהיה לנו הוא יהיה בדרך כלל באלפים שלושת אלפים ארבעים אלף שישים אלף אי-אופס זה אינפוט אאוטפוט בשנייה בלוק סייז בדרך כלל נמדד בקילו בייט ארבע שמונה שש עשרה שלושים ושתיים טרופוט בדרך כלל נמדד במגה בייט ולייטנסי בדרך כלל נמדד במיליסקונס.
אז למשל אני יכול להגיד לכם המערכת שלי אני צריך שתביאו לי דיסק בבקשה ואתם שואלים איזה דיסק אתה צריך אז אני אומר אני צריך דיסק בגודל של 2 טרה בייט זה הגודל כמובן אבל שתדעו המערכת שלי עושה 50 אלף איופס 50 אלף איופס מה הגודל של הבלוק סייז אנחנו עושים 8 קילו בייט אני עכשיו יש פורמולה אני אוכל להגיד לכם מה הטרופות שהמערכת שלך דורשת
אחרי שאתה תפעיל את האפליקציה ואני אתן לך דיסק שיודע לעמוד ב-30,000 אי-אופס ויודע לתת לך 300 מגה-בייט של בנוויץ', אתה תוכל להפעיל את האפליקציה ולמדוד באפליקציה כמה זמן היא מחכה לתגובה של הדיסק.
לחכות לתגובה של הדיסק נמדד במיליסקנד, אוקיי? 5 מיליסקנד, 2 מיליסקנד, 20 מיליסקנד. אתם צריכים גם להבין שכשאנחנו בוחרים דיסקים, לכם שלדיסקים השונים יש יכולות אי-אופס שונות.
אז כבר פה אני בעצם אומר לכם, אני מגלה לכם את הסוד שאם לקוח בא ואומר אני צריך 20,000 אי-אופס, אתם לא תיתנו לו דיסק HDD מן הסתם. אם לקוח אומר שהוא צריך 80,000 אי-אופס אני לא אתן לו ssd אני אתן לו nvme, שימו לב. אז כבר עכשיו בקלות אתם מבינים שכשהלקוח דורש x, y, z של אי-אופס אתם
תצטרכו לתת לו דיסק שמתאים לאפליקציה. 3,000 עד 40,000 איופס, NVME, 60,000 250,000 איופס, HDD איופס מודדים 50 עד 200 איופס.
וכשבחרתם את הדיסק ללקוח, נגיד שהוא ביקש 50,000 איופס או 100,000 איופס, אז נתתם לו דיסק NVME, יופי, מה עכשיו?
עכשיו יכול להיות שהוא ישאל אתכם, מה לגבי ה-Banwidth? אני צריך, מה לגבי הטרופות? סליחה, אני צריך טרופות מסוים. איך אתם מודדים את הטרופות?
הם חייבים לשאול אותו מה בלוק סייז. אני נותן לך 50,000 איופ דיסק שמאפשר 50,000 איופס, אבל בהתאם לבלוק סייז אני אוכל להגיד לך מה אתה מקבל בטרופוט.
ככל שהחבילה גדולה יותר, אני יכול לתת לך יותר טרופוט. אבל מה לעשות? ככל שהטרופוט גדל, ככה הכמות של האיופס שלך יקטנו, וככה זה גם ישפיע על הלייטנסי שלך.
אז הדבר הקל ביותר לעשות זה לשאול את הלקוח עצמו: כמה איופס המערכת שלך דורשת? וכמה טרופות המערכת שלך דורשת ואם הוא לא יודע את התשובה אתם תיתנו לו את הדיסק שאתם חושבים שהוא אולי מתאים לו והוא יעשה ניסיונות הוא יעשה טסטים ואז תצטרכו להחליט אם לשנות לו את הדיסק ופה מגיעים בעצם לדיסקים שאנחנו נותנים ב-AWS אפשר לשנות את הדיסק on the fly בלי בעיה לכן אין שום בעיה לבדוק ולמדוד
ואז להחליט עם איזה דיסק להשאיר את הלקוח אז רק שתדעו לכם שיש חישוב מתמטי פשוט מאוד, שיכול לעזור לכם בקביעה של הטרופוט או האי-אופס שהלקוח יקבל בסוף היום.
אבל דבר אחד בטוח, אתם צריכים בסוף היום לוודא שהלייטנסי מתאים לאותה אפליקציה. הלייטנסי צריך להתאים לו. מה זאת אומרת לייטנסי, צריך לבדוק, אחרי שנתתם ללקוח דיסקים מסוימים שמאפשרים לו 50,000 אי-אופס והוא מתחיל להריץ את האפליקציה ופתאום הוא מגלה שהלייטנסי מאוד מאוד איטי,
יש סיכוי שיצטרכו לתת לו דיסקים יותר מהירים, כי יכול מאוד להיות שתגלו שהוא אומר לכם שהאפליקציה דורשת לו 30,000 אי-אופס, אבל הוא בעצם משתמש ב-80,000 אי-אופס, אוקיי? בפיק טיים. מה שחשוב להבין זה שיש חישוב מתמטי שמאפשר לכם להבין מה הטרופוט שתקבלו במידה ותשתמשו
בבלוק סייז מסוים ובכמות אי-אופס, והפוך, תוכלו לדעת כמה אי-אופס תוכלו לתת ללקוח לאפליקציה, הוא ייתן לכם את הטרופות ואת הבלוק סייז.
זה שני בעצם הנוסחאות האלה. אתם לא יכולים לדעת מה הלקוח דורש ומה... אני לא יודע אם יש איזה לקוח שביקש שנרים לו משהו בענן של אמזון, זה בנק.
אנחנו לא יודעים כמה לקוחות יש לבנק וכמה הם יעשו טרנזקציות באינטרנט. כלומר, יש הרבה דברים שהם unknown וצריך לבדוק אותם.
אבל מצד שני, יש המון דברים שהם מאוד חוזרים על עצמם. ולמה הכוונה? הכוונה שאם הלקוח שלכם הולך להשתמש ב-SQL דאטאבייס, אז אני כבר עכשיו יכול להגיד לכם מה מבחינת ביצועים SQL דאטאבייס שנותן עבודה כנראה צריך.
או אם הלקוח הולך להשתמש ב-Oracle דאטאבייס, או אם הלקוח הולך להשתמש באיזשהו סוג אחר של אפליקציה, מה פחות או יותר הוא כנראה צריך, עם מה האפליקציה שלו תחיה בשלום.
וכשאנחנו אומרים עם מה האפליקציה תחיה בשלום, אנחנו מדברים על latency. latency בסוף היום זה מה שהכי חשוב. אני רוצה לדעת שהאפליקציה שלך לא ממתינה יותר מדי זמן, אף אחד לא אוהב ללחוץ על כפתורים באינטרנט ולהמתין, אנחנו רוצים ללחוץ ושהדברים יקרו, ופה זה המשמעות של latency.
כמה מהר האפליקציה הולכת להגיב בגלל הדיסק, אוקיי? ובנושא של latency, אני יכול להגיד לכם כבר עכשיו שאפליקציות שהן בעצם מבוססות על דאטאבייס, אם הדאטאבייס, אם נתתם דיסקים לשרת דאטאבייס, אנחנו צריכים לאפשר לדאטאבייס בין 5 ל-2 מיליסקנד של לייטנסי,
לא יותר. הדאטאבייס שלכם יהיה מאוד מאוד מאושר. אם אתם יכולים לתת לו פחות מ-1 מיליסקנד אז הדאטאבייס שלכם, הלקוח שלכם יהיה שמח עד השמיים.
ועל מה אני מדבר כשאני אומר דאטאבייס? אני מתכוון לאורקל, אני מתכוון ל-SQL, אני מתכוון ל-MySQL, MariaDB, ל-PostgresSQL וכו', וכולי כל הדייטאבס השונים כשאתם תבואו להציג לשרת דייטאבס דיסקים אני כבר עכשיו אומר לכם אם אתם יכולים לתת לאותה אפליקציה בין 2 ל-5 מיליסקנד
אפילו פחות מ-1 מיליסקנד הלקוח שלכם יהיה מאושר בשמיים זה the best עם מה הוא יכול לחיות עם 10 מיליסקנד אולי יוכל לחיות עם זה בשלום האפליקציה לא תמות אבל האפליקציה ממש הדאטאבס ממש לא יעבוד טוב מעל 15 מיליסקנד הדאטאבס שלכם לא יהיה מאושר זה לא יעבוד טוב איזה עוד אפשרויות קיימות?
יכול להיות שאתם תצטרכו לתת Storage למערכת שלמשל איזשהו NFS Mount או SMB, מערכת שהיא רק דורשת קבצים, איזושהי אפליקציה ששומרת תמונות או משהו כזה, למשל.
אז אם אתם הולכים על SMB או NFS, שתדעו לכם ש-150 מיליסקנד המערכת שלכם, האפליקציה שלכם תהיה מאושרת כנראה. פחות מזה, ממש יהיה מקסים.
קצת יותר מזה, לא קרה כלום. מערכת לא כל כך תהיה, היא לא כל כך תאהב את זה? Not so good, אנחנו מדברים על 300 פלאס מיליסקנד, גדול מ-300 מיליסקנד, מעל זה כבר המערכת ממש לא תאהב את זה.
איזה עוד אפשרויות קיימות בפנינו? כמובן שמדובר על למשל, אתר אינטרנט