راز پنهان آمازون در دیتاسنترها؛ چرا شبکه اختصاصی AWS برگ برنده این شرکت در عصر هوش مصنوعی است؟

در جریان بازدید اخیر از آزمایشگاه شبکه AWS (خدمات ابری آمازون) و گفت‌وگو با مت ریدر (Matt Rehder)، نایب‌رئیس مهندسی شبکه جهانی این شرکت، شوخی معروفی درباره مهره‌های فنری قفسه‌ای (Cage Nuts) و بریدن دست مهندسان هنگام بستن رک‌ها مطرح شد؛ اما این شوخی با نگاهی کاملاً متعجب و ناآشنا از سوی مدیران آمازون روبه‌رو شد.

دلیل این واکنش نه بی‌مزه بودن شوخی، بلکه پایان یافتن این دوره از تاریخ فناوری برای آمازون است. این روزها رک‌های سرور در دیتاسنترهای AWS به‌شکل کامپکت و پیش‌مونتاژ شده وارد می‌شوند و عملاً هیچ‌کس با پیچ‌گوشتی سراغ بستن قطعات نمی‌رود. این تجربه، نمایی گذرا از دنیای پشت پرده‌ای بود که ستون فقرات زیرساخت ابری مدرن را تشکیل می‌دهد، اما کمتر کسی از جزئیات آن آگاه است.

پیش‌تر در تحلیل‌های تخصصی به مقاله پژوهشی آمازون در این زمینه پرداخته شده بود. به‌طور خلاصه، ایده محوری این است: «یک شبکه مسطح و تک‌لایه با کابل‌کشی هدفمند با الگوی شبه‌تصادفی، به شبکه‌ای بسیار مقاوم‌تر و پایدارتر منجر می‌شود که هزینه عملیاتی به‌مراتب پایین‌تری دارد.»

نکته‌ای که کمتر به آن توجه شده و ابعاد اقتصادی ماجراست، نحوه اثرگذاری این تحول بر مشتریان خدمات ابری آمازون است. رویکرد نوین شبکه در AWS تا ۴۰ درصد بازدهی انرژی بالاتری دارد و اکنون به استاندارد پیش‌فرض در بیشتر دیتاسنترهای جدید این شرکت بدل شده است؛ دیتاسنترهایی که ساخت آن‌ها با سرعت سرسام‌آوری ادامه دارد. این دستاورد فنی تاکنون چه در درون آمازون و چه در بیرون از آن کمتر دیده شده است.

صرفه‌جویی مالی و بهبود بازدهی هزینه‌ها کاملاً واقعی است؛ اما پرسش اساسی این است که این صرفه‌جویی‌ها دقیقاً کجا هزینه می‌شوند؟

صرفه‌جویی‌های چشمگیر در هزینه‌ها

هفده سال پیش، جیمز همیلتون، نایب‌رئیس ارشد وقت آمازون، روی صحنه رفت و در ارائه‌ای [فایل PDF] توضیح داد که حاشیه سود شرکت‌های تولیدکننده تجهیزات شبکه شباهت زیادی به سازندگان رایانه‌های بزرگ (Mainframe) قدیمی دارد که درآمدهای گزافی را از خریداران طلب می‌کردند.

دغدغه اصلی همیلتون این بود که این شرکت‌ها مانع توسعه سریع آمازون هستند. در نتیجه، او و تیمش تصمیم گرفتند خودشان دست‌به‌کار شوند؛ تصمیمی که در نهایت به بازسازی کامل تمام لایه‌های نرم‌افزار و معماری شبکه روی سخت‌افزارهای تجاری استاندارد و عمومی ختم شد.

تا چند سال پیش، هزینه‌های شبکه آمازون در مقایسه با اتکا به سازندگان سنتی تجهیزات شبکه بهینه‌تر شده بود. سپس راهکار جدید این شرکت تحت عنوان «گراف شبکه انعطاف‌پذیر» (Resilient Network Graph یا RNG) به میدان آمد و باز هم هزینه‌های شبکه را به‌شکل چشمگیری کاهش داد. اما این صرفه‌جویی‌ها طی سال‌های اخیر کجا رفته است؟

