Андрій Шетухін: Добрий день, мене звати Андрій Шетухін, я з компанії "Рамблер". Перед тим як почати, хотілося б задати одне питання. Ось всі кажуть: "Рамблер помер, Рамблер помер". Скажіть, будь ласка, у кого є проект з обсягом даних більше терабайта? Більше 10 терабайт? Більше 100 терабайт? Петабайт? Відмінно!

Про що хотілося б поговорити?

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

Що зараз являє собою наша пошта?

• Це 1 петабайт даних (зараз трохи більше).
• 100 мільйонів ящиків, з яких 30 мільйонів використовуються постійно. Постійно - це значить частіше, ніж раз в 3 місяці.
• Щомиті ми обробляємо приблизно 3 000 запитів по HTTP. Я навіть важко сказати, скільки SMTP-сесій ми тримаємо одночасно. Їх, мабуть, десятки тисяч. Хто їх рахує ...
• Призначена для користувача аудиторія складає приблизно 5 мільйонів користувачів в тиждень.

Що, власне, було?

Я розумію, що "Рамблер" - це така штука, яку ніхто не ходить, тому я зробив знімок, щоб показати, що було. Було приблизно ось що. Це щось на зразок сайту "в стилі" Web 1.0, на якому можна було щось почитати, щось відправити. Як зазвичай...

Що стало? Ми зробили це веб-додатком.

Чому ми зробили так?

У кожного проекту є своя місія. Рано чи пізно місія старого проекту закінчується. Іноді можна далі поліпшувати старе. Сюди можна було, звичайно, "прикрутити" AJAX, ще щось, але це вже не працює - світ змінився.

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

Що було зроблено?

Був зроблений головний вибір між двома альтернативами "веб-додаток" і "звичайний сайт".

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

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

Веб-додаток "Рамблер-Пошта" займається саме цим. Ми маємо невелике (маленьке) ядро, яке дуже-дуже швидко обробляє багато запитів і "важкий" клієнт, який щось показує користувачеві. Він показує це дуже спритно. У цьому можна переконатися, просто зайшовши на новий сайт email.rambler.ru.

Чим відрізняється розробка веб-додатки від розробки звичайного сайту?

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

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

Веб-додаток розробляється зовсім інакше.

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

Якщо у вас є хороші дизайнери інтерфейсів, ви зробили половину роботи. Коли розробляють концепцію звичайного сайту, часто говорять: "Давайте щось зробимо, запрограмуємо, а потім на нього натягнемо дизайн - злетить / НЕ злетить". Це не правильно. Це вже не працює.

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

Чому хочеться розповісти саме про це? Тому що більшість сайтів в Рунеті виглядають приблизно так: "Давайте ми зараз зробимо якийсь сайт, а потім на нього навіс AJAX". Зазвичай після цього виникають проблеми: нічого не працює, не кешуються дані, сайт відповідає дуже повільно.

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

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

Twitter раніше було написаний на Ruby, а потім там все поміняли.

Важливі три неважливих дрібниці:

• деплоймент (розгортання);
• статистика;
• моніторинг.

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

Зрозуміло, що якщо у вас один сервер, куплений де-небудь в "Masterhost" за 10 доларів в місяць, - це одне. Якщо у вас серйозний бізнес, то має сенс спочатку приділити увагу дрібницям.

Отже, почнемо з цих самих дрібниць.

Розгортання (деплоймент)

Здавалося б, програмісти написали код і віддали його адмінам. Адміни його "викотили". Чи буде це працювати? Практика показує, що він не працює. Зазвичай програмісти, коли пишуть код, мають на увазі зовсім-зовсім не те, що хочуть бачити адміни.

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

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

Чи не винаходить велосипед!

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

Хотілося б наголосити, що код і конфігурація - це різні речі. Наприклад, "Рамблер-Пошта". У нас стоїть Ubuntu Server. Напевно, багато хто з вас чули дискусії з приводу FreeBase проти Ubuntu. Справа минуле. У нас стоїть Ubuntu Server, і "розкочування" проводиться за допомогою стандартного менеджера пакетів.

Не треба винаходити велосипеди! Свій велосипед, звичайно, їде, але не дуже добре.

Користуйтеся всім тим, що пропонує вам операційна система. Вона може бути будь-хто. Я ні за Ubuntu, ні за CentOS. Може бути, FreeBase теж дуже непогана, не знаю.

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

Висновки дуже прості.

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

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

