Інтеграція сайту з хмарним сховищем

Олександр Демидов: Добрий день, мене звати Олександр Демидов. Сьогодні я розповідаю про "хмарних" сховищах. Коли ми з Олегом Буніним обговорювали цю презентацію і обговорювали, що в неї варто чи не варто включати, Олег говорив, що не треба додавати зайвих вступних слів про те, «що таке хмарні сховища». Всі прекрасно знають, що це таке і навіщо це потрібно. Всі ми знаємо, що хмарні сховища потрібні для того, щоб гіки могли закачати назад в Інтернет все те, що викачали звідти за багато років.

Існують різні сховища. Є такі, які можуть функціонувати як абсолютно окремий сервіс (наприклад, "Amazon S3"). Є такі, які більш повно інтегровані з "хмарної" платформою в цілому (наприклад, "Google Cloud Storage"). Є OpenSource-проекти (наприклад, "OpenStack"). Давайте поговоримо про все це докладніше.

Практично всі "хмарні" сховища дуже схожі з точки зору клієнта. Вони дозволяють зберігати практично необмежену кількість самих різних об'єктів, аж до терабайтов розміром. Вони дозволяють безпосередньо віддавати їх користувачам по HTTP, HTTPS. Всі сховища мають досить простий REST- або SAP-інтерфейс API для роботи з ними, а також відрізняються невисокою ціною. Практично всі сховища декларують вкрай високу надійність і доступність.

Я вважаю, що один з ключових моментів використання будь-якого зовнішнього сервісу - питання довіри користувачів. Важливо, наскільки користувач готовий розмістити свої дані десь зовні, наскільки він довіряє цьому сервісу.

За рахунок чого досягається надійність, відмовостійкість тих чи інших "хмарних" сховищ?

Загальний принцип роботи "хмарних" сховищ приблизно такий. Всі дані, які туди завантажуються, реплицируются відразу в кілька точок. Найчастіше, це три і більше точки для того, щоб забезпечити відмовостійкість у разі виходу з ладу двох і більше вузлів.

Якщо ви завантажуєте новий файл, відповідь про успішну завантаженні ви отримаєте тільки тоді, коли файл завантажився не на одне пристрій, а, як мінімум, на кілька. Все це відбувається прозоро, швидко. Точки найчастіше географічно розподілені. Щоб забезпечити надійність, вони географічно незалежні один від одного.

Наприклад, той же "Amazon" щодо свого сервісу "Amazon S3" говорить про те, що їх архітектура влаштована таким чином, що доступність знаходиться на рівні двох дев'яток після коми, а відмовостійкість, ймовірність втрати даних - одна мільярдна відсотка. Якщо ви завантажили 10 тисяч файлів в сховище "Amazon", то з деякою часткою ймовірності один файлик приблизно раз в десять мільйонів років ви можете втратити.

З технічної точки зору відмовостійкість забезпечена, всі добре. Виникає питання: чи варто створювати резервні копії таких даних? Навіть якщо провайдер нас запевнив, ми йому повірили, що все зберігається надійно, ніхто не застрахований від збоїв у власному програмному забезпеченні або від людського фактора, коли ми пішли і видалили ті чи інші файли, і щось з ними сталося.

Найпростіший варіант - можна реалізувати звичайне резервне копіювання, або ж використовувати якісь більш розумні, просунуті механізми. Наприклад, той же "Amazon" дозволяє використовувати версійність файлів, коли ми спеціальними запитами формуємо, задаємо зберігання кількох останніх копій файлу. Навіть якщо ми його видаляємо або перезаписувати, ми можемо звернутися до більш ранньої версії. Єдиний мінус - ми платимо за зберігання всіх файлів. Якщо ми завантажили файл в один мегабайт, і у нас є його десять версій, то платимо ми вже за десять мегабайт. Але, насправді, механізм зручний. Його вкрай корисно використовувати в своїх проектах, щоб максимально себе убезпечити.

Ще одне питання безпеки - це збереження, конфіденційність даних. Часто ми хочемо дати доступ до файлів не всім, а якимсь певним користувачам. Практично кожен "хмарний" провайдер, так чи інакше, реалізував механізм access-листів, які дозволяють дати доступ на читання, наприклад, всім користувачам або якимось певним. ACL реалізовані практично у всіх.

