Anatoly Levenchuk ([info]ailev) wrote,
@ 2009-06-28 13:54:00
Previous Entry  Add to memories!  Tell a Friend  Next Entry
Заоблачные вычисления.
Облачные вычисления стали уже заоблачными: на виртуальных машинах Amazon EC2 и памяти Amazon S3 фирма Microsoft (ладно, не сама она, а только что проглоченный ей Powerset, поиск на естественном языке) разворачивает свободную кластерную инфраструктуру Hadoop (http://hadoop.apache.org/core/), и затем решает свои задачи на этом "виртуальном суперкомпьютере", собранном из виртуальных машин. Облако на облаке, заоблачность налицо. Это не единственный пример. Рекламная сеть Adknowledge поступает ровно таким же образом: Hadoop поверх EC2. И японский поиск изображений CblR, и многие другие (http://wiki.apache.org/hadoop/PoweredBy).

Ежели спуститься на ступеньку ниже, и просто собирать Hadoop-кластеры из обычных, а не виртуальных машин, то становятся возможными заоблачные вычисления в старинном ("недостижимости") смысле этого слова. Так, Yahoo! приняла участие в соревнованиях по сортировке больших массивох данных http://sortbenchmark.org/ и бодро отрапортовала (http://developer.yahoo.net/blogs/hadoop/2009/05/hadoop_sorts_a_petabyte_in_162.html), что умеет сегодня отсортировать случайным образом перетасованный петабайт 100-байтных записей (это 1,000,000,000,000,000 байт -- по тройкам нулей кило, мега, гига, тера, пета) за 16.5 часов), а терабайт за 62 секунды. Эти соревнования проводятся с 1985 года, и тогда сортировка 100Мб занимала 1 час. Сегодня 0.1GB стобайтных записей сортируется одну секунду, ускорение за прошедших двадцать четыре года в 3600 раз.

Чем больше электроный фундамент уходит в "нано", тем больше в облачных и даже заоблачных высях приходится запоминать значения слов уже не только "тера" (байты, флопсы), но и пета. Это несмотря на то, что герцы так и замерли в начале "гига".

Инфраструктуру распределенных вычислений сделать не так уж дорого: за $10тыс. уже можно получить вполне навороченный собственный кластер, ежели есть чем его занять на полную катушку. А ежели нет уверенности в полной его занятости, то можно для экспериментов купить процессорное время в том же Amazon EC2/S3.

Есть множество готовых свободнософтовых приложений для Hadoop -- от самого обычного веб-поиска (http://lucene.apache.org/nutch/) и корпоративного поиска (http://lucene.apache.org/solr/) до библиотек машинного обучения (http://lucene.apache.org/mahout/, the first public release includes implementations for clustering, classification, collaborative filtering and evolutionary programming).

И при все этом я (вслед за Аланом Кеем) имею наглость утверждать, что компьютерная революция еще не началась: все помянутое обеспечение многослойно и в силу этого неэффективно дублирует друг друга, основано на допотопных процессорных и сетевых архитектурах, некомпактно из-за использования нынешних языков.

Но я думаю, что переход от "пета" (квадриллион) к "экза" (следующие три нолика, квинтиллион), имена которых появились в 1975г., произойдет много быстрее, чем компьютерная революция. А уж компьютерная революция заставит вспомнить о появившихся в 1991г. "зетта" и "йотта" (http://www.wikiznanie.ru/ru-wz/index.php/Метрическая_приставка).

Имеет ли это значение? Да, именно это и имеет определяющее значение. Хотя я и не сторонник параллельности (я считаю, что последовательные вычисления далеко не исчерпали потенциала своего развития, и именно они являются определяющими для прогресса), дешевая параллельность крайне важна. Сначала все появляется в виде mainframe с заоблачными ценами, а затем такая же вычислительная мощность обязательно появляется у кого-нибудь в ноутбуке. Так было, и так будет. Поэтому крайне интересно смотреть на датацентры Гугля и думать, что будет в тот относительно недалекий момент, когда такие датацентры будут доступны в ноутбуках. А что будет в этот момент считаться в датацентрах (которые никуда, конечно, не денутся), даже представить сейчас невозможно.

А пока проходим в среднем одну приставку за десятилетие. Что там за заоблаками?


(33 comments) - (Post a new comment)


[info]vit_r
2009-06-28 06:37 pm UTC (link)
Играюсь сейчас с инсталяшками OpenSolaris и FreeBSD. Они поддерживают замечательную операционную систему ZFS (Zettabyte File System). Причём, ставяться на USB стик.

А в облаках проблема с применимостью. Сейчас выгоднее большой фирме делать свой кластер, а маленькой таких вычислительных мощностей не нужно. Прыгающие же нагрузки мало у кого бывают.

(Reply to this) (Thread)


[info]avlasov
2009-06-29 10:30 am UTC (link)
Прыгающие нагрузки - обычное дело.
Ибо народ обычно работает в рабочее время, оно сервера и нагружает, остальное время все простаивает.
Есть еще неожиданные пиковые нагрузки, которым подверженны все, у кого сервера выходят в интернет.
Например у Голдман Сакса в августе 2007го нагрузка на систему выросла в 24 раза. А смерть Майкла Джексона обрушила многие сайты.
Есть такой слэш-дот эффект: после публикации ссылки на slashdot.org куча народу ломилось на сервер и ложила его.
Так что прыгающие нагрузки - это норма жизни. Это было понятно даже в эпоху первого интернет бума, когда все стартапы старались закупиться оборудованием, чтобы выдержать внезапный наплыв посетителей - никто не хотел оставить первое впечатление о проекте в виде неработающего сайта.

(Reply to this) (Parent)(Thread)


[info]vit_r
2009-06-29 01:35 pm UTC (link)
Посетители и покупатели - группы не во всём совпадающие. В большинстве случаев оптимизация под пиковую нагрузку не оправдана.

Те, кто на слешдоте висят, висят на слешдоте. Нужны же клиенты.

(Reply to this) (Parent)(Thread)


[info]avlasov
2009-06-29 01:51 pm UTC (link)
Оправдана/не оправдана - это уже другой вопрос. Вопрос этот стоит по любому у того, кто вовлечен в глобальную экономику. А вовлечены многие, хотя бы косвенно.
К примеру, проблемы с ликвидностью в 2006 году вызвали ипотечный кризис в америке в августе 2007 года, который вызвал уже глобальный кризис в сентябре 2008 года. И все с ним так или иначе столкнулись.

Оптимизация под пиковую нагрузку не то что не оправдана - она невыгодна. Т.е. Голдман Сакс должен был содержать мощности не в 3 раза больше, а в 24 раза, т.е. на порядок больше. Даже Голдман Саксу это напряжно. Но все 5 крупнейших инвестбанков (плюс несколько коммерческих банков, страховых контор и проч фин институций) через год подверглись серьезному реформированию (т.е. рейдерскому захвату).
В частности это было связано с тем, что в время кризиса, их execution system была парализована наплывом ордеров и они и их клиенты просто не успевали продавать акции по хорошим ценам. А это очень накладно, ибо у них позиции были взяты в кредит, и убытки у них мультиплицировались. Т.е. они на самом деле, благодаря ловким операциям с отчетностью отложили кризис на следующий год просто.

Однако некоторые финансовые институты были готовы к такому повороту событий - у них были сетки, которые выдержали такой наплыв транзакций и смогли быстро раскидать их по пулам ликвидности. Понятное дело, они неплохо наварились на стрижке крупнейших инвестбанков и их клиентов.

Так что я даже не знаю, оправдана была такая перестраховка или нет. Невыгодна для бизнесов в текущей перспективе - это да, а в долгосрочной - критично для жизнеспособности. Так же можно утверждать, что обществу в целом такой кризис и такое его течение не выгодно, поэтому я считаю, что если бы сети исполнения ордеров были работоспособны под такой нагрузкой, это было бы оправданно с точки зрения и общества в целом, и финансового коммьюнити. Потому как это называется предсказуемые правила игры.

(Reply to this) (Parent)(Thread)


[info]vit_r
2009-06-29 02:25 pm UTC (link)
Проблема только в том, что ни один из предлагателей облаков сейчас не готов подписать SLA.

С другой стороны, если оптимизировать софт, железа понадобиться гораздо меньше. Я знаю проекты, которые на одном сервере с Перлом делали быстрее и лучше то, для чего другим фирмам нужен был маленький кластер сановских машин.

(Reply to this) (Parent)(Thread)


[info]avlasov
2009-06-29 02:31 pm UTC (link)
Ну для оптимизации софта простор несомненно широкий. У меня правило, что любой софт можно ускорить в 10 раз, а в 3-5 раз можно ускорит маленькими усилиями.
Хотя кому-то удобнее Амазон облако. К примеру, если контрагент тоже в облаке, то между ними трафик будет бесплатным, чем некоторые пользуются, у тех у кого интенсивный информационный обмен. А так как активность опять же циклическая, в рабочие часы в основном, то почасовая аренда выгодна.

(Reply to this) (Parent)(Thread)


[info]vit_r
2009-06-29 02:33 pm UTC (link)
На амазоновской лекции мужик привёл знаменитую цитату Таненбаума о том, что не надо недооценивать полосу пропускания грузовика, набитого носителями. Короче, они читают себе в облако информацию, на носителе им присланную.

(Reply to this) (Parent)(Thread)


[info]avlasov
2009-06-29 02:47 pm UTC (link)
Грузовик набитый ДВДюками - это хорошо, но у него велика латентность. Иногда это важно.
Я не скажу, что Амазон облако это всегда гуд, но встречал пару проектов, где оно использовалось и там это было хорошей идеей.
Я и сам подумываю. К примеру, у меня есть одна идея-проект, там есть интенсивная вычислительная часть, пропорциональная юзерской нагрузке. Самому содержать ферму серваков неохота, а ускорить я конечно ускорю, но все равно считать много надо.

(Reply to this) (Parent)(Thread)


[info]vit_r
2009-06-29 03:15 pm UTC (link)
Смотрел на Амазон. По их ценам ферма серваков всё-таки проще. Тем более, что услугу хостинга без облаков предоставляют многие.

(Reply to this) (Parent)(Thread)


[info]avlasov
2009-06-29 03:20 pm UTC (link)
Да ценник дороговатый у них.

(Reply to this) (Parent)


[info]109
2009-06-29 08:08 pm UTC (link)
У меня правило, что любой софт можно ускорить в 10 раз, а в 3-5 раз можно ускорит маленькими усилиями

ай, маладэц.

из этого следует, кстати, что любой софт можно ускорить в бесконечное число раз маленькими усилиями.

(Reply to this) (Parent)(Thread)


[info]avlasov
2009-06-30 08:30 am UTC (link)
Не следует. Потому как кол-во переходит в качество, и сумма маленьких усилий может оказаться уже не маленькой.
ЗЫ Разумеется этот мой тезис формально неверен, и легко опровергается. Только непонятно зачем его опровергать :)

(Reply to this) (Parent)(Thread)


[info]109
2009-06-30 09:01 pm UTC (link)
из вашего же тезиса следует, что усилия складываются, а скорость умножается. так что per performance gain усилия в вашей модели становятся как раз все меньше и меньше, в то же самое время, как производительность стремится к бесконечности.

опровергать тезис нужно, потому что это чушь собачья.

я как-то две недели занимался исключительно производительностью большой базы на sql сервере. пробовал/измерял разные индексы/materialized views, код хранимых процедур подстраивал, локи и транзакции тюнил, whole nine yards. выжал всё, что имело смысл с точки зрения cost/benefits. а потом вот кто-то такой же продвинутый заявил "да раз плюнуть, мы сейчас ещё в пять раз ускорим маленькими усилиями". "как именно?" - в изумлении поинтересовался я. "ещё индексы построим" - уверенно сказал эксперт.

через месяц эксперт признался, что ускорить ещё в пять раз оказалось не такой простой задачей, как виделось сначала. построенные под его руководством дополнительные индексы привели к замедлению работы в полтора раза по сравнению с тем, что вышло из моих рук.

ну и далее, поскольку производительность базы увеличить не удалось, эксперт решил переключиться на оптимизацию производительности дотнетовского кода. типа под фонарём легче ключи искать.

true story, ничего не приукрасил. мораль - тщательнее надо, осторожнее с формулировками типа "любой софт можно ускорить в 10 раз, а в 3-5 раз можно ускорить маленькими усилиями".

(Reply to this) (Parent)(Thread)


[info]avlasov
2009-07-01 08:15 am UTC (link)
из вашего же тезиса следует, что усилия складываются, а скорость умножается. так что per performance gain усилия в вашей модели становятся как раз все меньше и меньше, в то же самое время, как производительность стремится к бесконечности.
В то время как производительность стремится в бесконечности, сумма маленьких усилий не продолжает оставаться малым. Количество переходит в качество. Ха-ха-ха.
опровергать тезис нужно, потому что это чушь собачья.
Всем и так понятно, что мой тезис не всегда верен. Что Вы нового-то хотели сказать? Что Вы пытались ускорить и у Вас не получилось? Может Вы просто не умеете?
Тот подход который Вы описали заведомо неэффективный: другие программеры/администраторы ведь уже подтюнили что смогли. Нестандартно надо действовать.
true story, ничего не приукрасил. мораль - тщательнее надо, осторожнее с формулировками типа "любой софт можно ускорить в 10 раз, а в 3-5 раз можно ускорить маленькими усилиями".
Зачем осторожнее, может наоборот смелее надо? Я вот считаю что аппаратно-софтовый комплекс суммарно можно ускорить в 1000 раз.

(Reply to this) (Parent)(Thread)


[info]109
2009-07-01 09:41 pm UTC (link)
вопросов больше не имею :)

(Reply to this) (Parent)(Thread)


[info]avlasov
2009-07-02 08:09 am UTC (link)
Если Вас интересуют вопросы оптимизации софта, рекомендую почитать книжку Реинжиниринг Корпорации. Она конечно не про софт, но и к софту тоже применима.

(Reply to this) (Parent)(Thread)


[info]109
2009-07-02 06:15 pm UTC (link)
спасибо, но вы не вызвали у меня ощущения человека, рекомендациям которого надо следовать :)