Крім усього, максимально автоматизуйте процес. Стара версія "Рамблер-Пошти" "жила" приблизно на 200 серверах. Нова "живе" на 10 серверах бізнес-логіки. Вона "розкочувалася" за допомогою всемогутнього скрипта типу "все запустити". Через нього вручну передавали список серверів, на яких потрібно було "все запустити" і команду.

Все це було б смішно, якби люди не помилялися. Рано чи пізно це закінчувалося тим, що третина кластера відключалася. Так ось: це неправильно. Потрібно робити не так. Потрібно робити систему "розкочування" такий, щоб помилка там "де-факто" була неможливе.

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

Щодо статистики. Статистика - це така штука, про яку говорять: "брехня".

Або "велика брехня".

Ось так навіть говорять:

Ще говорять, що це просто статистика.

Це правда. Статистика - це велика брехня, коли ви отримуєте цифри, не знаючи, що вони означають. Якщо ви щось вважаєте, завжди необхідно розуміння, що і як працює. Ми поставили Google Analytics на нову пошту, і раптом з'ясувалося, що відсоток відходу користувачів, які провели на проекті від 0 до 10 секунд, приблизно 60%. Це було жахливо! Це означало, що нову пошту треба закрити.

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

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

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

Завжди вибирайте певний невелика кількість значущих параметрів, які вам потрібні для статистики, а решта пишіть в логи, тому що минулого не повернути. Але якщо у вас в логах записано час звернення, швидкість обробки запиту, час першого, другого, n-ного звернення до сайту або ще що-небудь, ви завжди зможете відновити необхідні вам параметри.

Погано ось так. Це приладова дошка літака.

Добре ось так, коли є кілька фундаментальних графіків, з яких все зрозуміло.

Про графіки.

Що має сенс вимірювати?

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

Скільки користувачів отримують сервіс за певний час?

Дивіться, у нас є зелений графік. Він показує середнє значення. Показ листи відбувається в середньому за 200 мілісекунд. Це миттєво. Швидкість реакції людини - приблизно 400 мілісекунд. 90% листів показуються за час менше 0,5 секунди. Це дуже добре. Це означає, що 9 з 10 листів ви побачите миттєво. 95% листів показується під час менше секунди.

Зрозуміло, що якщо вам прислали лист розміром 50 мегабайт, показати його швидко не вдасться, тому що потрібен якийсь час для передачі даних. Треба розібрати лист, перевірити, що в ньому не так (раптом вам XXS підсунули).

Важливо, що ми розуміємо - є середній час. Воно ні про що не говорить. Є статистика, що 9 з 10 листів ви побачите миттєво. Решта можуть трохи "пригальмовувати".

Графік інформативніше. Середнє значення ні про що не говорить. Тут не видно, правда: іноді середнє вище, ніж 90% користувачів бачить. Це теж нормально. Статистичний розподіл - така штука, що результати можуть бути якими завгодно.

моніторинг

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

Робиться це приблизно наступним чином. Якщо у вас новий проект, то з цим є деякі складності. Напевно, має сенс поставити якийсь тестовий стенд, на якому відображено погану поведінку сайту: десь щось "гальмує", тому що йому дали мало пам'яті або процесорного часу. "Віртуалкою" зараз дуже добре працюють, можна "задавлівать" будь-параметр. Варіюючи ці параметри, можна з'ясувати, що у нас працює не так. Коли у нас щось працює не так, як треба, можна з'ясувати, які параметри за це відповідальні. Власне, ці параметри і варто моніторити.

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

А ось дискова чергу, навпаки, важлива. Завжди вибирайте з безлічі параметрів ті, які ви зможете моніторити за допомогою Nagios, ZABBIX (кому що хочеться). Вони описують поточне поведінку системи. Решта не потрібно, тому що воно тільки відволікає службу підтримки або вас, якщо ви є в одній особі і розробником, і службою підтримки.

Дуже погано, коли вам хтось подзвонив, а телефон кожні 30 секунд починає пищати "вам дзвонили", "вам дзвонили". Те ж саме, але набагато гірше відбувається з моніторингом. Чи не треба відправляти повідомлення про проблеми з кожного приводу! Надсилайте їх тільки для самих фатальних і трохи менше фатальних помилок.

Якщо у вас десь кінчається місце, про це треба кричати тільки коли зовсім все погано. Не треба починати писати в службу підтримки, що "у нас 50% місця залишилося", "49%, 48%" і далі 50 разів поспіль, поки все не закінчиться.

