Google App Engine *

Google App Engine позволяет легко создавать приложения, надежно работающие даже при большой нагрузке и с большими объемами данных. Но ещё проще создать программного монстра, который будет работать очень медленно или вовсе не работать, постоянно возвращая ошибку HTTP 500.

Как писать быстрые и хорошо масштабируемые приложения – об этом пойдет речь в этой статье.

Все ниже изложенное прежде всего касается приложений, написанных на Java, но большей частью должно быть справедливо и для приложений написанных на языке Python.

Сначала расскажу об изменениях в SDKs, а потом о том, что такое AppEngie for business.

Итак,
— Новое API: OAuth. Теперь можно использовать приложение в качестве провайдера (очевидно, для Apps Marketplace)
— Поддержка OpenID.
— Blobstore больше не экспериментальное API (очень жаль, что не ввели direct-загрузок, цены для AppEngine дешевле, чем для нового WebStore). Максимальный размер файла — 2GB, против 50MB, что было раньше.

Для Python SDK:
— Добавлено автоматическое исполнение tasks на локальном SDK.
— Новый bulkloader с визардом для импорта/экспорта данных

Для Java SDK:
— Полная поддержка javax.el.*
— Java 1.5 теперь deprecated.

В основном в этой версии исправлены ошибки, но тем не менее есть и добавления, в том числе одно довольно интересное (про SQLite).

Разбираясь с обозначенной в заголовке темой, попутно обнаружил, что в рунете она раскрыта довольно слабо, хотя с момента представления данного протокола прошло уже много времени. Хочу слегка заполнить этот небольшой пробел, поделившись опытом.
Напомню кратко, что PubSubHubbub (PuSH) — это протокол, предложенный Google и призванный сделать более эффективным процесс доставки данных по каналам типа RSS от издателей к подписчикам. Центральное место в схеме, обеспечивающей работу протокола, отводится независимым хабам, выполняющим роль посредников между непосредственными источниками данных и конечными их получателями. При этом, хаб оповещает всех зарегистрированных у него подписчиков канала о поступлении новых данных сразу после их появления, одновременно передавая новую порцию данных.
Таким образом, если вы создаете приложение, занимающееся обработкой фидов в формате RSS или Atom, то можете заметно облегчить себе жизнь, возложив «черную» работу на хаб. Конкретные плюсы такой схемы:

• возможность «интеграции» множества внешних каналов в единый поток данных общего формата, поступающий на вход приложения: хаб может позаботиться об этом;
• отсутствие необходимости отделения новых данных от старых: хаб доставит только новые;
• не нужно постоянно отслеживать канал на предмет новых данных: хаб сам сообщит когда надо;
• минимальное время с момента публикации до момента оповещения вашего приложения.

Другими словами, вы можете получить оперативную доставку данных, заметно сэкономив как на объеме входящего трафика, так и на процессорном времени приложения. Для приложений на App Engine, ограниченных квотами, эти моменты могут оказаться принципиальными. Кроме того, вы сэкономите свое время, поскольку придется написать меньший объем несложного кода.
Ниже приведены минимально необходимые фрагменты кода на Java, которые были успешно мною опробованы на одном из хабов. Кода совсем немного и он несложный.

Все конечно с нетерпением ждут, когда в App Engine появится полнотекстовый поиск, но пока его нет даже в roadmap. Тем не менее, для GAE/Java полнотекстовый поиск можно прикрутить самостоятельно уже сейчас.

Для использования одного из самых удобных веб фреймворков для java на популярной облачной платформе Google AppEngine необходимо совершить ряд действий. Данная статья появилась в результате моих продолжительных экспериментов. Буду рад, если Вы поделитесь своим опытом работы с вашими любимыми фреймворками на платформе GAE в коментариях :-)

Используемые библиотеки

Я использую обычно следующий набор библиотек:

• commons-fileupload-1.2.1.jar
• commons-io-1.3.2.jar
• commons-logging-1.0.4.jar
• commons-logging-api-1.1.jar
• freemarker-2.3.13.jar
• ognl-2.6.11.jar
• struts2-core-2.1.6.jar
• xwork-2.1.2.jar

