تغییر اندازه نمونه های EC2 بدون خرابی – انجمن DEV

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

قدم در دنیای واقعی

هنگام مقیاس بندی زیرساخت خود، مهم است که مرتباً ارزیابی کنید که آیا اندازه نمونه فعلی شما مطابق با خواسته های پروژه شما است یا خیر. عواملی مانند استفاده از CPU و رشد کاربر را در نظر بگیرید تا تعیین کنید چه زمانی تغییر اندازه ضروری است.

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

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

resource "aws_autoscaling_group" "example_ec2_asg" {
  name                      = "example-asg"
  vpc_zone_identifier       = [aws_subnet.private_subnet_1.id, aws_subnet.private_subnet_2.id]
  launch_configuration      = aws_launch_configuration.ecs_launch_config.name
  force_delete              = true
  health_check_grace_period = 10

  desired_capacity = 2
  min_size         = 1
  max_size         = var.max_size

  lifecycle {
    create_before_destroy = true
  }
}

# EC2 launch configuration
resource "aws_launch_configuration" "example_ecs_launch_config" {
  name_prefix          = "ecs_launch_config-"
  image_id             = data.aws_ami.example_ami.id
  iam_instance_profile = aws_iam_instance_profile.ecs_agent.name
  security_groups      = [aws_security_group.ecs_tasks_sg.id]
  instance_type               = var.ec2_instance_type // passing in as var
  associate_public_ip_address = false
  user_data                   = <<EOF
    #!/bin/bash
    echo ECS_CLUSTER=${aws_ecs_cluster.main.name} >> /etc/ecs/ecs.config
    EOF

  depends_on = [aws_ecs_cluster.main]
  lifecycle {
    create_before_destroy = true
  }
}

در قطعه کد بالا می‌توانید پیکربندی راه‌اندازی نمونه‌های EC2 من را ببینید. متوجه خواهید شد که من نوع نمونه را به عنوان یک متغیر وارد می‌کنم – این به این دلیل است که من از اندازه‌های نمونه متفاوتی بسته به محیط استقرار (به عنوان مثال QA، تست، تولید) استفاده می‌کنم.

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

هدف

نمونه های EC2 من در حال حاضر هستند t2.small و من می خواهم آنها را به روز کنم t2.medium

نگرانی

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

طرح

من متغیر محیطی را برای terraform به روز کردم تا اکنون a t2.medium و برای مشاهده تغییرات معلق، یک پلان زمینی اجرا کرد:

در اسکرین شات، می توانید ببینید که پلان زمینی نشان می دهد که یک وجود خواهد داشت force replacement از نمونه EC2 برای به روز رسانی نوع.

برای آزمایش و اینکه ببینم خرابی ایجاد می کند یا خیر، استقرار در محیط آزمایشی خود را تأیید کردم. هنگامی که پلان terraform تمام شد، به کنسول EC2 رفتم و می‌توانستم ببینم که نمونه‌های من هر دو هنوز اندازه t2.small هستند.

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

امتحان

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

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

هنگامی که نمونه متوسط ​​جدید در حالت آماده بود و من در ECS می‌توانستم ببینم که سرویس راه‌اندازی شده است، نمونه کوچک دوم را متوقف کردم. دوباره وقتی متوقف شد، می‌توانستم ببینم که یک نمونه متوسط ​​جدید به جای آن ایجاد می‌شود و در ECS ثبت می‌شود.

اکنون اطمینان دارم که می‌توانم این ارتقا را در محیط‌های QA و Production خود بدون هیچ گونه خرابی کاربر نهایی انجام دهم.

ملاحظات

• از یک ابزار زیرساخت به عنوان کد برای کمک به پیگیری به‌روزرسانی‌های پیکربندی استفاده کنید.

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

• اطمینان حاصل کنید که تعداد نمونه های مورد نظر شما بیشتر از یک نمونه است، تا استراتژی به روز رسانی چرخشی را فعال کنید و همچنین در صورت ناسالم شدن یکی از نمونه های شما کمک کنید.

• مطمئن شوید که یک نقطه پایانی سلامتی دارید، که به شما امکان می‌دهد به راحتی سرویس را در طول به‌روزرسانی زیرساخت آزمایش کنید تا مطمئن شوید که ترافیک طبق انتظار هدایت می‌شود.

• در صورتی که چیزی در طول به روز رسانی شما با شکست مواجه شود، یک استراتژی بازگشت به عقب داشته باشید

نتیجه

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