Дарудар — хмара в дар від Microsoft

Дарудар — відомий на просторах Рунета проект, став сполучною ланкою між людьми, охочими щось подарувати, але не знають кому, і тими, хто може цього захотіти. На сайті можна знайти все, що завгодно — від побутових і не дуже речей до справжнісіньких котів у мішках. Про те, як працює сервіс, де вже подарували більше 2 мільйонів дарів, розповідає один із засновників сервісу, Антон brutto Каракулов.



Дарудар — справжнісінький перевантажений проект. Розміщений у хмарі і використовує повністю Linux-стек, у добу він витримує ~2.5 тис дарів і ~1.5 тис подяк, ~20 тис. коментарів, ~40 тис. повідомлень і ~4.5 тис. файлів. Подробиці під катом.


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

— Широкий вибір операційних систем, ЯП, фреймворків, інструментів, БД і пристроїв.
— Широкі можливості інтеграції: Linux-контейнери в Docker; нарівні з
створенням JavaScript, Python, .NET, PHP, Java і Node.JS додатків
— І, звичайно, бекенда для додатків під iOS, Android і Windows

Відсутність необхідності освоювати нові технології або рішення/інструменти, укупі з білінгом в реальному часі і масштабованої «по запиту» залізної інфраструктурою — ось наріжний камінь, на якому стоять всі сучасні хмари, і Microsoft Azure тут, звичайно ж, не виняток.

Мабуть, ще одна важлива перевага хмарних платформ в цілому і Microsoft Azure зокрема — це можливість перенесення існуючого проекту і отримання всіх уже згаданих переваг. Власне, зараз «перевезти» власний бек-енд з дата-центру, в якому ви, можливо, орендуєте окремі стійки, у хмару не представляє ніякої праці: гібридні бази даних, сховища, безпечні способи підключення — все це є з коробки. А в випадку Microsoft є ще і Azure Stack, що дозволяє принести модель розробки і викочування (деплоя) додатків Azure в будь ЦОД або дата-центр.

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

Про «чому?»

Ми, як і багато інших, отримали грант від компанії Microsoft за програмою підтримки стартапів. На наш погляд, це жирний плюс, особливо для початківців проектів або проектів, які хотіли б лише випробувати хмара. Хоча, звичайно, нам пощастило дізнатися про переваги Azure в один з найважчих моментів (наша попередня майданчик-хостер різко припинила свою діяльність, і ми «рятували» власну інфраструктуру). Наші попередні хостери славно потрудилися в свій час, і я не можу сказати про них нічого поганого, але з-за постійної нестачі повноцінного системного адміністратора (на зарплату якого у нас немає коштів) — хмара помітно спростила моменти, пов'язані саме з адмініструванням інфраструктури.

Про архітектуру і технології

У Дарудара цілком класичний nix-стек: nginx, php, mysql, memcached, sphinx.

Зустрічає все nginx, далі запит йде на php-бекенд, який вже взаємодіє з усіма іншими як внутрішніми, так і зовнішніми сервісами проекту.

Зараз на Azure використовується Cloud Services і виртуальныемашины Ubuntu всередині однієї мережі. Для кожного внутрішнього сервісу створений образ, який може бути використаний для аварійного
відновлення/заміни і планується використовувати також для можливості подальшого горизонтального масштабування сервісів проекту не без допомоги зручних інструментів платформи Azure Available Sets і Load Balancing set.

В планах стоїть переїзд медіа-сховища на Azure Blob Storage, а також використання Azure Queue (тестування).



Про стереотипи

«Azure — MS, а MS — Windows» — у мене в голові теж спрацьовувала така зв'язка. І це було першим, що я перевірив, коли отримав доступ до контрольної панелі Azure.

Все виявилося не так. Azure виявився лояльний до Nix-систем, і ми використовуємо саме їх.

