چگونه AWS خدمات الاستیک خود را طبخ می کند. مقیاس پذیری سرورها و پایگاه داده

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

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

درباره گوینده: واسیلی پانتیوخین (مرغ) به عنوان مدیر یونیکس در شرکت‌های .ru شروع به کار کرد، به مدت 6 سال روی سخت‌افزار بزرگ Sun Microsystem کار کرد و به مدت 11 سال در EMC یک دنیای داده محور را تبلیغ کرد. به طور طبیعی به ابرهای خصوصی تبدیل شد و در سال 2017 به ابرهای عمومی منتقل شد. اکنون او توصیه های فنی برای کمک به زندگی و توسعه در ابر AWS ارائه می دهد.

سلب مسئولیت: همه موارد زیر نظر شخصی واسیلی است و ممکن است با موقعیت خدمات وب آمازون مطابقت نداشته باشد. ضبط ویدیو گزارشی که مقاله بر اساس آن است در کانال یوتیوب ما موجود است.

چرا در مورد دستگاه آمازون صحبت می کنم؟

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

همه چیز عالی بود، به جز یک چیز - گیر کردن در ترافیک. به نظر می رسد که نشسته اید و هیچ کاری انجام نمی دهید، اما دائماً دنده ها را عوض می کنید، کلاچ، گاز، ترمز را فشار می دهید - واقعاً شما را خسته می کند. مشکل ترافیک تا حدودی حل شد که خانواده یک ماشین اتوماتیک گرفتند. در حین رانندگی وقت داشتم به چیزی فکر کنم و به یک کتاب صوتی گوش کنم.

راز دیگری در زندگی من ظاهر شد، زیرا من کاملاً متوجه نحوه کار ماشینم نشدم. ماشین مدرن یک وسیله پیچیده است. این خودرو به طور همزمان با ده ها پارامتر مختلف سازگار است: فشار دادن گاز، ترمز، سبک رانندگی، کیفیت جاده. من دیگر نمی فهمم چگونه کار می کند.

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

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

در مورد چی صحبت کنیم

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

بهینه سازی سرور. ابرهای زودگذر با تجسم فیزیکی: مراکز داده فیزیکی که در آن سرورهای فیزیکی وجود دارند که با چراغ ها زمزمه می کنند، گرم می شوند و چشمک می زنند.

توابع بدون سرور (لامبدا) احتمالاً مقیاس پذیرترین سرویس در فضای ابری است.

مقیاس بندی پایگاه داده. من به شما خواهم گفت که چگونه پایگاه داده های مقیاس پذیر خود را می سازیم.

مقیاس بندی شبکه. آخرین قسمتی که در آن دستگاه شبکه خود را باز خواهم کرد. این یک چیز شگفت انگیز است - هر کاربر ابری معتقد است که در فضای ابری تنها است و به هیچ وجه مستاجران دیگر را نمی بیند.

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

سرورها

ابر زودگذر است. اما این زودگذری هنوز هم یک تجسم فیزیکی دارد - سرورها. در ابتدا معماری آنها کلاسیک بود. چیپست استاندارد x86، کارت های شبکه، لینوکس، هایپروایزر Xen که ماشین های مجازی روی آن ها اجرا می شدند.

در سال 2012، این معماری به خوبی از پس وظایف خود برآمد. Xen یک هایپروایزر عالی است، اما یک اشکال اساسی دارد. او به اندازه کافی است سربار بالا برای شبیه سازی دستگاه. با در دسترس قرار گرفتن کارت های شبکه جدید و سریعتر یا درایوهای SSD، این سربار بسیار زیاد می شود. چگونه با این مشکل برخورد کنیم؟ ما تصمیم گرفتیم همزمان در دو جبهه کار کنیم - هم سخت افزار و هم هایپروایزر را بهینه کنید. وظیفه بسیار جدی است.

بهینه سازی سخت افزار و هایپروایزر

انجام همه کارها به یکباره و انجام آن به خوبی کارساز نخواهد بود. اینکه «خوب» چیست نیز در ابتدا نامشخص بود.

ما تصمیم گرفتیم یک رویکرد تکاملی در پیش بگیریم - یک عنصر مهم معماری را تغییر می دهیم و آن را به تولید می اندازیم.

ما بر روی هر چنگک پا می گذاریم، به شکایات و پیشنهادات گوش می دهیم. سپس یک جزء دیگر را تغییر می دهیم. بنابراین، با افزایش های کوچک، کل معماری را بر اساس بازخورد کاربران و پشتیبانی به طور اساسی تغییر می دهیم.

