איך בנינו רשת סלולרית שלמה עם קוד פתוח – סיפור לקוח
מאת:
ניר סמיונוביץ, 19.6.14, 19:50
אם מבצעים תכנון קפדני ותשתיתי נכון, אפשר להמיר חלקים ניכרים מרשת הסלולר (כל רשת) לתשתיות קוד פתוח ועי"כ להוזיל עלויות בצורה ניכרת.
כל מי שהקים רשת סלולרית או מי שהשתתף בהקמה של רשת כזו יודע, שהתהליך סבוך ויקר עם הרבה עליות ומורדות. בין אם אנו מדברים על תהליכי הרכש הסבוכים, או אוסף היועצים והטכנולוגים המספקים לנו דעות שונות או אוסף הטכנולוגיות הנערם במערכת במהירות האור – זה תהליך כואב ומתיש.
ההתמודדות עם עולם האיתותים היא בעיה ידועה, אך תודות לחברות כמו
Inno Networks ו-
Squire Technologies, מנגנוני הרשת כגון
HLR,
GGSN,
SMSC ועוד כבר אינם יקרים כפי שהיינו רגילים לכך. מערכות
HLR של חברות דוגמת
NOKIA, שנמכרו במיליוני דולרים, נמכרות היום בעלות של כמה עשרות אלפי דולרים למערכות קטנות (המשרתות עשרות אלפי משתמשים), ולכל היותר כמה מאות אלפי דולרים למערכות גדולות (המשרתות מיליוני משתמשים).
יחד עם מערכות האיתות יש לכל רשת סלולרית מספר אלמנטים, שבלעדיהם אי אפשר לתפקד:
- MSC or Mobile Switching Center
- SCP or Service Control Point
- SMS Gateways
- Voice Switching
- Local Number Portability
- IN Services
- Billing and Invoicing
מי שהמושגים הללו לא זרים לו יודע, שמחירם של אלה לא מבוטל והוא יכול להגיע במצטבר במערכות גדולות למספר מיליוני דולרים.
עם זאת, אם מבצעים תכנון קפדני ותשתיתי נכון, אפשר להמיר חלקים ניכרים מתשתית זו לתשתיות קוד פתוח ועי"כ להוזיל עלויות בצורה ניכרת.
לפני כ-3 שנים פנתה אלינו חברת סלולר בהקמה וביקשה מאיתנו לבדוק את האפשרות של בניית המערכות המופיעות ברשימה מעלה (למעט
Billing), תוך כדי שימוש בקוד פתוח ולא באמצעות רכישה של ציודים קנייניים. בניית כל האלמנטים המופיעים מעלה זו בהחלט משימה לא פשוטה. אולם, האתגר סיקרן אותנו והלקוח היה מוכן לקחת את ההימור הזה, שלימים הסתבר כמוצלח.
מה היו הכלים בהם בחרנו?
- מערכות מיתוג Voice – בחרנו במקרה זה ב-Asterisk, כיוון שנתנה לנו את יכולת הפיתוח הזריזה ביותר ואת התוצאה הטובה ביותר.
- מערכות IN – בחרנו במקרה זה ב-Kamailio שנתן לנו גם את הגמישות הדרושה בפיתוח הפתרון וגם את ה-Scalability שחיפשנו.
- מערכת SMS – מערכות ה-SMSC כבר היו קיימות, אך היה לנו צורך באמצעי קישור, שייתן API פשוט ומסודר. בחרנו במקרה זה לבנות ,Cluster שיהיה מבוסס על Kannel, שהוא פרויקט קוד פתוח בתחום ה-SMS.
- מערכת SCP – כיוון שלא היתה שום מערכת פתוחה קיימת, כתבנו מערכת משל עצמנו, שהיוותה מערכת Middleware בין כל האלמנטים ברשת, ושלטה על כל המתרחש בכל שיחה או Session.
היה ברור לנו, שאנו זקוקים גם לפתרון של ניתוח לוגים, ניטור ובקרה ועבור אלה בחרנו את הבאים:
- מערכת ניטור – בחרנו לבנות פתרון משולב של ICINGA ו-MRTG. הראשון נתן לנו שכבת התראה וניטור, שקושרה להתראות קוליות ו-SMS. השני נתן Dashboard מסודר לתעבורה. בנוסף, פותח Dashboard המספק "מבט על" של המערכת כדי לתת לאנשי התפעול אמצעי נוח לבקרה.
- מערכת Logging – במקרה זה בחרנו ב-Graylog2, שהוא מערכת Log Aggregation המבוססת על מסדר NoSQL מסוג MongoDB ומעליו מערכת ElasticSearch. המערכת אוגרת כ-10 גיגה בייט של לוגים ביום, מנתחת אותם ומספקת סטטיסטיקה והתראות על בסיס המידע המנותח.
כדי להפוך את כל הפתרון לכדאי ברמת הברזלים, נבחרו לביצוע הפרויקט שרתים של
IBM, שהותקנו עם תוכנת
VMware. בתחילת הדרך, השרתים הותקנו בעזרת
VMware ESXi 5.0 ולאחרונה שודרגו ל-
VMware ESX 5.5.
קצת על תוכן מערכות ותוכן תוכנה:
קיים הבדל מהותי בין תוכן מערכת ובין תוכן תוכנה, שנובע מצורת ההתרחבות של כל אחת מאלו. מערכות נוטות להיות מורחבות לעומק, כלומר, עוד אחסון, עוד שרתים, עוד מתגים. מרבית בעיות הביצועים נפתרות ע"י הוספה של רכיב חומרה אחד או יותר והתאמות תצורה בהתאם לדרישות. לעומת זאת, התרחבות בעולם התוכנה הוא משהו, שצריך להיות מובנה לתוך התוכן התוכנתי מהיום הראשון. היה והגענו לנקודה בה תוכן המערכת אינו מאפשר גדילה, פגענו בתקרת הזכוכית של המערכת, ומכאן לשדרג את המערכות המשימה תהיה קשה מאוד.
אחד מהעקרונות, שעמדו מולנו בשלב התכנון, היה הצורך של המערכת להיות מסוגלת לגדול, ללא שינויי תשתית, שינויי תוכנה או שינויים בארכיטקטורה הכללית של המערכת.
לאור עקרון זה, הוחלט על מערכת במודל
“Out-of-Band Call Control with De-Coupled Services” – כלומר, כל רכיב במערכת מתפקד בפני עצמו בצורה מונוליטית, אך הרכיבים מדברים בינם לבין עצמם ב-
API מוגדר מראש על מנת לאפשר למערכת לתפקד ביחידה אחת.
נקודות לחשיבה בבניית מערכת Middleware:
אחת הבעיות בבניית
Middleware יעיל הוא נושא של
Caching. כלומר, אילו שאילתות אנו שומרים בזיכרון המערכת ואילו שאילתות לא. ברשת סלולרית מתרחשות הרבה מאוד שאילתות בין מערכות המיתוג לבין מערכות המיקום, מערכות ה-
Billing ועוד.
לכולנו ברור שתשובות ממערכות המיקום לא יכולות לעבור תהליך
Cache. כמו כן, תשובות ממערכות ה-
Billing נחשבות למידע
Real Time וגם איתן אי אפשר לבצע
Cahing. לעומת זאת, שאילתות מול מערכות ה-
Voicemail, ניידות מספרים, מערכות ה-
IN ומערכות מיתוג וניתוב השיחות יכולות לעבור תהליך
Caching.
תכנון נכון ובחירה קפדנית של כלי ה-
Caching יכול להיות ההבדל בין רשת מקרטעת לרשת מדהימה. כמו כן, כאשר עוסקים ב-
Caching, צריך גם לתכנן את מיקום ה-
Cache ואת המבנה שלו. למשל, מנגנון כמו
Memcache ייתן ביצועים אחרים מול מנגנון מבוסס
Redis או אחרים.
דבר נוסף, שנוכחנו לגלות, שמערכות ניידות מספרים מתפקדות יותר טוב כאשר הן בנויות על בסיס של
NoSQL מאשר
SQL. במסגרת אחד הנסיונות ביצענו ניסוי, שכלל שרת
Oracle, שרת
MS-SQL ומולו שרת
MongoDB, שצוייד ב-
ElasticSearch. הפרש הביצועים היה כ-15% לטובת ה-
MongoDB, בייחוד ביחס לגודל ה-
,DB שכלל כ-35 מיליון רשומות. לעומת זאת, ההפרש העקרוני היה בעלויות החומרה והתוכנה הדרושים.
אפליקציות סלולריות ו-VoIP OTT:
ספקי הסלולר בעולם מפחדים מעולם ה-
VoIP OTT. אפליקציות כגון
Skype ו-
Viber משליכות צל כבד וגדול על היכולת של ספקים לתת שירותים הולמים ומתקדמים, בייחוד בעולם בו ה-
Data הופך להיות מוצר צריכה ולא מוצר פנאי. מעבר ספקי הסלולר מעולם שרותי ה-
Voice/
SMS לעולם ה-
Dumb Pipe הוא מהלך ברור ההולך לקרות בין אם הספקים ירצו או לא.
יחד עם זאת, ספקים כגון
AT&T ו-
T-Mobile כבר התחילו לשלב
בתוך הרשתות שלהם יכולות
VoIP OTT כדי לתת ללקוחות מענה, גם כאשר הם נמצאים מחוץ לאזור קליטת הרשת.
לדוגמא, ל-
T-Mobile בארה"ב יש אפליקציה המותקנת על הטלפון, המאפשרת לבצע
Off Load של השיחות מעולם ה-
GSM לעולם ה-
WiFi, ועי"כ לשמור על הלקוח גם כאשר הוא מחוץ לאזור הקליטה או אפילו ב-
Roaming.
אותה חברה שעבדנו עבורה, ביקשה מאיתנו לפני כשנה לפתח עבורה אפליקצייה בסגנון האפליקציה של
T-Mobile, כמובן, עם טוויסטים שלה. התוצאה היתה מערכת מיתוג מבוססת ענן המופעלת לחלוטין בשרתים של
RackSpace ו-
DigitalOcean, שמספקות את השירות. מערך המיתוג היוא מערך דינמי. כלומר, הוא מסוגל לגדול ולקטון בהתאם לצרכים ועי"כ לשמור על יחס עלות תפעול למשתמשים פעילים ברמה סבירה ללא צורך בהפעלה של משאבים מיותרים.
האפליקציה בנויה על תשתיות תוכנה פתוחות, מבוססות
PJSIP עם מנוע מדיה מבוסס
WebRTC. האפליקציה נכון לעכשיו עדיין לא הושקה ונמצאת בשלבי בדיקות אחרונים מול מערכות ה-
Billing ו-
OSS/BSS.
סיכום
עולם הטכנולוגיה התקדם במשך 2 העשורים האחרונים בקצב אקספוננציאלי, דבר שגרם לחלק מהטכנולוגיות המוטמעות היום אצל ספקי הסלולר ולחלק מהמתודולוגיות הפעילות של ספקי הסלולר להיראות לא עדכניות, מיושנות עד כדי שעבר זמנן.
הצורך בהורדת עלויות האחזקה, ההקמה, התפעול והנדל"ן הדרוש (כן, גם נדל"ן הוא פקטור), גרמו לספקים לחפש פתרונות אלטרנטיביים. בעולם של תשתיות תוכנה ו-
SDN, ספק סלולרי שלם יכול לחיות כחווה של מכונות ווירטואליות בתוך 2-3 ארונות תקשורת וכבר אין ממש צורך בחדרי מכונות שלמים.
להערכתי, לא רחוק היום בו נראה ספקים שונים מעבירים תשתיות קריטיות לתוך ענני העיבוד של גוגל (
Google AppEngine) ואמזון (אוסף שירותי
AWS). תשתיות, שאינן קשורות ישירות למיתוג
Voice או מערכות שבהן
Scaling דינמי יאפשר מקסום עלות תועלת, תעבורנה לעננים ציבוריים או פרטיים.
מאת
: ניר סמיונוביץ, יוני 2014
מנכ"ל
GreenfieldTech
www.greenfieldtech.net
nirs@greenfieldtech.net
