Като платформа за управление на сложен и взискателен софтуерен продукт, AWS предлага гъвкавост, като използва ресурси, когато е необходимо, в необходимия мащаб. Той е при поискване и незабавен, позволяващ пълен контрол върху работещата среда. Когато предлагате такова решение за архитектура в облак на клиент, предоставената инфраструктура и нейната цена силно зависят от изискванията, които трябва да бъдат настроени отпред.

Тази статия ще представи една такава архитектура за облачна инфраструктура на AWS, предложена и внедрена за НИВА , социална мрежа с интегрирана функция за лицево плащане, която намира и прилага всички предимства, които потребителите могат да получат за картовите програми, в които се намират, нещата, които притежават или местата, в които живеят.

Изисквания

Клиентът имаше две основни изисквания, на които трябваше да отговаря предложеното решение:

1. Сигурност
2. Мащабируемост

The изискване за сигурност беше всичко за защита на данните на потребителите от неоторизиран достъп отвън, но и отвътре. The изискване за мащабируемост беше за способността на инфраструктурата да поддържа автоматично ръст на продукта адаптиране към увеличаващия се трафик и периодични скокове, както и автоматично възстановяване при откази и възстановяване в случай на откази на сървъри, минимизиране на потенциалния престой.

Преглед на концепциите за сигурност на AWS

Едно от основните предимства на настройването на вашата собствена инфраструктура на AWS Cloud е пълната мрежова изолация и пълен контрол над вашия облак. Това е основната причина, поради която бихте избрали маршрута на инфраструктурата като услуга (IaaS), вместо да изпълнявате по-опростени среди на платформата като услуга (PaaS), които предлагат солидни настройки по подразбиране, но им липсва пълният, фин контрол, който получавате настройване на собствен облак с AWS.

Въпреки че LEVELS беше млад продукт, когато се обърнаха към ApeeScape за AWS консултантски услуги , те бяха готови да се ангажират с AWS и знаеха, че искат най-съвременна сигурност със своята инфраструктура, тъй като са много загрижени за потребителските данни и поверителността. На всичкото отгоре те планират да подкрепят обработката на кредитни карти в бъдеще, така че знаеха, че ще трябва да осигурят спазването на PCI-DSS в даден момент.

Виртуален частен облак (VPC)

Сигурността на AWS започва със създаването на ваша собствена Виртуален частен облак на Amazon (VPC) - специална виртуална мрежа, която хоства вашите AWS ресурси и е логично изолирана от други виртуални мрежи в AWS Cloud. VPC получава собствен диапазон от IP адреси, напълно конфигурируеми подмрежи, маршрутни таблици, списъци за контрол на достъпа до мрежата и групи за сигурност (на практика защитна стена).

С LEVELS започнахме, изолирайки нашата производствена среда от среди за разработка, тестване и QA. Първата идея беше да се изпълни всеки от тях като свой напълно изолиран VPC, като всеки изпълнява всички услуги, както се изисква от приложението. След обмисляне се оказа, че можем да позволим споделяне на ресурси в трите непроизводствени среди, което до известна степен намали разходите.

По този начин ние се спряхме на производствената среда като един VPC, с разработка, тестване и QA среди като друг VPC.

Изолиране на достъп на ниво VPC

Настройката с два VPC изолира производствената среда от останалите три среди на мрежово ниво, като гарантира, че случайната неправилна конфигурация на приложението не може да премине тази граница. Дори ако конфигурацията на непроизводствената среда погрешно трябва да сочи към ресурси на производствената среда, като опашки от бази данни или съобщения, няма начин да получите достъп до тях.

С разработка, тестване и QA среди, споделящи една и съща VPC, трансграничен достъп е възможен в случай на неправилна конфигурация, но тъй като тези среди използват тестови данни, не съществува реална загриженост за сигурността поради липсата на изолация там.

Модел за сигурност на активите

Активите се съхраняват в Amazon Simple Storage Service (S3) съхранение на обект. Инфраструктурата за съхранение на S3 е напълно независима от VPC, а моделът й на сигурност е различен. Съхранението е организирано в отделни сегменти S3 за всяка среда и / или класове активи, като се защитава всяка група със съответните права за достъп.