(Reply to this) (Parent)(Thread)


[info]avlasov
2009-07-03 09:00 am UTC (link)
Разумно. Не уверен, что они принесут Вам радость.

(Reply to this) (Parent)


[info]avlasov
2009-06-30 08:33 am UTC (link)
ЗЗЫ Есть такая теорема, что любой алгоритм можно ускорить в некотором смысле (преобразовать так, чтобы делал меньше шагов асимптотически).

(Reply to this) (Parent)


[info]ailev
2009-06-29 08:34 pm UTC (link)
Очень странная история. Когда-то давным-давно было выяснено, что основная причина беспорядков на фондовых рынков -- это как раз перегрузка систем исполнения сделок. И тогда Комиссия потребовала от всех трейдерских систем выдерживание семикратной нагрузки по сравнению с их средней нагрузкой. Воплей было тогда много, но все подчинились, а вскоре какой-то мелкий кризис доказал правоту Комиссии и все заткнулись. Я думал, что обязательное требование по запасу мощности систем заказа-исполнения сделок сохранилось. Странно слышать, что мощностей не хватило в этот раз.

(Reply to this) (Parent)(Thread)


[info]avlasov
2009-06-30 08:26 am UTC (link)
Ну дык что в 24 раза больше будет транзакций, никто не ожидал. Говорят, кол-во серваков срочно удвоили и это не помогло.
Кредитное плечо ведь возросло, инвестбанки наэммитировали производных в районе 10 трлн, что сравнимо с кредитной эмиссией. И потом вся эта масса в один момент стала сдуваться.