Ще можна використовувати шифрування на стороні клієнта. Тоді сам клієнт відповідає за зберігання і обробку всіх ключів, за допомогою яких відбувається шифрування. Або можна використовувати сервер-сайт шифрування ( "Amazon S3" надає таку послугу), тоді ці речі провайдер бере на себе.

Безпека, надійність - це ключовий момент використання будь-якого зовнішнього сервісу, особливо якщо мова йде про якісь "хмарних" сервісах. Люди часто говорять, заперечуючи проти використання "хмари": "Я ніколи в житті не віддам свої дані кудись назовні". У порівнянні, наприклад, з традиційними хостерами, це нітрохи не менш надійно. Може бути, в чомусь навіть більш надійно. Це насправді кльово і зручно.

Якщо ми все-таки вирішимо це використовувати, давайте подивимося, яку користь нам це може принести.

Ми не можемо зберігати там скрипти і виконувати їх. Ми можемо зберігати там тільки статику.

Які плюси це може дати нам або вам як власникові веб-проекту?

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

Майже кожен "хмарний" провайдер пропонує для своїх "хмарних" сховищ власну (або в партнерстві з кимось) CDN-мережу (Content Delivery Network), яка дозволяє віддавати ваш контент відвідувачам вашого сайту з найближчої до нього географічної точки.

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

Якщо ми винесемо всю статику кудись назовні, наш сайт стає досить "легким". Нам простіше робити його резервні копії і переносити його з сервера на сервер. Або ж, якщо наш проект виріс, і його потрібно смасштабіровать на кілька серверів, нам простіше вирішити питання синхронізації контенту між серверами.

Нарешті, ми прискорюємо швидкість рендеринга сторінок в браузері. Навіть якщо у нас суперпродуктивний сервер, все в порядку з мережею, і весь контент віддається максимально швидко - всі браузери за замовчуванням відкривають досить обмежена кількість підключень до одного домену. Зазвичай допустимо чотири-п'ять з'єднань. Якщо основні сторінки ваших сайтів і вся статика (Java-скрипти, CSS і картинки) віддаються з одного домену, то при десятках сторінок браузер буде завантажувати все це в чотири-п'ять потоків.

Якщо ви це розносите за різними доменами (навіть якщо не використовуєте "хмарне" сховище, а фізично використовуєте те ж саме сховище, просто по доменах рознесли), то браузер буде відкривати незалежне з'єднання кожному з піддоменів.

Здавалося б, ми тут "економимо на сірниках". Йдеться про якісь частки секунди або секунди. Але, насправді, це досить критичне значення.

Є одна компанія під назвою Gomez ... Займається вона якраз консалтингом в сфері продуктивності, аудитом сайтів, і так далі. Вони проводили дослідження 150 мільйонів хітів зі 150-ти різних сайтів. До якого висновку вони прийшли? Уповільнення завантаження сторінки на одну секунду призводить до зменшення кількості переглядів сторінок на 11% і до зменшення конверсії - на 7%. Для онлайн-бізнесу це величезні цифри і величезні втрати. Так що має сенс заощадити і ці речі не втратити.

Amazon S3

Чудовий, зручний інструмент. Давайте тепер виберемо, яке конкретно сховище ми будемо використовувати.

"S3" в назві "Amazon S3" розшифровується як Simple Storage Service. Це і справді простий сервіс зберігання. Він простий, як молоток, яким забивають цвяхи. Молотком можна виконувати тільки одну функцію - забивати цвяхи. Але це можна робити класно. Дуже популярне сховище, дуже багато його використовують. На мій погляд, популярність пов'язана з тим, що його можна використовувати абсолютно незалежно від всієї інфраструктури Amazon. Можна використовувати разом, наприклад, з тією ж CDN, через Cloudfront від Amazon віддавати файли відвідувачам через їх CDN. Але це сховище можна використовувати абсолютно незалежно.

Дуже розвинені і офіційно підтримуються різні SDK, Java, .NET, PHP, Ruby. Наскільки я знаю, Amazon чи не єдиний провайдер "хмарних" сховищ, які офіційно (першими, по крайней мере) стали підтримувати SDK і для мобільних платформ, iOS і Android. Цим, напевно, і пояснюється популярність саме цієї платформи; її використовують дуже багато розробників.

