KEDA

همان‌طور که می‌دونید و قبلا هم در موردش صحبت کردیم مقیاس‌پذیری (Scalability) یکی از اصول کلیدی در طراحی و مدیریت سیستم‌های توزیع‌شده است. گاهی مقیاس‌پذیری مستقیم هست. یعنی با افزایش لود میزان مصرف رم و پردازنده زیاد می‌شه که باید یا تعداد اپلیکیشن رو بیشتر کنیم (Scale Out) که با HPA انجام می‌دیم و یا مقدار منابع رو زیاد کنیم (Scale Up) که اونم با VPA انجام می‌دیم. این مدل خیلی مرسوم هست و راه حلش رو هم قبلا تو auto scaling kubernetes توضیح دادیم. حالا اگر چیزی که می‌خواهیم باهاش اسکیل کنیم منابع نباشه چی کار باید بکنیم؟ مثلا تعداد ریکوئست‌های تو نوبت یا تعداد Queuهای تو صف؟ برای این نوع از موارد باید چی کار کنیم؟ این بار می‌خوام در مورد مدل‌هایی صحبت کنم که دیگه مقیاس‌پذیری این طوری مستقیم نیست. مثلا فرض کنید یه سرویس ربیت داریم که یکی از صف‌های اون خیلی طولانی شده. اینجا دیگه اسکیل کردن ربیت کمکی به ما نمی‌کنه. باید استفاده‌کننده‌ی آن صف (consumer) رو اسکیل کنیم. اونم بی خبر از همه چیز داره آروم آروم صف رو خالی می‌کند. دقیقا اینجا KEDA به داد ما می‌رشد. KEDA (Kubernetes Event-driven Autoscaling) ابزاری است که به ما کمک می‌کند تا به‌راحتی بر اساس رویدادهای مختلف و بار کاری سیستم، مقیاس‌گذاری کنیم.  

 

KEDA چیست؟

KEDA یک نوع ورکلود برای AutoScaling داخل کوبرنتیز است که به ما امکان می‌دهد تا مقیاس‌گذاری خودکار پادها (Pods) را بر اساس رویدادها انجام دهیم. به عبارت دیگر، با استفاده از KEDA، می‌توانیم تعداد پادها را بر اساس بار کاری و تعداد رویدادهایی که به سیستم می‌رسد، به‌طور خودکار افزایش یا کاهش دهیم. فرض کنید شما یک سرویس پردازش داده دارید که از یک صف پیام (Message Queue) پشتیبانی می‌کند. KEDA می‌تواند تعداد پادها را بر اساس تعداد پیام‌های موجود در صف به‌طور خودکار تنظیم کند.

چرا KEDA مهم است؟

۱. مقیاس‌گذاری بهینه: KEDA به ما این امکان را می‌دهد که منابع را بر اساس تقاضای واقعی مدیریت کنیم و از مصرف بی‌مورد منابع جلوگیری کنیم.

۲. پشتیبانی از منابع مختلف: KEDA از منابعی مانند Apache Kafka، RabbitMQ، Azure Queue، AWS SQS و غیره پشتیبانی می‌کند. این گستردگی به کاربران اجازه می‌دهد تا از KEDA در پروژه‌های مختلف با انواع نیازها استفاده کنند.

۳. سادگی پیاده‌سازی: نصب و راه‌اندازی KEDA در کوبرنتیز بسیار ساده است و می‌تواند به سرعت قابلیت‌های مقیاس‌گذاری خودکار را به پروژه‌های شما اضافه کند.

۴. انعطاف‌پذیری: می‌توان KEDA را به راحتی با میکروسرویس‌های مختلف یکپارچه کرد و حتی می‌توان متدهای خودتون را برای اسکیلینگ تعریف کنید.

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

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

۷. توانمندی‌های پیشرفته: KEDA امکان تعریف چندین Trigger را فراهم می‌کند، به این معنی که می‌توانید مقیاس‌گذاری را بر اساس چندین معیار همزمان انجام دهید. این امر به توسعه‌دهندگان اجازه می‌دهد تا سناریوهای پیچیده‌تری را پیاده‌سازی کنند و سیستم‌های خود را بهینه‌تر مدیریت نمایند.

نحوه کارکرد KEDA

