Web HighLoad - របៀបដែលយើងគ្រប់គ្រងចរាចរណ៍សម្រាប់ដែនរាប់ម៉ឺន

ចរាចរណ៍ស្របច្បាប់នៅលើបណ្តាញ DDoS-Guard ថ្មីៗនេះបានលើសពីមួយរយជីហ្គាបៃក្នុងមួយវិនាទី។ បច្ចុប្បន្ននេះ 50% នៃចរាចរណ៍របស់យើងទាំងអស់ត្រូវបានបង្កើតឡើងដោយសេវាកម្មគេហទំព័ររបស់អតិថិជន។ ទាំងនេះគឺជាដែនជាច្រើនម៉ឺន ដែលខុសគ្នាខ្លាំង ហើយក្នុងករណីភាគច្រើនទាមទារវិធីសាស្រ្តបុគ្គល។

ខាងក្រោមការកាត់នេះគឺជារបៀបដែលយើងគ្រប់គ្រងថ្នាំងខាងមុខ និងចេញវិញ្ញាបនបត្រ SSL សម្រាប់គេហទំព័ររាប់រយរាប់ពាន់។

ការរៀបចំផ្នែកខាងមុខសម្រាប់គេហទំព័រមួយ សូម្បីតែគេហទំព័រធំមួយក៏ងាយស្រួលដែរ។ យើងយក nginx ឬ haproxy ឬ lighttpd កំណត់រចនាសម្ព័ន្ធវាតាមការណែនាំ ហើយភ្លេចអំពីវា។ ប្រសិនបើ​យើង​ត្រូវ​ការ​ផ្លាស់​ប្តូរ​អ្វី​មួយ យើង​ធ្វើការ​ផ្ទុក​ឡើង​វិញ ហើយ​ភ្លេច​ម្តង​ទៀត​។

អ្វីគ្រប់យ៉ាងផ្លាស់ប្តូរនៅពេលអ្នកដំណើរការបរិមាណដ៏ធំនៃចរាចរណ៍ភ្លាមៗ វាយតម្លៃភាពស្របច្បាប់នៃសំណើ បង្ហាប់ និងឃ្លាំងសម្ងាត់មាតិកាអ្នកប្រើប្រាស់ ហើយក្នុងពេលតែមួយផ្លាស់ប្តូរប៉ារ៉ាម៉ែត្រជាច្រើនដងក្នុងមួយវិនាទី។ អ្នកប្រើប្រាស់ចង់ឃើញលទ្ធផលនៅលើថ្នាំងខាងក្រៅទាំងអស់ភ្លាមៗបន្ទាប់ពីគាត់បានផ្លាស់ប្តូរការកំណត់នៅក្នុងគណនីផ្ទាល់ខ្លួនរបស់គាត់។ អ្នក​ប្រើ​ក៏​អាច​ទាញ​យក​ដែន​រាប់​ពាន់ (និង​ពេល​ខ្លះ​រាប់​ម៉ឺន) ដែល​មាន​ប៉ារ៉ាម៉ែត្រ​ដំណើរ​ការ​ចរាចរណ៍​បុគ្គល​តាម​រយៈ API ។ ទាំងអស់នេះក៏គួរតែដំណើរការភ្លាមៗនៅអាមេរិក និងនៅអឺរ៉ុប និងនៅអាស៊ីផងដែរ - កិច្ចការនេះមិនមែនជារឿងតូចតាចបំផុតនោះទេ ដោយពិចារណាថានៅទីក្រុងមូស្គូតែម្នាក់ឯងមានថ្នាំងចម្រោះដែលដាច់ដោយឡែកពីគ្នាជាច្រើន។

ហេតុអ្វីបានជាមានថ្នាំងដែលអាចទុកចិត្តបានធំៗជាច្រើននៅជុំវិញពិភពលោក?

• គុណភាពនៃសេវាកម្មសម្រាប់ចរាចរណ៍អតិថិជន - សំណើពីសហរដ្ឋអាមេរិកចាំបាច់ត្រូវដំណើរការនៅសហរដ្ឋអាមេរិក (រួមទាំងការវាយប្រហារ ការវិភាគ និងភាពមិនប្រក្រតីផ្សេងទៀត) ហើយមិនត្រូវបានទាញទៅទីក្រុងម៉ូស្គូ ឬអឺរ៉ុបទេ បង្កើនការពន្យារពេលដំណើរការដោយមិនអាចទាយទុកជាមុនបាន។