Люди відволікаються. Це призводить до того, що стає неможливо нормально відстежувати дійсно важливі проблеми. Чим менше інформаційного шуму, тим краще.

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

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

Корінь проблеми не в бізнес-логікою, а в тому, що один сервер недоступний.

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

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

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

Репліка із залу: Ви сказали, що використовуєте менеджери пакетів і операційні системи сервера.

Андрій Шетухін: Так.

Репліка із залу: У вас є 10 серверів додатків. Ви на них робите викладку нового релізу. Як ви забезпечуєте синхронність викладки, щоб всім користувачам все стало доступно в один і той же момент часу? Або для вас це неактуально?

Андрій Шетухін: Це актуально. Це дуже важливий момент. Робиться це в такий спосіб. Ми спочатку "ставимо" пакети, а потім по черзі (тобто досить швидко) перенавантажуємо на сервери додатки. Пакети можуть "ставитися" протягом певного часу - нехай навіть декількох хвилин - послідовно.

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

Так, іноді буває так, що все зовсім-зовсім погано - потрібно поправити фатальну помилку. Протягом 20 секунд сервіс буде недоступний. Це не так страшно, що помилка, через яку можуть "пропхати" XXS або що-небудь схоже.

Репліка із залу: У вас нова версія ставиться поруч зі старою, і потім відбувається перемикання?

Андрій Шетухін: Вона ставиться пакетом, після чого сервер додатків перезавантажується. "Опускається / піднімається". Так, спереду стоїть Nginx, який вміє це нормально "розрулювати", балансуючи, навантаження. При цьому користувач не бачить "404".

Репліка із залу: Чи можна дізнатися, на чому у вас написано сервер додатки, який запускається через 20 секунд?

Андрій Шетухін: На Сі ++. Запускається він на Apache 2.2. Загалом, Fast CGI back-end ми почали було писати, але з'ясувалося, що це безглуздо. Правильно налаштований Apache цілком непогано обробляє 8 000 запитів в секунду на одній машині.

Репліка із залу: Як у вас влаштована інфраструктура "staging" - пре-продакшн-тестування? Що використовується?

Андрій Шетухін: Пре-продакшн виглядає наступним чином. У нас є сервери розробки. Вони знаходяться на "віртуалкою". Це дуже кльово і здорово: якщо хтось напартачив або щось "вбив", то виртуалка "піднімається" за 15 секунд. Просто кажеш: "Переподніміте" мені її ". Вона" піднімається ". Це KVM.

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

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

Перший. Звичайний сервер для тестувальників.

Другий. Повний варіант продакшн, який не видно зовні.

Репліка із залу: Можна трохи докладніше про те, чому сисадміни не повинні лізти в архітектуру до програмістам, адже з їх боку багато технічні моменти видно краще.

Андрій Шетухін: Неправда! Чи не видно вони краще.

Репліка із залу: Чому?

Андрій Шетухін: Якщо ви допускаєте ситуацію, коли у вас є програмісти і сисадміни, то далі починається втрата точки відповідальності. За проект повинен бути відповідальний одна людина. Я знаю багато проектів - я працював в одному з провідних операторів стільникового зв'язку, де відповідальними за проект були саме сисадміни, тому що їм поставлено якесь ПО, який чіпати було не можна. Це Було добро.

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

Програмісти чогось писали, сисадміни чогось "викачували". Коли все впало, не можна було знайти того, хто винен. Це дуже погано. Це фатально! Навіть не для того, щоб покарати когось, а просто для того, щоб з'ясувати, в чому проблема.

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

Репліка із залу: На графіках, по-моєму, був ZABBIX.

Андрій Шетухін: Ні.

Репліка із залу: Ні? Цікаво, як ви збираєте по Квантиль? У вас є окремий демон, який збирає статистику?

Андрій Шетухін: Так, ми написали окремий демон, який вміє рахувати статистику. Йому по UDP "скидається" час запиту відповіді від будь-якого XML-RPC або ще чого-небудь іншого, що потрібно. За допомогою JavaScript і empty.gif (улюбленого модуля Nginx) можна порахувати швидкість завантаження сторінок. Туди теж "скидається".

Відповідно, він вважає якусь статистику і малює квантилі.

Репліка із залу: Як ви зберігаєте петабайт даних?

Андрій Шетухін: Ну, як ... В файлах. Конкретизуйте.

