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