ওয়েব হাইলোড - আমরা কীভাবে হাজার হাজার ডোমেনের ট্রাফিক পরিচালনা করি

DDoS-গার্ড নেটওয়ার্কে বৈধ ট্র্যাফিক সম্প্রতি প্রতি সেকেন্ডে একশো গিগাবিট অতিক্রম করেছে৷ বর্তমানে, আমাদের সমস্ত ট্রাফিকের 50% ক্লায়েন্ট ওয়েব পরিষেবাগুলি দ্বারা উত্পন্ন হয়। এগুলি হাজার হাজার ডোমেন, খুব আলাদা এবং বেশিরভাগ ক্ষেত্রে একটি পৃথক পদ্ধতির প্রয়োজন।

আমরা কীভাবে সামনের নোডগুলি পরিচালনা করি এবং কয়েক হাজার সাইটের জন্য SSL শংসাপত্র ইস্যু করি তা নীচে কাটা হয়েছে৷

একটি সাইটের জন্য একটি ফ্রন্ট সেট আপ করা, এমনকি একটি খুব বড় একটি, সহজ। আমরা nginx বা haproxy বা lighttpd নিই, গাইড অনুযায়ী কনফিগার করি এবং ভুলে যাই। যদি আমাদের কিছু পরিবর্তন করতে হয়, আমরা একটি পুনরায় লোড করি এবং আবার ভুলে যাই।

যখন আপনি ফ্লাইতে প্রচুর পরিমাণে ট্র্যাফিক প্রক্রিয়া করেন, অনুরোধের বৈধতা মূল্যায়ন করেন, ব্যবহারকারীর সামগ্রী সংকুচিত করেন এবং ক্যাশে করেন এবং একই সময়ে প্রতি সেকেন্ডে কয়েকবার পরামিতি পরিবর্তন করেন। ব্যবহারকারী তার ব্যক্তিগত অ্যাকাউন্টে সেটিংস পরিবর্তন করার সাথে সাথে সমস্ত বাহ্যিক নোডগুলিতে ফলাফল দেখতে চায়। একজন ব্যবহারকারী API এর মাধ্যমে স্বতন্ত্র ট্রাফিক প্রক্রিয়াকরণ পরামিতি সহ কয়েক হাজার (এবং কখনও কখনও কয়েক হাজার) ডোমেন ডাউনলোড করতে পারেন। এই সমস্তটি আমেরিকা, এবং ইউরোপ এবং এশিয়াতে অবিলম্বে কাজ করা উচিত - কাজটি সবচেয়ে তুচ্ছ নয়, শুধুমাত্র মস্কোতেই বেশ কয়েকটি শারীরিকভাবে পৃথক পরিস্রাবণ নোড রয়েছে।

কেন বিশ্বজুড়ে অনেক বড় নির্ভরযোগ্য নোড আছে?

• ক্লায়েন্ট ট্র্যাফিকের জন্য পরিষেবার গুণমান - মার্কিন যুক্তরাষ্ট্র থেকে অনুরোধগুলিকে মার্কিন যুক্তরাষ্ট্রে প্রক্রিয়া করতে হবে (আক্রমণ, পার্সিং এবং অন্যান্য অসঙ্গতি সহ), এবং মস্কো বা ইউরোপে টানা হবে না, প্রক্রিয়াকরণের বিলম্ব অপ্রত্যাশিতভাবে বৃদ্ধি পাবে।

• আক্রমণের ট্র্যাফিক অবশ্যই স্থানীয়করণ করা উচিত - আক্রমণের সময় ট্রানজিট অপারেটররা অবনমিত হতে পারে, যার পরিমাণ প্রায়শই 1Tbps অতিক্রম করে। ট্রান্সঅ্যাটলান্টিক বা ট্রান্সাসিয়ান লিঙ্কগুলির উপর আক্রমণের ট্র্যাফিক পরিবহন করা একটি ভাল ধারণা নয়। আমাদের কাছে বাস্তব ঘটনা ছিল যখন টিয়ার-1 অপারেটররা বলেছিল: "আপনি যে আক্রমণগুলি পেয়েছেন তা আমাদের জন্য বিপজ্জনক।" এই কারণেই আমরা ইনকামিং স্ট্রীমগুলিকে যতটা সম্ভব তাদের উত্সের কাছাকাছি গ্রহণ করি৷