Репліка із залу: розподілу? Як реплікація зроблена? Це WebDAV з HTTP і синхронними демонами реплікації?

Андрій Шетухін: Все набагато простіше. Я взагалі не бачу сенсу в застосуванні чогось складного, тому що складні речі зазвичай складніше лагодити. Простим речам ніде ламатися, і чиняться вони на ура. Все виглядає наступним чином. Є рейт 1 (дзеркало), де лежать файли. Усе. Воно працює.

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

Репліка із залу: У вас реально не було жодного моменту, коли фізичний сервер виходив з ладу?

Андрій Шетухін: Виходив багато разів.

Репліка із залу: Але тоді у користувача немає цих даних.

Андрій Шетухін: Чому? Послухайте, в сервері 12 дисків. Ви вважаєте, що всередині нього вибухнула маленька нейтронна бомба? Ні звичайний.

Репліка із залу: Блок живлення вийшов з ладу, два блоки живлення вийшли з ладу! У мене сто раз було таке.

Андрій Шетухін: Коли два блоки живлення поспіль виходили з ладу?

Репліка із залу: Так.

Андрій Шетухін: Купуйте не в Kraftway.

Репліка із залу: Ок. Я зрозумів.

Репліка із залу: У вас "heavy web application reach"?

Андрій Шетухін: Так.

Репліка із залу: Відбувається наступне. Стандартна ситуація: людина відкрила "Рамблер-Пошту". Сидить там 3 дні, а на другий день трапився реліз саме на сервері додатків. Як ви вирішуєте таку ситуацію?

Андрій Шетухін: перезавантажити, і все. Інша версія статики завантажиться.

Репліка із залу: Як це фізично відбувається?

Андрій Шетухін: Фізично - в шляхах для статики є номер релізу.

Репліка із залу: Для цього мені треба сторінку перезавантажити. Я цього просто не роблю. Ви примусово перезавантажувати? Якщо так, то за яких подій.

Андрій Шетухін: Вона перезавантажується по наступних подій. N-ну кількість простою великого. Коли все зовсім-зовсім погано (треба перезавантажити), то можна просто подія написати: "Давайте перезавантажити сторінку".

Репліка із залу: Ви можете прямо з сервера послати подія всім клієнтам: "Пора перезавантажитися"?

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

Репліка із залу: У цей момент пік навантаження ви витримуєте?

Андрій Шетухін: Так пік навантаження припадає на сервери статики.

Репліка із залу: Ні, чому на сервери статики? Перезавантаження сторінки, по крайней мере, перезапроса весь список листів.

Андрій Шетухін: Вони візьмуться з кешу.

Репліка із залу: Як раз про це було питання. У вас є багаторазовий запас на випадок, якщо всі клієнти раптом перезавантажити по релізу?

Андрій Шетухін: Щодо кеша. У кеші зберігається 1/10% всіх даних. Даних у нас петабайт, а кешу терабайт. Цього цілком вистачає, якщо правильно інвалідіровать кеш і зберігати в ньому правильні дані. Тоді все добре.

Це таке відволікання. Є 90% програмістів PHP, які дуже люблять робити сериализацию на основі хешу від вхідних даних, а потім хеш від вхідних даних є ключем в memcache. Після цього вони роблять йому TTL 15 секунд, 15 хвилин, день, або ще скільки-небудь, а потім дивуються: як же так - в rss-стрічці у нас одне, а в реальних даних - інше.

Є такий сайт roem.ru, де "убиту" новина легко знайти в rss. Ні, roem.ru - дуже хороший сайт, чудовий! Але з кешуванням не пощастило.

Репліка із залу: Це робиться спеціально.

Андрій Шетухін: А, спеціально? Добре. Чудово. Відмінно! Будь ласка, збільште TTL на годину!

Якщо серйозно, то кешування - це невід'ємна частина системи. Або ви розробляєте її разом з основною бібліотекою (з ядром системи), або у вас проблеми. Відповідно, якщо все зроблено нормально, то приблизно 1/10% кеша вистачає. У разі чого, коли потрібно швидко оновити всіх клієнтів, система витримує.

Репліка із залу: Які бібліотеки Сі ++ ви використовуєте?

Андрій Шетухін: Я вже, напевно, 2 або 3 доповіді зробив з приводу сервера додатків. Деякий час назад великим колективом програмістів був розроблений сервер додатків Сі ++. Це ядро ​​системи, яке вміє швидко-швидко брати щось з бази даних (наприклад, IMAP, MySQL, Memcached) і швидко-швидко це справа віддати назовні або по JSON-RPC або по XML-RPC, або по HTTP за допомогою якогось шаблонізірующего движка.