Цікава особливість Amazon S3

Для цього сховища передбачена така послуга, як RRS (Reduced Redundancy Storage), тобто сховище зниженою надійності. Дані реплицируются в меншу кількість точок в порівнянні зі звичайним сховищем. За рахунок цього знижується вартість, RRS приблизно на 25% дешевше.

Де можна використовувати RRS?

Наприклад, RRS підійде для зберігання контенту, який не дуже важливий, і його можна, так чи інакше, відтворити. Наприклад, RRS згодиться для маленьких прев'ю-картинок або відео в гіршій якості. Якщо ви оригінали зберігайте в нормальному сховище, то цей контент ви завжди можете перегенеріровать, і це буде не дуже критично. Якщо взяти ті ж цифри (приблизно) про 10 тисяч файлів в зберіганні, то втрата одного файлу з такого сховища може відбутися не раз в 10 мільйонів років, а приблизно раз на рік.

Як працювати з таким сховищем?

Є API Rest. Воно досить просте. Через нього можна отримати список Бакета, список об'єктів в Бакета. Можна завантажити файл, отримати файл, управляти access-листами для файлів (визначати, хто має доступ до файлів) і виконувати інші подібні операції, список яких досить обмежений. Це дійсно дуже простий інструмент.

Можна працювати через веб-інтерфейс самого провайдера, через зовнішніх клієнтів від сторонніх виробників. Можна використовувати таку цікаву річ, як s3fs. Можна застосувати рішення на основі FUSE - це файлова система, яка просто монтується до всієї системи і виглядає як окремий розділ. Далі можна з ним абсолютно прозоро працювати: копіювати, переміщати, з нього файли видаляти.

Фінансове питання

Вартість зберігання досить невисока - зберігання 14 гігабайт даних коштує 12 центів на місяць. Трафік, наскільки я пам'ятаю, приблизно так само - 12 центів за гігабайт. Все залежить від обсягів. Якщо мова йде вже про терабайт, то вартість може знижуватися приблизно до двох разів залежно від об'єму.

Google Cloud Storage

Наступне сховище - це Google Cloud Storage.

Воно, по-моєму, використовується менше, ніж Amazon S3. На мій погляд, це пов'язано з тим, що дане сховище багато в чому "зав'язано" на "хмарну" платформу від Google під назвою Google App Engine. Не існує навіть SDK окремо для роботи з цим сховищем. Воно використовується для всієї платформи. Історично воно підтримується для Java і Python. Набір інструментів там досить обмежений.

Які цікаві особливості Google Cloud Storage?

Стандартний механізм авторизації, який використовується в Google Cloud Storage називається OAuth 2.0. Він документований. Є безліч прикладів робіт саме з цим механізмом. Використовувати його легко і просто.

Access-листи, які використовуються в Google Cloud Storage засновані на акаунтах Google. Якщо ви хочете віддавати файли не всім, а якимсь певним користувачам, то вказуєте їх рахунок у Gmail або Google+. Користувач, якщо він авторизований в Google в своєму браузері, і ви йому дали права на файл, файл завантажить. Якщо він в своєму браузері в цьому акаунті не авторизований, то він файл не отримає. Досить зручний інструмент, тому що дуже у багатьох (хоча і не у всіх) є акаунти Google в тих чи інших сервісах. Файли зручно віддавати цілком конкретним людям.

Так само, як і в випадку з Amazon S3, в Google Cloud Storage є стандартний веб-інтерфейс для роботи з файлами в сховище. Є API, утиліти для роботи з командним рядком, зовнішні клієнти для роботи з файлами.

Фінансове питання

Вартість практично така ж, як і в Amazon S3: ті ж 12 центів за зберігання і 12 центів за трафік. Зменшення вартості в залежності від обсягу приблизно до півтора разів, в залежності від того, скільки терабайт даних ви зберігаєте і передаєте.

Windows Azure Storage

Наступне сховище - це Windows Azure Storage.

