Поуки от неотдавнашното прекъсване на AWS S3

Amazon S3 е в основата на много AWS услуги, включително AWS Lambda, Elastic BeanStalk и собственото табло за управление на здравето на Amazon. Той също така служи като обект и медиен магазин за много други интернет услуги, които разчитат на него всеки ден.

На 28 февруари 2017 г. AWS претърпя часово прекъсване на услугата Amazon S3 в регион US-EAST – 1. Това създаде каскаден ефект от прекъсвания в голяма част от интернет, включително услуги като Dockerhub.

Основната причина се оказа човешка грешка:

В 9:37 ч. PST, упълномощен член на екипа на S3, използващ утвърдена книга за изпълнение, изпълни команда, която имаше за цел да премахне малък брой сървъри за една от подсистемите S3, които се използват от процеса на фактуриране на S3. За съжаление, един от входовете в командата е въведен неправилно и по-голям набор от сървъри е премахнат от предвиденото.

Както се оказва, има често срещано погрешно схващане за разликата между трайността и наличността. Трайността измерва колко надеждно е съхранението и отговаря на въпроса „Ще загубя ли данните си?“ Наличността, от друга страна, измерва колко достъпни са данните, т.е. „Ще мога ли да извлека данните си?“

AWS S3 предлага 99,999999999% издръжливост в рамките на един регион. Ако разгледаме примера на Amazon, това означава, че ако съхранявате 10 000 обекта в S3, средно един обект може да се загуби веднъж на 10 милиона години. Amazon S3 постига това, като репликира данните в множество съоръжения в даден регион.

Стандартната наличност на обекти S3, от друга страна, е 99,99% годишно в рамките на даден регион. Това означава, че за всеки даден 12-месечен период трябва да очаквате общо 52 минути и 33 секунди да не можете да получите достъп до вашите данни.

AWS предлага както услуги IaaS, така и PaaS. На ниво IaaS клиентите на AWS имат пълен контрол върху виртуалните сървъри и мрежи. Те могат да конфигурират всеки софтуер и услуга, които желаят, и се управляват сами. Всяко прекъсване е отговорност на клиента.

На ниво PaaS, AWS предлага напълно управлявани платформени услуги като съхранение на обекти, бази данни, опашки и т.н. Клиентът делегира отговорността за наличността и трайността на тези услуги на управлявания доставчик на услуги - AWS в този случай. Услугите на платформата на AWS, които се използват чрез собствения им API, са особено уязвими към регионално прекъсване поради човешка грешка в AWS.

Човешката грешка може да доведе до прекъсване навсякъде - на място, в облака, управлявано или самостоятелно хоствано. Помислете за неотдавнашното прекъсване на работата на компютъра Delta като пример за срив на цяла система за самостоятелно хостване. Делегирането на отговорността за управление на услуга на платформата на доставчик на облак не променя факта, че човешката грешка може да я свали - но усилва въздействието. Докато прекъсването на Delta засегна само Delta, прекъсването на AWS S3 повлия на добра част от интернет.

За щастие AWS S3 предлага достатъчно инструменти за намаляване на въздействието на прекъсване. Нека разгледаме само няколко.

S3 междурегионална репликация

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

Архиви

Репликацията между региони може да помогне за увеличаване на наличността. Архивите на AWS Glacier могат да допринесат за повишена трайност. Удобно, AWS предлага автоматичен механизъм за архивиране на обекти в S3 към Glacier.

Помислете за разпространение на съдържание с CloudFront

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

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

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