• পরিষেবার ধারাবাহিকতার জন্য কঠোর প্রয়োজনীয়তা - পরিচ্ছন্নতা কেন্দ্রগুলি আমাদের দ্রুত পরিবর্তিত বিশ্বে একে অপরের উপর বা স্থানীয় ইভেন্টগুলির উপর নির্ভর করা উচিত নয়। আপনি কি এক সপ্তাহের জন্য MMTS-11 এর সমস্ত 9টি তলায় বিদ্যুৎ বিচ্ছিন্ন করেছেন? - সমস্যা নেই. এই নির্দিষ্ট স্থানে কোনো শারীরিক সংযোগ নেই এমন কোনো একক ক্লায়েন্ট ক্ষতিগ্রস্ত হবে না, এবং ওয়েব পরিষেবা কোনো অবস্থাতেই ক্ষতিগ্রস্ত হবে না।

এই সব কিভাবে পরিচালনা করবেন?

পরিষেবা কনফিগারেশনগুলি যত তাড়াতাড়ি সম্ভব সমস্ত ফ্রন্ট নোডে বিতরণ করা উচিত (আদর্শভাবে তাত্ক্ষণিকভাবে)। আপনি শুধুমাত্র টেক্সট কনফিগারেশনগুলি নিতে এবং পুনর্নির্মাণ করতে পারবেন না এবং প্রতিটি পরিবর্তনে ডেমনগুলি পুনরায় বুট করতে পারবেন না - একই nginx আরও কয়েক মিনিটের জন্য (বা দীর্ঘ ওয়েবসকেট সেশন থাকলে কয়েক ঘন্টা) প্রক্রিয়াগুলি বন্ধ করে রাখে (কর্মী শাট ডাউন)।

nginx কনফিগারেশন পুনরায় লোড করার সময়, নিম্নলিখিত চিত্রটি বেশ স্বাভাবিক:

মেমরি ব্যবহারের উপর:

পুরানো কর্মীরা মেমরি খায়, মেমরি সহ যা সংযোগের সংখ্যার উপর নির্ভর করে না - এটি স্বাভাবিক। ক্লায়েন্ট সংযোগ বন্ধ হলে, এই মেমরি মুক্ত করা হবে।

কেন এই একটি সমস্যা ছিল না যখন nginx সবে শুরু হচ্ছে? কোন HTTP/2 ছিল না, কোন WebSocket ছিল না, কোন বৃহদায়তন দীর্ঘ-জীবিত সংযোগ ছিল না। আমাদের ওয়েব ট্রাফিকের 70% হল HTTP/2, যার অর্থ খুব দীর্ঘ সংযোগ।

সমাধানটি সহজ - nginx ব্যবহার করবেন না, পাঠ্য ফাইলের উপর ভিত্তি করে ফ্রন্ট পরিচালনা করবেন না এবং অবশ্যই ট্রান্সপ্যাসিফিক চ্যানেলে জিপ করা পাঠ্য কনফিগারেশন পাঠাবেন না। চ্যানেলগুলি অবশ্যই গ্যারান্টিযুক্ত এবং সংরক্ষিত, তবে এটি তাদের কম ট্রান্সকন্টিনেন্টাল করে না।

আমাদের নিজস্ব সামনের সার্ভার-ব্যালেন্সার রয়েছে, যার অভ্যন্তরীণ অংশগুলি আমি নিম্নলিখিত নিবন্ধগুলিতে আলোচনা করব। এটি যে প্রধান জিনিসটি করতে পারে তা হ'ল ফ্লাইতে প্রতি সেকেন্ডে হাজার হাজার কনফিগারেশন পরিবর্তনগুলি প্রয়োগ করা, রিস্টার্ট না করে, পুনরায় লোড করা, মেমরি খরচে আকস্মিক বৃদ্ধি এবং এই সমস্ত কিছু। এটি হট কোড রিলোডের অনুরূপ, উদাহরণস্বরূপ Erlang এ। ডেটা একটি জিও-ডিস্ট্রিবিউটেড কী-ভ্যালু ডাটাবেসে সংরক্ষণ করা হয় এবং সামনের অ্যাকচুয়েটরদের দ্বারা অবিলম্বে পড়া হয়। সেগুলো. আপনি মস্কোতে ওয়েব ইন্টারফেস বা API এর মাধ্যমে SSL শংসাপত্র আপলোড করেন এবং কয়েক সেকেন্ডের মধ্যে এটি লস অ্যাঞ্জেলেসে আমাদের পরিচ্ছন্নতা কেন্দ্রে যাওয়ার জন্য প্রস্তুত। যদি হঠাৎ একটি বিশ্বযুদ্ধ ঘটে এবং সারা বিশ্বে ইন্টারনেট অদৃশ্য হয়ে যায়, আমাদের নোডগুলি স্বায়ত্তশাসিতভাবে কাজ করতে থাকবে এবং লস অ্যাঞ্জেলেস-আমস্টারডাম-মস্কো, মস্কো-আমস্টারডাম-হংকং-এর একটি ডেডিকেটেড চ্যানেলের সাথে সাথেই বিভক্ত-মস্তিষ্ক মেরামত করতে থাকবে। লস-লস উপলব্ধ। অ্যাঞ্জেলেস বা কমপক্ষে একটি জিআরই ব্যাকআপ ওভারলে।

