Мы ў Skyeng карыстаемся Amazon Redshift, у тым ліку паралельным маштабаваннем, таму артыкул Стэфана Громола, заснавальніка dotgo.com, для intermix.io, падаўся нам цікавым. Пасля перакладу — крыху нашага вопыту ад інжынера па дадзеных Даніяра Белхаджаева.
дазваляе маштабаванне шляхам дадання новых вузлоў у кластар. Неабходнасць спраўляцца з пікавай колькасцю запытаў можа прывесці да залішняга рэзервавання вузлоў (over-provisioning). Паралельнае маштабаванне (Concurrency Scaling), у адрозненне ад дадання новых вузлоў, павялічвае вылічальную магутнасць па меры неабходнасці.
Паралельнае маштабаванне Amazon Redshift дае кластарам Redshift дадатковыя магутнасці для апрацоўкі пікавага колькасці запытаў. Яно працуе шляхам перанясення запытаў на новыя "раўналежныя" кластары ў фонавым рэжыме. Запыты маршрутызуюцца на аснове канфігурацыі і кіраваў WLM.
Коштаўтварэнне для паралельнага маштабавання грунтуецца на крэдытнай мадэлі з нормай бясплатнага карыстання. Звыш нормы бясплатных крэдытаў аплата грунтуецца на часе, калі кластар паралельнага маштабавання апрацоўвае запыты.
Аўтар пратэсціраваў паралельнае маштабаванне на адным з унутраных кластараў. У гэтым пасце ён раскажа аб выніках тэсціравання і дасць парады аб тым, як пачаць працу.
Патрабаванні да кластара
Для выкарыстання паралельнага маштабавання кластар Amazon Redshift павінен адпавядаць наступным патрабаванням:
- платформа: EC2-VPC;
- Тып вузла: dc2.8xlarge, ds2.8xlarge, dc2.large ці ds2.xlarge;
- лік вузлоў: ад 2 да 32 (кластары з адным вузлом не падтрымліваюцца).
Дапушчальныя тыпы запытаў
Раўналежнае маштабаванне падыходзіць не для ўсіх тыпаў запытаў. У першай версіі яно апрацоўвае толькі запыты на чытанне, якія задавальняюць тром умовам:
- SELECT-запыты толькі для чытання (хоць плануецца больш тыпаў);
- запыт не спасылаецца на табліцу са стылем сартавання INTERLEAVED;
- запыт не выкарыстоўвае Amazon Redshift Spectrum для спасылкі на знешнія табліцы.
Для маршрутызацыі ў кластар паралельнага маштабавання запыт павінен устаць у чаргу. Акрамя таго, запыты, прыдатныя для чаргі , не будуць выконвацца ў кластарах паралельнага маштабавання.
Чэргі і SQA патрабуюць правільнай наладкі . Мы рэкамендуем спачатку аптымізаваць ваш WLM - гэта зменшыць патрэбнасць у паралельным маштабаванні. І гэта важна, таму што паралельнае маштабаванне праводзіцца бясплатна толькі на працягу пэўнай колькасці гадзін. AWS сцвярджае, што паралельнае маштабаванне будзе бясплатным для 97% кліентаў, што падводзіць нас да пытання коштаўтварэння.
Кошт паралельнага маштабавання
Для паралельнага маштабавання AWS прапануе крэдытную мадэль. Кожны актыўны кластар штогадзіны назапашвае крэдыты, да адной гадзіны бясплатных крэдытаў паралельнага маштабавання ў дзень.
Вы плаціце толькі тады, калі выкарыстанне кластараў паралельнага маштабавання перавышае суму крэдытаў, якія вы атрымалі.
Кошт разлічваецца па пасекундным тарыфе па патрабаванні для паралельнага кластара, які выкарыстоўваецца звыш бясплатнай нормы. Плата робіцца толькі за час выканання вашых запытаў, з мінімальнай аплатай за адну хвіліну, кожны раз пры актывацыі кластара паралельнага маштабавання. Пасекундны тарыф па патрабаванні вылічаецца на падставе агульных прынцыпаў цэнаўтварэння , гэта значыць залежыць ад тыпу вузла і колькасці вузлоў у вашым кластары.
Запуск паралельнага маштабавання
Паралельнае маштабаванне запускаецца для кожнай чаргі WLM. Перайдзіце ў кансоль AWS Redshift і абярыце "Workload Management" у левым меню навігацыі. Абярыце групу параметраў WLM вашага кластара ў наступным якое расчыняецца меню.
Вы ўбачыце новы слупок пад назвай "Concurrency Scaling Mode" (Рэжым паралельнага маштабавання) побач з кожнай чаргой. Па змаўчанні ўсталявана значэнне "Выключана". Націсніце "Змяніць", і вы зможаце памяняць налады для кожнай чаргі.
Канфігурацыя
Паралельнае маштабаванне працуе шляхам накіравання адпаведных запытаў у новыя выдзеленыя кластары. Новыя кластары маюць той жа памер (тып і колькасць вузлоў), што і асноўны кластар.
Колькасць кластараў, выкарыстоўваных для раўналежнага маштабавання, па змаўчанні роўна аднаму (1) з магчымасцю налады ў агульнай складанасці да дзесяці (10) кластараў.
Агульная колькасць кластараў для раўналежнага маштабавання можа быць усталявана параметрам max_concurrency_scaling_clusters. Павелічэнне значэння гэтага параметра забяспечвае дадатковыя рэзервовыя кластары.
Маніторынг
У кансолі AWS Redshift ёсць некалькі дадатковых графікаў. Дыяграма "Max Configured Concurrency Scaling Clusters" адлюстроўвае значэнне max_concurrency_scaling_clusters з цягам часу.
Колькасць кластараў актыўнага маштабавання адлюстроўваецца ў карыстацкім інтэрфейсе ў раздзеле "Concurrency Scaling Activity":
Ва ўкладцы "Запыты" ёсць слупок, які паказвае, ці выконваўся запыт у асноўным кластары або ў кластары паралельнага маштабавання:
Незалежна ад таго, ці выконваўся пэўны запыт у асноўным кластары або праз кластар паралельнага маштабавання, ён захоўваецца ў stl_query.concurrency_scaling_status.
Значэнне 1 кажа аб тым, што запыт выконваўся ў кластары раўналежнага маштабавання, а іншыя значэнні кажуць аб тым, што ён выконваўся ў асноўным кластары.
Прыклад:
Інфармацыя аб паралельным маштабаванні таксама захоўваецца ў некаторых іншых табліцах і паданнях (views), напрыклад, SVCS_CONCURRENCY_SCALING_USAGE. Акрамя таго, ёсць шэраг catalog табліц, у якіх захоўваецца інфармацыя аб паралельным маштабаванні.
Вынікі
Аўтары запусцілі паралельнае маштабаванне для адной чаргі ва ўнутраным кластары прыкладна ў 18:30:00 па Грынвічы 29.03.2019 г. Змянілі параметр max_concurrency_scaling_clusters на 3 прыкладна ў 20:30:00 29.03.2019 г.
Каб змадэляваць чаргу запытаў, і паменшылі колькасць слотаў для гэтай чаргі з 15 да 5.
Ніжэй прыведзена дыяграма дэшборда intermix.io, якая паказвае колькасць выкананых і стаялых у чарзе запытаў пасля памяншэння колькасці слотаў.
Мы бачым, што час чакання запытаў у чарзе павялічыўся, пры гэтым максімальны час склаў больш за 5 хвілін.
Вось адпаведная інфармацыя з кансолі AWS аб тым, што адбылося за гэты час:
Redshift запусціў тры (3) кластара паралельнага маштабавання ў адпаведнасці з наладай. Падобна, што гэтыя кластары былі скарыстаны не цалкам, нават не гледзячы на тое, што шматлікія запыты ў нашым кластары стаялі ў чарзе.
Графік выкарыстання карэлюе з графікам актыўнасці маштабавання:
Праз некалькі гадзін аўтары праверылі чаргу, і, здаецца, 6 запытаў выконваліся з паралельным маштабаваннем. Таксама выбарачна праверылі два запыты праз карыстацкі інтэрфейс. Не правяралі, як карыстацца гэтымі значэннямі, калі актыўныя адразу некалькі паралельных кластараў.
Высновы
Паралельнае маштабаванне можа зменшыць час знаходжання ў чарзе запытаў падчас пікавых нагрузак.
Па выніках базавага тэсту атрымалася, што сітуацыя з загрузкай запытаў часткова палепшылася. Аднак само па сабе паралельнае маштабаванне не вырашыла ўсіх праблем з паралелізмам.
Гэта звязана з абмежаваннямі па тыпах запытаў, якія могуць выкарыстоўваць раўналежнае маштабаванне. Напрыклад, у аўтараў ёсць шмат табліц з якія чаргуюцца (interleaved) ключамі сартавання, і вялікая частка нашай працоўнай нагрузкі - гэта запіс.
Хоць раўналежнае маштабаванне і не ўніверсальнае рашэнне ў наладзе WLM, у любым выпадку карыстацца гэтай функцыяй проста і зразумела.
Таму аўтар рэкамендуе выкарыстоўваць яе для вашых WLM-чэргаў. Пачніце з аднаго паралельнага кластара і адсочвайце пікавую нагрузку праз кансоль, каб вызначыць, ці цалкам выкарыстоўваюцца новыя кластары.
Па меры таго, як AWS будзе дадаваць падтрымку дадатковых тыпаў запытаў і табліц, раўналежнае маштабаванне паступова павінна станавіцца ўсё больш і больш эфектыўным.
Каментарый ад Белхаджаева Даніяра, інжынера па дадзеных Skyeng
Мы ў Skyeng таксама адразу звярнулі ўвагу на якая з'явілася магчымасць раўналежнага маштабавання.
Функцыянал вельмі прывабны, асабліва з улікам таго, што па адзнацы AWS большасці карыстачоў нават не прыйдзецца за гэта даплочваць.Так атрымалася, што ў сярэдзіне красавіка ў нас быў незвычайны шквал запытаў да кластара Redshift. У гэты перыяд мы часта звярталіся да дапамогі Concurrency Scaling, часам дадатковы кластар працаваў па 24 гадзіны ў суткі без прыпынку.
Гэта дазволіла калі не поўнасцю вырашыць праблему з чэргамі, то як мінімум зрабіць сітуацыю прымальнай.
Нашы назіранні шмат у чым супадаюць з уражаннем рабят з intermix.io.
Мы таксама заўважылі, што нягледзячы на наяўнасць запытаў, якія чакаюць у чарзе, не ўсе запыты адразу перанакіроўваліся на паралельны кластар. Мабыць гэта адбываецца з-за таго, што паралельны кластар усё ж такі патрабуе часу для старту. Як вынік, падчас кароткачасовых пікавых нагрузак у нас усё роўна ўтвараюцца невялікія чэргі, і паспяваюць спрацоўваць адпаведныя алармы.
Пазбавіўшыся ад анамальных нагрузак у красавіку, мы, як і меркаваў AWS, выйшлі ў рэжым эпізадычнага выкарыстання - у рамках бясплатнай нормы.
Адсочваць выдаткі на раўналежнае маштабаванне можна ў AWS Cost Explorer. Трэба абраць Service - Redshift, Usage Type - CS, напрыклад USW2-CS:dc2.large.Падрабязна пра кошты на рускай мове можна пачытаць
Крыніца: habr.com