একটি ক্রমবর্ধমান অল-ইন-ওয়ান APM হিসাবে, AppSignal আমাদের ট্রাফিক বৃদ্ধির সাথে মানিয়ে নিতে পারে তা নিশ্চিত করতে আমরা অনেক সময় ব্যয় করি। সাধারণত, আমরা কীভাবে তা করি সে বিষয়ে কথা বলি না; আমাদের ব্লগটি রুবির হুডের অধীনে দুর্দান্ত জিনিসগুলি বা এলিক্সিরের সাথে পাগল জিনিসগুলি সম্পর্কে নিবন্ধে পূর্ণ, তবে অ্যাপসিগন্যালকে কী টিক দেয় সে সম্পর্কে নয়৷
এইবার যাইহোক, আমরা গত কয়েক বছরে আমাদের স্ট্যাকের কিছু বড় পরিবর্তন শেয়ার করতে চাই, যাতে আমরা (সহজেই) প্রতি মাসে আমাদের প্রেরিত দ্বিগুণ-অঙ্কের বিলিয়ন অনুরোধগুলি প্রক্রিয়া করতে পারি। বাস্তব সময়ে. তাই আজ আমরা আমাদের স্কেলিং অভিজ্ঞতা ব্যবহার করে আমাদের নিজস্ব স্ট্যাক নিয়ে আলোচনা করি এবং আপনাকে সেইভাবে সাহায্য করি৷
একটি স্ট্যান্ডার্ড রেল সেটআপ থেকে আরও কাস্টম পার্টস পর্যন্ত
AppSignal একটি সুন্দর স্ট্যান্ডার্ড রেল সেটআপ হিসাবে শুরু হয়েছিল। আমরা একটি Rails অ্যাপ ব্যবহার করেছি যা একটি API এন্ডপয়েন্টের মাধ্যমে ডেটা সংগ্রহ করেছে যা পটভূমিতে প্রক্রিয়া করার জন্য Sidekiq কাজ তৈরি করেছে।
কিছুক্ষণ পরে আমরা কিছুটা গতি অর্জনের জন্য Rails API-কে একটি Rack Middleware দিয়ে প্রতিস্থাপিত করেছি এবং পরে এটি একটি Go ওয়েব সার্ভারের সাথে প্রতিস্থাপিত হয়েছে যা Sidekiq সামঞ্জস্যপূর্ণ কাজগুলিকে Redis-এ ঠেলে দিয়েছে৷
অ্যাপ স্টেট এবং ইনক্রিমেন্ট/আপডেট
যদিও এই সেটআপটি দীর্ঘ সময়ের জন্য ভালভাবে কাজ করেছিল, আমরা এমন সমস্যাগুলির মধ্যে পড়তে শুরু করি যেখানে ডেটাবেসগুলি তাদের বিরুদ্ধে চালানো প্রশ্নের পরিমাণের সাথে তাল মিলিয়ে চলতে পারেনি। এই মুহুর্তে আমরা ইতিমধ্যে কয়েক বিলিয়ন অনুরোধ প্রক্রিয়া করছিলাম। এর প্রধান কারণ ছিল সঠিক কাউন্টার বৃদ্ধি এবং সঠিক নথি আপডেট করার জন্য প্রতিটি Sidekiq প্রক্রিয়ার জন্য ডাটাবেস থেকে পুরো অ্যাপের অবস্থা পেতে হবে।
আমরা ডেটার স্থানীয় ক্যাশিং দিয়ে এটি কিছুটা কমিয়ে দিতে পারি, কিন্তু আমাদের সেটআপের রাউন্ড-রবিন প্রকৃতির কারণে এটি এখনও বোঝায় যে প্রতিটি সার্ভারে সমস্ত ডেটার একটি সম্পূর্ণ ক্যাশে থাকা দরকার, কারণ আমরা কোন সার্ভারে পেলোডটি নিশ্চিত করতে পারিনি। শেষ হবে আমরা বুঝতে পেরেছি যে ডেটা বৃদ্ধির সাথে আমরা এই সেটআপটি অনুভব করছিলাম ভবিষ্যতে অসম্ভব হয়ে উঠবে৷
কাফকাতে প্রবেশ করুন
ডেটা প্রসেসিং পাইপলাইন হিসাবে কাফকা ব্যবহার করার বিষয়ে আমরা স্থির হয়েছি ডেটা পরিচালনা করার আরও ভাল উপায়ের সন্ধানে। ডাটাবেসে মেট্রিক্স একত্রিত করার পরিবর্তে, আমরা এখন কাফকা প্রসেসরে মেট্রিকগুলিকে একত্রিত করি . আমাদের লক্ষ্য হল আমাদের কাফকা পাইপলাইন কখনই ডাটাবেসকে জিজ্ঞাসা করবে না যতক্ষণ না সমষ্টিগত ডেটা ফ্লাশ করা হয়। এটি প্রতি পেলোডের কোয়েরির পরিমাণকে দশটি রিড থেকে কমিয়ে দেয় এবং পাইপলাইনের শেষে মাত্র একটি লেখায় লেখে।
আমরা প্রতিটি কাফকা বার্তার জন্য একটি কী নির্দিষ্ট করি এবং কাফকা গ্যারান্টি দেয় যে একই কীগুলি একই পার্টিশনে শেষ হবে, যা একই সার্ভার দ্বারা গ্রাস করা হবে। আমরা বার্তাগুলির জন্য একটি কী হিসাবে অ্যাপের আইডি ব্যবহার করি, এর অর্থ হল সার্ভারে সমস্ত গ্রাহকদের জন্য একটি ক্যাশে রাখার পরিবর্তে, আমাদের শুধুমাত্র কাফকা থেকে সার্ভার প্রাপ্ত অ্যাপগুলির জন্য ডেটা ক্যাশে করতে হবে, সমস্ত অ্যাপ নয়৷
কাফকা একটি দুর্দান্ত সিস্টেম এবং আমরা গত দুই বছরে স্থানান্তরিত হয়েছি। এই মুহুর্তে প্রায় সমস্ত প্রক্রিয়াকরণ কাফকার মাধ্যমে মরিচায় করা হয়, তবে এখনও কিছু জিনিস রয়েছে যা রুবিতে সহজে করা যায়, যেমন বিজ্ঞপ্তি পাঠানো এবং অন্যান্য ডাটাবেস-ভারী কাজ। এর মানে হল যে কাফকা থেকে আমাদের রেল স্ট্যাকে ডেটা পেতে আমাদের কিছু উপায় দরকার।
কাফকা এবং রুবি/রেল সংযোগ করা হচ্ছে
যখন আমরা এই রূপান্তর শুরু করি তখন সেখানে কয়েকটি কাফকা রুবি রত্ন ছিল, কিন্তু কোনটিই কাফকার সর্বশেষ (0.10.x সময়ে) প্রকাশের সাথে কাজ করেনি এবং বেশিরভাগই অপরিবর্তিত ছিল৷
আমরা আমাদের নিজস্ব রত্ন লেখার দিকে তাকিয়েছিলাম (যা আমরা শেষ পর্যন্ত করেছি)। আমরা একটি ভিন্ন নিবন্ধে এটি সম্পর্কে আরও লিখব. কিন্তু একটি সুন্দর ড্রাইভার থাকা শুধুমাত্র প্রয়োজনীয়তার অংশ। আমাদের ডেটা ব্যবহার করার জন্য এবং রুবিতে কাজগুলি চালানোর জন্য এবং পুরানোগুলি ক্র্যাশ হলে নতুন কর্মীদের জন্ম দেওয়ার জন্য একটি সিস্টেমের প্রয়োজন ছিল৷
অবশেষে আমরা একটি ভিন্ন সমাধান নিয়ে এসেছি। আমাদের কাফকা স্ট্যাক রাস্টে তৈরি করা হয়েছে এবং আমরা একটি ছোট বাইনারি লিখেছি যা একটি sidekiq_out ব্যবহার করে বিষয় এবং Redis এ Sidekiq সামঞ্জস্যপূর্ণ চাকরি তৈরি করে। এইভাবে আমরা এই বাইনারিটি আমাদের কর্মী মেশিনে স্থাপন করতে পারি এবং এটি Sidekiq-এ নতুন কাজ যোগাবে ঠিক যেমন আপনি নিজেই রেলের মধ্যে করবেন।
বাইনারিতে কয়েকটি বিকল্প রয়েছে যেমন রেডিসে ডেটার পরিমাণ সীমিত করে কাফকা বিষয়ের থ্রেশহোল্ড পরিষ্কার না হওয়া পর্যন্ত ব্যবহার করা বন্ধ করা। এইভাবে কাফকার সমস্ত ডেটা রেডিসের মেমোরিতে কর্মীদের উপর শেষ হবে না যদি কোনও ব্যাকলগ থাকে৷
রুবির দৃষ্টিকোণ থেকে, রেলে উৎপন্ন চাকরি এবং কাফকা থেকে আসা চাকরির মধ্যে কোনো পার্থক্য নেই। এটি আমাদের নতুন কর্মীদের প্রোটোটাইপ করার অনুমতি দেয় যারা কাফকা থেকে ডেটা পায় এবং রেলে এটি প্রক্রিয়া করে – বিজ্ঞপ্তি পাঠাতে এবং ডাটাবেস আপডেট করতে – কাফকা সম্পর্কে কিছু না জেনেই।
এটি কাফকাতে স্থানান্তরকে সহজ করে তুলেছে কারণ আমরা নতুন রুবি কোড স্থাপন না করেই কাফকাতে এবং ফিরে যেতে পারি। এটি পরীক্ষাকে অত্যন্ত সহজ করে তুলেছে কারণ আপনি স্থানীয়ভাবে একটি সম্পূর্ণ কাফকা স্ট্যাক সেটআপ না করেই রুবি দ্বারা খাওয়ার জন্য টেস্ট স্যুটে সহজেই কাজ তৈরি করতে পারেন৷
আমরা আমাদের সমস্ত (অভ্যন্তরীণ) বার্তাগুলিকে সংজ্ঞায়িত করতে প্রোটোবাফ ব্যবহার করি, এইভাবে আমরা নিশ্চিত হতে পারি যে পরীক্ষায় উত্তীর্ণ হলে, কর্মী সঠিকভাবে কাফকা থেকে কাজগুলি প্রক্রিয়া করবে৷
শেষ পর্যন্ত এই সমাধানটি আমাদের অনেক সময় এবং শক্তি বাঁচিয়েছে এবং আমাদের রুবি দলের জন্য জীবনকে অনেক সহজ করে তুলেছে।
সুবিধা ও অসুবিধা
সবকিছুর মতো এই সেটআপের জন্য কিছু সুবিধা এবং অসুবিধা রয়েছে:
সুবিধা:
- রুবিতে কোন পরিবর্তনের প্রয়োজন নেই, API সামঞ্জস্যপূর্ণ
- স্থাপন করা এবং প্রত্যাবর্তন করা সহজ
- কাফকা এবং রুবির মধ্যে পরিবর্তন করা সহজ
- লিমিটার ব্যবহার করার সময় রেডিস বার্তাগুলির দ্বারা ওভারলোড হয় না, সার্ভারে মেমরি সংরক্ষণ করে, পরিবর্তে বার্তাগুলিকে কাফকাতে রাখে৷
- অনুভূমিক স্কেলিং প্রতিটি সার্ভারে ছোট ক্যাশে নিয়ে যায়, কারণ কীযুক্ত বার্তাগুলি৷
কনস:
- এখনও সমস্যা রয়েছে যে প্রতিটি Sidekiq থ্রেডের সার্ভার ব্যবহার করা পার্টিশনগুলি থেকে অ্যাপগুলির জন্য সমস্ত ডেটার ক্যাশে অ্যাক্সেসের প্রয়োজন৷ (যেমন মেমক্যাশে)।
- সার্ভারে আলাদা প্রক্রিয়া চলছে
- মরিচা প্রসেসর যখন বার্তাটি রেডিস-এ ফ্লাশ করা হয় তখন বার্তাটি অফসেট করে, এর মানে হল যে এটি রেডিস-এ থাকার নিশ্চয়তা, কিন্তু রুবি দ্বারা বার্তাটি প্রক্রিয়াকরণের কোনও নিশ্চয়তা নেই, এর মানে হল সার্ভার ক্র্যাশের ক্ষেত্রে, সেখানে রেডিস-এ থাকা কিছু বার্তা, কিন্তু প্রসেস করা হয়নি এমন একটি সুযোগ।
সিডেকিক এবং কাফকা
আমাদের প্রসেসিং পাইপলাইন কাফকাতে স্থানান্তরিত করার সময় Sidekiq ব্যবহার করা আমাদের দারুণভাবে সাহায্য করেছে। আমরা এখন প্রায় সম্পূর্ণভাবে Sidekiq থেকে দূরে সরে গেছি এবং সরাসরি আমাদের কাফকা ড্রাইভারের মাধ্যমে সবকিছু পরিচালনা করছি, কিন্তু এটি অন্য নিবন্ধের জন্য।
এই সুখী সমাপ্তি প্রেমের গল্পকে গুটিয়ে দেয়। আমরা আশা করি আপনি পারফরম্যান্স এবং স্কেলিং এবং AppSignal স্কেলিং করার আমাদের অভিজ্ঞতার এই দৃষ্টিকোণটি উপভোগ করেছেন। আমরা আশা করি যে আমাদের স্ট্যাকের চারপাশে আমরা যে সিদ্ধান্তগুলি নিয়েছি তার উপর এই গল্পটি আপনাকে সাহায্য করবে৷
আমাদের কাফকা সেটআপ সম্বন্ধে পরবর্তী পর্ব কখন প্রকাশিত হবে সেদিকে নজর রাখতে বাকি ব্লগটি দেখুন বা আমাদের অনুসরণ করুন৷ এবং যদি আপনি একটি সর্ব-ইন-ওয়ান APM খুঁজছেন যা সত্যিই ডেভেলপারদের জন্য ডেভেলপারদের দ্বারা, তাহলে আমাদের খুঁজুন।
