✕ סגור 
צור קשר
תודה על ההתעניינות .

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form

שימוש בענן כתשתית גלובלית

אייל אסטרין
|
May 7, 2020
alt="blogs"
alt="blogs"
alt="blogs"
Events
Event
title="Google"

שימוש בענן כתשתית גלובלית

קיימת כמות אדירה של מסמכים והמלצות כיצד להקים תשתית ענן, כאשר הלקוח ממוקם באזור גיאוגרפי (region) מסוים, אך מה קורה במידה ואנו ארגון המספק מידע או שירותים ללקוחות מכל רחבי הגלובוס?

דוגמת לשירותים שכאלו - אתרי e-commerce, שירותי streaming, אתרי חדשות, פלטפורמת משחקים, שירותי IoT ועוד.

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

 

רקע

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

בתרחישים מסוימים (דוגמת Streaming media), ייתכן שנרצה לסנכרן את אותו התוכן לאזור שונים בעולם.

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

 

כאשר בוחנים את הצורך לבנות ארכיטקטורה גלובלית, קיימות מספר סיבות:


• מהירות גישה למידע ללקוח הקצה

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


• התאוששות מאסון (Disaster recovery)

- Active-Active Site – פתרון יקר, אך מאפשר התאוששות מהירה מאסון, במידה ומבצעים סנכרון מידע בזמן אמת בין אזורים גיאוגרפיים שונים

- Active-Passive Site – פתרון המאפשר התאוששות מאסון, אך מחייב מנגנון סנכרון מידע והעברה ידנית של תעבורת DNS בין אתרים, וכן החלפת תפקיד בסיסי נתונים מ-Replica ל-Master role


• דרישות רגולציה או דרישות הנוגעות ללקוח עצמו

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

 

ארכיטקטורה לדוגמא




היבטי תקשורת