KEDA به کمک یک یا چند “اسکیلر” (Scaler) کار می‌کند که به منابع مختلف متصل می‌شوند و وضعیت بار کاری را بررسی می‌کنند. وقتی که بار کاری به یک سطح مشخص برسد، KEDA می‌تواند تعداد پادها را تغییر دهد. مثلاً اگر یک صف پیام حاوی ۱۰۰ پیام باشد و ما تنظیم کرده باشیم که اگر تعداد پیام‌ها بیش از ۵۰ باشد، تعداد پادهای استفاده کننده از آن صف افزایش یابد، KEDA به‌طور خودکار تعداد پادها را افزایش می‌دهد. این فرایند به چند مرحله تقسیم می‌شود:

  • پیکربندی اسکیلر: شما می‌توانید نوع اسکیلر را که می‌خواهید استفاده کنید (برای مثال، تعداد پیام در صف) تعریف کنید.
  • مقیاس‌گذاری: زمانی که بار کاری از سطح مشخصی فراتر می‌رود، KEDA به‌طور خودکار تعداد پادهای استفاده‌کننده را افزایش می‌دهد و برعکس، اگر بار کاری کاهش یابد، تعداد پادهای استفاده کننده را نیز کاهش می‌یابد.
  • نظارت: KEDA قابلیت نظارت بر وضعیت پادها و بار کاری را دارد و می‌تواند بر اساس‌ تغییرات، تصمیمات لازم را اتخاذ کند..

مزایا و چالش‌های KEDA:

مزایا:

  • کاهش هزینه‌ها: با مقیاس‌گذاری هوشمندانه بر اساس تقاضا، می‌توانید هزینه‌های زیرساخت خود را تا حد زیادی کاهش دهید.
  • تجربه کاربری بهتر: با کنار گذاشتن مشکلات مربوط به بار اضافی، کاربران تجربه بهتری خواهند داشت.
  • مدیریت ساده: راه‌اندازی و پیکربندی KEDA بسیار ساده است و نیاز به دانش عمیق فنی ندارد.

چالش‌ها:

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

کامپوننت‌های KEDA

۱. کامپوننت KEDA Operator:

KEDA Operator در واقع یک اپلیکیشن درون کوبرنتیز است که وظیفه اصلی مدیریت منابع KEDA را بر عهده دارد. این اپراتور به صورت دائمی در حال اجرا است و به‌طور مداوم تغییرات وضعیت‌ پادها، ScaledObjectها و Triggerها را نظارت می‌کند. وظایف KEDA Operator شامل موارد زیر است:

  • مدیریت وضعیت پادها: اپراتور در صورت تغییر شرایط بار کاری، تعداد پادها را به‌طور خودکار افزایش یا کاهش می‌دهد.
  • نظارت بر منابع: KEDA Operator به‌طور فعال وضعیت منابع وابسته به Triggerها را نظارت می‌کند و به روش‌های مختلف بار کاری را اندازه‌گیری می‌کند.
  • پیکربندی: این اپراتور به شما امکان می‌دهد که به راحتی پارامترهای لازم را پیکربندی کنید، بدون اینکه نیاز باشد مستقیماً با API کوبرنتیز کار کنید.

۲. کامپوننت ScaledObject:

ScaledObject ساختاری است که شما به عنوان کاربر KEDA تعریف می‌کنید تا مشخص کنید که کدام پاد باید مقیاس‌گذاری شود و چه شرایطی باید بر اساس آن انجام گیرد. هر ScaledObject شامل اطلاعات زیر است:

  • scaleTargetRef: این بخش مشخص می‌کند که کدام پاد یا Deployment باید کنترل و مقیاس‌گذاری شود.
  • minReplicaCount و maxReplicaCount: این دو پارامتر حداقل و حداکثر تعداد پادها را مشخص می‌کنند. به عنوان مثال، اگر بار کاری به کمترین حد خود برسد، KEDA به حداقل تعداد پادها (minReplicaCount) برمی‌گردد و اگر بار کاری افزایش یابد، می‌تواند به حداکثر تعداد (maxReplicaCount) برسد.
  • triggers: این بخش شامل تعدادی Trigger است که شرایط مقیاس‌گذاری را تعیین می‌کند. به عنوان مثال، می‌توان مشخص کرد که در صورت وجود یک تعداد مشخص از پیام‌ها در صف، تعداد پادها باید افزایش یابد.

. کامپوننت Trigger:

Trigger، یا محرک، کلید اصلی عمل‌کرد اتو اسکیلینگ در KEDA است. KEDA به کمک Triggerها تصمیم می‌گیرد که چه زمانی باید پادها را مقیاس‌بندی کند. برخی از مهم‌ترین Triggerها عبارتند از:

  • Queue Length Trigger: این Trigger می‌تواند با صف‌های مختلفی مانند RabbitMQ یا AWS SQS کار کند. با توجه به تعداد پیام‌ها در صف، KEDA تعداد پادها را تنظیم می‌کند.
  • Prometheus Trigger: این Trigger از متریک‌های Prometheus استفاده می‌کند. شما می‌توانید متریک‌های خاصی تعریف کنید و KEDA می‌تواند بر اساس آن‌ها تعداد پادها را افزایش یا کاهش دهد.
  • External API Trigger: این نوع Trigger به شما امکان می‌دهد که با استفاده از یک API خارجی، شرایط خاصی را برای مقیاس‌گذاری تعریف کنید. به عنوان مثال، وقتی یک سرویس خاص به یک Endpoint خاص دسترسی پیدا کند، KEDA می‌تواند پادها را افزایش دهد.

