שירותי AWS, כך מספרים, נולדו מתוך מחסני הספרים של אמזון. בתחילת שנות ה 2000 אמזון הייתה כבר מקצוענית בתפעול מחסנים. בכדי לייעל את עלויות התפעול בקצת יותר החליטה אמזון להשכיר לגורמים חיצוניים שטחי אחסון במחסנים שלה, שלא היו באותו הרגע בשימוש – וכך להגיע לנצילות גבוהה יותר של הנכסים שלה.
\"מדוע להשכיר אחסון פיסי, אך לא אחסון לוגי?\" – מישהו באמזון שאל.
אמזון הצטיינה לא רק בלוגיסטיקה פיסית אלא גם בתוכנה. בכדי לנהל חנות מקוונת כ\"כ גדולה, ובזמינות גבוהה – נדרשו תשתיות טכנולוגיות שלא היו רבות כמותן בעולם. בכלל, חברות הטכנולוגיה שפרחו (אמזון, נטפליקס, פייסבוק וכו\') הן החברות שהיו גם חזקות טכנולוגית מספיק, בכדי לאפשר צמיחה מהירה מבלי להיעצר. על המתחרות שהיו מאוד מרשימות אך היו חסרות את הטכנולוגיה לצמוח בקצב מהיר (גמזון, נטפליפפלופ ופייסבורד) – לא נשמע לעולם.
אמזון החלה לשווק את AWS בשנת 2006, בעיקר על בסיס של EC2 (שירות ניהול VMs) ושירות S3 (אחסון מסמכים).
השירותים הללו לא היו חדשים – אמזון השתמשה בהם כבר כמה שנים, באינטנסיביות לצרכיה הפנימיים. כשנחשפו לשוק הם כבר היו מוצרים בוגרים (בקטגוריה) ומוכחים.
שירותים נוספים היו Simple Queue Services (בקיצור: SQS) ו SimpleDB (בסיס נתונים רלציוני כשירות, עבור כמויות קטנות של נתונים. כיום, נראה שאמזון נמצאת בשלבים להפוך אותו ל deprecated לטובת שירותים חדשים יותר).
על הבסיס הזה היה ניתן להקים מערכת מבוזרת, High Scale ו Highly Available – ובזול. היה עדיין צריך לעבוד הרבה יותר קשה מהיום בכדי לבנות פתרון על AWS, וכל הרעיון של מחשוב ענן היה עוד חדש – כך שלאחר שנה היו \"רק\" 180 אלף מפתחים רשומים לשירותי AWS.
היום, מיותר לציין, אמזון היא \"הגורילה\" של שירותי ב IaaS ובדרך המבטיחה להיות גם \"הגורילה\" של שירותי ה PaaS עם AWS Beanstalk. מיקרוסופט, גוגל, יבמ, ו Heroku הצליחו לספק בשנים האחרונות תחרות מוגבלת בלבד.
מדוע אם כן – אמזון לא מעלה מחירים? מדוע היא כ\"כ אגרסיבית בתמחור של השירותים שלה?
- זה עניין תרבותי, כך טוענים. אמזון מתמחרת שירותים בצורה אגרסיבית מיום היווסדה.
- קצת יותר מפתיע: עם כל ההצלחה של הענן, כח המחשוב שנמצא היום בענן הוא רק כ 5% עד 10% מכח המחשוב העולמי (המספר המדויק תלוי במי מחשב וכיצד). קרב השליטה בענן עוד נמצא בשלביו המוקדמים.
חברות הענן לא מתמקדות כרגע ברווחים (הן מוכנות להיות break even לבינתיים) אלא רק בצמיחה ותפיסת נתח גדול יותר מפלח השוק.
מייקרוסופט, לדוגמה, עשתה חייל בשנה האחרונה: היא העבירה את הפוקוס שלה ממובייל – לענן, והצליחה תוך כך להעביר Enterprises רבים שהם \"Microsoft Shop\" – ל Azure.
התרשים למעלה הוא מעניין, אבל עלול גם להטעות – ולכן יש לי רגשות אמביבלנטיים לגבי ההוספה שלו.
אם נראה מהתרשים שמייקרוסופט הולכת להשוות לאמזון תוך כמה שנים – אז חשוב לאזן: מייקרוסופט עושה את הרווחים שלה מ Full Stack של טכנולוגיות, בעוד Amazon רק מהשכבות הנמוכות (בעיקר IaaS). כשאמזון נכנסת עתה לשכבות גבוהות יותר (PaaS, DBaaS, וכו…) – היא צפויה \"לפלוש\" לפלחי שוק גדולים וחדשים עבורה – ולהשיג \"קפיצה\" בהכנסות.
בידיעה ש 90% מהשוק עוד נותר לכיבוש – ברור שאמזון לא נשארת שאננה, וממשיכה בתחרות עיקשת ובכל המרץ.
כיום, 8 שנים אחרי ששוחררה לראשונה לקהל הרחב, יש ל AWS עשרות שירותים בענן:
כל שנה, אמזון חושפת כמה שירותים חדשים. עוד שנתיים-שלוש, הרשימה למעלה תראה חלקית ולא מעודכנת בעליל.
יצירת instance של EC2 – איך זה נראה?
אני מאמין שאין טוב ממראה עיניים – ולכן אציג את התהליך שעשיתי לפני כמה ימים. שימו לב שיש כמה פרטים פחות מעניינים – ועליהם אני אדלג.
הערה: עם Deployment כל 10 שניות של עדכון למערכות אמזון – הכל יכול להשתנות בכל רגע. אל תניחו שעוד חצי שנה התהליך יראה בדיוק אותו הדבר – אבל הוא כנראה יהיה דומה.
אמזון מאפשרת מסלול בשם AWS Free Tier בו אתם יכולים להתנסות בשירותים AWS, על חומרה מינימלית (לא הולכים עם חומרה כזו ל production) ותוכנה חופשית – למשך כשנה (!). מכניסים אמנם כרטיס אשראי – שיחויב רק אם \"התפתתם\" לבקש קצת מעבר למינימום שמוצע בתכנית.
העלויות המורגשות באמזון, בשלבים אלו של פיתוח ראשוני, הם לרוב לא החומרה שבשימוש – אלא החומרה שלקחתם לשימוש ושכחתם להחזיר. איזה שרת בינוני שלקחתם לכמה שעות, אבל נשאר רץ כל סופהשבוע – למשל.
במהלך ה Wizard למטה תראו אופציות מסוימות המסומנות כ Free tier eligible. המשמעות היא: \"ניתן לבחור באופציה זו ללא חיוב, כחלק מתוכנית ה Free Tier\". אני אבחר מבין אופציות אלו בלבד.
בחירת ה AMI
Amazon Machine Image (בקיצור AMI) הוא הפורמט של אמזון ל VM Image (בעברית: תמונת מכונה-מדומה). אני לא בקיא בפרטי המימוש הפנימי של AMI, אך הפונקציונלית היא כמו זו של קובץ dmg. ב Mac או קובץ ovf. עבור Virtual Box או VMWare.
את הקובץ ה AMI, אתם לא מנהלים אצלכם – הוא מנוהל על שירות S3 (קיצור של Simple storage service) של אמזון – שירות אמין במיוחד, scalable, לאחסון קבצים בגודל של עד 5TB (נכון לרגע זה). אתם יכולים להשתמש ב AMI מוכן מבית אמזון (הרשימה למעלה), לקנות AMI מצד-שלישי (יש Marketplace שלם, הכולל עלות שימוש לשעה המכילה את החמורה מאמזון + רשיונות התוכנה המתאימים), או פשוט לקחת snapshot מ EC2 instance שבבעלותכם.
לדוגמה: ליצור instance חדש של Red Hat Linux, להתקין עליו VIM – וכך ליצור AMI חדש \"Red Hat /w VIM\".
שווה לציין שאם אתם זקוקים ל Landscape גדול, זו עבודה קצת סיזיפית לייצר instance אחר instance. לשם כך יש שירות של אמזון שנקרא Cloud Formation המאפשר יכולות דומות ל AMI – רק בקנה מידה גדול. במקום הקמה של מכונה בודדת – הקמה של Landscape של מכונות (כל אחת עם ה AMI שהוגדר לה), הגדרות רשת, אבטחה וכו\' וכו\'.
בחירת חומרה (וירטואלית)
השלב המשמעותי הבא הוא לבחור חומרה (וירטואלית, כמובן). חומרת השרתים מסווגת לפי אופן השימוש:
- כללי / מאוזן – סדרה t או m3
- CPU intensive – סדרה c3
- Memory Optimized – סדרה r3
- Disk optimized – סדרה i2 או hs1
- וכו\'.
בתוך כל סדרה יש כמה \"גדלים\" שונים של מכונות (\"T-Shirt Size\")
- small
- medium
- large
- xlarge
- וכו\'.
אי אפשר לדעת איזו חומרה פיסית תריץ את ה VM שלכם. אם אתם בררניים (למשל: כתבתם קוד ב C בהסתמך על מעבדים מסדרה מסוימת של אינטל) – ההמלצה של אמזון (כפי שאני מכיר אותה, קצת ישנה) היא לבקש instance, לבדוק מה יצא – ואם לא אהבתם \"לזרוק\" ולבקש חדש עד שתהיו מרוצים.
בחירת Storage
השרת שלכם זקוק ל Storage. שתי האפשרויות הבסיסיות הן כדלהלן:
- Ephemeral Storage (אחסון זמני, נקרא גם Instance Storage) – מה שמוקצה כחלק מה VM.
כשתחזירו את המכונה לרשותה של אמזון – כל המידע יימחק.
אם ה VM של אמזון קרס (יכול לקרות) – המידע יאבד.
אולי תוכלו לייצר AMI מהמכונה וכך לשמור עותק של המידע.
- EBS (קיצור של Elastic Block Store) הוא בעצם סוג של NAS (קיצור של Network Attached Storage) ממנו ניתן להקצות חלקים ולעשות mount ל instance שלכם.
EBS ממשיך לחיות אחרי שהמכונה הוחזרה / ה VM נפל.
EBS הוא אמין יותר, ועובר רפליקציה בין Availability zones בתוך ה Region – הכוונה, בין Data Centers (הנקראים Availability Zones) החברים באותו אשכול של Data Centers – שנקרא Region. על כך בהמשך הפוסט.
הוא עדיין לא אמין כמו S3, ומומלץ לבצע גיבויים למידע – אם הוא חשוב לכם.
יש לאמזון שירותי Storage נוספים, שזמינים כשירות (כלומר: API) ולא כ mount למערכת ההפעלה:
Simple Storage Service (בקיצור S3)
- Key/Object Storage. למה Object ולא Value? – כי לרוב מאחסנים בו \"קבצים\" ולא ערכים קטנים (למשל מחרוזת או מספר).
- Static files – ניתן לגשת ישירות לקובץ ב HTTP ו/או HTTPS (ואז הוא מוגן בעזרת הרשאות)
- אמין בצורה יוצאת דופן (durability של 99.999999999% או משהו דומה). יש רק מקרים בודדים מתועדים בהם מידע אבד מ S3, ולרוב זה היה בצורת corruption של נתונים בעקבות באגים של אמזון.
- שומר אובייקטים בגודל של עד 5TB
- המידע נשמר מוצפן על השרתים של אמזון (encrypted at rest)
- זמינות השירות היא גבוהה (99.99%). שימו לב: יכול להיות שהקובץ \"חי וקיים\", אך אין שרת זמין שיגיש אותו (ולכן הפער בזמינויות).
- יש לו אינטגרציה ל Glacier – אחסון \"קר\" יותר (קפוא!), וזול יותר.
- יש לו אינטגרציה ל CloudFront – שירות ה CDN של אמזון, על מנת להגיש את הקבצים ממיקומים קרובים יותר לצרכן.
- Region-Specific, מסתנכרן בין ה Availability Zones שונים.
- קל מאוד לשימוש (REST API פשוט).
Glacier
- Archival Storage – מיועד לשמירת כמויות מידע, ב offline.
- לקוח 2-6 שעות לשלוף קובץ (מה שמרמז שהקובץ מאוחסן על קלטות?)
- זול מאוד (סנט ל GB לחודש, כשליש מ S3). עיקר המחיר הוא בשליפה של הנתונים.
- הנה השירות הראשון של אמזון שאנו נתקלים בו – שהוא בעל תמחור מורכב:
אמזון מציעים לכם שירות זול – הכי זול שיש, כנראה.
אבל… התמחור הוא זול כל עוד אתם מצליחים לעמוד בכמה תנאים. זה לא ניסיון של אמזון להכשיל אתכם, זו הדרך שלהם להציב תנאים בהם הם יכולים להציע מחירים כ\"כ זולים. ואלו תנאים שידרשו מכם מאמץ.
- למשל: בכדי לצמצם את מחיר השליפה מ Glacier עליכם לקבל (download) את הקובץ בקצב הורדה קבוע לאורך 24 שעות, ויש הנחה אם אתם מורידים קובץ שלם ולא חלק ממנו. פרטים נוספים.
- אתם אמורים להבין ששירות כזה לא מתאים לסטארט-אפ תפרן בתחילת דרכו (כי הוא עלול להתקשות בתנאי התמחור הזול), אלא לארגון מתופעל היטב שמנסה לצמצם עלויות לרצפה – ומוכן להזיע קצת בשביל זה.
Security Groups
כל Instance של EC2 משויך ל Security Group. השם עשוי מעט לבלבל – אולי עדיף היה לקרוא להם Traffic Policy.
כל קבוצה מכילה מספר EC2 instances וקובעת עבורם איזו תקשורת נכנסת תתאפשר ע\"פ פרוטוקולים, מקור, או ports שהגדרתם. ההגבלות הן על תקשורת נכנסת בלבד – לא מגבילים תקשורת יוצאת.
מכירים יכולת שכזו בעולם ה On-Premises? נכון – זה נקרא Firewall.
בעצם ה Security Groups היא דרך קלה ומהירה להחיל אבטחה בסיסית של Firewall על השרתים שלכם. הריכוז בקבוצות עוזר לנהל מצב בו יש לכם instances רבים.
באופן מעט מוזר, לא ניתן להזיז instance מרגע שהוגדר – בין Security Groups. אתם יכולים לשנות את ההגדרות של ה Security Group או \"לזרוק\" את ה instance ולהקים אחד חדש ב Security Group אחר.
החלפת מפתחות
טוב. ה instance שנמצא באמזון מוכן להתניע – אבל הם מוסרים לכם אותו?
הרי הוא עכשיו באמזון, ואתם – ובאמצע יש רשת עוינת של האקרים. אז… לשלוח או לא לשלוח את פרטי החיבור (\"Admin\"/\"Admin\") במייל וזהו?
הפתרון (הטבעי / הגיוני) של אמזון הוא להשתמש בהצפנה א-סימטרית. אתם יכולים לייצר זוג מפתחות ולשלוח אחד לאמזון, או לבקש שאמזון תיצור זוג מפתחות – ותשלח אחד אליכם (האופציה הזו יותר קלה).
במקרה זה תורידו (ב https, כמובן) את המפתח שלכם כקובץ perm. ותתבקשו מאוחר יותר להציג אותו בחזרה – כאשר תרצו להתחבר למכונה.
במכונות עם מערכת ההפעלה \"חלונות\" תעלו את הקובץ ותקבלו ססמה שעליכם לזכור, במכונות לינוקס תדרשו לצרף את הקובץ עצמו ככלי האימות ל ssh בעת חיבור למכונה. אם לינוקס – אז כדאי שתשמרו היטב את הקובץ שלא יאבד (מקסימום – \"זרקו\" את המכונה והקימו חדשה. זהו הקצב באמזון: שרת = disposable).
קצת על הפריסה של אמזון
שירותי AWS פזורים על 27 Data Centers ברחבי העולם (AWS Global Infrastructure – לצורך עדכונים במצב)
Availability Zone (בקיצור AZ) הוא Data Center עצמאי, עם רשת משלו, הספקת חשמל משלו, אבטחה משלו, עמידות בפני שריפות, אסונות טבע (טוב – רובם) משלו וכו\'. הוא אמור להיות חסין לקריסה של Availability Zone אחר.
ה AZs מקובצים לתוך אשכולות בשם Region – שזה אזור גאוגרפי בעולם. יש בין ה AZs ב Region רשת מהירה, שמאפשרת רפליקציה של נתונים בין ה AZ בכדי ליצור ולשמר יתירות. Region יכול להיות \"מזרח ארה\"ב\" או \"גרמניה\".
סה\"כ לאמזון יש כיום 11 Regions ברחבי העולם.
רבים מהשירותים של אמזון הם זמינים ברמת ה Region. למשל שירות S3 – מסנכרן לבד את הנתונים שלו בין ה AZs ב Region.
שרתים שלכם (EC2 instances) – הם באחריותכם: כדאי שתפזרו את השרתים ב Region על פני כמה Availability zones שונים, ואם יש צורך בסנכרון – הוא עליכם.
בהרבה Regions יש שלושה Availability Zones. למה שניים לא מספיקים?
ראשית – כי 3 זה יותר בטוח מ 2.
נניח שהסבירות ששני AZs יקרסו באותו הזמן היא קטנה מדי בכדי להטריד אתכם (נניח), האם יש טעם לפזר את השרתים על יותר משני AZs? התשובה הפשוטה היא – כן.
נשווה פיזור של אפליקציה בין 3 ל 2 Availability Zones:
- ברגע הנפילה – ה capacity שלכם ירד ל 67% ולא ל 50%.
- \"להרים instance זה עניין של כמה דקות ב AWS, נכון?\"
- נכון – אבל לא בעת אירוע של נפילת Availability Zone. במקרה כזה אלפי לקוחות של אמזון מבקשים ממנה instances חדשים באותו הרגע ממש – מה שאומר שהזמן לקבל instance חדש יהיה ארוך מהרגיל, זמן בו יהיה עליכם להסתפק בקיבולת שנותרה לכם – וכאן ההבדל בין 50% קיבולת ל 67% קיבולת – היא יותר משמעותית.
נטפליקס, למשל, שהעסקים שלהם מבוססים לגמרי על AWS עשו מעבר לכך: ברגע שנופל AZ הם מורידים את איכות השירות (נאמר: ל 65%) בכדי להמשיך לתת את השירות לכל הלקוחות ללא הפרעה – ומבלי להסתמך על כך שיוכלו להוסיף בזמן קצר עוד EC2 instances מספיקים. שיפורים אלו נעשו מתוך outages שהם חוו בפועל, ולא מתוך \"תכנון מוקדם\".
למה אמזון לא מחברת את כל ה Regions שלה אחד לשני?
- כי תעבורת הרשת תהיה יקרה מאוד (יש הבדל בין תקשורת מהירה בתוך וירג\'יניה לתקשורת מהירה בין וירג\'יניה לסין)
- כי קשר = תלות = פחות disaster tolerance.
- כי שירותים מסוימים (לדוגמה VPC) לא יעבדו על פני מרחק גיאוגרפי גדול.
אחד ה Regions המעניינים הוא GovCloud שנמצא בצפון-מערב ארה\"ב. אחד החסמים של גופים ממשלתיים להשתמש בשירותי הענן של אמזון הוא רגולציה. כל מיני חוקים שמבטיחים שרק אזרחים אמריקאים יהיו מסוגלים לגשת לשרתים ולרשת, חוקים של אבטחת מידע ואחסון ייחודיים (מישהו שמע על ITAR?) וכו\'. מכיוון שהמגזר הציבורי בארה\"ב הוא מספיק גדול להצדיק השקעה שכזו (הממ הממ) – אמזון בנו Region מיוחד רק לגופי ממשלה בארה\"ב שתפור לכללי הרגולציה. המיקום במערב ארה\"ב נקבע בגלל סיבות טקטיות – והוא יורחב גם למזרח ארה\"ב בעתיד (אני מניח שכ Region נוסף).
שימו לב שלא כל השירותים של אמזון זמינים בכל ה Regions.
Edge location
אמזון, כספקית CDN שצריכה להיות \"קרובה\" לכל המשתמשים בעולם, מחזיקה גם אתרים (מה שנקרא לעתים PoP – Point of Presence) רק לצורך Caching של נתונים או שירות ה DNS (נקרא Route 53).
קצת על אבטחה
מודל האבטחה של AWS הוא מודל של אחריות משותפת: של אמזון \"בשותף\" עם הלקוח.
אמזון לוקחת אחריות על כמה תחומים שלה, ומספקת ללקוח מגוון כלים – בציפיה שהוא יהיה אחראי על הצד שלו.
אחריות הלקוח כוללת:
ניהול משתמשים והראשות. אמזון מספקת את IAM (קיצור של: Identity and Access Management) שהוא סוג של Repository לניהול משתמשים (כמו Active Directory), הכולל גם יכולות של Federated Identity ו SSO (כמו Active Directory Federation Services – ADFS).
אמזון מספקת גם יכולת Multi-Factor Authentication. למשל: הכנסת ססמה ב Desktop ובנוסף אימות ה Login מתוך הסמארטפון (על בסיסי ID ייחודי של היצרן – שמוודא שזה אכן הטלפון שלכם) או חומרה ייעודית אחרת (כמו כרטיס RSA המייצר קוד זמני שהשרת יכול לאמת – למי שמכיר). ייתכן ותרצו לאכוף מנגנון שכזה על גישה של משתמשי מפתחי (Admins למיניהם).
אמזון מספקת גם שירותי ייעוץ בנושא אבטחה, אותו תוכלו לשכור מאמזון (בתשלום, כמובן).
Security Groups – אותם הזכרנו בהקדמה, שזה סוג של Firewall.
הרשאות שונות (ACLs) – מי יכול לגשת לאיזה שירות (שירותים כמו בסיסי נתונים כשירות, CDN, וכו\').
אם אתם רוצים לאבטח את הרשת שלכם יותר מהרמה של Security Groups ו ACLs, אמזון מספקת יכולת בשם Virtual Private Cloud (בקיצור VPC) בה תקבלו רשת נפרדת משאר הענן (ע\"י ויראוליזציה, כמובן) ותהיה לכם יכולת שליטה רבה על הגדרת הרשת וההרשאות שלה – כרצונכם. זו כמובן התעסקות לא קטנה, הדורשת הבנה טובה של הרשת – ושל יכולות ה VPC של אמזון.
אחריות אמזון כוללת:
הגנה פיסית – אף אדם בעל שלא מורשה לכך לא יוכל לגשת פיסית ולהתחבר לחומרה שמשרתת אתכם. איך עושים זאת? קירות בטון, דלתות פלדה, מצלמות אבטחה, שומרים וכלבים כעוסים. וכמובן: תרגול האופרציה הזו שתהיה בכושר לטפל בתקריות האפשריות.
אחריות על הגנת הרשת הפנימית של AWS: ניהול ה switches / routers בצורה מאובטחת. אמזון מנטרת את תנועת הרשת מפני חריגות עקרוניות: שרת ששלוח IP Packets ומצהיר על IP שאינו שלו, פעילות של Port scanning וכו\'. אמזון יודיעו לכם אם הם מזהים התנהגות חשודה כלפי ה EC2 Instances שלכם.
המדיניות של אמזון אוסרת עליכם, למשל, להשתמש ב NMAP או כלי דומה לבצע port scanning לעצמכם. עליכם לסמוך על אמזון. אם אתם רוצים לבצע להריץ Web Scanner על השרתים שלכם – עליכם לתאם זאת עם אמזון מראש ולעשות זאת רק במסגרת הזמן שהוקצב לכם.
אמזון מבטיחה Multi-tenancy של המערכות שלה (ע\"י Hypervisors, VLANs, או Multi-tenancy ברמת התוכנה, וכו\') שמבטיח שלקוח אחר, שמשתף אתכם חומרה פיסית – לא יוכל לנצל עובדה זו בכדי לגשת לנתונים שלכם. הפרדה מוחלטת.
שירותי הגנה מ DDoS (כלומר: Distributed Denial of Service) – התקפה נפוצה, שירות כזה מסופק ע\"י רוב ספקיות ה CDN הגדולות, ואמזון היא אחת מהן.
תאימות לסטנדרטי-אבטחה מרכזיים בתעשייה. לדוגמה: אם הרגולציה של HIPPA (אחסון מידע רפואי) דורשת השמדה פיסית של אמצעי האחסון של מידע רפואי שמפסיקים לשמור – אמזון תספק את השירות הזה עבורכם, ותשמיד במיומנות רבה את הדיסקים הפיסיים ששימשו אתכם לאחסון המידע הרפואי. הכל, ע\"פ הנחיותיכם ותמורת תשלום מתאים – כמובן.
סיכום
אחרי שסקרתי את OpenStack (גם חלק שני) – יהיה רק הגיוני לסקור את AWS.
שילבתי בפוסט לא מעט פרטים – אך הדרך להכיר את AWS היא עוד ארוכה.
שיהיה בהצלחה!
