AWS в дауні: чому небеса впали

21 квітня о 01:41 за тихоокеанським часом стався серйозний збій в одному з дата-центрів Amazon Web Services, «хмари» для багатьох сайтів. Деякі великі проекти (Reddit, Quora, Foursquare) пішли в офлайн або сильно постраждали. Я вже бачив купу дезінформації з натяком на те, що проблеми постраждалих сайтів пов'язані тільки з лінню інженерів цих проектів, але в даному випадку причина в іншому. І ось чому.

У AWS дві концепції щодо доступності: регіони (Regions) і зони доступності (Availability Zones, AZ). Є п'ять регіонів: два в США (західне і східне узбережжя), один в Європі (Ірландія) і два в Азії (Токіо, Сінгапур). У кожному регіоні розташовані кілька AZ, які повинні бути ізольовані один від одного і не мати загальної точки збою, крім стихійного лиха або чого-небудь подібного масштабу.

AWS каже, що «ставлячи інстанси в окремих AZ, ви можете захистити свої додатки від збою в якомусь окремому місці». Під «місцем» вони передбачають «фізичну незалежність зон доступності один від одного і незалежну інфраструктуру». Судячи з усього, це окремі дата-центри (хоча, з опису Amazon це не очевидно - може бути, це різні поверхи/кімнати в дата-центрі з незалежним харчуванням і підключенням по різних каналах - прим. пер.). Вони не повинні валитися одночасно один з одним, якщо не сталося катастрофи, яка накрила весь регіон.

Зони доступності також пропонують «недорогу можливість з'єднання з низькою затримкою між зонами доступності в тому ж регіоні». Міжрегіональний коннект, з іншого боку, йде через відкритий інтернет, і відносно дорогий, повільний і ненадійний.

Це «правила гри». Отже, якщо ви граєте за правилами AWS і підняли master/slave базу даних MySQL (щоб взяти найпоширеніший приклад), то, за логікою, ви повинні поставити master і slave в одному і тому ж регіоні, але переконатися, що вони в різних зонах доступності. Ви не будете розміщувати їх в різних регіонах, інакше доведеться ганяти трафік по повільних і дорогих каналах між регіонами, і швидше за все у вас буде більше проблем з синхронізацією баз. Ви ризикуєте тільки в тому випадку, якщо, наприклад, ураган обрушиться на східне узбережжя і знищить дата-центр (и), але за винятком цього все повинно бути в порядку - принаймні, якщо дотримуються обіцянки AWS.

Так що, в підсумку, у нас утворилася проблема. Вчора кілька зон виявилися недоступними в регіоні східного узбережжя. AWS порушили власні обіцянки за сценарієм збоїв у зонах доступності. Це означає, що у AWS є якась загальна точка збою (якщо припустити, що не стався якийсь абсолютно неймовірний сценарій на кшталт одночасного фізичного пошкодження декількох незалежних інфраструтур). Сайти, які досі в дауні, цілком коректно виконали свої умови «правил гри», проблема в тому, що AWS не слідували власним специфікаціям. Сталося це через некомпетентність або нечесність, або чогось більш простивого, ми просто не знаємо на даний момент. Але розробники в Quora, Foursquare і Reddit дуже компетентні і буде неправильно направляти звинувачення в їх бік.

Звичайно, теоретично можна захиститися навіть від катастрофічних збоїв (декількох зон доступності), але для більшості бізнесів ці додаткові витрати на розробку і витрати не варті того (або можуть бути навіть контрпродуктивними, ускладнюючи систему). Я впевнений, що у всіх сайтів, які зараз в дауні, збереглися бекапи. Проблема в тому, що їх повернення в онлайн може стати складним і ризикованим - на практиці, вам потрібно все перемістити в інший регіон, інакше мережева затримка між вашими серверами буде занадто великою. На AWS це надзвичайно складно: на серверах різних регіонів - різний набір опцій, різні ідентифікатори AMI, я думаю, що зарезервовані інстанси взагалі не можна переміщати між дата-центрами - в реальності, передача управління в інший регіон практично неможлива. Напевно, тут буде потрібно приблизно стільки ж зусиль, скільки при міграції в зовсім іншу хмару, що, ймовірно, і є найкращим варіантом відновлення після такої катастрофи. Наскільки ми знаємо, Quora почала цей процес в ту ж хвилину, як тільки стався збій на AWS, і не завершила його досі - це може зайняти добу.

Так що, коротко, звинувачувати тут потрібно виключно AWS, яка «гарантувала» умови, які порушила. Помилки трапляються, але тут саме помилка AWS.

І це не помилка хмарного хостингу як такого. Цей випадок показує, що потрібно ретельно вибирати провайдера. Я думаю, багато людей переглянуть свій вибір на користь AWS.

Ще кілька думок:

• Причина, через яку так багато сайтів розміщуються в регіоні східного узбережжя в тому, що саме тут AWS раніше за все викочує нові фічі. Він також найдешевший. І це, ймовірно, найкращий регіон для обслуговування трафіку (нормальна продуктивність для Північної Америки, стерпна продуктивність для Європи)
• Причиною збою насправді стали дискові масиви EBS (Elastic Block Store), які катастрофічно проявили себе в плані надійності з самого початку їх використання. Але це вже тема зовсім іншої статті!
• Масиви EBS можуть бути тільки в одній зоні доступності і доступ до них може йти тільки з цієї зони. Судячи з усього, розподілена база даних Amazon RDS використовує секретні API, що дозволяють отримувати доступ до EBS з інших зон, але ці інтерфейси не доступні нікому, крім RDS (хм... компанія з Сіетла, яка використовує секретні API для отримання конкурентної переваги - звучить якось знайомо?)