Google Talk представляет собой сервис мгновенного обмена сообщениями от Google. В основе этого сервиса лежит XMPP протокол, более известный как Jabber. В России среди IM-сервисов несомненно наиболее широко распространен ICQ, но количество русских пользователей Jabber тоже неуклонно растет.
Вам когда-нибудь доводилось задумываться какое количество сообщений приходится обрабатывать такого рода сервисам? Допустим есть абстрактный IM-сервис, которым пользуется миллион пользователей, в среднем каждый из них отправляет сто текстовых сообщений. Сколько всего сообщений обработал и доставил сервис? Сто миллионов? Наивно!
Введение
Сервисы мгновенного обмена на самом деле подвергаются существенно большей нагрузке, чем это может показаться на первый взгляд. Давайте взглянем на расшифровку аббревиатуры XMPP: eXtensible Messaging and Presence Protocol. Обмен сообщениями - лишь одна из его функций, наиболее важная же его часть остается "за сценой" - отображение присутствия пользователей online.
Давайте посмотрим на наш абстрактный пример с точки зрения присутствия: пускай им пользуется все тот же миллион пользователей, когда один из них включил компьютер и появился online - он должен уведомить весь свой список контактов об этом событии, а также узнать кто из них находится online. Если этот список велик, то такое элементарное событие может обернуться для сервиса далеко не одной сотней обработанных и доставленных сообщений. Помимо простого изменения статуса online/offline подобную цепочку сообщений может генерировать и любое другое изменение статуса: связанное с отсутствием пользователя около компьютера или с изменением небольшого текстового сообщения, которое обычно отображается в контакт листе рядом с ником пользователя и призвано отображать текущее его состояние, занятие или чего там только не пишут (эта функция не всегда предоставляется IM-сервисами, но наверняка многим знакома по ICQ, если не по Jabber). Все эти сообщения как раз и стоят за "presence" в аббревиатуре XMPP, суммарный траффик, ими генерируемый, может в несколько раз превышать траффик от собственно самих текстовых сообщений.
Если учесть факты, описанные в предыдущем абзаце, не трудно догадаться, что зависимость суммарного количества presence-сообщений от количества пользователей IM-сервиса далеко не линейна. Их количество за какой-то период времени можно очень приблизительно посчитать как произведение трех параметров: количества пользователей online, средней длины списка контактов среди них и количества изменений статуса каждым пользователем. А каждый дополнительный пользователь в системе так или иначе увеличивает как минимум два из этих трех параметров.
Введение несколько затянулась, а проблема масштабируемости XMPP-сервисов я думаю теперь стала очевидна, так что сейчас очень подходящий момент, чтобы вернуться к основной теме разговора - сервису Google Talk и том, как команда его разработчиков решает эту проблему.
Источники информации
Наверное уже стало заметно, что это не очередной перевод, а лично мной написанный текстик. Так что сразу выдам видео, являющееся основным источником информации, и продолжу.
Архитектура
Со стороны Google (о котором я, кстати говоря, уже писал) было бы глупо строить сервис мгновенного обмена сообщениями в стороне от остальных коммуникационных сервисов, предоставляемых этой компанией. Еще до своего публичного старта Google Talk был интегрирован в почтовый сервис GMail и социальную сеть Orkut: эти сервисы просто запрашивали у Google Talk присутствие online пользователей из своего списка контактов при возникновении соответствующих событий, но при этом не отображали результаты в своих страницах. Таким образом разработчики получили возможность оценить предстоящие нагрузки и готовность сервиса к публичному запуску намного более точно, чем они могли бы это сделать средствами синтетических тестов.
В отношении распределения нагрузок, сразу же был выбран и реализован подход, связанный с разбиением пользователей на группы и распределением работы с каждой отдельной группой по разным серверам. Это позволило избежать всей той эволюции серверной части приложения от одного сервера до большого кластера, что впрочем вполне оправданно, так как сразу же после запуска сервису предстояло столкнуться с огромным количеством пользователей и не ничуть не меньшей нагрузкой. Разработчики не забыли и сразу же предусмотреть безболезненный перенос пользователей с одного сервера на другой без видимых для него изменений, это позволило очень гибко изменять количество серверов в системе.
С точки зрения интеграции сервиса с другими проектами Google, очень важно было предоставить определенный уровень абстракции для взаимодействия в виде API и набора адресов, по которым необходимо обращаться к сервису. Придерживаясь одного API можно производить практически любые архитектурные или программные изменения в рамках проекта таким образом, что все его пользователи и проекты, в которые он интегрирован, просто не заметят что что-то изменилось. Адреса, к которым происходит обращение при обмене данных, так же являются своеобразной абстракцией - можно переместить сервис в новый датацентр и благодаря DNS трафик будет направляться в нужное место.
С другой стороны необходимо учитывать и программное обеспечение работающие ниже уровнем, чем собственно код приложения: особенно ядро операционной системы и используемые библиотеки. В данном случае большую роль играет количество открытых TCP соединений, так как IM требует большое их количество, но активность в них не велика.
Разработчики Google Talk постарались как можно больше внимания уделить возможным сбоям и связанным с ними ситуациям. Любое даже запланированное временное прекращение функционирования какой-то части системы может резко увеличить нагрузку на остальную часть, даже если это просто перезагрузка части системы - из-за очистившегося кэша серверы снова начнут полноценно функционировать далеко не сразу, не говоря уже о непредвиденных сбоях, когда последствия намного более глобальны. Для своевременного устранения потенциальных проблем как с общем функционированием системы, так и с недостаточной производительностью, ведутся логи для всех этапов обработки запросов, а также предусмотрена возможность профайлинга прямо на работающих в системе серверах.
Но не стоит забывать и о клиентской части программного обеспечения: какая-нибудь глупая ошибка в коде клиента сервиса запросто может устроить DDoS атаку на сервис, что и случилось с одной из ранних версий клиента Google Talk. Помимо этого необходимо поддерживать совместимость разных версий клиентских приложений.
Заключение
Благодаря описанным выше принципам Google Talk удается обрабатывать каждое из миллиардов сообщений в день менее чем за 100 миллисекунд. Тесная интеграция с другими сервисами Google позволила проекту сразу же получить невероятную популярность, а продуманный подход к разработке сервиса позволил справиться с огромной нагрузкой.
На этот раз статья получилась скорее о специфике сервиса, чем о его реализации. Технической информации найти практически не удалось, так что очень кратко все, но надеюсь и в таком варианте было достаточно интересно почитать. Напоследок хочу порекомендовать подписаться на RSS, если не хотите пропустить публикацию новых постов.
