האם צריך VPS בקנדה? מה באמת קובע
PIPEDA אינו מחייב אחסון מידע בקנדה: גלו מתי חוזה או חוק כן מחייבים זאת, וכיצד למדוד את זמן ההלוך ושוב מהמיקום שבו נמצאים המשתמשים שלכם.
האם ה-VPS שלכם חייב להיות בקנדה?
כדאי לבחור באירוח VPS בקנדה כאשר חוק או חוזה מחייבים שהנתונים יישארו בשטח קנדה. זו הסיבה המחייבת היחידה. זמן הלוך ושוב מחיבור ביתי בטורונטו למרכז נתונים בניו יורק הוא כ-18 אלפיות השנייה, לעומת כ-3 אלפיות השנייה למרכז נתונים בטורונטו, וכמעט שום יישום אינטרנט אינו יכול להבחין בהבדל.
שלושה גורמים מובילים אנשים לבחור שרת בקנדה. ריבונות נתונים היא חובה משפטית, ולכן היא מכריעה את השאלה בפני עצמה. זמן האחזור ניתן למדידה, ובדרך כלל הוא קצר יותר מכפי שאנשים מצפים. חיוב בדולרים קנדיים הוא נוחות עבור מנהל החשבונות שלכם. בדקו אם הגורם הראשון חל עליכם לפני שתשקלו גורמים אחרים.
פוסט זה מסביר באופן כללי כיצד הכללים פועלים. אין לראות בו ייעוץ משפטי. אם חוק פרטיות מחייב את הארגון שלכם, קבלו את התשובה מהיועץ המשפטי שלכם.
ריבונות נתונים: הדרישה המחייבת היחידה
PIPEDA (חוק הגנת המידע האישי והמסמכים האלקטרוניים) הוא חוק הפרטיות הפדרלי של קנדה החל על המגזר הפרטי, והוא אינו מחייב להשאיר מידע אישי במדינה. החוק מתייחס להעברת נתונים למעבד מחוץ למדינה כאל העברה לצורך עיבוד: הארגון שלכם נשאר אחראי לנתונים, על המעבד לספק להם הגנה דומה, ועליכם ליידע את האנשים שהעברה כזו מתבצעת. Office of the Privacy Commissioner התייעץ בשנת 2019 בנוגע להחמרת דרישה זו, ולאחר מכן השאיר את עמדתו הקיימת. לכן הטענה הנפוצה שלפיה PIPEDA מחייב שהנתונים שלכם יאוחסנו בקנדה שגויה, אף שהיא חוזרת בחומרי שיווק רבים של שירותי אחסון.
כללי ריבונות אמיתיים אכן קיימים. הם חלים בתחומים מצומצמים יותר.
- Law 25 של Quebec מחייב לבצע הערכה לפני שליחת מידע אישי אל מחוץ לפרובינציה, ועל המידע לקבל הגנה הולמת במקום שאליו הוא מגיע. הוראה זו בתוקף מאז September 2023. מדובר בתיעוד ובהחלטה שעליכם להיות מסוגלים להצדיק, ולא באיסור.
- כללים החלים על המגזר הציבורי מחייבים גופים ציבוריים ואת החברות המספקות להם שירותים. PIIDPA של Nova Scotia מגביל אחסון של מידע אישי מחוץ לקנדה. FIPPA של British Columbia כלל הוראה דומה עד שתוקן בשנת 2021, כדי לאפשר אחסון במדינות זרות לאחר ביצוע הערכה.
- עבודות עבור הממשל הפדרלי כפופות להנחיות הענן של Government of Canada, המחייבות להשאיר נתונים ברמת Protected B ומעלה בקנדה.
- חוקי הפרטיות של מידע רפואי בפרובינציות מוסיפים תנאים משלהם לגבי המקום שבו ניתן לאחסן רשומות רפואיות, והם שונים מפרובינציה לפרובינציה.
- חוזים עם לקוחות ומכרזים ציבוריים הם הגורם הנפוץ ביותר בפועל. שאלון אבטחה הקובע "נתונים במנוחה בקנדה" מחייב אתכם באותה מידה כמו חוק, משום שחתמתם עליו.
הבדיקה המעשית פשוטה. האם אתם יכולים להפנות לסעיף המתאים? אם איש בארגון שלכם אינו יכול לציין את החוק או את החוזה המחייבים את קנדה, אתם מקבלים את ההחלטה על סמך זמן השהיה והמחיר.
האם מרכז נתונים קנדי נמצא מחוץ לסמכות החוקית של ארצות הברית?
לא כשלעצמו. חוק הענן של ארצות הברית (US CLOUD Act — Clarifying Lawful Overseas Use of Data Act) חל על נתונים הנמצאים בחזקתו, במשמורתו או בשליטתו של ספק אמריקאי, ללא קשר למיקום החומרה. לכן, אזור Toronto המופעל על ידי חברה אמריקאית נמצא בתחום תחולתו. אם הדרישה האמיתית נוגעת להליך משפטי זר ולא למיקום גאוגרפי, הגורמים החשובים הם זהות מפעיל השירות וזהות הגורם שמחזיק במפתחות ההצפנה. כתובת קנדית של הבניין אינה מספקת לכך תשובה בפני עצמה.
ניתוב הוא ההפתעה השנייה. תעבורת רשת בין שתי ערים בקנדה עוברת לעיתים דרך ארצות הברית, משום ששם התקיימו היסטורית קשרי peering זולים. חוקרים מכנים זאת ניתוב בומרנג. הפעילו traceroute לפני שתאמרו למישהו שהמנות שלכם לעולם אינן יוצאות מהמדינה.
traceroute vps.example.comשמות ה-hop כוללים קודי ערים כגון nyc, chi או ash. שמות אלה הם רמזים והם מתיישנים, לכן ראו בהם סיבה לפנות לספק ולא הוכחה. עבור נתונים בתעבורה, התשובה האמינה היא הצפנה שבשליטתכם, ולא מפה. אם אתם רוצים נתיב פרטי בין המכונות שלכם, VPN מסוג WireGuard באירוח עצמי מספק לכם נתיב שאינו תלוי במדינה שבה עובר הסיב האופטי.
זמן השהיה: יש למדוד אותו, ולא להניח אותו מראש
האור עובר בסיב במהירות של כ-200 ק"מ למילישנייה, ולכן כל מרחק של 100 ק"מ מוסיף בערך 1 ms לזמן הלוך-חזור, עוד לפני שמעורב ציוד כלשהו. המרחק בין Toronto ל-Vancouver הוא כ-3,400 ק"מ בקו ישר, והוא גדול יותר בתוואי הכבל, ולכן הגבול התחתון הוא כ-40 ms. מסלולים בפועל מניבים ערכים גבוהים יותר.
The data behind this chart
[
{
"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
}
]אלה נתונים אופייניים שפורסמו עבור קו צרכני בעל קישוריות טובה ב-Toronto. הם נקודת התחלה, ולא התחייבות. הנתונים שלכם תלויים ברשת הגישה שלכם ובקשרי ה-peering של הספק שלכם, והם משתנים במהלך היום.
כדאי לקרוא שוב שתי שורות. זמן ההלוך-חזור בין Toronto ל-Montreal הוא כ-12 ms, קרוב מספיק כדי ששתי הערים יתפקדו כאזור אחד ברוב המקרים. זמן ההלוך-חזור בין Toronto ל-Vancouver הוא כ-62 ms, כלומר גדול יותר מהזמן בין Toronto ל-Northern Virginia, שעומד על 26 ms. העובדה שהשרת נמצא בקנדה אינה אומרת שהוא קרוב למשתמשים שלכם.
בכל מקרה, מקטע ה-last mile הוא בדרך כלל הגורם הדומיננטי. סיב ביתי מוסיף כמה מילישניות. חיבור כבלים מוסיף יותר כאשר הקו עמוס. חיבור סלולרי מוסיף לבדו עשרות מילישניות. משתמש בטלפון ב-Toronto עשוי לראות זמן של 50 ms לשרת ב-Toronto, והעברת השרת ל-New York תשנה את חוויית השימוש שלו באחוזים בודדים.
כיצד לבדוק השהיה מהמקום שבו נמצאים המשתמשים
תחילה בדקו היכן המשתמשים שלכם נמצאים בפועל. כלי הניתוח שלכם כבר מפלחים את ההפעלות לפי עיר או אזור. הסתמכו על הנתונים האלה במקום לנחש לפי מיקום המשרד.
לאחר מכן בצעו את המדידה משם. אי אפשר לבדוק השהיה מ־Vancouver מעמדה באוטווה. שכּרו 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 msavg הוא המספר המרכזי. mdev הוא jitter, כלומר הפיזור בין החבילות. אובדן חבילות בנתיב קצר הוא תקלה שכדאי לבדוק. jitter גבוה פוגע בשיחות קוליות ובמשחקים יותר מממוצע מעט גבוה יותר, משום שהמקבל צריך לאגור נתונים לפי החבילה הגרועה ביותר ולא לפי החבילה האופיינית.
mtr --report --report-cycles 50 vps.example.commtr מציג את האובדן בכל 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 הוא תהליך לחיצת היד. ttfb פחות tls הוא הלוך־חזור נוסף, בתוספת הזמן שהיישום שלכם נדרש כדי להשיב. הפער האחרון הוא המקום שבו אתרים איטיים מאבדים בדרך כלל את רוב זמנם. ערך ttfb של 0.8 s בנתיב קצר מצביע על בעיה ביישום, והעברת השרת לעיר אחרת לא תשנה אותה.
למדידת throughput, הפעילו את השרת ב־VPS ואת הלקוח מהצד של המשתמש. iperf3 מאזין ב־TCP 5201, לכן פתחו את הפורט באמצעות ufw לצורך הבדיקה וסגרו אותו שוב לאחר שתסיימו.
iperf3 -siperf3 -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 centre לא יפתור זאת.
בצעו את המדידה יותר מפעם אחת, ובצעו אותה בערב. העומס בשעה 9pm הוא הנתון שהמשתמשים שלכם חווים. הנתון בשעה 4am הוא הנתון שעמוד מכירות יעדיף לצטט.
מה המשמעות של זמן הלוך־ושוב עבור עומס העבודה שלך
טעינה קרה של דף דורשת ארבעה סבבים של הלוך־ושוב לפני שהדפדפן יכול להציג דבר כלשהו.
The data behind this chart
[
{
"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 מתבצע מול פותר שמות ולא מול השרת שלך, והוא נשמר בדרך כלל במטמון. לכן ביקור חוזר מדלג עליו. בחישוב מקצה לקצה, טעינה קרה מתחילה בפיגור של 72 אלפיות השנייה בנתיב לניו יורק, ובפיגור של 248 אלפיות השנייה בנתיב לוונקובר. שני הנתונים האלה זניחים לעומת שאילתת מסד נתונים יחידה שאורכת 400 אלפיות השנייה. לאחר פתיחת החיבור, HTTP/2 ו-HTTP/3 מעבירים בקשות רבות במקביל על אותו חיבור. לכן העלות הזו משולמת פעם אחת ולא עבור כל קובץ. הצב נכסים סטטיים ב-CDN (רשת להפצת תוכן), ואז מיקומה של עיר המקור כבר אינו משפיע עליהם כלל. לכן מבקר מאירופה, שההשהיה שלו לטורונטו היא 98 אלפיות השנייה, עדיין יכול לקבל דף מהיר.
משחקים מרובי משתתפים בזמן אמת הם המקרה ההפוך, משום שהסבב הלוך־ושוב הוא חוויית המשתמש. השהיה של פחות מ-50 אלפיות השנייה מרגישה מיידית במשחק פעולה מהיר. שחקנים מתחילים להבחין בהשהיה בסביבות 80 אלפיות השנייה, ומעל 120 אלפיות השנייה הם מאשימים את השרת. במקרה הזה, האזור קובע בפועל אם המוצר טוב. שרתים בקצב משחק איטי יותר סלחניים בהרבה, ולכן הפעלת שרת Minecraft ב-VPS יכולה להתמודד עם מרחקים שהיו פוגעים במשחק יריות.
מסדי נתונים הם המקום שבו בחירת אזור עלולה לגרום נזק ממשי. לעולם אל תציב את היישום באזור אחד ואת מסד הנתונים שלו באזור אחר. כל שאילתה היא סבב הלוך־ושוב. דף שמבצע 40 שאילתות משלם על 40 סבבים כאלה: בעלות של 18 אלפיות השנייה לכל שאילתה, מדובר כמעט בשנייה שלמה; ובעלות של 62 אלפיות השנייה לכל שאילתה, מדובר ביותר משתי שניות. זאת בדף שנמדדה בו השהיה של 30 אלפיות השנייה כאשר מסד הנתונים היה באותו שרת. שכפול אסינכרוני לאזור אחר מתאים לעותקי קריאה ולהתאוששות מאסון. אישור סינכרוני של כתיבות לאורך נתיב ארוך מוסיף את זמן הנתיב לכל כתיבה יחידה.
הפעלות אינטראקטיביות נמצאות באמצע. SSH נשאר נוח עד בערך 100 אלפיות השנייה, ומרגיש איטי מעבר לכך, משום שכל הקשה ממתינה עד שההד שלה יחזור. mosh חוזה מקומית ומסתיר את רוב ההשהיה הזו. Webhooks וממשקי API פנימיים צריכים לפעול תמיד באותו אזור שבו נמצא השירות שאליו הם קוראים.
חיוב, מטבע ומס
תשלום בדולרים קנדיים מונע את עמלת העסקה במטבע זר שחברת האשראי גובה, בדרך כלל בשיעור של כ-2.5% נכון ל-August 2026, ומשאיר את הנהלת החשבונות שלכם במטבע אחד. ספק קנדי מנפיק חשבונית הכוללת GST או HST, ועסק רשום יכול לתבוע החזר בגין מס תשומות. זו שאלה פיננסית, ולכן התשובה לה צריכה להיות פיננסית. היא לעולם לא צריכה לקבוע לאן מנות הרשת נשלחות. למידע על העלות האמיתית של שרת ועל השוואת תוכניות בלי להיתפס למחירי חידוש, קראו כמה VPS באמת עולה בחודש.
עלות השוק הקטן יותר
קנדה היא שוק אחסון קטן בהשוואה לארצות הברית, ועצה כנה צריכה לכלול גם את מה שעליכם לוותר עליו.
- פחות ספקים מתחרים על כספכם, ולכן המחיר לכל גיגה-בייט של RAM או של שטח דיסק בדרך כלל גבוה יותר עבור אותה קטגוריית שרת.
- הקיבולת מרוכזת ב-Toronto וב-Montreal, ויש פחות ממנה ב-Vancouver וב-Calgary. אזור קנדי שני לצורך מעבר בעת כשל פירושו לעיתים נתיב ארוך, או יציאה מהמדינה בכל מקרה.
- ספק אזורי קטן עשוי להפעיל בניין אחד המחובר לספק תשתית אחד או לשניים. שאלו כמה ספקי תשתית קיימים, ומה קורה כאשר אחד מהם מושבת.
- מגוון החומרה מצומצם יותר. קל יותר למצוא מופעים גדולים ומכונות GPU באזורים בארצות הברית, ולכן ייתכן ש-VPS עם GPU בגודל הרצוי לא יהיה זמין בעיר הרצויה.
- היקף התמיכה אצל ספק קטן הוא שאלה מעשית, לא שאלה שיווקית. שאלו מתי נציג אנושי זמין.
Montreal היא החריגה מבחינת המחיר. החשמל ההידרואלקטרי של Quebec זול, והחורפים מפחיתים את עלויות הקירור, ולכן אזור Montreal מציע קיבולת רבה בתעריפים המתחרים באזורים בארצות הברית. אם הדרישה שלכם היא קנדה ולא עיר מסוימת, התחילו שם.
אם שכבות ה-VPS הקנדיות נראות קטנות מדי לעומס העבודה, השוו בין VPS לשרת ייעודי לפני שתחליטו שהבעיה היא המדינה.
מתי אירוח VPS בקנדה הוא הבחירה הנכונה
- חוק, חוזה או מדיניות של גוף ציבורי מציינים את קנדה. ארחו בקנדה. שום דבר אחר בפוסט הזה אינו חל, ועליכם לקבל מהספק גם התחייבות בכתב לדרישת המיקום.
- המשתמשים שלכם נמצאים במטרופולין קנדי אחד, ועומס העבודה מוגבל על-ידי זמן האחזור: משחקים מרובי-משתתפים, תקשורת קולית, שולחנות עבודה מרוחקים או מסחר. ארחו בעיר הקרובה ביותר ומדדו את שתי האפשרויות לפני חתימה על דבר.
- המשתמשים שלכם מפוזרים ברחבי המדינה. טורונטו או מונטריאול מכסות את החלק הגדול ביותר של האוכלוסייה, ו-CDN לפני נכסים סטטיים מועיל למבקר מוונקובר יותר מהעברת שרת המקור.
- כל השאר, כלומר רוב המקרים. בחרו לפי המחיר ולפי החומרה שתקבלו בפועל, ולאחר מכן בדקו כיצד נראית התמיכה בשעה 2am. בצעו בדיקת ביצועים למועמד תחילה, משום ששתי תוכניות עם אותו דף מפרטים אינן מספקות בהכרח אותם ביצועים: כיצד לבצע בדיקת ביצועים ל-VPS כראוי.
בכל אפשרות שתבחרו, כתבו את הסיבה לצד ההחלטה. האדם הבא שישאל אם השירות צריך להיות בקנדה ראוי לתשובה טובה יותר מניחוש, ואם התשובה הייתה אי-פעם סעיף בחוזה, מישהו יצטרך למצוא אותו שוב. לאחר שהשרת קיים, עשר הדקות הראשונות ב-VPS חדש חשובות יותר לאבטחה שלכם מאשר העיר שבה הוא נמצא.
FAQ
האם PIPEDA מחייב את השארת הנתונים שלי בקנדה?
לא. ל־PIPEDA (Personal Information Protection and Electronic Documents Act) אין כלל המחייב אחסון נתונים בקנדה במגזר הפרטי. שליחת מידע אישי למעבד במדינה אחרת היא העברה לצורך עיבוד: הארגון שלכם נשאר אחראי לנתונים, על המעבד להגן עליהם ברמה דומה, ועליכם ליידע את האנשים שהדבר מתבצע. Office of the Privacy Commissioner התייעץ בשנת 2019 בנוגע לשינוי עמדה זו, ולאחר מכן הותיר אותה על כנה. דרישות לאחסון נתונים בקנדה נובעות ממקורות אחרים: הערכת Law 25 של Quebec, חוקים החלים על המגזר הציבורי כגון PIIDPA של Nova Scotia, הנחיית הענן של Government of Canada, או סעיף בחוזה הלקוחות שלכם.
האם משתמשים קנדים יבחינו בשרת בארצות הברית?
ביישום אינטרנט רגיל, לא. הלוך ושוב בין Toronto ל־New York נמשך כ־18 אלפיות השנייה, ובין Toronto ל־Northern Virginia כ־26 אלפיות השנייה. בשני המקרים הזמן קצר יותר מהזמן בין Toronto ל־Vancouver, העומד על 62 אלפיות השנייה. משתמשים מבחינים בזמן תגובת השרת ובמשקל הדף זמן רב לפני שהם מבחינים ב־20 אלפיות שנייה של תעבורת רשת. הם כן מבחינים בכך במשחקים בזמן אמת, בשיחות קוליות ובכל מצב שבו אדם אחד מגיב לאדם אחר.
האם מרכז נתונים קנדי נמצא מחוץ לתחולת החוק האמריקאי?
לא באופן אוטומטי. 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 ואת הזמן המלא עד לקבלת הבייט הראשון.