Windows Azure Storage - це складова частина хмарної платформи від Microsoft під назвою Windows Azure. У нього є головна ключова особливість, що говорить на користь вибору цього сховища: CDN-мережу в Росії. Наприклад, той же Amazon S3 має досить велику CDN-мережу, але не має точок присутності в Росії. CDN-мережу Microsoft в Росії має близько 10-ти точок. Ця CDN реально зручна для російських користувачів. Якщо ми вивантажує контент з Новосибірська, то отримаємо його з точки, найближчої до Новосибірську. Якщо з Москви - значить, з точки, найближчої до Москви.

SDK для роботи з Windows Azure Storage досить цікавий. Природно, підтримуються .NET, Node. js, Java, PHP (досить поширені інструменти). Існують сторонні клієнти для роботи з файлами, завантаження, отримання даних з цього "хмари". Цікава особливість - можливість використовувати Windows Azure Drive. Можна монтувати "хмара" як окремий NTFS-розділ. Цей же інструмент дозволяє швидко переносити дані з загальнодоступного "хмари" в приватне і навпаки.

Rackspace Cloud Files

Ще один "хмарний" провайдер - це Rackspace. Напевно, це один з найбільших провайдерів в світі.

Природно, як і будь-який "хмарний" провайдер подібного масштабу, Rackspace зробив свою хмарне сховище - Rackspace Cloud Files. Вони не стали робити власну мережу CDN, але працюють в партнерстві з одним з найбільших CDN-провайдерів в світі - Akamai. Користувачі Rackspace автоматично можуть користуватися послугами Akamai для дистрибуції контенту.

Чим цікава хмарна платформа, яку використовує Rackspace?

Спільно з NASA (навіть, напевно, на їх замовлення) вони розробляли "хмарну" платформу, яка в середині 2010-го року стала існувати у вигляді окремого відкритого проекту під назвою "OpenStack". Зараз це набір програмного забезпечення для створення повноцінної "хмарної" платформи, яку, по суті, будь-який бажаючий може взяти і розвернути у себе всередині для якихось внутрішніх цілей. Також можна розгорнути загальнодоступне "хмара" і почати надавати послуги на базі цього проекту.

Поки в Росії це зробила тільки компанія Clodo, наскільки я знаю. Це перша компанія, яка публічно надає послуги "хмарного" сховища саме в Росії. Це дуже зручно, як мінімум, з точки зору бухгалтерії, документів і плати за користування послугами.

"OpenStack" підтримується дуже багатьма компаніями. Їх близько 50-ти, включаючи Dell, Citrix, AMD і Intel. Проект активно розвивається, він дуже цікавий. "Хмар" на базі цього проекту буде багато.

FTP Cloud FS

Є цікавий інструмент - FTP Cloud FS. Це якась прошарок, яка дозволяє вам працювати з "хмарним" сховищем через стандартний FTP. Якщо ви звикли завантажувати файли саме таким чином, то можете підключити даний інструмент на своєму сервері і користуватися ним для завантаження файлів.

Припустимо, сховище ми вибрали.

Як це все буде працювати?

Файли, які віддаються користувачам безпосередньо, матимуть ось такий довгий URL щодо провайдера (замість нашого звичного короткого URL щодо нашого домену). Якщо наш додаток має щось зробити з файлами, воно теж візьме їх за таким URL. Так чи інакше, обробить і потім, використовуючи API, покладе їх назад в "хмара". Наприклад, візьме картинку, зробить превью, покладе в "хмара". Далі користувач буде його отримувати безпосередньо.

Давайте подивимося, як реалізована підтримка тих чи інших хмарних сховищ в різних популярних CMS, які ви можете використовувати на своєму проекті. Для нас це буде, природно, цікаво.

WordPress

Підтримка "хмарних" сховищ реалізується сторонніми плагінами. Є два основні сценарії використання. Перший має на увазі винесення всіх медіа-файлів (картинок, відео, музики) і віддача їх через "хмарні" сховища і CDN. Другий сценарій використання - це збереження резервних копій в "хмара".

Joomla

Приблизно те ж саме. Сценарії ті ж. Винос медіа-контенту, збереження копій. Є цікавий плагін - jomCDN, який дозволяє всю статику віддавати через CDN поширених "хмарних" провайдерів.

Drupal

Так само. Через зовнішні модулі, і ті ж самі сценарії використання.

Бітрікс

