https://www.insight-it.ru/Fri, 08 Feb 2008 22:41:00 +0300https://www.insight-it.ru//highload/2008/arkhitektura-flickr/<p><a href="https://www.insight-it.ru/goto/f50a76e1/" rel="nofollow" target="_blank" title="http://www.flickr.com">Flickr</a> является мировым лидером среди сайтов размещения фотографий. Перед Flickr стоит впечатляющая задача, они должны контролировать обширное море ежесекундно обновляющегося контента, непрерывно пополняющиеся легионы пользователей, постоянный поток новых предоставляемых пользователям возможностей, а делается все это при постоянной поддержке отличной производительности. Как же они это делают? <!--more--></p> <h3 id="istochniki-informatsii">Источники информации</h3> <p><em>Как и предыдущий пост <a href="https://www.insight-it.ru/highload/2008/arkhitektura-google/">"Архитектура Google"</a>, этот тоже является переводом <a href="https://www.insight-it.ru/goto/e7a0ee0d/" rel="nofollow" target="_blank" title="http://highscalability.com/flickr-architecture">статьи</a> от <a href="https://www.insight-it.ru/goto/f3f1b405/" rel="nofollow" target="_blank" title="http://highscalability.com/user/todd-hoff">Todd'а Hoff'а</a>. Возможно читателям <a href="/tag/google/">Google</a> был более интересен, но подход Flickr к масштабируемости тоже более чем заслуживает внимания. Далее привожу источники информации из оригинальной статьи:</em></p> <ul> <li><a href="https://www.insight-it.ru/goto/88014756/" rel="nofollow" target="_blank" title="http://www.niallkennedy.com/blog/uploads/flickr_php.pdf">Flickr и PHP</a> (ранний документ)</li> <li>Планирование нагрузок на LAMP</li> <li><a href="https://www.insight-it.ru/goto/6df1dabf/" rel="nofollow" target="_blank" title="http://www.bytebot.net/blog/archives/2007/04/25/federation-at-flickr-a-tour-of-the-flickr-architecture">Федерация Flickr: Тур по архитектуре Flickr</a></li> <li><a href="https://www.insight-it.ru/goto/9e0a13a1/" rel="nofollow" target="_blank" title="http://highscalability.com/book-building-scalable-web-sites">Построение масштабируемых веб-сайтов</a> от Call Handerson'а из Flickr</li> <li>История войн баз данных #3: Tim O'Reilly о Flickr</li> <li><a href="https://www.insight-it.ru/goto/d881b0d9/" rel="nofollow" target="_blank" title="http://www.iamcal.com/talks/">Cal Henderson's Talks</a> - много полезных презентаций</li> </ul> <h3 id="platforma">Платформа</h3> <ul> <li><a href="/tag/php/">PHP</a></li> <li><a href="/tag/sql/">MySQL</a></li> <li>Сегментирование <em>(прим.: разбиение системы на части, обслуживающие каждая свою группу пользователей; называть можно было по-разному, но давайте остановимся на этом варианте перевода слова "Shards")</em></li> <li><a href="/tag/memcached/">Memcached</a> для кэширования</li> <li><a href="/tag/squid/">Squid</a> в качестве обратной-прокси для html и изображений</li> <li><a href="/linux">Linux</a> (<a href="/tag/redhat/">RedHat</a>)</li> <li><a href="/tag/smarty/">Smarty</a> в роли шаблонизатора</li> <li><a href="/tag/perl/">Perl</a></li> <li>PEAR для парсинга e-mail и XML</li> <li>ImageMagick для обработки изображений</li> <li><a href="/tag/java/">Java</a> для узлового сервиса</li> <li><a href="/tag/apache/">Apache</a></li> <li><a href="/tag/systemimager/">SystemImager</a> для развертывания систем</li> <li><a href="/tag/ganglia/">Ganglia</a> для мониторинга распределенных систем</li> <li><a href="/tag/subcon/">Subcon</a> хранит важные системные конфигурационные файлы в SVN-репозитории для легкого развертывания на машины в кластере.</li> <li><a href="/tag/cvsup/">Cvsup</a> для распространения и обновления коллекций файлов по сети</li> </ul> <h3 id="statistika">Статистика</h3> <ul> <li>Более четырех миллиардов запросов в день</li> <li>Примерно 35 миллионов фотографий в кэше <a href="/tag/squid/">Squid</a></li> <li>Около двух миллионов фотографий в оперативной памяти <a href="/tag/squid/">Squid</a></li> <li>Всего приблизительно 470 миллионов изображений, каждое представлено в 4 или 5 размерах</li> <li>38 тысяч запросов к <a href="/tag/memcached/">memcached</a> (12 миллионов объектов)</li> <li>2 петабайта дискового пространства</li> <li>Более 400000 фотографий добавляются ежедневно</li> </ul> <h3 id="arkhitektura">Архитектура</h3> <p>Симпатичное изображение архитектуры Flickr можно увидеть на <a href="https://www.insight-it.ru/goto/d30e097b/" rel="nofollow" target="_blank" title="http://www.slideshare.net/techdude/scalable-web-architectures-common-patterns-and-approaches/138">этом слайде</a>. Краткое ее описание выглядит следующим образом:</p> <ul> <li>Два ServerIron</li> <li><a href="/tag/squid/">Squid</a> кэши</li> <li>Системы хранения NetApp</li> <li>Серверы <a href="/tag/php/">PHP</a> приложений</li> <li>Менеджер хранения данных</li> <li>Master-master сегменты</li> <li>Центральная база данных, структурированная по принципу Dual Tree</li> <li><a href="/tag/memcached/">Memcached</a> кластер</li> <li>Поисковая система</li> </ul> <h4>Хранение данных</h4> <ul> <li>Структура Dual Tree является индивидуальным набором модификаций для <a href="/tag/sql/">MySQL</a>, позволяющим масштабировать систему путем добавления новых мастер-серверов без использования кольцевой архитектуры. Эта система позволяет экономить на масштабировании, так как варианты мастер-мастер требовали бы удвоенных вложений в оборудование.</li> <li>Центральная база данных включает в себя таблицу пользователей, состоящую из основных ключей пользователей (несколько уникальных идентификационных номеров) и указатель на сегмент, на котором может быть найдена остальная информация о конкретном пользователе.</li> <li>Использование выделенных серверов для статического контента</li> <li>Все, за исключением фотографий, хранится в базе данных</li> <li>Отсутствие состояний заключается в том, что в случае необходимости они имеют возможность передать пользователей от сервера к серверу, что стало намного проще для них после создания своего API</li> <li>В основе масштабируемости лежит репликация, но этот факт помогает лишь при обработке операций чтения</li> <li>Для поиска по определенной части базы данных создается отдельная копия этого фрагмента</li> <li>Использования горизонтального масштабирования для того чтобы можно было проще добавлять новые машины в систему</li> <li>Обработка изображений, полученных от пользователей по электронной почте, происходит с помощью <a href="/tag/php/">PHP</a></li> <li>Раньше система страдала от задержек связанных с организацией по принципу мастер-слуга. При слишком большой нагрузке они имели одну точку, которая теоретически могла дать сбой.</li> <li>Им было необходимо иметь возможность проводить технические работы во время непрерывной работы сайта, не прекращая его функционирование.</li> <li>Были проведены отличные работы по планированию распределения дискового пространства, более подробную информацию можно найти по ссылкам в разделе "Источники информации".</li> <li>Для обеспечения возможности масштабирования в будущем, они пошли по федеративному пути развития:<ul> <li><em>Сегменты системы:</em> Мои данные хранятся на моем сегменте, но запись о Вашем комментарии хранится на Вашем сегменте.</li> <li><em>Глобальное кольцо:</em> Принцип работы схож с DNS, Вам необходимо знать куда Вы хотите пойти и кто контролирует то место, куда Вы собираетесь пойти.</li> <li>Логика на <a href="/tag/php/">PHP</a> устанавливает соединение с сегментом и поддерживает целостность данных (10 строк кода с комментариями!)</li> </ul> </li> <li><strong>Сегменты:</strong><ul> <li>Срез основной базы данных</li> <li>Активная репликация по принципу мастер-мастер: имеет несколько недостатков в <a href="/tag/sql/">MySQL</a> 4.1. Автоматическое инкрементирование идентификационных номеров используется для поддержания системы в режиме одновременной активности обоих серверов в паре</li> <li>Привязывание новых учетных записей к сегментам системы происходит случайным образом</li> <li>Миграция пользователей проводится время от времени для того, чтобы избавиться от проблем, связанных с излишне активными пользователями. Необходима сбалансированность в этом процессе, особенно в случаях с большим количеством фотографий&hellip; 192 тысячи фотографий, 700 тысяч тэгов, может занять несколько минут. Миграция выполняется вручную.</li> </ul> </li> <li>Нажатие на <strong>Favorite</strong>:<ul> <li>Получается информация об учетной записи владельца из кэша для того, чтобы узнать к какому сегменту он привязан (допустим на shard-5)</li> <li>Получается информация о моей учетной записи из кэша, более конкретно - мой сегмент (например shard-13)</li> <li>Начинается "распределенная транзакция" для определения ответов на вопросы: Кто добавил эту фотографию в избранное? Как изменился список избранных фотографий?</li> </ul> </li> <li>Подобные вопросы могут задаваться любому сегменту, информация на них абсолютно избыточна.</li> <li>Для избавления от задержек, связанных с репликацией...<ul> <li>при каждой загрузке страницы, пользователю предоставляется список серверов</li> <li>если сервер не в состоянии ответить на запрос, запрос переходит к следующему серверу в списке; если список кончился - выводится сообщение об ошибке. При этом не используются постоянные соединения, каждый раз создаются и разрываются новые соединения.</li> </ul> </li> <li>Запросы на чтение и запись от каждого пользователя ограничиваются рамками одного сегмента. Задержки репликации исчезают из поля зрения пользователей.</li> <li>Каждый сервер в рамках одного сегмента в обычном состоянии нагружен ровно на половину. Выключите половину серверов в каждом сегменте и система продолжит функционировать без изменений. Это значит, что один сервер внутри сегмента может взять на себя всю нагрузку второго, в то время как второй сервер может по каким либо причинам быть отключен от системы, например для проведения технических работ. Обновление оборудования производится очень просто: отключается половина сегмента, она же обновляется, подключается обратно, процесс повторяется для оставшейся половины.</li> <li>Периоды пиковой нагрузки также нарушают правило 50% нагрузки. В такие моменты система получает 6-7 тысяч запросов в секунду, в то время как на данный момент система может работать на пятидесятипроцентном уровне нагрузки только при четырех тысячах запросов в секунду.</li> <li>В среднем при загрузке одной страницы выполняется 27-35 SQL-запросов. Списки избранных фотографий обрабатываются в реальном времени, ровно как и доступ через API к базе данных. Все требования к нагрузке в реальном времени выполняются без каких-либо недостатков.</li> <li>Более 36 тысяч запросов в секунду может выполняться не выходя за рамки возможностей системы, даже при резком росте трафика.</li> <li>Каждый сегмент содержит данные о более чем 400 тысячах пользователей.</li> <li>Многие данные хранятся в двух местах одновременно. Например, комментарий является частью между комментатором и автором комментируемого контента. Где его хранить? Как насчет обоих мест? Транзакции используются для предотвращения рассинхронизации данных: открывается первая транзакция, выполняется запись, открывается вторая транзакция, выполняется запись, подтверждается первая транзакция если все нормально, после чего вторая подтверждается только в случае если первая прошла успешно.</li> </ul> <h4>Поиск</h4> <ul> <li>Используется два варианта поиска: поиск в рамках сегмента, поддерживающий до 35 тысяч запросов в секунду, а также проприетарный веб-поиск от Yahoo!</li> <li>В 90% случаев используется система от Yahoo!, за исключением поиска по тэгу фотографий одного пользователя и массовых изменений тэгов.</li> <li>Эту систему стоит рассматривать как аналог Lucene.</li> </ul> <h4>Оборудование</h4> <ul> <li>EMT64 под управлением RHEL 4 с 16 Gb оперативной памяти.</li> <li>6 жестких дисков с 15000rpm, объединены в RAID-10.</li> <li>Размер для пользовательских метаданных достигает 12 терабайт (это не включает фотографии, для них цифры существенно больше).</li> <li>Используются 2U корпуса.</li> </ul> <h4>Резервное копирование данных</h4> <ul> <li>ibbackup выполняется регулярно посредством cron daemon'а, на каждом сегменте настроен на разное время.</li> <li>Каждую ночь делается снимок со всего кластера баз данных.</li> <li>Запись или удаление нескольких больших файлов с резервными копиями одновременно на реплицирующую систему хранения может сильно сократить производительность системы вцелом на последующие несколько часов из-за процесса репликации. Выполнение этого на активно работающей системе хранения фотографий было бы не самой лучшей идеей.</li> <li>Содержание нескольких резервных копий всех Ваших данных требует существенных материальных затрат, но оно того стоит. Особенно это актуально для тех ситуаций, когда Вы понимаете, что что-то пошло не так только спустя несколько дней после того как это случилось, в таких случаях неплохо иметь, например, резервные копии 1, 3, 10 и 30-дневной давности.</li> <li>Фотографии хранятся в системе хранения данных. После загрузки изображения система выдает различные его размеры, на чем ее работа заканчивается. Метаданные и ссылки на файловые системы, где расположены фотографии, хранятся в базе данных.</li> <li>Агрегация данных проходит очень быстро, так как она ограничена пределами сегмента.</li> <li><code>max_connections = 400</code> соединений на каждый сегмент, неплохой запас. Значение для кэша потоков установлено равным 45, так как не бывает ситуаций когда более 45 пользователей одновременно выполняют какие-либо действия с одним конкретным сегментом.</li> </ul> <h4>Тэги</h4> <ul> <li>Тэги плохо вписываются в традиционную нормализованную схему реляционной базы данных. Денормализация или активное кэширование - единственные способы сгенерировать облако меток для сотен миллионов тэгов в течении миллисекунд.</li> <li>Некоторые данные обрабатываются отдельными вычислительными кластерами, которые сохраняют результаты своей работы в MySQL, так как иначе вычисление сложных отношений заняло бы все процессорное время основных серверов баз данных.</li> </ul> <h4>Направления для развития</h4> <p>Ускорение работы с помощью создания организационного плана для непрерывной работы всей системы на уровне нескольких датацентров, таким образом чтобы все датацентры имели возможность получать запросы на общий уровень данных (как сами БД, так и memcache и прочее) все вместе одновременно. Если все части системы постоянно активны - время простоя оборудования будет сведено к минимуму.</p> <h3 id="podvodim-itogi">Подводим итоги</h3> <ul> <li>Старайтесь думать о своем приложении как о чем-то большем, чем просто веб-приложении, тогда у Вас возможно появятся поддержка различных API, RSS и Atom ленты и многие другие возможности.</li> <li>Отсутствие состояний системы позволяет более легко выполнять модернизации не моргнув и глазом.</li> <li>Реструктуризация базы данных - не самое лучшее занятие.</li> <li>Планирование нагрузок должно проводиться уже на ранних этапах развития проекта</li> <li>Начинайте медленно. Не покупайте сразу много оборудования просто из-за того, что Вы рады/боитесь, что ваш сайт взорвется.</li> <li>Измеряйте реально, планирование нагрузок должно базироваться на реальных вещах, а не абстрактных.</li> <li>Внедряйте ведение логов и индивидуальные измерения для оценки реальных показателей на основе серверной статистики, статистика использования не менее важна чем серверная.</li> <li>Кэширование и оперативная память может стать ответом на все вопросы.</li> <li>Создавайте четкие уровни абстракции между работой базы данных, бизнес-логикой, логикой страниц, разметкой страниц и презентационным уровнем. Это позволяет ускорить циклы итеративной разработки.</li> <li>Разделение приложения на уровни позволяет каждому заниматься своим делом: разработчики могут строить логику страниц, в то время как дизайнеры работают с удобством работы для пользователей.</li> <li>Делайте релизы как можно чаще, пускай даже это будет происходить каждые полчаса.</li> <li>Забудьте о всех небольших эффективных вещах, предварительная оптимизация является корнем всего зла в примерно 97% всех случаев.</li> <li>Тестируйте в работе. Постройте архитектурные механизмы (флаги конфигурации, балансировку нагрузки, и так далее), которые позволят Вам разворачивать новое оборудование в (и из) работу.</li> <li>Забудьте об искусственных тестах, они годятся только для получения общего представления о нагрузках, но не для планирования. Искуственные тесты дают искусственные результаты, для настоящих тестов все же стоит пользоваться реальным временем выполнения задач.</li> <li>Найдите максимальное значения для всех показателей:<ul> <li>Какой максимум чего-то, что может выполнять каждый сервер?</li> <li>Как близко параметр находится к максимуму и каковы тенденции?</li> <li><a href="/tag/sql/">MySQL</a> (дисковый ввод/вывод?)</li> <li><a href="/tag/squid/">Squid</a> (дисковый ввод/вывод? или процессорное время?)</li> <li><a href="/tag/memcached/">Memcached</a> (процессорное время? или пропускная способность?)</li> </ul> </li> <li>Старайтесь учесть особенности использования Вашего приложения.<ul> <li>Возможен ли резкий рост нагрузки, связанный с каким-либо событием? Например: какое-либо бедствие, или может быть новость?</li> <li>Flickr получает на 20-40% больше новых фотографий в первый рабочий день нового года, чем в любой пик в предыдущем году.</li> <li>По воскресеньям нагрузка в среднем на 40-50% выше, чем в любой другой день недели.</li> </ul> </li> <li>Учтите возможность экспоненциального роста. Больше пользователей означает больше контента, больше контента означает больше соединений, больше соединений означает более активное использование.</li> <li>Планируйте возможные варианты управления работой системы в периоды пиковых нагрузок.</li> </ul>Иван БлинковFri, 08 Feb 2008 22:41:00 +0300tag:www.insight-it.ru,2008-02-08:highload/2008/arkhitektura-flickr/ApacheCvsupflickrGangliaJavaLinuxMemcachedMySQLonlinePerlPHPRedHatshardSmartySquidSubconSystemImagerархитектураархитектура FlickrинтернеткластерМасштабируемостьсервер