Я пользуюсь IntelliJ Idea 9 и она подкачивает зависимости автоматически после того, как я указываю использование Struts 2 при создании проекта. Также существует возможность развертывать приложения на облачной платформе через специальное меню IDE, и вообще поддержка AppEngine на очень хорошем уровне.

Далее необходимо обойти или адаптироваться к ограничениям облачной платформы, ибо Appengine запрещает прямой доступ к тредам, файловым и многим другим ресурсам.

Сначала расскажу об изменениях в SDKs, а потом о том, что разработчики нам обещают в ближайшие 6 месяцев.

Итак,
— Хранилище поддерживает 2 режима чтения данных и исполнения запросов: strong consistency (изначальное поведение хранилища, установлено по умолчанию), и eventual consistency. При режиме «strong consistency» все операции чтения данных и запросы будут ждать до окончания предыдущих изменений (которые были совершены, но не успели примениться к данным в распределенном хранилище). При режиме «eventual consistency» все операции чтения и запросы будут использовать версии уже имеющихся данных в хранилище, даже если эти данные ожидают изменений. Этот режим нужно использовать тогда, когда скорость чтения важнее, чем гарантированно обновленные данные.

— Хранилище поддерживает максимальный срок ответа (deadline) для большинства операций. Если при запросе хранилище его превышает, вызов прерывается и управление передается приложению.

— Возможность включить защиту от ДДОСА, посредством прописывания в конфиге приложения (dos.*yaml*xml*) «неугодных» ip-адресов и подсетей. Топ наиболее активных ip, которые подозреваются в атаке, появляются в админке приложения в новом разделе Blacklists, и их можно заносить в конфиг. Я в прошлую среду общался в чате с одним из разработчиков AppEngine (jason@google), и он сказал, что развитие DDOS-сервиса на этом точно НЕ остановится (думаю будет фильтрация и по странам и пр).

— Доступ из приложения к данным из BlobStore напрямую, посредством задания диапазона байт. На данный момент лимит на чтение составляет 1 мегабайт (как и для большинства сервисов AppEngine).

— Возможность добавления множества заданий в очередь при одиночном обращении к TaskQueueAPI, а также увеличена максимальная скорость пополнения очереди до 50/сек.

— Через URL Fetch можно теперь обращаться к удаленным ресурсам, используя порты 80-90, 440-450, и 1024-65535 (раньше были только 80 и 443).

— В JavaSDK добавлена утилита AppStats, по аналогии с PythonSDK.

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

И вот, увидел свет App Engine SDK 1.3.1. С момента выхода пререлиза прошло совсем немного времени. Одним из самых заметных нововведений явилось переработанное хранилище. Три основных улучшения хранилища:

1. Курсоры запросов — Курсоры позволяют приложению сохранять их состояние с помощью запросов для дальнейшего восстановления через некоторое время.

2. Нет больше лимита на 1000 результатов запроса — С добавлением курсоров и расширением хранилища в течение нескольких последних месяцев, был убран лимит на максимальные количество результатов.

3. Уменьшен уровень ошибок с помощью Механизма Автоматических Повторов в хранилище — При возникновении ошибки, App Engine повторит запрос (но не транзакцию).

Также были добавлены другие функции:

Для Python была добавлена библиотека AppStats RPC. AppStats позволит пользователям легко выполнять вызов к другим сервисам App Engine, исключить неэффективное кеширование и избыточные вызовы RPC в своих приложениях (для Java это пока находится на стадии бета-тестирования).

Для Java был добавлен новый фреймворк для юнит-тестов. Он позволит девелоперу проверять код своего App Engine приложения на корректность, а также даст возможность использовать другие существующие фреймворки для тестирования.

Полный список изменений и доработок можно прочитать здесь: Python, Java.

Скачать новый релиз SDK.

Вчера разработчики отписали, что приступили к реализации Issue 644. Уж не знаю, атаки ли из Китая повлияли, но приоритет ей выставлен в high, так что в ближайшем будущем этот функционал появится.

Там в комментах один из разработчиков попросил написать, какие фичи пользователи хотят видеть в этом сервисе, а также рассказать о подробностях атак на реальные проекты. Так что если вы заинтересованы — не поленитесь, отпишите, это поможет получше сформировать ядро сервиса.

Так что помимо MapReduce и Cursors (из roadmap), в приложениях довольно скоро появится и поддержка Firewall, a также Full Text Search.

