Catalyst IT is one of Australia's largest open source software houses. We are all about using the awesome array of tools at our disposal from the FOSS (Free and Open Source) spectrum. In Nov 2012, Catalyst was engaged by a major Australian university to help them pioneer an Australian MOOC (Massive Open Online Course) application - Open2Study.com From the outset, the application was to be hosted on AWS (Amazon Web Services). Catalyst had experience with applications on AWS but the scale and business requirements of Open2Study meant there was a lot for us to learn and master throughout the build and deployment. The application is a customised extension of Drupal, Moodle and simpleSAMLphp. Moodle is an open source LMS (Learning Management System) Coming from a background of deployment onto both physical and virtual hardware, Catalyst was used to working within the confines of various linux environments. Building and deploying our application into a full AWS environment gave us a great opportunity to get to grips with the power and challenges associated with Amazon's infrastructure-as-a-service offering.

1. Our AWS Journey
Presented by Andrew Boag

2. предисловие: о Catalyst (нас) и инфраструктуре
➔ У нас есть собственный дата-центр
➔ Catalyst берет ответственность за сервера, физически
расположенные у клиента
➔ Мы любим Ubuntu linux, но так же работаем с Red Hat
➔ У нас есть опыт работы с AWS и Rackspace OpenStack
➔ Мы любим Open Source
➔ Catalyst является Amazon Partner
➔ Catalyst недавно запустил собственный OpenStack Cloud в Новой
Зеландии

3. MOOC - open2study
➔ MOOC = Massive Open Online Course
➔ Moodle + Drupal + simpleSAMLphp
➔ Посмотрите Open2study.com
➔ Проэкт Open Universities Australia – начался в середине 2012,
запуск апрель 2013
➔ Польностю Agile Project Management

4. Алло
➔ Клиент позвонил нам в ноябре 2012
➔ Вы с ума сошли, что ли?

5. Наша дорога - AWS
➔ Клиент выбрал AWS
➔ AWS появилось в Сиднее в ноябре 2012

6. Общие впечетления от AWS
➔ Чем больше работашь с AWS, тем больше понимаешь его силу
➔ Некоторые AWS службы реально способствуют быстрому и
гибкому запуску решений
➔ Очень быстро развивается
➔ Если правильно применять - выходит дешевле (по крайне мере в
Австралии)

7. Отказоустойчивая Архитехтура
➔ Скот - не домашные животные
➔ Любой компонент может отказать в любой момент и архитехтура
не должна рухнуть
➔ Пример: FEs в Auto Scale Group
➔ Single Point of Failure - нельзя
➔ AWS Solution Architects – умные парни

8. AWS Auto Scaling
➔ Super cool!!!

9. Примерный AWS Architecture

10. Clustered File Systems – GlusterFS
➔ Зачем Network Storage?
➔ Мы работали с: NFS, OCFS2 (Oracle), DRBD, CEPH … даже rsync
… нет идеального варианта
➔ NFS не подходит для AWS. Single point of failure
➔ Мы были чайниками в плане GlusterFS.
➔ Clustered Filesystem != Legacy File System
➔ Есть доля черной магии
➔ Решает Одни проблемы, создает другие
➔ Не для всех ситуации
➔ Иногда S3 лучше как storage

11. Наша AWS Architecture политика
➔ Применяем AWS инструменты когда можем
➔ Автоматизация – это хорошо
➔ Мы в тренде AWS
➔ Достаточно часто общаемся с AWS Solution Architect

12. AWS Deployments
➔ Немножко другие правила
➔ Есть много подходов
➔ Мы не стали работать с ElasticBeanstalk
➔ В последнее время активно работаем с AWS OpsWorks –
Orchestration
➔ Наш Оригинальный подход
➔ python script с помощью AWS API:
● Делаем snapshot Admin Deploy EC2 как AMI после того как
deployment сделан
● Добавляем новый AMI template к AWS Auto Scale group
● Настраиваем Auto Scale Group для того, чтобы заместить Front
End Server (между AWS Availability Zone)
● Новые EC2 сервера запускаются

13. Некоторые моменты
➔ Мы не запускаем код на production серверах
➔ Мы используем Debian package, чтобы разместить новый код на
сервере

14. Load testing in AWS
➔ Иногда AWS DOS защита воспринимает Load testing как DOS
атаку. Это проблема
➔ Нужно постепенно увеличивать обьем траффика, чтобы
дополнительные ELB (Load Balancer) активировались
➔ Жесткое применение JMeter не всегда работает.

15. Bees with Mechs – For User Stories
➔ Применили Bees with Machine Guns (от Chicago Tribune), чтобы
строить собственный bot net.
➔ Мы поменяли “machine gun” на multimech (Mechanize)
➔ Мы написали некоторые “user journeys” (Mechanize), которые
запускались средством Bees with Machine Guns.
➔ Мы использоавали больше 100 IP адресов (иначе будет DOS
защита)

16. Performance
➔ Настроили Apache, чтобы не искать .htaccess на glusterFS
➔ Web service оптимизация (общение между компонентами)
➔ Varnish + boost
➔ memcached
➔ Много итераций

17. SQS – Применение Simple Queue System
➔ Очередь не только в ночные клубы!
➔ Очереди очень классно используются для Load Tolerance
➔ Очереди помогают интеграции между сервисами

18. RDS – не совсем MySQL
➔ Доступ к логам был проблематичным – теперь есть доступ
➔ Некоторые вещи не включенны по умолчанию – например
кеширование
➔ Подход к мониторингу отличается
➔ Multi-AZ RDS оптимальный вариант
➔ Легко делается Read-replica (аналитика)

19. AWS Мониторинг
➔ Мы мониторим извне (наш nagios живет в другом дата-центре)
➔ Cloudwatch капризничает
➔ Из за того, что компоненты могут отказать, появляются новые
нюансы
➔ Мы мониторим через VPN – это не всегда удобно
➔ Auto Scale мониторинг имеет свои особенности
➔ Еще вопрос: должны ли мы мониторить AWS. Например: RDS
read replica.

20. AWS Билинг
➔ Некоторые вещи дорогие
➔ Некоторые дешевые
➔ Некоторые вещи непонятные
➔ Иногда клиент предоставляет свой аккаунт
➔ Приходится сталкиваться с новыми проблемами клиента
➔ Есть гибкость в плане инфраструктуры
➔ Reserved Instances – очень толково

21. То, что нам понравилось
➔ Гибкость (не надо ждать)
➔ Auto Scaling
➔ AWS API – CloudWatch metrics (очень мошьно)
➔ Cloudwatch graphs – удобно
➔ Load Testing возможности
➔ OpsWorks / Cloudformation
➔ Консультирование с AWS Solutions Architects

22. Ошибки, которые мы видели
➔ Построение AWS-стека как традиционной архитехтуры
➔ Отсуствие отказоустойчивости
➔ Неправильный мониторинг
➔ Когда девелопер без навыков занимается архитехтурой
➔ Неприятие Amazon Way
➔ AWS Business Support нужная вещь

23. Еще моменты
➔ Найти экспертов не легко
➔ как можно больше общаться с AWS Solutions Architects
➔ Надо быть в тренде AWS
➔ Привязанность к AWS
➔ Cloudwatch хранит только две недели логов

24. AWS и Ваши данные
➔ Где наши данные?
➔ Это сложная, большая тема
➔ Privacy vs Secrecy

25. AWS для Вас?
➔ Попробуйте!
➔ Учиться, Учиться … и еще раз учиться

26. Вопросы
➔ Спасибо за внимание