ВІН зазначеним не тому, что я там працюю, а тому, что це реально найпопулярніша платна CMS. Яким Шляхом ПІШЛИ ми, реалізуючи підтрімку "Хмарний" Сховище в Нашій системе? Ми Зроби підтрімку "Хмарний" Сховище на Рівні ядра. Це вбудований в систему модуль, Який пошірюється в усіх редакціях. Підтримка сховищ далі реалізована у всіх внутрішніх модулях системи. Є API, які можуть використовувати всі сторонні розробники, реалізуючи власні модулі.

Як ми міркували, роблячи підтримку хмарних сховищ у себе в системі?

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

Мало взяти файли і завантажити їх в "хмара". Мало взяти і на сайті поміняти всі посилання на нові. Якщо ви захочете кудись переїхати, доведеться проробляти всю цю роботу заново.

У вас на сайті існують абсолютно різні ролі. Є адміністратор сайту, є контент-менеджер і користувачі вашого сайту, які можуть реєструватися, завантажувати якийсь контент (наприклад, аватари, фотографії, ще щось). У вас робота з усім контентом повинна відбуватися абсолютно прозоро, незалежно від того, де ви його хочете зберігати (локально на диску, в одному "хмарному" сховище або іншому).

Якщо ми беремо автомобіль, то не повинні замислюватися, як зараз поїдемо, за яким типом дороги. Якщо ми поїдемо по асфальту - візьмемо одні шини, заправимося одним бензином. Якщо по грунтовій - візьмемо інше. Ми повинні сісти і поїхати. Про те, як все влаштовано і як воно працює всередині, ми замислюватися не повинні.

Як це реалізувати?

Як ми міркували? Може бути, ці міркування допоможуть вам в реалізації якихось ваших проектів.

Перше, що повинно у нас бути - це API для роботи з самим "хмарним" сховищем. З цим у нас все в порядку, все добре. "Хмарні" сховища API для роботи надають.

Далі. У нас повинен бути якийсь новий рівень абстракції для роботи з файлами в нашій системі. Ми не повинні використовувати стандартні функції для роботи з файлами - для копіювання, отримання інформації про файлах. Ми не знаємо, де файл у нас зберігається (локально, в одному "хмарі", іншому). Ми повинні написати якийсь власний API для роботи з файлами. Може бути, це не дуже зручно для нас як для розробника. Але це набагато зручніше в подальшому для підтримки, підключення нового будь-якого сховища, абсолютно прозоро для контент-менеджера і користувача.

Важливе завдання, яке нам треба вирішити - це постаратися уникнути наявності так званих "диких" файлів, які ми по FTP завантажили і в текстовому редакторі в сторінку вставили, що цей файл вантажиться звідти. Ми його ніяким чином відстежити не можемо і роботу з ним через наш API реалізувати не можемо. В ідеалі, всі модулі нашого сайту, всієї нашої системи повинні, так чи інакше, реєструвати попадання будь-яких файлів, отримувати якусь інформацію про кожен файл і фіксувати, де він зберігається (на локальному диску, в сховище або де-небудь ще).

Сховища, які ми використовуємо, повинні легко і просто підключатися до системи. Не повинно бути такого, що ми підключили одне сховище, перенесли туди дані, а потім виявили, що нам стало дорого і невигідно, і ми вирішили переїхати в інше ... і витратили на це декілька днів або тиждень. Робота зі сховищем повинна відбуватися просто.

В ідеалі, ми повинні вміти працювати з різними сховищами, щоб, по-перше, просто в тестах подивитися, яке з них краще. Може бути, в різних сценаріях варто використовувати різні сховища. Це було б реально зручно. Для будь-яких сторонніх розробників, які працюють з нашою системою, робота з файлами повинна бути прозорою.

Що ми можемо зробити для того, щоб все це забезпечити?

Чи можемо у себе (наприклад, в таблиці в базі даних) зберігати інформацію про всі файли, які присутні у нас в системі. Завантажуються вони через форуми, блоги, форми завантаження. Ми зберігаємо інформацію про файл. Якщо мова йде про зображення, в ідеалі ми відразу отримуємо всю інформацію про конкретний зображенні (наприклад, розмір, ширину, висоту, ще якісь дані) і зберігаємо її в тій же таблиці. У цій же таблиці фіксуємо, де у нас зберігається цей файл. В окремій таблиці фіксуємо всі "хмарні" сховища, які підключені до системи.