Четвертая часть статьи, и вероятно — не последняя. Напомню, что предыдущие три статьи (а так же все последующие) теперь можно будет увидеть по этому адресу — статей много и проставлять в них навигационные ссылки друг на друга мне надоело;-)

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

Представление

Как вы знаете, такие слова как MVC уже давно стали даже не модными, а прям-таки подразумевающимеся (другой вопрос что понимает их всяк по своему). Наш пример не стал исключением — и теперь нам нужно объединить достижения контроллера и модели воедино и показать их пользователю. В этом нам немало поможет тот факт, что GAE внутри использует Django, механизм шаблонов которого является одним из самых лучших среди тех, которые я знаю. Одним из самых интересных, на мой взгляд, свойств шаблонов Django является то, что они поддерживают наследование.

Действительно, зачастую дизайн двух функционально разных страниц веб-сайта отличается лишь незначительно и использует общие элементы — header, footer, меню и т.д. Обидно будет дублировать этот код — и в то же время, всяческие include-директивы это все-таки вчерашний день. В Django вы можете наследовать один шаблон от другого.

Рассмотрим наш базовый шаблон, который можно найти в дереве исходников как templates/basic.html. Поскольку HTML на Хабр красиво вставляться не желает (и никакой Хабраредактор с этим справится не может), а некрасиво его читать — голову сломать можно, посмотрите его уж в SVN по ссылке выше. Суть не в этом. Суть в том, что в каких-то местах мы объявляем «заглушки»:

1. <div id='content'>
2. {% block content %} {% endblock %}
3. </div>

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

Контроллер

Какое-то время назад мы уже определили несколько URL в app.yaml — пора разобраться, как заставить приложение правильно «реагировать» на них. Вот так выглядят наши маппинги:

# $Id: app.yaml 4 2010-01-25 12:14:48Z sigizmund $

application: helloworld
version: 1
runtime: python
api_version: 1

handlers:
- url: /(stats|login)
  script: main.py
  login: required

- url: .*
  script: main.py

Как мы видим, определены три типа URL — /stats, /login и «всё остальное». Все три, что характерно, будут обработаны одним и тем же скриптом main.py, однако настройки отличаются — /stats и /login требуют наличия активной пользовательской сессии, в то время как для остальных это не обязательно. Давайте рассмотрим содержимое скрипта main.py:

В предыдущей статье мы выяснили, что такое Google AppEngine, что с ним можно делать, и создали самое простое и примитивное приложение для GAE — helloworld с минимальной поддержкой аутентификации пользователей. Попробуем расширить это приложение, рассмотрев, попутно, возможности Google AppEngine.

Структура и архитектура

Наше предыдущее приложение было предельно простым, и, как таковое, ни в какой архитектуре не нуждалось. Теперь мы ставим перед собой более сложную и более реальную задачу — соответственно, нам следует подумать о том, что будет, когда приложение начнет расти. Разумеется, наша задача выдумана и для нее никакой архитектуры тоже не требуется, но для примера попробуем все сделать «по науке».

Недавно я задал вопрос — было бы интересно хабралюдям почитать о том, как писать под Google AppEngine? Хабралюди сказали что да, интересно — ну я и решил начать. В этой статье мы рассмотрим следующие вопросы:

1. Ультра-краткое введение в Google AppEngine (GAE), что это такое и с чем его едят
2. Возможности и ограничения GAE
3. Супер-краткий обзор архитектуры GAE-приложения
4. Разработка минимального приложения с аутентификацией
5. Разработка более сложного, реального приложения на основе MyTwiLinks

Начнем с самого начала, с самого простого — совсем для нубов (каковым я и являлся, когда начал разбираться с GAE), постепенно продвигаясь к более сложным концепциям, заканчивая грязными хаками на тему «как быть, если нельзя, но очень надо» (почти наверняка не успеем в рамках этого поста, но доберемся обязательно).

Сравнительно недавно заинтересовался облачной платформой Google App Engine. Очень обрадовался, узнав, что App Engine поддерживает Django. Но, как оказалось, поддерживается только Django 0.96, а чтобы использовать свежую версию, требуется её загружать вместе с разрабатываемым проектом.
app-engine-patch — проект, позволяющий перенести максимально возможное количество функций Django в облачную платформу App Engine. Для того, чтобы пользоваться данным проектом, необходимо установить Python 2.5 и App Engine SDK.

