هذا هو الجزء الأول من المقالة التي سأتحدث فيها عن الطريقة التي صممنا بها عملية العمل على مشروع كبير لنقل قواعد البيانات: حول التجارب الآمنة ، وتخطيط الفريق والتفاعل بين الفرق. سوف أتحدث في المقالات التالية بمزيد من التفصيل عن المشكلات الفنية التي حلناها: حول التحجيم والتسامح مع الأخطاء في PostgreSQL واختبار التحميل.
لفترة طويلة ، كانت قاعدة البيانات الرئيسية في ميرو (RealtimeBoard السابقين) هي Redis. قمنا بتخزين كل المعلومات الأساسية: بيانات حول المستخدمين ، والحسابات ، واللوحات ، إلخ. كل شيء يعمل بسرعة ، ولكن واجهنا عددًا من المشكلات.
مشاكل مع Redis- الاعتماد على زمن الوصول إلى الشبكة. الآن في السحابة لدينا ، حوالي الساعة 20 بتوقيت موسكو ، ولكن عند زيادتها ، سيبدأ التطبيق في العمل ببطء شديد.
- عدم وجود فهارس نحتاجها على مستوى منطق العمل. يمكن أن يؤدي تنفيذها المستقل إلى تعقيد منطق العمل ويؤدي إلى تضارب البيانات.
- تعقيد التعليمات البرمجية يجعل أيضًا من الصعب الحفاظ على تناسق البيانات.
- كثافة الموارد للاستعلامات مع التحديدات.
هذه المشكلات ، بالإضافة إلى زيادة في كمية البيانات الموجودة على الخوادم ، كانت السبب في ترحيل قاعدة البيانات.
بيان المشكلة
تم اتخاذ القرار بشأن الهجرة. الخطوة التالية هي فهم قاعدة البيانات المناسبة لنموذج البيانات الخاص بنا.
أجرينا دراسة لتحديد قاعدة البيانات المثلى بالنسبة لنا ، واستقرنا على PostgreSQL. يتناسب نموذج البيانات الخاص بنا بشكل جيد مع قاعدة بيانات علائقية: يحتوي PostgreSQL على أدوات مدمجة لضمان تناسق البيانات ، وهناك نوع JSONB وقدرة على فهرسة بعض الحقول في JSONB. إنه يناسبنا.
تبدو البنية المبسطة لتطبيقنا كما يلي: هناك خوادم تطبيق تصل إلى Redis و RiakKV من خلال طبقة البيانات.
خادم التطبيق الخاص بنا هو تطبيق Java متجانس. تتم كتابة منطق الأعمال في إطار يتم تكييفه لـ NoSQL. يحتوي التطبيق على نظام معاملات خاص به ، والذي يسمح لك بتوفير مستخدمين متعددين على أي من لوحاتنا.
استخدمنا RiakKV لتخزين البيانات من لوحات الأرشيف التي لم تفتح لمدة 7 أيام.
أضف PostgreSQL إلى هذا المخطط. نجعل خوادم التطبيقات تعمل مع قاعدة البيانات الجديدة. نسخ البيانات من Redis و RiakKV إلى PostgreSQL. تم حل المشكلة!
لا شيء معقد ، ولكن هناك فروق دقيقة:- لدينا 2.2 مليون مستخدم مسجل. في كل يوم ، توظف ميرو 50 ألف مستخدم ، ويصل الحد الأقصى للحمل إلى 14 ألف مستخدم في المرة الواحدة. يجب ألا يواجه المستخدمون أخطاء بسبب عملنا ، ولا ينبغي لهم عمومًا أن يلاحظوا لحظة الانتقال إلى قاعدة جديدة.
- 1 تيرابايت من البيانات في قاعدة البيانات أو 410 مليون كائن.
- الإفراج المستمر عن الميزات الجديدة من قبل الفرق الأخرى ، التي يجب ألا نتدخل في عملها.
خيارات لحل المشكلة
واجهنا خيارين لترحيل البيانات:
- أوقف تطوير الخدمة → أعد كتابة الكود على الخادم ← اختبر الوظيفة ← قم بتشغيل إصدار جديد.
- قم بإجراء ترحيل سلس: قم بنقل أجزاء المنتج تدريجيًا إلى قاعدة بيانات جديدة ، ودعم كلاً من PostgreSQL و Redis وعدم مقاطعة تطوير ميزات جديدة.
يعد إيقاف تطوير الخدمة بمثابة خسارة للوقت يمكننا استخدامها للنمو ، مما يعني خسارة المستخدمين وحصة السوق. هذا أمر بالغ الأهمية بالنسبة لنا ، لذلك اخترنا الخيار مع الهجرة السلس. على الرغم من حقيقة أنه في التعقيد ، يمكن مقارنة هذه العملية باستبدال العجلات على سيارة أثناء القيادة.
عند تقييم العمل ، قمنا بتقسيم منتجاتنا إلى كتل رئيسية: المستخدمون والحسابات واللوحات وما إلى ذلك. بشكل منفصل ، تم تنفيذ العمل لإنشاء بنية PostgreSQL الأساسية. ويضعون المخاطر في التقييم في حالة حدوث خطأ ما (طريقة حدوث ذلك).
سباق العدوانية والأهداف
والخطوة التالية هي بناء فريق من خمسة أشخاص بحيث ينتقل الجميع بالسرعة المناسبة إلى هدف مشترك.
لدينا نقطتان: بداية العمل على المهمة والهدف النهائي. مثالي عندما نتحرك نحو الهدف بطريقة مباشرة. لكن غالبًا ما يحدث أننا نريد أن نسير في الاتجاه الصحيح ، لكن يبدو كما يلي:
على سبيل المثال ، بسبب الصعوبات والمشاكل التي لا يمكن التنبؤ بها مقدما.
الوضع ممكن لن نصل فيه إلى الهدف على الإطلاق. على سبيل المثال ، إذا ذهبنا إلى إعادة هيكلة عميقة أو إعادة كتابة التطبيق بأكمله.
لقد قسمنا المهمة إلى سباق أسبوعي لتقليل الصعوبات الموضحة أعلاه. إذا غادر الفريق فجأة إلى الجانب ، فيمكنه العودة بسرعة بأقل خسائر ممكنة للمشروع ، لأن التكرار القصير لا يسمح لك بالذهاب بعيدًا "بطريقة خاطئة".
كل تكرار له هدفه الخاص ، والذي ينقل الفريق إلى النتيجة الكبيرة النهائية.
إذا ظهرت مهمة جديدة أثناء سباق السرعة ، فنحن نقيم ما إذا كان تنفيذها يقربنا من الهدف أم لا. نعم - خذ السباق التالي أو غيّر الأولويات في الأولى الحالية ، إن لم تكن كذلك - لا تأخذها. إذا ظهرت أخطاء ، فإننا نعطيهم أولوية عالية ونصلحها بسرعة.
يحدث أن المطورين داخل العدو يجب أن تؤدي المهام في تسلسل محدد بدقة. أو ، على سبيل المثال ، يقوم المطور بتسليم المهمة النهائية إلى مهندس ضمان الجودة للاختبار العاجل. في مرحلة التخطيط ، نحاول بناء علاقات مماثلة بين المهام لكل عضو في الفريق. يسمح هذا للفريق بأكمله برؤية من سيقوم بماذا ومتى لا ينسى الاعتماد على الآخرين.
الفريق لديه مزامنة يومية وأسبوعية. كل صباح ، نناقش من وماذا وفي أي أولوية ستفعل اليوم. بعد كل سباق ، نتزامن مع بعضنا البعض للتأكد من أن الجميع يتحرك في الاتجاه الصحيح. تأكد من التخطيط لإصدارات كبيرة أو معقدة. نقوم بتعيين مطورين في الخدمة ، إذا لزم الأمر ، حاضرين أثناء الإصدار ونراقب أن كل شيء في محله.
يسمح التخطيط والمزامنة داخل الفريق بإشراك جميع المشاركين في جميع مراحل المشروع. الخطط والتقييمات لا تأتي إلينا من الأعلى ، بل نجعلها أنفسنا. هذا يزيد من مسؤولية واهتمام الفريق في إنجاز المهام.
هذا هو واحد من سباق العدو. نحمل كل شيء على لوحة ميرو:
وسائط والتجارب الآمنة
أثناء الترحيل ، كان علينا ضمان التشغيل المستقر للخدمة في ظروف القتال. للقيام بذلك ، عليك التأكد من اختبار كل شيء وعدم وجود أخطاء في أي مكان. لتحقيق هذا الهدف ، قررنا أن نجعل هجرتنا السلسة أكثر سلاسة.
كانت الفكرة هي تبديل كتل المنتجات تدريجياً إلى قاعدة بيانات جديدة. للقيام بذلك ، توصلنا إلى سلسلة من وسائط.
في وضع "Redis Read / Write" الأول ، تعمل قاعدة البيانات القديمة ، Redis فقط.
في الوضع الثاني لـ "PostgreSQL Passive Write" ، يمكننا التأكد من أن الكتابة إلى قاعدة البيانات الجديدة صحيحة وأن قواعد البيانات متسقة.
يسمح لك
الوضع الثالث "قراءة / كتابة PostgreSQL ، Redis Passive Write" بالتحقق من صحة قراءة البيانات من PostgreSQL ومعرفة كيفية سلوك قاعدة البيانات الجديدة في ظروف القتال. في نفس الوقت ، يظل Redis هو القاعدة الرئيسية ، التي مكنتنا من العثور على حالات محددة من العمل مع لوحات قد تؤدي إلى أخطاء.
في وضع "الكتابة / الكتابة" الأخير ، يتم تشغيل قاعدة البيانات الجديدة فقط.
يمكن أن تؤثر أعمال الترحيل على الوظائف الرئيسية للمنتج ، لذلك كان علينا التأكد بنسبة 100٪ من أننا لن نكسر أي شيء وأن قاعدة البيانات الجديدة تعمل على الأقل بنفس سرعة القاعدة القديمة. لذلك ، بدأنا في إجراء تجارب آمنة مع تبديل أوضاع.
لقد بدأنا في تبديل الأوضاع على حساب الشركة الخاص بنا ، والذي نستخدمه يوميًا في العمل. بعد التأكد من عدم وجود أخطاء فيه ، بدأنا في تبديل الأوضاع على مجموعة صغيرة من المستخدمين الخارجيين.
الجدول الزمني لإطلاق التجارب مع الأوضاع هو كما يلي:
- يناير-فبراير: Redis قراءة / كتابة
- مارس-أبريل: PostgreSQL السلبي الكتابة
- من مايو إلى يونيو: قراءة / كتابة PostgreSQL ، قاعدة البيانات الرئيسية - Redis
- تموز (يوليو) - آب (أغسطس): PostgreSQL قراءة / كتابة
- سبتمبر-ديسمبر: الهجرة الكاملة.
في حالة حدوث أخطاء ، أتيحت لنا الفرصة لإصلاحها بسرعة ، لأننا نحن يمكن أن نصدر إصدارات إلى الخوادم التي يعمل فيها المستخدمون المشاركون في التجربة. لم نعتمد على الإصدار الرئيسي ، لذلك قمنا بإصلاح الأخطاء بسرعة وفي أي وقت.
التعاون عبر الفريق
أثناء الترحيل ، تقاطعنا غالبًا مع الفرق التي أصدرت ميزات جديدة. لدينا قاعدة شفرة واحدة ، وكجزء من عملهم ، يمكن للفرق تغيير الهياكل الموجودة في قاعدة بيانات جديدة أو إنشاء هياكل جديدة. في الوقت نفسه ، يمكن أن تحدث تقاطعات الفرق لتطوير الميزات الجديدة وسحبها. على سبيل المثال ، وعد أحد فرق المنتج فريق التسويق بإصدار ميزة جديدة بحلول تاريخ محدد ؛ قام فريق التسويق بالتخطيط لحملة إعلانية لهذه الفترة ؛ ينتظر فريق المبيعات ميزة وحملة لبدء التواصل مع عملاء جدد. اتضح أن الجميع يعتمد على بعضهم البعض ، وتأخير المواعيد النهائية من قبل فريق واحد يعطل خطط الآخر.
لتجنب مثل هذه المواقف ، قمنا ، مع الفرق الأخرى ، بتجميع خريطة طريق واحدة للبقالة ، تمت مزامنتها عدة مرات كل ربع عام ، ومع بعض الفرق أسبوعيًا.
الاستنتاجات
ما تعلمناه خلال هذا المشروع:
- لا تخف من القيام بمشاريع معقدة. بعد التحلل والتقييم وتطوير أساليب العمل ، تبدو المشروعات المعقدة مستحيلة.
- لا تدخر الوقت والجهد على التقديرات الأولية والتحلل والتخطيط. يساعد هذا في فهم المشكلة بشكل أعمق قبل البدء في العمل عليها ، وفهم حجم وتعقد العمل.
- ضع المخاطر في المشروعات الفنية والتنظيمية الصعبة. في عملية العمل ، سوف تواجه بالتأكيد مشكلة لم يتم أخذها في الاعتبار عند التخطيط.
- لا تهاجر إلا إذا لزم الأمر.
في المقالات التالية ، سأتحدث أكثر عن المشكلات الفنية التي حللناها أثناء الترحيل.