وقتی از مدیران AWS پرسیده شد که آیا منصفانه است بگوییم آمازون بهبود حاشیه سود را برای خود نگه داشته و آن را به مشتریان بازنگردانده، پاسخ آن‌ها کاملاً صریح و بی‌پرده بود:

«از دیدگاه هزینه و حاشیه سود؟ در عمل، بله.»

اقتصاد ابری در AWS

شاید در نگاه اول این پاسخ انتقادآمیز به نظر برسد؛ اما با نگاهی دقیق‌تر به روندهای کلان صنعت طی سال‌های گذشته، واقعیت دیگری نمایان می‌شود. برخلاف رقبای بزرگ، AWS قیمت واحدهای خدمات موجود (SKU) را افزایش نداده است.

(البته هزینه بلوک‌های ظرفیت پردازنده‌های گرافیکی (GPU) به‌صورت فصلی افزایش یافته است، اما ساختار این سرویس‌ها اساساً مانند نسخه کندتری از Spot Instances طراحی شده است؛ همچنین هزینه جداگانه‌ای برای آدرس‌های عمومی IPv4 از دو سال قبل در نظر گرفته شد.)

با این حال، شما می‌توانید همین امروز یک ماشین مجازی با ۶۴ گیگابایت رم را دقیقاً با همان قیمت سال ۲۰۲۰ راه‌اندازی کنید؛ این یعنی قیمت‌ها حتی متناسب با تورم جهانی نیز بالا نرفته‌اند. از سوی دیگر، هرچند انتقال از نمونه مبتنی بر پردازنده Graviton4 (مانند c8g.2xlarge) به نمونه جدیدتر Graviton5 (مانند c9g.2xlarge) حدود ۹ درصد افزایش قیمت دارد، اما هیچ اجباری برای ارتقا وجود ندارد. با در نظر گرفتن جهش شدید قیمت قطعات سخت‌افزاری، ثابت نگه داشتن افزایش قیمت در سطح ۹ درصد خود دستاورد قابل‌توجهی محسوب می‌شود.

افزون بر این، با وجود جزئیات زیاد و میلیون‌ها کد محصول در صورت‌حساب‌های AWS، هر شناسه محصول پنهان‌کننده لایه‌های عظیمی از پیچیدگی فنی است. وقتی هزینه یک ساعت استفاده از نمونه‌های EC2 را پرداخت می‌کنید (که البته بر حسب ثانیه محاسبه می‌شود)، این مبلغ تک لایه شامل هزینه پردازنده، حافظه رم، مدار ارتباطی، برق، امنیت فیزیکی ساختمان، ابزارهای مدیریت هویت و دسترسی (IAM) برای حفظ ایزولاسیون کامل، دستمزد مهندسان و حجم شگفت‌انگیزی از نوآوری‌های زیرساختی شبکه است.

تحول بنیادین در رویکرد شبکه

یکی از ابعاد جذاب این معماری شبکه آن است که هرچند جابه‌جایی ترافیک میان مناطق در دسترس (Availability Zones یا AZ) می‌تواند هزینه‌بر باشد (در مناطق اصلی هر گیگابایت داده یک سنت برای ورود و یک سنت برای خروج هزینه دارد که در مجموع ۲ سنت در هر گیگابایت می‌شود)، اما انتقال داده درون یک AZ کاملاً رایگان است.

این موضوع زمانی اهمیت واقعی خود را نشان می‌دهد که بدانید هر AZ از چندین ساختمان و دیتاسنتر مجزا تشکیل شده است. با توسعه مداوم AZها و انفجار حجم داده‌ها، هزینه‌های زیرساختی پیوسته افزایش می‌یابد؛ هزینه‌هایی که آمازون تاکنون تصمیم گرفته آن‌ها را خودش تقبل کند و بر دوش مشتری نگذارد.

