אירוח VPS בקנדה: מתי הוא באמת נחוץ?

האם ה־VPS שלכם צריך להיות בקנדה?

אירוח VPS בקנדה כדאי כאשר חוק או חוזה מחייבים שהנתונים יישארו בשטח קנדה. זו הסיבה המחייבת היחידה. זמן הלוך־חזור מחיבור ביתי בטורונטו אל מרכז נתונים בניו יורק הוא בערך 18 מילישניות, לעומת כ־3 מילישניות למרכז נתונים בטורונטו, וכמעט שום יישום Web אינו מסוגל להבחין בהבדל.

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

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

ריבונות נתונים: הדרישה המחייבת היחידה

PIPEDA (Personal Information Protection and Electronic Documents Act) הוא חוק הפרטיות הפדרלי של קנדה החל על המגזר הפרטי, והוא אינו מחייב להשאיר מידע אישי במדינה. החוק מתייחס להעברת נתונים למעבד מחוץ למדינה כאל העברה לצורך עיבוד: הארגון שלכם נשאר אחראי לנתונים, על המעבד לספק להם הגנה שוות־ערך, ועליכם ליידע את האנשים שהעברה כזו מתבצעת. Office of the Privacy Commissioner התייעץ בשנת 2019 בנושא החמרת הדרישה, ולאחר מכן השאיר את עמדתו הקיימת על כנה. לכן הטענה הנפוצה שלפיה PIPEDA מחייב אתכם לאחסן את הנתונים בקנדה שגויה, אף שחומרי שיווק רבים של ספקי אירוח חוזרים עליה.

כללי ריבונות אמיתיים אכן קיימים. הם חלים בתחומים מצומצמים יותר.

• Law 25 של Quebec מחייב לבצע הערכה לפני שליחת מידע אישי מחוץ לפרובינציה, והמידע חייב לקבל הגנה הולמת במקום שאליו הוא נשלח. הוראה זו בתוקף מאז September 2023. מדובר בתיעוד ובהחלטה שעליכם להיות מסוגלים להצדיק, ולא באיסור.
• כללים החלים על המגזר הציבורי מחייבים גופים ציבוריים ואת החברות המספקות להם שירותים. PIIDPA של Nova Scotia מגביל אחסון של מידע אישי מחוץ לקנדה. FIPPA של British Columbia כלל הוראה דומה עד שתוקן בשנת 2021, כדי לאפשר אחסון מחוץ למדינה לאחר ביצוע הערכה.
• עבודה עבור הממשלה הפדרלית כפופה למדיניות הענן של Government of Canada, המחייבת להשאיר נתונים ברמת Protected B ומעלה בקנדה.
• חוקי הפרטיות הפרובינציאליים בתחום הבריאות מוסיפים תנאים משלהם למיקום אחסון רשומות רפואיות, והם שונים מפרובינציה לפרובינציה.
• חוזים עם לקוחות ומכרזים ציבוריים הם הגורם הנפוץ ביותר בפועל. שאלון אבטחה שקובע "data at rest in Canada" מחייב אתכם לא פחות מחוק, משום שחתמתם עליו.

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

האם מרכז נתונים בקנדה נמצא מחוץ לתחולת החוק האמריקאי?

לא בפני עצמו. חוק ה־CLOUD האמריקאי (Clarifying Lawful Overseas Use of Data Act) חל על נתונים הנמצאים בחזקתו, במשמורתו או בשליטתו של ספק אמריקאי, ללא קשר למיקום החומרה. לכן אזור בטורונטו המופעל על ידי חברה אמריקאית נמצא בתחולת החוק. אם הדרישה האמיתית נוגעת להליך משפטי זר ולא למיקום גאוגרפי, הגורמים החשובים הם זהות מפעיל השירות וזהות הגורם שמחזיק במפתחות ההצפנה. כתובת קנדית של הבניין אינה מספקת לכך תשובה בפני עצמה.

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

traceroute vps.example.com

