Артем Денисов ( , )
Badoo - әлемдегі ең үлкен танысу сайты. Қазіргі уақытта бізде бүкіл әлем бойынша 330 миллионға жуық тіркелген пайдаланушылар бар. Бірақ бүгінгі әңгімеміздің контекстінде әлдеқайда маңызды нәрсе - біз шамамен 3 петабайт пайдаланушы фотосуреттерін сақтаймыз. Күн сайын біздің қолданушылар шамамен 3,5 миллион жаңа фотосурет жүктейді және оқу жүктемесі шамамен Секундына 80 мың сұраныс. Бұл біздің серверіміз үшін өте көп, кейде бұл мәселеде қиындықтар туындайды.
Мен жалпы фотосуреттерді сақтайтын және жіберетін осы жүйенің дизайны туралы айтамын және мен оны әзірлеуші тұрғысынан қарастырамын. Оның қалай дамығаны туралы қысқаша ретроспективасы болады, онда мен негізгі кезеңдерді сипаттаймын, бірақ мен қазір қолданып жатқан шешімдер туралы толығырақ сөйлесемін.
Енді бастайық.
Мен айтқанымдай, бұл ретроспективалық болады және оны бір жерден бастау үшін ең көп таралған мысалды алайық.
Бізде ортақ тапсырма бар, пайдаланушы фотосуреттерін қабылдау, сақтау және жіберу керек. Бұл пішінде тапсырма жалпы, біз кез келген нәрсені пайдалана аламыз:
- заманауи бұлтты сақтау,
- қорапты шешім, оның ішінде қазір де көп;
- Біз деректер орталығында бірнеше машинаны орнатып, оларға үлкен қатты дискілерді салып, фотосуреттерді сол жерде сақтай аламыз.
Badoo тарихи түрде - қазір де, содан кейін де (ол жаңадан басталған кезде) - өз серверлерінде, біздің жеке DC-де тұрады. Сондықтан бұл нұсқа біз үшін оңтайлы болды.
Біз жай ғана бірнеше машинаны алып, оларды «фотосуреттер» деп атадық және фотосуреттерді сақтайтын кластерді алдық. Бірақ бірдеңе жетіспейтін сияқты. Мұның бәрі жұмыс істеуі үшін біз қандай фотосуреттерді қандай құрылғыда сақтайтынымызды анықтауымыз керек. Ал мұнда да Американы ашудың қажеті жоқ.
Біз пайдаланушылар туралы ақпараты бар жадымызға кейбір өрістерді қосамыз. Бұл бөлу кілті болады. Біздің жағдайда біз оны place_id деп атадық және бұл орын идентификаторы пайдаланушы фотосуреттері сақталатын орынды көрсетеді. Біз карталарды жасаймыз.
Бірінші кезеңде бұл тіпті қолмен де жасалуы мүмкін - біз мұндай пайдаланушының фотосы осындай серверге түседі деп айтамыз. Осы картаның арқасында біз әрқашан пайдаланушы фотосуретті қашан жүктеп салатынын, оны қайда сақтау керектігін білеміз және оны қайдан беру керектігін білеміз.
Бұл мүлдем тривиальды схема, бірақ оның айтарлықтай артықшылықтары бар. Біріншісі, мен айтқанымдай қарапайым, ал екіншісі, бұл тәсіл арқылы біз жай ғана жаңа көліктерді жеткізу және оларды картаға қосу арқылы көлденеңінен оңай масштабтауға болады. Басқа ештеңе істеудің қажеті жоқ.
Біраз уақыт бізде солай болды.
Бұл шамамен 2009 жыл болды. Олар көліктерді жеткізіп берді, жеткізіп берді...
Және бір сәтте біз бұл схеманың белгілі бір кемшіліктері бар екенін байқай бастадық. Қандай кемшіліктері бар?
Біріншіден, мүмкіндігі шектеулі. Біз бір физикалық серверге қалағанымызша қатты дискілерді жинай алмаймыз. Бұл уақыт өте келе және деректер жиынтығының өсуіне байланысты белгілі бір мәселеге айналды.
Ал екінші. Бұл машиналардың типтік емес конфигурациясы, өйткені мұндай машиналарды кейбір басқа кластерлерде қайта пайдалану қиын; олар өте нақты, яғни. олар өнімділікте әлсіз болуы керек, бірақ сонымен бірге үлкен қатты дискімен.
Мұның бәрі 2009 жылы болды, бірақ, негізінен, бұл талаптар бүгінгі күні де өзекті. Бізде ретроспектива бар, сондықтан 2009 жылы мұның бәрі мүлде нашар болды.
Және соңғы нүкте - бұл баға.
Ол кезде баға өте жоғары болды, сондықтан бізге балама іздеу керек болды. Анау. бізге деректер орталықтарындағы кеңістікті де, осының бәрі орналасқан физикалық серверлерді де жақсырақ пайдалану керек болды. Біздің жүйелік инженерлер үлкен зерттеуді бастады, онда олар әртүрлі нұсқаларды қарастырды. Олар сондай-ақ PolyCeph және Luster сияқты кластерленген файлдық жүйелерді қарастырды. Өнімділік проблемалары және өте қиын операция болды. Олар бас тартты. Біз қандай да бір түрде масштабтау үшін барлық деректер жиынтығын NFS арқылы әр көлікке орнатуға тырыстық. Оқу да нашар болды, біз әртүрлі жеткізушілердің әртүрлі шешімдерін қолданып көрдік.
Соңында біз сақтау аймағы деп аталатын желіні пайдалануды шештік.
Бұл үлкен көлемдегі деректерді сақтау үшін арнайы жасалған үлкен SHD дискілері. Олар соңғы оптикалық шығару машиналарына орнатылған дискілері бар сөрелер. Бұл. Бізде өте кішкентай машиналар пулы бар және бұл біздің жіберу логикасы үшін мөлдір SHD, яғни. біздің nginx немесе басқа біреу үшін осы фотосуреттерге арналған сұрауларды орындау үшін.
Бұл шешімнің айқын артықшылықтары болды. Бұл SHD. Ол фотосуреттерді сақтауға бағытталған. Бұл машиналарды қатты дискілермен жабдықтаудан гөрі арзанырақ.
Екінші плюс.
Бұл қуаттылық әлдеқайда үлкен болды, яғни. біз әлдеқайда аз көлемде әлдеқайда көп сақтауды орналастыра аламыз.
Бірақ өте тез пайда болған кемшіліктер де болды. Пайдаланушылар саны мен осы жүйеге жүктеме өскен сайын өнімділік мәселелері туындай бастады. Бұл жерде мәселе өте айқын - көптеген фотосуреттерді шағын көлемде сақтауға арналған кез келген SHD, әдетте, қарқынды оқудан зардап шегеді. Бұл кез келген бұлттық қоймаға немесе басқа нәрсеге қатысты. Енді бізде шексіз масштабталатын тамаша сақтау орны жоқ, оған кез келген нәрсені салуға болады және ол оқуға өте жақсы шыдайды. Әсіресе кездейсоқ оқулар.
Біздің фотосуреттеріміздегідей, өйткені фотосуреттер сәйкессіз сұралады және бұл олардың жұмысына айтарлықтай әсер етеді.
Тіпті бүгінгі сандарға сәйкес, егер біз жад қосылған құрылғыдағы фотосуреттер үшін 500 RPS-тен көп нәрсені алсақ, проблемалар қазірдің өзінде басталады. Бұл біз үшін өте нашар болды, өйткені пайдаланушылар саны артып келеді, жағдай нашарлайды. Мұны қандай да бір жолмен оңтайландыру керек.
Оңтайландыру үшін біз сол уақытта жүктеме профилін - жалпы не болып жатқанын, нені оңтайландыру керек екенін қарауды шештік.
Ал мұнда бәрі біздің қолымызда.
Мен бірінші слайдта айттым: бізде секундына 80 мың оқу сұрауы бар, күніне небәрі 3,5 миллион жүктеп салу. Яғни, бұл үш дәрежелі айырмашылық. Оқуды оңтайландыру керек екені анық және қалай екені іс жүзінде анық.
Тағы бір шағын нүкте бар. Қызметтің ерекшелігі мынада: адам тіркеледі, фотосуретті жүктейді, содан кейін басқа адамдарға белсенді түрде қарай бастайды, олар ұнайды және басқа адамдарға белсенді түрде көрсетіледі. Содан кейін ол жұбайын табады немесе таппайды, бұл оның қалай болатынына байланысты және біраз уақытқа қызметті пайдалануды тоқтатады. Қазіргі уақытта оны пайдаланған кезде оның фотосуреттері өте қызып кетеді - олар сұранысқа ие, көптеген адамдар оларды көреді. Мұны істеуді тоқтатқаннан кейін ол басқа адамдарға бұрынғыдай әсер етуді тез тастайды және оның фотосуреттері ешқашан сұралмайды.
Анау. Бізде өте кішкентай ыстық деректер жинағы бар. Бірақ бұл ретте оған өтініштер көп. Мұнда толық айқын шешім - кэшті қосу.
LRU бар кэш біздің барлық мәселелерімізді шешеді. Біз не істеп жатырмыз?
Біз фотокэштер деп аталатын сақтау орны бар үлкен кластердің алдына тағы бір салыстырмалы түрде кішігірім қосамыз. Бұл негізінен кэштеу проксиі.
Ол ішкі жағынан қалай жұмыс істейді? Міне, біздің пайдаланушымыз, міне, сақтау орны. Бәрі бұрынғыдай. Арасына не қосамыз?
Бұл жай ғана физикалық жергілікті дискі бар машина, ол жылдам. Бұл, мысалы, SSD-де. Және бұл дискіде жергілікті кэштің қандай да бір түрі сақталады.
Ол неге ұқсайды? Пайдаланушы фотосуретке сұраныс жібереді. NGINX оны алдымен жергілікті кэште іздейді. Олай болмаса, жай ғана біздің қоймаға proxy_pass, фотосуретті сол жерден жүктеп алып, пайдаланушыға беріңіз.
Бірақ бұл өте қарапайым және ішінде не болып жатқаны түсініксіз. Бұл осындай нәрсе жұмыс істейді.
Кэш логикалық түрде үш қабатқа бөлінген. Мен «үш қабат» десем, бұл қандай да бір күрделі жүйе бар дегенді білдірмейді. Жоқ, бұл файлдық жүйедегі шартты түрде үш каталог:
- Бұл прокси-серверден жүктеп алынған фотосуреттер өтетін буфер.
- Бұл қазіргі уақытта белсенді түрде сұралған фотосуреттерді сақтайтын ыстық кэш.
- Ал суық кэш, мұнда фотосуреттер сұраныс аз болған кезде ыстық кэштен біртіндеп шығарылады.
Бұл жұмыс істеу үшін бізге бұл кэшті қандай да бір жолмен басқару керек, ондағы фотосуреттерді қайта реттеу керек және т.б. Бұл да өте қарапайым процесс.
Nginx әрбір сұрау үшін жай ғана RAMDisk access.log файлына жазады, онда ол қазіргі уақытта қызмет еткен фотосуретке жолды (әрине, салыстырмалы жол) және қандай бөлімге қызмет еткенін көрсетеді. Анау. ол «фото 1», содан кейін буфер, ыстық кэш, суық кэш немесе прокси деп айтуы мүмкін.
Осыған байланысты біз фотосуретпен не істеу керектігін шешуіміз керек.
Бізде әрбір машинада жұмыс істейтін шағын демон бар, ол үнемі осы журналды оқиды және оның жадында белгілі бір фотосуреттерді пайдалану статистикасын сақтайды.
Ол жай ғана сонда жинайды, есептегіштерді ұстайды және мерзімді түрде келесі әрекеттерді жасайды. Ол көптеген сұраулар бар белсенді түрде сұралған фотосуреттерді қай жерде болса да, ыстық кэшке жылжытады.
Сирек сұралатын және жиі сұралатын фотосуреттер бірте-бірте ыстық кэштен суық фотосуретке шығарылады.
Кэште бос орын таусылғанда, біз жай ғана суық кэштен барлығын таңдаусыз жоя бастаймыз. Айтпақшы, бұл жақсы жұмыс істейді.
Фотосуретті буферге прокси арқылы жіберу кезінде дереу сақталуы үшін біз proxy_store директивасын қолданамыз және буфер де RAMDisk болып табылады, яғни. пайдаланушы үшін ол өте жылдам жұмыс істейді. Бұл кэштеу серверінің ішкі бөліктеріне қатысты.
Қалған сұрақ осы серверлер бойынша сұрауларды қалай таратуға болады.
Жиырма сақтау машиналары мен үш кэштеу серверінің кластері бар делік (осылай болды).
Біз қандай фотосуреттерге қандай сұраныстар бар екенін және оларды қайда қою керектігін анықтауымыз керек.
Ең көп таралған нұсқа - Round Robin. Әлде кездейсоқ жасайсыз ба?
Мұның бірқатар кемшіліктері бар екені анық, өйткені мұндай жағдайда кэшті өте тиімсіз пайдаланатын боламыз. Сұраулар кейбір кездейсоқ машиналарға түседі: мұнда ол кэштелген, бірақ келесіде ол енді жоқ. Ал егер мұның бәрі жұмыс істесе, бұл өте нашар болады. Тіпті кластердегі аздаған машиналармен.
Біз қандай да бір түрде қандай серверге қандай сұрау салу керектігін анықтауымыз керек.
Банальды жол бар. Біз URL мекенжайынан хэшті немесе URL мекенжайындағы бөлісу кілтінен хэшті аламыз және оны серверлер санына бөлеміз. Жұмыс істей ме? Will.
Анау. бізде 2% сұрау бар, мысалы, кейбір «example_url» үшін ол әрқашан «XNUMX» индексі бар серверге түседі және кэш мүмкіндігінше жақсырақ жойылады.
Бірақ мұндай схемада қайта бөлу мәселесі бар. Қайта бөлу - мен серверлер санын өзгертуді айтамын.
Біздің кэштеу кластері бұдан былай жеңе алмайды деп есептейік және біз басқа машинаны қосуды шештік.
қосайық.
Енді бәрі үшке емес, төртке бөлінеді. Осылайша, бұрын бізде болған барлық дерлік кілттер, барлық дерлік URL мекенжайлары қазір басқа серверлерде тұрады. Бүкіл кэш бір сәтке жарамсыз болды. Барлық сұраулар біздің сақтау кластерімізге түсті, ол нашарлады, қызмет сәтсіз болды және пайдаланушылар қанағаттанбады. Мен мұны істегім келмейді.
Бұл опция бізге де сәйкес келмейді.
Бұл. Біз не істеуіміз керек? Біз қандай да бір түрде кэшті тиімді пайдалануымыз керек, бір сұрауды бір серверге қайта-қайта жіберуіміз керек, бірақ қайта бөлуге төзімді болуымыз керек. Және мұндай шешім бар, бұл күрделі емес. Ол дәйекті хэштеу деп аталады.
Бұл қалай көрінеді?
Біз sharding кілтінен кейбір функцияларды аламыз және оның барлық мәндерін шеңберге таратамыз. Анау. 0 нүктесінде оның ең төменгі және ең үлкен мәндері жинақталады. Әрі қарай, біз барлық серверлерімізді бір шеңберге шамамен келесідей орналастырамыз:
Әрбір сервер бір нүктемен анықталады және оған сағат тілімен жүретін секторға сәйкесінше осы хост қызмет көрсетеді. Бізге сұраулар түскенде, біз бірден көреміз, мысалы, А сұрауы – онда хэш бар – және оған 2-сервер қызмет көрсетеді. В сұранысына – сервер 3. және т.б.
Қайта бөлу кезінде бұл жағдайда не болады?
Біз бұрынғыдай толық кэшті жарамсыз етпейміз және барлық пернелерді ауыстырмаймыз, бірақ салыстырмалы түрде айтқанда, біз қосқымыз келетін алтыншы серверіміз бос кеңістікке сәйкес келетіндей етіп әрбір секторды қысқа қашықтыққа жылжытамыз және сол жерге қосамыз.
Әрине, мұндай жағдайда кілттер де қозғалады. Бірақ олар бұрынғыға қарағанда әлдеқайда әлсіз қозғалады. Біздің алғашқы екі кілтіміз өз серверлерінде қалғанын, ал кэштеу сервері тек соңғы кілт үшін өзгергенін көреміз. Бұл өте тиімді жұмыс істейді және жаңа хосттарды біртіндеп қоссаңыз, мұнда үлкен мәселе болмайды. Сіз бірте-бірте қосасыз және қосасыз, кэш қайтадан толығанша күтіңіз және бәрі жақсы жұмыс істейді.
Жалғыз сұрақ бас тартуда қалады. Бір көлік түрі істен шықты делік.
Мысалы, машина қайта жүктелсе және бізге қандай да бір түрде сұрауларға қызмет көрсету қажет болса, біз дәл қазір бұл картаны қалпына келтіруді, кэштің бір бөлігін жарамсыз етуді және т.б. қаламас едік. Біз жай ғана әрбір сайтта бір сақтық фотосурет кэшін сақтаймыз, ол қазіргі уақытта істен шыққан кез келген құрылғыны ауыстыру ретінде әрекет етеді. Егер кенеттен серверлеріміздің бірі қолжетімсіз болып қалса, трафик сол жерге түседі. Әрине, бізде кэш жоқ, яғни. суық, бірақ кем дегенде пайдаланушы сұраулары өңделуде. Егер бұл қысқа аралық болса, біз оны толығымен тыныш сезінеміз. Жадта көбірек жүктеме бар. Егер бұл интервал ұзақ болса, онда біз қазірдің өзінде шешім қабылдай аламыз - бұл серверді картадан алып тастау немесе жою немесе оны басқасымен ауыстыру.
Бұл кэштеу жүйесі туралы. Нәтижелерді қарастырайық.
Бұл жерде күрделі ештеңе жоқ сияқты. Бірақ кэшті басқарудың бұл әдісі бізге шамамен 98% трюк жылдамдығын берді. Анау. секундына осы 80 мың сұраныстың 1600-і ғана қоймаға жетеді және бұл қалыпты жүктеме, олар оны сабырмен көтереді, бізде әрқашан резерв бар.
Біз бұл серверлерді үш DC-ге орналастырдық және үш қатысу нүктесін алдық - Прага, Майами және Гонконг.
Бұл. олар біздің мақсатты нарықтарымыздың әрқайсысында азды-көпті жергілікті жерде орналасқан.
Жақсы бонус ретінде біз бұл кэштеу проксиін алдық, онда процессор іс жүзінде жұмыс істемейді, өйткені ол мазмұнға қызмет көрсету үшін қажет емес. Онда NGINX+ Lua көмегімен біз көптеген утилитарлы логиканы іске асырдық.
Мысалы, біз webp немесе прогрессивті jpeg (бұл тиімді заманауи пішімдер) арқылы тәжірибе жасай аламыз, оның трафикке қалай әсер ететінін көру, кейбір шешімдер қабылдау, оны белгілі бір елдер үшін қосу және т.б.; динамикалық өлшемін өзгерту немесе жылдам фотосуреттерді қию.
Бұл, мысалы, сізде фотосуреттерді көрсететін мобильді қолданба болған кезде және мобильді қолданба клиенттің орталық процессорын үлкен фотосуретті сұрауға жұмсағысы келмейтін болса, содан кейін оны итеру үшін оның өлшемін белгілі бір өлшемге өзгерткісі келмейтін жағдайда жақсы қолданылады. көрініс. Біз жай ғана UPort шартты URL мекенжайында кейбір параметрлерді динамикалық түрде көрсете аламыз және фото кэш фотосуреттің өлшемін өзгертеді. Әдетте, ол дискіде физикалық түрде бар өлшемді сұрағанға мүмкіндігінше жақын таңдайды және оны белгілі бір координаттарда сатады.
Айтпақшы, біз жоғары жүктемелі жүйелерді әзірлеушілер конференциясының соңғы бес жылындағы бейнежазбаларды жалпыға қолжетімді еттік. . Көріңіз, үйреніңіз, бөлісіңіз және жазылыңыз .
Біз сонымен қатар көптеген өнім логикасын қоса аламыз. Мысалы, URL параметрлерін пайдаланып әртүрлі су белгілерін қоса аламыз, фотосуреттерді бұлдыратуға, бұлдыратуға немесе пиксельге келтіруге болады. Бұл кезде біз адамның фотосын көрсеткіміз келеді, бірақ оның бетін көрсеткіміз келмейді, бұл жақсы жұмыс істейді, бәрі осында жүзеге асырылады.
Біз не алдық? Бізде үш қатысу нүктесі, жақсы трюк жылдамдығы бар және сонымен бірге бұл машиналарда бос процессор жоқ. Ол, әрине, бұрынғыдан да маңыздырақ болды. Біз өзімізге күшті машиналарды беруіміз керек, бірақ бұл оған тұрарлық.
Бұл фотосуреттерді қайтаруға қатысты. Мұнда бәрі анық және анық. Менің ойымша, мен Американы ашпадым, кез келген дерлік CDN осылай жұмыс істейді.
Және, ең алдымен, күрделі тыңдаушыда сұрақ туындауы мүмкін: неге бәрін CDN-ге өзгертпеске? Бұл шамамен бірдей болар еді; барлық заманауи CDN мұны істей алады. Және бірқатар себептер бар.
Біріншісі - фотосуреттер.
Бұл біздің инфрақұрылымымыздың негізгі нүктелерінің бірі және біз оны мүмкіндігінше бақылауымыз керек. Егер бұл үшінші тарап жеткізушісінің қандай да бір шешімі болса және сізде оған ешқандай күшіңіз болмаса, сізде үлкен деректер жинағы болған кезде және сізде өте үлкен ағын болған кезде онымен өмір сүру өте қиын болады. пайдаланушы сұрауларының саны.
Бір мысал келтірейін. Енді, біздің инфрақұрылымымызбен, мысалы, қандай да бір ақаулар немесе жер асты соққылары кезінде, салыстырмалы түрде айтқанда, машинаға барып, сол жерде тәртіпсіздік жасай аламыз. Біз тек бізге қажет кейбір көрсеткіштер жинағын қоса аламыз, қандай да бір түрде тәжірибе жасай аламыз, оның графиктерге қалай әсер ететінін көре аламыз және т.б. Қазір осы кэштеу кластерінде көптеген статистика жиналуда. Ал біз мезгіл-мезгіл қарап, кейбір ауытқуларды зерттейміз. Егер ол CDN жағында болса, оны басқару әлдеқайда қиын болар еді. Немесе, мысалы, қандай да бір апат орын алса, біз не болғанын білеміз, онымен қалай өмір сүру керектігін және оны қалай жеңуге болатынын білеміз. Бұл бірінші тұжырым.
Екінші тұжырым да біршама тарихи, өйткені жүйе ұзақ уақыт бойы дамып келеді және әртүрлі кезеңдердегі көптеген әртүрлі бизнес талаптары болды және олар әрқашан CDN тұжырымдамасына сәйкес келе бермейді.
Ал алдыңғысынан шығатын мәселе
Себебі фото кэштерде бізде сұраныс бойынша әрқашан қосу мүмкін емес көптеген нақты логикалар бар. Кез келген CDN сіздің сұрауыңыз бойынша сізге кейбір реттелетін нәрселерді қосатыны екіталай. Мысалы, клиенттің бір нәрсені өзгерте алуын қаламасаңыз, URL мекенжайларын шифрлау. Сервердегі URL мекенжайын өзгертіп, оны шифрлап, кейбір динамикалық параметрлерді осында жібергіңіз келе ме?
Бұл қандай қорытынды жасауға мүмкіндік береді? Біздің жағдайда CDN өте жақсы балама емес.
Ал сіздің жағдайыңызда, егер сізде қандай да бір нақты бизнес талаптары болса, мен сізге көрсеткен нәрсені оңай жүзеге асыра аласыз. Және бұл ұқсас жүктеме профилімен тамаша жұмыс істейді.
Бірақ егер сізде қандай да бір жалпы шешім болса және тапсырма өте нақты болмаса, сіз CDN-ді қауіпсіз түрде ала аласыз. Немесе сіз үшін бақылаудан гөрі уақыт пен ресурстар маңыздырақ болса.
Қазіргі CDN-де мен айтқандардың барлығы дерлік бар. Плюс немесе минус кейбір мүмкіндіктерді қоспағанда.
Бұл фотосуреттерді беру туралы.
Енді ретроспективада сәл алға жылжып, сақтау туралы сөйлесейік.
2013 жыл өтіп бара жатты.
Кэштеу серверлері қосылды, өнімділік мәселелері жойылды. Барлығы жақсы. Деректер жинағы өсуде. 2013 жылғы жағдай бойынша бізде сақтау жүйесіне қосылған 80-ге жуық сервер және әрбір DC-де 40-қа жуық кэштеу серверлері болды. Бұл әрбір тұрақты токта 560 терабайт деректер, яғни. жалпы алғанда петабайтқа жуық.
Деректер жиынтығының өсуімен операциялық шығындар айтарлықтай өсе бастады. Бұл нені білдірді?
Бұл сызылған диаграммада - SAN-мен, оған қосылған машиналар мен кэштермен - көптеген сәтсіздік нүктелері бар. Егер біз бұрын серверлерді кэштеу сәтсіздігімен айналысқан болсақ, бәрі азды-көпті болжамды және түсінікті болды, бірақ сақтау жағында бәрі әлдеқайда нашар болды.
Біріншіден, Storage Area Network (SAN) өзі істен шығуы мүмкін.
Екіншіден, ол соңғы машиналарға оптика арқылы қосылады. Оптикалық карталар мен оталдыру шамдарында ақаулар болуы мүмкін.
Әрине, олардың саны SAN-дағыдай көп емес, бірақ соған қарамастан, бұл да сәтсіздік нүктелері.
Келесі - қоймаға қосылған машинаның өзі. Сондай-ақ сәтсіздікке ұшырауы мүмкін.
Жалпы, бізде үш сәтсіздік бар.
Бұдан басқа, ақаулық нүктелерінен басқа, қойманың өзіне күрделі жөндеу жұмыстары жүргізіледі.
Бұл күрделі көп компонентті жүйе және жүйелік инженерлер онымен жұмыс істеу қиынға соғуы мүмкін.
Және соңғы, ең маңызды сәт. Осы үш нүктенің кез келгенінде сәтсіздік орын алса, бізде пайдаланушы деректерін жоғалту мүмкіндігі нөлге тең емес, себебі файлдық жүйе істен шығуы мүмкін.
Біздің файлдық жүйеміз бұзылды делік. Біріншіден, оны қалпына келтіру ұзақ уақытты алады - деректердің үлкен көлемімен бір апта кетуі мүмкін. Екіншіден, соңында біз түсініксіз файлдардың жиынтығымен аяқталуымыз мүмкін, олар қандай да бір түрде пайдаланушы фотосуреттеріне біріктірілуі керек. Ал біз деректерді жоғалту қаупі бар. Тәуекел өте жоғары. Мұндай жағдайлар неғұрлым жиі орын алса және осы тізбекте проблемалар неғұрлым көп болса, соғұрлым бұл тәуекел жоғары болады.
Бұл туралы бірдеңе істеу керек еді. Біз деректердің сақтық көшірмесін жасау керек деп шештік. Бұл шын мәнінде айқын және жақсы шешім. Біз не істедік?
Біздің сервер бұрын қоймаға қосылған кезде осылай көрінді. Бұл бір негізгі бөлім, бұл оптика арқылы қашықтан сақтауға арналған қондырғыны көрсететін блоктық құрылғы.
Біз жай ғана екінші бөлімді қостық.
Біз оның жанына екінші қойманы орналастырдық (бақытымызға орай, бұл ақша тұрғысынан қымбат емес) және оны резервтік бөлім деп атадық. Ол сондай-ақ оптика арқылы қосылған және бір машинада орналасқан. Бірақ біз олардың арасындағы деректерді синхрондауымыз керек.
Мұнда біз жақын жерде асинхронды кезек жасаймыз.
Ол өте бос емес. Бізде жазбалар жеткіліксіз екенін білеміз. Кезек - бұл MySQL-де «бұл фотосуреттің сақтық көшірмесін жасау керек» сияқты жолдар жазылған жай ғана кесте. Кез келген өзгерту немесе жүктеп салу кезінде біз негізгі бөлімнен сақтық көшірмеге асинхронды немесе жай ғана фондық жұмысшының көмегімен көшіреміз.
Осылайша бізде әрқашан екі дәйекті бөлім бар. Бұл жүйенің бір бөлігі істен шықса да, біз әрқашан сақтық көшірмемен негізгі бөлімді өзгерте аламыз және бәрі жұмыс істей береді.
Бірақ осыған байланысты оқу жүктемесі айтарлықтай артады, өйткені... негізгі бөлімнен оқитын клиенттерге қосымша, өйткені олар алдымен сол жерде фотосуретті қарайды (ол жерде жаңарақ), содан кейін оны таппаған болса, сақтық көшірмеден іздейді (бірақ NGINX мұны жасайды), біздің жүйе де негізгі бөлімнен оқитын қосымша резервтік көшірме болып табылады. Бұл қиыншылық емес, бірақ мен жүктемені арттырғым келмеді, дәл солай.
Біз үшінші дискіні қостық, ол шағын SSD болып табылады және оны буфер деп атадық.
Қазір қалай жұмыс істейді.
Пайдаланушы фотосуретті буферге жүктейді, содан кейін оны екі бөлімге көшіру қажет екенін көрсететін оқиға кезекке жіберіледі. Ол көшіріледі және фотосурет буферде біраз уақыт (айталық, бір күн) тұрады, содан кейін ғана сол жерден тазартылады. Бұл пайдаланушы тәжірибесін айтарлықтай жақсартады, өйткені пайдаланушы фотосуретті жүктеп салады, әдетте, сұраулар бірден орындала бастайды немесе ол парақты өзі жаңартып, оны жаңартты. Бірақ бәрі жүктеп салуды жүзеге асыратын қолданбаға байланысты.
Немесе, мысалы, ол өзін көрсете бастаған басқа адамдар осы фотосуреттен кейін бірден сұраулар жібереді. Ол әлі кэште жоқ; бірінші сұрау өте тез орындалады. Негізінде фото кэштегідей. Баяу сақтау бұған мүлдем қатысы жоқ. Бір күннен кейін ол тазартылған кезде, ол біздің кэштеу қабатында кэштелген немесе, ең алдымен, ол енді ешкімге қажет емес. Анау. Мұнда қарапайым манипуляциялардың арқасында пайдаланушы тәжірибесі өте жақсы өсті.
Ең бастысы: біз деректерді жоғалтуды тоқтаттық.
Біз тоқтадық делік ықтимал деректерді жоғалту, өйткені біз оны шынымен жоғалтқан жоқпыз. Бірақ қауіп болды. Біз бұл шешімнің, әрине, жақсы екенін көріп отырмыз, бірақ бұл мәселені толығымен шешудің орнына, оның белгілерін тегістеуге ұқсайды. Ал кейбір мәселелер осында қалып отыр.
Біріншіден, бұл барлық техника жұмыс істейтін физикалық хост түріндегі сәтсіздік нүктесі; ол жойылған жоқ.
Екіншіден, САН-ға қатысты проблемалар әлі де бар, оларға күрделі техникалық қызмет көрсету және т.б. Бұл маңызды фактор емес еді, бірақ мен онсыз өмір сүруге тырыстым.
Ал біз үшінші нұсқаны (шын мәнінде екіншісін) – брондау нұсқасын жасадық. Ол қандай болды?
Бұл болды -
Біздің негізгі проблемаларымыз - бұл физикалық хост.
Біріншіден, біз SAN файлдарын алып тастаймыз, өйткені біз тәжірибе жасағымыз келеді, біз тек жергілікті қатты дискілерді қолданғымыз келеді.
Бұл қазірдің өзінде 2014-2015 жылдар, сол кезде дискілер мен олардың бір хосттағы сыйымдылығының жағдайы әлдеқайда жақсы болды. Неліктен байқамасқа деп шештік.
Содан кейін біз сақтық көшірме бөлімін алып, оны физикалық түрде бөлек құрылғыға тасымалдаймыз.
Осылайша, біз бұл диаграмманы аламыз. Бізде бірдей деректер жиынын сақтайтын екі көлік бар. Олар бір-бірінің сақтық көшірмесін толығымен жасайды және бірдей MySQL ішіндегі асинхронды кезек арқылы желі арқылы деректерді синхрондайды.
Неліктен бұл жақсы жұмыс істейді, өйткені бізде жазбалар аз. Анау. егер жазуды оқумен салыстыруға болатын болса, бізде желілік шығындар мен проблемалар болуы мүмкін еді. Жазу аз, көп оқу - бұл әдіс жақсы жұмыс істейді, яғни. Біз бұл екі сервер арасында фотосуреттерді сирек көшіреміз.
Бұл қалай жұмыс істейді, егер сіз егжей-тегжейлі қарастырсаңыз.
Жүктеп салу. Баланстауыш жай ғана жұбы бар кездейсоқ хосттарды таңдап, оған жүктеп салады. Сонымен бірге ол табиғи түрде денсаулығын тексереді және көліктің құлап кетпеуін қадағалайды. Анау. ол фотосуреттерді тек тірі серверге жүктейді, содан кейін асинхронды кезек арқылы оның барлығы көршісіне көшіріледі. Жүктеп салу арқылы бәрі өте қарапайым.
Тапсырма сәл қиынырақ.
Луа бізге мұнда көмектесті, өйткені NGINX ванильінде мұндай логика жасау қиын болуы мүмкін. Алдымен біз бірінші серверге сұраныс жасаймыз, фотосуреттің бар-жоғын білеміз, өйткені оны, мысалы, көршіге жүктеп салуға болады, бірақ әлі мұнда келмеді. Егер фотосурет сонда болса, бұл жақсы. Біз оны бірден клиентке береміз және оны кэштейміз.
Егер ол жоқ болса, біз көршімізге өтініш жасаймыз және оны сол жерден алуға кепілдік береміз.
Бұл. Тағы да айта аламыз: өнімділікке қатысты мәселелер болуы мүмкін, өйткені тұрақты сапарлар бар - фотосурет жүктелді, ол мұнда жоқ, біз бір сұраудың орнына екі сұрау жасап жатырмыз, бұл баяу жұмыс істеуі керек.
Біздің жағдайымызда бұл баяу жұмыс істемейді.
Біз бұл жүйеде көптеген көрсеткіштер жинаймыз және мұндай механизмнің шартты смарт жылдамдығы шамамен 95% құрайды. Анау. Бұл сақтық көшірменің кешігуі аз, сондықтан біз фотосуретті жүктеп салғаннан кейін біз оны бірінші рет қабылдаймыз және екі рет ешқайда барудың қажеті жоқ.
Сонымен, бізде шынымен керемет тағы не бар?
Бұрын бізде негізгі сақтық көшірме бөлімі болды және біз олардан дәйекті түрде оқыдық. Анау. Біз әрқашан алдымен негізгісін, содан кейін сақтық көшірмесін іздедік. Бұл бір қимыл болды.
Енді біз бірден екі құрылғыдан оқуды қолданамыз. Біз сұрауларды Round Robin көмегімен таратамыз. Жағдайлардың аз ғана пайызында біз екі өтініш жасаймыз. Бірақ жалпы алғанда, қазір бізде бұрынғыдан екі есе көп оқу қоры бар. Ал жүк жөнелту машиналарында да, тікелей сақтау машиналарында да айтарлықтай төмендеді, ол кезде бізде де болды.
Қателікке төзімділікке келетін болсақ. Шындығында, біз негізінен осы үшін күрестік. Қателікке төзімділікпен мұнда бәрі керемет болды.
Бір көлік бұзылады.
Проблема жоқ! Жүйе инженері түнде де оянбауы мүмкін, ол таңға дейін күтеді, жаман ештеңе болмайды.
Егер бұл машина істен шықса да, кезек істен шыққан болса, ешқандай проблема жоқ, журнал алдымен тірі машинада жинақталады, содан кейін ол кезекке, содан кейін келесі машинаға қосылады. біраз уақыттан кейін іске қосылады.
Техникалық қызмет көрсетумен бірдей нәрсе. Біз жай ғана машиналардың бірін өшіреміз, оны барлық бассейндерден қолмен шығарамыз, ол трафикті қабылдауды тоқтатады, біз қандай да бір техникалық қызмет көрсетеміз, біз бірдеңені өңдейміз, содан кейін оны қызметке қайтарамыз және бұл сақтық көшірме өте тез орындалады. Анау. тәулігіне бір вагонның тоқтап қалуы бірнеше минут ішінде жетеді. Бұл шынымен өте аз. Қателікке төзімділікпен, мен тағы айтамын, мұнда бәрі керемет.
Бұл резервтік схемадан қандай қорытынды жасауға болады?
Бізде қателікке төзімділік бар.
Қолдануға оңай. Машиналарда жергілікті қатты дискілер болғандықтан, онымен жұмыс істейтін инженерлер үшін бұл операциялық тұрғыдан әлдеқайда ыңғайлы.
Біз екі еселенген оқу ақысын алдық.
Бұл ақауларға төзімділікке қосымша өте жақсы бонус.
Бірақ проблемалар да бар. Енді бізде осыған байланысты кейбір мүмкіндіктердің әлдеқайда күрделі дамуы бар, өйткені жүйе ақыр соңында 100% үйлесімді болды.
Біз, айталық, қандай да бір фондық жұмыста: «Біз қазір қандай серверде жұмыс істеп жатырмыз?», «Бұл жерде шынымен қазіргі фотосурет бар ма?» Деп ойлауымыз керек. және т.б. Мұның бәрі, әрине, аяқталды және бизнес логикасын жазатын бағдарламашы үшін бұл мөлдір. Бірақ, соған қарамастан, бұл үлкен күрделі қабат пайда болды. Бірақ біз одан алған жақсылығымыз үшін бұған төтеп беруге дайынбыз.
Міне, тағы да қайшылықтар туындайды.
Мен алдымен жергілікті қатты дискілерде барлығын сақтау жаман екенін айттым. Ал енді айтамын, бізге ұнады.
Иә, шынында да, уақыт өте келе жағдай көп өзгерді, қазір бұл тәсілдің көптеген артықшылықтары бар. Біріншіден, біз әлдеқайда қарапайым операцияны аламыз.
Екіншіден, бұл өнімдірек, өйткені бізде мұндай автоматты контроллерлер немесе диск сөрелеріне қосылымдар жоқ.
Онда техниканың үлкен көлемі бар және бұл машинада рейдке жиналған бірнеше дискілер ғана.
Сонымен қатар кемшіліктері де бар.
Бұл бүгінгі бағамен SAN пайдаланудан шамамен 1,5 есе қымбат. Сондықтан біз бүкіл үлкен кластерді жергілікті қатты дискілері бар автомобильдерге батыл айналдырмауды шештік және гибридті шешімді қалдыруды шештік.
Біздің машиналарымыздың жартысы қатты дискілермен жұмыс істейді (жақсы, жартысы емес - 30 пайыз). Ал қалғандары бұрын бірінші брондау схемасы болған ескі көліктер. Біз оларды жай ғана қайта монтаждадық, өйткені бізге жаңа деректер немесе басқа ештеңе қажет болмағандықтан, біз қондырғыларды бір физикалық хосттан екіге ауыстырдық.
Ал бізде қазір үлкен оқу қоры бар және біз оны кеңейттік. Бұрын біз бір жадты бір машинаға орнататын болсақ, енді төртеуін, мысалы, бір жұпқа орнатамыз. Және ол жақсы жұмыс істейді.
Неге қол жеткізгеніміз, не үшін күрескеніміз және жетістікке жеткеніміз туралы қысқаша қорытынды жасайық.
Нәтижелері
Бізде пайдаланушылар бар - 33 миллионға дейін.
Бізде үш қатысу нүктесі бар - Прага, Майами, Гонконг.
Оларда NGINX қарапайым техникасы, оның access.log және Python демондары жұмыс істейтін, мұның бәрін өңдейтін және кэшті басқаратын жылдам жергілікті дискілері (SSD) бар автомобильдерден тұратын кэштеу қабаты бар.
Қаласаңыз, сіз өзіңіздің жобаңыздасыз, егер фотосуреттер сіз үшін біз үшін маңызды болмаса немесе әзірлеу жылдамдығы мен ресурс шығындарын салыстыру бақылауы сіз үшін басқа бағытта болса, оны қауіпсіз ауыстыруға болады. CDN-мен заманауи CDN-лер жақсы жұмыс істейді.
Одан кейін сақтау қабаты келеді, онда бізде бір-бірінің сақтық көшірмесін жасайтын жұп машиналар кластерлері бар, файлдар өзгерген сайын бірінен екіншісіне асинхронды түрде көшіріледі.
Сонымен қатар, бұл машиналардың кейбірі жергілікті қатты дискілермен жұмыс істейді.
Бұл машиналардың кейбірі SAN құрылғыларына қосылған.
Және, бір жағынан, оны пайдалану ыңғайлы және сәл өнімдірек болса, екінші жағынан, ол орналастыру тығыздығы және гигабайт бағасы бойынша ыңғайлы.
Бұл біз алған нәрсенің архитектурасына және оның қалай дамығанына қысқаша шолу.
Капитаннан тағы бірнеше кеңестер, өте қарапайым.
Біріншіден, егер сіз кенеттен фото инфрақұрылымыңыздағы барлығын тез арада жақсарту керек деп шешсеңіз, алдымен өлшеңіз, себебі ештеңені жақсарту қажет емес шығар.
Бір мысал келтірейін. Бізде чаттардағы тіркемелерден фотосуреттерді жіберетін машиналар кластері бар, схема 2009 жылдан бері жұмыс істейді және одан ешкім зардап шекпейді. Барлығы жақсы, бәріне бәрі ұнайды.
Өлшеу үшін алдымен бірнеше метрика іліп, оларға қараңыз, содан кейін сіз нені қанағаттандырмайтыныңызды және нені жақсарту керектігін шешіңіз. Мұны өлшеу үшін бізде Pinba деп аталатын керемет құрал бар.
Ол әрбір сұрау мен жауап кодтары үшін NGINX-тен өте егжей-тегжейлі статистиканы жинауға және уақытты бөлуге мүмкіндік береді - қалағаныңызша. Оның әртүрлі аналитикалық жүйелердің барлық түрлерімен байланысы бар, содан кейін оның бәрін әдемі қарауға болады.
Алдымен өлшеп, сосын жетілдірдік.
Әрі қарай. Біз кэшпен оқуды, кесіндімен жазуды оңтайландырамыз, бірақ бұл айқын мәселе.
Әрі қарай. Егер сіз жүйеңізді енді ғана құруды бастасаңыз, фотосуреттерді өзгермейтін файлдар ретінде жасау әлдеқайда жақсы. Өйткені сіз кэшті жарамсыздандырумен, логика фотоның дұрыс нұсқасын қалай табу керектігімен және т.б. мәселелердің бүкіл класын бірден жоғалтасыз.
Сіз жүз жүктеп салдыңыз делік, содан кейін оны айналдырыңыз, оны физикалық түрде басқа файл болатындай етіп жасаңыз. Анау. ойлаудың қажеті жоқ: енді мен аздап орын сақтаймын, оны сол файлға жазамын, нұсқаны өзгертемін. Бұл әрқашан жақсы жұмыс істемейді және кейінірек көптеген бас ауруларын тудырады.
Келесі нүкте. Өлшемді жылдам өзгерту туралы.
Бұрын пайдаланушылар фотосуретті жүктеп салған кезде, біз бірден барлық жағдайларға, әртүрлі клиенттерге арналған өлшемдердің тұтас жиынтығын кесіп тастадық және олардың барлығы дискіде болды. Енді біз осыдан бас тарттық.
Біз тек үш негізгі өлшемді қалдырдық: шағын, орташа және үлкен. Біз жай ғана Uport-та бізге сұралған өлшемнің артындағы барлық өлшемді азайтамыз, біз жай ғана кішірейтуді орындап, оны пайдаланушыға береміз.
Мұндағы кэштеу қабатының процессоры біз бұл өлшемдерді әр жадта үнемі жаңартып отыратынымыздан әлдеқайда арзан болып шықты. Біз жаңасын қосқымыз келеді делік, бұл бір айға созылады - кластерді жоймай, мұның бәрін ұқыпты орындайтын сценарийді барлық жерде іске қосыңыз. Анау. Егер сізде қазір таңдау мүмкіндігі болса, мүмкіндігінше аз физикалық өлшемдерді жасаған дұрыс, бірақ кем дегенде кейбір бөлу, айталық, үш болуы үшін. Қалғанының барлығын дайын модульдер арқылы жылдам өзгертуге болады. Мұның бәрі қазір өте оңай және қол жетімді.
Және қосымша асинхронды сақтық көшірме жақсы.
Біздің тәжірибеміз көрсеткендей, бұл схема өзгертілген файлдарды кешіктіріп көшірумен тамаша жұмыс істейді.
Соңғы нүкте де анық. Егер сіздің инфрақұрылымыңызда қазір мұндай проблемалар болмаса, бірақ бұзылатын нәрсе бар болса, ол сәл көбірек болған кезде міндетті түрде бұзылады. Сондықтан бұл туралы алдын ала ойластырған дұрыс және онымен проблемалар туындамайды. Менің айтқым келгені осы болды.
Байланыстар
»
»
Бұл баяндама жоғары жүктемелі жүйелерді әзірлеушілер конференциясындағы ең жақсы сөздердің бірінің стенограммасы болып табылады . HighLoad++ 2017 конференциясына бір айдан аз уақыт қалды.
Бізде қазірдің өзінде дайын , қазір кесте белсенді түрде құрылуда.
Биылғы жылы біз архитектура және масштабтау тақырыбын зерттеуді жалғастырамыз:
- / Игорь Васильев
- / Дмитрий Егоров
- / Анатолий Пласковский
- / Роман Шеховцов, Алексей Громатчиков
- / Филип Делгадо
Біз сондай-ақ осы материалдардың кейбірін жоғары жүктемелі жүйелерді әзірлеуге арналған онлайн оқыту курсында пайдаланамыз арнайы таңдалған хаттар, мақалалар, материалдар, бейнелер тізбегі болып табылады. Біздің оқулығымызда қазірдің өзінде 30-дан астам бірегей материалдар бар. Қосылыңыз!
Ақпарат көзі: www.habr.com