۴. کامپوننت Metrics Adapter:

Metrics Adapter به عنوان یک پل عمل می‌کند که اطلاعات مربوط به بار کاری را از Triggerها به KEDA منتقل می‌کند. این کامپوننت، داده‌های جمع‌آوری‌شده از Triggerها را پردازش کرده و شرایط فعلی بار کاری را به KEDA ارائه می‌دهد. وظایف مهم Metrics Adapter شامل موارد زیر است:

  • جمع‌آوری داده: اطلاعات مربوط به بار کاری از Triggerها را جمع‌آوری و پردازش می‌کند تا قابل استفاده برای تصمیم‌گیری KEDA باشد.
  • سازگاری با منابع مختلف: Metrics Adapter فرایند جمع‌آوری داده‌ها را از منابع مختلف، مانند صف‌ها یا متریک‌های تعریف‌شده، انجام می‌دهد.

۵. کامپوننت KEDA Dashboard:

رابط کاربری KEDA به کاربر این امکان را می‌دهد که به‌طور بصری وضعیت KEDA و ScaledObjectها را مشاهده کند. این Dashboard به کاربران کمک می‌کند تا به راحتی وضعیت مقیاس‌گذاری و بار کاری پادها را بررسی کرده و در صورت نیاز تغییراتی ایجاد کنند.

چند نمونه از استفاده‌‌های KEDA:

۱. پردازش داده‌های زمان واقعی (Real-time Data Processing)

KEDA می‌تواند در سناریوهای پردازش داده‌های زمان واقعی، مانند پردازش پیام‌ها از صف‌هایی مانند Apache Kafka یا RabbitMQ، بسیار مفید باشد. به عنوان مثال:

  • وضعیت: یک سیستم پردازش پیام که نیاز دارد بر اساس تعداد پیام‌های موجود در صف، تعداد پادهای مصرف‌کننده‌ی آن پیام را تنظیم کند.
  • عملکرد: KEDA می‌تواند به طور خودکار تعداد پادها را بر اساس تعداد پیام‌ها در صف افزایش یا کاهش دهد. این باعث افزایش کارایی و کاهش هزینه‌های زیرساخت می‌شود.

۲. مدیریت بار کاربران متغیر (Variable User Load Management)

در برنامه‌هایی که دارای بار کاربری متغیر هستند، KEDA می‌تواند به مقیاس‌گذاری پادها بر اساس تعداد درخواست‌های ورودی کمک کند. مثلاً:

  • وضعیت: یک وب‌سایت یا اپلیکیشن که در زمان‌هایی خاص (مانند روزهای تعطیل یا رویدادهای خاص) حجم بالایی از ترافیک وب را تجربه می‌کند.
  • عملکرد: با اتصال KEDA به متریک‌های یکی از ابزارهای نظارتی (مانند Prometheus)، می‌توان بار را مدیریت کرده و با افزایش تعداد پادها در زمان نیاز، پاسخگویی بهتری به کاربران ارائه داد.

۳. تولید و پردازش رویدادها (Event Generation and Processing)

KEDA می‌تواند در پردازش و مدیریت رویدادها در سیستم‌های مبتنی بر رویداد کمک کند. این مسئله در محیط‌هایی که نیاز به تولید و پردازش سریع رویدادها دارند، بسیار مفید است. برای مثال:

  • وضعیت: یک سیستم پایش که باید به رویدادهای ورودی (مانند رویدادهای IoT یا تحلیل داده‌های سنسورها) پاسخ دهد.
  • عملکرد: KEDA می‌تواند تعداد پادهای پردازش به ازای هر رویداد ورودی را تنظیم کند و به شما این امکان را می‌دهد که به سرعت به نیازهای پردازش سریع پاسخ دهید.

۴. سناریوهای ترکیبی (Hybrid Scenarios)

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

  • وضعیت: نیاز به پردازش هم‌زمان درخواست‌های کاربری و رویدادهای پردازش داده.
  • عملکرد: KEDA می‌تواند با تنظیم چند Trigger مختلف، به‌طور هم‌زمان و بهینه‌سازی مقیاس‌ها بپردازد.

۵. خدماتی بر بستر APIs