כאשר אנו בונים ארכיטקטורה גלובלית, הדבר הראשון אותו נרצה לבחון, מנקודת המבט של הלקוח (דפדפן, מכשיר mobile, התקן IoT וכו') הוא נושא התקשורת.


• שירותי DNS – באמצעות שירותים אלו, הלקוח ניגש לתשתית אותה אנו בונים מכיוון האינטרנט.

להלן מספר דוגמאות לשירותי DNS המסוגלים לשרת תשתית גלובלית:

- Amazon Route 53 – שירות DNS הפרוש ברחבי העולם ומאפשר להגדיר חוקי גישה למשאבים על-בסיס מיקום גיאוגרפי

- Azure Traffic Manager – שירות המאפשר הפניית תעבורת תקשורת על-בסיס פניות DNS

- Google Cloud DNS – שירות DNS הפרוש ברחבי העולם ומאפשר להגדיר חוקי גישה למשאבים


• שירותי CDN – תשתית גלובלית הפרוסה ברחבי העולם ומאפשרת ללקוח גישה מהירה וקרובה ככל האפשר (באמצעות caching) למשאבים.

להלן מספר דוגמאות לשירותי CDN:

-  Amazon CloudFront – תשתית CDN הפרוסה ברחבי העולם ב-Edge Locations

- Azure CDN – תשתית CDN הפרוסה ברחבי העולם (במקומות מסוימים מבוססת על תשתית ה-CDN של Akamai)

- Google Cloud CDN – תשתית CDN הפרוסה ברחבי העולם, כחלק מהתשתית הגלובלית של Google


• הגנה מפני מתקפות תקשורת ומתקפות אפליקטיביות – מכיוון שאנו בונים תשתית החשופה לגישה מכיוון כל מקום ברחבי האינטרנט, נרצה להגן על התשתית ולהיות מסוגלים להשתלב עם שירותים אחרים (דוגמת DNS, Load-Balancing וכו').

להלן מספר דוגמאות לשירותי הגנה על תשתית גלובלית:

- AWS Shield – שירות גלובלי להגנה מפני מתקפות DDoS, המכיל יכולות WAF

- Azure Front Door – שירות גלובלי להגנה מפני מתקפות DDoS, המכיל יכולות WAF

- Google Cloud Armor - שירות גלובלי להגנה מפני מתקפות DDoS, המכיל יכולות WAF


• שירותי Load-Balancing – שירותים המאפשרים פיזור עומסי תקשורת בין מספר data centers או מספר אזורים גיאוגרפיים.

להלן מספר דוגמאות לשירותי Load-Balancing:

- Amazon Application Load Balancer – שירות Load Balancer בשכבה 7 של מודל OSI (שכבת האפליקציה). אומנם לא מדובר בשירות גלובלי, אך באמצעות הפניית תעבורת DNS משירות Route53, ניתן לבנות תשתית אשר תספק מענה ללקוחות מכל העולם

- AWS Global Accelerator – שירות גלובלי המאפשר להאיץ את התעבורה לאפליקציה, תוך שימוש בכתובת IP אחידה מכל מקום בעולם, התומך בתעבורת HTTP/HTTPS, TCP/UDP

- Azure Front Door – שירות Load Balancer גלובלי עבור תעבורת HTTP

- Google Cloud Load Balancing – שירות Load Balancer גלובלי, בעל כתובת IP אחידה מכל מקום בעולם, התומך בתעבורת HTTP/HTTPS, TCP/SSL ו-UDP


היבטי אחסון קבצים

כמו בכל מערכת, קיים סיכוי גבוה שנרצה לשתף תוכן סטאטי (קבצים) באזורים שונים בעולם, בין אם מדובר במקור (origin) ממנו נשתף תוכן דרך שירות CDN, בקבצי הגדרות, גיבויים ועוד.


• שירותי Object Storage – שירותים אלו מאפשרים לנו לאחסן קבצים לצורך קריאה או עדכון.

להלן מספר דוגמאות של שירותי Object Storage:

- Amazon S3 – שירות אחסון קבצים מנוהל. אומנם לא מדובר בשירות גלובלי, אך באמצעות הפעלת יכולת Cross-Region Replication, ניתן לשכפל קבצים המאוחסנים ב-S3 bucket בין אזורים גיאוגרפיים מרוחקים

- Azure Blob Storage – שירות אחסון קבצים מנוהל. אומנם לא מדובר בשירות גלובלי, אך באמצעות הפעלת יכולת Geo Redundant Storage או Geo Zone Redundant Storage, ניתן לשכפל קבצים המאוחסנים ב-Blob storage בין אזורים גיאוגרפיים מרוחקים

- Google Cloud Storage – שירות אחסון קבצים גלובלי ומנוהל, המאפשר אחסון קבצים ושכפול אוטומטי בין אזורים גיאוגרפיים מרוחקים


היבטי אחסון מידע בבסיסי נתונים

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

• בסיסי נתונים רלציוניים (Relational databases) – בסיסי נתונים המיועדים לאחסון מידע במבנה טבלאי מוגדר.

להלן מספר דוגמאות של Relational databases:

- Amazon Aurora – בסיס נתונים מנוהל מבוסס מנוע MySQL או PostgreSQL. באמצעות יכולת Amazon Aurora Global Database, ניתן לבנות תשתית של בסיס נתונים בין מספר אזורים גיאוגרפיים מרוחקים

- Azure SQL Database – בסיס נתונים מנוהל מבוסס מנוע MS-SQL. אומנם לא מדובר בשירות גלובלי, אך באמצעות יכולת Active Geo-Replication ו-Automatic Asynchronous Replication, ניתן לבצע שכפול אסינכרוני של מידע בין אזורים גיאוגרפיים מרוחקים

- Google Cloud Spanner – בסיס נתונים גלובלי ומנוהל, באמצעותו ניתן לבנות תשתית לשכפול מידע (בתצורת read/write) בין מספר אזורים גיאוגרפיים מרוחקים


• בסיסי נתונים מבוססי מנוע NoSQL – בסיסי נתונים המיועדים לאחסון כמויות גדולות של מידע ללא מבנה מוגדר (unstructured data).

להלן מספר דוגמאות של NoSQL databases:

- Amazon DynamoDB – שירות NoSQL מנוהל. באמצעות יכולת Global Tables ניתן לבנות תשתית אשר תתמוך בשכפול מידע (בתצורת read/write) בין מספר אזורים גיאוגרפיים מרוחקים

- Azure Cosmos DB – שירות NoSQL גלובלי, באמצעותו ניתן לבנות תשתית לשכפול מידע (בתצורת read/write) בין מספר אזורים גיאוגרפיים מרוחקים

- Google Cloud Bigtable – שירות NoSQL גלובלי, באמצעותו ניתן לבנות תשתית לשכפול מידע (בתצורת read/write) בין מספר אזורים גיאוגרפיים מרוחקים

היבטי עלויות

כאשר מתכננים ארכיטקטורה גלובלית, כדאי לקחת בחשבון את נושא העלויות, דוגמת:

• עלויות שירותים – בחלק מהותי מהפתרונות המופיעים במאמר זה, פתרון גלובלי מחייב רישוי Premium

• עלויות תעבורת תקשורת – סנכרון מידע בין אזורים גיאוגרפיים (cross region replication), אשר עובר על גבי רשת האינטרנט, טומן בחובו עלויות תעבורת תקשורת יוצאת (egress traffic)


היבטי תפעול

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

• פריסה אפליקציות ושדרוגים (DevOps) – היכולת לבצע פריסה מדורגת של אפליקציות (או שדרוגים) על פני מספר אזורים גיאוגרפיים

• Source / Configuration Registry – הצורך בבניית registry אחיד בו יאוחסנו הגדרות, Container images וכל מידע אחר אותו נדרש לסנכרן בין אזורים גיאוגרפיים על-מנת לבנות תשתית אחידה בכל העולם

• ניטור – הצורך בניטור שוטף של שירותים רבים (החל מזמינות, דרך בעיית משאבים ו-scale), על פני מספר אזורים גיאוגרפיים

• אמינות המידע (Data integrity / consistency) – היכולת לוודא כי מידע מסונכרן ומאוחסן בצורה אחידה על פני מספר אזורים גאוגרפיים

• זמינות – היכולת לוודא זמינות השירותים, על פני מספר אזורים גיאוגרפיים

• התאוששות מאסון / Disaster Recovery – היכולת לבצע בדיקות DR באזורים גיאוגרפיים מרוחקים, לרבות היכולת להתמודד עם תקלות ומעבר תעבורת לקוחות מאזור גיאוגרפי אחד לאזור אחר

• אבטחת מידע / Governance – היכולת לאכוף הרשאות גישה והגדרות אבטחת מידע על-פני מספר אזורים גיאוגרפיים

• תאימות לרגולציות – היכולת לקיים תשתית גלובלית, תוך שמירה על הנחיות רגולציה ופרטיות באזור גיאוגרפיים מסוימים (דוגמת ה-GDPR באירופה)


סיכום

במאמר זה ביצעתי סקירה של ההיבטים וההשלכות בבניית ארכיטקטורה גלובאלית אשר מאפשרת לארגונים scale ושירות יותר טוב ללקוחות ע"פ מקורם.

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

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

Additional references:
• The quest for availability in the cloud
https://read.acloud.guru/the-quest-for-availability-771fa8a94a7c
• How to build a multi-region active-active architecture on AWS
https://read.acloud.guru/why-and-how-do-we-build-a-multi-region-active-active-architecture-6d81acb7d208
• Build a serverless multi-region, active-active backend solution in an hour
https://read.acloud.guru/building-a-serverless-multi-region-active-active-backend-36f28bed4ecf
• Build a serverless multi-region, active-active backend solution — within a VPC
https://read.acloud.guru/adding-support-for-vpc-build-a-serverless-multi-region-active-active-backend-solution-d80d25157688
• Multi-region serverless backend — reloaded
https://medium.com/@adhorn/multi-region-serverless-backend-reloaded-1b887bc615c0
• Architecting Multi-Region SaaS Solutions on AWS
https://aws.amazon.com/blogs/apn/architecting-multi-region-saas-solutions-on-aws/
• Run a web application in multiple Azure regions for high availability
https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/app-service-web-app/multi-region
• Run an N-tier application in multiple Azure regions for high availability
https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/n-tier/multi-region-sql-server
• Choosing the right architecture for global data distribution, based on GCP
https://cloud.google.com/solutions/architecture/global-data-distribution
• Architecture: Scalable commerce workloads using microservices, based on GCP
https://cloud.google.com/solutions/architecture/scaling-commerce-workloads-architecture
• Choosing the right load balancer in Google Cloud
https://medium.com/google-cloud/choosing-the-right-load-balancer-9ec909148a85 
• Spanning the Globe without Google Spanner
https://medium.com/yugabyte/spanning-the-globe-without-google-spanner-c7c8683dac65 
• My cheat sheet for choosing a database on GCP
https://medium.com/@hello_92179/my-cheat-sheet-for-choosing-the-right-database-on-gcp-d0f3fe8c2360 



המאמר נכתב ע"י אייל אסטרין, ארכיטקט ענן במרכז החישובים הבינאוניברסיטאי ותמיר דרשר, ארכיטקט ראשי ב-Clarizen



שימוש בענן כתשתית גלובלית

קיימת כמות אדירה של מסמכים והמלצות כיצד להקים תשתית ענן, כאשר הלקוח ממוקם באזור גיאוגרפי (region) מסוים, אך מה קורה במידה ואנו ארגון המספק מידע או שירותים ללקוחות מכל רחבי הגלובוס?

דוגמת לשירותים שכאלו - אתרי e-commerce, שירותי streaming, אתרי חדשות, פלטפורמת משחקים, שירותי IoT ועוד.

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

 

רקע

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

בתרחישים מסוימים (דוגמת Streaming media), ייתכן שנרצה לסנכרן את אותו התוכן לאזור שונים בעולם.

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

 

כאשר בוחנים את הצורך לבנות ארכיטקטורה גלובלית, קיימות מספר סיבות:


• מהירות גישה למידע ללקוח הקצה

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


• התאוששות מאסון (Disaster recovery)

- Active-Active Site – פתרון יקר, אך מאפשר התאוששות מהירה מאסון, במידה ומבצעים סנכרון מידע בזמן אמת בין אזורים גיאוגרפיים שונים

- Active-Passive Site – פתרון המאפשר התאוששות מאסון, אך מחייב מנגנון סנכרון מידע והעברה ידנית של תעבורת DNS בין אתרים, וכן החלפת תפקיד בסיסי נתונים מ-Replica ל-Master role


• דרישות רגולציה או דרישות הנוגעות ללקוח עצמו

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

 

ארכיטקטורה לדוגמא




היבטי תקשורת

כאשר אנו בונים ארכיטקטורה גלובלית, הדבר הראשון אותו נרצה לבחון, מנקודת המבט של הלקוח (דפדפן, מכשיר mobile, התקן IoT וכו') הוא נושא התקשורת.


• שירותי DNS – באמצעות שירותים אלו, הלקוח ניגש לתשתית אותה אנו בונים מכיוון האינטרנט.

להלן מספר דוגמאות לשירותי DNS המסוגלים לשרת תשתית גלובלית:

- Amazon Route 53 – שירות DNS הפרוש ברחבי העולם ומאפשר להגדיר חוקי גישה למשאבים על-בסיס מיקום גיאוגרפי

- Azure Traffic Manager – שירות המאפשר הפניית תעבורת תקשורת על-בסיס פניות DNS

- Google Cloud DNS – שירות DNS הפרוש ברחבי העולם ומאפשר להגדיר חוקי גישה למשאבים


• שירותי CDN – תשתית גלובלית הפרוסה ברחבי העולם ומאפשרת ללקוח גישה מהירה וקרובה ככל האפשר (באמצעות caching) למשאבים.

להלן מספר דוגמאות לשירותי CDN:

-  Amazon CloudFront – תשתית CDN הפרוסה ברחבי העולם ב-Edge Locations

- Azure CDN – תשתית CDN הפרוסה ברחבי העולם (במקומות מסוימים מבוססת על תשתית ה-CDN של Akamai)

- Google Cloud CDN – תשתית CDN הפרוסה ברחבי העולם, כחלק מהתשתית הגלובלית של Google


• הגנה מפני מתקפות תקשורת ומתקפות אפליקטיביות – מכיוון שאנו בונים תשתית החשופה לגישה מכיוון כל מקום ברחבי האינטרנט, נרצה להגן על התשתית ולהיות מסוגלים להשתלב עם שירותים אחרים (דוגמת DNS, Load-Balancing וכו').

להלן מספר דוגמאות לשירותי הגנה על תשתית גלובלית:

- AWS Shield – שירות גלובלי להגנה מפני מתקפות DDoS, המכיל יכולות WAF

- Azure Front Door – שירות גלובלי להגנה מפני מתקפות DDoS, המכיל יכולות WAF

- Google Cloud Armor - שירות גלובלי להגנה מפני מתקפות DDoS, המכיל יכולות WAF


• שירותי Load-Balancing – שירותים המאפשרים פיזור עומסי תקשורת בין מספר data centers או מספר אזורים גיאוגרפיים.

להלן מספר דוגמאות לשירותי Load-Balancing:

- Amazon Application Load Balancer – שירות Load Balancer בשכבה 7 של מודל OSI (שכבת האפליקציה). אומנם לא מדובר בשירות גלובלי, אך באמצעות הפניית תעבורת DNS משירות Route53, ניתן לבנות תשתית אשר תספק מענה ללקוחות מכל העולם

- AWS Global Accelerator – שירות גלובלי המאפשר להאיץ את התעבורה לאפליקציה, תוך שימוש בכתובת IP אחידה מכל מקום בעולם, התומך בתעבורת HTTP/HTTPS, TCP/UDP

- Azure Front Door – שירות Load Balancer גלובלי עבור תעבורת HTTP

- Google Cloud Load Balancing – שירות Load Balancer גלובלי, בעל כתובת IP אחידה מכל מקום בעולם, התומך בתעבורת HTTP/HTTPS, TCP/SSL ו-UDP


היבטי אחסון קבצים

כמו בכל מערכת, קיים סיכוי גבוה שנרצה לשתף תוכן סטאטי (קבצים) באזורים שונים בעולם, בין אם מדובר במקור (origin) ממנו נשתף תוכן דרך שירות CDN, בקבצי הגדרות, גיבויים ועוד.


• שירותי Object Storage – שירותים אלו מאפשרים לנו לאחסן קבצים לצורך קריאה או עדכון.

להלן מספר דוגמאות של שירותי Object Storage:

- Amazon S3 – שירות אחסון קבצים מנוהל. אומנם לא מדובר בשירות גלובלי, אך באמצעות הפעלת יכולת Cross-Region Replication, ניתן לשכפל קבצים המאוחסנים ב-S3 bucket בין אזורים גיאוגרפיים מרוחקים

- Azure Blob Storage – שירות אחסון קבצים מנוהל. אומנם לא מדובר בשירות גלובלי, אך באמצעות הפעלת יכולת Geo Redundant Storage או Geo Zone Redundant Storage, ניתן לשכפל קבצים המאוחסנים ב-Blob storage בין אזורים גיאוגרפיים מרוחקים

- Google Cloud Storage – שירות אחסון קבצים גלובלי ומנוהל, המאפשר אחסון קבצים ושכפול אוטומטי בין אזורים גיאוגרפיים מרוחקים


היבטי אחסון מידע בבסיסי נתונים

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

• בסיסי נתונים רלציוניים (Relational databases) – בסיסי נתונים המיועדים לאחסון מידע במבנה טבלאי מוגדר.

להלן מספר דוגמאות של Relational databases:

- Amazon Aurora – בסיס נתונים מנוהל מבוסס מנוע MySQL או PostgreSQL. באמצעות יכולת Amazon Aurora Global Database, ניתן לבנות תשתית של בסיס נתונים בין מספר אזורים גיאוגרפיים מרוחקים

- Azure SQL Database – בסיס נתונים מנוהל מבוסס מנוע MS-SQL. אומנם לא מדובר בשירות גלובלי, אך באמצעות יכולת Active Geo-Replication ו-Automatic Asynchronous Replication, ניתן לבצע שכפול אסינכרוני של מידע בין אזורים גיאוגרפיים מרוחקים

- Google Cloud Spanner – בסיס נתונים גלובלי ומנוהל, באמצעותו ניתן לבנות תשתית לשכפול מידע (בתצורת read/write) בין מספר אזורים גיאוגרפיים מרוחקים


• בסיסי נתונים מבוססי מנוע NoSQL – בסיסי נתונים המיועדים לאחסון כמויות גדולות של מידע ללא מבנה מוגדר (unstructured data).

להלן מספר דוגמאות של NoSQL databases:

- Amazon DynamoDB – שירות NoSQL מנוהל. באמצעות יכולת Global Tables ניתן לבנות תשתית אשר תתמוך בשכפול מידע (בתצורת read/write) בין מספר אזורים גיאוגרפיים מרוחקים

- Azure Cosmos DB – שירות NoSQL גלובלי, באמצעותו ניתן לבנות תשתית לשכפול מידע (בתצורת read/write) בין מספר אזורים גיאוגרפיים מרוחקים

- Google Cloud Bigtable – שירות NoSQL גלובלי, באמצעותו ניתן לבנות תשתית לשכפול מידע (בתצורת read/write) בין מספר אזורים גיאוגרפיים מרוחקים

היבטי עלויות

כאשר מתכננים ארכיטקטורה גלובלית, כדאי לקחת בחשבון את נושא העלויות, דוגמת:

• עלויות שירותים – בחלק מהותי מהפתרונות המופיעים במאמר זה, פתרון גלובלי מחייב רישוי Premium

• עלויות תעבורת תקשורת – סנכרון מידע בין אזורים גיאוגרפיים (cross region replication), אשר עובר על גבי רשת האינטרנט, טומן בחובו עלויות תעבורת תקשורת יוצאת (egress traffic)


היבטי תפעול

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

• פריסה אפליקציות ושדרוגים (DevOps) – היכולת לבצע פריסה מדורגת של אפליקציות (או שדרוגים) על פני מספר אזורים גיאוגרפיים

• Source / Configuration Registry – הצורך בבניית registry אחיד בו יאוחסנו הגדרות, Container images וכל מידע אחר אותו נדרש לסנכרן בין אזורים גיאוגרפיים על-מנת לבנות תשתית אחידה בכל העולם

• ניטור – הצורך בניטור שוטף של שירותים רבים (החל מזמינות, דרך בעיית משאבים ו-scale), על פני מספר אזורים גיאוגרפיים

• אמינות המידע (Data integrity / consistency) – היכולת לוודא כי מידע מסונכרן ומאוחסן בצורה אחידה על פני מספר אזורים גאוגרפיים

• זמינות – היכולת לוודא זמינות השירותים, על פני מספר אזורים גיאוגרפיים

• התאוששות מאסון / Disaster Recovery – היכולת לבצע בדיקות DR באזורים גיאוגרפיים מרוחקים, לרבות היכולת להתמודד עם תקלות ומעבר תעבורת לקוחות מאזור גיאוגרפי אחד לאזור אחר

• אבטחת מידע / Governance – היכולת לאכוף הרשאות גישה והגדרות אבטחת מידע על-פני מספר אזורים גיאוגרפיים

• תאימות לרגולציות – היכולת לקיים תשתית גלובלית, תוך שמירה על הנחיות רגולציה ופרטיות באזור גיאוגרפיים מסוימים (דוגמת ה-GDPR באירופה)


סיכום

במאמר זה ביצעתי סקירה של ההיבטים וההשלכות בבניית ארכיטקטורה גלובאלית אשר מאפשרת לארגונים scale ושירות יותר טוב ללקוחות ע"פ מקורם.

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

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

Additional references:
• The quest for availability in the cloud
https://read.acloud.guru/the-quest-for-availability-771fa8a94a7c
• How to build a multi-region active-active architecture on AWS
https://read.acloud.guru/why-and-how-do-we-build-a-multi-region-active-active-architecture-6d81acb7d208
• Build a serverless multi-region, active-active backend solution in an hour
https://read.acloud.guru/building-a-serverless-multi-region-active-active-backend-36f28bed4ecf
• Build a serverless multi-region, active-active backend solution — within a VPC
https://read.acloud.guru/adding-support-for-vpc-build-a-serverless-multi-region-active-active-backend-solution-d80d25157688
• Multi-region serverless backend — reloaded
https://medium.com/@adhorn/multi-region-serverless-backend-reloaded-1b887bc615c0
• Architecting Multi-Region SaaS Solutions on AWS
https://aws.amazon.com/blogs/apn/architecting-multi-region-saas-solutions-on-aws/
• Run a web application in multiple Azure regions for high availability
https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/app-service-web-app/multi-region
• Run an N-tier application in multiple Azure regions for high availability
https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/n-tier/multi-region-sql-server
• Choosing the right architecture for global data distribution, based on GCP
https://cloud.google.com/solutions/architecture/global-data-distribution
• Architecture: Scalable commerce workloads using microservices, based on GCP
https://cloud.google.com/solutions/architecture/scaling-commerce-workloads-architecture
• Choosing the right load balancer in Google Cloud
https://medium.com/google-cloud/choosing-the-right-load-balancer-9ec909148a85 
• Spanning the Globe without Google Spanner
https://medium.com/yugabyte/spanning-the-globe-without-google-spanner-c7c8683dac65 
• My cheat sheet for choosing a database on GCP
https://medium.com/@hello_92179/my-cheat-sheet-for-choosing-the-right-database-on-gcp-d0f3fe8c2360 



המאמר נכתב ע"י אייל אסטרין, ארכיטקט ענן במרכז החישובים הבינאוניברסיטאי ותמיר דרשר, ארכיטקט ראשי ב-Clarizen



לפרטים נוספים ויצירת קשר עם נציג אורקל

תודה הודעתך התקבלה

הודעתך לא התקבלה - נסה שוב מאוחר יותר

אייל אסטרין

הירשם לרשימת הדיוור של IsraelClouds

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form

מילון מונחיםהשירותים שלנו תנאי שימושהרשמה לניוזלטרמדיניות פרטיות