С LEVELS бяха идентифицирани няколко класа активи: качвания от потребители, създадено от LEVELS съдържание (промоционални видеоклипове и подобно съдържание), активи на уеб приложения и потребителски интерфейс (JS код, икони, шрифтове), конфигурация на приложения и инфраструктура и пакети за разполагане от страна на сървъра.

Всеки от тях получава отделна кофа S3.

Управление на тайни на приложения

С AWS има криптиран AWS Systems Manager Parameter Store или AWS Secrets Manager , които са управлявани услуги ключ-стойност, предназначени да пазят тайните в безопасност (можете да научите повече на Linux Academy и 1 Стратегия ).

AWS управлява основните ключове за криптиране и обработва криптирането / декриптирането. Самите тайни могат да имат политики за разрешения за четене и запис, приложени въз основа на ключовите префикси, както за инфраструктурата, така и за потребителите (съответно сървъри и разработчици).

Сървър SSH достъп

SSH достъп до сървъри в напълно автоматизирана и неизменяема среда изобщо не трябва да е необходим. Дневниците могат да бъдат извлечени и изпратени до специализирани услуги за регистриране, мониторингът също се разтоварва до специална услуга за наблюдение. Все пак може да има нужда от случаен SSH достъп за проверка на конфигурацията и отстраняване на грешки.

За да ограничи повърхността за атака на сървърите, SSH портът не се излага на обществената мрежа. До сървърите се достига чрез бастион хост, специална машина, позволяваща външен SSH достъп, допълнително защитена чрез включване в белия списък само на разрешения IP адрес в защитната стена. Достъпът се контролира чрез разполагане на публичните SSH ключове на потребителите в съответните полета (влизанията с пароли са деактивирани). Подобна настройка предлага доста устойчива порта за преминаване от злонамерени нападатели.

Достъп до база данни

Същите принципи, описани по-горе, се прилагат за сървърите на бази данни. Също така може да има случайна необходимост от свързване и манипулиране на данните директно в базата данни, въпреки че това определено не е препоръчителна практика и такъв достъп трябва да бъде защитен по същия начин, както SSH достъпът на сървърите е защитен.

Може да се използва подобен подход, като се използва същата бастионна хост инфраструктура с SSH тунелиране. Необходим е двоен SSH тунел, един към бастионния хост, а през него още един към сървъра, имащ достъп до базата данни (бастионният хост няма достъп до сървъра на базата данни). Чрез този втори тунел вече е налична връзка от клиентската машина на потребителя към сървъра на базата данни.

Преглед на концепциите за мащабируемост на AWS

Когато говорим чисто за сървъри, мащабируемостта е доста лесно постижима с платформи, по-прости от AWS. Основният недостатък е, че някои изисквания може да се наложи да бъдат покрити от външните услуги на платформата, което означава, че данните пътуват през публичната мрежа и нарушават границите на сигурността. Придържайки се към AWS, всички данни се пазят частни, докато мащабируемостта трябва да бъде проектирана, за да се постигне мащабируема, устойчива и устойчива на грешки инфраструктура.

С AWS най-добрият подход към мащабируемостта е чрез използване на управлявани AWS услуги с мониторинг и автоматизация, тествани в битки при хиляди клиенти, използващи платформата. Добавете резервни копия на данни и механизми за възстановяване в комбинацията и ще получите много притеснения извън масата, като просто разчитате на самата платформа.

Разтоварването на всичко това позволява по-малък оперативен екип, което донякъде компенсира по-високата цена на услугите, управлявани от платформата. Екипът на LEVELS с удоволствие избра този път, където е възможно.

Amazon Elastic Compute Cloud (EC2)

Разчитайки на доказана среда, която работи EC2 екземпляри все още е доста разумен подход в сравнение с допълнителните режийни разходи и сложност на работещи контейнери или все още много младите и бързо променящи се архитектурни концепции за безсървърни изчисления.

Предоставянето на екземпляри на EC2 трябва да бъде напълно автоматизирано. Автоматизацията се постига чрез персонализирани AMI за различни класове сървъри и групи за автоматично мащабиране, които се грижат за изпълнението на динамични сървърни паркове, като поддържат подходящия брой екземпляри на работещи сървъри във флота според текущия трафик.

