আপনি যদি একটি নতুন অ্যাপ তৈরি করছেন অথবা ইতিমধ্যেই একটি উচ্চ-ট্রাফিক পরিষেবা চালাচ্ছেন, তাহলে FCM-এর মাধ্যমে কীভাবে মসৃণভাবে স্কেল করবেন সে সম্পর্কে এই নির্দেশিকার অন্তর্দৃষ্টি এবং সুপারিশগুলি থেকে আপনি উপকৃত হতে পারেন। এই ধারণা এবং অনুশীলনগুলি আপনাকে যখন প্রচুর পরিমাণে বার্তা পাঠানোর প্রয়োজন হয় তখন নেতিবাচক প্রভাব এড়াতে সাহায্য করতে পারে।
মূল শব্দ এবং ধারণা
বার্তা অনুরোধ : একটি FCM বার্তা অনুরোধ; "অনুরোধ", "বার্তা", বা "প্রশ্ন" এর সাথে বিনিময়যোগ্যভাবে ব্যবহৃত হয়।
প্রতি সেকেন্ডে অনুরোধ (RPS) : FCM-এ আগত অনুরোধের হার বর্ণনা করার জন্য একটি মেট্রিক; Queries-per-second (QPS) এর সাথে বিনিময়যোগ্যভাবে ব্যবহৃত হয়।
কোটা টোকেন, টোকেন বাকেট এবং রিফিল : FCM HTTP v1 API এর বিপরীতে বার্তা পাঠানোর সময়, প্রতিটি অনুরোধ একটি নির্দিষ্ট সময় উইন্ডোতে একটি বরাদ্দকৃত কোটা টোকেন ব্যবহার করে। " টোকেন বাকেট " নামে পরিচিত এই উইন্ডোটি সময় উইন্ডোর শেষে পূর্ণ রিফিল করে । উদাহরণস্বরূপ: HTTP v1 API প্রতিটি 1-মিনিটের টোকেন বাকেটের জন্য 600K কোটা টোকেন বরাদ্দ করে, যা প্রতিটি 1-মিনিটের উইন্ডোর শেষে পূর্ণ রিফিল করে।
সার্ভার-সাইড থ্রটলিং : যখন ট্র্যাফিক ভলিউম FCM পরিষেবার ধারণক্ষমতা অতিক্রম করে, তখন পরিবেশন ক্ষমতার বাইরের অনুরোধগুলি রেট-লিমিট ইনগ্রেস ফ্লোতে প্রত্যাখ্যান করা হয়। retry-after হেডার সহ 429 ত্রুটির প্রতিক্রিয়া ফেরত পাঠানো হতে পারে যা নির্দেশ করে যে অনুরোধটি পুনরায় চেষ্টা করার আগে আপনার একটি নির্দিষ্ট সময়কাল অপেক্ষা করা উচিত।
ক্লায়েন্ট-সাইড থ্রটলিং : যখন ক্লায়েন্টরা অনুরোধ ব্যর্থতা, উচ্চ বিলম্বিতা, অথবা 429 ত্রুটি লক্ষ্য করেন, তখন তাদের স্বেচ্ছায় বহির্গমন প্রবাহকে রেট-সীমাবদ্ধ করা উচিত যাতে যানজট আরও তীব্র না হয়।
সূচকীয় ব্যাকঅফ : ত্রুটিগুলি পুনরায় চেষ্টা করার সময়, সূচকীয়ভাবে ক্রমবর্ধমান সময় বিলম্ব যোগ করুন। উদাহরণস্বরূপ: 1s, 2s, 4s, 8s, 16s, 32s, এবং আরও অনেক কিছু।
ঝাঁকুনি : সঠিক বিরতিতে পুনরায় চেষ্টা করার অনুরোধ এড়ানো। ঝাঁকুনির মাধ্যমে, আপনি সময়ের সাথে সাথে সমানভাবে বিতরণ করার জন্য একটি এলোমেলো প্রক্রিয়ার মাধ্যমে পুনরায় চেষ্টা করার বিলম্ব পরিবর্তন করেন (উদাহরণস্বরূপ: 0.9s, 2.3s, 4.1s, 8.5s, 17.9s, 34.7s)।
পুনঃচেষ্টা পরিবর্ধন : যখন ব্যর্থ অনুরোধগুলি সূচকীয় ব্যাকঅফ/জিটারিং ছাড়াই পুনরায় চেষ্টা করা হয়, তখন প্রায়শই সেগুলি জমা হয় এবং চলমান ট্র্যাফিক লোডকে বাড়িয়ে তোলে, সম্ভাব্যভাবে "প্রসারিত" করে এবং ট্র্যাফিক যানজটের সমস্যাকে আরও বাড়িয়ে তোলে।
সমস্যা: যানজট বৃদ্ধি
FCM প্রতি সেকেন্ডে লক্ষ লক্ষ অনুরোধ (RPS) প্রক্রিয়া করে। সিস্টেমিক যানজট, ল্যাটেন্সি সমস্যা এবং বিভ্রাটের সবচেয়ে বড় কারণ হল ট্র্যাফিক স্পাইক।
স্পাইকি ট্র্যাফিক কী?
বিভিন্ন ধরণের ট্র্যাফিক স্পাইক রয়েছে।
ঘন্টাব্যাপী স্পাইক: প্রতি ঘন্টার প্রথম 30 সেকেন্ড থেকে 2 মিনিটের মধ্যে FCM দ্বিগুণেরও বেশি ট্র্যাফিক পায়। একইভাবে, কম হলেও, আধ ঘন্টা এবং ত্রৈমাসিকের সময়ও স্পাইক পরিলক্ষিত হয় (উদাহরণ: 00:15, 00:30, 00:45)
পুনঃচেষ্টা পরিবর্ধন : এক্সপোনেনশিয়াল ব্যাকঅফ ছাড়া ব্যর্থ বা সময়সীমা শেষ হয়ে যাওয়া অনুরোধগুলি পুনরায় চেষ্টা করলে বিদ্যমান ট্র্যাফিক ক্রেস্টের উপরে ট্র্যাফিকের পুনরাবৃত্তি তরঙ্গ জমা হতে পারে।
ট্র্যাফিক প্যাটার্নের আকস্মিক পরিবর্তন: ধীরে ধীরে র্যাম্প-আপের মতো মসৃণ কারণ ছাড়াই নতুন ট্র্যাফিককে FCM-এ নির্দেশ করা বা অঞ্চল জুড়ে FCM-এ ট্র্যাফিক স্থানান্তর করা স্পাইক তৈরি করতে পারে।
ফ্রন্ট-লোডিং কোটা টোকেন ব্যবহার: কোটা উইন্ডো জুড়ে সমানভাবে অনুরোধগুলি ছড়িয়ে দেওয়ার পরিবর্তে কোটা উইন্ডোর শুরুতে সমস্ত কোটা টোকেন নিঃশেষ করে দিলে অন-অফ দোলন তৈরি হবে যা লোড-ব্যালেন্স করা কঠিন এবং ব্যয়বহুল।
বিশেষ অনুষ্ঠান: ছুটির দিনে (নববর্ষের আগের দিন) অথবা ক্রীড়া ইভেন্টে ( ফিফা বিশ্বকাপ ) যানজট বেড়ে যায়।
"বক্ররেখা সমতল করে" যানজটের বৃদ্ধি প্রতিকার করুন
এই অংশে সম্ভব হলে ট্র্যাফিকের চাপ কমানোর কৌশলগুলি বর্ণনা করা হয়েছে - "বক্ররেখা সমতল করার" কৌশলগুলি।
শুধুমাত্র উপযুক্ত ব্যবহারের ক্ষেত্রে FCM ব্যবহার করুন
কিছু ক্ষেত্রে এমন কিছু ক্ষেত্রে আছে যেখানে বিজ্ঞপ্তি প্রদানের জন্য FCM ব্যবহার করা প্রয়োজন বা উপযুক্ত নয়।
উদাহরণস্বরূপ, ক্যালেন্ডার ইভেন্ট বিজ্ঞপ্তির জন্য, আপনি আপনার অ্যাপ সার্ভার থেকে পাঠানোর পরিবর্তে উপযুক্ত সময়ে একটি বিজ্ঞপ্তি প্রদর্শনের জন্য আপনার অ্যাপে একটি স্থানীয় টাস্ক শিডিউল করতে পারেন। FCM বার্তাগুলিকে ক্যালেন্ডার সিঙ্কের মধ্যে সীমাবদ্ধ করুন।
স্পাইক এড়িয়ে চলুন
একটি স্কেলিং অ্যান্টি-প্যাটার্ন হল সার্ভার-সাইড থ্রটলিং প্রয়োগ করার পরিবর্তে, সিস্টেম যত তাড়াতাড়ি সম্ভব FCM বিজ্ঞপ্তি পাঠানো। নিম্নলিখিতগুলি বিবেচনা করুন:
- আপনার সকল গ্রাহকদের কি ১ মিনিটের মধ্যে একই বিজ্ঞপ্তি পেতে হবে? উদাহরণস্বরূপ, ৫ মিনিটের ডেলিভারি সময় কি এখনও আপনার ব্যবসার চাহিদা পূরণ করবে?
- আপনার গ্রাহকদের কি অগ্রাধিকারের ভিত্তিতে ভাগ করা যেতে পারে যাতে স্পাইকগুলি মসৃণ হয়?
- আপনার বিজ্ঞপ্তিগুলি কি আগে থেকে নির্ধারণ করা যেতে পারে?
যেখানেই সম্ভব : এমন কৌশল এড়িয়ে চলুন যার ফলে আপনার FCM সেন্ড কোটা তাৎক্ষণিকভাবে শেষ হয়ে যায়, এবং আপনার টোকেন বাকেট রিফিল হওয়ার সাথে সাথেই প্যাটার্নটি পুনরাবৃত্তি করতে হয়। এই অ্যাক্সেস প্যাটার্নটি FCM এবং এর উপর নির্ভরশীল সিস্টেমগুলির জন্য লোড-ব্যালেন্সিং সমস্যা তৈরি করে। যতটা সম্ভব ধীরে ধীরে ট্র্যাফিক বাড়ান। কমপক্ষে, 60 সেকেন্ডের টাইম-উইন্ডো জুড়ে 0 থেকে সর্বোচ্চ RPS পর্যন্ত র্যাম্প করুন। উচ্চতর RPS এর জন্য লম্বা উইন্ডো পছন্দ করুন।
"ঘন্টাব্যাপী" যানজট এড়িয়ে চলুন
যেখানে সম্ভব : :00, :15, :30, এবং :45 মিনিটের প্রতিটির 2 মিনিটের মধ্যে বার্তা পাঠানো এড়িয়ে চলুন।
সার্ভার-সাইড থ্রটলিং বাস্তবায়ন করুন
FCM-এ ট্র্যাফিক প্রবাহ পর্যবেক্ষণ এবং পরিচালনা করার জন্য সার্ভার-সাইড থ্রটলিং বাস্তবায়ন করুন।
পুনরায় চেষ্টা পরিচালনা করা
যদিও FCM সর্বোচ্চ উপলব্ধ থাকার চেষ্টা করে, কখনও কখনও কিছু অনুরোধের সময়সীমা শেষ হয়ে যায় বা ব্যর্থ হয়। কারণগুলি ভিন্ন হলেও, নিম্নলিখিত সর্বোত্তম অনুশীলনগুলি যত তাড়াতাড়ি সম্ভব বার্তা সরবরাহ করার জন্য পুনরায় চেষ্টা করার আচরণকে সর্বোত্তম করে তোলে এবং যানজটের উপর প্রভাব কমিয়ে দেয়।
টাইমআউট
পুনরায় চেষ্টা করার আগে প্রেরণ অনুরোধগুলিতে কমপক্ষে ১০ সেকেন্ডের সময়সীমা নির্ধারণ করুন। FCM এর বেশিরভাগ অভ্যন্তরীণ দূরবর্তী প্রক্রিয়া কলগুলিতে ১০ সেকেন্ডের সময়সীমা ব্যবহার করা হয়।
ত্রুটি
- ৪০০, ৪০১, ৪০৩, ৪০৪ ত্রুটির জন্য: বাতিল করুন, এবং পুনরায় চেষ্টা করবেন না।
- ৪২৯টি ত্রুটির জন্য: পুনঃপ্রয়াস-পরবর্তী হেডারে সেট করা সময়কালের জন্য অপেক্ষা করার পরে পুনরায় চেষ্টা করুন। যদি পুনঃপ্রয়াস-পরবর্তী হেডার সেট না থাকে, তাহলে ডিফল্টরূপে ৬০ সেকেন্ড।
- ৫০০টি ত্রুটির জন্য: সূচকীয় ব্যাকঅফ দিয়ে পুনরায় চেষ্টা করুন।
সূচকীয় ব্যাকঅফ
পুনঃচেষ্টা পরিবর্ধন এড়াতে, পুনঃচেষ্টার অনুরোধের জন্য জিটারিং সহ এক্সপোনেনশিয়াল ব্যাক-অফ প্রয়োগ করুন। উদাহরণস্বরূপ, ফায়ারবেস অ্যাডমিন SDK, এক্সপোনেনশিয়াল ব্যাকঅফ প্রয়োগ করে।
এখানে আরও কিছু প্রস্তাবিত সেটিংস দেওয়া হল:
- ন্যূনতম ব্যবধান: FCM দিয়ে ব্যর্থ অনুরোধটি অবিলম্বে পুনরায় চেষ্টা করবেন না। ব্যর্থ অনুরোধটি পুনরায় চেষ্টা করার আগে কমপক্ষে 10 সেকেন্ড অপেক্ষা করুন।
- সর্বোচ্চ ব্যবধান: অনির্দিষ্টকালের জন্য পুনরায় চেষ্টা করার পরিবর্তে, সময়োপযোগী নয় এমন অনুরোধগুলি বাদ দেওয়ার জন্য সর্বাধিক ব্যবধান সেট করুন।
যদি কোনও অনুরোধ ক্রমাগত এক্সপোনেনশিয়াল ব্যাকঅফের সাথে পুনরায় চেষ্টা করা হয় এবং 60 মিনিট পরেও ব্যর্থ হয়, তাহলে হয় এটিকে পুনরায় চেষ্টাযোগ্য ত্রুটি হিসাবে ভুলভাবে শ্রেণীবদ্ধ করা হয়েছে, অথবা FCM একটি বিভ্রাটের সম্মুখীন হচ্ছে যেখানে পুনরায় চেষ্টা অসাবধানতাবশত পরিস্থিতিকে আরও খারাপ করে তুলতে পারে।
রোলআউট এবং রোলব্যাক পরিকল্পনা তৈরি করুন এবং ধীরে ধীরে পরিবর্তন করুন
বৃহৎ পরিসরে ট্র্যাফিক পরিবর্তন করার সময়, যেমন FCM-এ ট্র্যাফিক বৃদ্ধি করা বা অঞ্চল বা নেটওয়ার্ক জুড়ে ট্র্যাফিক স্থানান্তর করা, একটি রোলআউট/রোলব্যাক পরিকল্পনা ডিজাইন করা এবং ধীরে ধীরে পরিবর্তনগুলি বাস্তবায়ন করা আপনার ব্যবহারকারীদের, আপনার পরিষেবা এবং FCM-কে সুরক্ষিত করবে।
- একটি রোলআউট পরিকল্পনা স্টেকহোল্ডারদের প্রত্যাশার সাথে সামঞ্জস্যপূর্ণ। কিছু পরিস্থিতিতে (নীচে আলোচনা করা হয়েছে), আপনি অবাক হওয়া এড়াতে আপনার রোলআউট পরিকল্পনাটি FCM টিমের সাথে আগে থেকেই শেয়ার করতে চাইতে পারেন।
- একটি রোলব্যাক পরিকল্পনা আপনাকে আকস্মিক পরিস্থিতির হিসাব রাখতে এবং অপ্রত্যাশিত ব্যর্থতা থেকে দ্রুত এবং নিরাপদে পুনরুদ্ধারের জন্য ব্যবস্থা প্রস্তুত করতে সহায়তা করে।
- ধীরে ধীরে পরিবর্তন আনার দুটি দিক রয়েছে:
- "ধাপ-ভিত্তিক" র্যাম্প-আপ: ধাপগুলি ১% -> ৫% -> ১০% -> ২৫% -> ৫০% -> ৭৫% -> ১০০% বা তার চেয়েও সূক্ষ্ম হওয়া উচিত। ১ দিন থেকে ১ সপ্তাহের জন্য প্রতিটি ধাপে " সোক " (লোডের নিচে সিস্টেমের আচরণ পর্যবেক্ষণ করুন)। এটি আপনাকে পরবর্তী "ধাপ-আপ" এর আগে সম্ভাব্য সমস্যাগুলি সনাক্ত করতে দেয়।
- ধীরে ধীরে ট্র্যাফিক বৃদ্ধি: ট্র্যাফিক বৃদ্ধির জন্য প্রতিটি "পদক্ষেপ" নেওয়ার সময়, কমপক্ষে এক ঘন্টার মধ্যে ট্র্যাফিক মসৃণ করুন। এটি FCM-এর লোড-ব্যালেন্সিং অবকাঠামোকে আপনার নতুন ট্র্যাফিককে যথাযথভাবে স্কেল করার অনুমতি দেয় এবং হটস্পট এবং যানজটের সম্ভাবনা কমিয়ে দেয়।
বিশ্বব্যাপী ৫০০,০০০ RPS কে FCM Legacy HTTP API থেকে FCM HTTP v1 API-তে স্থানান্তর করার জন্য এখানে একটি কাল্পনিক দৃশ্যকল্প দেওয়া হল:
| সপ্তাহ | ধাপ | ধীরে ধীরে র্যাম্প-আপ কৌশল |
|---|---|---|
| 0 | ১% র্যাম্প-আপ | এক ঘন্টার মধ্যে ০ থেকে ৫,০০০ RPS থেকে FCM HTTP v1-এ মসৃণভাবে র্যাম্প-আপ করুন। |
| ১ | ৫% র্যাম্প-আপ | ২ ঘন্টার মধ্যে ৫,০০০ থেকে ২৫,০০০ RPS পর্যন্ত মসৃণভাবে র্যাম্প-আপ। |
| ২ | ১০% র্যাম্প-আপ | ২ ঘন্টার মধ্যে ২৫,০০০ থেকে ৫০,০০০ RPS পর্যন্ত সুচারুভাবে র্যাম্প-আপ |
| ৩ | ২৫% র্যাম্প-আপ | ৩ ঘন্টার মধ্যে ৫০,০০০ থেকে ১২৫,০০০ RPS পর্যন্ত র্যাম্প-আপ |
| ৪ | ৫০% র্যাম্প-আপ | ৬ ঘন্টার মধ্যে ১২৫,০০০ থেকে ২৫০,০০০ RPS পর্যন্ত র্যাম্প-আপ |
| ৫ | ৭৫% র্যাম্প-আপ | ৬ ঘন্টার মধ্যে ২৫০,০০০ থেকে ৩৭৫,০০০ RPS পর্যন্ত র্যাম্প-আপ |
| ৬ | ১০০% র্যাম্প-আপ | ৬ ঘন্টার মধ্যে ৩৭৫,০০০ থেকে ৫০০,০০০ RPS পর্যন্ত র্যাম্প-আপ |
কাল্পনিক রোলব্যাক পরিকল্পনা:
- যদি ৯৫-শতাংশ ল্যাটেন্সি ৫০০ মিলিসেকেন্ডের বেশি হয়ে যায় অথবা যেকোনো ধাপে এক ঘন্টার বেশি সময় ধরে ত্রুটি অনুপাত ১% ছাড়িয়ে যায়, তাহলে পূর্ববর্তী ধাপে ফিরে যেতে ডায়নামিক কনফিগারেশন ব্যবহার করুন।
- ল্যাটেন্সি এবং ত্রুটি অনুপাত নামমাত্র স্তরে ফিরে না আসা পর্যন্ত পূর্ববর্তী ধাপগুলিতে রোলব্যাক চালিয়ে যান।
কখন FCM-এর সাথে যোগাযোগ করবেন
নিম্নলিখিতগুলির মধ্যে কোনটি প্রযোজ্য হলে Firebase সাপোর্টের মাধ্যমে FCM-এর সাথে যোগাযোগ করুন:
- ডিফল্ট কোটা আর আপনার ব্যবহারের ক্ষেত্রে প্রযোজ্য নয়।
- আপনি ৩ মাসের মধ্যে বিশ্বব্যাপী ১০০,০০০ RPS অথবা মহাদেশীয়ভাবে ৩০,০০০ RPS স্কেলে আপনার পাঠানোর ধরণ পরিবর্তন করছেন।