درس های بدون سرور – مکان همه چیز است!

جامعه بدون سرور در مورد تأخیر زیاد صحبت می کند.

ما در مورد نحوه اتصال سرویس به سرویس صحبت می کنیم در طول زمان بهبود یا کاهش یابد. ما در مورد استراتژی های بهینه سازی لامبدا صحبت می کنیم. ما در مورد بهترین شیوه‌های مدل‌سازی داده DynamoDB برای عملکرد بحث می‌کنیم.

ما به دلایل خوبی در مورد آن صحبت می کنیم – این به طور مستقیم به هزینه مربوط می شود! هرچه عملکردهای Lambda ما بیشتر اجرا شود، هزینه بیشتری از صورتحساب ماهانه دریافت می کنیم. این یک مفهوم اصلی ابری است که همه ما در این مرحله با آن آشنا هستیم.

اما موقعیت مکانی چطور؟ فاصله جغرافیایی بین جایی که کاربران شما هستند و محل اجرای کد شما بر عملکرد تاثیر می گذارد. ما آنقدر که باید در مورد آن صحبت نمی کنیم.

مطمئناً، ما در مورد اضافه کردن توزیع‌های CloudFront در جلوی سایت شما یا اجرای مقداری محاسبات با Lambda@Edge صحبت می‌کنیم، اما چیزهای بسیار بیشتری در مورد آن وجود دارد – به خصوص وقتی صحبت از بسته‌های شخص ثالث می‌شود! اگر تابع Lambda شما در eu-west-1 اجرا می‌شود، اما API شخص ثالثی که استفاده می‌کنید خارج از کالیفرنیا است، مقدار قابل توجهی مسافتی وجود دارد که ترافیک برای پاسخگویی باید طی کند!

قوانین فیزیک در انتقال داده اعمال می شود. به همان اندازه که من دوست دارم باور کنم که اینترنت جادویی است و اتفاقات در یک لحظه رخ می دهند، متاسفانه اینطور نیست.

محاسبه تاخیر

آیا می دانستید که می توانید (نوعی) تأخیر را بر اساس فاصله فیزیکی محاسبه کنید؟

به طور خوش بینانه، داده ها می توانند با سرعت نور حرکت کنند. واقع بینانه، این کار را نمی کند. دارای یک وسیله سفر مانند کابل فیبر نوری یا سیم مسی است که زمان سفر را کاهش می دهد. همچنین، به استثنای بسیار کمی، داده‌ها نقطه به نقطه حرکت نمی‌کنند. درخواست API که از دستگاه خود می کنید مستقیماً به سروری که کد شما را اجرا می کند نمی پرد. در راه رسیدن به مقصد چندین پرش طول خواهد کشید.

در واقع، برای رسیدن از خانه خود به یک API که در منطقه AWS زندگی می کند us-east-1، 18 پرش بود!

به همین دلیل، ما نمی توانیم تأخیر را دقیقاً با سرعت نور محاسبه کنیم. ما باید سرعت آن را کاهش دهیم تا از دست دادن از طریق رسانه ها (مس / فیبر) محاسبه شود. به طور کلی، می‌توانیم تخمین بزنیم که داده‌ها با سرعت 200،000،000 متر در ثانیه برای محاسبه این تلفات حرکت می‌کنند. که هنوز هم سریع است، اما قابل چشم پوشی نیست!

برای قرار دادن یک عدد قابل مقایسه در این زمان، شهر نیویورک تقریباً 16000 کیلومتر با Syndey، استرالیا فاصله دارد. درخواست بین این دو شهر حدود 160 میلی ثانیه طول می کشد. هنگامی که تأخیر را برای پرش و صف شبکه اضافه کردید، می توانید انتظار داشته باشید که این درخواست مورد قبول واقع شود حدود 300 میلی‌ثانیه رفت و برگشت! و این فقط زمان سفر است – هنوز باید درخواست را پردازش کرده و پاسخی را برگردانید.

تعداد بی نهایت متغیری وجود دارد که بر تأخیر شبکه تأثیر می گذارد. محاسبه سریع ترین زمان ممکن به دلیل نزدیک بودن به منبع محاسباتی، راه خوبی برای نشان دادن بهترین سناریو به شما است. می دانید که با توجه به قوانین فیزیک، هرگز نمی تواند سریعتر از آن باشد.