Освен това, функцията за автоматично мащабиране позволява задаване на долната и горната граница в броя на изпълняваните екземпляри EC2. Долната граница помага за толерантност към грешки, като потенциално елиминира престоя в случай на повреди. Горната граница държи разходите под контрол, позволявайки известен риск от престой в случай на неочаквани екстремни условия. След това автоматичното мащабиране динамично мащабира броя на екземплярите в рамките на тези граници.

Услуга за релационна база данни на Amazon (RDS)

Екипът вече работи Amazon RDS за MySQL , но подходящото архивиране, толерантност към грешки и стратегия за сигурност все още не са разработени. При първата итерация екземплярът на базата данни беше надграден до клъстер от два екземпляра във всеки VPC, конфигуриран като главен и реплика за четене, поддържащ автоматичен отказ.

В следващата итерация, с наличието на двигател MySQL версия 5.7, инфраструктурата получи надстройка до Amazon Aurora MySQL обслужване. Въпреки че се управлява напълно, Aurora не е автоматично мащабирано решение. Той предлага автоматично мащабиране на съхранението, избягвайки проблема с планирането на капацитета. Но архитектът на решения все още трябва да избере размера на изчислителния екземпляр.

Престоите поради мащабиране не могат да бъдат избегнати, но могат да бъдат намалени до минимум с помощта на възможността за автоматично излекуване. Благодарение на по-добре възможности за репликация , Aurora предлага безпроблемна функционалност при отказоустойчивост. Мащабирането се изпълнява чрез създаване на реплика за четене с желаната изчислителна мощност и след това изпълнение на срив към този екземпляр. Всички други реплики за четене също се изваждат от клъстера, оразмеряват се и се връщат обратно в клъстера. Изисква ръчно жонглиране, но е повече от изпълнимо.

Новото Aurora Serverless предложение позволява някакво ниво на автоматично мащабиране и на изчислителните ресурси, функция, която определено си заслужава да се разгледа в бъдеще.

Управлявани AWS услуги

Освен тези два компонента, останалата част от системата се възползва от механизмите за автоматично мащабиране на напълно управляваните AWS услуги. Това са Elastic Load Balancing (ELB), Amazon Simple Queue Service (SQS), Amazon S3 object storage, AWS Lambda functions и Amazon Simple Notification Service (SNS), където не са необходими особени усилия за мащабиране от архитекта.

Изменяема срещу неизменяема инфраструктура

Ние разпознаваме два подхода за работа със сървърната инфраструктура - а променлив инфраструктура, където сървърите се инсталират и непрекъснато се актуализират и модифицират на място; и an неизменен инфраструктура, при която сървърите никога не се модифицират след предоставяне и всякакви модификации на конфигурацията или актуализации на сървъра се обработват чрез осигуряване на нови сървъри от общо изображение или инсталационен скрипт, заместващи старите.

С LEVELS изборът е да стартирате неизменна инфраструктура без актуализации на място, промени в конфигурацията или действия по управление. Единственото изключение са внедряванията на приложения, които се случват на място.

Повече за изменяемата срещу неизменната инфраструктура можете да намерите в Блогът на HashiCorp .

Общ преглед на архитектурата

Технически, LEVELS е мобилно приложение и уеб приложение с REST API бекенд и някои фонови услуги - доста типично приложение в днешно време. Във връзка с това беше предложена и конфигурирана следната инфраструктура:

Изолация на виртуална мрежа - Amazon VPC

Диаграмата визуализира структура на една среда в своя VPC. Други среди следват същата структура (като Application Load Balancer (ALB) и Amazon Aurora клъстер са споделени между непроизводствените среди в техния VPC, но настройката на мрежата е абсолютно същата).

VPC е конфигуриран в четири зони за наличност в рамките на AWS регион за устойчивост на грешки. Подмрежите и групите за сигурност с мрежови списъци за контрол на достъпа позволяват да се удовлетворят изискванията за сигурност и контрол на достъпа.

Разширяването на инфраструктурата в множество региони на AWS за допълнителна толерантност към грешки би било твърде сложно и ненужно на ранен етап от бизнеса и неговия продукт, но е опция в бъдеще.

Изчислителна техника

LEVELS изпълнява традиционен REST API с някои работници на заден план за логиката на приложението, която се случва във фонов режим. И двете се изпълняват като динамични флоти от обикновени екземпляри EC2, напълно автоматизирани чрез групи за автоматично мащабиране. Amazon SQS управляваната услуга се използва за разпространение на фонови задачи (задачи), като се избягва необходимостта от изпълнение, поддръжка и мащабиране на вашия собствен MQ сървър.