שמות ה־hop כוללים קודי ערים כגון nyc, chi או ash. שמות אלה הם אינדיקציה בלבד, והם עלולים להתיישן. לכן התייחסו אליהם כסיבה לפנות לספק ולא כהוכחה. עבור נתונים בתעבורה, התשובה האמינה היא הצפנה שבשליטתכם, ולא מפה. אם אתם רוצים נתיב פרטי בין המכונות שלכם, VPN פרטי מסוג WireGuard מספק נתיב שאינו תלוי במדינה שבה עובר הסיב האופטי.

זמן אחזור: מדדו אותו, אל תניחו אותו

האור בסיב אופטי עובר כ־200 ק"מ בכל אלפית שנייה, ולכן כל מרחק של 100 ק"מ מוסיף בערך 1 ms לזמן הלוך־וחזור, עוד לפני שמעורב ציוד כלשהו. המרחק מטורונטו לוונקובר הוא כ־3,400 ק"מ בקו ישר, וגדול יותר במסלול הכבל, ולכן הגבול התחתון הוא כ־40 ms. במסלולים אמיתיים הערך גבוה יותר.

[
  {
    "label": "Toronto",
    "rtt_ms": 3
  },
  {
    "label": "Montreal",
    "rtt_ms": 12
  },
  {
    "label": "New York",
    "rtt_ms": 18
  },
  {
    "label": "Chicago",
    "rtt_ms": 24
  },
  {
    "label": "Northern Virginia",
    "rtt_ms": 26
  },
  {
    "label": "Dallas",
    "rtt_ms": 42
  },
  {
    "label": "Vancouver",
    "rtt_ms": 62
  },
  {
    "label": "London",
    "rtt_ms": 88
  },
  {
    "label": "Frankfurt",
    "rtt_ms": 98
  }
]

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

כדאי לקרוא פעמיים שתי שורות. זמן ההלוך־וחזור מטורונטו למונטריאול הוא בערך 12 ms, קרוב מספיק כדי ששתי הערים יתפקדו כאזור אחד ברוב המקרים. זמן ההלוך־וחזור מטורונטו לוונקובר הוא בערך 62 ms, כלומר גדול יותר מהזמן מטורונטו ל־Northern Virginia, שעומד על 26 ms. העובדה ששירות נמצא בקנדה אינה אומרת שהוא קרוב למשתמשים שלכם.

בכל מקרה, לרוב ה־last mile הוא הגורם הדומיננטי. סיב אופטי ביתי מוסיף כמה אלפיות שנייה. חיבור כבלים מוסיף יותר כאשר הקו עמוס. חיבור סלולרי מוסיף עשרות אלפיות שנייה בפני עצמו. משתמש בטלפון בטורונטו עשוי לראות זמן אחזור של 50 ms לשרת בטורונטו, והעברת השרת ל־New York תשנה את חוויית השימוש שלו בכמה אחוזים בלבד.

כיצד לבדוק השהיה מהמקומות שבהם נמצאים המשתמשים

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

לאחר מכן מדדו משם. אי אפשר לבדוק השהיה מ־Vancouver מעמדה ב־Ottawa. שכרו VPS לפי שעה בעיר היעד למשך 20 דקות, והשמידו אותו לאחר מכן. בקשו מעמית או מלקוח להריץ פקודה אחת. אפשר גם להשתמש ברשת המדידות החינמית RIPE Atlas בכתובת https://atlas.ripe.net, הכוללת probes בערים קנדיות ומאפשרת להריץ מהן בדיקות ping.

sudo apt update && sudo apt install -y mtr-tiny traceroute iperf3
ping -c 20 vps.example.com

קראו את שתי השורות האחרונות.

20 packets transmitted, 20 received, 0% packet loss, time 19031ms
rtt min/avg/max/mdev = 17.412/18.006/19.882/0.594 ms

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

mtr --report --report-cycles 50 vps.example.com

mtr מציג את אובדן המנות בכל hop. אם הפקודה מסתיימת בשגיאת הרשאה, הריצו אותה עם sudo. hops באמצע הנתיב מציגים לעיתים קרובות אובדן שאינו אמיתי, משום שראוטרים נותנים למעני ICMP שהם יוצרים בעצמם את העדיפות הנמוכה ביותר. רק אובדן שנמשך עד השורה האחרונה מייצג אובדן שסובלת ממנו התעבורה שלכם. קראו תחילה את השורה התחתונה, ולאחר מכן עלו כלפי מעלה.

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