(Reply to this) (Parent)


[info]avlasov
2009-06-30 08:43 am UTC (link)
История действительно очень странная, я пока проследил до 2006 года.
Тогда закончился срок правления Гринспена, появилась биржа ICE, торги нефтью на которой проходили в Лондоне, и американские трейдеры перестали отчитываться по крупным нефтянным фьючерсным позициям в CFTC.
Также было два интересных события, американская аккаунтинговая комиссия велела (если не ошибаюсь в сентябре 2007го, как раз после ипотечного кризиса) всем считать активы по принципу mark-to-market (до этого был mark-to estimate), а потом снова разрешила шире применять mark-to-estimate (осенью 2008го).
Также было интересно почитать Term Sheets по тем префферед стокам, которые гос-во выдавала Ситигруп. История с Мэйдоффом тоже очень интересное.
Вобщем там копать и копать, материалов даже в интернете много интересных есть.

(Reply to this) (Parent)(Thread)


[info]ailev
2009-06-30 08:59 am UTC (link)
Меня не правила учета интересуют, меня интересует тут только один аспект: предписанная мощность вычислительных систем исполнения заявок, которая во время кризисов а) не должна выдавать сигнал "занято" и б) не должна терять заказы. Ибо по всем "разборам полетов" самые ужасные последствия фондовых микрокризисов ("паник") -- это потерянные из-за перегрузок систем исполнения ордера и начинающийся из-за этого бардак.