Всі інші бібліотеки більш-менш стандартні. Не знаю ... Давайте, я розповім з приводу того, що XML ми Парс Lib Expat. IMAP-підключення ми обробляємо Lib IMAP. Що ще? Memcached обробляється через LibEvent або Memcached, який є в пакетах Ubuntu.

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

Власне, вся принадність веб-додатків і полягає в тому, що вся робота проводиться на клієнті, а не на сервері. Так, можна взяти Apache - "запхати" на нього 8 000 запитів в секунду. Він не впаде, притому що на сервері Core 2 Duo (чогось не пам'ятаю там), по-моєму, 12 гігабайт "оперативки" всього. Проте, туди можна "запхати" таку кількість запитів, і все буде працювати.

Чим хороші веб-додатки? Вони хороші тим, що серверів мало, а клієнтів багато. Так давайте клієнтам дамо роботу, а сервери розвантажимо!

Репліка із залу: Андрій, у мене два питання. Один про веб-додатки. Що ви думаєте з приводу старих клієнтів? Будете ви для них робити якусь окрему версію? Куди вони будуть ходити? Той же IE6 і ще більш тупі браузери (наприклад, на старих телефонах).

Друге питання я відразу задам: він стосується приводу архітектури зберігання. Петабайт ж не водночас виник. Він за багато років накопичився. Міняли ви архітектуру зберігання? Якщо так, то як мігрували. Якщо немає, то молодці.

Андрій Шетухін: З приводу другого питання. Міграція - це дуже-дуже складно, тому правильний вибір - це не мігрувати. Тобто, не зовсім так. Замінювати ПО, звичайно, треба, а ось мігрувати не варто. Приблизно півтора роки тому ми були змушені написати з нуля IMAP. Якщо все буде зовсім добре, і сильно пощастить, то, може бути, ми ... Я не впевнений в цьому, тому що це вирішую не я, але я особисто цілком "за", щоб ця штука стала відкритим рішенням.

У ній нічого складного немає. На мій погляд, в тому, щоб написати SMTP IMAP сервер, нічого складного немає. Складніше зробити так, щоб він швидко працював. Напевно, ми будемо готові його випустити в Open Source. Ми фактично написали повний аналог, скажімо так, іншого ПО, яке деякий час у нас працювало (це було давно і неправда, ясна річ), таким чином, щоб не потрібно було мігрувати. Щоб йому потрібно було "прибити" старий демон і "підняти" новий, а він поруч побудував індекси.

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

Репліка із залу: Індекси нові, а сховище старе?

Андрій Шетухін: Ні, не так. Є така штука як mailbox, де кожна папка (IMAP) - це фактично листи, "склеєні" послідовно (найближчі в одному файлі). До нього збоку є деякі індекси.

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

Так, щодо першого питання. Ще раз можна його нагадати?

Репліка із залу: Що ви думаєте щодо версії для старих слабких браузерів, для тупих мобільних браузерів?

Андрій Шетухін: Якщо дуже пощастить, і все буде добре з дизайнерами, з розробкою і проектувальниками інтерфейсів, то до липня, напевно, все буде.

Репліка із залу: Я розумію. Я маю на увазі, як це буде реалізовано з технічної точки зору? Там же не зробиш веб-додаток.

Андрій Шетухін: Це не буде ніяк відрізнятися взагалі.

Репліка із залу: Це буде все одно додаток Web 1.0.

Андрій Шетухін: Ні, це буде статика, мабуть. Але з точки зору системи відрізнятися вона не буде ніяк зовсім. Просто зовні поставимо ще 2-3 сервера front-end, на яких за допомогою шаблонізатора і через XML-RPC дані будуть збиратися в єдину статичну сторінку.

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

Репліка із залу: Буде просто якийсь front-end, який все збирає перед цим?

Андрій Шетухін: Так. При цьому ядро ​​системи взагалі ніяк не буде змінено.

Репліка із залу: Зрозуміло.

Андрій Шетухін: Дописувати практично нічого не потрібно. Треба намалювати і, боже мій, провести тест на юзабіліті.

Репліка із залу: Андрій, я знаю, що у вас для серверної шаблонізаціі використовується CTPP. Що у вас використовується для клієнтської шаблонізаціі? Як ви це робіте?

Андрій Шетухін: Фактично шаблонізаціі на стороні клієнта немає. Є JavaScript, який отримує JSON-відповідь і малює все, що є. Все, що ви бачите.

Репліка із залу: Так, а малює щось він що? Як ви з JSON отримуєте HTML або XML?

Андрій Шетухін: Є якийсь jQuery, над яким є якась надбудова. Конкретизуйте питання - в чому проблема. Писали ми щось інше? Ні, не писали.

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

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

Репліка із залу: Гаразд, спасибі.

Репліка із залу: Можна питання в продовження попереднього. У вас, як я розумію, шаблонізаціі йде не тільки на клієнті, але спочатку на сервері все малюється (HTML)?

Андрій Шетухін: На сервері малюється наступна річ. При першому заході малюється обв'язування. З'ясовується, що за браузер. Завантажуються до нього хакі CSS і хакі JS. Пишеться топ-лайн зі списком листів, наскільки я пам'ятаю. Для рендеринга листи, що показує, що всередині (не можна ж на клієнта передавати не зрозумій що), використовується ще один шаблон. Фактично серверних шаблонизатор там дуже-дуже мало.

Репліка із залу: Виходить, у вас є перетин - одні й ті ж шаблони реалізовані на клієнті і на сервері?

Андрій Шетухін: Ні, навіщо. Грубо кажучи, є Index: Templates і Message: templates. Усе. Більше Нічого нема. Все інше малює JavaScript. Якщо у вас відключений JavaScript, ви не побачите сайту. Ну що зробити. Якщо у вас відключений JavaScript, ви невдаха, і вас менше 0,5%.

Таке буває. Ну що робити.

Репліка із залу: Shit happens.

Андрій Шетухін: Так, shit happens. Це до питання про те, чи варто робити щось для IE6. Всі говорять: "IE6", "IE6", "спадщина", "це важливо". Давайте подивимося статистику! Ми побачимо, що в ній iPad в два рази більше, ніж IE 6. Мабуть, потрібно зробити версію для iPad, щоб заробити ті ж самі гроші, а IE6 просто не підтримувати. Тому що є ще і IE5, і OS / 2, але кого це хвилює?

Репліка із залу: Дякую ...

Андрій Шетухін: У нас є графіки по швидкості, в тому числі зведені. Їх багато. Тут треба дивитися в кожному конкретному випадку. Ще я привів 4 фундаментальних графіка - це серверна частина.

Репліка із залу: Це час відповіді на AJAX-запит?

Андрій Шетухін: Так. Наприклад, зверху ми бачимо квантиль 90% -ний. Максимум у нього 420 мілісекунд, а мінімум у нього 340 мілісекунд. Фактично, це взагалі ніяк не залежить від відвідуваності. Визначальною швидкістю є швидкість доступу до диска. Це логічно, тому що лист ми в тому чи іншому вигляді забираємо з диска. З такою середньою швидкістю працює доступ до диска.

Що тут ще є? Поставити прапор: прочитано / не прочитане, отвечено або ще що-небудь, важливість.

Фактично ці 200 - 300 мілісекунд - це і є швидкість доступу до індексу.

Репліка із залу: Які ключові показники ви використовуєте в статистиці, крім часу відповіді?

Андрій Шетухін: Статистика різна буває. Є статистика, яка показує, "живий" проект чи ні з точки зору розробника. "Впав" сервер back-end, злетіло час відповіді. Це один тип статистики. Є тип статистики - скільки людей прийшло, скільки людей пішло (це дає Google Analytics) ...

Репліка із залу: А для продуктивності?

Андрій Шетухін: Що стосується продуктивності ... На мій погляд, для кожного проекту (причому чим більше проект, тим це правильніше) завжди необхідно шукати власні показники. Для пошти таких показників два. Дуже важлива швидкість показу списку листів в папці, тому що це основне, що робить користувач. Також важлива швидкість перегляду листи.

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

Для будь-якого сайту соціальної активності (типу "віддам що-небудь" або якого-небудь аукціону), мабуть, кількість ставок. Це треба дивитися в кожному конкретному випадку. Не можна так відразу сказати. Кожен проект унікальний.

Репліка із залу: Дякую.

Репліка із залу: Андрій, скажіть, будь ласка, скільки людей і тварин постраждало при розробці нової пошти "Рамблера"?

Андрій Шетухін: Експерименти на людях не проводилися.

Репліка із залу: Дякую!