איך Badoo השיגה את היכולת לשלוח 200 תמונות בשנייה

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

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

באופן טבעי, מיד עלתה השאלה: אם אחד מהשרתים שלנו נופל והופך ללא זמין, איזה חלק מהתנועה נאבד? בדקנו מה יש בשוק והחלטנו לקנות חומרה כדי שתפתור לנו את כל הבעיות. הבחירה נפלה על הפתרון של חברת F5-network (שאגב, רכשה לאחרונה את NGINX, Inc): BIG-IP Local Traffic Manager.

מה שרכיב החומרה הזה (LTM) עושה: זהו נתב ברזל שגורם ליותר ברזל של היציאות החיצוניות שלו ומאפשר לך לנתב תעבורה על סמך טופולוגיית הרשת, על הגדרות מסוימות, ועושה בדיקות תקינות. היה לנו חשוב שאפשר יהיה לתכנת את רכיב החומרה הזה. בהתאם לכך, נוכל לתאר את ההיגיון של האופן שבו הוגשו תמונות של משתמש ספציפי ממטמון ספציפי. כמו מה זה נראה? יש חומרה שמסתכלת על האינטרנט בדומיין אחד, IP אחד, מבצעת ssl offload, מנתחת בקשות http, בוחרת מספר מטמון מ-IRule, לאן ללכת ומאפשרת לתנועה לעבור לשם. במקביל, הוא מבצע בדיקות תקינות, ובמקרה שמכונה כלשהי לא הייתה זמינה, באותו זמן עשינו את זה כך שהתעבורה עברה לשרת גיבוי אחד. מנקודת מבט של תצורה, יש כמובן כמה ניואנסים, אבל באופן כללי הכל די פשוט: אנו רושמים כרטיס, התכתבות של מספר מסוים ל-IP שלנו ברשת, אנו אומרים שנקשיב ביציאות 80 ו-443, אנו אומרים שאם השרת אינו זמין, אז אתה צריך לשלוח תעבורה לגיבוי, במקרה זה ה-35, ואנחנו מתארים חבורה של היגיון כיצד יש לפרק את הארכיטקטורה הזו. הבעיה היחידה הייתה שהשפה בה תוכנת החומרה הייתה Tcl. אם מישהו זוכר את זה בכלל... השפה הזו היא יותר כתיבה בלבד מאשר שפה נוחה לתכנות:

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

אבל…

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

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

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

כלומר, זיהינו את מקור הבעיה, זיהינו את צוואר הבקבוק. נותר להחליט מה נעשה.

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

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

בהתאם, ההיגיון נשאר זהה: אנו מתקינים את Nginx, הוא יכול לבצע SSL-offload, נוכל איכשהו לתכנת את לוגיקת הניתוב, בדיקות בריאות בהגדרות ופשוט לשכפל את ההיגיון שהיה לנו קודם.

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

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

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

כדי להימנע מכך, עשינו שני דברים:

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

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

למרבה הצער, גם זה לא הכל, כי פשוטו כמשמעו, השבועיים הראשונים לפעילות של תכנית זו הראו שבדיקת בריאות TCP היא גם דבר לא אמין: בשרת במעלה הזרם זה אולי לא Nginx, או Nginx במצב D, וב במקרה זה, הקרנל יקבל את החיבור, בדיקת הבריאות תעבור, אך לא תעבוד. לכן, מיד החלפנו את זה ב-Health Check http, יצרנו אחד ספציפי, שאם הוא מחזיר 200, אז הכל עובד בסקריפט הזה. אתה יכול לעשות היגיון נוסף - למשל, במקרה של שרתי מטמון, בדוק שמערכת הקבצים מותקנת כהלכה:

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

מכיוון שאי אפשר לעבור למעלה זרם אחר במעלה זרם אחד, היה צורך לוודא שאם ה-upstream הראשי, שבו פשוט הקלטנו את מטמון הצילום הנכון והדרוש, לא היה זמין, פשוט עברנו את error_page ל-fallback, מ- איפה הלכנו לגיבוי במעלה הזרם:

ובעצם הוספת ארבעה שרתים, זה מה שקיבלנו: החלפנו חלק מהעומס - הסרנו אותו מ-LTM לשרתים האלה, הטמענו שם את אותו היגיון, באמצעות חומרה ותוכנה סטנדרטיים, ומיד קיבלנו את הבונוס שהשרתים האלה יכולים להיות מוגדלים, כי הם יכולים להיות פשוט לספק כמה שצריך. ובכן, השלילי היחיד הוא שאיבדנו זמינות גבוהה עבור משתמשים חיצוניים. אבל באותו רגע היינו צריכים להקריב את זה, כי היה צורך לפתור את הבעיה מיד. אז, הסרנו חלק מהעומס, זה היה בערך 40% באותו זמן, LTM הרגיש טוב, וממש שבועיים אחרי שהבעיה התחילה, התחלנו לשלוח לא 45 בקשות לשנייה, אלא 55. למעשה, גדלנו ב-20% - ברור שזו התנועה שלא נתנו למשתמש. ואחרי זה התחילו לחשוב איך לפתור את הבעיה שנותרה - להבטיח נגישות חיצונית גבוהה.

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