(Reply to this) (Parent)(Thread)


[info]avlasov
2009-06-30 09:20 am UTC (link)
От бирж и торговых систем (на которых ордера матчатся) скорее всего требуется, ибо они действительно заботятся, у них это четко продуманно и прописано, требования по каналам расписаны и доведены до сведения. Но я думаю они и выдержали нагрузку (я не слышал ни о каких проблемах с производительностью на американских биржами в августе 2007го).
А вот брокера - другое дело. Я не сталкивался с тем, чтобы брокеров заставляли гарантировать производительность систем исполнения (я был бы очень-очень рад если бы это было так, потому что у меня было бы много очень интересной работы, которую мало кто может делать). В требованиях бирж есть ограничения на пропускную способность каналов, т.е. брокера должны резервировть и покупать дополнительные каналы. А представьте, что Голдман Сакс, с его оборотами, покупал бы в 24 раза больше каналов, чем нужно в среднем! Он и в 7 бы вряд ли купил. Вот раза в 3 резервировать - это да.
Плюс, на тестах-то они что угодно могли показать. А на практике, какой-нить неожиданный боттлнек вылезет.

В реальности, у многих брокеров были траблы с обработкой потока заказов. Не было у тех, кто вложился в создание специальных execution сетей, но это не просто набор серверов с кабелями. Нужно подключится к пулам ликвидности - сейчас в Америке около дюжины бирж, плюс куча торговых систем, которые биржами не являются, но ордера сводят. Причем не все они открытые, т.е. у них есть какие-то ограничения на клиентов. Ну и опять же, нужно достаточное кол-во интернет каналов и private сетей сделать, чтобы клиенты смогли все эти приказы запихать.