curl -o /dev/null -s -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://vps.example.com/

כל שדה מציג מספר מצטבר של שניות מתחילת הבקשה. connect פחות dns הוא סבב TCP אחד. tls פחות connect הוא ה־handshake. ttfb פחות tls הוא סבב נוסף, בתוספת הזמן שהיישום שלכם נדרש כדי להשיב. הפער האחרון הוא המקום שבו רוב האתרים האיטיים מאבדים את זמנם. ttfb של 0.8 s בנתיב קצר מצביע על בעיה ביישום, והעברת השרת לעיר אחרת לא תשנה זאת.

כדי למדוד throughput, הריצו את השרת על ה־VPS ואת הלקוח מהצד של המשתמש. iperf3 מאזין ב־TCP 5201, לכן פתחו את הפורט באמצעות ufw לצורך הבדיקה וסגרו אותו שוב לאחר שתסיימו.

iperf3 -s

iperf3 -c vps.example.com -t 20
iperf3 -c vps.example.com -t 20 -R
iperf3 -c vps.example.com -t 20 -P 8

-R הופך את כיוון הבדיקה, כך שתמדדו גם הורדה וגם העלאה. -P 8 פותח שמונה streams מקבילים. אם שמונה streams מהירים בהרבה מאחד, המגבלה היא חלון ה־TCP בנתיב ארוך ולא הקישור עצמו, משום ש־stream יחיד יכול להעביר רק חלון אחד בכל סבב. אותו חלון בנתיב אל Vancouver מעביר בערך שליש מכמות הנתונים לשנייה שהוא מעביר בנתיב אל New York. גיבויים למרחקים ארוכים מתנהגים באותה דרך, ולכן גיבויים מחוץ לאתר באמצעות restic מרגישים איטיים מול יעד מרוחק, גם בקו מהיר.

השאירו ping פועל בטרמינל שני בזמן ש־iperf3 עובד. אם זמן הסבב עולה מ־20 ms ל־300 ms במהלך ההעברה, מדובר ב־bufferbloat בציוד הגישה שלכם, ושום מיקום של data center לא יפתור זאת.

בצעו את המדידה יותר מפעם אחת, ומדדו גם בערב. העומס בשעה 9pm הוא הנתון שהמשתמשים שלכם חווים. הנתון של 4am הוא הנתון שדף מכירות יעדיף לצטט.

מהו זמן הלוך־חזור עבור עומס העבודה שלך

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

[
  {
    "label": "DNS lookup",
    "toronto_to_new_york_ms": 18,
    "toronto_to_vancouver_ms": 62
  },
  {
    "label": "TCP handshake",
    "toronto_to_new_york_ms": 18,
    "toronto_to_vancouver_ms": 62
  },
  {
    "label": "TLS 1.3 handshake",
    "toronto_to_new_york_ms": 18,
    "toronto_to_vancouver_ms": 62
  },
  {
    "label": "Request and first byte",
    "toronto_to_new_york_ms": 18,
    "toronto_to_vancouver_ms": 62
  },
  {
    "label": "All four round trips",
    "toronto_to_new_york_ms": 72,
    "toronto_to_vancouver_ms": 248
  }
]

חיפוש ה־DNS נשלח ל־resolver ולא לשרת שלך, ובדרך כלל נשמר במטמון. לכן ביקור חוזר מדלג עליו. בחישוב מקצה לקצה, טעינה קרה מתחילה בפיגור של 72 אלפיות השנייה במסלול ל־New York, ובפיגור של 248 אלפיות השנייה במסלול ל־Vancouver. שני הנתונים זניחים לעומת שאילתת מסד נתונים יחידה שאורכת 400 אלפיות השנייה. לאחר פתיחת החיבור, HTTP/2 ו־HTTP/3 מעבירים בקשות רבות במקביל על אותו חיבור, ולכן העלות משולמת פעם אחת ולא עבור כל קובץ. הצבת נכסים סטטיים ב־CDN (רשת להפצת תוכן) מבטלת למעשה את חשיבות העיר שבה נמצא שרת המקור עבור נכסים אלה. לכן מבקר מאירופה, שחווה 98 אלפיות השנייה ל־Toronto, עדיין יכול לקבל דף מהיר.