Има и някои полезни задачи, които нямат бизнес логика, споделена с останалата част от приложението, като обработка на изображения. Такива задачи се изпълняват изключително добре AWS Ламбда , тъй като Lambdas са неограничено хоризонтално мащабируеми и предлагат несравнима паралелна обработка в сравнение със сървърните работници.

Балансиране на натоварването, автоматично мащабиране и толерантност към грешки

Балансирането на натоварването може да се постигне ръчно чрез Nginx или HAProxy, но като изберете Amazon Elastic Load Balancing (ELB) добавя предимството от това, че инфраструктурата за балансиране на натоварването е присъщо автоматично мащабируема, високодостъпна и устойчива на повреди.

Използва се вкусът на ELB на Application Load Balancer (ALB), като се използва маршрутизация на HTTP слой на разположение в балансиращия товар. Новите екземпляри, добавени към флота, се регистрират автоматично в ALB чрез механизмите на платформата AWS. ALB също така следи наличността на инстанциите по всяко време. Той има силата да дерегистрира и прекрати вредните случаи, като задейства автоматичното мащабиране, за да ги замени с нови. Чрез това взаимодействие между двете се постига автоматично излекуване на флота EC2.

Съхранение на данни за приложения

Хранилището за данни на приложението е Клъстер на Amazon Aurora MySQL , състоящ се от главен екземпляр и редица екземпляри за четене-реплика. В случай на неуспех на главния екземпляр, една от репликите за четене автоматично се повишава в нов главен екземпляр. Конфигуриран като такъв, той отговаря на изискването за устойчивост на неизправности.

Репликите за четене, както подсказва името им, също могат да се използват за разпределяне на натоварването на клъстера на база данни за операции за четене на данни.

Съхранението на базата данни се мащабира автоматично на стъпки от 10 GB с Aurora, а архивите също се управляват изцяло от AWS, като предлагат възстановяване по време по подразбиране. Всичко това намалява тежестта на администриране на базата данни до почти никаква, с изключение на увеличаването на изчислителната мощност на базата данни, когато възникне необходимост - услуга, която си струва да се плати, за да работи безгрижно.

Съхранение и обслужване на активи

LEVELS приема качено от потребителите съдържание, което трябва да се съхранява. Amazon S3 съхранението на обекти е съвсем предсказуемо услугата, която ще се погрижи за тази задача. Има и активи на приложението (елементи на потребителския интерфейс - изображения, икони, шрифтове), които трябва да бъдат предоставени на клиентското приложение, така че те да се съхраняват и в S3. Предлагайки автоматизирани резервни копия на качените данни чрез тяхната вътрешна репликация за съхранение, S3 осигурява трайност на данните по подразбиране.

Изображенията, които потребителите качват, са с различен размер и тегло, често ненужно големи за директно обслужване и наднормено тегло, което натоварва мобилните връзки. Произвеждането на няколко вариации в различни размери ще даде възможност за обслужване на по-оптимизирано съдържание за всеки случай на употреба. AWS Ламбда се използва за тази задача, както и за създаване на копие на качени оригинални изображения в отделна резервна кофа, за всеки случай.

И накрая, уеб приложението, изпълнявано от браузър, също е набор от статични активи - инфраструктурата за изграждане на непрекъсната интеграция компилира JavaScript кода и съхранява всяко изграждане в S3.

След като всички тези активи са безопасно съхранени в S3, те могат да бъдат обслужвани директно, тъй като S3 предоставя публичен HTTP интерфейс или чрез Amazon CloudFront CDN. CloudFront прави активите географски разпределени, намалявайки латентността до крайните потребители, а също така дава възможност за HTTPS поддръжка за обслужване на статични активи.

Осигуряване и управление на инфраструктурата

Предоставянето на инфраструктурата на AWS е комбинация от работа в мрежа, управлявани от AWS ресурси и услуги и голи изчислителни ресурси EC2. Управляваните AWS услуги се управляват добре. Няма много общо с тях, освен осигуряването и прилагането на подходящата сигурност, докато с изчислителните ресурси на EC2 трябва да се погрижим сами за конфигурацията и автоматизацията.

Инструментиране