Кроме того, биржевой софт как правило весьма быстрый, производительность что-то типа десятков тысяч событий в сек на процессор. Брокерский софт очень медленный, производительность типа 100-1000 событий в сек на процессор.

(Reply to this) (Parent)(Thread)


[info]ailev
2009-06-30 09:35 am UTC (link)
В общем, я понял: депозитарный софт на нагрузках уже отстроили, биржевой тоже, брокерский -- у некоторых типов брокеров, а у других игроков финансовых рынков (работающих с не очень классическими типами инструментов, типа акций-облигаций) эта волна борьбы со сбоями на пиках еще не дошла. Но уж теперь (после того, как это осознали) волна дойдет обязательно, пока на следующей панике что-нибудь опять не вылезет.

(Reply to this) (Parent)(Thread)


[info]avlasov
2009-06-30 09:50 am UTC (link)
Думаю да.
Единственно, что надо учитывать институциональные ограничения, потому как каналы к биржам стоят недешево, и держать в 24 раза больше каналов никто не сможет себе позволить. И даже в 10 раз - вряд ли. И каналы IP связи тоже. Т.е. надо менять правила игры, передоговариваться.
Что конечно не отменяет требований к софту - там есть много над чем работать, я эту проблему хорошо знаю, мой принцип что любой софт можно ускорить в 10 раз не на пустом месте взялся :).

