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 для Вас?➔ Попробуйте!➔ Учиться, Учиться … и еще раз учиться

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