در پلتفرم‌هایی که با API کار می‌کنند، KEDA می‌تواند به بهینه‌سازی بارهای ورودی به این APIs کمک کند. به عنوان مثال:

  • وضعیت: خدماتی که باید به حجم بالایی از درخواست‌های API در دوره‌های خاص پاسخ دهند.
  • عملکرد: تنظیم تعداد پادها بر اساس تعداد درخواست‌های API، به‌گونه‌ای که کارایی سیستم به حداکثر برسد.

نتیجه‌گیری

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

 

 در ادامه برخی از نمونه‌های Keda رو بررسی می‌کنیم:

نمونه اول: پردازش پیام از RabbitMQ

فرض کنید که شما یک سرویس دارید که پیام‌ها را از یک صف RabbitMQ دریافت می‌کند و می‌خواهید تعداد پادها را بر اساس تعداد پیام‌های موجود در آن صف مقیاس‌بندی کنید.

				
					apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
 name: rabbitmq-processed
 namespace: default
spec:
 scaleTargetRef:
   name: my-rabbitmq-consumer
 minReplicaCount: 1
 maxReplicaCount: 10
 triggers:
 - type: rabbitmq
   metadata:
     queueName: my-queue
     host: RabbitMQ-Host
     queueLength: "5"# If length of queue is more than 5, scale up
				
			

نمونه دوم: مقیاس‌گذاری بر اساس Prometheus

در این سناریو، شما می‌خواهید تعداد پادها را بر اساس متریک‌های Prometheus مقیاس‌بندی کنید. فرض کنید که متریکی به نام http_requests_total دارید که تعداد درخواست‌های ورودی را نشان می‌دهد.

				
					apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
 name: prometheus-scaler
 namespace: default
spec:
 scaleTargetRef:
   name: my-http-service
 minReplicaCount: 2
 maxReplicaCount: 20
 triggers:
 - type: prometheus
   metadata:
     server: http://prometheus-server:9090
     metricName: http_requests_total
     threshold: '100'# Scale up when there are more than 100 requests
     query: sum(rate(http_requests_total[1m])) by (instance)

				
			

نمونه سوم: پردازش Batch Jobs

این مثال نشان می‌دهد که چگونه می‌توان تعدادی Job را پردازش کرد که بر اساس حداکثر تعداد jobs موجود در صف عمل می‌کند.

				
					apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
 name: batch-job-processor
 namespace: default
spec:
 scaleTargetRef:
   name: my-batch-processor
 minReplicaCount: 1
 maxReplicaCount: 5
 triggers:
 - type: jobs
   metadata:
     jobName: my-batch-job
     queueLength: "3"  # Scale up when there are more than 3 jobs

				
			

نمونه چهارم: HTTP Request Scaler

فرض کنید که شما می‌خواهید تعداد پادهای خود را بر اساس تعداد درخواست‌های API دریافتی مقیاس‌بندی کنید.

				
					apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
 name: http-request-scaler
 namespace: default
spec:
 scaleTargetRef:
   name: my-api-service
 minReplicaCount: 2
 maxReplicaCount: 10
 triggers:
 - type: http
   metadata:
     url: http://my-api-service:8080/health
     method: GET
     responseThreshold: "200"#Scaleup if response time exceeds 200 ms


				
			

دیدگاه‌ خود را بنویسید

مقاله های داکرمی

KEDA

KEDA

همان‌طور که می‌دونید و قبلا هم در موردش صحبت کردیم مقیاس‌پذیری (Scalability) یکی از اصول کلیدی در طراحی و مدیریت سیستم‌های توزیع‌شده است. گاهی مقیاس‌پذیری مستقیم هست. یعنی با افزایش لود میزان مصرف رم و پردازنده زیاد می‌شه که باید

توضیحات بیشتر »
Kubernetes

دیپلوی voting-app (قسمت بیستم)

توی این قسمت میریم به سراغ اینکه بررسی کنیم چطوری می‌تونیم یه اپلیکیشن رو روی کلاستر کوبرنتیزمون دیپلوی کنیم و بالا بیاریم: خب یه مروری کنیم پست‌های قبلی رو: دواپس چیه و چرا لازمه؟  اینجا در مورد دواپس و ضرورت

توضیحات بیشتر »
Kubernetes

نصب کلاستر با rancher (قسمت نوزدهم)

توی این قسمت میریم به سراغ اینکه بررسی کنیم چطوری می‌تونیم یه کلاستر کوبرنتیز رو با استفاده از rancher ستاپ کنیم و بیاریم بالا. خب یه مروری کنیم پست‌های قبلی رو: دواپس چیه و چرا لازمه؟ اینجا در مورد دواپس و

توضیحات بیشتر »
پیمایش به بالا