(Reply to this) (Parent)


[info]avlasov
2009-06-30 09:22 am UTC (link)
Ибо по всем "разборам полетов" самые ужасные последствия фондовых микрокризисов ("паник") -- это потерянные из-за перегрузок систем исполнения ордера и начинающийся из-за этого бардак.
Дык это и на макроуровне так. Почему не дали банкротить AIG, Fannie/Freddie? Если бы их забанкротили, то такая неразбериха была бы с тем, кто кому сколько должен, что без войны бы дело не обошлось.

(Reply to this) (Parent)


[info]avlasov
2009-06-29 10:21 am UTC (link)
И при все этом я (вслед за Аланом Кеем) имею наглость утверждать, что компьютерная революция еще не началась: все помянутое обеспечение многослойно и в силу этого неэффективно дублирует друг друга, основано на допотопных процессорных и сетевых архитектурах, некомпактно из-за использования нынешних языков.
Не началась. Это все клей, который связывает железо, выполненное во все той же старой парадигме. Конечно всякие хабубы/вирутализации повышают эффективность использования железа в разы, но резервы повышения на 2-3 порядка все равно есть.
Для начала надо выкинуть Виндоуз (и Линукс) - сразу требования к ресурсом снизяться, и на чип можно запихать пару сотен серверов. Если еще юзать адекватные процессорные архитектуры - то тоже возможен рост на 1.5-2 порядка, например можно прикинуть по аналогии с ФПГА, на которых задача часто ускоряется в 30-100 раз (ну или те же ГПГПУ).

(Reply to this) (Thread)


[info]ailev
2009-06-29 08:37 pm UTC (link)
Это революция по скорости и памяти. А я еще имею ввиду революцию и по приложениям и методам их создания.

(Reply to this) (Parent)(Thread)


[info]avlasov
2009-06-30 08:48 am UTC (link)
Тут есть синергетический эффект, кол-во переходит в качество. Если выкинуть "окошки" с сервера (а зачем на сервере окошки??), то то что останется влезет на чип несколько раз.

(Reply to this) (Parent)(Thread)


[info]ailev
2009-06-30 09:02 am UTC (link)
Ну да. У Кея приложения "верстаются" -- и тут же приходит на память (pun intended) вариант вёрстки веб-страницы, когда разные куски веб-страницы подсасываются с разных серверов. Ежели описывать эти процессы адекватным языком "программирования-в-большом" (programming-in-large, языки типа BPEL), то вообще все превратится в россыпь чипов, которые сами на себя поместятся по многу раз...

(Reply to this) (Parent)


[info]109
2009-06-29 08:04 pm UTC (link)
Хотя я и не сторонник параллельности

в cloud computing важны не столько параллельные вычисления, сколько scale-free и self-healing properties, типа "загрузка кластера близка к предельной? возьмём из пула ещё сотню виртуальных машин. упал контроллер? сразу взамен поднялся на другой машине". по крайней мере, это то, на что я стараюсь акцент делать.

(Reply to this) (Thread)


[info]ailev
2009-06-30 09:04 am UTC (link)
Да, это важный аспект. Характерное замечание про размер кластера в Yahoo! -- "в кластере примерно 3600 машин, ибо при таком размере кластера всегда несколько кластеров случайным образом неработоспособны".

(Reply to this) (Parent)


(33 comments) - (Post a new comment)

Create an Account
Forgot your login or password?
Login w/ OpenID
English • Español • Deutsch • Русский…