משחקי multiplayer בזמן אמת הם המקרה ההפוך, משום שזמן ההלוך־חזור הוא חלק מחוויית המשחק. זמן של פחות מכ־50 אלפיות השנייה מרגיש מיידי במשחק פעולה מהיר. סביב 80 אלפיות השנייה שחקנים מתחילים להבחין בעיכוב, ומעבר ל־120 אלפיות השנייה הם מאשימים את השרת. במקרה זה האזור אכן קובע אם המוצר טוב. שרתים בקצב משחק איטי יותר סלחניים בהרבה, ולכן הפעלת שרת Minecraft ב־VPS יכולה להתמודד עם מרחקים שהיו פוגעים במשחק יריות.

מסדי נתונים הם המקום שבו בחירת האזור עלולה לגרום נזק ממשי. לעולם אל תציב את היישום באזור אחד ואת מסד הנתונים באזור אחר. כל שאילתה היא סבב הלוך־חזור. דף שמבצע 40 שאילתות משלם על 40 סבבים כאלה: בעלות של 18 אלפיות השנייה לכל שאילתה, מדובר בכמעט שנייה. בעלות של 62 אלפיות השנייה לכל שאילתה, מדובר ביותר משתי שניות. זאת בדף שנמדד ב־30 אלפיות השנייה כאשר מסד הנתונים נמצא באותו שרת. שכפול אסינכרוני לאזור אחר מתאים לעותקי קריאה ולהתאוששות מאסון. commit סינכרוני על גבי מסלול ארוך מוסיף את זמן המסלול לכל כתיבה.

סשנים אינטראקטיביים נמצאים באמצע. SSH נשאר נוח עד בערך 100 אלפיות השנייה, ומרגיש איטי מעל ערך זה, משום שכל הקשה ממתינה לחזרת ההד שלה. mosh חוזה את ההד באופן מקומי ומסתיר את רוב העיכוב. Webhooks ו־API פנימיים צריכים להימצא תמיד באותו אזור שבו נמצא השירות שאליו הם קוראים.

חיוב, מטבע ומס

תשלום בדולרים קנדיים מונע את עמלת העסקה במטבע זר שחברת האשראי שלך גובה, בדרך כלל בשיעור של כ־2.5% נכון לאוגוסט 2026, ומשאיר את הנהלת החשבונות שלך במטבע אחד. ספק קנדי כולל בחשבונית GST או HST, ועסק רשום יכול לדרוש את הסכום כזיכוי מס תשומות. זו שאלה פיננסית, ולכן התשובה לה צריכה להיות פיננסית; היא לעולם לא צריכה לקבוע לאן מנות הרשת ינותבו. כדי להבין כמה שרת עולה בפועל וכיצד להשוות בין תוכניות בלי להיתפס לתמחור בעת החידוש, קראו על העלות החודשית בפועל של VPS.

המחיר של שוק קטן יותר

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

• פחות ספקים מתחרים על כספכם, ולכן המחיר לכל גיגה-בייט של RAM או אחסון בדרך כלל גבוה יותר עבור אותה קטגוריית מכונה.
• הקיבולת מרוכזת בטורונטו ובמונטריאול, ויש פחות ממנה בוונקובר ובקלגרי. אזור קנדי שני לצורכי failover משמעותו לעיתים נתיב ארוך, או יציאה מהמדינה בכל מקרה.
• ספק אזורי קטן עשוי להפעיל בניין אחד המחובר לספק upstream אחד או שניים. שאלו כמה ספקים כאלה קיימים, ומה קורה כאשר אחד מהם כושל.
• מגוון החומרה מצומצם יותר. קל יותר למצוא מופעים גדולים ומכונות GPU באזורים בארצות הברית, ולכן ייתכן ש־GPU VPS בגודל הרצוי לא יהיה זמין בעיר הרצויה.
• היקף התמיכה אצל ספק קטן הוא שאלה מעשית, ולא שאלה שיווקית. שאלו מתי אדם זמין.

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

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

