تا همین اواخر، هر جلسه جدید مشتری به سرویس جهانی AWS ما با یک درخواست پیشپرواز شروع میشد که تنها هدفش تعیین منطقه AWS برای احراز هویت بود. این رفتوبرگشت پنهان سالها بهعنوان یک راهحل موقت در معماری ما باقی مانده بود تا اینکه مجموعهای از قطعیهای منطقهای ما را به بازنگری و مهاجرت به AWS Signature Version 4a (SigV4a) وادار کرد. در این مقاله، چالشها و درسهای این تحول معماری را بررسی میکنیم.
محدودیتی که معماری را شکل داد
ما یک سرویس تنظیمات کاربری را در دو منطقه AWS مستقر کرده بودیم و از Route 53 با مسیریابی مبتنی بر تأخیر استفاده میکردیم تا ترافیک را به نزدیکترین منطقه هدایت کنیم. در این معماری، زیرساخت باید تصمیم میگرفت که درخواست به کدام منطقه برود، اما مشکل از جایی شروع شد که مجبور به استفاده از احراز هویت AWS Identity and Access Management (IAM) برای API Gateway شدیم. در آن زمان، تنها گزینه AWS Signature Version 4 (SigV4) بود.
SigV4 هر امضا را به یک سرویس و منطقه خاص محدود میکند. منطقه در فرآیند امضای درخواست جاسازی میشود، به این معنی که درخواست امضا شده برای us-west-2 اگر به eu-west-1 برسد، از نظر رمزنگاری نامعتبر است و بررسی امضا قبل از پردازش شکست میخورد. این محدودیت باعث ایجاد یک مصالحه معماری شد: ما میخواستیم زیرساخت تصمیمگیرنده باشد، اما مشتری مجبور بود قبل از ساخت درخواست، منطقه مقصد را انتخاب کند.
راهحل موقت: کشف منطقه پیش از پرواز
برای دور زدن این محدودیت، یک مرحله پیشپرواز پیادهسازی کردیم. مشتری ابتدا یک نقطه پایانی بدون احراز هویت به نام DiscoverRegion را فراخوانی میکرد تا نزدیکترین منطقه را بیاموزد، سپس نتیجه را کش میکرد و تمام درخواستهای بعدی را با SigV4 برای آن منطقه امضا میکرد. این معماری برای سالها به خوبی کار کرد، اما یک مشکل اساسی داشت: در صورت قطعی یک منطقه، مشتریان به دلیل وابستگی رمزنگاری به آن منطقه، نمیتوانستند بهراحتی به منطقه دیگر سوئیچ کنند.
قطعهای منطقهای: انگیزه واقعی برای تغییر
مجموعهای از رویدادها در us-east-1 (ویرجینیای شمالی) – از جمله مشکلات شبکه در دسامبر ۲۰۲۱، AWS Lambda در ژوئن ۲۰۲۳ و Amazon DynamoDB در اکتبر ۲۰۲۵ – مستقیماً روی سرویس ما تأثیر گذاشت. حتی با وجود معماری جهانی، نمیتوانستیم ترافیک را از منطقه آسیبدیده دور کنیم، زیرا مشتریان امضاهای خود را برای آن منطقه ایجاد کرده بودند. تنها راه بازیابی، اجرای مجدد جریان کشف منطقه بود که خود یک عملیات هزینهبر بود.
راهحل: SigV4a و امضای نامتقارن
AWS Signature Version 4A (SigV4a) که با عنوان Signature Version 4 Asymmetric نیز شناخته میشود، این مشکل را با استفاده از امضای مبتنی بر رمزنگاری نامتقارن حل میکند. در SigV4a، امضا به جای یک منطقه، برای مجموعهای از مناطق معتبر است. این یعنی زیرساخت میتواند درخواست را بدون نیاز به امضای مجدد به هر منطقهای هدایت کند. مهاجرت از SigV4 به SigV4a از نظر کدنویسی بسیار ساده است، اما هماهنگی با فراخوانهای وابسته چالش اصلی است. با این حال، مزایای آن – بهویژه تابآوری منطقهای – ارزش این تلاش را دارد.
درسهای فنی و فرآیندی
- SigV4a کمک میکند اگر: مشتریان شما یک مرحله پیشپرواز برای کشف منطقه اجرا میکنند. این مرحله به دلیل مدل احراز هویت وجود دارد، نه به دلیل ارزش افزوده.
- بررسی دورهای راهحلهای موقت: محدودیتهایی که زمانی یک راهحل را توجیه میکردند ممکن است دیگر وجود نداشته باشند. ابزارهای جدید مانند SigV4a را بررسی کنید.
- مشکلات فرآیندی: هماهنگی فراخوانهای وابسته، چالش اصلی مهاجرت است، نه الگوریتمها.
نتیجهگیری
حذف مرحله کشف منطقه نه تنها تأخیر را کاهش داد، بلکه تابآوری سرویس ما را در برابر قطعیهای منطقهای افزایش داد. با نگاهی به گذشته، این قدمی ضروری برای رسیدن به معماری واقعاً جهانی و مقاوم در AWS بود. اگر سرویس شما نیز با چنین رفتوبرگشت پنهانی مواجه است، اکنون بهترین زمان برای بازنگری و مهاجرت به SigV4a است.
