আপনি নতুন অ্যাপ তৈরি করছেন বা আগে থেকেই হাই-ট্রাফিক পরিষেবা চালাচ্ছেন, FCM-এর মাধ্যমে কীভাবে মসৃণভাবে স্কেল করবেন সেই বিষয়ে এই নির্দেশিকার ইনসাইট ও সাজেশন থেকে উপকৃত হতে পারবেন। আপনাকে যখন প্রচুর পরিমাণে মেসেজ পাঠাতে হয়, তখন এইসব ধারণা ও পদ্ধতি আপনাকে নেতিবাচক প্রভাব এড়াতে সাহায্য করতে পারে।
গুরুত্বপূর্ণ শব্দ ও ধারণা
মেসেজ অনুরোধ: একটি FCM মেসেজ অনুরোধ; "অনুরোধ", "মেসেজ" বা "কোয়েরি" শব্দের পরিবর্তে ব্যবহার করা হয়।
প্রতি সেকেন্ডে অনুরোধ (RPS): FCM-এ আসা অনুরোধের হার বর্ণনা করার জন্য একটি মেট্রিক; প্রতি সেকেন্ডে কোয়েরি (QPS)-এর সাথে পারস্পরিকভাবে ব্যবহার করা হয়।
কোটা টোকেন, টোকেন বাকেট ও রিফিল: FCM HTTP v1 API-এর বিরুদ্ধে মেসেজ পাঠানোর সময়, প্রতিটি অনুরোধ একটি নির্দিষ্ট সময় সীমার মধ্যে বরাদ্দ করা কোটা টোকেন ব্যবহার করে। এই উইন্ডোকে "টোকেন বাকেট" বলা হয়, এটি সময়সীমা শেষ হওয়ার আগে আবার ভরে যায়। যেমন: HTTP v1 API প্রতিটি ১-মিনিটের টোকেন বাকেটের জন্য ৬০০K কোটা টোকেন বরাদ্দ করে, যা প্রতিটি ১-মিনিটের উইন্ডোর শেষে সম্পূর্ণভাবে রিফিল হয়ে যায়।
সার্ভার-সাইড থ্রটলিং: ট্রাফিকের ভলিউম FCM পরিষেবার
ক্ষমতার বেশি হলে, ইনগ্রেস
ফ্লো রেট-লিমিট করার জন্য পরিষেবা দেওয়ার ক্ষমতার বাইরের অনুরোধ প্রত্যাখ্যান করা হয়। retry-after হেডার সহ 429 সমস্যার উত্তর ফেরত পাঠানো হতে পারে। এর মাধ্যমে বোঝানো হয় যে
অনুরোধ আবার করার আগে আপনাকে নির্দিষ্ট সময়সীমা পর্যন্ত অপেক্ষা করতে হবে।
ক্লায়েন্ট-সাইড থ্রটলিং: ক্লায়েন্টরা অনুরোধ ব্যর্থ হওয়া, বেশি লেটেন্সি,
বা 429 সমস্যা দেখতে পেলে, তাদের স্বেচ্ছায় এগ্রেস ফ্লো রেট-লিমিট করা উচিত যাতে
কনজেশন আরও খারাপ না হয়।
এক্সপোনেনশিয়াল ব্যাকঅফ: সমস্যা আবার চেষ্টা করার সময়, এক্সপোনেনশিয়ালি ক্রমবর্ধমান সময় বিলম্ব যোগ করুন। যেমন: ১ সেকেন্ড, ২ সেকেন্ড, ৪ সেকেন্ড, ৮ সেকেন্ড, ১৬ সেকেন্ড, ৩২ সেকেন্ড ইত্যাদি।
জিটারিং: নির্দিষ্ট সময় অন্তর অনুরোধ আবার করার পরিবর্তে অন্য সময় অনুরোধ করা। জিটারিংয়ের মাধ্যমে, আপনি একটি র্যান্ডম প্রসেসের মাধ্যমে আবার চেষ্টা করার বিলম্বের সময়সীমা পরিবর্তন করেন যাতে সেগুলি সময়ের সাথে সাথে সমানভাবে ডিস্ট্রিবিউট করা যায় (যেমন: ০.৯ সেকেন্ড, ২.৩ সেকেন্ড, ৪.১ সেকেন্ড, ৮.৫ সেকেন্ড, ১৭.৯ সেকেন্ড, ৩৪.৭ সেকেন্ড)।
আবার চেষ্টা করার ফলে হওয়া বৃদ্ধি: ব্যর্থ অনুরোধগুলি যখন এক্সপোনেনশিয়াল ব্যাকঅফ/জিটারিং ছাড়াই আবার চেষ্টা করা হয়, তখন সেগুলি প্রায়শই জমা হয় এবং চলমান ট্রাফিক লোডে যোগ হয়, সম্ভাব্যভাবে ট্রাফিক জ্যামের সমস্যা "বৃদ্ধি" করে এবং আরও খারাপ করে।
সমস্যা: ট্রাফিক স্পাইক
FCM প্রতি সেকেন্ডে লক্ষ লক্ষ অনুরোধ (RPS) প্রসেস করে। সিস্টেমিক কনজেশন, লেটেন্সি সংক্রান্ত সমস্যা এবং আউটএজের সবচেয়ে বড় কারণ হল ট্রাফিক স্পাইক।
স্পাইকি ট্রাফিক কী?
ট্রাফিক স্পাইকের বিভিন্ন ধরন রয়েছে।
প্রতি ঘণ্টার শুরুতে ট্রাফিকে স্পাইক: FCM প্রতি ঘণ্টার প্রথম ৩০ সেকেন্ড থেকে ২ মিনিটের মধ্যে দ্বিগুণ ট্রাফিক পায়। এছাড়াও, প্রতি আধ ঘণ্টা ও পনেরো মিনিট অন্তর একই ধরনের, তবে তুলনামূলকভাবে কম, স্পাইক দেখা গেছে (যেমন: ০০:১৫, ০০:৩০, ০০:৪৫)
আবার চেষ্টা করা: ব্যর্থ হওয়া বা টাইম-আউট হয়ে যাওয়া অনুরোধে এক্সপোনেনশিয়াল ব্যাকঅফ ব্যবহার না করলে আগে থেকে থাকা ট্রাফিক স্পাইকের উপরে ট্রাফিকের ঢেউয়ের পুনরাবৃত্তি হতে পারে।
ট্রাফিক প্যাটার্নে আকস্মিক পরিবর্তন: FCM-এ নতুন ট্রাফিক ডাইরেক্ট করা অথবা ধীরে ধীরে ট্রাফিক বাড়ানো ইত্যাদির মতো স্মুথ ফ্যাক্টর ছাড়াই বিভিন্ন অঞ্চল জুড়ে FCM-এ ট্রাফিক সরিয়ে নিয়ে যাওয়া স্পাইক তৈরি করতে পারে।
কোটা টোকেন ব্যবহারের ফ্রন্ট-লোডিং: কোটা উইন্ডোর শুরুতেই সব কোটা টোকেন শেষ করে দেওয়া হলে, কোটা উইন্ডো জুড়ে সমানভাবে অনুরোধ স্প্রেড আউট করার পরিবর্তে, অন-অফ অসিলেশন তৈরি হবে যা লোড-ব্যালেন্স করা কঠিন ও ব্যয়বহুল।
বিশেষ ইভেন্ট: ছুটির দিন (নববর্ষের আগের রাত) বা খেলাধূলার ইভেন্টে ট্রাফিক বেড়ে যাওয়া (FIFA World Cup)।
"কার্ভ ফ্ল্যাটেন" করার মাধ্যমে ট্রাফিক স্পাইক কমানো
এই বিভাগে ট্রাফিকের স্পাইক কমানোর কৌশল বর্ণনা করা হয়েছে, যেখানে সম্ভব—"কার্ভ ফ্ল্যাট করার" কৌশল।
উপযুক্ত ব্যবহারিক ক্ষেত্রের জন্য FCM ব্যবহার করুন
কিছু ব্যবহারের ক্ষেত্রে, বিজ্ঞপ্তি ডেলিভার করার জন্য FCM ব্যবহার করা প্রয়োজনীয় বা উপযুক্ত নয়।
যেমন, ক্যালেন্ডার ইভেন্ট বিজ্ঞপ্তির জন্য, আপনার অ্যাপ সার্ভার থেকে বিজ্ঞপ্তি পাঠানোর পরিবর্তে, উপযুক্ত সময়ে বিজ্ঞপ্তি দেখানোর জন্য আপনার অ্যাপে একটি লোকাল টাস্ক শিডিউল করতে পারবেন। ক্যালেন্ডার সিঙ্কের জন্য FCM মেসেজ সীমিত করুন।
স্পাইক এড়িয়ে চলুন
একটি স্কেলিং অ্যান্টি-প্যাটার্ন হল, সার্ভার-সাইড থ্রটলিং প্রয়োগ করার পরিবর্তে, সিস্টেম যত দ্রুত FCM বিজ্ঞপ্তি পাঠাতে দেবে তত দ্রুত পাঠানো। নিম্নলিখিত বিষয়গুলি বিবেচনা করুন:
- আপনার সব গ্রাহককে কি ১ মিনিটের মধ্যে একই বিজ্ঞপ্তি পাঠাতে হবে? উদাহরণস্বরূপ, ৫ মিনিটের ডেলিভারি উইন্ডো কি এখনও আপনার ব্যবসার প্রয়োজন পূরণ করতে পারবে?
- স্পাইক কমানোর জন্য অগ্রাধিকারের ভিত্তিতে আপনার গ্রাহকদের কি ভাগ করা যায়?
- আপনার বিজ্ঞপ্তি কি আগে থেকে শিডিউল করা যায়?
যেখানে সম্ভব: এমন কৌশল এড়িয়ে চলুন যার ফলে আপনার FCM পাঠানোর কোটা অবিলম্বে শেষ হয়ে যায় এবং টোকেন বাকেট রিফিল হওয়ার সাথে সাথেই সেই প্যাটার্ন আবার রিপিট হয়। এই অ্যাক্সেস প্যাটার্ন FCM ও এর উপর নির্ভরশীল সিস্টেমের জন্য লোড ব্যালেন্সিং সংক্রান্ত সমস্যা তৈরি করে। যত ধীরে ধীরে সম্ভব ট্রাফিক বাড়ান। কমপক্ষে, ৬০ সেকেন্ডের টাইম-উইন্ডো জুড়ে ০ থেকে সর্বাধিক RPS পর্যন্ত র্যাম্প করুন। বেশি RPS-এর জন্য বেশি সময়ের উইন্ডো পছন্দ করুন।
"প্রতি ঘণ্টার" ট্রাফিক এড়িয়ে যাওয়া
যেখানে সম্ভব: :০০, :১৫, :৩০ এবং :৪৫ মিনিটের চিহ্ন থেকে ২ মিনিটের মধ্যে মেসেজ পাঠানো এড়িয়ে চলুন।
সার্ভার-সাইড থ্রটলিং প্রয়োগ করা
FCM-এ ট্রাফিক ফ্লো মনিটর ও ম্যানেজ করতে সার্ভার-সাইড থ্রটলিং প্রয়োগ করুন।
আবার চেষ্টা করা ম্যানেজ করা
FCM সবসময় উপলভ্য থাকার চেষ্টা করলেও, কখনও কখনও কিছু অনুরোধের টাইম-আউট হয়ে যায় বা সেগুলি সম্পূর্ণ করা যায় না। এর কারণগুলি আলাদা আলাদা হলেও, নিম্নলিখিত পেশাদার পদ্ধতিগুলি রিট্রাই বিহেভিয়ারকে অপ্টিমাইজ করে যাতে ট্রাফিক কনজেশনের উপর প্রভাব কমানোর পাশাপাশি মেসেজ যত তাড়াতাড়ি সম্ভব ডেলিভার করা যায়।
টাইম-আউট
আবার চেষ্টা করার আগে পাঠানোর অনুরোধে কমপক্ষে ১০ সেকেন্ডের টাইমআউট সেট করুন। FCM-এর বেশিরভাগ ইন্টার্নাল রিমোট প্রসিডিওর কল ১০ সেকেন্ডের টাইমআউট ব্যবহার করে।
সমস্যা
- 400, 401, 403, 404 সমস্যার ক্ষেত্রে: বাতিল করুন এবং আবার চেষ্টা করবেন না।
- ৪২৯ সমস্যার ক্ষেত্রে: retry-after হেডারে সেট করা সময়সীমা শেষ হওয়ার পরে আবার চেষ্টা করুন। কোনও retry-after হেডার সেট করা না থাকলে, ডিফল্ট হিসেবে ৬০ সেকেন্ড সেট করা হয়।
- ৫০০ সমস্যার ক্ষেত্রে: এক্সপোনেনশিয়াল ব্যাক-অফ সহ আবার চেষ্টা করুন।
এক্সপোনেনশিয়াল ব্যাকঅফ
আবার চেষ্টা করার সংখ্যা যাতে না বাড়ে, তার জন্য অনুরোধ আবার করার সময় জিটারিং সহ এক্সপোনেনশিয়াল ব্যাক-অফ প্রয়োগ করুন। যেমন, Firebase Admin SDK এক্সপোনেনশিয়াল ব্যাকঅফ প্রয়োগ করে।
এখানে আরও কিছু সাজেস্ট করা সেটিংস দেওয়া হল:
- ন্যূনতম বিরতি: FCM-এর মাধ্যমে ব্যর্থ হওয়া অনুরোধ সঙ্গে সঙ্গে আবার পাঠাবেন না। কোনও অনুরোধ ব্যর্থ হলে আবার চেষ্টা করার আগে অন্তত ১০ সেকেন্ড অপেক্ষা করুন।
- সর্বাধিক ব্যবধান: যে অনুরোধগুলি আর সময়মতো নেই সেগুলি অনির্দিষ্টকালের জন্য আবার চেষ্টা না করে, সেগুলি বাদ দেওয়ার জন্য সর্বাধিক ব্যবধান সেট করুন।
কোনও অনুরোধ যদি এক্সপোনেনশিয়াল ব্যাকঅফ সহ ক্রমাগত আবার চেষ্টা করা হয় এবং ৬০ মিনিট পরে এখনও ব্যর্থ হয়, তাহলে এটি হয় আবার চেষ্টা করার মতো সমস্যা হিসেবে ভুলভাবে শ্রেণীবদ্ধ করা হয়েছে, অথবা FCM-এ কোনও পরিষেবা বন্ধ আছে যেখানে আবার চেষ্টা করার ফলে পরিস্থিতি আরও খারাপ হতে পারে।
রোল-আউট ও রোল-ব্যাক প্ল্যান তৈরি করা এবং ধীরে ধীরে পরিবর্তন করা
FCM-এ ট্রাফিক বাড়ানো বা বিভিন্ন অঞ্চল বা নেটওয়ার্ক জুড়ে ট্রাফিক শিফট করার মতো বড়-মাপের ট্রাফিক পরিবর্তন করার সময়, রোলআউট/রোলব্যাক প্ল্যান ডিজাইন করা এবং ধীরে ধীরে পরিবর্তন প্রয়োগ করা হলে আপনার ব্যবহারকারী, আপনার পরিষেবা এবং FCM সুরক্ষিত থাকবে।
- রোল-আউট প্ল্যান স্টেকহোল্ডারদের প্রত্যাশা পূরণ করে। কিছু নির্দিষ্ট পরিস্থিতিতে (নিচে আলোচনা করা হয়েছে), অপ্রত্যাশিত ঘটনা এড়াতে, আপনি FCM টিমের সাথে আগে থেকেই আপনার রোল-আউট প্ল্যান শেয়ার করতে চাইতে পারেন।
- রোলব্যাক প্ল্যান আপনাকে আকস্মিক ঘটনাগুলি বিবেচনা করতে এবং অপ্রত্যাশিত ব্যর্থতা থেকে দ্রুত ও নিরাপদে রিকভার করার জন্য মেকানিজম প্রস্তুত করতে সাহায্য করে।
- ধীরে ধীরে পরিবর্তন করার দুটি দিক আছে:
- "ধাপে ধাপে" র্যাম্প-আপ: ধাপগুলি ১% -> ৫% -> ১০% -> ২৫% -> ৫০% -> ৭৫% -> ১০০% বা আরও সূক্ষ্ম হতে হবে। প্রতিটি ধাপের জন্য ১ দিন থেকে ১ সপ্তাহ "সোয়াক" (লোড চলাকালীন সিস্টেমের আচরণ পর্যবেক্ষণ করা)। এর ফলে, পরবর্তী "স্টেপ-আপ" করার আগে সম্ভাব্য সমস্যাগুলি শনাক্ত করতে পারবেন
- ধীরে ধীরে ট্রাফিক বাড়ানো: ট্রাফিক বাড়ানোর জন্য প্রতিটি "ধাপ" নেওয়ার সময়, অন্তত এক ঘণ্টা ধরে ট্রাফিককে মসৃণ করুন। এর ফলে, FCM-এর লোড-ব্যালেন্সিং ইনফ্রাস্ট্রাকচার আপনার নতুন ট্রাফিককে যথাযথভাবে স্কেল করতে পারে এবং একই সাথে হটস্পট ও কনজেশন হওয়ার সম্ভাবনাও কমে যায়।
FCM লেগ্যাসি HTTP API থেকে FCM HTTP v1 API-তে বিশ্বজুড়ে ৫০০,০০০ RPS মাইগ্রেট করার একটি কাল্পনিক পরিস্থিতি এখানে দেওয়া হল:
| সপ্তাহ | ধাপ | ধীরে ধীরে বৃদ্ধি করার স্ট্র্যাটেজি |
|---|---|---|
| 0 | ১% র্যাম্প-আপ | এক ঘণ্টার মধ্যে FCM HTTP v1-এর জন্য ০ থেকে ৫,০০০ RPS পর্যন্ত ধীরে ধীরে বাড়ান। |
| 1 | ৫% র্যাম্প-আপ | ২ ঘণ্টায় ৫,০০০ থেকে ২৫,০০০ RPS পর্যন্ত ধীরে ধীরে বাড়ান। |
| 2 | ১০% র্যাম্প-আপ | ২ ঘণ্টায় ২৫,০০০ থেকে ৫০,০০০ RPS পর্যন্ত ধীরে ধীরে বাড়ানো |
| 3 | ২৫% র্যাম্প-আপ | ৩ ঘণ্টায় ৫০,০০০ থেকে ১২৫,০০০ RPS পর্যন্ত র্যাম্প-আপ |
| 4 | ৫০% র্যাম্প-আপ | ৬ ঘণ্টায় ১২৫,০০০ থেকে ২৫০,০০০ RPS পর্যন্ত র্যাম্প-আপ |
| 5 | ৭৫% র্যাম্প-আপ | ৬ ঘণ্টায় ২৫০,০০০ থেকে ৩৭৫,০০০ RPS পর্যন্ত র্যাম্প-আপ |
| 6 | ১০০% র্যাম্প-আপ | ৬ ঘণ্টায় ৩৭৫,০০০ থেকে ৫০০,০০০ RPS পর্যন্ত বৃদ্ধি |
কাল্পনিক রোলব্যাক প্ল্যান:
- ৯৫-পার্সেন্টাইল লেটেন্সি ৫০০ মিলিসেকেন্ডের বেশি হলে অথবা কোনও ধাপে এক ঘণ্টার বেশি সময় ধরে ১%-এর বেশি ত্রুটি হলে, আগের ধাপে ফিরে যেতে অবিলম্বে ডাইনামিক কনফিগারেশন ব্যবহার করুন।
- লেটেন্সি ও সমস্যার অনুপাত স্বাভাবিক লেভেলে না ফেরা পর্যন্ত আগের ধাপে রোলব্যাক করা চালিয়ে যান।
FCM-এর সাথে কখন যোগাযোগ করতে হবে
নিচে উল্লেখ করা বিষয়গুলির মধ্যে কোনওটি প্রযোজ্য হলে, Firebase সহায়তা-এর মাধ্যমে FCM-এর সাথে যোগাযোগ করুন:
- ডিফল্ট কোটা আর আপনার ব্যবহারিক ক্ষেত্রের প্রয়োজন পূরণ করতে পারছে না
- আপনি ৩ মাসের মধ্যে বিশ্বব্যাপী ১০০,০০০ RPS বা মহাদেশীয় ৩০,০০০ RPS-এর স্কেলে আপনার পাঠানোর প্যাটার্ন পরিবর্তন করছেন।