Розробляємо API, який буде працювати поверх стандартної функції. Стандартні функції роботи з файлами намагаємося не використовувати. Тоді підключення будь-якого нового провайдера буде зведено до додавання запису в таблицю і (якщо ми сторонній розробник) написання якогось інтерфейсу провайдера для роботи з цим новим сховищем.

Коли ми розробляли підтримку хмарного сховища у себе в системі, ми спочатку зробили підтримку Amazon S3 і Google Storage. Лише пізніше ми підключили підтримку OpenStack. Готова архітектура дозволила написати її, по-моєму, за два-три дні.

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

Я зараз пояснив, як все зробити правильно і зручно для всіх ролей в системі.

Є ще один окреме питання: як зробити красиво?

Довгий URL, який дає "хмарне" сховище, використовувати не хочеться. Хочеться використовувати, як мінімум, свій власний піддомен.

Принцип роботи практично у всіх провайдерів дуже схожий. Поясню його на прикладі Amazon S3. За замовчуванням файли віддаються двома шляхами. Або це шлях s3.amazonaws.com/, далі назва Бакета, далі повний шлях до файлу. Або назва Бакета точка s3.amazonaws.com, і далі повний шлях до файлу.

Ми можемо Бакет назвати ім'ям нашого субдомена. Наприклад, files.domain.ru. Прописати спеціальний запис в DNS виду IN CNAME s3.amazonaws.com, і тоді файли будуть доступні нам по шляху щодо нашого субдомена. Простий, красивий, зручний спосіб.

Єдиний мінус - практично всі провайдери дозволяють отримувати файли не тільки по HTTP, а й по HTTPS, причому з абсолютно дійсним сертифікатом. Якщо ми використовуємо власний домен для такого підключення, свій сертифікат ми майже ніколи підключити не зможемо. У нас відбувається розбіжність імен. Виникають складності.

Колеги з Clodo махають руками, значить, вони цю річ реалізували. Але я на практиці поки такого не бачив.

Можна це обійти. Можна, наприклад, поставити який-небудь власний легкий сервер, "підняти" на ньому Nginx і далі проксіровать запити через нього.

Що нам це в підсумку дало? Які типові сценарії використання хмарних сховищ? Як це може виглядати?

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

Ми передбачили можливість підключення різних сховищ, і це у нас відбувається абсолютно прозоро - ми можемо абсолютно вільно файли переносити туди-сюди між локальними дисками і різними сховищами. Ми можемо підключити кілька різних сховищ і налаштувати правила для роботи з ними. Наприклад, файли менше 10-ти мегабайт зберігати на Amazon, все відео зберігати в Google, а всі інші файли скласти в Clodo. Ми можемо оцінити роботу кожного провайдера і легко і просто перемикатися між ними.

Ще один великий дуже важливий приклад використання "хмарних" сховищ - це використання в великих масштабованих проектах.

Ми самі зараз запускаємо абсолютно новий для себе проект - "Бітрікс 24". Кому цікаво, у всіх в роздачі є запрошення на цей проект. Він зараз працює в режимі закритого бета-тестування. Всі бажаючі можуть подивитися. Ми самі прекрасно розуміємо, що у нас ніколи не буде другого шансу справити перше враження. Проект на старті повинен швидко "злетіти", швидко всім показуватися, віддаватися. При цьому у нас повинна бути можливість дуже швидко масштабироваться і витримати, напевно, будь-яке навантаження.

Все це можна вирішити, забезпечивши собі величезний запас. Закупивши заздалегідь багато серверів, розвернувшись на них, закластися в 10 разів на можливе навантаження. Все буде добре. Але для проектів, які з якихось причин потім можуть не "злетіти", це буде великий удар по бюджету. Гроші вклали, витратили, але ніякої віддачі не отримали. Це може відбити всі бажання запускати будь-які нові проекти, займатися будь-яким новим бізнесом.

Хочеться запускатися з невеликими ресурсами і мати можливість їх дуже швидко розширювати. Причому зрозуміло, що нескінченно зростати вертикально, збільшуючи потужність сервера, неможливо. Рано чи пізно ми зайдемо в ті чи інші рамки. Тому колись нам доведеться навчитися масштабироваться горизонтально, просто додаючи нові машини.

