בהמשך לפוסט "הצצה ראשונית ל AWS" התחלתי לכתוב פוסט על ה Big Data Stack של AWS, אך מהר מאוד נתקעתי: הבנתי שחסר רקע ב Hadoop, ורקע קצת יותר מקיף על שירותי הבסיס של AWS.
שירותי הבסיס של AWS? מלבד EC2 (שהוא מרכזי מאוד, אבל לא כ"כ מפתיע), שירות חשוב מאוד הוא S3, ולו החלטתי להקדיש את הפוסט הבא.
S3 (קיצור של Simple Storage Service, להזכיר) הוא שירות האכסון הבסיסי של אמזון, והוא שימושי מאוד בתסריטים רבים. הממשק שלו דומה למערכת קבצים מבוזרת (אם כי הוא קצת יותר מורכב).
את הקבצים מארגנים ב Buckets - שהם סוג של Root Folders, עליו ניתן להגדיר הרשאות ועוד מספר תכונות.
לכל קובץ ניתן לגשת ישירות בעזרת HTTP, בצורה:
כאשר קבצים יכולים להיות בגודל של עד 5TB.
למרות הממשק הדומה למערכת קבצים, כדאי לזכור שבגישה ל S3 יש latency של רשת + ה latency הפנימי של S3 (שיכול להיות עוד 100-200ms בממוצע). אל תנסו לרוץ בלולאה על קבצים ב S3 בזה אחר זה, כמו שאולי אתם עשויים לעשות עם מערכת קבצים מקומית. להזכיר: זמן גישה חציוני למערכת קבצים מקומית עשויה להיות משהו באזור ה 10ms..., ואין לה את המורכבות הנוספת של הרשת.
כאשר יוצרים Bucket, ניתן לבחור להגדיר אותו באחת מ2 רמות אמינות קיימות:
פחות או יותר כל מה שאפשר לעשות עם מערכת קבצים מבוזרת, אמינה מאוד, מהירה יחסית, ובעלת קיבולת בלתי מוגבלת. השימושים הנפוצים הם:
את הפעולות הבסיסיות ניתן לעשות דרך ה UI של אמזון:
ניתן להשתמש ב awscli בכדי לבצע פעולות על s3 מתוך command line:
התשלום ב S3 הוא לא רק עבור האחסון, אלא גם עבור תעבורת הרשת (הורדה). אם אתם חוששים שגורם צד שלישי מפנה לתוכן שלכם לשימושים שלא רציתם, אתם יכולים להגביל את אורך החיים של ה URLs או לחייב את מי שקורא את המשאבים לשלם על התעבורה (מה שלא מאפשר למשתמשים אנונימיים לגשת למשאב).
S3 הוא שירות ברמת ה Region, ובאופן אוטומטי תהיה רפליקציה של הנתונים בין ה Availability Zones השונים. הרפליקציה מתבצעת תוך כדי כתיבה, כך שאם קיבלתם OK על הפעולה - המידע שם ומסונכרן (בניגוד ל offline replication המתבצע מאוחר יותר).
שם של Bucket צריך להיות ייחודי ברמת כל ה Regions של AWS (כלומר: Globally unique ב Account).
שם האובייקט משפיע על האופן שבו S3 תעשה partition לנתונים, ולכן אם אתם זקוקים ל tps גבוה - כדאי לדאוג לשמות בעלות שונות גבוהה, ושאינם תלויים בדפוסים שלא מייצגים את דפוסי הגישה (למשל: לא להתחיל שם של אובייקט ב timestamp - כי יהיו קבצים רבים המתחילים באופן דומה). הנה פוסט בנושא, אם הנושא רלוונטי עבורכם.
על Bucket ניתן לקבוע policies, המוגדרים מכמה אלמנטים:
הנה עברנו בחינה מעמיקה של S3. היא לא הייתה ארוכה, בעיקר בגלל ש S3 הוא באמת... די פשוט.
S3 הוא מאבני הבניין היסודיות ביותר של AWS - וכדאי להכיר אותו היטב.
שיהיה בהצלחה!
---
לינקים רלונטיים
FAQ של אמזון על S3
המחירון של S3
Data encryption on S3
שירותי הבסיס של AWS? מלבד EC2 (שהוא מרכזי מאוד, אבל לא כ"כ מפתיע), שירות חשוב מאוד הוא S3, ולו החלטתי להקדיש את הפוסט הבא.
S3 (קיצור של Simple Storage Service, להזכיר) הוא שירות האכסון הבסיסי של אמזון, והוא שימושי מאוד בתסריטים רבים. הממשק שלו דומה למערכת קבצים מבוזרת (אם כי הוא קצת יותר מורכב).
את הקבצים מארגנים ב Buckets - שהם סוג של Root Folders, עליו ניתן להגדיר הרשאות ועוד מספר תכונות.
לכל קובץ ניתן לגשת ישירות בעזרת HTTP, בצורה:
s3://bucket/folder/filename
כאשר קבצים יכולים להיות בגודל של עד 5TB.
למרות הממשק הדומה למערכת קבצים, כדאי לזכור שבגישה ל S3 יש latency של רשת + ה latency הפנימי של S3 (שיכול להיות עוד 100-200ms בממוצע). אל תנסו לרוץ בלולאה על קבצים ב S3 בזה אחר זה, כמו שאולי אתם עשויים לעשות עם מערכת קבצים מקומית. להזכיר: זמן גישה חציוני למערכת קבצים מקומית עשויה להיות משהו באזור ה 10ms..., ואין לה את המורכבות הנוספת של הרשת.
Bucket, הסמל של S3 |
כאשר יוצרים Bucket, ניתן לבחור להגדיר אותו באחת מ2 רמות אמינות קיימות:
- רמת רגילה, המספקת durability של 99.999999999% (11 תשיעיות, וואהו!)
- Reduced Durability (נקראת RRS, קיצור של Reduced Redundancy Storage) - המספקת durability של 99.99% בלבד. כלומר: סיכון של 0.01% אחוז, כל שנה, לאבד את המידע. המחיר שלו נמוך ב 15-20% מהתצורה הסטנדרטית. תצורה זו מתאימה למידע לא קריטי / שניתן לשחזר.
מה אני יכול לעשות עם S3?
פחות או יותר כל מה שאפשר לעשות עם מערכת קבצים מבוזרת, אמינה מאוד, מהירה יחסית, ובעלת קיבולת בלתי מוגבלת. השימושים הנפוצים הם:
- הנגשה של תוכן סטטי (קבצי HTML/CSS/תמונות וכו', לעתים קבצים JSON או XML עם נתונים) על גבי HTTP. ל S3 ניתן לגשרת ע"י REST ו/או SOAP.
- שיתוף של נתונים, בצורה מבוזרת, בין כמה שרתים. לעתים כאשר קצב הקריאה הוא גבוה מאוד.
- שמירה של כמות גדולה של נתונים סטטיסטיים לא מעובדים / מעובדים קלות - עבור עיבוד עתידי (מה שנקרא "Data Lake")
את הפעולות הבסיסיות ניתן לעשות דרך ה UI של אמזון:
- יצירת Bucket, וקביעת הגדרות שונות שלו.
- העלאת קבצים
- ניהול קבצים
- וכו'
ניתן להשתמש ב awscli בכדי לבצע פעולות על s3 מתוך command line:
- ליצור bucket (פקודת mb), להציג את רשימת הקבצים שנמצאים ב s3 (פקודת ls) או להעתיק קבצים בין s3 למחשב המקומי (פקודת cp), וכו'...
- פקודת sync - לסנכרן תיקיה מקומית מול bucket של s3. הפקודה תגרום רק לקבצים חדשים, בעלי גודל שונה, או תאריך עדכון חדש יותר מאשר ב s3 - להיות מועלים ל s3. הפרמטר delete-- יגרום לפקודה לנקות מ s3 קבצים שנמחקו מהמחשב המקומי.
דרך שלישית ומקובלת היא להשתמש ב Programmatic APIs.
אם אתם עובדים על "חלונות", יש כלי UI נחמד בשם S3 Browser, המאפשר לראות את ה Bucket ולבצע עליו פעולות בצורה נוחה (משהו כמו כלי FTP נוח).
על כל bucket יש מספר תכונות:
אם אתם עובדים על "חלונות", יש כלי UI נחמד בשם S3 Browser, המאפשר לראות את ה Bucket ולבצע עליו פעולות בצורה נוחה (משהו כמו כלי FTP נוח).
ה UI של S3 |
על כל bucket יש מספר תכונות:
- הרשאות: מי רשאי לגשת לקבצים ב bucket? ניתן לאפשר גישה ציבורית (ע"י HTTP url). ניתן גם לקבוע הרשאות ברמת הקובץ הבודד.
- ניהול גרסאות: כל שינוי לקובץ ב bucket ינוהל בגרסה (כולל מחיקה). ריבוי העותקים יגביר את העלויות, וניתן לקבוע מדיניות ("lifecycle rules") מתי ניתן למחוק עותקים ישנים או להעביר אותם ל AWS Glacier (אכסון זול בהרבה, במחיר גישה אטית לקבצים - יכול לקחת גם כמה שעות בכדי לעשות checkout לקובץ).
- האזנה לאירועים: ניתן להאזין להוספה / מחיקה / עדכון קבצים ב bucket, ולשלוח הודעה לאחד משלושה שירותים של AWS:
- Simple Notification Service (בקיצור SNS) - שירות ה publish/subscribe של אמזון. מאפשר לכמה לקוחות להירשם ל topic, ושולח את ההודעות ב push (ל HTTP endpoint, דוא"ל, או SMS).
- Simple Queue Service (בקיצור SQS) - שירות queues. על הלקוח לשלוף ביוזמתו את ההודעה מה queue, ומרגע זה - ההודעה כבר לא קיימת יותר. לעתים קרובות מחברים את SNS שישלח הודעות למספר SQS queues - אחד לכל נמען.
- AWS Lambda - בכדי להריץ פונקציה על בסיס השירות.
- אירוח אתרים סטטיים (Web Hosting) - על בסיס קבצי html/css/javascript שמועלים ל s3, בשילוב עם Route 53 (שירות ה DNS של אמזון).
- הצפנה (server side encryption): אמזון יכולה להצפין עבורנו את הנתונים הנשמרים ב s3, ע"פ מפתחות שאנו מספקים לה. אם מישהו פרץ לתשתיות של אמזון (או קיבל צו חיפוש פדרלי בארה"ב - למשל), הוא מוצא קבצים מוצפנים שאין בהם הרבה שימוש.
- אינטגרציה ל Cloudfront - שירות ה CDN של אמזון, המאפשר להנגיש קבצים המאוחסנים ב S3 בעלויות נמוכות יותר, ו latency קצר יותר (על חשבון: עד כמה מעודכנים הקבצים שניגשים אליהם).
- Multipart upload - המאפשר לחתוך קבצים גדולים לכמה parts ולטעון אותם במקבלים על גבי כמה HTTP connections.
- Logging - שמירת לוג של הפעולות שנעשו על ה Bucket.
התשלום ב S3 הוא לא רק עבור האחסון, אלא גם עבור תעבורת הרשת (הורדה). אם אתם חוששים שגורם צד שלישי מפנה לתוכן שלכם לשימושים שלא רציתם, אתם יכולים להגביל את אורך החיים של ה URLs או לחייב את מי שקורא את המשאבים לשלם על התעבורה (מה שלא מאפשר למשתמשים אנונימיים לגשת למשאב).
היבטים של Landscape
S3 הוא שירות ברמת ה Region, ובאופן אוטומטי תהיה רפליקציה של הנתונים בין ה Availability Zones השונים. הרפליקציה מתבצעת תוך כדי כתיבה, כך שאם קיבלתם OK על הפעולה - המידע שם ומסונכרן (בניגוד ל offline replication המתבצע מאוחר יותר).
שם של Bucket צריך להיות ייחודי ברמת כל ה Regions של AWS (כלומר: Globally unique ב Account).
שם האובייקט משפיע על האופן שבו S3 תעשה partition לנתונים, ולכן אם אתם זקוקים ל tps גבוה - כדאי לדאוג לשמות בעלות שונות גבוהה, ושאינם תלויים בדפוסים שלא מייצגים את דפוסי הגישה (למשל: לא להתחיל שם של אובייקט ב timestamp - כי יהיו קבצים רבים המתחילים באופן דומה). הנה פוסט בנושא, אם הנושא רלוונטי עבורכם.
Policies
על Bucket ניתן לקבוע policies, המוגדרים מכמה אלמנטים:
- Resources - על אילו משאבים (קבצים) ב bucket אנו רוצים להחיל את ה policy.
- Actions - אלו פעולות על הקבצים אנו רוצים להשפיע (upload, list, delete, וכו')
- Conditions - באלו תנאים יחול ה Policy: שעות פעילות מסוימות, regions של AWS, מצב של הקובץ, וכו'. בעצם ב conditions נמצא הכוח האמיתי של ה Policy.
- Effect - משמעות: allow/deny. אם יש סתירה בין policy של deny ל policy של allow - ה deny policy הוא זה שיכריע.
- Principal - החשבון ב AWS או IAM user עליו חל ה policy.
Policy לדוגמה יכול להיות הכנסת ססמה לפני מחיקה של קבצים מה Bucket, בכדי לצמצם את הסיכון שמישהו מוחק נתונים קריטיים, בטעות. ה Durability הגבוה של S3 הופך את הגורם האנושי לחלק המסוכן בשמירת המידע.
את ה policy מגדירים כקובץ json ע"פ מבנה מסוים, ועושים לו copy-paste לתוך ה UI (ב properties של bucket / הרשאות / policy). אמזון (בצדק) לא יצרו את ה UI המורכב שהיה נדרש בכדי לאפשר להגדיר policies בתוך ה UI של ה bucket. ניתן להשתמש ב AWS Policy Generator בכדי לייצר Policies (אך לא לערוך או למחוק) ואז להדביק את התוצאה ב UI של ה bucket properties.
Policy לדוגמה. מקור: אמזון |
סיכום
הנה עברנו בחינה מעמיקה של S3. היא לא הייתה ארוכה, בעיקר בגלל ש S3 הוא באמת... די פשוט.
S3 הוא מאבני הבניין היסודיות ביותר של AWS - וכדאי להכיר אותו היטב.
שיהיה בהצלחה!
---
לינקים רלונטיים
FAQ של אמזון על S3
המחירון של S3
Data encryption on S3
סקירה יפה! כמה הארות למי שלא מכיר:
השבמחק1. יש היום כבר ממש המון כלים שנכתבו מעל s3 ואכן s3browser הוא מעולה. אבל יש גם למשל גם את "אחיו" (מאותו היצרן) שנקרא tnt drive שמייצר דיסק וירטואלי מקומי מסונכרן לs3. פשוט מאוד ומגניב למדי (יש גם אחרים דומים) ולמעשה יכול לשמש כתחליף מסויים לbox ואחרים. ויש אלפי שירותים ותוכנות אחרות.
2.פרוטוקול התקשורת של s3 היום כל כך מוכר, ששרתי קבצים אחרים רבים מציעים תאימות אליו, קצת כמו ftp.
3. המון שרותי saas כמובן תואמים לשירות ומציעים יכולות נוספות אם אתה משתמש בs3 כבר. למשל cloudmailin.com, שזה שרות נחמד שנותן לקבל מיילים לכתובת מסויימת והצרופה ישר תשמר לs3 שלך (ותקבל קריאת http לאן שתבחר עם פרטי ההודעה)
תודה רבה עופר על התוספות!!
מחקאציין רק עוד נקודה אחת בהקשר זה: היכולת להפעיל את הכלים של Hadoop (בתצורת EMR) מעל S3 במקום HDFS (מערכת הקבצים של Hadoop).
כתמיד, מענין.
השבמחקשלום. תודה על הפוסט המעניין.
השבמחקלפי מה שאני מבין מהאתר של אמזון האחסון ה"קר" לטוח ארוך הוא בתשלום זול אך חודשי. לא חד פעמי כמו שהבנתי מהפוסט כאן.
היי אנונימי,
מחקאתה בוודאי מתכוון למה שכתבתי על Galcier בפוסט הקודם.
אתה בהחלט צודק, אני לא יודע איך הבנתי אז את הדברים באופן הזה. תיקנתי את הפוסט.
תודה על הפידבק,
ליאור