في المقالة دي من medium بيتكلموا عن ازاي عملوا scaling للdigest service ودي مسئولة عن الemails اليومية اللي فيها ترشيحات لمقالات.
الموضوع ممكن يكون بسيط في انك تعمل scaling بانك تزود الworkers او تستخدم lambda مثلا بس الفكرة انهم كانوا عايزين يقللوا الcost.
1/n
الموضوع ممكن يكون بسيط في انك تعمل scaling بانك تزود الworkers او تستخدم lambda مثلا بس الفكرة انهم كانوا عايزين يقللوا الcost.
1/n
بيحصل generation للemails ازاي؟
هم عايزين الdigest يوصل للناس الساعة 8AM فبيبدأوا مثلا قبلها بست ساعات عشان يضمنوا ان كل الusers هيجيلهم الdigest قبل 8AM وطبعا في time zones مختلفة.
2/n
هم عايزين الdigest يوصل للناس الساعة 8AM فبيبدأوا مثلا قبلها بست ساعات عشان يضمنوا ان كل الusers هيجيلهم الdigest قبل 8AM وطبعا في time zones مختلفة.
2/n
كل عشر دقايق Jenkins بتعمل trigger لevent اسمه shard event وده بيتقسم ل256 shard events وكل event بيجيب الusers من الshard بتاع الusers emails table وبيجيب اللي في الtime zone بتاعتهم الوقت اللي المفروض يبدأوا فيه.
3/n
3/n
لكل users بيتعمله generation event ودي بتعمل الdigest emails من الrecommendation service اللي اسمها Rex.
بعد كدة بيبقي في send events اللي بتبعت الemails لsendgrid ودي الthird party email service اللي بتبعت الemails للusers.
4/n
بعد كدة بيبقي في send events اللي بتبعت الemails لsendgrid ودي الthird party email service اللي بتبعت الemails للusers.
4/n
بيعملوا throttling للevents فهم عاملين max rate للevents يكون 500 في الثانية عشان يقللوا الcost فوصلوا للlimit فكان الemails بتتأخر وكمان events بتتأخر لليوم اللي بعده.
5/n
5/n
فصلوا الevents عن بعض في SQS queues مختلفة فبدل ما الgeneration event يعمل شغله ويبعت الsend events للqueue من الاول تاني لا هي دلوقتي هتروع لqueue تانية يتعملها processing علي طول ونفس الكلام طبقوه بعدين بالنسبة للshard events.
6/n
6/n
قللوا الevents بانهم يبعتوا للusers اللي فتحوا medium او الemails في ال45 يوم اللي فاتوا. كانوا بيعملوا الموضوع ده في اول الgenerartion events بس غيروا وبقوا يعملوه في الshard events عشان ميبقاش في generation events لكل الusers.
7/n
7/n
كان لسة في 22.5% من الgeneration events مبيتعملهمش send بسبب اللي وقفوا الemails او اتعملهم suspension فهيضيفوا الحاجات دي الusers emails table عشان الcheck يبقي من الshard events الاول.
8/n
8/n
لاحظوا ان في peaks كل عشر دقايق في Rex عشان الevents كل عشر دقايق فده خلي الservice تscale up وdown كل شوية.
وده بسبب الgeneration events اللي كانت بتتلغي اول ما تبدأ اتشالت وبقي الcheck من الshard events فالgeneration events كانت كأنها buffer بتخلي الRex جاهزة لload زيادة.
9/n
وده بسبب الgeneration events اللي كانت بتتلغي اول ما تبدأ اتشالت وبقي الcheck من الshard events فالgeneration events كانت كأنها buffer بتخلي الRex جاهزة لload زيادة.
9/n
حلوا الموضوع ده بانهم قسموا الgeneration events علي العشر دقايق بالSQS message timers يعني لكل user بيتعمله generation event بrandomized delay خلال العشر دقايق.
docs.aws.amazon.com
10/n
docs.aws.amazon.com
10/n
Scaling Email Infrastructure for Medium Digest
How we increased our email capacity by 3.8x
medium.engineering
11/n
How we increased our email capacity by 3.8x
medium.engineering
11/n
جاري تحميل الاقتراحات...