Google App Engine *

Те, кто включил в своём приложении на GAE поддержку сессий, знают, что сессии, во-первых, записываются в datastore, а во-вторых, автоматически оттуда не исчезают. От протухших сессий надо как-то избавляться самостоятельно.

Я как-то не заботился о протухших сессиях, и за полтора года их накопилось полтора миллиона штук. Недавно размер хранимых в datastore данных превысил бесплатную квоту и, так как 99% было занято сессиями, я решил поудалять протухшие.

• Отмена 1000-лимита на запрос в хранилище для count и offset. Такие безлимитные запросы будут теперь исполняться до получения результата, или выкидывать ошибку по таймауту хранилища. Я сам слегка потестировал — есть небольшие тормоза на средней базе в пару миллионов записей при смещении в миллион (порядка пары-тройки секунд задержка), однако вполне годно. Хотя, судя по коду SDK, максимальный лимит все же есть, равный 2^31 — 1.
• Новое Namespaces API для Java и Python, которое позволяет создавать «коммунальные» (multi-tenancy) приложения без особых модификаций уже существующего кода.
• Замена сервиса картинок на высокопроизводительное решение, основанное на picasa, что позволит делать превьюшки картинок (crop и/или resize), фактически без использования ваших ресурсов (только трафик) в добавлении к предыдущим умениям Image API.
• Пользовательские страницы для системных ошибок — over quota, DoS, timeout и прочих.
• В Java добавлено Capabilities API, по аналогии с Питоном, а также java-приложения научились понимать конфиги в yaml-формате.
• Многие фиксированные квоты бесплатных приложений увеличились до уровня платных, подробнее.
• Blobstore API теперь поддерживает Content-Range заголовок.

Полные списки изменений:
— Release Notes: Python
— Release Notes: Java
— Revision History

В рассылке Google Alerts наткнулся на интересный ресурс — сайт со списком разработчиков со всего мира под платформу Google App Engine.


Своей целью, создатели сайта, называют

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

Итак,
— Увеличение квот TaskQueue с 50 запросов на приложение до 50 запросов на очередь, в последующих резилах ожидаются дальнейшие улучшения этого сервиса.
— Возможность настройки лимита хранилища для TaskQueue.
— Прекомпиляция для Python, в настоящее время отключена по умолчанию, включается в конфиге.
— Добавлены программные интерфейсы для доступа к blob-файлам напрямую из приложения. Идет работа над созданием и редактированием blob из приложения, пока не готово.
— Для local python SDK задания теперь выполняются автоматически.

Из изменений видно, что текущий релиз был в контексте развития технологии MapReduce для AppEngine, о ней речь пойдет ниже.

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