انتقال داده به خارج از محیط AWS همواره هزینه‌برتر بوده است.

در گذشته، خانواده دستگاه‌های اسنوبال (Snowball) برای انتقال فیزیکی داده‌ها استفاده می‌شد؛ ارسال داده به AWS هزینه ثابتی داشت، اما استخراج داده علاوه‌بر کارمزد پایه، هزینه مجزایی بر اساس گیگابایت به‌همراه داشت.

اما طی یک سال گذشته با معرفی سرویس AWS Interconnect (برای زیرساخت‌های چندابری یا Multicloud)، این ساختار دگرگون شد. در این سرویس هزینه‌ای بر اساس گیگابایت دریافت نمی‌شود و صرفاً تعرفه ساعتی درگاه (پورت) محاسبه می‌گردد. حتی یک سطح رایگان ۵۰۰ مگابیت‌برثانیه‌ای برای هر ارائه‌دهنده تعریف شده که هزینه ارسال ترافیک از سمت AWS به گوگل کلود، اوراکل و به‌زودی مایکروسافت آژور را به صفر می‌رساند. برای مقایسه، ارسال ترافیک مداوم با این پهنای باند در بستر اینترنت آزاد ماهانه حدود ۱۲ هزار دلار هزینه در بر دارد.

این رویکرد پیش از این در اکوسیستم AWS سابقه نداشته و بسیار جالب‌توجه است. مدیران آمازون در پاسخ به چرایی این تصمیم صراحتاً اعلام کردند:

«ما می‌دانیم که مشتریان از تعرفه‌های متغیر شبکه رضایت ندارند؛ زیرا پیش‌بینی هزینه‌ها را دشوار می‌کند. به همین دلیل در محصولات جدید شبکه به سمت تعرفه‌های ثابت و تخت (Flat-rate) حرکت می‌کنیم.»

این تغییر جهت‌گیری بسیار بنیادین و غیرمنتظره است؛ به‌ویژه در دورانی که قیمت سرویس‌های ابری در سرتاسر جهان به‌جای کاهش، رو به افزایش گذاشته است.

طراحی شبکه چقدر دشوار است؟ بسیار دشوار

چالش اصلی این است که بخش اعظم نوآوری‌های AWS در عمل نامرئی می‌ماند. خود آمازون نیز معترف است که در روایت دستاوردهای فنی خود ضعف دارد؛ اگرچه علاقه‌مند است این روایت‌ها شنیده شوند. از گذشته تا امروز، رویکرد آمازون این بوده که روایت داستان را بر عهده مشتریان خود بگذارد تا اثرگذاری بیشتری داشته باشد.

نمونه بارز این موضوع، طراحی معماری شبکه است. بخش سخت یک شبکه شبه‌تصادفی، کابل‌کشی فیزیکی آن نیست، بلکه «مسیریابی» (Routing) است. تمام پروتکل‌های شناخته‌شده دنیای شبکه (نظیر BGP یا OSPF و پروتکل‌های اختصاصی سیسکو) کوتاه‌ترین مسیر را محاسبه می‌کنند. اما وقتی میان هر دو نقطه هزاران مسیر معادل و هم‌ارز وجود دارد، مفهوم «کوتاه‌ترین مسیر» عملاً کارایی خود را از دست می‌دهد. AWS این گره کور را با پروتکلی به نام SIDR (مسیریابی مقیاس‌پذیر مبتنی بر هدف یا Scalable Intent-Driven Routing) حل کرده است؛ این پروتکل لایه کنترل (Control Plane) را مدیریت می‌کند، در حالی که لایه ارجاع و هدایت داده‌ها توسط راهکاری به نام Spraypoint اداره می‌شود.