Уеб базираната конзола AWS прави управлението на „подобната на лего тухли“ инфраструктура на AWS всичко друго, но не и тривиално и, както всяка ръчна работа, по-скоро склонно към грешки. Ето защо използването на специален инструмент за автоматизиране на тази работа е силно желано.

Един такъв инструмент е AWS CloudFormation , разработен и поддържан от AWS. Друг е HashiCorp’s Тераформа - малко по-гъвкав избор, като предлага множество доставчици на платформи, но интересен тук главно поради философията на неизменната инфраструктура на Terraform. Съобразен с начина, по който се управлява инфраструктурата LEVELS, Terraform, заедно с Packer за предоставяне на базовите AMI изображения, се оказаха страхотни.

Документация за инфраструктурата

Допълнителна полза от инструмента за автоматизация е, че той не изисква подробна инфраструктурна документация, която рано или късно остарява. Парадигмата „Инфраструктура като код“ (IaC) на инструмента за предоставяне се пресъздава като документация, с предимството да бъде винаги в крак с реалната инфраструктура. Наличието на общ преглед на високо ниво, по-малко вероятно да бъде променен и относително лесен за поддържане с евентуални промени, документирани отстрани, е достатъчно.

Финални мисли

Предложената инфраструктура на AWS Cloud е мащабируемо решение, което може да отговори най-вече на бъдещия растеж на продуктите автоматично. След почти две години той успява да поддържа оперативните разходи ниски, разчитайки на облачна автоматизация без да има специален оперативен екип за дежурства 24/7.

Що се отнася до сигурността, AWS Cloud поддържа всички данни и всички ресурси вътре частна мрежа вътре в същия облак. Никога не се изискват поверителни данни за пътуване в публичната мрежа. Външният достъп се предоставя с фини гранулирани разрешения до надеждни системи за поддръжка (CI / CD, външно наблюдение или алармиране), ограничавайки обхвата на достъп само до ресурсите, необходими за тяхната роля в цялата система.

Архитектурирана и настроена правилно, такава система е гъвкава, издръжлива, сигурна и готова да отговори на всички бъдещи изисквания по отношение на мащабиране за растежа на продукта или внедряване на усъвършенствана защита като PCI-DSS съответствие.

Не е задължително по-евтино от продуцираните предложения от подобни на Heroku или подобни платформи, които работят добре, стига да се впишете в общите модели на използване, обхванати от техните предложения. Избирайки AWS, вие получавате повече контрол над вашата инфраструктура, допълнително ниво на гъвкавост с гамата от предлагани услуги на AWS и персонализирана конфигурация с възможност за фина настройка на цялата инфраструктура.

---

Свързани:

• Направете си домашна работа: 7 съвета за изпит за архитект, сертифицирани от AWS
• Terraform срещу CloudFormation: Окончателното ръководство

Разбиране на основите

Какво представлява облачната инфраструктура?

Облачната инфраструктура е високо автоматизирано предложение, при което изчислителните ресурси, допълнени със услуги за съхранение и мрежи, се предоставят на потребителя при поискване. По същество потребителите разполагат с ИТ инфраструктура, която могат да използват, без никога да се налага да плащат за изграждането на физическа инфраструктура.

Какво представлява Amazon Web Services (AWS)?

Amazon Web Services е доставчик на облачни услуги, който притежава и поддържа мрежово свързан хардуер, необходим за тези услуги за приложения. AWS Cloud предоставя комбинация от инфраструктура като услуга (IaaS), платформа като услуга (PaaS) и пакетиран софтуер като услуга (SaaS).

Как работи AWS Cloud?

AWS Cloud работи като ресурс за изчислителни облаци при поискване, който позволява на потребителите да предоставят и използват само това, от което се нуждаят. Той предлага гъвкави, надеждни, мащабируеми, лесни за използване и рентабилни решения за изчислителни облаци.

Какво е Cloud Computing?

Облачните изчисления представляват доставка при поискване на изчислителна мощност, база данни, съхранение, приложения и други ИТ ресурси чрез интернет с ценообразуване при плащане.

AWS публичен облак ли е?

AWS е управляван от API глобално разпределен публичен облак, предлагащ почти моментален и безкраен капацитет чрез самообслужване за разработчици. Приложенията могат автоматично да мащабират капацитета нагоре или надолу в зависимост от търсенето, постигайки незабавен глобален мащаб.