আপনি নতুন অ্যাপ তৈরি করছেন বা আগে থেকেই হাই-ট্রাফিক পরিষেবা চালাচ্ছেন, 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 হেডারে সেট করা সময়সীমা শেষ হওয়ার পরে আবার চেষ্টা করুন। আবার চেষ্টা করার জন্য কোনও হেডার সেট করা না থাকলে, ডিফল্ট হিসেবে ৬০ সেকেন্ড সেট করা হয়।
- ৫০০ নম্বর সমস্যার জন্য: এক্সপোনেনশিয়াল ব্যাক-অফ সহ আবার চেষ্টা করুন।
এক্সপোনেনশিয়াল ব্যাকঅফ
আবার চেষ্টা করার সময় যাতে সমস্যা না হয়, তাই অনুরোধের জন্য আবার চেষ্টা করার সময় জিটারিং সহ এক্সপোনেনশিয়াল ব্যাক-অফ প্রয়োগ করুন। যেমন, 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-এর স্কেলে আপনার পাঠানোর প্যাটার্ন পরিবর্তন করছেন।