تحول در سال 2013 با پیچیده ترین چیز - شبکه آغاز شد. که در С3 در مواردی، یک کارت شبکه شتاب دهنده ویژه به کارت شبکه استاندارد اضافه شد. این به معنای واقعی کلمه با یک کابل Loopback کوتاه در پانل جلویی متصل شد. زیبا نیست، اما در ابر قابل مشاهده نیست. اما تعامل مستقیم با سخت‌افزار به طور اساسی باعث بهبود جیتر و توان عملیاتی شبکه شد.

در مرحله بعد تصمیم گرفتیم دسترسی به ذخیره سازی داده های بلوک EBS - Elastic Block Storage را بهبود دهیم. این ترکیبی از شبکه و ذخیره سازی است. مشکل این است که در حالی که کارت‌های شتاب دهنده شبکه در بازار وجود داشتند، هیچ گزینه‌ای برای خرید سخت‌افزار Storage Accelerator وجود نداشت. بنابراین ما به یک استارتاپ روی آوردیم آزمایشگاه آناپورنا، که تراشه های ویژه ASIC را برای ما توسعه دادند. آنها اجازه دادند تا ولوم های EBS راه دور به عنوان دستگاه های NVMe نصب شوند.

در مواردی C4 ما دو مشکل را حل کردیم اولین مورد این است که ما پایه ای را برای آینده نویدبخش، اما جدید در آن زمان، فناوری NVMe پیاده سازی کردیم. دوم، ما به طور قابل توجهی پردازنده مرکزی را با انتقال پردازش درخواست ها به EBS به یک کارت جدید تخلیه کردیم. خوب معلوم شد، بنابراین اکنون آزمایشگاه آناپورنا بخشی از آمازون است.

در نوامبر 2017، متوجه شدیم که زمان آن رسیده است که خود هایپروایزر را تغییر دهیم.

هایپروایزر جدید بر اساس ماژول های هسته اصلاح شده KVM توسعه یافته است.

این امکان را به طور اساسی کاهش داد که سربار شبیه سازی دستگاه و کار مستقیم با ASIC های جدید. موارد С5 اولین ماشین‌های مجازی با یک هایپروایزر جدید در زیر کاپوت بودند. اسمش را گذاشتیم نیترو.

تکامل نمونه ها در جدول زمانی.

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

در طی دو سال آینده، تعداد انواع نمونه های نیترو از دوجین فراتر رفت: A1، C5، M5، T3 و موارد دیگر.

انواع نمونه

ماشین های مدرن نیترو چگونه کار می کنند

آنها سه جزء اصلی دارند: هایپروایزر نیترو (در بالا مورد بحث قرار گرفت)، تراشه امنیتی و کارت های نیترو.

تراشه امنیتی مستقیماً در مادربرد ادغام شده است. بسیاری از عملکردهای مهم مانند کنترل بارگذاری سیستم عامل میزبان را کنترل می کند.

کارت های نیترو - چهار نوع از آنها وجود دارد. همه آنها توسط آزمایشگاه Annapurna توسعه یافته اند و بر اساس ASIC های رایج هستند. برخی از سیستم عامل آنها نیز رایج است.

چهار نوع کارت نیترو.

یکی از کارت ها برای کار با آن طراحی شده است شبکهVPC. این همان چیزی است که در ماشین های مجازی به عنوان کارت شبکه قابل مشاهده است ENA - آداپتور شبکه الاستیک. همچنین هنگام انتقال آن از طریق یک شبکه فیزیکی، ترافیک را کپسوله می کند (در قسمت دوم مقاله در مورد آن صحبت خواهیم کرد)، فایروال گروه های امنیتی را کنترل می کند و مسئول مسیریابی و سایر موارد شبکه است.

کارت‌های انتخابی با ذخیره‌سازی بلوک کار می‌کنند EBS و دیسک هایی که در سرور تعبیه شده اند. آنها برای ماشین مجازی مهمان به عنوان ظاهر می شوند آداپتورهای NVMe. آنها همچنین مسئول رمزگذاری داده ها و نظارت بر دیسک هستند.

سیستم کارت های نیترو، هایپروایزر و تراشه امنیتی در یک شبکه SDN یا شبکه تعریف شده نرم افزار. مسئول مدیریت این شبکه (Control Plane) کارت کنترل.

البته، ما به توسعه ASIC های جدید ادامه می دهیم. به عنوان مثال، در پایان سال 2018، آنها تراشه Inferentia را منتشر کردند که به شما امکان می دهد کارآمدتر با وظایف یادگیری ماشین کار کنید.

تراشه پردازشگر یادگیری ماشین Inferentia.

پایگاه داده مقیاس پذیر