Заинтересовавшись данным проектом, решил перевести документацию по app-engine-patch, так как она достаточно небольшая.
Выложил в Google Docs, если кому-нибудь понадобится. Перевод небольшой, но достаточно увесистый, чтобы публиковать его полностью в этом топике.
Замечу, что я не являюсь профессиональным переводчиком, и переводил для себя, поэтому прошу строго не судить.
Надеюсь, что кому-нибудь моя работа будет полезна.

Недавно был пост о сборе статистики в Google App Engine. Вот один из рецептов, который я использую для подобных целей:

#!/bin/bash
appcfg.py --num_days=10 request_logs code/ today.txt
visitors -A -m 50 -T --time-delta 10 --trails --prefix http://toptuby.appspot.com/ today.txt > today.html
firefox today.html

Так получается и показывается в браузере статистика за последние 10 дней для приложения toptuby.appspot.com

Одной из целей создания bullshitbingo.ru было посмотреть как ведёт себя google application engine (GAE) в более-менее реальных условиях. Особенно меня интересовала возможность получения собственной статистики, потому что то, что дают GAE и google analitics меня не устраивает по причинам, которые я приведу ниже. На сам пост особой реакции не было, но на главную он вышел и за день сайт получил примерно 15 тысяч загрузок, чего было вполне достаточно. Пик нагрузки составил 3-4 запроса в секунду, в итоге отведённый GAE лимит бесплатных ресурсов превышен не был.

Дальше описание особенностей работы со статистикой в GAE и во второй части графики про полученную нагрузку: собственные и те, которые формирует google. Постарался написать так, чтобы было понятно и тем, кто с GAE вообще не сталкивался.

Поддержка загрузки больших файлов (>1 мегабайта) — на данный момент это экспериментальная фича, и включено ограничение до 50МБ на файл. Загрузка происходит только через веб-форму (file upload), и никак иначе. Однако я думаю, что в ближайшем будущем будет и поддержка прямой закачки (как в Youtube API, где совсем недавно сделали прямые закачки).
Подробнее: java, python.

И так случилось то что давно ждали… И странно что ещё никто не написал, релиз то был 3 декабря.

Расширенная консоль администратора — новые инструменты для управления задачами и очередей созданные с Task Queue API, и более понятный index processing(а то блин ждёшь часами(днями)).

Улучшена совместимость Java — добавлена поддержка для новых операторов фильтров и наследования JPA и JDO, а также поддержка JAXB.

Новая поддержка приложений pre-compilation для сокращения продолжительности загрузки.(To enable pre-compilation on your application, add this flag to your appengine-web.xml:
<precompilation-enabled>true</precompilation-enabled>)

Low-level Memcache API now supports incrementAll()

HTTPResponse object now has getFinalUrl() method for 302 redirects.

Java Dev Appserver now automatically executes tasks. If you prefer the old behavior where tasks do not automatically execute you can use the --jvm_flag=-Dtask_queue.disable_auto_task_execution flag when starting the server.

Additional file extensions permitted when sending mail.

И куча фиксов…

ReleaseNotes

Downloads

Вчера я написал небольшое приложение на Django для Google App Engine, но выложить не смог, т.к. на мой номер не приходили SMS с auth. code. Я конечно огорчился, написал в поддержку Google, а сам стал думать что может это и к лучшему, ведь на нормальном хостинге и возможностей больше.

Но на следующий день мне пришло такое письмо:

Hello,

You're receiving this email because you indicated you'd had some problems verifying your Google App Engine account using SMS. We just wanted to let you know we've enabled your account--you should be able to create applications now!

To start creating applications with Google App Engine, simply follow this link:

appengine.google.com

Thanks!
The Google App Engine Team

По моему это образец правильного саппорта. Да, есть странное требование авторизации по SMS, но если у клиента с этим проблема, проблема будет решена.

За сутки, прошедшие со времени моего обращение в поддержку, я свыкся с мыслью о том, что мне надо искать нормального хостера и перенес весь код на нормальное Django. Но это другая история и мое отношение к Google как к компании стало только лучше.