• ចរាចរណ៍វាយប្រហារត្រូវតែត្រូវបានធ្វើមូលដ្ឋានីយកម្ម - ប្រតិបត្តិករឆ្លងកាត់អាចបន្ទាបបន្ថោកក្នុងអំឡុងពេលវាយប្រហារ ដែលបរិមាណដែលច្រើនតែលើសពី 1Tbps ។ ការដឹកជញ្ជូនការវាយប្រហារតាមតំណឆ្លងកាត់អាត្លង់ទិក ឬឆ្លងកាត់អន្តរទ្វីប មិនមែនជាគំនិតល្អទេ។ យើងមានករណីពិតប្រាកដនៅពេលដែលប្រតិបត្តិករ Tier-1 បាននិយាយថា "បរិមាណនៃការវាយប្រហារដែលអ្នកទទួលបានគឺមានគ្រោះថ្នាក់សម្រាប់យើង" ។ នោះហើយជាមូលហេតុដែលយើងទទួលយកការផ្សាយចូលជិតប្រភពរបស់ពួកគេតាមដែលអាចធ្វើទៅបាន។

• តម្រូវការតឹងរ៉ឹងសម្រាប់ការបន្តនៃសេវាកម្ម - មជ្ឈមណ្ឌលសម្អាតមិនគួរពឹងផ្អែកលើគ្នាទៅវិញទៅមក ឬលើព្រឹត្តិការណ៍ក្នុងតំបន់នៅក្នុងពិភពលោកដែលកំពុងផ្លាស់ប្តូរយ៉ាងឆាប់រហ័សរបស់យើង។ តើ​អ្នក​បាន​ដាច់​ភ្លើង​ដល់​ជាន់​ទាំង 11 នៃ MMTS-9 អស់​រយៈពេល​មួយ​សប្តាហ៍​ហើយ​ឬ​នៅ? - គ្មាន​បញ្ហា។ មិនមែនអតិថិជនតែមួយទេដែលមិនមានការតភ្ជាប់រូបវ័ន្តនៅក្នុងទីតាំងជាក់លាក់នេះនឹងរងទុក្ខ ហើយសេវាកម្មគេហទំព័រនឹងមិនរងទុក្ខក្នុងកាលៈទេសៈណាក៏ដោយ។

តើធ្វើដូចម្តេចដើម្បីគ្រប់គ្រងទាំងអស់នេះ?

ការកំណត់រចនាសម្ព័ន្ធសេវាកម្មគួរតែត្រូវបានចែកចាយទៅកាន់ថ្នាំងខាងមុខទាំងអស់ឱ្យបានលឿនតាមដែលអាចធ្វើទៅបាន (តាមឧត្ដមគតិភ្លាមៗ)។ អ្នកមិនអាចគ្រាន់តែយក និងបង្កើតការកំណត់រចនាសម្ព័ន្ធអត្ថបទឡើងវិញ និងចាប់ផ្ដើមដេមិននៅរាល់ការផ្លាស់ប្តូរនោះទេ - nginx ដូចគ្នារក្សាដំណើរការបិទ (កម្មករបិទ) ពីរបីនាទីទៀត (ឬប្រហែលជាម៉ោងប្រសិនបើមានវគ្គ websocket វែង)។

នៅពេលផ្ទុកការកំណត់រចនាសម្ព័ន្ធ nginx ឡើងវិញ រូបភាពខាងក្រោមគឺធម្មតាណាស់៖

លើការប្រើប្រាស់អង្គចងចាំ៖

កម្មករចាស់ស៊ីការចងចាំ រួមទាំងការចងចាំដែលមិនអាស្រ័យលើចំនួននៃការតភ្ជាប់ - នេះគឺជារឿងធម្មតា។ នៅពេលដែលការភ្ជាប់ម៉ាស៊ីនភ្ញៀវត្រូវបានបិទ អង្គចងចាំនេះនឹងត្រូវបានដោះលែង។