یک پایگاه داده سنتی دارای ساختار لایه ای است. برای ساده سازی تا حد زیادی، سطوح زیر متمایز می شوند.

• SQL - ارسال کننده های مشتری و درخواست روی آن کار می کنند.
• مفاد معاملات - اینجا همه چیز واضح است، اسید و همه چیز.
• ذخیره سازی، که توسط استخرهای بافر ارائه می شود.
• ورود به سیستم - کار با سیاهههای مربوط به انجام مجدد را فراهم می کند. در MySQL به آنها Bin Logs می گویند، در PosgreSQL - Write Ahead Logs (WAL).
• ذخیره سازی - ضبط مستقیم روی دیسک

ساختار پایگاه داده لایه ای

راه‌های مختلفی برای مقیاس‌سازی پایگاه‌های داده وجود دارد: اشتراک‌گذاری، معماری Shared Nothing، دیسک‌های مشترک.

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

آمازون شفق قطبی

ایده اصلی معماری جداسازی سطوح ذخیره سازی و ثبت گزارش از پایگاه داده اصلی است.

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

سطوح ثبت و ذخیره سازی جدا از پایگاه داده است.

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

این رویکرد به شما امکان می دهد موارد جالبی مانند شبیه سازی. به دلیل اینکه نیازی به ایجاد یک کپی کامل از همه داده ها ندارد، اساساً سریعتر و اقتصادی تر کار می کند.

لایه ذخیره سازی به عنوان یک سیستم توزیع شده پیاده سازی می شود. از تعداد بسیار زیادی سرور فیزیکی تشکیل شده است. هر ثبت مجدد به طور همزمان پردازش و ذخیره می شود شش گره. این امر حفاظت از داده ها و تعادل بار را تضمین می کند.

مقیاس خواندن را می توان با استفاده از کپی های مناسب به دست آورد. ذخیره سازی توزیع شده نیاز به همگام سازی بین نمونه اصلی پایگاه داده را که از طریق آن داده ها را می نویسیم و کپی های باقی مانده را از بین می برد. داده های به روز تضمین شده است که در دسترس همه کپی ها هستند.

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

ذخیره سازی را مرتب کردیم.

نحوه مقیاس بندی سطوح DBMS

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

بیایید فرض کنیم یک برنامه کاربردی داریم که از طریق یک گره اصلی با DBMS ارتباط برقرار می کند.

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

سپس، برنامه را از گره اصلی قدیمی به نود جدید تغییر می دهیم. مشکلات پیش می آید.

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

چگونه می توان وضعیت را بهبود بخشید؟ یک پروکسی بین برنامه و گره اصلی تنظیم کنید.

این چه چیزی به ما می دهد؟ اکنون همه برنامه ها نیازی به هدایت دستی به گره جدید ندارند. سوئیچ را می توان تحت یک پروکسی انجام داد و اساساً سریعتر است.

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

راه حل نهایی با Amazon Aurora بدون سرور

چگونه این مشکلات را حل کردیم؟

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

مجموعه ای از گره های گرم با اندازه های مختلف اضافه شده است. بنابراین، اگر نیاز به اختصاص یک گره جدید با اندازه بزرگتر یا کوچکتر باشد، بلافاصله در دسترس است. نیازی نیست منتظر بمانید تا بارگذاری شود.

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

پراکسی های توزیع شده، نمونه های گرم و نظارت.

یک گره با توان مورد نیاز در دسترس است. مخزن‌های بافر روی آن کپی می‌شوند و سیستم شروع به منتظر ماندن برای یک لحظه امن برای تغییر می‌کند.

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

کار با رزومه های پایگاه داده

نمودار نشان می دهد که تعلیق در واقع بسیار کوتاه است. نمودار آبی بار را نشان می دهد و گام های قرمز لحظه های مقیاس بندی را نشان می دهد. افت های کوتاه مدت در نمودار آبی دقیقاً همان تأخیر کوتاه است.

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

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

بر HighLoad++ واسیلی پانتیوخین گزارشی ارائه خواهد کرد "هوستون، ما یک مشکل داریم. طراحی سیستم های شکست، الگوهای توسعه برای سرویس های ابری داخلی آمازون" اینکه توسعه دهندگان آمازون از چه الگوهای طراحی برای سیستم های توزیع شده استفاده می کنند، دلایل خرابی سرویس ها چیست، معماری مبتنی بر سلول چیست، کار مداوم، Shuffle Sharding - جالب خواهد بود. کمتر از یک ماه تا کنفرانس بلیط های خود را رزرو کنید. 24 اکتبر افزایش قیمت نهایی.

منبع: www.habr.com