Win-серверами ми на Дарударе ніколи не користувалися і не користуємося взагалі. З виндовой технологією віртуалізації знайомий тільки з чуток —в основному на вінді для цього використовую VMware який-небудь. У Azure є, наскільки мені відомо, можливість розгортати вин-сервер і віддалено підключитися до нього, начебто «віддалений робочий стіл», але сам особисто з цим не працював і не пробував навіть (прим.ред: дійсно, до Windows Server'mssql у можна підключатися за допомогою візуального інтерфейсу).

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

Мінуси:

— При ресайзе (зміну конфігурації) VM (віртуальної машини) вона повністю перезавантажується.
— Системний диск VM вкрай повільний і тому використовувати його потрібно обережно або не використовувати зовсім.
— Є великий додатковий диск, який присутній у кожній машини і з хорошою швидкістю, але він вважається тимчасовим і при перезавантаженні може обнулятиметься, тому використовувати його під чутливі дані вкрай не рекомендується (до речі, тепер Azure став про це писати скрізь, а не тільки в документації!).
— Неочевидна з першого разу для розуміння структура Cloud Services.

Плюси:

— Можна створювати, а потім використовувати власні образи (зручно для кластеризації і масштабування).
— Будь-які диски можна додати самостійно, можна навіть спосіб зробити з потрібною кількістю дисків, які будуть потім «підніматися» і «чіплятися» самостійно.
— Наявність консольної утиліти для управління інфраструктурою (зручно для автоматизації робіт по включенню/виключенню, додавання/видалення).
— Можливість створити VPN.
— Наявність інструментів для управління трафіком/навантаженням (Azure Available Sets, Load Balancing Sets, DNS Traffic Manager).

Можливо, певні речі вже давно є і у Амазона або Гугла, але я за ними поки перестав стежити, а у Azure ми всім цим користуємося і залишаємося з хорошими враженнями.

Про вартість

Azure обходиться нам зараз в \~140 тис. рублів на місяць. Цього нам вистачає на 90%, так як для пікових навантажень все ж цього мало.

Думаю, кінцева вартість для повноцінного обслуговування поточного положення справ буде близько 160-180 тис. Про навантаження на «Дарударе» відповім так:

~2.5 тис дарів і ~1.5 тис подяк на добу
~20 тис. коментарів на добу
~40 тис. повідомлень на добу
~4.5 тис. файлів (зображень) на добу

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

Пробувати тому, що це модно і «всі зараз в хмарах», не варто. Для нас (Дарудар) ключовим при виборі переходити в хмару або залишатися на collocation стала відсутність в штаті сисадміна, і тому, фактично, для нас вартість хмарного хостингу — це вартість інфраструктури + базовий адміністратор.

Про те, варто чи ні взагалі, можна багато міркувати, наприклад, так:

— Добре для проектів прям щойно трапилися і які тільки відпрацьовують свою модель;
— Добре для проектів, які розраховують жити тільки на інвестиції (мається на увазі, що при відсутності інвестицій проект закривається);
— Добре для проектів, які можуть заробляти самостійно і їм цікавий ріст і розвиток.

Про плани

Все, що нам цікаво і може плануватися до впровадження, так чи інакше призводить до vendor lock'у, вимагаючи, відповідно, обережного впровадження в проект.

1. Наприклад, дуже потрібні черзі. Думаємо над впровадженням.
2. Треба вирішити питання з медіа-сховищем. У підсумку потрібно буде перейти на повноцінне хмарне рішення (а це 100% vendor lock).
3. Дуже цікава штука, яка теж нами запланована і про яку говорив вище — управління трафіком/навантаженням (Azure Available Sets, Load Balancing Sets, DNS Traffic Manager).

Про best practices

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

Локальний диск хоч і виглядає привабливо з точки зору розміру і швидкості, і навіть, не дивлячись на попередження про те, що дані з нього можуть загубитися, може зберігати дані при перезавантаженні инстансов (!), але зберігати там критично важливі дані все ж таки помилка. Наприклад при вертикальному масштабуванні инстанса він за будь обнулиться.

Трапляється, що VM може зависнути так, що йому вже нічого не допоможе, крім перезавантаження. А іноді навіть вона може не допомогти. Тому виділення кожного внутрішнього сервісу в окремий інстанси або групу на порядок полегшує управління інфраструктурою. У зв'язку з цим навіть думки стали «хмарними»: краще перезавантажити, ніж виправити. Якщо після перезавантаження не виправилося, краще перестворювати.

Резюмуючи

Після болю і страждань при освоєнні платформи (були і такі моменти) тепер маю спокій за майбутнє інфраструктури проекту. З'явилася передбачуваність, яка дозволяє повноцінно займатися плануванням і розвитком проекту. І що ще дуже цінно: з'явилася можливість керувати інфраструктурою, не володіючи глибокими знаннями в області адміністрування, і підключати до обслуговування інфраструктури додаткових людей.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.