ហេតុអ្វីបានជាវាមិនមែនជាបញ្ហានៅពេលដែល nginx ទើបតែចាប់ផ្តើម? មិនមាន HTTP/2, គ្មាន WebSocket, គ្មានការភ្ជាប់បន្តរស់រានមានជីវិតដ៏ធំ។ 70% នៃចរាចរណ៍គេហទំព័ររបស់យើងគឺ HTTP/2 ដែលមានន័យថាការតភ្ជាប់យូរណាស់។

ដំណោះស្រាយគឺសាមញ្ញ - កុំប្រើ nginx កុំគ្រប់គ្រងផ្នែកខាងមុខដោយផ្អែកលើឯកសារអត្ថបទ ហើយពិតជាមិនផ្ញើការកំណត់រចនាសម្ព័ន្ធអត្ថបទដែលបានបង្ហាប់លើបណ្តាញឆ្លងកាត់។ ជាការពិតណាស់ ប៉ុស្តិ៍ត្រូវបានធានា និងបម្រុងទុក ប៉ុន្តែវាមិនធ្វើឱ្យពួកគេឆ្លងទ្វីបតិចជាងនេះទេ។

យើង​មាន server-balancer ខាងមុខ​ផ្ទាល់​របស់​យើង ដែល​ផ្នែក​ខាងក្នុង​ដែល​ខ្ញុំ​នឹង​និយាយ​ក្នុង​អត្ថបទ​បន្ទាប់។ រឿងចំបងដែលវាអាចធ្វើបានគឺអនុវត្តការផ្លាស់ប្តូរការកំណត់រាប់ពាន់ក្នុងមួយវិនាទីភ្លាមៗ ដោយមិនចាំបាច់ចាប់ផ្តើមឡើងវិញ ផ្ទុកឡើងវិញ ការកើនឡើងភ្លាមៗនៃការប្រើប្រាស់អង្គចងចាំ និងអ្វីៗទាំងអស់។ នេះគឺស្រដៀងទៅនឹង Hot Code Reload ឧទាហរណ៍នៅក្នុង Erlang ។ ទិន្នន័យត្រូវបានរក្សាទុកក្នុងមូលដ្ឋានទិន្នន័យតម្លៃកូនសោដែលចែកចាយតាមភូមិសាស្ត្រ ហើយត្រូវបានអានភ្លាមៗដោយអ្នកធ្វើសកម្មភាពខាងមុខ។ ទាំងនោះ។ អ្នកបង្ហោះវិញ្ញាបនបត្រ SSL តាមរយៈចំណុចប្រទាក់គេហទំព័រ ឬ API នៅទីក្រុងមូស្គូ ហើយក្នុងរយៈពេលពីរបីវិនាទី វានឹងរួចរាល់ដើម្បីទៅកាន់មជ្ឈមណ្ឌលសម្អាតរបស់យើងនៅ Los Angeles ។ ប្រសិនបើសង្គ្រាមលោកកើតឡើងភ្លាមៗ ហើយអ៊ីនធឺណេតបានរលាយបាត់នៅជុំវិញពិភពលោក ថ្នាំងរបស់យើងនឹងបន្តធ្វើការដោយស្វ័យភាព និងជួសជុលខួរក្បាលដែលបំបែកបានភ្លាមៗ នៅពេលដែលបណ្តាញមួយក្នុងចំណោមបណ្តាញដែលខិតខំប្រឹងប្រែង Los Angeles-Amsterdam-Moscow, Moscow-Amsterdam-Hong Kong- Los-Los អាចប្រើបាន។ Angels ឬយ៉ាងហោចណាស់មួយនៃការត្រួតលើការបម្រុងទុក GRE ។

យន្តការដូចគ្នានេះអនុញ្ញាតឱ្យយើងចេញ និងបន្តវិញ្ញាបនបត្រ Let's Encrypt ឡើងវិញភ្លាមៗ។ សាមញ្ញណាស់វាដំណើរការដូចនេះ៖