نگاهی به تأخیر مبتنی بر فاصله

من آزمایش کردم تا ببینم اگر یک تابع Lambda داشته باشید که به یک API شخص ثالث در مکان‌های جغرافیایی مختلف فراخوانی می‌کند چه اتفاقی می‌افتد. API من در us-east-1 زندگی می کند که عمدتاً در خارج از ویرجینیای شمالی قرار دارد.

من در دالاس، تگزاس زندگی می کنم، که حدود 2000 کیلومتر از مراکز داده در us-east-1 فاصله دارد. با توجه به فرمول ما از بالا، انتظار تاخیر رفت و برگشتی در حدود 38 میلی ثانیه را دارم. اما چه اتفاقی می‌افتد وقتی تابع us-east-1 به جایی از نظر جغرافیایی دورتر متصل شود؟

برای اجرای آزمایش، از Node.js Momento SDK برای دریافت و تنظیم ترکیبات رنگ-هگز در یک کش استفاده کردم. Momento SDK به شما این امکان را می دهد که یک توکن تأیید هویت را با هدف یک منطقه خاص ارائه دهید، بنابراین من مجموعه ای از 1000 تماس API را در مناطق زیر اجرا کردم.

• AWS us-east-1 (همان منطقه)
• AWS us-west-2 (هرمیستون، اورگان ~ 4200 کیلومتر دورتر)
• GCP آسیا-شمال شرقی 1 (توکیو، ژاپن 11000 کیلومتر دورتر)
• AWS ap-south-1 (بمبئی، هند ~ 13000 کیلومتر دورتر)

با توجه به فاصله هر منطقه، من انتظار دارم زمانی که به نقطه پایانی مشابهی از دستگاه من در دالاس برخورد می کنم، تأخیرها به طور قابل توجهی متفاوت باشد.

این از همان نقطه پایانی API استفاده می کرد و تنها تفاوت آن منطقه ای بود که Momento SDK برای عملیات داده به آن متصل شده بود. این شواهد قوی نشان می دهد که فاصله تأثیر ملموسی بر تأخیر دارد.

بدیهی است که در منطقه سریع‌ترین سرعت خواهد بود، زیرا داده‌ها نیازی به سفر تقریباً دور ندارند. یک مشاهده کنجکاو این است که تاخیر بیشتر است آسیا-شمال شرقی 1 از آن است api-south-1 با وجود فاصله کمتر این می تواند به دلیل تعداد پرش های شبکه یا کیفیت کابل هایی باشد که داده ها از طریق آنها منتقل می شوند. هر چه که باشد، یادآوری می کند که ده ها عامل وجود دارد که در تأخیر شبکه وجود دارد.

تقویت عملکرد جغرافیایی

نزدیک کردن اپلیکیشن خود به مشتریان تنها بخشی از پازل است. هنگامی که از چیزی مانند CDN استفاده می کنید، محتوای رابط کاربری خود را از نظر جغرافیایی به کاربران نهایی خود نزدیک می کنید. از آنجایی که من در دالاس، تگزاس زندگی می‌کنم، محتوای پشت آمازون CloudFront به من تحویل داده می‌شود. دالاس / فورت ورث محل لبه این نزدیکی به این معنی است که صفحات وب می توانند با کمتر از 1 میلی ثانیه تاخیر به دلیل فاصله جغرافیایی به من ارائه شوند.

اما در مورد داده ها چطور؟ APIها و پردازش‌های پشتیبان در این مکان‌های لبه وجود ندارند. می‌توانید Lambda@Edge را اضافه کنید که توابع «لایه میانی» توزیع‌شده جغرافیایی را ارائه می‌دهد، اما برای اجرای منطق اصلی کسب‌وکار شما در نظر گرفته نشده است. پس چه کاری می‌توانید انجام دهید؟

برای شروع، می توانید برنامه خود را در چندین منطقه مستقر کنید. چه در AWS، GCP، Azure یا هر فروشنده ابری دیگری باشید، مجموعه ای از مناطق جغرافیایی متنوع برای اجرای کد خود دارید. از مسیریابی مبتنی بر IP در لایه DNS خود برای هدایت درخواست ها به نزدیک ترین منطقه به تماس گیرنده خود استفاده کنید.

