AWS Advanced: The Quota Monitor Review

78641.25 دلار

در هر ماه

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

بدیهی است که این یک تفسیر کاملاً منصفانه از تجزیه و تحلیل هزینه نیست. اما بسیار مضحک است که هزینه در اینجا به این اندازه باشد. ما به طور کامل انتظار داریم که هزینه ای نزدیک به صفر برای اجرای یک مانیتور سهمیه ای داشته باشیم.

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

اما AWS آن را ندارد، بنابراین بیایید بهترین کار بعدی را امتحان کنیم. ساختن نسخه بهتر

خط مبنا

معماری پیشنهادی اولیه چیزی شبیه به این است:

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

الزامات اصلی آنچه ما نیاز داریم عبارتند از:

1. با Service Quota API تماس بگیرید و بررسی کنید که سهمیه ها در کجا هستند.
2. هشدار در مورد این مشکل

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

این بدان معناست که تنها کاری که ما باید انجام دهیم این است که بخشی از فناوری را به کار بگیریم که سرویس Quota API را فراخوانی می کند، پیامی را در CloudWatch Logs ثبت می کند و اشتراک CloudWatch را برای ارسال آن پیام ها به مکان مناسب تنظیم می کند. ساده درسته؟.

مرحله صفر: معماری

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

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

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

چند جزئیات مهم:

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

مشکل اصلی در اینجا این است که AWS Solutions' Quota Monitor فقط از داده های CloudWatch Metrics استفاده می کند. یعنی فقط سهمیه هایی که به CloudWatch وارد می شوند می توانند استفاده شوند. به عنوان مثال، من به یکی از حساب های AWS خود نگاه می کنم و تنها 194 معیار در منطقه وجود دارد.

بسیاری از سهمیه هایی که جالب هستند معیاری ندارند. از مسیر 53 استفاده کنید. آیا عالی نیست اگر می دانستید چقدر به محدودیت ایجاد رکوردهای جدید مسیر 53 نزدیک شده اید.

{
            "ServiceCode": "route53",
            "ServiceName": "Amazon Route 53",
            "QuotaArn": "arn:aws:servicequotas:::route53/L-E209CC9F",
            "QuotaCode": "L-E209CC9F",
            "QuotaName": "Records per hosted zone",
            "Value": 10000.0,
            "Unit": "None",
            "Adjustable": true,
            "GlobalQuota": true
        }

اما مشکل اینجاست که Route53 یک متریک برای شمارش رکورد ثبت نمی کند.

aws service-quotas list-aws-default-service-quotas \
  --service-code route53 --region us-east-1 \
  --query 'Quotas[?UsageMetric.MetricNamespace==`AWS/Usage`]'

اجرای این دستور CLI به شما می گوید که کدام سهمیه ها در حال پیگیری هستند. نتیجه این دستور فقط این است:

[
    {
        "ServiceCode": "route53",
        "ServiceName": "Amazon Route 53",
        "QuotaArn": "arn:aws:servicequotas:::route53/L-F767CB15",
        "QuotaCode": "L-F767CB15",
        "QuotaName": "Domain count limit",
        "Value": 20.0,
        "Unit": "None",
        "Adjustable": true,
        "GlobalQuota": true,
        "UsageMetric": {
            "MetricNamespace": "AWS/Usage",
            "MetricName": "ResourceCount",
            "MetricDimensions": {
                "Class": "None",
                "Resource": "DomainCount",
                "Service": "Route 53 Domains",
                "Type": "Resource"
            },
            "MetricStatisticRecommendation": "Maximum"
        },
        "Period": {
            "PeriodValue": 5,
            "PeriodUnit": "MINUTE"
        }
    }
]

اخیرا متوجه شدیم که باید RPS را برای دروازه‌های API برای Authress درخواست کنیم. پس بیایید بررسی کنیم تا ببینیم Quota Monitor چه چیزی را پیدا کرده است:

aws service-quotas list-aws-default-service-quotas \
  --service-code apigateway --region eu-west-1 \
  --query 'Quotas[?UsageMetric.MetricNamespace==`AWS/Usage`]'

[]

خوب RIP 🪦 . به نظر می رسد نظارت بر سهمیه کاملاً بی فایده است. حتی اگر خودمان بخواهیم از فضاهای نام متفاوت متریک استفاده کنیم، تنها مورد مرتبط با لامبدا این است:

[
    {
        "ServiceCode": "lambda",
        "ServiceName": "AWS Lambda",
        "QuotaArn": "arn:aws:servicequotas:eu-west-1::lambda/L-B99A9384",
        "QuotaCode": "L-B99A9384",
        "QuotaName": "Concurrent executions",
        "Value": 1000.0,
        "Unit": "None",
        "Adjustable": true,
        "GlobalQuota": false,
        "UsageMetric": {
            "MetricNamespace": "AWS/Lambda",
            "MetricName": "ConcurrentExecutions",
            "MetricDimensions": {},
            "MetricStatisticRecommendation": "Maximum"
        }
    }
]

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

aws service-quotas list-aws-default-service-quotas \
  --service-code lambda --region eu-west-1 \
  --query 'Quotas[?Adjustable==`true`].QuotaName'

[
    "Concurrent executions",
    "Function and layer storage",
    "Elastic network interfaces per VPC"
]

بنابراین سه، و تنها یک مورد بیشتر از آنچه با یک الگوی استفاده پیدا کردیم.

بنابراین در حال حاضر ما در وضعیت بسیار بدی هستیم. Quota Monitor به داده هایی وابسته است که در بیشتر موقعیت ها هرگز وجود نخواهد داشت.

ناامیدی

بسیار خوب، متاسفم برای فقدان هر راه حل واقعی. در حالی که این یک سفر برای تعریف یک مانیتور سهمیه ای است که هر کسی می تواند استفاده کند، بر اساس نحوه ساخت مانیتور اصلی، ما می دانیم که راه حل ساده ای وجود ندارد. این به این دلیل است که Quota Monitor AWS Solution بر اساس طراحی شکسته شده است. این فقط در مورد چیزهایی که ردیابی می شوند گزارش می دهد و AWS فقط زمانی استفاده را ردیابی می کند که آسان باشد. وقتی سخت است بگو Max(RPS) برای API Gateway در 5 دقیقه گذشته، هیچ داده استفاده یکپارچه Quota Service وجود ندارد. و بدون ردیابی آن داده ها، هیچ راهی برای هشدار در مورد آن وجود ندارد. اگر می‌خواهیم بدانیم که آیا می‌خواهیم با یکی از سرویس‌هایی که واقعاً استفاده می‌کنیم به محدودیت برسیم، باید به صراحت راه‌حلی بسازیم که آن چیز خاص را ردیابی کند.

من در حال حاضر مشغول راه اندازی مانیتورهای واقعی برای زیرساختمان هستم و برای هر کدام یک پست اختصاصی خواهیم داشت که نحوه انجام آن را بررسی می کند. پس با ما همراه باشید!

در مورد این موضوع کنجکاو هستید و می خواهید در مورد چیزهایی که ساخته ام گپ بزنید، در انجمن به من پیام دهید:

به جامعه بپیوندید