Ссылку на презентацию пока не нашел, надеюсь никто не расстроится если я запосчу тут этот лог
.<<< [15:56:16] gnoblin: по презенташке Zynga:
[15:56:35] gnoblin: в день в их игры играет 65 млн человек. за месяц 225 млн уникальных игроков
[15:57:14 | Изменены 16:01:02] gnoblin: первая игра которую они приводят в пример за одни выходные выросла до 1 млн DAU (facebook я так понял)
[15:57:34] gnoblin: это чел говорит про scalability challеnges
[16:00:51] gnoblin: unique daily active users (DAU)
[16:01:28] gnoblin: вторая игра которую приводят в пример - за неделю до 6 млн DAU
[16:03:02] gnoblin: (вторая игра) фармвиль - через 5 месяцев уже 25млн DAU. Чел говорит что софт и инфраструктура должны быть готовы к таким нагрузкам
[16:14:28] gnoblin: zynga-чел в разделе game architectures говорит что у них есть два подхода к созданию клиента и два подхода к созданию сервера
[16:17:00] gnoblin: server side: (1) "web stack". Usually based on LAMP stack. Game logic in php. HTTP communication. Пример - farmville.
[16:17:42] gnoblin: (2) "mixed stack". Game logic in MMO server (напр. Java). Web stack for everything else.
[16:17:58] gnoblin: Пример - Yoville.
[16:18:34] gnoblin: LAMP - linux\apache\mysql\php
[16:22:11] gnoblin: Пример FishVille: "DB Servers \ Cache & Queue Servers" <-> "Web Servers + CDN" <-> FishVille
[16:23:18 | Изменены 16:23:26] gnoblin: Пример YoVille: та же схема только на втором этапе к webservers еще добавляется MMO Servers
[16:24:30] gnoblin: отдельно сервера с БД
[16:24:39] gnoblin: отдельно сервера для кеширования и очереди какой-то
[16:24:42] gnoblin: хз что это).
[16:27:19] gnoblin: слайд "Why web stack?":
1) HTTP scales very well.
2) stateless request\response.
3) easy to load balance across servers.
4) easy to add more servers.
some limitations:
1) server initiated actions
2) storing state between requests.
[16:28:55] gnoblin: балансировать он говорит хорошо http потому что запросы между собой не связаны особо
[16:30:11] gnoblin: some limitations:
1) server initiated actions тут он имеет ввиду что запустить какой-то экшн с сервера сложно потому что тут модель взаимодействия больше идет request-response
[16:36:02] gnoblin: говорит что нужно снижать частоту запросов к БД чтобы сервер не загнулся. Предлагает строить поверх БД cache layer и обещал чуть позже рассказать про какой-то network attached memory
[16:37:34] gnoblin: слайд "MMO servers" пропускаю, там ниче интересного
[16:39:29] gnoblin: тут он говорит что в отличие от web stack подхода тут мы уже game state можем просто хранить в памяти
[16:40:59] gnoblin: про вебстек он только говорил что нужен кеш-слой для бд если все делается через вебсерверы
[16:42:21] gnoblin: часть игр они делают на флеше, а часть html+ajax
[16:44:54] gnoblin: говорит что в соцсети интегрировать легко, с той точки зрения что проблем с scalability тут нету. Соц сети предоставляю REST APIs или client libraries
[16:48:09] gnoblin: часть 2. Scalability.
[16:48:28] gnoblin: два подхода: scaling up, scaling out
[16:49:29] gnoblin: up: куплю более мощную железку, out: куплю еще железок
[16:50:25] gnoblin: так вот он говорит что второй подход правильный
[16:50:41] gnoblin: но тут надо чтобы архитектура поддерживала это изначально
[16:52:25] gnoblin: пример: одна их игра когда запускалась имела одну БД что в итоге и стало bottleneck'ом
[16:52:38] gnoblin: там у них за неделю набежало 500к daily players
[16:53:41] gnoblin: 4 элемента масштабирования которые он расписывает: database, caching, game servers, capacity planning
[16:53:57] gnoblin: тут зависит от подхода и целей - надо гарантии стабильности работы или масштабность потребляемого электричества ?...а?
[16:54:57] gnoblin: говорит что БД валится у них обычно самой первой
[16:55:37] gnoblin: что это самая уязвимая часть
[16:57:28] gnoblin: они юзают mysql
[16:58:37] gnoblin: "все начинают обычно с одной БД. Тут есть проблема с количеством запросов в секунду которая БД может обработать."
[16:59:39] gnoblin: приводит пример одной тулзы которую они для бенчмарка БД использовали SmartSmack что-ли - не расслышал
[17:01:45] gnoblin: еще чел говорит что кроме бенчмарка БД важно знать какое количество каких запросов будет вызывать средний игрок
[17:04:30] gnoblin: 3 подхода к скейлу БД: 1) replicating data to read-only slaves
[17:04:59] gnoblin: master\slave в терминах mysql, не знаю как в оракле )
[17:05:30] gnoblin: говорит что этот подход для игр не катит
[17:06:07] gnoblin: т.к. например для выдачи вебстраничек это катит - отдаем инфу
[17:06:19] gnoblin: а игры обычно связаны с изменением профиля игрока, к примеру.
[17:06:39] gnoblin: т.е. все равно master БД станет узким местом с таким подходом
[17:07:15] gnoblin: 2) multiple master setup
[17:07:41] gnoblin: но тут есть consistency resolution problem
[17:08:58] gnoblin: второй подход тоже им не нравится
[17:09:51] gnoblin: 3) database sharding. Когда на уровне игрового сервера известно какие данные в какую независимую базу должны пойти
[17:10:45] gnoblin: ну или там еще какой-то промежуточный слой вводится который рулит что куда писать
[17:12:45] gnoblin: "How to partition data":
1)Vertical - by table.
Easy but does not scale up.
2) Horizontal - by row.
Сложнее сделать, но круче.
Different rows live on different DBs.
Need a good mapping from row # to DB
[17:13:07] gnoblin: sharding==partitioning
[17:22:14] gnoblin: говорит что главный challenge был грамотно разбить огромный dataset по горизонтали и вертикали ))
[17:22:41] gnoblin: "With sharding you need to know shard ID for each query!"
[17:24:49 | Изменены 17:26:11] gnoblin: Sharding surprises: (1) "be careful with joins". Can't do joins across the shards. Instead, do multiple selects or denormalize your data
[17:26:50] gnoblin: не делать его для данных которые находятся на разных шардах).
[17:28:55] gnoblin: Sharding surprises:
(2) "skip transactions and foreign key constrains"
- CPU expensive; easier to pay this cost in application layer (just be careful)
- чем больше вы держите в RAM, тем меньше они\это вам понадобятся
[17:32:36] gnoblin: memcached: network attached RAM cache
[17:33:17] gnoblin: радуется, говорит опенсорс и популярная
[17:34:53] gnoblin: Memcache.
хранит пары ключ-значение.
Кладем сюда structured game data & mutexes for actions across the servers
[17:35:30 | Изменены 17:35:40] gnoblin: минусы:
это LRU кеш, а не БД!
No persistence!
[17:40:21] gnoblin: чел говорит что в memcached забавный момент это то что по всем значениям нельзя пробежаться)
[17:49:51] gnoblin: memcached тоже чел предлагает шардить
[17:50:55] gnoblin: на разные сервера бить чтоле
[17:51:03] gnoblin: я не знаю как мемкешд выглядит
[17:51:15] gnoblin: ну как куча серверов с БД - та же самая ситуация
[17:51:16] gnoblin: тонкий момент с мемкешдом я так понял в том что нужно успеть записать данные из него в БД пока он не переполнился и важные данные не вытолкнул
[17:53:55] gnoblin: данные из него в БД пока он не переполнился и важные данные не вытолкнулну это по-умолчанию кеш
[17:54:28] gnoblin: что происходит когда ты пихаешь слишком много данных в него? он переполняется и освобождает по определенному алгоритму в себе место
[17:57:44] gnoblin: про БД в презенташке закончили, теперь речь про серверы пошла.
[17:58:32] gnoblin: балансировка. первый способ - через прокси.
[17:59:54] gnoblin: и как апгрейд этой схемы: много load balancers(LB)+DNS LB
[18:01:44] gnoblin: scaling content delivery: между webserver и client гоняем только game data, а media files как-то в обход через CDN идут
[18:10:48] gnoblin: да! подкачивать ассетбандли с отдельного сервера идея интересная
[18:12:53 | Изменены 18:13:01] gnoblin: в общем в презенташке рекомендуется так бить разнообразные серверы чтобы они были независимыми друг от друга для более крутой масштабируемости всей архитектуры в целом
[18:32:23] gnoblin: minimize inter-server communication
[18:32:34 | Изменены 18:32:47] gnoblin: all live events should take place on the same server
[18:34:48] gnoblin: говорит о том что для каждой игры можно рассчитать стоимость "лежащего" сервера в $\мин.
[18:39:00] gnoblin: чел говорит что спрос на игру может расти скачками, поэтому нужно что-то иметь про запас чтобы не сесть в лужу
[18:39:39] gnoblin: говорит о двух вариантах (размещения серверного ПО?): colocation и cloud
[18:41:01] gnoblin: написано что в случае с облаком добаить еще серверов можно достаточно быстро при необходимости
[18:42:54] gnoblin: Чел говорит о том что они используют несколько инструментов для наблюдения за кучей своих серверов.
[18:43:16] gnoblin: какой-то custom dashboard - я так понял куча реалтаймграфиков о том что происходит на серверах
[18:45:20] gnoblin: еще две проги упоминает: Munin & Nagios
[18:45:32] gnoblin: http://ru.wikipedia.org/wiki/Nagios
[18:45:37] gnoblin: http://en.wikipedia.org/wiki/Munin_%28n ... ication%29
[18:48:17] gnoblin: прикольно. Можно выставлять алерты на снижение каких-то показателей, в том числе business показателей, типа DAU
[18:48:19] gnoblin: )
[18:48:36] gnoblin: если ваш сервер вырубился - вам приходит печальная смска))
[18:49:30] gnoblin: еще чувак говорит о том что в архитектуре не должно быть одного сервера убив который мы можем сломать игру)
[18:49:55] gnoblin: т.е. сделать ее недоступной для пользователей
[18:52:49] gnoblin: Чел говорит что они используют мускул просто потому что особо крутых фишек не используют у себя). Транзакции например не используют, потому что им легче вынести это на application layer