اما باز هم این تنها بخشی از مشکل است. در مثال بالا، بسته شخص ثالث در مناطق کاملاً مجزا در سراسر جهان اجرا شد.

این مسئولیت شما به عنوان سازنده است که بدانید کد شما در کجا اجرا می شود.

هنگام ارزیابی یک بسته شخص ثالث، باید بفهمید که چگونه می توانید مشتریان را تنظیم کنید تا در صورت امکان به بقیه کد شما نزدیکتر شوند. این ممکن است در حین اجرای شما آشکار نباشد، اما همانطور که تنظیم عملکرد را انجام می دهید، باید به آن توجه کنید.

از داده های ردیابی برای تشریح زمان های اجرای خود استفاده کنید. ردیابی ها به شما نشان می دهند که در زمان اجرای کد شما تمام زمان در کجا صرف می شود تا بتوانید به سرعت اجزای کندتر را شناسایی کرده و بر اساس آن عمل کنید.

خلاصه

زمان شروع سرد تنها عامل تاخیر در برنامه های بدون سرور نیست! فاصله جغرافیایی بین کاربران نهایی و کد تأثیر زیادی بر عملکرد دارد.

در نظر بگیرید که تمام اجزای برنامه شما در کجا اجرا می شوند. اگر کد بک‌اند در منطقه AWS us-east-1 در حال اتمام است، اما از یک API شخص ثالث استفاده می‌کنید که فقط در بمبئی، هند تمام شده است، ممکن است در استفاده از آن بسته تجدید نظر کنید. نه تنها زمان تماس های شبکه شما را افزایش می دهد، بلکه هزینه برنامه شما را نیز افزایش می دهد. هرچه بیشتر در یک تابع لامبدا در فرآیندهای شخص ثالث منتظر بمانید، به دلیل افزایش زمان اجرا، هزینه بیشتری پرداخت می کنید.

از داده های ردیابی برای شناسایی کندی بسته های شخص ثالث خود استفاده کنید. هنگام انجام تحقیقات خود، اسناد را بخوانید یا در گوگل جستجو کنید تا مراکز داده در کجا قرار دارند.

اگر متوجه شدید که می توانید مشتری را برای استفاده از مرکز داده در مرکز تنظیم کنید، این کار را انجام دهید! اگر نمی توانید …. مزایا و معایب ضربه تأخیر را در مقابل ارزشی که ارائه می دهد، بسنجید.

برنامه خود را در چندین منطقه در سراسر جهان مستقر کنید. مشتریان شما کجا هستند؟ آیا از نمونه ای از برنامه خود در نزدیکی آنها پشتیبانی می کنید؟ برای استقرار یک نمونه دیگر در نزدیکی چقدر نیاز است؟ آیا قدرت عملیاتی برای پشتیبانی از آن را دارید؟

از یک خط مشی مسیریابی مناسب برای هدایت ترافیک به منطقه مناسب برنامه خود استفاده کنید. شما می توانید گزینه هایی مانند موقعیت جغرافیایی، تأخیر یا مسیریابی مبتنی بر IP را برای بهینه سازی عملکرد برای کاربران نهایی خود انتخاب کنید.

توجه – بر اساس روشی که انتخاب می‌کنید، نیازهای تکراری داده‌های متفاوتی خواهید داشت. اگر به صورت پویا ترافیک کاربر را به نمونه های مختلف برنامه خود هدایت می کنید، باید داده ها را برای همه نمونه ها تکرار کنید (معمولاً با ضمانت کاملاً سازگار یا SLA تکراری فشرده). اما اگر پروفایل های کاربر را به مناطق خاصی اختصاص دهید، نیازهای تکراری شما از بین می رود.

به یاد داشته باشید که همیشه در مورد کد نیست! قوانین فیزیک نقشی ناچیز در علوم کامپیوتر ایفا می کنند. هنگام ساخت برنامه های بدون سرور، باید در هنگام طراحی برنامه شما در نظر گرفته شود. این می تواند هزاران دلار در هر ماه شما را ذخیره کند!

کد نویسی مبارک!