এই একই পদ্ধতি আমাদেরকে তাৎক্ষণিকভাবে লেটস এনক্রিপ্ট সার্টিফিকেট ইস্যু ও পুনর্নবীকরণ করতে দেয়। খুব সহজভাবে এটি এই মত কাজ করে:

1. যত তাড়াতাড়ি আমরা একটি শংসাপত্র ছাড়া আমাদের ক্লায়েন্টের ডোমেনের জন্য কমপক্ষে একটি HTTPS অনুরোধ দেখতে পাই (অথবা একটি মেয়াদোত্তীর্ণ শংসাপত্র সহ), বহিরাগত নোড যা অনুরোধটি গ্রহণ করেছে তা অভ্যন্তরীণ শংসাপত্র কর্তৃপক্ষকে রিপোর্ট করে।

   

2. ব্যবহারকারী যদি লেটস এনক্রিপ্ট ইস্যু করা নিষিদ্ধ না করে থাকে, তবে সার্টিফিকেশন কর্তৃপক্ষ একটি CSR তৈরি করে, LE থেকে একটি নিশ্চিতকরণ টোকেন পায় এবং এটি একটি এনক্রিপ্ট করা চ্যানেলের মাধ্যমে সমস্ত ফ্রন্টে পাঠায়। এখন যেকোন নোড LE থেকে একটি যাচাইকরণের অনুরোধ নিশ্চিত করতে পারে।

   

3. কিছুক্ষণের মধ্যে, আমরা সঠিক সার্টিফিকেট এবং প্রাইভেট কী পাব এবং একইভাবে ফ্রন্টে পাঠাব। আবার, ডেমনগুলি পুনরায় চালু না করে

   

4. মেয়াদ শেষ হওয়ার 7 দিন আগে, সার্টিফিকেট পুনরায় প্রাপ্তির প্রক্রিয়া শুরু হয়

এই মুহূর্তে আমরা 350k সার্টিফিকেট রিয়েল টাইমে ঘুরিয়ে দিচ্ছি, ব্যবহারকারীদের কাছে সম্পূর্ণ স্বচ্ছ৷

সিরিজের নিম্নলিখিত নিবন্ধগুলিতে, আমি বৃহৎ ওয়েব ট্র্যাফিকের রিয়েল-টাইম প্রক্রিয়াকরণের অন্যান্য বৈশিষ্ট্যগুলি সম্পর্কে কথা বলব - উদাহরণস্বরূপ, ট্রানজিট ক্লায়েন্টদের পরিষেবার মান উন্নত করতে অসম্পূর্ণ ডেটা ব্যবহার করে RTT বিশ্লেষণ করা এবং সাধারণভাবে ট্রানজিট ট্র্যাফিক সুরক্ষা সম্পর্কে টেরাবিট আক্রমণ, ট্রাফিক তথ্যের ডেলিভারি এবং একত্রীকরণ সম্পর্কে, WAF সম্পর্কে, প্রায় সীমাহীন CDN এবং বিষয়বস্তু বিতরণকে অপ্টিমাইজ করার জন্য অনেক প্রক্রিয়া।

শুধুমাত্র নিবন্ধিত ব্যবহারকারীরা জরিপে অংশগ্রহণ করতে পারবেন। সাইন ইন করুনকরুন।

আপনি প্রথমে কি জানতে চান?

• 14,3%ওয়েব ট্রাফিকের গুণমান ক্লাস্টারিং এবং বিশ্লেষণের জন্য অ্যালগরিদম <3

• 33,3%DDoS-Guard7 ব্যালেন্সারের অভ্যন্তরীণ

• 9,5%ট্রানজিট L3/L4 ট্রাফিকের সুরক্ষা2

• 0,0%ট্রানজিট ট্রাফিকের উপর ওয়েবসাইটগুলি রক্ষা করা0

• 14,3%ওয়েব অ্যাপ্লিকেশন ফায়ারওয়াল3

• 28,6%পার্সিং এবং ক্লিক করার বিরুদ্ধে সুরক্ষা 6

21 ব্যবহারকারী ভোট দিয়েছেন। 6 জন ব্যবহারকারী বিরত ছিলেন।

উত্স: www.habr.com