المقدمة

شركة Stripe هي شركة متخصصة في توفير حلول الدفع سواء أونلاين أو في التعاملات الشخصية، وكمان بتوفر خدمات مالية للشركات بمختلف أحجامها. وطبعًا الشركة شغالة بنظام الـ Microservices وهو نظام معقد جدًا ومبني على AWS.

خلونا في رحلتنا انهاردة نتعرف على الرحلة والتحديات اللي قابلتها Stripe، والحلول اللي استخدمتها لما قررت تنقل نظام الـ (Observability Solution) بتاعها للمستخدمين على Amazon Managed Service for Prometheus (AMP).

الوضع قبل الـ Migration

قبل ما تبدأ Stripe عملية الـ Migration ، كانت بتتعامل مع أكتر من:

• 300 مليون metric.
• 40 ألف alert.
• 100 ألف Queries بتحصل على الـ Dashboards.

وده كله كان بيتم من خلال حوالي 7,000 موظف ، والشركة كانت معتمدة على time-series data platform كحل لمراقبة الـ metrics بتاعتها. ولكن واجهتهم بعض المشاكل زي:

1. الـ Scalability limits: نظام الـ Observability ماكنش بيستحمل الحجم ده من الـ Metrics , Alerts والـ Queries اللي بتحصل على الـ Dashboard.
2. الـ Reliability issues: مشاكل في استقرار النظام.
3. الـ Increased cost: تكلفة متزايدة مع استمرار استخدام النظام ده.

التحديات

أكبر تحديين كانوا بيواجهوا Stripe في الـ Third-Party Vendor Solution اللي كانوا بيستعملوه هما:

1. التكلفة
2. الـ Scalability: وده لإن كل ما نظام الـ microservices بتاعهم زاد تعقيدًا، ظهرت الحاجة لحل أكتر كفاءة من حيث التكلفة والـ Scale.

عشان كده قرروا ينقلوا تخزين الـ metrics بتاعتهم لـ Amazon Managed Prometheus.

نظرة سريعة على الحل

شركة Stripe قررت تتبع خطة من 4 مراحل لنقل النظام وعملية الـ Migration ككل والخطة كانت:

1. اعتمادهم على الـ Dual-write: وده معناه إنهم هيكتبوا الـ metrics على النظام القديم والجديد في نفس الوقت.
2. الـ Translation: وده من خلال تحويل الـ alerts والـ dashboards الحالية للغة PromQL وAmazon Managed Grafana عشان تبقى متناسبة معاها.
3. الـ Validation: التأكد من صحة البيانات اللي تمت ترجمتها عشان تبقى Compatible مع النظام الجديد والـ metrics المكتوبة.
4. الـ Migration of users' mental models: تغيير طريقة تفكير المستخدمين عشان تتناسب مع Prometheus.

خلونا نشوف الـ Architecture كان عامل ازاي اثناء الـ Migration Process بتاعتهم:

Collection

الـ Collection (جمع البيانات):

• الـ Metrics بيتم جمعها من خلال :
  1. الـ host applications (ودي التطبيقات اللي شغالة على الـ servers).
  2. الـ Kubernetes clusters (وده من خلال عملية scraping).
• البيانات دي بتتبعت بعد كده للـ Aggregation Layer.

Aggregation

الـ Aggregation (تجميع البيانات):

• في المرحلة دي، الـ shuffler بيبعت البيانات للـ host الصح.
• الـ Aggregator بيعمل حاجات أساسية لتقليل الحجم الـ Cardinality زي إنه:
  • بيحسب المتوسطات (averages) للـ gauges.
  • بيجمع الـ counters.
  • بيحسب الـ percentiles.

طب يعني ايه Cardinality Reductions ؟
هي عملية بنقوم بيها عشان نقلل عدد العناصر أو البيانات الفريدة اللي بيتعامل معاها النظام لما بيحلل أو بيخزن البيانات وبيكون الهدف منها هو تحسين أداء النظام وتقليل استهلاك الموارد زي التخزين والمعالجة.

طب ليه ممكن نحتاج لحاجة زي كده ؟
لما تبقى الـ metrics فيها عدد كبير جدًا من القيم الفريدة (unique values)، ده ممكن يعمل مشاكل زي:

1. زيادة استهلاك الذاكرة (Memory Usage): كل قيمة فريدة لازم يكون ليها مكان في التخزين.
2. بطء في معالجة البيانات (Processing): النظام بياخد وقت أطول لما العدد يزيد.
3. زيادة التكلفة: سواء من ناحية التخزين أو استهلاك الموارد.

وعشان كده الـ Aggregator كان من ضمن مهامه الأساسية إنه يقلل من الـ Cardinality على قد ما يمكن.

Writing to AMP