Our AWS Journey
Presented by Andrew Boag
предисловие: о Catalyst (нас) и инфраструктуре
➔ У нас есть собственный дата-центр
➔ Catalyst берет ответственность за сер...
MOOC - open2study
➔ MOOC = Massive Open Online Course
➔ Moodle + Drupal + simpleSAMLphp
➔ Посмотрите Open2study.com
➔ Проэ...
Алло
➔ Клиент позвонил нам в ноябре 2012
➔ Вы с ума сошли, что ли?
Наша дорога - AWS
➔ Клиент выбрал AWS
➔ AWS появилось в Сиднее в ноябре 2012
Общие впечетления от AWS
➔ Чем больше работашь с AWS, тем больше понимаешь его силу
➔ Некоторые AWS службы реально способс...
Отказоустойчивая Архитехтура
➔ Скот - не домашные животные
➔ Любой компонент может отказать в любой момент и архитехтура
н...
AWS Auto Scaling
➔ Super cool!!!
Примерный AWS Architecture
Clustered File Systems – GlusterFS
➔ Зачем Network Storage?
➔ Мы работали с: NFS, OCFS2 (Oracle), DRBD, CEPH … даже rsync
...
Наша AWS Architecture политика
➔ Применяем AWS инструменты когда можем
➔ Автоматизация – это хорошо
➔ Мы в тренде AWS
➔ До...
AWS Deployments
➔ Немножко другие правила
➔ Есть много подходов
➔ Мы не стали работать с ElasticBeanstalk
➔ В последнее вр...
Некоторые моменты
➔ Мы не запускаем код на production серверах
➔ Мы используем Debian package, чтобы разместить новый код ...
Load testing in AWS
➔ Иногда AWS DOS защита воспринимает Load testing как DOS
атаку. Это проблема
➔ Нужно постепенно увели...
Bees with Mechs – For User Stories
➔ Применили Bees with Machine Guns (от Chicago Tribune), чтобы
строить собственный bot ...
Performance
➔ Настроили Apache, чтобы не искать .htaccess на glusterFS
➔ Web service оптимизация (общение между компонента...
SQS – Применение Simple Queue System
➔ Очередь не только в ночные клубы!
➔ Очереди очень классно используются для Load Tol...
RDS – не совсем MySQL
➔ Доступ к логам был проблематичным – теперь есть доступ
➔ Некоторые вещи не включенны по умолчанию ...
AWS Мониторинг
➔ Мы мониторим извне (наш nagios живет в другом дата-центре)
➔ Cloudwatch капризничает
➔ Из за того, что ко...
AWS Билинг
➔ Некоторые вещи дорогие
➔ Некоторые дешевые
➔ Некоторые вещи непонятные
➔ Иногда клиент предоставляет свой акк...
То, что нам понравилось
➔ Гибкость (не надо ждать)
➔ Auto Scaling
➔ AWS API – CloudWatch metrics (очень мошьно)
➔ Cloudwat...
Ошибки, которые мы видели
➔ Построение AWS-стека как традиционной архитехтуры
➔ Отсуствие отказоустойчивости
➔ Неправильны...
Еще моменты
➔ Найти экспертов не легко
➔ как можно больше общаться с AWS Solutions Architects
➔ Надо быть в тренде AWS
➔ П...
AWS и Ваши данные
➔ Где наши данные?
➔ Это сложная, большая тема
➔ Privacy vs Secrecy
AWS для Вас?
➔ Попробуйте!
➔ Учиться, Учиться … и еще раз учиться
Вопросы
➔ Спасибо за внимание
Upcoming SlideShare
Loading in …5
×

Our AWS Cloud Journey - Andrew Boag

419 views
317 views

Published on

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.

Published in: Internet
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
419
On SlideShare
0
From Embeds
0
Number of Embeds
46
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Our AWS Cloud Journey - Andrew Boag

  1. 1. Our AWS Journey Presented by Andrew Boag
  2. 2. предисловие: о Catalyst (нас) и инфраструктуре ➔ У нас есть собственный дата-центр ➔ Catalyst берет ответственность за сервера, физически расположенные у клиента ➔ Мы любим Ubuntu linux, но так же работаем с Red Hat ➔ У нас есть опыт работы с AWS и Rackspace OpenStack ➔ Мы любим Open Source ➔ Catalyst является Amazon Partner ➔ Catalyst недавно запустил собственный OpenStack Cloud в Новой Зеландии
  3. 3. MOOC - open2study ➔ MOOC = Massive Open Online Course ➔ Moodle + Drupal + simpleSAMLphp ➔ Посмотрите Open2study.com ➔ Проэкт Open Universities Australia – начался в середине 2012, запуск апрель 2013 ➔ Польностю Agile Project Management
  4. 4. Алло ➔ Клиент позвонил нам в ноябре 2012 ➔ Вы с ума сошли, что ли?
  5. 5. Наша дорога - AWS ➔ Клиент выбрал AWS ➔ AWS появилось в Сиднее в ноябре 2012
  6. 6. Общие впечетления от AWS ➔ Чем больше работашь с AWS, тем больше понимаешь его силу ➔ Некоторые AWS службы реально способствуют быстрому и гибкому запуску решений ➔ Очень быстро развивается ➔ Если правильно применять - выходит дешевле (по крайне мере в Австралии)
  7. 7. Отказоустойчивая Архитехтура ➔ Скот - не домашные животные ➔ Любой компонент может отказать в любой момент и архитехтура не должна рухнуть ➔ Пример: FEs в Auto Scale Group ➔ Single Point of Failure - нельзя ➔ AWS Solution Architects – умные парни
  8. 8. AWS Auto Scaling ➔ Super cool!!!
  9. 9. Примерный AWS Architecture
  10. 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. 11. Наша AWS Architecture политика ➔ Применяем AWS инструменты когда можем ➔ Автоматизация – это хорошо ➔ Мы в тренде AWS ➔ Достаточно часто общаемся с AWS Solution Architect
  12. 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. 13. Некоторые моменты ➔ Мы не запускаем код на production серверах ➔ Мы используем Debian package, чтобы разместить новый код на сервере
  14. 14. Load testing in AWS ➔ Иногда AWS DOS защита воспринимает Load testing как DOS атаку. Это проблема ➔ Нужно постепенно увеличивать обьем траффика, чтобы дополнительные ELB (Load Balancer) активировались ➔ Жесткое применение JMeter не всегда работает.
  15. 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. 16. Performance ➔ Настроили Apache, чтобы не искать .htaccess на glusterFS ➔ Web service оптимизация (общение между компонентами) ➔ Varnish + boost ➔ memcached ➔ Много итераций
  17. 17. SQS – Применение Simple Queue System ➔ Очередь не только в ночные клубы! ➔ Очереди очень классно используются для Load Tolerance ➔ Очереди помогают интеграции между сервисами
  18. 18. RDS – не совсем MySQL ➔ Доступ к логам был проблематичным – теперь есть доступ ➔ Некоторые вещи не включенны по умолчанию – например кеширование ➔ Подход к мониторингу отличается ➔ Multi-AZ RDS оптимальный вариант ➔ Легко делается Read-replica (аналитика)
  19. 19. AWS Мониторинг ➔ Мы мониторим извне (наш nagios живет в другом дата-центре) ➔ Cloudwatch капризничает ➔ Из за того, что компоненты могут отказать, появляются новые нюансы ➔ Мы мониторим через VPN – это не всегда удобно ➔ Auto Scale мониторинг имеет свои особенности ➔ Еще вопрос: должны ли мы мониторить AWS. Например: RDS read replica.
  20. 20. AWS Билинг ➔ Некоторые вещи дорогие ➔ Некоторые дешевые ➔ Некоторые вещи непонятные ➔ Иногда клиент предоставляет свой аккаунт ➔ Приходится сталкиваться с новыми проблемами клиента ➔ Есть гибкость в плане инфраструктуры ➔ Reserved Instances – очень толково
  21. 21. То, что нам понравилось ➔ Гибкость (не надо ждать) ➔ Auto Scaling ➔ AWS API – CloudWatch metrics (очень мошьно) ➔ Cloudwatch graphs – удобно ➔ Load Testing возможности ➔ OpsWorks / Cloudformation ➔ Консультирование с AWS Solutions Architects
  22. 22. Ошибки, которые мы видели ➔ Построение AWS-стека как традиционной архитехтуры ➔ Отсуствие отказоустойчивости ➔ Неправильный мониторинг ➔ Когда девелопер без навыков занимается архитехтурой ➔ Неприятие Amazon Way ➔ AWS Business Support нужная вещь
  23. 23. Еще моменты ➔ Найти экспертов не легко ➔ как можно больше общаться с AWS Solutions Architects ➔ Надо быть в тренде AWS ➔ Привязанность к AWS ➔ Cloudwatch хранит только две недели логов
  24. 24. AWS и Ваши данные ➔ Где наши данные? ➔ Это сложная, большая тема ➔ Privacy vs Secrecy
  25. 25. AWS для Вас? ➔ Попробуйте! ➔ Учиться, Учиться … и еще раз учиться
  26. 26. Вопросы ➔ Спасибо за внимание

×