מתי אירוח VPS בקנדה הוא הבחירה הנכונה

1. חוק, חוזה או מדיניות של גוף ציבורי מציינים את קנדה. אירחו בקנדה. שום דבר אחר בפוסט הזה אינו חל, וכדאי לקבל מהספק התחייבות בכתב בנוגע למיקום הנתונים.
2. המשתמשים שלכם נמצאים במטרופולין קנדי אחד, ועומס העבודה מוגבל לפי זמן האחזור: משחקים מרובי־משתתפים, קול, שולחנות עבודה מרוחקים או מסחר. אירחו בעיר הקרובה ביותר, ומדדו את שתי האפשרויות לפני חתימה על חוזה.
3. המשתמשים שלכם פרוסים ברחבי המדינה. Toronto או Montreal מכסות את החלק הגדול ביותר של האוכלוסייה, ו־CDN לפני נכסים סטטיים ישפר את החוויה של מבקר מ־Vancouver יותר מהעברת שרת המקור.
4. כל השאר, כלומר רוב המקרים. בחרו לפי המחיר ולפי החומרה שתקבלו בפועל, ולאחר מכן בדקו כיצד נראית התמיכה בשעה 2 לפנות בוקר. בצעו benchmark למועמד תחילה, משום ששתי תוכניות עם אותו מפרט על הנייר אינן מספקות בהכרח ביצועים זהים: כיצד לבצע benchmark נכון ל־VPS.

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

FAQ

האם PIPEDA מחייב את שמירת הנתונים שלי בקנדה?

לא. PIPEDA (חוק ההגנה על מידע אישי ומסמכים אלקטרוניים) אינו כולל כלל בדבר מיקום הנתונים במגזר הפרטי. שליחת מידע אישי למעבד במדינה אחרת היא העברה לצורך עיבוד: הארגון שלכם נשאר אחראי לנתונים, על המעבד להגן עליהם ברמה דומה, ועליכם ליידע את האנשים שהדבר מתבצע. Office of the Privacy Commissioner בחן שינוי של עמדה זו במסגרת התייעצות בשנת 2019, ולאחר מכן הותיר אותה על כנה. דרישות למיקום נתונים נובעות ממקורות אחרים: הערכה לפי Law 25 של Quebec, חוקים החלים על המגזר הציבורי כגון PIIDPA של Nova Scotia, הנחיית הענן של Government of Canada, או סעיף בחוזה שלכם מול הלקוח.

האם משתמשים קנדיים יבחינו בכך שהשרת נמצא בארצות הברית?

ביישום אינטרנט רגיל, לא. הלוך ושוב בין Toronto ל־New York נמשך כ־18 ms, ובין Toronto ל־Northern Virginia כ־26 ms; בשני המקרים מדובר בזמן קצר יותר מהזמן בין Toronto ל־Vancouver, שעומד על 62 ms. משתמשים יבחינו בזמן תגובת השרת ובמשקל הדף זמן רב לפני שיבחינו ב־20 ms של תעבורת רשת. הם כן יבחינו בכך במשחקים בזמן אמת, בשיחות קוליות ובכל מצב שבו אדם אחד מגיב לאדם אחר.

האם מרכז נתונים קנדי נמצא מחוץ לתחולת החוק האמריקאי?

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

כיצד מודדים שיהוי מעיר שבה איני מתגורר?

שכרו VPS לפי שעה באותה עיר, הריצו ping -c 20 ו־mtr --report --report-cycles 50 אל השרת שלכם, ולאחר מכן מחקו את ה־VPS. רשת RIPE Atlas היא חלופה חינמית, עם probes בערים קנדיות. אם ICMP חסום, מדדו את הבקשה האמיתית באמצעות curl -o /dev/null -s -w '%{time_connect} %{time_starttransfer}\n' https://your.server/, שמציג את זמן הלוך ושוב של TCP ואת הזמן המלא עד קבלת ה־byte הראשון.