מלכתחילה, ממה מורכב Keepalved? הראשון הוא פרוטוקול ה-VRRP, המוכר בקרב אנשי רשת, הממוקם על ציוד רשת המספק סובלנות לתקלות לכתובת ה-IP החיצונית שאליה מתחברים לקוחות. החלק השני הוא IPVS, שרת IP וירטואלי, לאיזון בין נתבי צילום והבטחת סובלנות תקלות ברמה זו. ושלישית - בדיקות בריאות.

נתחיל מהחלק הראשון: VRRP - איך זה נראה? יש IP וירטואלי מסוים, שיש לו ערך ב-dns badoocdn.com, שבו לקוחות מתחברים. בשלב מסוים בזמן, יש לנו כתובת IP בשרת אחד. מנות Keepalive פועלות בין השרתים באמצעות פרוטוקול VRRP, ואם המאסטר נעלם מהרדאר - השרת בוצע מחדש או משהו אחר, אז שרת הגיבוי קולט אוטומטית את כתובת ה-IP הזו - אין צורך בפעולות ידניות. ההבדל בין מאסטר לגיבוי הוא בעיקר בעדיפות: ככל שהוא גבוה יותר, כך גדל הסיכוי שהמכונה תהפוך למאסטר. יתרון גדול מאוד הוא שאין צורך להגדיר כתובות IP בשרת עצמו, מספיק לתאר אותן בתצורה, ואם כתובות ה-IP זקוקות לכללי ניתוב מותאמים אישית, זה מתואר ישירות בתצורה, באמצעות אותו תחביר כפי שמתואר בחבילת VRRP. אתה לא תיתקל בדברים לא מוכרים.

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

לפיכך, הבטחנו את סבילות התקלות של כתובת ה-IP החיצונית. החלק הבא הוא איכשהו לאזן את התעבורה מכתובת ה-IP החיצונית לנתבי הצילום שכבר מפסיקים אותה. הכל די ברור עם פרוטוקולי האיזון. זה או סיבוב סיבוב פשוט, או דברים קצת יותר מורכבים, wrr, חיבור רשימה וכן הלאה. זה בעצם מתואר בתיעוד, אין שום דבר מיוחד. אבל שיטת המשלוח... כאן נסקור מקרוב מדוע בחרנו באחד מהם. אלה הם NAT, ניתוב ישיר ו-TUN. העובדה היא שמיד תכננו לספק 100 גיגה-ביט של תעבורה מהאתרים. אם אתה מעריך, אתה צריך כרטיסי 10 גיגה-ביט, נכון? 10 כרטיסי גיגה בשרת אחד כבר מעבר לטווח של, לפחות, הרעיון שלנו של "ציוד סטנדרטי". ואז נזכרנו שאנחנו לא רק נותנים קצת תנועה, אנחנו נותנים תמונות.

מה מיוחד? - הבדל עצום בין תנועה נכנסת ויוצאת. התנועה הנכנסת קטנה מאוד, התנועה היוצאת גדולה מאוד:

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

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

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

עצרנו איפשהו באמצע: יש לנו בקשת https למיקום מסוים, הסקריפט נקרא, אם הוא מגיב בתגובה 200, אנחנו מאמינים שהכל בסדר עם השרת הזה, שהוא חי וניתן להפעיל אותו די בְּקַלוּת.

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

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

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

כל מה שנותר לומר הוא שכל זה, כמובן, צריך להיות במעקב. בנפרד, יש לציין של-Keealivede, בתור תוכנה שנכתבה לפני זמן רב, יש המון דרכים לנטר אותה, הן באמצעות צ'קים דרך DBus, SMTP, SNMP ו-Zabix הסטנדרטי. בנוסף, הוא עצמו יודע לכתוב מכתבים כמעט לכל עיטוש, ולמען האמת, באיזשהו שלב אפילו חשבנו לכבות את זה, כי הוא כותב הרבה מכתבים לכל העברת תעבורה, הפעלה, לכל חיבור IP, וכן הלאה. כמובן, אם יש הרבה שרתים, אז אתה יכול להציף את עצמך עם האותיות האלה. אנו מפקחים על nginx על נתבי תמונות בשיטות סטנדרטיות, וניטור החומרה לא נעלם. היינו, כמובן, מייעצים שני דברים נוספים: ראשית, בדיקות בריאות חיצוניות וזמינות, כי גם אם הכל עובד, למעשה, אולי המשתמשים לא מקבלים תמונות בגלל בעיות עם ספקים חיצוניים או משהו מורכב יותר. תמיד כדאי לשמור איפשהו ברשת אחרת, באמזון או במקום אחר, מכונה נפרדת שיכולה לעשות פינג לשרתים שלכם מבחוץ, וכדאי גם להשתמש בזיהוי חריגות, למי שיודע לעשות למידת מכונה מסובכת, או ניטור פשוט , לפחות כדי לעקוב אחר אם הבקשות ירדו בחדות, או להיפך, עלו. זה גם יכול להיות שימושי.

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

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

מקור: www.habr.com