1. ដរាបណាយើងឃើញយ៉ាងហោចណាស់សំណើ HTTPS មួយសម្រាប់ដែនរបស់អតិថិជនរបស់យើងដោយគ្មានវិញ្ញាបនបត្រ (ឬជាមួយវិញ្ញាបនបត្រផុតកំណត់) ថ្នាំងខាងក្រៅដែលទទួលយកសំណើរាយការណ៍នេះទៅអាជ្ញាធរបញ្ជាក់ផ្ទៃក្នុង។

   

2. ប្រសិនបើអ្នកប្រើមិនបានហាមឃាត់ការចេញ Let's Encrypt ទេ អាជ្ញាធរបញ្ជាក់បង្កើត CSR ទទួលសញ្ញាបញ្ជាក់ពី LE ហើយផ្ញើវាទៅគ្រប់ផ្នែកតាមបណ្តាញអ៊ីនគ្រីប។ ឥឡូវនេះថ្នាំងណាមួយអាចបញ្ជាក់សំណើដែលមានសុពលភាពពី LE ។

   

3. បន្តិចទៀតនេះ យើងនឹងទទួលបានវិញ្ញាបនបត្រត្រឹមត្រូវ និងសោឯកជន ហើយផ្ញើវាទៅផ្នែកខាងមុខតាមរបៀបដូចគ្នា។ ជាថ្មីម្តងទៀតដោយមិនចាប់ផ្តើមដេមិនឡើងវិញ

   

4. 7 ថ្ងៃមុនថ្ងៃផុតកំណត់ នីតិវិធីសម្រាប់ការទទួលវិញ្ញាបនបត្រឡើងវិញត្រូវបានផ្តួចផ្តើម

ឥឡូវនេះ យើងកំពុងបង្វិលវិញ្ញាបនបត្រ 350k ក្នុងពេលវេលាជាក់ស្តែង តម្លាភាពទាំងស្រុងចំពោះអ្នកប្រើប្រាស់។

នៅក្នុងអត្ថបទខាងក្រោមនៃស៊េរី ខ្ញុំនឹងនិយាយអំពីលក្ខណៈពិសេសផ្សេងទៀតនៃដំណើរការពេលវេលាពិតប្រាកដនៃចរាចរណ៍គេហទំព័រធំ - ឧទាហរណ៍អំពីការវិភាគ RTT ដោយប្រើទិន្នន័យមិនពេញលេញ ដើម្បីបង្កើនគុណភាពនៃសេវាកម្មសម្រាប់អតិថិជនឆ្លងកាត់ និងជាទូទៅអំពីការការពារចរាចរណ៍ឆ្លងកាត់ពី ការវាយប្រហារ terabit អំពីការចែកចាយ និងការប្រមូលផ្តុំព័ត៌មានចរាចរណ៍ អំពី WAF ស្ទើរតែគ្មានដែនកំណត់ CDN និងយន្តការជាច្រើនសម្រាប់បង្កើនប្រសិទ្ធភាពការចែកចាយមាតិកា។

មានតែអ្នកប្រើប្រាស់ដែលបានចុះឈ្មោះប៉ុណ្ណោះដែលអាចចូលរួមក្នុងការស្ទង់មតិនេះ។ ចូលសូម។

តើអ្នកចង់ដឹងអ្វីមុនគេ?

• 14,3%ក្បួនដោះស្រាយសម្រាប់ការធ្វើចង្កោម និងវិភាគគុណភាពនៃចរាចរណ៍គេហទំព័រ <3

• 33,3%ផ្នែកខាងក្នុងនៃសមតុល្យ DDoS-Guard7

• 9,5%ការការពារចរាចរណ៍ L3/L4 ឆ្លងកាត់ ២

• 0,0%ការការពារគេហទំព័រនៅលើចរាចរណ៍ឆ្លងកាត់ 0

• 14,3%Web Application Firewall3

• 28,6%ការការពារប្រឆាំងនឹងការញែកនិងការចុច 6

អ្នកប្រើប្រាស់ ៨១ នាក់បានបោះឆ្នោត។ អ្នកប្រើប្រាស់ ៨ នាក់ត្រូវបានហាមឃាត់។

ប្រភព: www.habr.com