مهندسان آمازون پروتکل SIDR را در رویداد re:Invent سال ۲۰۲۳ و سپس در سال ۲۰۲۴ به‌صورت عمومی معرفی کردند. پس از آن نیز مقاله علمی مربوط به گراف شبکه انعطاف‌پذیر (RNG) را منتشر ساختند؛ مقاله‌ای که حتی اشاره‌ای به نام SIDR نکرده بود. در واقع کمتر متخصصی در خارج از آمازون متوجه پیوند عمیق این پروتکل با زیرساخت پایدار شبکه AWS شده است؛ نه به این دلیل که موضوع محرمانه بوده، بلکه چون آمازون هرگز بر اهمیت حیاتی آن در به حرکت درآوردن کل این چرخه تأکید نکرده است.

این عدم مهارت در روایت‌گری به ضرر آمازون تمام شده است؛ چراکه اکنون در بازار هوش مصنوعی این تصور شکل گرفته که ابرهای نوظهور (Neoclouds) و طرح‌های مرجع انویدیا عملکرد بهتری دارند. اما واقعیت چنین نیست. شما می‌توانید بدون دانش عمیق از پیچیدگی‌های شبکه، یک ابر محاسباتی راه‌اندازی کنید و برخی از بازیگران جدید بازار دقیقاً همین کار را کرده‌اند.

واقعیت این است که شبکه بسیاری از دیتاسنترها با ناشی‌گری تمام اداره می‌شود. آمازون پیچیدگی‌های فنی شبکه را به‌قدری ماهرانه پنهان کرده است که فراموش می‌کنیم دسترسی به حداکثر پهنای باند خطی (Full line-rate) میان هر دو نقطه دلخواه در AWS چه دستاورد مهندسی بزرگی است. در دیتاسنترهای معمولی، همواره این دغدغه وجود دارد که سوییچ بالای رک (Top-of-Rack) توانایی عبور حجم مشخصی از ترافیک را دارد و همه گره‌ها نمی‌توانند هم‌زمان با حداکثر سرعت تبادل اطلاعات کنند؛ مشکلی که در AWS عملاً هیچ‌گاه رخ نمی‌دهد. اکنون نسلی از مهندسان رشد کرده‌اند که به دلیل پنهان بودن این پیچیدگی‌ها در پلتفرم‌های ابری، چالش‌های زیرساختی را نادیده می‌گیرند و هنگام راه‌اندازی دیتاسنترهای اختصاصی، کار را بسیار ساده می‌پندارند.

اما واقعیت آن است که راه‌اندازی چنین شبکه‌ای به‌شدت دشوار است و بعید به نظر می‌رسد ابرهای محاسباتی نوظهوری که یک‌شبه سر برآورده‌اند، به این جزئیات حیاتی توجه کافی داشته باشند. در پاسخ به این پرسش که آیا دیتاسنترهای ویژه یادگیری ماشین و هوش مصنوعی AWS (نظیر تأسیسات میسیسیپی) به دلیل بارهای کاری مبتنی بر پردازنده‌های گرافیکی استانداردهای متفاوتی دارند، مدیران ارشد شبکه آمازون تأکید کردند که تمام دیتاسنترهای این شرکت بدون کوچک‌ترین استثنا با یک استاندارد واحد و بدون هیچ‌گونه میان‌بر مهندسی ساخته می‌شوند.

با این همه، مشتریان معمولاً زمانی متوجه اهمیت این زیرساخت‌ها می‌شوند که کار از کار گذشته باشد؛ تجربه نشان داده است که ارزش پایداری و تاب‌آوری شبکه معمولاً پس از قطعی‌های بزرگ، پرهزینه و رسواکننده در پلتفرم‌های رقیب درک می‌شود.

فروتنی در مهندسی زیرساخت

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

بی‌تردید AWS ضعف‌های خود را دارد؛ کمپین‌های تبلیغاتی گاه ناموفق اجرا می‌کند، چندین سرویس موازی با کارکردهای مشابه می‌سازد که نام‌گذاری‌های سردرگم‌کننده‌ای دارند و اغلب با شرکای تجاری خود نیز وارد رقابت می‌شود.

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

تنها مشکل آن‌ها این است که مهارت کافی برای نشان دادن این دستاوردهای شگفت‌انگیز به جهان را ندارند.