Саме запускаючи "Бітрікс 24", ми вважаємо, що важливо передбачити резервування на рівні дата-центру. Навіть якщо у нас вийде з ладу цілий дата-центр, ми повинні швидко перемкнутися на другий (бажано зробити це практично непомітно для користувачів). В цьому випадку контент логічно зберігати десь між усім цим. Наприклад, в тому ж самому "хмарному" сховище.

Що у нас в підсумку виходить? Як це все виглядає в нашому конкретному живому проект, який вже зараз працює?

По суті, на веб-нодах, де працює безпосередньо додаток Application, ніякого контенту, даних користувачів немає. По суті, все там в режимі "тільки читання", крім якихось тимчасових директорій. Користувачі, які завантажують файли, відразу завантажують їх у "хмара", отримують вони їх теж з "хмари". По суті, у нас всі машини з додатком просто стають витратним матеріалом.

Якщо у нас відбувається збій, аварія або незрозуміла аномалія на будь-якій машині - сильно простіше і сильно дешевше з точки зору адміністрування просто цю машину "загасити" і "підняти" нову і не розбиратися, що сталося. Точно так же працювати з оновленнями програмного забезпечення, як системного, так і нашого власного додатка. Ми створюємо новий образ машини. Далі розгортаємо нові машини з цього образу, а старі машини просто "гасимо".

Призначений для користувача контент, дані зберігаються або в базі, або в "хмарі", але не на самих машинах, збоями вони не будуть зачіпатися і не губляться.

Ми трохи параноїки. Подумали, що неправильно дані різних користувачів нашого сервісу скласти в одне сховище, тільки на рівні додатків ізолювати їх один від одного. Ми подумали, що треба б їх ізолювати ще й на рівні безпосередньо сховища.

Саме тому у нас в проекті зараз для кожного нового користувача, який реєструється в системі, створюється окремий обліковий запис. Ми робимо все в Amazon, застосовуючи Amazon IAM (identity access management). Отже, створюється окремий обліковий запис. Для неї виходить пара AccessKey і SecretKey. Вона прописується для даного конкретного користувача, і потім користувач отримує доступ тільки до конкретної директорії, яка доступна тільки йому, але не його сусідам. Ми тим самим забезпечуємо ізоляцію користувачів один від одного.

резюме

Таким чином на нашому проекті виходить "дешеве" використання великих обсягів файлів. Є просте масштабування і проста можливість резервувати наші програми на рівні різних дата-центрів. "Хмарне" сховище (якщо ми його використовуємо грамотно) дозволяє нам отримати високу доступність наших даних, високу їх надійність, максимально резервувати їх і забезпечувати швидку роботу нашого сайту. По суті, це невеликий план захоплення світу. Залишилося тільки опрацювати деталі.

Я зараз із задоволенням відповім на ваші питання. Будь ласка, задавайте.

Питання та відповіді

Репліка із залу: У мене питання технічне, більше про досвід роботи з Amazon. Зокрема, я стикався з такою дивною ситуацією при роботі з Amazon Cloud: додаток, здавалося б, стабільно працювало на кожній ноді, на кожному сервері, і були нормальні дані профілювання, що показують константне час відповіді і продуктивність. Проте, при виклику з зовнішньої мережі додаток показує "плаваючі" результати під час неответа. Швидше за все, це пов'язано як раз з внутрішнім пристроєм мережі Amazon або якимись мережевими операціями в ній.

Ви з чимось подібним стикалися? На CDN, на доставці контента великого обсягу ви, швидше за все, щось подібне могли "зловити".

Олександр Демидов: Ви питаєте про балансувальник, про CDN, або безпосередньо з їх EC2 машин віддачу?

Репліка із залу: Насправді, про все.

Олександр Демидов: Там можливі найрізноманітніші нюанси. Наприклад, балансувальник може впливати. Він може визначати, жива машина чи ні. Через це може бути деяка затримка. Потрібно конкретніше дивитися. Хочете, я вам свої контакти дам, ми з вами предметно поговоримо. У нас досвід експлуатації Amazon дуже великий, ми їм із задоволенням ділимося. Підходьте, поговоримо, поспілкуємося.

Добре, що тема Amazon вам цікава. Це означає, що "хмари" вже не здаються людям якийсь маркетингової річчю. Спасибі вам.