Блог Amazon Web Services https://aws.amazon.com/ru/blogs/rus/ Thu, 23 Nov 2017 10:29:39 +0000 ru-RU hourly 1 Базовые меры по предотвращению инцидентов при работе с AWS https://aws.amazon.com/ru/blogs/rus/incidents-prevention/ Thu, 23 Nov 2017 10:29:39 +0000 4455b043bc374fc06c2f6acf04d7253b85f322ea Андрей Зайчиков, Архитектор AWS В IT практике мы нередко сталкиваемся с неприятными инцидентами при работе с инфраструктурой. Частыми причинами возникновения непредвиденных ситуаций становятся: ошибки при обслуживании и поддержке инфраструктуры (удаление или некорректное изменение ресурсов авторизованным персоналом); ошибки и недоработки при проектировании приложений (hardcode конфигурации, отсутствие корректной обработки ошибок, проч.); взломы приложений и атаки на инфраструктуру. […] <p style="text-align: right"><em><a href="http://www.linkedin.com/in/zaychikov">Андрей Зайчиков</a>, Архитектор AWS</em></p> <p>В IT практике мы нередко сталкиваемся с неприятными инцидентами при работе с инфраструктурой. Частыми причинами возникновения непредвиденных ситуаций становятся:</p> <ul> <li>ошибки при обслуживании и поддержке инфраструктуры (удаление или некорректное изменение ресурсов авторизованным персоналом);</li> <li>ошибки и недоработки при проектировании приложений (hardcode конфигурации, отсутствие корректной обработки ошибок, проч.);</li> <li>взломы приложений и атаки на инфраструктуру.</li> </ul> <p>Довольно часто инциденты происходят одновременно или последовательно – один за другим. Это происходит потому, что людям в стрессовой ситуации сложно что-то менять в инфраструктуре / приложении, одновременно пытаясь отразить атаки и восстановить работоспособность системы. Именно поэтому предельно важно по возможности подготовиться к решению инцидентов заранее, а также выполнить ряд мер для их предотвращения.</p> <p>В этом посте мы рассмотрим ряд простых правил, которые помогут вам сократить вероятность возникновения инцидентов, а также начать оптимизировать собственную инфраструктуру и процессы её сопровождения.</p> <h3>Один на редкость счастливый день</h3> <p>Начнем мы с примера ситуации, реально возникшей у одной крупной компании.</p> <p>В один прекрасный солнечный день SysOps инженер, ответственный за проведение обновления backend для мобильных приложений, случайно удалил основную Hosted Zone в Route53. В результате, несколько миллионов мобильных приложений потеряли возможность взаимодействия с собственным backend. TTL для DNS был установлен на 24 часа, обновить конфигурацию приложений было нельзя, так как она зашита в код … занавес? Но не тут-то было.</p> <p>Новость о проблемах в работе компании быстро распространилась на просторах интернета и привлекла профессиональных хакеров.</p> <p>В самое короткое время начались атаки на различные ресурсы компании две из которых увенчались успехом.</p> <p>Одна из атак – классическая SQL Injection была проведена знаменитым в регионе хакером. Факт успешной атаки он незамедлительно опубликовал в своем блоге.</p> <p>Через некоторое время другой &laquo;специалист&raquo; по ИБ в поиске ключей доступа смог найти в коде мобильного приложения прямо в виде строковых переменных Access Key и Secret Access Key IAM пользователя с правами администратора. Думаю, излишне говорить, насколько это серьезно. К счастью, команда поддержки уже находилась в режиме постоянной готовности – они смогли зафиксировать взлом и оперативно устранить его последствия. Как результат – мобильное приложение лишилось возможности работать с некоторыми ресурсами backend, так как основной IAM User этого приложения был скомпрометирован.</p> <p>Довольно естественно, после таких событий коллеги начали оперативно искать алгоритм для максимально быстрого выравнивания ситуации и предотвращения возникновения инцидентов в будущем.</p> <h3>Алгоритм решения проблем</h3> <p>Предложенный алгоритм состоял из шести простых и довольно быстро выполнимых шагов.</p> <ol> <li>Проверка и тегирование ресурсов</li> <li>Проверка IAM политик и доступа к ресурсам AWS</li> <li>Включение логирования и мониторинга</li> <li>Выполнение сканирования безопасности</li> <li>Проверка текущего состояния баз данных</li> <li>Покомпонентная проверка DR</li> </ol> <p>Выполнение этого алгоритма позволило коллегам достаточно быстро нормализовать ситуацию, корректно распределить ответственность и снять давление с разработчиков и SysOps команды.</p> <p>Далее мы детально рассмотрим каждый шаг описанного нами алгоритма.</p> <h3>Шаг 1: Проверка и тегирование ресурсов</h3> <p>Вам наверняка интересно, почему проверка и тегирование ресурсов была поставлена на первое место в такой сложной ситуации. Дело в том, что у коллег не существовало вменяемой схемы маркировки ресурсов и документации. Например, существовали ресурсы с именованием наподобие PLEASE_DO_NOT_DELETE_UNTIL_28/09.</p> <p>Не зная, какие ресурсы к чему относятся, зачем они нужны и насколько их существование критично, невозможно ни установить приоритеты устранения уязвимостей, ни корректно определить права на ресурсы, ни определить порядок решения инцидентов. Да и читать логи становится крайне затруднительно.</p> <p>Для начала мы определили простую схему тегирования ресурсов:</p> <ul> <li>Наименование ресурса в формате uid:function:system</li> <li>Владелец ресурса (подразделение или специалист)</li> <li>Среда, к которой относится тот или иной ресурс</li> <li>Критичность данного ресурса для работоспособности основных систем</li> <li>Возможности DR для конкретного ресурса (backup / replication / auto-scaling и проч.)</li> </ul> <p>После определения схемы ресурсов необходимо было выполнить собственно процедуру тегирования. Технически выполнить это не сложно, однако, некоторое время ушло на разбор – какие ресурсы кому принадлежат и для чего они нужны.</p> <p>Применение тегов для различных групп ресурсов выполняется по-разному. Более подробную информацию можно найти тут:</p> <ul> <li>Для сред <a href="http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.tagging.html">Elastic Beanstalk</a>;</li> <li>Для <a href="http://docs.aws.amazon.com/autoscaling/latest/userguide/autoscaling-tagging.html">Auto Scaling</a> групп;</li> <li>Для <a href="http://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/tag-editor.html">различных ресурсов с помощью Management Console</a>.</li> </ul> <p>После того, как схема тегов применена и все ресурсы промаркированы можно выполнить реверс генерацию архитектурной диаграммы c использованием различных инструментов, таких как VisualOps, Hava, Lucidchart и других.</p> <h3>Шаг 2: Проверка IAM политик и доступа</h3> <p>Проверка IAM политик и способов организации доступа к ресурсам AWS – один из наиболее критичных процессов с точки зрения сокращения вероятности возникновения инцидентов.</p> <ul> <li>Средства аутентификации пользовательских приложений;</li> <li>Средства аутентификации администраторов;</li> <li>Средства аутентификации backend приложений;</li> <li>Политики прав доступа пользовательских ролей;</li> <li>Политики прав доступа администраторов и их ролей;</li> <li>Политики прав доступа приложений.</li> </ul> <p>Важность проверки и корректировки политик доступа сложно переоценить. В ситуации, когда первый инцидент случился по вине конкретного инженера, а данные о ресурсах и их назначении восстановлены по памяти, отсутствие вменяемых и контролируемых политик разграничения прав доступа дополнительно давит на специалистов и увеличивает риск нарушения работы системы вследствие ошибок обслуживающего персонала. Естественно, когда пользователи с административными правами &laquo;зашиты&raquo; в код приложения, это также усложняет жизнь разработчикам.</p> <p>Для проверки и корректировки политик доступа к ресурсам мы предложили следующий простой алгоритм.</p> <ol> <li>Основываясь на результатах тегирования ресурсов и с помощью архитектурных диаграмм / других артефактов идентифицируется список критически важных ресурсов.</li> <li>Для каждого типа критически важных ресурсов идентифицируется список потенциально опасных действий (Actions). К таким действиям может относиться: <ul> <li>Удаление вычислительных ресурсов (EC2, RDS, ElasticCache, RedShift);</li> <li>Удаление прочих ресурсов (DynamoDB tables, DynamoDB streams, S3 buckets, SQS queues, SNS topics, SES mailing lists, Lambda functions, VPN Gateways, Internet Gateways, VPC Routes)</li> <li>Модицификация политик (IAM Policies, Bucket policies, Security Groups Ingress/Egress rules, nACL Ingress/Egress rules).</li> </ul> </li> <li>Для комбинации потенциально опасных действий над критически важными ресурсами создаются и тестируются отдельные политики, при этом список ресурсов может быть ограничен условиями (<a href="http://docs.aws.amazon.com/AmazonS3/latest/dev/amazon-s3-policy-keys.html">Condition: Tag</a>). Дополнительно, можно добавить необходимость <a href="http://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_enable_virtual.html">ввода MFA кода</a> для выполнения опасных действий.</li> <li>Для выполнения потенциально опасных действий создаются специальные роли, при этом лучше не объединять все действия в одну политику / роль. Для пользователей / групп пользователей создается Assume Role Policy, которая позволяет применять роль к IAM пользователю (позволяет пользователю потреблять роль).</li> <li>После того, как роли созданы и политики назначены, а также после тестирования возможности применения данных ролей, необходимо переопределить политики административного доступа, в которых нужно запретить выполнять потенциально опасные действия с критически важными ресурсами.</li> </ol> <p>Более подробную информацию можно найти тут:</p> <ul> <li><a href="http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html">IAM roles for EC2</a>;</li> <li><a href="http://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html">Secure Token Service</a> для ротации Credentials приложениями;</li> <li><a href="https://aws.amazon.com/cognito/">AWS Cognito</a> для аутентификации и авторизации пользователей мобильных приложений (с функцией ротации Credentials);</li> <li><a href="http://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html">MFA protected API access</a>.</li> </ul> <h3>Шаг 3: Включение логирования и мониторинга</h3> <p>После того, как все ресурсы известны и права на них корректно распределены и ограничены можно приступить к корректной настройке логирования и мониторинга. Оба эти процесса играют ключевую роль для любого SysOps специалиста и на сегодняшний момент существует огромное количество средств и инструментов, обеспечивающих сбор метрик, логов, их корректное представление и анализ. В некоторой мере, настройка этих инструментов постепенно превращается в искусство.</p> <p>Этой теме посвящено большое количество различных постов и даже книг, поэтому, здесь мы ограничимся кратким обзором того, что можно сделать с использованием уже существующих платформенных сервисов логирования и мониторинга.</p> <h4>Логирование</h4> <p>В AWS существует значительное количество инструментов для сбора самых разнообразных логов.</p> <p>В первую очередь необходимо обратить внимание на логирование доступа пользователей и приложений / скриптов к API AWS. Для этого используется сервис под названием Amazon CloudTrail. Этот сервис рекомендуется применять всегда и хранить его логи в течение продолжительного времени (например, в течение одного года). Данные полученные с использованием AWS CloudTrail можно использовать не только в качестве отличного материала для анализа работы пользователей и приложений с инфраструктурой AWS, но и для обоснования финансовых запросов в AWS.</p> <p>Включить CloudTrail <a href="https://aws.amazon.com/blogs/aws/aws-cloudtrail-update-turn-on-in-all-regions-use-multiple-trails/">очень просто</a>.</p> <p>Для анализа логов CloudTrail можно использовать различные инструменты. В первую очередь это <a href="http://docs.aws.amazon.com/awscloudtrail/latest/userguide/send-cloudtrail-events-to-cloudwatch-logs.html">Cloud Watch Logs</a>. Кроме того, существует большое количество сторонних приложений, предназначенных в том числе для анализа логов CloudTrail. Список этих инструментов приведен <a href="https://aws.amazon.com/cloudtrail/partners/">здесь</a>.</p> <p>Кроме перечисленных сервисов, полезными источниками логов могут быть:</p> <ul> <li><a href="http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/flow-logs.html">VPC Flow Logs</a> (в основном используются в критичной инфраструктуре / для поиска проблем на сетевом уровне)</li> <li><a href="http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/access-log-collection.html">ELB Logs</a>;</li> <li><a href="http://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html">ALB Logs</a>;</li> <li><a href="http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/AccessLogs.html">CloudFront Logs</a>;</li> <li><a href="http://docs.aws.amazon.com/AmazonS3/latest/UG/ManagingBucketLogging.html">S3 Bucket Logs</a>.</li> </ul> <p>Для сбора и анализа всех логов в качестве базового инструмента можно использовать уже упомянутый выше функционал Amazon CloudWatch – CloudWatch Logs. Он предоставляет базовую функциональность сбора и просмотра логов, однако для анализа логов потребуется применять регулярные выражения. В качестве еще одной удобной функции можно упомянуть интеграцию с SNS и возможность генерировать и отправлять alert’ы при появлении определенных ошибок.</p> <p>Другим популярным вариантом инструментов для сбора и анализа логов является комбинация ELK (ElasticSearch + Logstash + Kibana) или её <a href="https://aws.amazon.com/blogs/aws/cloudwatch-logs-subscription-consumer-elasticsearch-kibana-dashboards/">вариации</a>, в том числе с заменой Logstash на CloudWatch Logs и использованием сервиса Amazon Elasticsearch. Такая схема позволяет существенно кастомизировать процессы анализа логов и при этом не фокусироваться на выделении ресурсов и управлении ими.</p> <h4>Мониторинг</h4> <p>Основным сервисом мониторинга на платформе AWS является Amazon CloudWatch. Этот сервис предоставляет достаточно широкие возможности по организации мониторинга сервисов AWS, а также решений, размещенных на платформе.</p> <p>Amazon CloudWatch предоставляет значительное количество предопределенных метрик (список можно посмотреть <a href="http://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html">здесь</a>), которые позволяют быстро и эффективно настраивать мониторинг ресурсов. При этом, интеграция CloudWatch с другими сервисами AWS уже выполнена.</p> <p>Кроме того, CloudWatch позволяет создавать и использовать кастомизированные метрики для унификации процесса мониторинга приложений / специфических особенностей инфраструктуры. Также для организации мониторинга можно использовать сторонние приложения / системы партнеров AWS.</p> <h3>Шаг 4: Выполнение сканирования безопасности</h3> <p>Сканирование безопасности – важный шаг, который, по опыту, лучше всего выполнять после того, как все ресурсы известны, доступ обеспечен в необходимом объеме, а также все средства мониторинга и логирования настроены и позволят контролировать результаты сканирования и выявлять конкретные особенности работы приложений и инфраструктуры.</p> <p>При организации сканирования ИБ необходимо уведомлять AWS о проведении процедур сканирования с использованием следующей <a href="https://aws.amazon.com/premiumsupport/knowledge-center/penetration-testing/">формы</a>. При этом, если для сканирования применяются средства, прошедшие проверку со стороны AWS и получившие разрешение на использование для сканирования, уведомление посылать не нужно.</p> <p>Проверка ИБ может состоять из нескольких основных шагов:</p> <ul> <li>ASV сканирование периметра вычислительной сети (VPC и собственной сети) – можно использовать ASV провайдеров сертифицированных <a href="https://www.pcisecuritystandards.org/assessors_and_solutions/approved_scanning_vendors">PCI Council</a>;</li> <li>Сканирование уязвимостей с помощью <a href="https://aws.amazon.com/inspector/">Amazon Inspector</a> или <a href="https://aws.amazon.com/marketplace/search/results?x=0&amp;y=0&amp;searchTerms=Pre-Authorized+Scanning&amp;page=1&amp;ref_=nav_search_box">сторонних инструментов</a>;</li> <li>Penetration тестирование (в случае необходимости / требований регуляторов, например, по требованиям PCI\DSS).</li> </ul> <p>На основании проверки результатов сканирования ИБ необходимо принять меры по устранению выявленных рисков и проблем. В числе подобных мер могут быть:</p> <ul> <li>Откорректировать правила фильтрации трафика Security Groups и Network Access Control Lists;</li> <li>Реализовать Web Application Firewall и интегрировать его с собственными приложениями;</li> <li>Обновить программное обеспечение и операционные системы;</li> <li>Изменить парольные политики / пароли используемые для доступа к стороннему ПО (базы данных, сервера приложений, сервлет контейнеры и проч.);</li> <li>Изменить средства аутентификации и авторизации (например, перейти на использование одноразовых токенов вместо использования IAM User Credentials);</li> <li>Обеспечить контроль целостности на уровне операционных систем, конфигурационных файлов, сторонних приложений и проч. (например, с использованием OSSEC);</li> </ul> <p>Естественно, перечисленные выше шаги – это только малая часть того объема мер, которые возможно и, нередко, необходимо применять. Хорошей практикой является встраивание проверок ИБ в релизный цикл и реализация данных процедур на периодической основе.</p> <h3>Шаг 5: Проверка текущего состояния баз данных</h3> <p>Большинство информационных систем, с которыми мы работаем, хранит структурированную и полу-структурированную информацию в базах данных. Соответственно, одним из важнейших аспектов сокращения вероятности серьезного инцидента и повышения шансов устранить последствия инцидента без существенных потерь является обеспечение disaster recovery на уровне баз данных.</p> <p>При этом, естественно, необходимо помнить о таких параметрах восстановления баз данных, как Recovery Point Objective и Recovery Time Objective. Кроме того, нельзя забывать, что наличие репликации и различных high availability опций для БД не отменяет необходимость создания бекапов. Это релевантно не только для RDBMS, но также и для различных NoSQL БД.</p> <p>Итак, с точки зрения проверки состояния БД желательно:</p> <ul> <li>Проверить наличие бекапов и процедур их автоматического создания в рамках, определенных RPO;</li> <li>Проверить специфику использования баз данных – не хранится ли важная информация в БД кеша (Redis, Memcached, etc.) / поисковом движке (Solr, ElasticSearch) в единственном экземпляре, не запускаются ли ETL процедуры на мастер-базе и проч.;</li> <li>Проверить специфику установки БД и определить потоки данных (в том числе с использованием ETL процедур, специализированных приложений, MQ систем), определить необходимость / наличие реализации HA &amp; DR процедур для этих компонент;</li> <li>По возможности обеспечить выполнение процедур ротации параметров доступа к БД со стороны приложений / пользователей;</li> <li>Обеспечить специфическое для конкретной БД покрытие средствами мониторинга / логирование.</li> </ul> <h3>Шаг 6: Покомпонентная проверка DR</h3> <p>В качестве последнего шага мы рекомендуем выполнить покомпонентную проверку DR вашей системы. Первую итерацию такой проверки лучше проводить на тестовой среде и переносить результаты проверки на продуктивную систему (проверять наличие процедур, настройки и проч.).</p> <p>Среди тех вещей, которые необходимо проверять, можно отметить:</p> <ul> <li>Проверка бекапов: <ul> <li>Конфигурационных файлов Infrastructure-as-a-Code (CloudFormation, Elastic Beanstalk, Terraform, etc.);</li> <li>Эталонных EBS snapshot’ов и образов AMI;</li> <li>Баз данных / файловых хранилищ;</li> <li>Конфигураций приложений и сервисов;</li> <li>Кодовой базы.</li> </ul> </li> <li>Проверка HA функций <ul> <li>Схема IP адресации (private / public / static &amp; IP failover);</li> <li>Схема внутренней и внешней DNS адресации;</li> <li>Представление схемы адресации в приложениях + failover схемы адресации на уровне приложений;</li> <li>Поведение приложений при инвалидации кешей / перезапуске процедуры построения индекса;</li> <li>Failover баз данных (переключение на slave / выбор нового мастера / другие процедуры) + переключение приложений;</li> <li>DNS based routing &amp; health checks</li> <li>ELB based routing &amp;workspaces health checks</li> </ul> </li> </ul> <h3>Сервисы AWS по обеспечению информационной безопасности</h3> <p>В дополнение ко всему сказанному выше, хотелось бы подчеркнуть, что AWS имеет большое портфолио сервисов по обеспечению информационной безопасности и каждому из них можно посвятить не один пост. Однако для вашего удобства здесь я опубликую диаграмму со всеми актуальными на сегодняшний день сервисами в области ИБ. Крупное изображение доступно <a href="https://s3-eu-west-1.amazonaws.com/zaychiko-aws-blog/sec+tools.png">здесь</a>.</p> <div style="width: 891px" class="wp-caption aligncenter"> <img class="size-medium" src="https://s3-eu-west-1.amazonaws.com/zaychiko-aws-blog/sec+tools+copy.png" alt="Полный перечень сервисов по обеспечению ИБ в AWS" width="881" height="551" /> <p class="wp-caption-text">Полный перечень сервисов по обеспечению ИБ в AWS</p> </div> <h3>Вместо заключения: Well Architected Framework</h3> <p>На этом на сегодня, пожалуй, все. В этом посте перечислен набор простых и быстро выполнимых действий, которые помогут вам существенно сократить влияние инцидентов на вашу инфраструктуру и сон. Однако, на этом наши рекомендации не исчерпываются. Тем, кто действительно заботится о безопасности и устойчивости инфраструктуры на AWS мы настоятельно советуем прислушаться к рекомендациям, собранным специалистами AWS в <a href="https://aws.amazon.com/architecture/well-architected/">Well-Architected Framework</a>.</p> <p>Всем спасибо. До скорого!</p> Apache Spark – за рамками MapReduce https://aws.amazon.com/ru/blogs/rus/emr-spark/ Mon, 15 May 2017 22:11:53 +0000 e723e043ce9c8a4f19859c6ae1a8ef425a1db292 Виталий Федоренко (Vitalii Fedorenko), AWS Big Data Cloud Architect Данная статья это вольный перевод одного из наиболее популярных AWS постов об Apache Spark Джона Фрица. Как многим из Вас уже известно, веб-сервис Amazon EMR упрощает обработку и анализ больших объемов данных используя такие библиотеки как Hadoop, Hive, HBase, Presto, Impala и Spark. В то время […] <p><em>Виталий Федоренко (<a href="https://www.linkedin.com/in/myresume/">Vitalii Fedorenko</a>), AWS Big Data Cloud Architect</em><br /> <img class="alignleft" src="https://denisb-aws.s3.amazonaws.com/rus-blog/emrspark/FullSizeRender.jpg" alt="Author: Vitalii Fedorenko" width="70" height="70" /></p> <p>Данная статья это вольный перевод <a href="https://aws.amazon.com/blogs/aws/new-apache-spark-on-amazon-emr/">одного из наиболее популярных AWS постов</a> об Apache Spark Джона Фрица.</p> <p>Как многим из Вас уже известно, веб-сервис Amazon EMR упрощает обработку и анализ больших объемов данных используя такие библиотеки как Hadoop, Hive, HBase, Presto, Impala и Spark. В то время как Hadoop MapReduce все еще популярен для обработки больших объёмов данных, анализа неструктурированных данных и машинного обучения, Apache Spark стал вытеснять его, обеспечивая лучшую производительность кластера и скорость разработки. Используя движок на основе направленного ациклического графа (DAG), Spark создает более эффективный план выполнения запросов преобразования данных. Кроме того, Spark использует отказоустойчивые распределенные наборы данных (RDD), сохраняя промежуточные, входные и выходные данные в памяти, а не на диске. Эти элементы функциональности повышают производительность определенных программ по сравнению с Hadoop (к примеру, машинное обучение), так как MapReduce выполняет задачи по последовательной схеме и затрачивает большее количество ресурсов на ввод-вывод промежуточных данных на диск.</p> <p>Spark поддерживает такие языки программирования как Scala, Python, Java, и SQL API, популярные алгоритмы машинного обучения, обработку графов и потоков данных. В Spark есть множество параметров которые упрощают разработку по сравнению с различными абстракциями, обернутыми вокруг Hadoop MapReduce API.</p> <h2>Spark на Amazon EMR</h2> <p>Вы можете создавать масштабируемые Spark кластера с различными типами EC2 инстансов непосредственно из консоли Amazon EMR, CLI или API. Работая в контейнере EMR, Spark может читать данные через EMRFS напрямую из S3, пересылать логи в хранилище данных S3, использовать Spot EC2 для снижения затрат, а также интегрироваться с такими функциями безопасности AWS как IAM роли, группы безопасности EC2 и шифрование S3 в состоянии покоя (на стороне сервера или клиента). Одним из основных достоинств является то, что нет никакой дополнительной платы за Spark на AWS EMR.</p> <p><span id="more-156"></span></p> <p>Spark включает в себя интерфейс SQL для интерактивных SQL-запросов, MLlib для масштабируемых распределенных алгоритмов машинного обучения, Spark Streaming для создания приложений обработки потоков и GraphX для работы с графиками. Вы также можете установить на EMR кластер Ganglia для дополнительного мониторинга Spark. Приложения на EMR Spark запускаются через EMR Step API, напрямую через Spark API или Spark Shell на главном узле кластера.</p> <h2>Примеры использования Spark клиентами AWS</h2> <p>Несколько примеров использования Spark клиентами AWS:</p> <ul> <li>Система рекомендации контента читателям Washington Post работает на основе Spark: <a href="https://conferences.oreilly.com/strata/strata-ny-2016/public/schedule/detail/51468">https://conferences.oreilly.com/strata/strata-ny-2016/public/schedule/detail/51468</a></li> <li>Yelp использует библиотеки машинного обучения Spark MLlib, чтобы увеличить количество просмотров рекламных объявлений: <a href="https://spark-summit.org/2017/events/yelp-ad-targeting-at-scale-with-apache-spark/">https://spark-summit.org/2017/events/yelp-ad-targeting-at-scale-with-apache-spark/</a></li> <li>Корпорация Hearst использует Spark Streaming для обработки данных о кликах на сайте Cosmopolitan. Это позволяет им создавать отчеты о читаемости статей и трендах в режиме реального времени: <a href="https://www.youtube.com/watch?v=6cwbbqi36k8">https://www.youtube.com/watch?v=6cwbbqi36k8</a></li> <li>Krux использует Spark и EMRFS для обработки логов, хранящихся в Amazon S3: <a href="https://aws.amazon.com/solutions/case-studies/krux/">https://aws.amazon.com/solutions/case-studies/krux/ </a></li> </ul> <h2>Пример анализа данных с помощью Apache Spark</h2> <p>В этой части мы покажем пример того как можно в течение короткого времени начать обработку данных с помощью Spark на Amazon EMR ответив на несколько вопросов о задержке рейсов и аннулировании внутренних рейсов в Соединенных Штатах Америки. Министерство транспорта США публикует общедоступные данные о перелетах с 1987 года. Мы преобразовали формат исходных файлов из CSV в Parquet (для лучшей производительности) и загрузили его в общедоступную корзину S3 <code>s3://us-east-1.elasticmapreduce.samples/flightdata/input</code>. Этот набор данных составляет около 4 ГБ (79 ГБ без сжатия) и содержит более 160 миллионов строк. Набор данных довольно большой и оптимальным средством для его обработки будет Spark. Мы вычислим 10 аэропортов с наибольшим количеством вылетов, рейсы с задержкой более 15 минут, рейсы с задержкой более 60 минут, и отмененные рейсы. Мы также узнаем количество отмененных рейсов по 10 самым популярным маршрутам. Все эти запросы будут реализованы на SQL, а само приложение написано на Scala. Вот, к примеру, несколько строк из исходного кода:</p> <p><code>// Файлы parquet могут быть зарегистрированы как таблицы для дальнейшего использования в SQL запросах<br /> val df = session.read.parquet (&quot;s3://us-east-1.elasticmapreduce.samples/flightdata/input/&quot;)<br /> // Топ 10 аэропортов с наибольшим количеством вылетов с 2000 года<br /> df.createOrReplaceTempView(&quot;flights&quot;)<br /> val topDepartures = session.sql(&quot;SELECT origin, count (*) AS total_departures<br /> FROM flights WHERE year &gt;= '2000' GROUP BY origin ORDER BY total_departures DESC LIMIT 10&quot;)</code></p> <p>Полный исходный код доступен по адресу: <a href="https://s3.amazonaws.com/us-east-1.elasticmapreduce.samples/flightdata/sparkapp/FlightSample-1.0.scala">https://s3.amazonaws.com/us-east-1.elasticmapreduce.samples/flightdata/sparkapp/FlightSample-1.0.scala</a></p> <p>Jar файл со скомпилированным кодом: <a href="https://s3.amazonaws.com/us-east-1.elasticmapreduce.samples/flightdata/sparkapp/flightsample-1.0.jar">https://s3.amazonaws.com/us-east-1.elasticmapreduce.samples/flightdata/sparkapp/flightsample-1.0.jar</a></p> <p>Обратите внимание, что приложение создает таблицу &laquo;flights&raquo;, которая является фреймом в памяти (DataFrame), и SQL-запрос считывает эту таблицу из памяти для сокращения затрат ввода-вывода на диск. Кроме того, EMR Spark использует EMRFS для доступа к данным в S3 без необходимости сначала копировать их в HDFS.</p> <p>Теперь давайте запустим EMR Spark кластер из трех m3.xlarge инстансов EC2 для выполнения нашего приложения. Данные для этого примера расположены в us-east-1 и скорость чтения будет наиболее оптимальна если кластер находится в этом же регионе. Для начала откройте страницу EMR &laquo;Create Cluster&raquo;, а затем &laquo;Go to Advanced Options&raquo; в консоли Amazon EMR. Затем выберите Spark в качестве приложения.</p> <p><img class="aligncenter" src="https://denisb-aws.s3.amazonaws.com/rus-blog/emrspark/Spark_Screenshot_1.png" alt="" width="" height="" /><br /> По умолчанию Amazon EMR конфигурирует Spark для использования динамического распределения ресурсов и устанавливает количество ядер процессора и RAM для каждого Spark executor на основе типа EC2 инстанса. Вы всегда можете переопределить эти параметры во время выполнения задач, передав дополнительные аргументы в команду spark-submit. Теперь перейдите к разделу Add Steps в нижней части страницы, и выберите Spark Application, затем нажмите Configuration чтобы добавить шаг приложения Spark:</p> <p><img class="aligncenter" src="https://denisb-aws.s3.amazonaws.com/rus-blog/emrspark/Spark_Screenshot_2.png" alt="" width="" height="" /><br /> Выберите &laquo;Cluster&raquo; для &laquo;Deploy mode&raquo;. В качестве ссылки на приложение введите <code>s3://us-east-1.elasticmapreduce.samples/flightdata/sparkapp/flightsample-1.0.jar</code>. В поле &laquo;Аrguments&raquo; укажите путь S3, куда бы вы&nbsp;хотели чтобы Spark записал результат. Нажмите &laquo;Add&raquo; и установите флажок &laquo;Auto-terminate cluster after the last step is completed&raquo; в нижней части страницы, чтобы кластер автоматически удалился после завершения работы приложения. Нажмите &laquo;Continue&raquo;, чтобы перейти ко второму этапу создания кластера. Просмотрите EC2 конфигурацию вашего кластера. Для этого приложения мы выберем один master-узел и два core-узла типа m4.xlarge. Нажмите &laquo;Continue&raquo; и снимите флажки параметров &laquo;Logging&raquo; и &laquo;Termination protection&raquo; в разделе &laquo;General Options&raquo;. Нажмите &laquo;Continue&raquo;, чтобы перейти к последнему этапу (все параметры остаются без изменения). В заключение, нажмите &laquo;Create cluster&raquo;. Amazon EMR запустит кластер и ваше Spark приложение. По завершении вы можете просмотреть результат по указанному вами ранее пути в S3. Мы не будем раскрывать здесь результатов нашего отчета, но обязательно захватите с собой что-нибудь почитать, если вы летите из Чикаго!</p> <p>Дополнительную информацию о Spark на Amazon EMR вы можете найти на странице <a href="https://aws.amazon.com/elasticmapreduce/spark/">https://aws.amazon.com/elasticmapreduce/spark/</a></p> Разворачиваем GridGain кластер на AWS через AWS Marketplace: Часть I https://aws.amazon.com/ru/blogs/rus/gridgain-via-marketplace-1/ Thu, 11 May 2017 20:47:57 +0000 6706de608b353ca060cff66e9237c251fcc40561 Денис Баталов, архитектор AWS, @dbatalov Друзья, рад представить вашему вниманию первую часть из серии гостевых постов от коллег из компании GridGain! Платформа GridGain – это современное и технически интересное решение по созданию сверх-производительных распределённых баз данных с реляционным интерфейсом, работающих в основном в оперативной памяти. Для справки немного о самой компании. GridGain Systems – калифорнийский […] <p><em>Денис Баталов, архитектор AWS,</em> <a href="https://twitter.com/dbatalov" target="_blank">@dbatalov</a><br /> <img class="alignleft" src="https://denisb-public.s3.amazonaws.com/SpeakerDenisSmall.png" alt="Author: Denis V. Batalov" width="70" height="70" /></p> <p>Друзья, рад представить вашему вниманию первую часть из серии гостевых постов от коллег из компании GridGain! Платформа GridGain – это современное и технически интересное решение по созданию сверх-производительных распределённых баз данных с реляционным интерфейсом, работающих в основном в оперативной памяти.</p> <p>Для справки немного о самой компании. GridGain Systems – калифорнийский стартап, который дорос до серьезной и быстрорастущей международной компании с клиентами по всему миру. Среди клиентов GridGain можно встретить таких именитых мастодонтов, как Сбербанк, Barclays, American Express, Microsoft, IBM, Huawei, RingCentral и Workday. Все они тем или иным образом используют GridGain In-Memory Data Fabric – платформу и фреймворк, который представляет из себя распределенное memory-first хранилище и вычислительную систему, масштабируемую горизонтально и дающую колоссальный прирост производительности, благодаря своей архитектуре.</p> <p>Платформа находит применение во всех отраслях и секторах, начиная от финансового, заканчивая cферой Интернета Вещей. Такая широкая область применения обусловлена обилием компонент, работающих поверх распределенного хранилища данных (таких как распределенный ANSI-99 SQL движок), поддержкой распределенных ACID транзакции, real-time streaming, machine learning и многим другим.</p> <p>В этой серии статей Денис Магда расскажет о том, как начать работу с GridGain кластером на AWS и доходчиво объяснит, как этот зверь работает “под капотом”.</p> <hr /> <p>&nbsp;</p> <p><em>Денис Магда, GridGain Product Manager</em><br /> <img class="alignleft" src="https://denisb-aws.s3.amazonaws.com/rus-blog/gridgain1/DenisMagdaSmallHiRes.jpg" alt="Author: Denis Magda" width="70" height="70" /></p> <p>В наше время, когда объемы хранимой и обрабатываемой информации разрастаются с небывалой скоростью, уже нелегко опираться на хранилища и платформы, которые проектировались и создавались совершенно для иных целей. Не каждая компания может позволить себе переход на очередной мэйнфрейм, если необходимо сохранить производительность при колоссально возросших объемах данных, хранимых в классической реляционной базе данных. Более того, зачастую, обновление железа выливается в своего рода временную пилюлю или инъекцию: мы вкладываем огромные деньги на обновление, но получаем непропорциональный прирост производительность и, более того, понимаем, что в скором времени снова упрёмся в потолок и железо, на котором работает СУБД, придется обновлять вновь.</p> <p>Данный вызов нашего времени породил определенное число распределенных реляционных баз данных, NoSQL хранилищ и Data Grids, которые воплощают в жизнь концепцию горизонтального масштабирования: хранение и обработка данных происходит в кластере состоящего из N-го кол-ва машин, и, если необходимо увеличить производительность при возросшем объеме данных, то достаточно добавить новый узел в кластер, работающий на обычном железе.</p> <p><span id="more-149"></span></p> <p><a href="https://www.gridgain.com/" target="_blank">GridGain In-Memory Data Fabric</a> – как раз та платформа, которая позволяет организовать хранение данных в RAM (с опциональной возможностью хранение данных на диске) в распределенном кластере машин, ускоряя работу приложений в десятки, сотни, тысячи раз. Платформа построена на базе open source проекта <a href="https://ignite.apache.org/" target="_blank">Apache Ignite In-Memory Data Fabric</a> и состоит из множества компонент, позволяющих выполнять распределенные ANSI-99 SQL запросы и транзакции, соответствующие ACID семантике, запускать распределленные вычисление и обрабатывать потоки данных в режиме реального времени, разворачивать микросервисы и многое другое.</p> <p>Благодаря тому, что GridGain – это распределенное хранилище и вычислительная платформа, продукт находит применение во <a href="https://www.gridgain.com/customers/industries" target="_blank">множестве отраслей и индустрий</a>, таких как телекоммуникации, финансовый сектор, интернет вещей, ритейл. На базе GridGain работают критические продукты Barclays, Сбербанк, RingCentral, Silver Spring Networks и многих других компаний, которые смогли достичь колоссального прироста производительности благодаря горизонтальному масштабированию GridGain. С некоторыми вариантами использования можно ознакомиться на <a href="https://www.gridgain.com/customers/case-studies" target="_blank">данной странице</a>.</p> <p>Что касается развертывания GridGain-кластера, то его можно с легкостью запустить на собственном железе, в облаке, либо в контейнерах. В данной статье мы узнаем, как можно быстро развернуть GridGain в AWS облаке, используя AWS Marketplace и начать использовать его в тестовых целях.</p> <h2>Установка GridGain через AWS Marketplace</h2> <p><a href="https://www.gridgain.com/products/software/enterprise-edition" target="_blank">GridGain Enterprise Edition</a> можно развернуть на AWS, минуя AWS Marketplace, но мы хотим сделать это наиболее быстрым для нас способом, следуя подготовленной <a href="https://www.gridgain.com/company/partners/amazon-aws-deployment#introduction" target="_blank">инструкции</a>.</p> <p>В соответствии с инструкцией, перейдем в <a href="https://aws.amazon.com/marketplace/" target="_blank">AWS Marketplace</a> и введем GridGain в строку поиска или можно сразу же перейти по следующей <a href="https://aws.amazon.com/marketplace/pp/B01KU8OYRQ" target="_blank">ссылке</a>:</p> <p><img class="aligncenter" src="https://denisb-aws.s3.amazonaws.com/rus-blog/gridgain1/image1.png" alt="" width="" height="" /><br /> Нажимаем на “Continue” и, пользуясь “1-Click Launch” опцией, выбираем любую из доступных EC2 виртуальных машин, к примеру, <b>m3.medium</b>:</p> <p><img class="aligncenter" src="https://denisb-aws.s3.amazonaws.com/rus-blog/gridgain1/image2.png" alt="" width="" height="" /><br /> GridGain узлы, которые будут входить в состав кластера взаимодействуют друг с другом через определенные TCP/IP порты на уровне <a href="https://apacheignite.readme.io/docs/cluster-config" target="_blank">discovery</a> и <a href="https://apacheignite.readme.io/docs/network-config" target="_blank">communication</a> сетевых компонент. В демонстрационных целях мы откроем все порты для наших AWS-узлов через группу безопасности (“Security Group”):</p> <p><img class="aligncenter" src="https://denisb-aws.s3.amazonaws.com/rus-blog/gridgain1/image3.png" alt="" width="" height="" /><br /> При необходимости настраиваем иные параметры и нажимаем на “Launch with 1-Click”:</p> <p><img class="aligncenter" src="https://denisb-aws.s3.amazonaws.com/rus-blog/gridgain1/image4.png" alt="" width="" height="" /><br /> Переходим в EC2 Console и проверяем, что виртуальная машина была успешно запущена:</p> <p><img class="aligncenter" src="https://denisb-aws.s3.amazonaws.com/rus-blog/gridgain1/image5.png" alt="" width="" height="" /></p> <h2>Запуск GridGain-кластера на AWS</h2> <p>В качестве следующего шага, нам необходимо подключиться к виртуальной машине и запустить GridGain-узлы, которые, соединяясь друг с другом, в итоге формируют распределенный кластер.</p> <p>Подключаемся к AWS через ssh, используя ключ и DNS имя виртуальной машины:</p> <p><code>ssh -i &quot;dmagda.pem&quot; ec2-user@ec2-54-82-240-125.compute-1.amazonaws.com</code></p> <p>В случае отсутствия ранее созданного ключа для SSH доступа к виртуальной машине EC2, такой ключ нужно создать следуя <a href="http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html" target="_blank">инструкции</a>.</p> <p>Проставляем следующие переменные окружения:</p> <p><code>export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk.x86_64<br /> export IGNITE_HOME=/usr/local/bin/gridgain/gridgain-enterprise-fabric-7.7.7<br /> export GRIDGAIN_HOME=${IGNITE_HOME}</code></p> <p>Примечание: версия GridGain и Java может отличаться в вашем окружении. В результате чего, значение переменных окружения JAVA_HOME и IGNITE_HOME может быть иным.</p> <p>Переходим в bin-каталог GRIDGAIN_HOME:</p> <p><code>cd ${GRIDGAIN_HOME}/bin</code></p> <p>Выполняем скрипт ignite-amazonaws-example.sh, который запустит GridGain-узел в собственном JVM-процессе:</p> <p><img class="aligncenter" src="https://denisb-aws.s3.amazonaws.com/rus-blog/gridgain1/image6.png" alt="" width="" height="" /><br /> Давайте переведем данный процесс из foreground в background, нажав <b><code>Ctr+Z</code></b> и выполнив команду <b><code>bg</code></b>. После этого запустим еще один GridGain-узел на той же AWS виртуальной машине с помощью ignite-amazonaws-example.sh:</p> <p><img class="aligncenter" src="https://denisb-aws.s3.amazonaws.com/rus-blog/gridgain1/image7.png" alt="" width="" height="" /><br /> Посмотрев на лог данного узла, мы заметим, что параметр “Topology snapshot” теперь равен 2. Это говорит о том, что мы смогли запустить GridGain-кластер из двух узлов на одной AWS виртуальной машине.</p> <h2>Продолжение следует…</h2> <p>Затратив буквально 5 минут нашего времени, нам удалось запустить кластер GridGain в AWS облаке, используя AWS Marketplace. В следующих постах мы покажем, как запустить кластер на нескольких AWS виртуальных машинах, а также, как подключиться к нему со стороны окружения разработчика, загрузить в него данные и позапускать разного рода приложения, которые будут взаимодействовать с кластером.</p> Реализация защищенной корпоративной системы резервного копирования и восстановления в AWS https://aws.amazon.com/ru/blogs/rus/secure-enterprise-backup-storage/ Tue, 20 Dec 2016 10:20:29 +0000 95be55f6b2ff5f6fa573a972e9043526cd167f90 Андрей Зайчиков, Архитектор AWS Всем привет! Сегодня мы поговорим о том, как реализовать защищенную корпоративную систему резервного копирования и восстановления с использованием сервисов AWS. Для начала – пара слов о проблематике. Многие компании начиная от маленьких и заканчивая крупными транснациональными корпорациями нуждаются в системах резервного копирования и восстановления. Обычно цель такой системы – защищенное надежное […] <p style="text-align: right"><em>Андрей Зайчиков, Архитектор AWS</em></p> <p>Всем привет!</p> <p>Сегодня мы поговорим о том, как реализовать защищенную корпоративную систему резервного копирования и восстановления с использованием сервисов AWS.</p> <p>Для начала – пара слов о проблематике.</p> <p>Многие компании начиная от маленьких и заканчивая крупными транснациональными корпорациями нуждаются в системах резервного копирования и восстановления. Обычно цель такой системы – защищенное надежное хранение резервных копий виртуальных машин, конфигурационных файлов, данных пользовательских машин, файл серверов, почтовых серверов, а также большого количества других данных. При условии нормального функционирования систем эти данные не нужны. Однако в случае форс-мажора могут существенно сократить потери компании как от прямой потери данных, так и от потери времени на восстановление работоспособности систем и пользователей.</p> <p>Очевидно, что системы резервного копирования и восстановления стоят денег, однако выделять деньги на подобные системы компании не спешат, т.к. стоимость данных решений в общем ИТ портфеле компании нередко довольно высока. Кроме того, для подобных систем характерны классические &laquo;железные&raquo; проблемы – неэффективное использование ресурсов, необходимость планировать ресурсы сильно заранее, сложность внедрения и сопровождения. В итоге, системы внедряются в ограниченном объеме (если вообще внедряются), что приводит к очевидным потерям в случае возникновения непредвиденных ситуаций.</p> <p>Преимущества облачных технологий для данного класса систем кажутся очевидными, среди них можно отметить:</p> <ul> <li>Практически неограниченный объем доступных ресурсов;</li> <li>Использование ресурсов по pay-as-you-go модели;</li> <li>Высочайший SLA по надежности и доступности;</li> <li>Широкие возможности оптимизации хранения данных.</li> </ul> <p>Однако, возникают резонные вопросы. Можно ли сохранить высокую степень конфиденциальности данных в облаке AWS? Можем ли мы быть уверенными, что данные не попадут в чужие руки / не будут повреждены / уничтожены? Можем ли мы гарантировать, что соединение нашей корпоративной сети с AWS безопасно? Насколько высока степень доступности, которую можно обеспечить? Насколько сильно удаленность региона повлияет на нашу работу? Получится ли выполнить архивирование / восстановление в заданный временной интервал? Насколько эффективно мы сможем использовать облачные ресурсы?</p> <p>Сегодня мы постараемся ответить на эти вопросы и описать решение, которое удовлетворяет высоким требованиям по надежности, доступности и безопасности и, одновременно, является экономически эффективным.</p> <p><span id="more-129"></span></p> <p><strong>Пример для рассмотрения</strong></p> <p>Для начала сформулируем основные параметры сегодняшнего примера защищенной корпоративной системы резервного копирования и восстановления.</p> <ul> <li>Общий объем данных резервного копирования – 50 TB</li> <li>Скорость обновления данных – 0,5 TB в день</li> <li>Частота создания резервных копий – 1 раз в неделю (выходные) / 48 часов</li> <li>Особенности процесса обновления данных – Инкрементное обновление уже существующих данных (не более 4 TB в неделю)</li> <li>RPO – 1 неделя (для основного массива резервных копий)</li> <li>RTO – Архивные копии последних версий – по запросу, архивные копии предыдущих версий – в течение 6 часов после направления запроса (без учета времени на скачивание и расшифровку объекта)</li> </ul> <p>Естественно, что основные ограничения по проекту связаны с необходимостью обеспечения высочайшей степени безопасности информации при организации её долговременного хранения.</p> <p>В связи с этим, для начала мы проведем оценку целесообразности реализации такого решения в случае конкретной компании.</p> <p>Как известно, в классическом варианте, под комплексной информационной безопасностью понимается триада конфиденциальность, целостность и доступность.</p> <p>Полезно разнести информацию по нескольким основным категориям, каждая их которых будет отображать возможности по хранению той или иной информации в облаке. В самом простом случае такие категории могут быть сформулированы следующим образом:</p> <ul> <li>[Cat1] Хранение в публичном облаке нежелательно в соответствие с внутренней политикой компании (например, резервные копии конфигураций программного обеспечения и оборудования СЗИ);</li> <li>[Cat2] Хранение данных в публичном облаке возможно в случае, если метаданные об объекте хранятся на стороне Компании (например, резервные копии конфигураций приложений);</li> <li>[Cat3] Хранение данных и метаданных в публичном облаке возможно (к примеру, резервные копии образов ВМ серверов).</li> </ul> <p>На основании данной схемы категорирования можно получить перечень информации, хранение которой в облаке возможно и допустимо. Далее мы можем оценить объем такой информации и экономический эффект от её переноса в облако AWS.</p> <p><strong>Архитектура решения</strong></p> <p>В данном разделе мы рассмотрим основную архитектуру предлагаемого решения, а также основные особенности её реализации.</p> <p><em><strong>Общее описание архитектуры решения</strong></em></p> <p>Упрощенное описание архитектуры решения представлено на схеме ниже. Данная архитектура состоит из следующих основных блоков:</p> <ul> <li>Элементы инфраструктуры, которые производят данные, подлежащие резервному копированию (СХД, дисковые массивы серверов);</li> <li>Транспортная инфраструктура, входящая в состав решения и обеспечивающая выполнение процедур резервного копирования и восстановления;</li> <li>Инфраструктура шифрования и управления ключами, находящаяся внутри периметра организации;</li> <li>Инфраструктура хранения зашифрованных данных, находящаяся в облаке AWS в одном из следующих регионов: eu-west-1 (Ireland), eu-west-2 (London) или eu-central-1 (Frankfurt, Germany).</li> </ul> <p>Данная архитектура реализована в виде гибридной архитектуры с обеспечением доступа к системе хранения с использованием 2х основных вариантов:</p> <ul> <li>Высокоскоростных выделенных каналов связи;</li> <li>Средств импорта / экспорта физических носителей данных.</li> </ul> <p>Представленная архитектура обеспечивает разделение процесса выполнения резервного копирования и восстановления данных таким образом, что:</p> <ul> <li>Объекты, подлежащие резервному копированию / восстановлению, не покидают периметр КСПД в незашифрованном виде;</li> <li>Отдельные элементы транспортной инфраструктуры, обеспечивающие непосредственное взаимодействие с AWS, не имеют доступа к внутренним ресурсам КСПД;</li> <li>Метаданные об объектах могут храниться как на стороне AWS, так и на уровне транспортной инфраструктуры подсистемы резервного копирования Компании;</li> <li>Шифрование, резервное копирование и восстановление производится по объектам (например, резервная копия ВМ будет зашифрована как объект);</li> <li>Обеспечение высокой доступности наиболее актуальных резервных копий (на уровне 99,9% – SLA для S3 Infrequent Access);</li> <li>Обеспечение инкрементного обновления архивов и оптимизация затрат на хранение данных;</li> <li>Надежность хранения резервных копий обеспечивается на уровне 99,999999999%.</li> </ul> <div style="width: 786px" class="wp-caption aligncenter"> <img class="" src="https://s3-eu-west-1.amazonaws.com/zaychiko-aws-blog/secure-storage-on-aws.png" alt="Схема решения" width="776" height="352" /> <p class="wp-caption-text">Схема решения</p> </div> <p><em><strong>Алгоритм работы решения</strong></em></p> <p>При проектировании алгоритма работы решения есть несколько ключевых моментов, которые будет оказывать существенное влияние на реализацию системы и параметры аппаратного и программного обеспечения.</p> <p><strong><em>Выбор минимальной единицы резервного копирования / восстановления</em></strong></p> <p>В предлагаемой архитектуре единицей резервного копирования / восстановления является объект. Под объектом понимается образ виртуальной машины, образ диска, набор файлов в виде архива и / или любые другие артефакты, которые можно разделить логически и сохранять / восстанавливать совместно. Настройка объектов осуществляется на уровне программного обеспечения / скриптов резервного копирования и восстановления. Выбор данного подхода позволит существенно сократить затраты и время на резервирование и восстановление данных.</p> <p><strong><em>Выбор методов и средств шифрования</em></strong></p> <p>В предлагаемой архитектуре управление ключами шифрования и выполнение процедуры шифрования объектов целиком находится в зоне ответственности заказчика. Данный подход позволит обеспечить максимально возможный уровень конфиденциальности информации в условиях хранения данных в публичном облаке. При этом дополнительно объекты могут быть зашифрованы стандартными средствами <a href="http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingServerSideEncryption.html">Server Side Encryption</a> на стороне AWS (AES256, каждый объект шифруется своим ключом, ключи управляются AWS).</p> <p><strong><em>Выбор методов и средств организации подключения с облаку AWS</em></strong></p> <p>Подключение к публичному облаку – стандартная, хорошо описанная и часто выполняемая процедура. В данном решении у подключения к публичному облаку есть несколько ключевых аспектов, связанных, прежде всего с обеспечением высокой производительности каналов связи и максимального уровня информационной безопасности. Предполагается реализовать инфраструктуру шлюза чтения и записи в публичное облако с односторонним доступом (доступ к шлюзу осуществляется только со стороны транспортного сервера из КСПД Компании). Кроме того, предлагается организовать два выделенных канала производительностью 1 Gbps или 10 Gbps. Дополнительно, в случае необходимости, для повышения эффективности использования каналов связи можно применить средства WAN оптимизации. Передача данных по сети будет защищена с помощью L2 VPN.</p> <p>При этом, если позволяют корпоративные политики информационной безопасности, возможно и прямое подключение КСПД Компании к облаку AWS.</p> <p><strong><em>Архивирование</em></strong></p> <p>Процесс стартует по времени сразу по окончании рабочей недели. Процесс запускается планировщиком задач на уровне программного обеспечения формирования резервных копий или на уровне операционной системы. Механизм старта формирования резервной копии определяется, настраивается и контролируется для каждого ресурса отдельно.</p> <p>На первом шаге программное обеспечение формирования резервных копий осуществляет запись резервной копии на выделенный раздел СХД, предназначенный для временного агрегирования данных.</p> <p>На втором шаге задействуется транспортный сервер. Он представляет собой выделенное аппаратное обеспечение, на котором развернут специализированный программный модуль, выполняющий следующие функции:</p> <ul> <li>Ведение реестра объектов, подлежащих резервному копированию;</li> <li>Мониторинг сетевого раздела временного агрегирования данных на предмет появления новых объектов для сохранения;</li> <li>Извлечение метаданных об объекте;</li> <li>Интеграцию с внутрикорпоративной инфраструктурой шифрования объектов;</li> <li>Безопасную интеграцию с компонентами шлюза обмена данными с облаком Amazon Web Services (передачу объекта на запись в облако AWS, передачу метаданных на запись в облако AWS);</li> <li>Контроль процесса резервного копирования и восстановления данных;</li> <li>Очистку дискового пространства по окончании процесса резервного копирования.</li> </ul> <p>Транспортный сервер осуществляет постоянный мониторинг сетевого раздела и по мере появления новых объектов, подлежащих резервированию, извлекает метаданные объекта, после чего отправляет объект на шифрование.</p> <p>Сервера шифрования (или HSM) обеспечивает шифрование объектов с использованием собственных (любых) протоколов шифрования и собственных ключей шифрования. Управление ключами шифрования при этом осуществляется с использованием стандартных для организации политик и процессов.</p> <p>После того как зашифрованный объект возвращается транспортному серверу он обеспечивает передачу объекта и его метаданных серверам записи в AWS.</p> <p>Сервера записи в AWS обеспечивают запись объекта в Amazon Simple Storage Service (далее – S3) с использованием сервиса API S3, а также сохраняют метаданные объекта в DynamoDB для последующего использования. Необходимо отметить, что для использования S3 Endpoint внутри VPC потребуется по расписанию поднимать несколько EC2 машин, выполняющих функцию proxy для запросов записи в S3.</p> <p>Для обеспечения поддержки инкрементных обновлений для корзины S3 должны быть произведены следующие настройки:</p> <ul> <li>Настроена поддержка версий;</li> <li>На добавление объектов должна быть настроена Lambda функция, которая будет проверять изменение версии объекта, выполнять перенос объекта из S3 в Glacier для оптимизации стоимости хранения и обновлять метаданные в таблицах DynamoDB.</li> </ul> <p>Таким образом, при появлении новой версии объекта устаревшая версия будет либо перенесена в архивное хранилище (Glacier) для оптимизации расходов, либо уничтожена. Дополнительные настройки правил жизненного цикла данных обеспечат автоматическое удаление устаревших объектов.</p> <p><strong><em>Восстановление</em></strong></p> <p>Восстановление объектов из облака AWS инициируется пользователем через специализированный интерфейс (UI или API) программного обеспечения транспортного сервера. С помощью интерфейса пользователь сможет определить версию объекта, просмотреть его метаданные, а также ориентировочное время необходимое на восстановление объекта. Необходимо отметить, что в предлагаемой архитектуре метаданные будут храниться в AWS DynamoDB на стороне AWS (также можно организовать и локальное хранение метаданных на стороне серверов чтения / записи). Для получения данных из DynamoDB в целях обеспечения высокого уровня информационной безопасности и отсутствия прямого подключения КСПД Компании к AWS будет использоваться специализированный API серверов чтения данных из AWS.</p> <p>После получения заявки на восстановление транспортный сервер направит эту заявку серверу чтения из AWS с использованием специализированного API.</p> <p>Сервер чтения с AWS обеспечивает восстановление объекта из Glacier в S3 и его последующее чтение из S3 (либо чтение из S3 если была запрошена последняя версия объекта). По окончании чтения результат сохраняется на дисках сервера чтения и записывается в выходную очередь.</p> <p>Транспортный сервер осуществляет мониторинг выходной очереди и по мере появления объектов в ней обеспечивает чтение объекта с диска сервера чтения, передачу объекта на севера шифрования и последующую запись на диск временного хранения результатов восстановления. Также транспортный сервер обеспечивает нотификацию заинтересованных лиц о выполнении процедуры восстановления.</p> <p><strong>Сервисы AWS</strong></p> <p>Рассмотрим основные сервисы AWS, которые предполагается использовать в данном решении.</p> <p><em><strong>Amazon Direct Connect</strong></em></p> <p>Сервис предоставления выделенного физического канала от ЦОД заказчика до ближайшего региона AWS (Дублин / Франкфурт / Лондон). В рамках предлагаемой архитектуры планируется выделение 2х 1 Gbps портов, которые будут полностью находиться под контролем заказчика. Более подробная информация доступна <a href="https://aws.amazon.com/ru/directconnect/faqs/">по ссылке</a>.</p> <p><em><strong>Amazon DynamoDB</strong></em></p> <p>Не реляционная база, предоставляемая как сервис. В данном решении будет являться базой метаданных об объектах, хранящихся в AWS. Хранение метаданных в БД (в отличие от хранения в тегах S3) удобно с точки зрения обеспечения быстрого поиска объекта, поиска объектов по условию и выполнения прочих операций, а также наличию возможностей по онлайн обработке данных (в том числе репликации в другие источники). Определение состава и структуры метаданных зависит от конкретного проекта, заказчика и данных. Один из вариантов заключается в том, что в качестве метаданных будет выступать уникальный кодификатор объекта и указатель на объект в S3. Связка объекта, сохраняемого в AWS с реальными метаданными будет храниться в БД в ЦОД заказчика (на уровне инфраструктуры шлюза данных) и не будет доступна из AWS. Более подробная информация о сервисе DynamoDB доступна <a href="https://aws.amazon.com/ru/dynamodb/faqs/">по ссылке</a>.</p> <p><em><strong>Amazon S3 (Infrequent Access)</strong></em></p> <p>Объектное хранилище, которое будет предоставлять основные возможности по записи, хранению и управлению зашифрованными архивными объектами текущего дня. Объект будет доступен к загрузке по требованию. Более подробная информация доступна <a href="https://aws.amazon.com/ru/s3/faqs/">по ссылке</a>.</p> <p>S3 поддерживает доступ через специализированные точки доступа внутри виртуальных подсетей в облаке, что сделает хранилище архивов доступным только из КСПД заказчика.</p> <p><em><strong>Amazon Glacier</strong></em></p> <p>Долговременное высоконадежное и эффективное с точки зрения стоимости хранилище. Данные будут попадать туда через S3 с использованием специализированных Lambda функций, которые будут отвечать за контроль версий, целостность данных, обновление метаданных об объекте и проч. Восстановление данных из Glacier может занимать несколько часов. Более подробная информация доступна <a href="https://aws.amazon.com/ru/glacier/faqs/">по ссылке</a>.</p> <p><strong>Обеспечение связи между ЦОД Компании и регионом</strong></p> <p><em><strong>Реализация выделенных каналов связи</strong></em></p> <p>Выделенные каналы связи обеспечиваются провайдером услуг связи, который имеет партнерское соглашение с AWS. Партнер обеспечивает выделение и предоставление заказчику выделенных каналов и портов. Выделенные порты доступны в варианте 1 Gbps и 10 Gbps. Канал выделяется от ЦОД партнеров (есть партнеры с собственными мощностями в Москве и Санкт-Петербурге).</p> <p>Порядок подключения следующий. Заключается договор с провайдером услуг связи, после чего он обеспечивает подключение заказчика к своим мощностям и каналам, ведущим до одного из ЦОД, скомутированных с регионом AWS. В данном ЦОД осуществляется физическое подключение выделенного порта, предоставляемого партнером к оконечной точке сервиса DirectConnect.</p> <p><em><strong>Реализация VPN туннелей</strong></em></p> <p>Подключение через L2 VPN организуется по стандартной процедуре между физическим сетевым оборудованием заказчика (или доверенного партнера) и сервисом Virtual Private Gateway со стороны AWS. Сформированный туннель поддерживает BGP, GRE и может быть построен с учетом необходимости обеспечения failover для канала связи.</p> <p>Более подробно по процедуре организации VPN подключения можно прочитать <a href="https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html">здесь</a>.</p> <p><em><strong>Оценка временного окна на выполнение процедуры резервного копирования</strong></em></p> <p>В данном разделе мы попробуем приблизительно рассчитать время необходимое на выполнение процедуры резервного копирования для ориентировочного недельного объема данных резервного копирования (3,5 TB). Резервное копирование будет проводиться в несколько основных шагов:</p> <ul> <li>Формирование резервных копий и запись их на диск промежуточного хранения;</li> <li>Выполнение шифрования объектов;</li> <li>Выполнение передачи серверам записи в AWS;</li> <li>Выполнение массовой параллельной загрузки в Amazon S3.</li> </ul> <p>При расчетах в качестве среднего размера объекта определим 100Gb (образ виртуальной машины, файловый архив). Для расчета скорости шифрования берется практическая оценка скорости шифрования с помощью CryptoPro по 3DES – составляет 5 минут на 200 GB при использовании сервера с характеристиками 2 CPU &amp; 8 GB RAM. Эти данные получены экспериментальным путем и могут не соответствовать фактической производительности в целевой системе. Ширина канала для передачи серверам записи в AWS, и собственно в AWS – 2x 1 Gbps.</p> <ul> <li>Формирование резервных копий и запись их на диск промежуточного хранения – Около 3х часов в нормальной конфигурации дисков</li> <li>Выполнение шифрования объектов – Около 4х часов</li> <li>Выполнение передачи серверам записи в AWS – Около 2х часов</li> <li>Выполнение массовой параллельной загрузки в Amazon S3 – Около 8ми часов</li> <li>Итого общее время загрузки – <strong>17 часов при нормальной загрузке систем / каналов (для инкрементной загрузки объектов)</strong></li> </ul> <p>Необходимо отметить, что более точный расчет по процедуре резервного копирования можно осуществить путем проведения пилотного проекта (Proof-of-concept) и его нагрузочного тестирования. Проведение такого тестирования возможно полностью на вычислительных мощностях AWS.</p> <p><strong>Отдельные аспекты технической реализации</strong></p> <p><em><strong>Интеграция корпоративного ПО</strong></em></p> <p>Интеграция корпоративного ПО с решением по резервному копированию данных осуществляется на уровне записи / чтения данных с томов временного хранения, размещенных на корпоративном СХД с использованием стандартных интерфейсов СХД.</p> <p><em><strong>Обеспечение надежности и отказоустойчивости решения</strong></em></p> <p>Отказоустойчивости компонент на уровне основной части подсистемы хранения обеспечивается AWS в соответствие с SLA.</p> <p>Отказоустойчивость части транспортной архитектуры решения может быть обеспечена несколькими основными способами:</p> <ul> <li>Резервирование ресурсов на уровне ЦОД Компании и/или ЦОД доверенного партнера (для транспортных серверов, серверов чтения / записи, а также сетевой инфраструктуры) с применением стандартных средств обеспечения отказоустойчивости (в том числе настройки динамической маршрутизации, резервного копирования самих ресурсов и проч.);</li> <li>Создание резервной площадки для обеспечения сетевого подключения к AWS. В таком случае сервера чтения и сервера записи могут быть развернуты также на резервной площадке либо в отдельной VPC AWS с использованием Amazon EC2 виртуальных машин.</li> </ul> <p><em><strong>Обеспечение управления решением</strong></em></p> <p>Управление решением на уровне основного хранилища данных в AWS будет осуществляться вручную через веб-консоль управления AWS Management Console. Доступ к ней будет осуществляться в соответствие с разграничением прав доступа, описанных ниже. Автоматизация рутинных функций возможна с применением собственных средств платформы AWS, а также с помощью CLI скриптов.</p> <p>Управление физической инфраструктурой выполнения процедур резервного копирования и записи / чтения в AWS на уровне ЦОД и КСПД Компании и/или доверенного партнера осуществляется с помочью стандартных средств управления инфраструктурой.</p> <p><strong>Отдельные аспекты обеспечения информационной безопасности</strong></p> <p>В данном разделе мы коротко рассмотрим основные аспекты обеспечения информационной безопасности в предложеном решении.</p> <p><em><strong>Сетевая безопасность</strong></em></p> <p><em>Разделение на подсети</em></p> <p>Согласно прилагаемой схеме, в решении используется три основных подсети:</p> <ul> <li>Внутренняя DMZ КСПД Компании;</li> <li>Внешняя DMZ КСПД Компании или сеть доверенного партнера;</li> <li>Подсеть AWS VPC.</li> </ul> <p>Доступа к внутренней DMZ КСПД Компании из любой другой подсети нет. Доступ из внутренней DMZ КСПД Компании осуществляется транспортным сервером по кастомизированным портам к внешней DMZ КСПД Компании или сети доверенного партнера. Сеть доверенного партнера подключается к AWS VPC через выделенный канал с настроенным L2 VPN.</p> <p>Между всеми сетями (включая AWS VPC) настраиваются максимально жесткие правила межсетевого экранирования. Разрешения касаются только отдельных кастомизированных портов и IP адресов.</p> <p><em>Межсетевые экраны</em></p> <p>Правила межсетевого экранирования определяются на последующих этапах.</p> <p>На уровне AWS VPC межсетевое экранирование включает в себя фильтрацию на уровне подсетей с использованием Network ACL (<a href="https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html">подробнее</a>) и фильтрацию на уровне оконечных точек сервиса Security Groups (<a href="https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_SecurityGroups.html">подробнее</a>).</p> <p><em>Системы предотвращения вторжений</em></p> <p>AWS отвечает за безопасность облака и следует крайне жестким политикам в области информационной безопасности. Предотвращение и обнаружение вторжений на уровень сервисов AWS является неотъемлемой частью этих политик. В случае обнаружения подозрительной активности заказчик будет уведомлен о наличии такой активности, её типе и предполагаемом источнике. Совместно со специалистами заказчика команды ИБ AWS предпримут меры по ограничению / устранению причин и повышению безопасности решения.</p> <p>На уровне КСПД и транспортной инфраструктуры должны быть включены системы IDS/IPS, рекомендованные политиками Компании.</p> <p><em><strong>Шифрование</strong></em></p> <p><em>Выполнение процедуры шифрования объектов, подлежащих резервированию</em></p> <p>Процедура шифрования объектов, подлежащих резервированию осуществляется для каждого объекта в строгом соответствие с внутренними политиками и регламентами заказчика и с использованием собственной инфраструктуры заказчика.</p> <p>Контроль выполнения процедуры шифрования лежит на программном обеспечении транспортного сервера.</p> <p>Все объекты, покидающие периметр КСПД должны быть зашифрованы в обязательном порядке.</p> <p><em>Шифрование данных при передаче по сети</em></p> <p>Шифрование данных при передаче между DMZ в которой находятся сервера чтения / записи и AWS будет осуществляться с использованием L2 IPSec VPN туннелей. Процедура создания туннелей и требования к оконечному оборудованию были описаны выше.</p> <p><em>Шифрование данных при хранении в AWS</em></p> <p>Дополнительно к сказанному выше возможно (и желательно) включение шифрования на стороне сервисов AWS. Server side encryption на уровне сервисов AWS поддерживает шифрование AES-256 с использованием отдельного ключа для каждого объекта. Ключи могут быть сгенерированы автоматически либо пользователем <a href="http://docs.aws.amazon.com/kms/latest/developerguide/services-s3.html">с использованием AWS Key Management Service</a>.</p> <p><em>Контроль целостности данных</em></p> <p>Контроль целостности данных осуществляется на уровне транспортного сервера с использованием инструментов согласно внутренним политикам Компании. Запись информации для контроля целостности осуществляется до шифрования и после шифрования. Также осуществляется проверка целостности информации. Проверка целостности может осуществляться и на уровне сервисов AWS. Например, это можно реализовать <a href="https://aws.amazon.com/premiumsupport/knowledge-center/data-integrity-s3/">с использованием механизма хранения MD5 Check Sum непосредственно в S3</a>.</p> <p><em><strong>Разграничение доступа</strong></em></p> <p><em>Аутентификация пользователей, осуществляющих управление инфраструктурой</em></p> <p>Пользователи, осуществляющие управление инфраструктурой, могут быть аутентифицированы двумя способами в зависимости от требований информационной безопасности.</p> <p>Первый способ – интеграция контроллера домена с Amazon Identity &amp; Access Management путем установки SAML федерации. В таком случае права пользователей на доступ к ресурсам AWS будут устанавливаться политиками IAM, а фактическая аутентификация пользователей будет проводиться на уровне контроллера домена.</p> <p>Интеграция контроллера домена, наиболее вероятно, потребует ввод нового контроллера на уровне серверов чтения / записи в AWS и его интеграцию с контроллером домена Компании и, с другой стороны, с Amazon IAM. Таким образом, пользователи будут аутентифицироваться в контроллере домена и получать корректные IAM Credentials для управления инфраструктурой. При этом основной контроллер домена будет лишь реплицировать данные в контроллер на уровне транспортной инфраструктуры и не будет доступен извне КСПД (обеспечен односторонний обмен информации).</p> <p>Второй вариант – использование стандартных средств Amazon Identity &amp; Access Management. Более подробно о возможностях Amazon IAM можно узнать <a href="https://aws.amazon.com/iam/faqs/">здесь</a>.</p> <p><em>Аутентификация приложений на доступ к сервисам AWS</em></p> <p>Приложения, которым необходим доступ к управлению ресурсами AWS (запись в endpoint S3) будут аутентифицироваться путем обращения к IAM Security Token Service (<a href="https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html">подробнее</a>). При этом им будут выдаваться временные credentials и роль, для которой определена политика доступа только на запись / только на чтение к одной оконечной точке сервиса.</p> <p><em>Разграничение доступа на уровне транспортных серверов</em></p> <p>Разграничение доступа на уровне транспортных серверов осуществляется в соответствие с политиками безопасности организации в части доступа к дискам СХД. В части взаимодействия с средствами шифрования точные варианты реализации определяются при проектировании интеграции и зависят от доступных API и требований конкретных средств (серверов шифрования или HSM).</p> <p><em><strong>Мониторинг и логирование</strong></em></p> <p><em>Мониторинг канала и сетевого трафика</em></p> <p>Мониторинг сетевого трафика на уровне выделенных портов и каналов осуществляется с использованием средств / инструментов, предоставляемых провайдером услуг связи.</p> <p>Мониторинг сетевого трафика на уровне подсетей AWS VPC (от VPN до S3 endpoint) осуществляется с использованием предоставляемой AWS функции логирования сетевого траффика (AWS VPC Flow Logs). Более подробная информация доступна <a href="https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/flow-logs.html">по ссылке</a>.</p> <p><em>Мониторинг обращений к API</em></p> <p>Мониторинг обращений к API сервисов AWS (включая мониторинг манипуляций с объектами) будет осуществляться с помощью сервиса CloudTrail. Он обеспечивает логирование всех обращений к API. Дополнительно можно обеспечить нотификацию заинтересованных пользователей в случае выполнения определенных действий с объектами в системе хранения и/или другими ресурсами на стороне AWS. В первую очередь такой мониторинг обеспечивает контроль работы серверов записи и серверов чтения, а также выполнения жизненного цикла управления данными. Более подробная информация по сервису AWS CloudTrail доступна <a href="https://aws.amazon.com/cloudtrail/faqs/">по ссылке</a>.</p> <p><strong>Финансовые особенности решения</strong></p> <p>Все сервисы доступны по pay-as-you-go модели, когда оплата осуществляется по факту использования ресурсов. При этом для разных сервисов под ресурсами подразумеваются различные аспекты. Все без исключения цены доступны по публичному прайс листу. В нашем примере все цены расчитаны на момент подготовки материала для региона eu-west-1 IИрландия).</p> <p>Ниже приведу ценовые модели для используемых в решении сервисов, а также вариант расчета для возможного сценария использования подсистемы хранения на AWS.</p> <p><em><strong>Правила формирования стоимости ресурсов для сервисов системы хранения</strong></em></p> <ul> <li>Объем хранения данных GB/мес <ul> <li>S3 IA – 0.0125$ за GB в месяц</li> <li>Glacier – 0.007$ за GB в месяц</li> <li>DynamoDB – $0.283 за GB в месяц</li> </ul> </li> <li>Входящий траффик – 0$</li> <li>Исходящий траффик <ul> <li>S3 IA – $0.050 за GB за 350 TB/мес</li> <li>Glacier – Восстановление из Glacier осуществляется в соответствие с ценовой политикой сервиса</li> <li>DynamoDB – $0.090 за GB за 10 TB/мес</li> </ul> </li> <li>Количество запросов на запись <ul> <li>S3 IA – $0.01 за 1,000 запросов</li> <li>Glacier – $0.055 за 1,000 запросов</li> <li>DynamoDB – $0.00735 за час за каждые 10 единиц</li> </ul> </li> <li>Количество запросов на чтение <ul> <li>S3 IA – $0.01 за 10,000 запросов</li> <li>Glacier – $0.055 за 1,000 запросов</li> <li>DynamoDB – $0.00735 за час за каждые 50 единиц</li> </ul> </li> </ul> <p><strong>Выполнение процедуры первичной загрузки данных</strong></p> <p>Процедура первичной загрузки данных будет существенно зависеть от того, сколько данных будет загружаться в S3 на еженедельной основе (инкремент размером ~3,5 TB или полный объем данных ~50 TB). Первичная загрузка имеет смысл только в случае, если на еженедельной основе будет загружаться инкремент (в противном случае первичная загрузка будет выполняться точно так же, как и еженедельная).</p> <p>Для первичной загрузки может быть реализован один из следующих сценариев:</p> <ul> <li>Первичная загрузка через быстрый выделенный канал;</li> <li>Первичная загрузка с использованием сервиса Import/Export.</li> </ul> <p><em><strong>Первичная загрузка через быстрый выделенный канал</strong></em></p> <p>Данный вариант предполагает, что первичная загрузка данных будет осуществляться в течение некоторого времени с помощью развернутой инфраструктуры записи в AWS. Для данного варианта возможно разделить данные на группы и обеспечивать начальную загрузку и шифрование в соответствие с планом. Так как загрузка выполняется для инкремента корпоративных данных, можно обеспечить параллельное выполнение процедуры первичной загрузки и рутинной процедуры резервного копирования инкрементов.</p> <p>Выполнение процедуры осуществляется следующим образом:</p> <ul> <li>На первом этапе обеспечивается временное выделение быстрого канала (2&times;1 Gbps) до указанного региона;</li> <li>Данные шифруются внутри периметра Компании с использованием тех же серверов шифрования, которые будут использоваться для шифрования еженедельной загрузки данных;</li> <li>Данные доставляются с помощью развернутой инфраструктуры резервного копирования;</li> <li>По окончании начальной загрузки осуществляется замена обоих каналов на 1 Gbps.</li> </ul> <p><em><strong>Первичная загрузка с использованием сервиса AWS Import/Export</strong></em></p> <p>Данная процедура сложна с точки зрения логистики, а также предполагает наличие некоторого лага, в течение которого резервное копирование не осуществляется (пока основные данные не будут загружены).</p> <p>Выполнение процедуры осуществляется следующим образом (пример для переноса данных в Ирландию):</p> <ul> <li>Для полного объема данных обеспечивается извлечение метаданных по каждому объекту и формируется уникальный идентификатор (hash);</li> <li>Данные шифруются внутри периметра Компании с использованием тех же серверов шифрования, которые будут использоваться для шифрования еженедельной загрузки данных;</li> <li>Зашифрованные данные записываются на физические носители (диски – eSATA / USB);</li> <li>Диски отправляются с помощью любой корпоративной службы доставки в Ирландию на адрес Amazon Web Services;</li> <li>Сотрудники компании Amazon Web Services осуществляют загрузку данных в S3;</li> <li>По окончании загрузки начинается выполнение рутинных процедур резервного копирования и восстановления;</li> <li>Возврат пустых дисков осуществляется на юридическое лицо, зарегистрированное в ЕС.</li> </ul> <p><strong>Вместо послесловия</strong></p> <p>Нужно отметить, что приведенная выше архитектура представляет собой некоторый &laquo;экстремальный&raquo; вариант защиты данных резервного копирования для организаций, к которым предъявляются крайне серьезные требования по ИБ и формальной сертификации. Для организаций, требования которых существенно проще, решение можно адаптировать путем изменения методов и средств шифрования, а также методов и средств организации подключения к облаку AWS.</p> <p>На сегодня все. Всем спасибо!</p> <p>Следите за нашими обновлениями! Будет интересно!</p> Миграция кластеров NoSQL DB между регионами AWS https://aws.amazon.com/ru/blogs/rus/nosql_db_migration/ Tue, 20 Dec 2016 10:20:12 +0000 21055c8803a6e5294a43a382531e46f99f42f88f Андрей Зайчиков, Архитектор AWS Роман Скваж, CTO FunCorp Александр Домнин, SysOps Engineer FunCorp Всем привет! Сегодня у нас в гостях замечательные специалисты и просто хорошие люди из компании FunCorp – Роман Скваж (CTO) и Александр Домнин (SysOps). Мы расскажем вам об одном интересном проекте по миграции больших кластеров нереляционных баз данных между регионами AWS (из […] <p style="text-align: right"><em>Андрей Зайчиков, Архитектор AWS</em></p> <p style="text-align: right"><em>Роман Скваж, CTO FunCorp</em></p> <p style="text-align: right"><em>Александр Домнин, SysOps Engineer FunCorp</em></p> <p>Всем привет!</p> <p>Сегодня у нас в гостях замечательные специалисты и просто хорошие люди из компании <a href="http://fun.co/rp">FunCorp</a> – Роман Скваж (CTO) и Александр Домнин (SysOps). Мы расскажем вам об одном интересном проекте по миграции больших кластеров нереляционных баз данных между регионами AWS (из Европы в США).</p> <p><strong>Что мигрировать?</strong></p> <p>По словам Романа Скважа: &laquo;Флагманский продукт компании – iFunny (<a href="https://ifunny.co/">https://ifunny.co/</a>) одно из наиболее популярных развлекательных приложений среди американской молодежи. За 5 лет сервис обзавелся внушительной аудиторией: мобильные приложения обслуживают более 3,5 миллионов активных пользователей в день и работают во всех часовых поясах. &nbsp;Backend приложения полностью реализован на Amazon Web Services и его масштаб впечатляет:</p> <ul> <li>Кластер Apache Cassandra – 25 узлов, 18 TB данных;</li> <li>Кластер Apache Cassandra – 18 узлов, 16 TB данных;</li> <li>Кластер MongoDB – 5TB данных, распределенных по 8 shard’ам, каждый shard – ReplicaSet из Master и двух Slave;</li> <li>Кластер MongoDB – 150GB данных, распределенных по 4 shard’ам, каждый shard – ReplicaSet из Master и двух Slave;</li> <li>Кластер Elasticsearch – поисковый индекс объемом 1 TB;</li> <li>3 ReplicaSet Redis – Master + 2 Slave с 15 GB, 10 GB и 1 GB данных и крайне высокой скоростью записи.</li> </ul> <p>Силами наших&nbsp;DevOps&nbsp;и&nbsp;Backend&nbsp;команд,&nbsp;нам предстояло перенести все это из одного региона AWS в другой без downtime и крупных изменений в приложении. При этом желательно было не задействовать сторонние приложения и платные сервисы&raquo;.</p> <p><span id="more-84"></span></p> <p><em><strong>Зачем мигрировать?</strong></em></p> <p>Наверняка у вас возник резонный вопрос. А зачем вообще все это переносить? Ведь работает?</p> <p>Ответ на этот вопрос, как это ни странно, довольно прост. Начальный выбор региона для размещения приложения был сделан исходя из близости к одному рынку, а приложение получило наибольшую популярность в совсем другой географии. До определенного момента обращение к backend на другом континенте не причиняло особых неудобств. Однако, повышенный latency сильно влиял на User Experience и коллегам очень хотелось его улучшить. В связи с чем и было принято решение о переезде backend’а.</p> <p>На процесс миграции был наложен ряд условий и ограничений:</p> <ul> <li>Нулевой downtime;</li> <li>Отсутствие изменений в приложениях и структуре БД;</li> <li>Минимальное использование сторонних инструментов.</li> </ul> <p>Забегая вперед, скажем, что перенос backend позволил снизить latency для конечных пользователей при обращении к API на 40%.</p> <p><em><strong>Как мигрировать?</strong></em></p> <p>Поначалу мы попытались решить вопрос, что называется, “в лоб”. Каждая из перечисленных выше БД (кроме Elasticsearch) обладает собственными возможностями по гео-распределенной репликации.</p> <p>Однако, после начала процесса репликации, мы столкнулись с несколькими существенными проблемами. Вполне естественно, что для каждой БД они были свои.</p> <p><strong>MongoDB</strong><br /> Первая проблема касалась MongoDB, а именно, mongos процессов. Сама репликация прошла относительно спокойно и была выполнена только с использованием штатных средств MongoDB. Но после переключения пользователей на новый backend MongoDB производительность mongos в США существенно упала. Буквально в разы. Дело в том, что на текущий момент, гео-распределенный кластер MongoDB поддерживает только один набор конфигурационных серверов (см. картинку), которые на тот момент располагались в другом регионе (Европе).</p> <p><strong><img class="alignnone" src="https://s3-eu-west-1.amazonaws.com/zaychiko-aws-blog/ifunny+case+for+tech+summit+-+mongodb%281%29.png" alt="MongoDB problem" width="765" height="529" /></strong></p> <p>Таким образом, для выполнения буквально каждой операции mongos обращается к конфигурационным серверам, которые, в нашем случае, оказались за океаном.</p> <p>Хорошая новость заключалась в том, что mongos кэширует конфигурацию. При этом возникает следующая проблема – нельзя увеличивать количество chunk’ов или реорганизовывать данные между ними (иначе кеш mongos будет инвалидироваться и сами mongos будут постоянно обращаться к конфигурационным серверам на другом континенте), соответственно, миграция серверов конфигурации должна была произойти довольно быстро. Сам алгоритм миграции выглядел следующим образом.</p> <ol> <li>&nbsp;В первую очередь, мы заранее создали новые инстансы в целевом регионе с конфигурацией, идентичной текущей и включили их в существующие ReplicaSet исходных кластеров. Затем дождались окончания репликации данных.</li> <li>Непосредственно перед переездом <a href="https://docs.mongodb.com/manual/tutorial/manage-sharded-cluster-balancer/#disable-the-balancer">отключили балансировку mongos</a>. Таким образом, mongos кластера в целевом регионе использовали кэшированную версию конфигурации.</li> <li>Во время переезда поочередно вывели все инстансы с данными в старом регионе. В ReplicaSet`ах остались только инстансы в целевом регионе, среди которых стандартными средствами MongoDB выбрались новые Primary-сервера.</li> <li>На последнем этапе была выполнена миграция конфигурационного ReplicaSet в новый регион.</li> </ol> <p><strong>Cassandra</strong></p> <p>Для переноса кластеров Cassandra мы создали дополнительные DC со стандартным EC2Snitch в целевом регионе и подключили их к существующим кластерам через software VPN туннель – подняли ноды и начали репликацию. VPN туннель был необходим для того, чтобы при миграции данных между регионами не пришлось проводить трудоемкую процедуру смены Snitch с EC2Snitch на EC2MultiRegionalSnitch, которая в нашем случае подразумевала не только смену самого Snitch, но и ручное масштабирование кластера, поддержку списков адресов в Security Groups, взаимодействие между узлами по публичным IP (авторизация на уровне кластера была отключена). При использовании VPN между регионами Cassandra позволяет реплицировать данные с EC2Snitch.</p> <p>Сразу после запуска процесса репликации производительность исходного кластера Cassandra упала в разы. Дело в том, что Cassandra начала реплицировать данные всех SSTable в новый DC одновременно на все узлы с учетом нашего фактора репликации и уровня консистентности, что дало примерно следующую картину (только многократно помноженную на количество узлов и фактор репликации).</p> <p>&nbsp;</p> <p><strong><img class="alignnone" src="https://s3-eu-west-1.amazonaws.com/zaychiko-aws-blog/cassandra.png" alt="Cassandra replication" width="783" height="309" /></strong></p> <p style="text-align: left"><em>http://blog.csdn.net/zyz511919766/article/details/38683219</em></p> <p>Для того, чтобы решить эту проблему мы остановили репликацию кластеров и начали проводить rebuild узлов целевого кластера по частям – по два-три node’а за один раз. Оба кластера с таким подходом были реплицированы в течение двух недель без остановки работы и практически без снижения производительности.</p> <p>По окончании процедуры репликации был проведен repair всех узлов целевого кластера, после чего приложения были отключены от исходного DC, он был исключен из кластера и остановлен.</p> <p><strong>Redis</strong></p> <p>Миграцию Redis мы начали по схожей схеме – создали новые кластера, подключили к уже существующему кластеру в исходном регионе и стали ждать … Объем мигрируемых данных был незначительный, однако данные менялись с очень большой скоростью. Это приводило к тому, что данные не успевали реплицироваться в рамках определенного для кластера максимального Replication Window, после чего все данные в целевом кластере инвалидировались.</p> <p>Мы рассматривали несколько разных решений, включая использование DirectConnect, WAN Optimization, Replication Acceleration и других. Подробнее о каждом из них расскажем ниже.</p> <p>После нескольких недель размышлений и поисков мы нашли простое решение проблем с репликацией Redis.</p> <ol> <li>Устанавливаем SSH туннель с компрессией и &laquo;пробрасываем&raquo; порт репликации на localhost: <strong>ssh -C -L 6280:localhost:6379 $MASTER_REDIS</strong></li> <li>Говорим slave синхронизироваться с localhost вместо синхронизации с master: <strong>redis-cli slaveof localhost:6280</strong></li> </ol> <p>Готово. Теперь репликация Redis проходит успешно поскольку за счет компрессии replication lag не растет и не достигает критического порогового значения Replication Window.</p> <p><strong>ElasticSearch</strong><br /> Начальная идея была в том, чтобы не переносить поисковый индекс ElasticSearch, а воссоздать его на месте. К сожалению, процедура создания индекса была слишком сложна и требовала привлечения команд разработчиков, что не допускалось по условиям проекта.</p> <p>Хорошая новость заключалась в том, что для ElasticSearch есть отличный plug-in, который позволяет делать backup’ы, в том числе инкрементные. Найти его можно <a href="https://github.com/elastic/elasticsearch-cloud-aws">здесь.</a></p> <p>Процесс переноса ElasticSearch выглядел довольно просто:</p> <ol> <li>Создаем кластер ElasticSearch;</li> <li>Создаем Bucket в S3 и включаем версионность и cross-regional replication;</li> <li>С помощью ElasticSearch plug-in создаем snapshot основного массива данных и записываем его в S3. Snapshot автоматически передается в новый регион;</li> <li>Восстанавливаем данные из snapshot в целевом регионе;</li> <li>Выполняем шаги 3-4 для инкремента (в нашем случае операция по переносу инкремента заняла порядка 12 минут).</li> </ol> <p>&nbsp;</p> <p><em><strong>А были ли еще варианты?</strong></em><br /> На проекте мы рассматривали несколько альтернативных вариантов, которые могут помочь в миграции больших объемов данных. Мы кратко опишем эти варианты, а также лучшие практики по использованию каждого из них.</p> <p><strong>AWS Direct Connect</strong><br /> Данный сервис предоставляет надежный выделенный канал связи и идеален для случаев, когда необходимо обеспечить взаимодействия собственных мощностей в своем ЦОД или co-location с облаком AWS. <a href="https://aws.amazon.com/ru/directconnect/">Подробнее тут.</a></p> <p>Как временное решение нам он не подходил, т.к. необходимо было настраивать выделенный канал через Атлантический океан, что сопряжено с некоторыми трудностями организационного характера (длинная цепочка договоров) и довольно затратно по времени.</p> <p><strong>AWS Import / Export</strong><br /> Сервис AWS Import/Export Disk позволяет одномоментно загрузить большие объемы данных в AWS и нередко является более быстрым решением, нежели организация передачи данных по каналам связи. Он использует физические носители для передачи данных в заданный регион и загрузки данных в объектное хранилище S3. Более подробная информация доступна <a href="https://aws.amazon.com/ru/importexport/disk/">здесь.</a></p> <p><strong>WAN Optimization</strong><br /> WAN Optimization – это набор технологий и продуктов, которые позволяют оптимизировать использование WAN канала за счет нескольких основных техник:</p> <ul> <li>Де-дупликация пакетов;</li> <li>Сжатие траффика;</li> <li>Кеширование;</li> <li>Улучшенная обработка ошибок передачи данных;</li> <li>другие.</li> </ul> <p>WAN оптимизация реализуется на двух основых уровнях модели OSI – транспортном (L4 – TCP) и уровне приложений (L7 – обычно HTTP).</p> <p>Данная техника используется в основном для ускорения работы сетевых протоколов в случае, когда простое увеличение пропускной способности канала не способно дать существенного прироста производительности, либо когда оптимизация использования сети на уровне приложения невозможна.</p> <p>Стандартная схема работы систем WAN Optimization представлена на схеме ниже.</p> <p><strong><img class="alignnone" src="https://s3-eu-west-1.amazonaws.com/zaychiko-aws-blog/wan-opt-2.png" alt="WAN Optimizaiton" width="880" height="299" /></strong></p> <p>WAN Optimization deployment включает в себя специализированное программное / аппаратное обеспечение, устанавливаемое на обоих концах соединения. После чего траффик по определенным портам пропускается через него.</p> <p>На текущий момент, на <a href="https://aws.amazon.com/marketplace/search/results/ref=dtl_navgno_search_box?searchTerms=wan+optimization&amp;page=1">AWS Marketplace</a> доступно несколько основных решений по WAN Optimization, включая Riverbed, SilverPeak, Citrix, Barracuda и Sangfor и других.</p> <p>Особенностью данных решений (за исключением Sangfor) является их ориентация на постоянное использование в гибридной среде. В связи с тем, что наш проект нуждался в подобном соединении лишь на ограниченное количество времени (2 месяца) решено было не использовать данный вариант.</p> <p>Хотелось отметить, что все рассматриваемые альтернативные варианты решения отлично подходят для многих вариантов использования, в числе которых:</p> <ul> <li>Постоянная работа приложений и баз данных в гибридной среде;</li> <li>Перенос больших (сотни Тб) объемов данных в облако и из облака AWS;</li> <li>Оптимизация использования вычислительной сети без оптимизации работы приложений;</li> <li>Множество других вариантов использования.</li> </ul> <p><em><strong>Вместо заключения</strong></em><br /> Миграция баз данных – всегда сложный процесс, требующий внимания к деталям. При миграции всегда могут возникнуть неоднозначные ситуации, нестандартное поведение движков баз данных, существенное влияние сети на процесс. Самый лучший и безопасный путь провести миграцию без потерь и сюрпризов – проверить на реальных данных и с реальными конфигурациями, и уже после переносить &laquo;боевые&raquo; базы в новое место. Даже если ваше приложение не “cloud-native”, использование облачных сервисов позволяет получить возможность экспериментировать – воспроизвести реальный use-case в географически распределенной среде на реальном масштабе кластеров и данных. Пользуйтесь ею!</p> <p>&nbsp;</p> <p>На этом на сегодня, пожалуй, все.</p> <p>Спасибо нашим сегодняшним гостям – компании FunCorp!</p> <p>Следите за следующими постами – будет интересно.</p> <p>twitter: @awsoblako</p> Как мониторить состояние AWS инфраструктуры и вовремя получать важные алерты через Corezoid Process Engine? https://aws.amazon.com/ru/blogs/rus/corezoid/ Mon, 03 Oct 2016 21:29:03 +0000 39e2e205cb986e99e4e7edf348ed71c045d90e66 Денис Баталов, архитектор AWS, @dbatalov Друзья, рад представить вам гостевой пост от коллег из ПриватБанка (Украина) – 13-ого по величине банка в Восточной Европе. Из более чем 25 миллионов клиентов банка, 10 миллионов регулярно пользуются онлайн платформой Приват24, и более 5,5 миллионов пользуются его мобильной версией. &nbsp; Недавно ПриватБанк заменил многие из своих систем обработки […] <p><em>Денис Баталов, архитектор AWS,</em> <a href="https://twitter.com/dbatalov" target="_blank">@dbatalov</a><br /> <img class="alignleft" src="https://denisb-public.s3.amazonaws.com/SpeakerDenisSmall.png" alt="Author: Denis V. Batalov" width="70" height="70" /></p> <p>Друзья, рад представить вам гостевой пост от коллег из ПриватБанка (Украина) – 13-ого по величине банка в Восточной Европе. Из более чем 25 миллионов клиентов банка, 10 миллионов регулярно пользуются онлайн платформой Приват24, и более 5,5 миллионов пользуются его мобильной версией.</p> <p>&nbsp;</p> <p>Недавно ПриватБанк заменил многие из своих систем обработки бизнес-логики на гибкий облачный бэкенд названный <a href="http://corezoid.com" target="_blank">Corezoid</a> и созданный отделом R&amp;D банка. В Corezoid всё построено на основе API, а сам он работает на AWS. ПриватБанк также запустил <a href="https://sender.mobi/ru/" target="_blank">Sender</a> – мобильный мессенджер для бизнеса, который позволяет ПриватБанку общаться со своими клиентами, а также клиентам – общаться с другими компаниями предоставляющими услуги. Sender спроектирован с учётом мобильного образа жизни, а его функционал реализован на основе Corezoid. О преимуществах использования Corezoid для банковских нужд вы можете прочитать <a href="https://new.corezoid.com/2016/08/how-a-new-digital-core-can-help-banks-with-the-real-time-processing-of-millions-of-events/" target="_blank">здесь</a>, а в нашем посте речь пойдёт об интересном примере использования Corezoid для мониторинга состояния инфраструктуры AWS. Далее текст коллеги из ПриватБанка.</p> <hr /> <p>&nbsp;</p> <p><em>Павел Шахман, руководитель команды DevOps, Corezoid</em><br /> <img class="alignleft" src="https://s3.amazonaws.com/denisb-aws/rus-blog/corezoid/PavelShakhmanSquareSmall.jpeg" alt="Author: Pavel Shakhman" width="70" height="70" /></p> <p>Для полного контроля за всеми изменениями в вашей AWS инфраструктуре есть замечательный веб-сервис CloudTrail.</p> <p>&nbsp;</p> <p>С помощью CloudTrail можно получить историю вызовов API AWS, сделанных в вашем аккаунте, включая вызовы API, сделанные из Консоли управления AWS или с помощью пакетов AWS SDK, инструментов командной строки и сервисов AWS более высокого уровня (таких как AWS CloudFormation). История вызовов API AWS в CloudTrail делает возможным проведение анализа безопасности, отслеживание изменения ресурсов и аудит соответствия, т.к. включает в себя идентификацию источника, совершившего вызов API, время вызова API, IP-адрес источника, совершившего вызов API, параметры запроса, а также элементы ответа, возвращенные сервисом AWS.</p> <p><span id="more-104"></span></p> <p>С полным списком поддерживаемых в CloudTrail сервисов можно ознакомиться в <a href="http://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-supported-services.html" target="_blank">документации</a>.</p> <p>&nbsp;</p> <p>В этой статье мы расскажем, как легко и быстро настроить уведомления о важных событиях в работе AWS инфраструктуры.</p> <p>&nbsp;</p> <p>Для получения событий из CloudTrail есть два основных пути:</p> <ul> <li>доставка лог файлов в определенную корзину (Amazon S3)</li> <li>доставка событий в указанную лог-группу (CloudWatch Logs)</li> </ul> <p>В первом случае рекомендуется настроить уведомление в SNS-топик о появлении нового файла, а во втором случае уже можно задействовать фильтры в CloudWatch Logs.</p> <p>&nbsp;</p> <p>При попадании событий в лог-группу на них можно применить различные пользовательские фильтры и связать их с CloudWatch Alarms, создав Alarm на каждый из них, для получения уведомлений, например всё в тот же SNS-топик.</p> <p>&nbsp;</p> <p>Настроить начальный набор фильтров достаточно легко – для этого можно использовать любезно предоставленный компанией AWS шаблон ☺.</p> <p>&nbsp;</p> <p>Если загрузить его в AWS CloudFormation Designer, то можно хоть как-то визуализировать создаваемые проверки, их взаимосвязи и в дальнейшем модифицировать этот шаблон, применяя обновления стека после каждой модификации.</p> <p>&nbsp;</p> <p><img class="aligncenter" src="https://s3.amazonaws.com/denisb-aws/rus-blog/corezoid/05-cloudformation-alarms.png" alt="CloudFormation Designer" width="614" height="612" /></p> <p>&nbsp;</p> <p>При срабатывании какого-либо фильтра, например на изменение Security Group, вы получите через SNS-топик сообщение:</p> <p>&nbsp;</p> <p><img class="aligncenter" src="https://s3.amazonaws.com/denisb-aws/rus-blog/corezoid/08-sns-mail.png" alt="SNS mail" width="1312" height="607" /></p> <p>&nbsp;</p> <p>Кроме этого можно получить доступ ко всем событиям CloudTrail используя AWS Console и, оперируя заданным набором фильтров, можно просматривать события через веб-интерфейс.</p> <p>&nbsp;</p> <p><img class="aligncenter" src="https://s3.amazonaws.com/denisb-aws/rus-blog/corezoid/cloudtrail_api_call_list_3.png" alt="CloudTrail Console" width="910" height="389" /></p> <p>&nbsp;</p> <p>Но заглядывать каждый раз в табличку и вручную что-то искать не очень удобно. Дальше мы расскажем как можно облегчить себе задачу по поддержке существующего набора фильтров, быстрому добавлению новой логики и визуализации. Как настроить отправление уведомлений в любой удобный канал коммуникации, где ответственному сотруднику удобно читать такие сообщения: мессенджер, е-майл или, к примеру, Slack.<br /> В нашем случае для получения уведомлений мы используем мобильный мессенджер Sender (Sender.mobi).</p> <p>&nbsp;</p> <p>Сервис CloudTrail сохраняет информацию о событии в течение 15 минут после вызова API и отправляет файлы логов в корзину примерно через каждые пять минут. Таким образом нужно учитывать, что задержка между временем события и уведомлением может быть до 20 мин. Если файлы с архивами не появляются в корзине – проверьте ее политику, возможно при редактировании допущена ошибка и CloudTrail не может сохранить файл.</p> <p>&nbsp;</p> <p>Напишем небольшую функцию Lambda, которая будет срабатывать при появлении нового архива с событиями в указанной выше S3 корзине.</p> <p>&nbsp;</p> <p>Для написания функций Lambda в AWS можно использовать Python, Node.js, Java. <a href="https://github.com/corezoid/aws-cloudtrail-events-processing/blob/master/fromCloudTrailToCorezoid.py" target="_blank">Нашу функцию</a> мы написали на Python.</p> <p>&nbsp;</p> <p>Она связана триггером с S3 корзиной и срабатывает по событию типа ObjectCreatedByPut: достает файл, распаковывает и отправляет массив событий (events) через API в наш Corezoid Process Engine. Эта функция срабатывает на каждый PUT файла в корзину: достает файл, распаковывает и отправляет массив событий (events) через API в наш Corezoid Process Engine.</p> <p>&nbsp;</p> <p>Corezoid Process Engine – это наша собственная технология, доступная по адресу Corezoid.com, а также в <a href="http://aws.amazon.com/marketplace/pp/B013AYOIYG" target="_blank">Amazon Marketplace</a>.</p> <p>&nbsp;</p> <p>Corezoid может получать данные из любого источника через API, обрабатывать их согласно заданной логике и возвращать ответ в любую внешнюю систему, также через API.<br /> Вот список логик, которые доступны в Corezoid:</p> <p>&nbsp;</p> <table border="1" cellspacing="0" cellpadding="7"> <tbody> <tr valign="top"> <td><span style="font-size: small"><b>Название</b></span></td> <td><span style="font-size: small"><b>Описание</b></span></td> </tr> <tr valign="top"> <td><a href="https://doc.corezoid.com/ru/counter.html"><span style="color: #4183c4"><span style="font-size: small"><b>Task<br /> Counter (Alert when there is tasks queue) </b></span></span></a></td> <td>Используется для запуска/закрытия эскалации по количеству задач в узле. Например, пусть необходимо реагировать на разное количество задач в очереди, которые требуют обработки. Если количество объектов в очереди превышает:<p></p> <ul> <li>50 – уведомляем менеджера;</li> <li>100 – уведомляем руководителя менеджера.</li> </ul> <p>При снижении количества объектов в очереди мы сможем уведомить менеджера/руководителя о уменьшении количества необработанных задач</p></td> </tr> <tr valign="top"> <td><a href="https://doc.corezoid.com/ru/timer.html"><span style="color: #4183c4"><span style="font-size: small"><b>Time<br /> limit (Limit the time of the task in the node)</b></span></span></a></td> <td>Если время нахождение задачи в узле превышает предельное время, то задача переводится в целевой узел</td> </tr> <tr valign="top"> <td><span style="color: #4183c4"><span style="font-size: small"><b>Go</b></span></span></td> <td>Задача безусловно переводится в целевой узел. Является последней командой в программе обработки</td> </tr> <tr valign="top"> <td><span style="color: #4183c4"><span style="font-size: small"><b>Condition</b></span></span></td> <td>Условие является конъюнкцией сравнений значений параметров задачи с константами. Если условие выполнено, то задача переводится в целевой узел</td> </tr> <tr valign="top"> <td><span style="color: #4183c4"><span style="font-size: small"><b>API<br /> Call</b></span></span></td> <td>Синхронный вызов метода внешнего API в форматах JSON, XML, SOAP. Задача зависает в узле, пока метод API выполняется</td> </tr> <tr valign="top"> <td><span style="color: #4183c4"><span style="font-size: small"><b>Waiting<br /> for callback</b></span></span></td> <td>Синхронизация с внешним процессом. Задача зависает в узле, пока не придет ответ от внешнего процесса</td> </tr> <tr valign="top"> <td><a href="https://doc.corezoid.com/ru/code.html"><span style="color: #4183c4"><span style="font-size: small"><b>Code</b></span></span></a></td> <td>Интерпретируется фрагмент кода на указанном языке (Java Script или Erlang). Доступ к параметрам задачи – через переменную <span style="color: #4183c4"><span style="font-size: small"><b>data</b></span></span></td> </tr> <tr valign="top"> <td><a href="https://doc.corezoid.com/ru/code.html"><span style="color: #4183c4"><span style="font-size: small"><b>Copy<br /> task</b></span></span></a></td> <td>Задача, возможно, частично копируется в начальный узел другого процесса</td> </tr> <tr valign="top"> <td><span style="color: #4183c4"><span style="font-size: small"><b>Modify<br /> task</b></span></span></td> <td>Задача, возможно, частично модифицируется, если находится в узле Waiting for callback или Set state</td> </tr> <tr valign="top"> <td><span style="color: #4183c4"><span style="font-size: small"><b>Call<br /> process</b></span></span></td> <td>Задача, возможно, частично копируется в начальный узел другого процесса, тем самым вызывается обработка этой задачи другим процессом. Когда обработка закончена, вызванный процесс должен вернуть обработанную задачу командой <span style="color: #4183c4"><span style="font-size: small"><b>Reply<br /> to process</b></span></span></td> </tr> <tr valign="top"> <td><span style="color: #4183c4"><span style="font-size: small"><b>Reply<br /> to process </b></span></span></td> <td>Задача возвращается вызвавшему процессу. Идентификатор процесса хранится в самой задаче</td> </tr> <tr valign="top"> <td><span style="color: #4183c4"><span style="font-size: small"><b>Sum</b></span></span></td> <td>Суммируются значения некоторых параметров задачи</td> </tr> <tr valign="top"> <td><span style="color: #4183c4"><span style="font-size: small"><b>Set<br /> parameter</b></span></span></td> <td>Присваивается значение параметру задачи</td> </tr> <tr valign="top"> <td><a href="https://doc.corezoid.com/ru/queue/index.html"><span style="color: #4183c4"><span style="font-size: small"><b>Queue</b></span></span></a></td> <td>Текущая задача переводится в локальное хранилище. При этом хранилище может работать в одном из двух режимов: в режиме очереди (FIFO = First In First Out) или в режиме стека (LIFO = Last In First Out). Задача находится в хранилище, пока не<br /> поступит сигнал<br /> <span style="color: #4183c4"><span style="font-size: small"><b>Get<br /> task from queue </b></span></span></td> </tr> <tr valign="top"> <td><span style="color: #4183c4"><span style="font-size: small"><b>Get<br /> task from queue </b></span></span></td> <td>Из очереди в указанном процессе и в указанном узле извлекается задача для обработки</td> </tr> <tr valign="top"> <td><span style="color: #4183c4"><span style="font-size: small"><b>Delay</b></span></span></td> <td>Обработка задачи приостанавливается на указанное время</td> </tr> </tbody> </table> <p>&nbsp;</p> <p>Используя эти логические блоки мы настроим отправку уведомлений для Non-API событий:</p> <ul> <li>попытки входа в AWS аккаунт;</li> <li>создание\удаление spot-инстансов.</li> </ul> <p>&nbsp;</p> <p style="text-align: center"><strong>Логика в Corezoid</strong></p> <p>Построим небольшой проект, состоящий из процесса-маршрутизатора и процессов для обработки 2-х основных типов событий CloudTrail: API вызовов и Non-API events.<br /> Первым делом, создаем папку, три новых процесса в Corezoid и настраиваем соответствующие узлы.</p> <p>&nbsp;</p> <p><img class="aligncenter" src="https://s3.amazonaws.com/denisb-aws/rus-blog/corezoid/04-process-list.png" alt="Corezoid Process List" width="370" height="296" /></p> <p>&nbsp;</p> <p>Для безопасной передачи данных в Corezoid создадим API-пользователя и сохраним его login, secret key и process id процесса-маршрутизатора – эти данные понадобятся для настройки нашей функции Lambda.<br /> API пользователю мы разрешим отправлять заявки в настройках папки с процессами:</p> <p>&nbsp;</p> <p><img class="aligncenter" src="https://s3.amazonaws.com/denisb-aws/rus-blog/corezoid/07-grant-access.png" alt="Corezoid Grant Access" width="1852" height="766" /></p> <p>&nbsp;</p> <p>Процесс – маршрутизатор имеет вид:</p> <p>&nbsp;</p> <p><img class="aligncenter" src="https://s3.amazonaws.com/denisb-aws/rus-blog/corezoid/01-event-router.png" alt="Event Router" width="1789" height="865" /></p> <p>&nbsp;</p> <ul> <li>В начале обработки в зависимости от аккаунта (логика Condition) мы заменяем числовой идентификатор на любой удобный алиас (например, логика Set Parameter -&gt; AccountAlias == “Corezoid Demo” и т.д.).</li> <li>В узле “Route by Event Type” мы в зависимости от типа события отправляем его на обработку в процесс Api Events или Non-Api Events.</li> </ul> <p>Процесс, реализующий обработку Non-Api событий, в веб-интерфейсе Corezoid выглядит примерно так:</p> <p>&nbsp;</p> <p><img class="aligncenter" src="https://s3.amazonaws.com/denisb-aws/rus-blog/corezoid/03-non-api-check.png" alt="Corezoid Non-API check" width="1920" height="1080" /></p> <p>&nbsp;</p> <p>В узле Сlassifier после определения типа событие направляется в нужную ветку обработки, где проставляются все необходимые флаги и в конечном итоге событие уходит в указанный канал отправки.<br /> Ниже вы можете видеть пример реального события после обработки в Corezoid:</p> <pre>{ &quot;eventVersion&quot;: &quot;1.04&quot;, &quot;eventID&quot;: &quot;bbf878c3-7138-4207-929d-5b4b1450fea8&quot;, &quot;eventTime&quot;: &quot;2016-10-02T17:51:36Z&quot;, &quot;additionalEventData&quot;: { &quot;MobileVersion&quot;: &quot;No&quot;, &quot;LoginTo&quot;: &quot;https://console.aws.amazon.com/console/home?state=hashArgs%23&amp;isauthcode=true&quot;, &quot;MFAUsed&quot;: &quot;No&quot; }, &quot;recipientAccountId&quot;: &quot;\&quot;Corezoid Dev\&quot;&quot;, &quot;requestParameters&quot;: null, &quot;eventType&quot;: &quot;AwsConsoleSignIn&quot;, &quot;errorMessage&quot;: &quot;Failed authentication&quot;, &quot;responseElements&quot;: { &quot;ConsoleLogin&quot;: &quot;Failure&quot; }, &quot;awsRegion&quot;: &quot;us-east-1&quot;, &quot;eventName&quot;: &quot;ConsoleLogin&quot;, &quot;userIdentity&quot;: { &quot;accountId&quot;: &quot;111111111111&quot;, &quot;principalId&quot;: &quot;AIDAJX3TJPA3E2GX6IZYC&quot;, &quot;type&quot;: &quot;IAMUser&quot;, &quot;accessKeyId&quot;: &quot;&quot;, &quot;userName&quot;: &quot;JohnDoe&quot; }, &quot;eventSource&quot;: &quot;signin.amazonaws.com&quot;, &quot;userAgent&quot;: &quot;Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0&quot;, &quot;sourceIPAddress&quot;: &quot;159.224.244.142&quot;, &quot;__conveyor_copy_task_result__&quot;: &quot;ok&quot;, &quot;MyEventDetails&quot;: &quot;Failed to login in account \&quot;Corezoid Dev\&quot; from ip 159.224.244.142&quot;, &quot;MfaUsage&quot;: &quot;False&quot;, &quot;MessageChannel&quot;: &quot;sender&quot;, &quot;Message&quot;: &quot;User: JohnDoe\\nAccount: 111111111111\\nMFA: False\\nType: IAMUser\\n\\nFailed to login in account \&quot;Corezoid Dev\&quot; from ip 159.224.244.142&quot; }</pre> <p>И уведомления в мессенджере Sender:</p> <p>&nbsp;</p> <p><img class="aligncenter" src="https://s3.amazonaws.com/denisb-aws/rus-blog/corezoid/06-sender-alerts.png" alt="Sender Alerts" width="360" height="640" /></p> <p>&nbsp;</p> <p>Итак, наш процесс в Corezoid получает от функции Lambda поток событий и согласно заданной логике отправляет алерты во внешний фронт-енд. В нашем случае, в качестве фронт-енда мы использовали мобильный мессенджер Sender (Sender.mobi), но Corezoid может отправлять через API алерты в любые внешние системы: Slack, E-mail, Sms.</p> <p>&nbsp;</p> <p>Обработка событий CloudTrail с помощью Corezoid поможет Вам быстро и эффективно построить процессы для облегчения соответствия требованиям безопасности и раннего обнаружения архитектурных проблем и ошибок конфигураций ПО.</p> <p>&nbsp;</p> <p>Вы можете уже сейчас зарегистрироваться на <a href="https://www.corezoid.com" target="_blank">www.corezoid.com</a> и оценить удобство нашего подхода в обработке событий CloudTrail.</p> <p>&nbsp;</p> <p>Все материалы из статьи и краткое руководство по их применению доступны в <a href="https://github.com/corezoid/aws-cloudtrail-events-processing" target="_blank">нашем репозитории</a>.</p> Основные способы оптимизации стоимости на AWS https://aws.amazon.com/ru/blogs/rus/cost-optimization-capabilities/ Wed, 01 Jun 2016 08:00:40 +0000 2a5529fadb44d88eeca67926b46946b6deefbcf4 Андрей Зайчиков, архитектор AWS Всем привет! Сегодня мы поговорим об основных и наиболее часто используемых возможностях оптимизации затрат на сервисы AWS. Основные варианты оптимизации затрат К таким вариантам относятся в первую очередь: Зарезервированные инстансы (Reserved Instances) – для постоянных нагрузок; Scheduled Reserved Instances – для нагрузок, постоянно возникающих в четко определенные моменты времени; Спотовые инстансы […] <p style="text-align: right"><em>Андрей Зайчиков, архитектор AWS</em></p> <p>Всем привет!</p> <p>Сегодня мы поговорим об основных и наиболее часто используемых возможностях оптимизации затрат на сервисы AWS.</p> <p><strong>Основные варианты оптимизации затрат</strong><br /> К таким вариантам относятся в первую очередь:</p> <ul> <li>Зарезервированные инстансы (Reserved Instances) – для постоянных нагрузок;</li> <li>Scheduled Reserved Instances – для нагрузок, постоянно возникающих в четко определенные моменты времени;</li> <li>Спотовые инстансы (Spot Instances) – &shy; для получения во временное пользование простаивающих серверов на сотовом рынке (с существенной скидкой);</li> <li>Оптимизация времени использования ресурсов;</li> <li>Оптимизация объема использования ресурсов;</li> <li>Контроль неиспользуемых ресурсов.</li> </ul> <p><span id="more-65"></span></p> <p>Прежде чем начать рассматривать каждый из этих вариантов более подробно хочу обратить ваше внимание, что перечисленные способы оптимизации – отнюдь не единственные способы оптимизации затрат.</p> <p><strong>Зарезервированные инстансы (Reserved Instances)</strong><br /> Если вы точно знаете, что определенное количество EC2 машин будет использоваться постоянно в течение года или даже более длительного периода, RI – отличный способ сэкономить. Стоимость RI состоит из двух основных компонент – начальный платеж и платеж за час работы сервера. Кроме экономии вы получаете гарантию наличия мощности в вашем распоряжении на протяжении периода резервирования.</p> <p>RI – это способ резервирования EC2 машин, который доступен в трех вариантах:</p> <ul> <li><em>No Upfront</em> – нет начального платежа, наименьшая скидка в сравнении с другими RI;</li> <li><em>Partial Upfront</em> – этот вариант предполагает достаточно существенный начальный платеж и, соответственно, существенную скидку на использование EC2;</li> <li><em>All Upfront</em> – вся стоимость EC2 машины выплачивается сразу, однако итоговая годовая стоимость будет существенно ниже. Кроме существенного снижения стоимости эта опция может рассматриваться в качестве средства управления валютными рисками.</li> </ul> <p>Кроме описанных выше вариантов относительно недавно появилась&nbsp; возможность резервирования части времени EC2 машин для выполнения периодических задач (например, ежемесячная обработка отчетности). Такой вариант резервирования называется Scheduled Reserved Instances. Стоимость таких машин несколько ниже, чем заказ виртуальных машин по требованию.</p> <p>Посчитать стоимость RI можно с использованием <a href="http://calculator.s3.amazonaws.com/index.html" target="_blank">Simple Monthly Calculator</a> (не забудьте указать корректный регион).</p> <p>Стоит добавить, что концепция резервирования применяется в AWS не только по отношению к EC2 машинам, но и ко многим другим сервисам, в том числе к <a href="https://aws.amazon.com/dynamodb/pricing/" target="_blank">DynamoDB</a>, <a href="https://aws.amazon.com/rds/reserved-instances/" target="_blank">RDS</a>, <a href="https://aws.amazon.com/redshift/pricing/" target="_blank">Redshift</a>, <a href="https://aws.amazon.com/elasticache/reserved-cache-nodes/" target="_blank">ElasticCache</a>.</p> <p><strong>Спотовые инстансы (Spot Instances)</strong><br /> Spot Instances – это, фактически, простаивающие на текущий момент виртуальные мощности.</p> <p>Спотовые инстансы могут быть заказаны в двух основных вариантах:</p> <ul> <li>Обычные Spot Instances;</li> <li>Spot Instances для продолжительного использования (defined duration).</li> </ul> <p>Механика очень простая – вначале вы делаете ставку. Запустить spot машину вы можете в тот момент, когда стоимость машины на спотовом рынке окажется ниже вашей ставки. Хорошая новость в том, что теоретически, при использовании Spot Instances, вы можете сэкономить до 90% стоимости от начальной стоимости ресурса. Обратная сторона медали – &nbsp;машина может быть остановлена в любой момент времени (если кто-то перебьет вашу ставку), однако при выключении машины вам будет дано две минуты на выполнение необходимых шагов перед выключением. Spot инстансы могут быть использованы в auto-scaling events либо, что встречается чаще, в качестве ресурсов для запуска больших вычислительных нагрузок.</p> <p>Ниже приведем диаграмму жизненного цикла spot.</p> <p><img class="alignnone" src="https://s3-eu-west-1.amazonaws.com/zaychiko-aws-blog/lifecycle.png" alt="Жизненный цикл spot instance" width="744" height="349" /></p> <p>Также существует специальный инструмент для <a href="https://aws.amazon.com/ec2/spot/bid-advisor/">оценки вероятности потери спотового инстанса</a>.</p> <p>Спотовые инстансы с заданной продолжительнустью использования подразумевают, что, в отличие от обычных spot машин, они точно проработают заданное время (можно выбрать от одного до шести часов с шагом в один час). В случае использования таких машин вы гарантированно получаете 50% скидки.</p> <p>Более подробно по стоимости spot instances можно узнать <a href="https://aws.amazon.com/ec2/spot/pricing/" target="_blank">здесь</a> (не забудьте указать нужный вам регион и тип spot или defined duration).</p> <p>Ниже приведена сравнительная схема основных вариантов оплаты EC2.</p> <p><img class="alignnone" src="https://s3-eu-west-1.amazonaws.com/zaychiko-aws-blog/ec2-pricing.png" alt="Варианты оплаты ресурсов EC2" width="1014" height="454" /></p> <p><strong>Варианты оптимизации</strong></p> <p><strong><em>Оптимизация времени работы</em></strong><br /> Оптимизация времени работы ресурсов dev/test среды – это интересная и часто недооцененная возможность экономии значительных средств. Кроме того, использовать эту возможность довольно просто – необходимо просто настроить машины таким образом, чтобы их можно было включать и выключать без потери данных, результатов тестирования и (если кто-то так делает) изменений в коде. Это вполне реализуемо с использованием таких функций, как EC2 AMI, EBS, CloudFormation и других, а также с использованием средств автоматизации. Отдельно нужно отметить, что технологически включение и выключение среды без потери состояния и данных – первый шаг к реализации HA &amp; DR для ваших приложений.</p> <p>Оптимизация времени работы может сэкономить вам много средств если вся ваша команда работает не 24/7.</p> <p><em><strong>Оптимизации объема ресурсов</strong></em><br /> Эта рекомендация носит вполне очевидный характер и, как все очевидные вещи, чаще других забывается. Всегда необходимо помнить, что AWS позволяет вам самостоятельно получить необходимые ресурсы в тот момент, когда у вас возникла потребность.</p> <p>В момент, когда вам потребуются ресурсы вам не нужно будет выполнять сложные административные процедуры или ждать несколько дней, пока служба эксплуатации выделит вам необходимые мощности. Вы можете получить все сразу.</p> <p>Скажу еще раз. Потребляйте ровно тот объем ресурсов, который вам нужен именно сейчас. Постарайтесь не:</p> <ul> <li>Не заказывать виртуальные диски со 100%м запасом – когда понадобится вы выделите новый диск и подключите к своей виртуальной машине;</li> <li>Не выделять мощные машины для рутинного функционального тестирования;</li> <li>Не использовать в рутинной работе гигантские объемы данных;</li> <li>Не устанавливать все заново каждый раз – используйте AMI;</li> <li>Не пренебрегать долгосрочными архивами и data lifecycle;</li> <li>Не злоупотреблять возможностью получить все сейчас – планируйте активности (анализ больших логов лучше проводить на Spot с минимальной ценой, проводить нагрузочное тестирование с on-demand EC2 в черную пятницу лучше перенести на более спокойное время и проч.);</li> <li>Не злоупотреблять ручными операциями – старайтесь использовать средства автоматизации;</li> <li>Не стесняться взаимодействовать – обратитесь в AWS и вам помогут если лимиты исчерпаны и кажется, что все пропало. Посмотрите на техническую поддержку – если нет времени ждать и, в особенности, если вы используете AWS для продуктивных сред.</li> </ul> <p>Ошибаюсь? Сталкивались с ситуациями, когда нет capacity для выделения ресурса? Подождите полчаса. Не хотите ждать? Стартуйте новую машину похожего типа. Диск инициализируется слишком долго? Посмотрите документацию – скорость инициализации можно оптимизировать. Достигнут лимит? Обратитесь в службу поддержки – вам их увеличат. Все проблемы решаемы. Если чего-то действительно не хватает – мы включим это в наш roadmap.</p> <p><em><strong>Контроль неиспользуемых ресурсов</strong></em><br /> Неиспользуемые ресурсы нередко становятся существенным источником расходов в AWS. Чаще всего неиспользуемые ресурсы возникают из-за некорректных настроек отдельных сервисов (например, EBS не удалился при удалении EC2 машины, т.к. был установлен флаг сохранения диска при удалении инстанса), непонимания основных концепций платежей (к примеру, Elastic IP долго остается не привязанным к конкретному ресурсу) или же при выполнении большого количества действий в ручном режиме (например, ручной provisioning и bootstrapping распределенной системы с использованием Management Console).</p> <p>Если спроецировать такую ситуацию на распределенную команду разработчиков, которая проводит множество экспериментов и одновременно работает над большим количеством проектов проблема неиспользуемых ресурсов может приобрести достаточно серьезный масштаб.</p> <p>В AWS есть несколько основных способов определения наличия неиспользуемых ресурсов. К самым доступным можно отнести:</p> <ul> <li>Прогнозирование счета с помощью Cost Explorer;</li> <li>Trusted Advisor – инструмент, выдающий рекомендации по четырем основным направлениям (безопасность, производительность, надежность и оптимизация стоимости).</li> </ul> <p>Кроме того, мы предлагаем вашему вниманию несколько основных рекомендаций при работы с AWS, которые позволят сократить вероятность появления неиспользуемых ресурсов:</p> <ul> <li>ограничивайте права разработчиков – выделяйте своим разработчикам права по мере необходимости, создайте каждому по отдельной подсети для экспериментов, используйте VPC и тэги для контроля scope проекта – это поможет понять, кто и сколько ресурсов потратил, а также сократит риск запуска ненужных ресурсов;</li> <li>используйте тэги – они помогут вам лучше разбираться и контролировать вашу среду. Правильно организовав тэги вы всегда сможете определить, что, кто, когда и кем было запущено, а также (что немаловажно) можно ли это выключить;</li> <li>используйте средства автоматизации для выделения и освобождения ресурсов (Amazon CloudFormation) – они позволяют не только создавать, но и корректно освобождать ресурсы стека. Вы можете создавать и удалять целые среды с использованием одного инструмента просто нажав одну кнопку;</li> <li>если вы используете собственные скрипты – не забывайте удалять ресурсы, обычно они связаны друг с другом. Ошибки при удалении позволят найти неиспользуемые ресурсы;</li> <li>не недооценивайте влияние правильно построенной архитектуры на итоговую стоимость решения – рассматривайте сервисы AWS уровня приложений.</li> </ul> <p>На этом на сегодня, пожалуй, все.</p> <p>Всем спасибо!</p> <p>Следите за следующими постами – будет интересно.</p> <p>twitter: @awsoblako</p> AWS для разработчиков. Типовые сценарии использования AWS https://aws.amazon.com/ru/blogs/rus/aws-for-developers-overview/ Wed, 01 Jun 2016 07:59:34 +0000 0deff36d58e54601ce8402505accbeedaf4b9ff9 Андрей Зайчиков, Архитектор AWS Всем привет! Этим постом мы открываем серию публикаций по использованию Amazon Web Services для создания и управления средами разработки и тестирования. Это будет серия постов, отражающих разные аспекты создания, управления и использования сред разработки и тестирования на AWS. Однако для начала хотелось бы сделать краткий обзор того, для чего вообще создавать […] <p style="text-align: right"><em>Андрей Зайчиков, Архитектор AWS</em></p> <p>Всем привет!</p> <p>Этим постом мы открываем серию публикаций по использованию Amazon Web Services для создания и управления средами разработки и тестирования. Это будет серия постов, отражающих разные аспекты создания, управления и использования сред разработки и тестирования на AWS.</p> <p>Однако для начала хотелось бы сделать краткий обзор того, для чего вообще создавать тестовые среды с использованием AWS. В чем преимущества? Какие основные сценарии? Какие основные возможности?</p> <p>Если вы когда-нибудь начинали работать над ИТ проектом с нуля&nbsp;– вы точно знаете, что Аристотель был прав. Это как раз тот случай, когда начало – это, как минимум, половина дела.</p> <p><span id="more-36"></span></p> <p>Прежде чем приступить непосредственно к работе, нужно сделать несколько простых действий:</p> <ul> <li>Настроить репозитории;</li> <li>Настроить тестовые среды;</li> <li>Настроить среду для проектной документации;</li> <li>Настроить build и CI сервера;</li> <li>Завести проект в баг трекер, настроить представления для клиента, настроить отчеты для менеджеров;</li> <li>Завести почтовые рассылки и группы в мессенджерах;</li> <li>Убедиться, что у всех есть доступ;</li> <li>Далее&nbsp;– в зависимости от того, насколько большая команда, проект, насколько &laquo;продвинутый&raquo; заказчик и проч.</li> </ul> <p>Как раз на этом этапе пойдет всё не так, как может пойти. Окажется, что часть арендованных серверов занята, аренда части ресурсов подходит к концу, человек, который в прошлом проекте отвечал за документацию уволился, а для хранения вики вы всегда использовали его собственный аккаунт на файл-шеринге. Команда поменяется на 30% и появятся еще две субподрядные организации, которые слыхом не слыхивали о половине ваших инструментов и пользуются своими, появятся удаленные разработчики; централизованного почтового сервиса у вас никогда не было, баг-трекер хочется поменять и нужно перенести данные. Да мало ли, что пойдет не так.</p> <p>И это, естественно, только на первом этапе. Дальше будет увеличение ресурсов где-нибудь на collocation, незапланированный переезд, долгий процесс настройки сети и последующие разборки, насколько сеть влияет на тестирование. Болезненный сбор логов, метрик и сравнение одного с другим.</p> <p>Естественно, операционные проблемы будут возникать на каждом этапе и отнимать время разработчиков, администраторов и менеджеров на решение задач, которые напрямую к делу не относятся.</p> <p>Очевидно, когда трудозатраты на администрирование очень большие, эксперименты становятся довольно накладными и рисковать временем и ресурсами не хочется. На одном из моих предыдущих проектов (вне рамок AWS) выделение одного &laquo;голого&raquo; сервера с Ubuntu для экспериментов удаленного разработчика заняло 32 дня при условии, что ресурсы были в наличии.</p> <p>Кроме того, обычно затраты на ресурсы тестовых сред – первый кандидат на сокращение затрат, а обосновать необходимость вложений (в особенности капитальных) в создание инфраструктуры тестовых сред практически невохможно.</p> <p>Вот, что мы получаем.</p> <p><img class="alignnone" src="https://s3-eu-west-1.amazonaws.com/zaychiko-aws-blog/problems.jpg" alt="Проблематика работы со средами команды" width="968" height="729" /></p> <p>AWS позволяет существенно изменить подход к организации и использованию тестовых сред. Есть несколько основных преимуществ платформы, позволяющих решить часть из описанных выше проблем.</p> <ul> <li>Вы всегда знаете, где можно получить необходимое количество ресурсов, а также, то, что эти ресурсы будут предоставлены по требованию;</li> <li>Вы платите только за то, что используете (например: выборочная остановка виртуальных машин по окончании рабочего дня, по выходным и в праздники позволит рациональнее расходовать ресурсы);</li> <li>Вы полностью контролируете выделение, использование и стоимость ресурсов (доступ к ресурсам, управление ресурсами; политики контроля стоимости ресурсов и проч.);</li> <li>В AWS уже есть большое количество сервисов, обычно входящих в состав общих ресурсов команды разработчиков (S3, CodeCommit, CodeDeploy, проч.). Для многих популярных продуктов существуют заранее подготовленные образы виртуальных машин (Amazon Machine Image – AMI), включающих лицензию в стоимость использования;</li> <li>У вас есть практически неограниченный объем ресурсов в зрелых регионах;</li> <li>Вам не нужно тратить время на админитсрирование: значительная часть сервисов AWS не требует никакой дополнительной работы по администрированию.</li> </ul> <p>Есть несколько основных сценариев использования тестовых сред и сред разработки:</p> <ul> <li>Персональные тестовые среды;</li> <li>Общие ресурсы команды разработчиков;</li> <li>Среды для быстрого прототипирования;</li> <li>Prod-like среды.</li> </ul> <p>Все четыре сценария могут быть одновременно реализованы с использованием сервисов AWS. Архитектура общей среды разработки и тестирования при этом может выглядеть примерно так, как показано на рисунке ниже.</p> <p><img class="alignnone" src="https://s3-eu-west-1.amazonaws.com/zaychiko-aws-blog/all+use-cases.png" alt="Вариант размещения всех четырех сред на AWS" width="2550" height="1934" /></p> <p>В этом сценарии:</p> <ul> <li>Используются<strong> три AWS accounts:</strong> один для общих ресурсов и персональных сред, один для прототипирования, один для организации продуктивной среды;</li> <li><strong>Virtual Private Cloud (VPC)</strong> используется для разделения ресурсов по подсетям, упрощения контроля ресурсов и эмуляции реальной сети. Доступ к VPC осуществляется через VPN туннель или Интернет;</li> <li><strong>Elastic Compute Cloud (EC2)</strong> используется в качестве основных вычислительных ресурсов. Это виртуальные сервера в облаке, которые разворачиваются с использованием Amazon Machine Image (AMI);</li> <li><strong>Simple Storage Service (S3)</strong> – объектное хранилище, которое можно использовать для хранения объектов (очевидно ;)) любых типов и объемов (размер одного объекта до 5Tb);</li> <li><strong>CloudFormation</strong> используется для автоматизации процедуры выделения ресурсов,&nbsp; в том числе, связанных ресурсов.</li> </ul> <p>Несколько интересных ресурсов и видео:</p> <ul> <li><a href="https://aws.amazon.com/ru/" target="_blank">Наша главная страница теперь на русском</a></li> <li><a href="https://www.youtube.com/watch?v=JIQETrFC_SQ" target="_blank">Видео (en): AWS Innovation at Scale</a></li> <li><a href="https://www.youtube.com/watch?v=hdIYrzjBhmA" target="_blank">Видео (en): Dev &amp; Test on AWS</a></li> <li><a href="https://www.youtube.com/watch?v=DU3yilHrDBU" target="_blank">Видео (en): Development &amp; Test</a></li> <li><a href="https://d0.awsstatic.com/whitepapers/managing-your-aws-infrastructure-at-scale.pdf" target="_blank">Whitepaper (en): Managing your AWS Infrastructure at scale</a></li> <li><a href="https://d0.awsstatic.com/whitepapers/aws-development-test-environments.pdf" target="_blank">Whitepaper (en): Development and Test on AWS</a></li> </ul> <p>На сегодня, пожалуй, все. Спасибо за внимание.</p> <p>Следите за нашими следующими постами. Будет интересно!</p> Всем привет! https://aws.amazon.com/ru/blogs/rus/vsem-privet/ Thu, 10 Mar 2016 15:32:45 +0000 66baf2b5238990c4bb0f6f2b9a036876121f9ab5 Денис Баталов, архитектор AWS, @dbatalov Друзья, сегодня мы запускаем русскоязычный блог Amazon Web Services! Мы планируем прежде всего фокусироваться на темах которые будут интересны русскоговорящим пользователям AWS. &nbsp;Собираемся публиковать как глубоко технические посты на узкие темы, так и обзорные посты по новым сервисам и функционалу, или по новым преимуществам использования облака AWS с точки зрения […] <p><em>Денис Баталов, архитектор AWS,</em> <a href="https://twitter.com/dbatalov" target="_blank">@dbatalov</a><br /> <img class="alignleft" src="https://denisb-public.s3.amazonaws.com/SpeakerDenisSmall.png" alt="Author: Denis V. Batalov" width="70" height="70" /></p> <p>Друзья, сегодня мы запускаем русскоязычный блог Amazon Web Services!</p> <p>Мы планируем прежде всего фокусироваться на темах которые будут интересны русскоговорящим пользователям AWS. &nbsp;Собираемся публиковать как глубоко технические посты на узкие темы, так и обзорные посты по новым сервисам и функционалу, или по новым преимуществам использования облака AWS с точки зрения организации и трансформации бизнеса.</p> <p>Пользуясь случаем, хочу напомнить что <a href="http://aws.amazon.com/ru/" target="_blank">основные страницы сайта AWS</a> уже доступны на русском языке, а для пользователей Twitter мы ведём русско-язычный микроблог <a href="https://twitter.com/awsoblako" target="_blank">@awsoblako</a>. Кроме этого вам доступны следующие материалы на русском (вебинары доступны после бесплатной регистрации на сайте BrightTalk):</p> <ul> <li>YouTube видео: <a href="https://www.youtube.com/watch?v=OkLHxpHOv2k" target="_blank">Принципы построения высоконагруженных сайтов на платформе АWS</a></li> <li>Обучающий вебинар: <a href="https://www.brighttalk.com/webcast/10089/171289" target="_blank">Amazon Simple Storage (S3) 22.09.2015</a></li> <li>Обучающий вебинар: <a href="https://www.brighttalk.com/webcast/10089/171301" target="_blank">Amazon Elastic Compute Cloud (EC2) 22.09.2015</a></li> <li>Обучающий вебинар: <a href="https://www.brighttalk.com/webcast/10089/171303" target="_blank">Amazon Elastic MapReduce (EMR) 22.09.2015</a></li> <li>Вебинар: <a href="https://www.brighttalk.com/webcast/10089/181191" target="_blank">AWS QuickQuestions – Ответы на вопросы по AWS Virtual Private Cloud, гибридной архитектуре и VPN 07.12.2015</a></li> <li>Вебинар: <a href="https://www.brighttalk.com/webcast/10089/181195" target="_blank">AWS QuickQuestions – Ответы на вопросы по DevOps сервисам 25.11.2015</a></li> <li>Вебинар: <a href="https://www.brighttalk.com/webcast/10089/126381" target="_blank">AWS QuickQuestions – ответы на вопросы слушателей 25.11.2014</a></li> </ul> <p>В самом первом посте я хотел бы оглянуться чуть-чуть назад и рассказать немного о том как часто&nbsp;у нас запускаются новые сервисы, новые возможности существующих сервисов и просто обновления.</p> <p>Например, в 2011 году мы осуществили 80 релизов значимых сервисов и возможностей. В 2012 – уже почти 160, в 2013 – 280, а в 2014 мы произвели уже 516 релизов. В прошлом 2015 году мы запустили 722 возможности и сервиса, что на 40% выше предыдущего года. В качестве иллюстрации ниже привожу список важных релизов 2016 года.</p> <p>Как видите, новостей много, так что читайте, подписывайтесь, следите за объявлениями!</p> <p>Основные релизы 2016 года, начиная с самых последних:</p> <ul> <li><a href="https://blogs.aws.amazon.com/security/post/TxES3UX2Z5BQRU/Announcing-the-AWS-Config-Rules-Repository-A-New-Community-Based-Source-of-Custo" target="_blank">Announcing the AWS Config Rules Repository: A New Community-Based Source of Custom Rules for AWS Config</a></li> <li><a href="https://aws.amazon.com/about-aws/whats-new/2016/03/announcing-support-for-security-group-references-in-a-peered-vpc/" target="_blank">Announcing Support for Security Group References in a Peered VPC</a></li> <li><a href="http://aws.amazon.com/about-aws/whats-new/2016/03/run-xctest-ui-tests-with-aws-device-farm/" target="_blank">Run XCTest UI tests with AWS Device Farm</a></li> <li><a href="https://aws.amazon.com/about-aws/whats-new/2016/03/new-accounts-default-to-long-ec2-resource-ids-on-march-7/" target="_blank">New accounts default to long EC2 resource IDs on March 7</a></li> <li><a href="https://aws.amazon.com/blogs/aws/aws-importexport-snowball-update-export-now-available/" target="_blank">AWS Import/Export Snowball Update – Export Now Available</a></li> <li><a href="https://aws.amazon.com/about-aws/whats-new/2016/03/local-time-zone-support-for-amazon-aurora/" target="_blank">Local Time Zone Support for Amazon Aurora</a></li> <li><a href="https://aws.amazon.com/about-aws/whats-new/2016/02/aws-cloudformation-adds-support-for-amazon-vpc-nat-gateway-amazon-ec2-container-registry-and-more/" target="_blank">AWS CloudFormation Adds Support for Amazon VPC NAT Gateway, Amazon EC2 Container Registry, and More</a></li> <li><a href="http://aws.amazon.com/about-aws/whats-new/2016/01/scheduled-auto-scaling-now-available-in-the-aws-management-console/" target="_blank">Scheduled Auto Scaling Now Available in the AWS Management Console</a></li> <li><a href="https://aws.amazon.com/about-aws/whats-new/2016/02/rds-now-supports-sharing-encrypted-database-snapshots-with-other-aws-accounts/" target="_blank">RDS now supports sharing encrypted database snapshots with other AWS accounts</a></li> <li><a href="http://aws.amazon.com/about-aws/whats-new/2016/02/aws-cloudtrail-now-supports-amazon-cognito/" target="_blank">AWS CloudTrail now supports Amazon Cognito</a></li> <li><a href="https://aws.amazon.com/blogs/aws/amazon-emr-update-support-for-ebs-volumes-and-m4-c4-instance-types/" target="_blank">Amazon EMR Update – Support for EBS Volumes, and M4 &amp; C4 Instance Types</a></li> <li><a href="https://aws.amazon.com/blogs/aws/new-access-resources-in-a-vpc-from-your-lambda-functions/" target="_blank">New – Access Resources in a VPC from Your Lambda Functions</a></li> <li><a href="http://aws.amazon.com/about-aws/whats-new/2016/02/improved-amazon-redshift-data-schema-conversion-from-amazon-machine-learning-console/" target="_blank">Improved Amazon Redshift Data Schema Conversion from Amazon Machine Learning Console</a></li> <li><a href="https://aws.amazon.com/blogs/aws/amazon-workspaces-update-support-for-audio-in-high-dpi-devices-and-saved-registrations/" target="_blank">Amazon WorkSpaces Update – Support for Audio-In, High DPI Devices, and Saved Registrations</a></li> <li><a href="https://aws.amazon.com/about-aws/whats-new/2016/01/aws-codepipeline-adds-support-for-triggering-aws-lambda-functions/" target="_blank">AWS CodePipeline Adds Support for Triggering AWS Lambda Functions</a></li> <li><a href="http://aws.amazon.com/about-aws/whats-new/2016/01/scheduled-auto-scaling-now-available-in-the-aws-management-console/" target="_blank">Scheduled Auto Scaling Now Available in the AWS Management Console</a></li> <li><a href="http://aws.amazon.com/about-aws/whats-new/2016/01/aws-cloudformation-adds-override-for-failed-update-rollbacks/" target="_blank">AWS CloudFormation Adds Override for Failed Update Rollbacks</a></li> <li><a href="https://aws.amazon.com/about-aws/whats-new/2016/01/introducing-amazon-vpc-nat-gateway-in-eu-frankfurt-region/" target="_blank">Introducing Amazon VPC NAT Gateway in EU (Frankfurt) Region</a></li> <li><a href="https://aws.amazon.com/about-aws/whats-new/2016/01/aws-iot-now-supports-websockets-custom-keepalive-intervals-and-enhanced-console/" target="_blank">AWS IoT Now Supports WebSockets, Custom Keepalive Intervals, and Enhanced Console</a></li> <li><a href="https://aws.amazon.com/blogs/aws/aws-marketplace-adds-sharepoint-enterprise/" target="_blank">AWS Marketplace Adds SharePoint Enterprise</a></li> <li><a href="https://forums.aws.amazon.com/ann.jspa?annID=3514" target="_blank">Amazon Route 53 Domain Name Registration Service Announces Support For Over 100 Additional Top-Level Domains</a></li> <li><a href="https://aws.amazon.com/blogs/aws/new-cloudwatch-events-track-and-respond-to-changes-to-your-aws-resources/" target="_blank">New CloudWatch Events – Track and Respond to Changes to Your AWS Resources</a></li> <li><a href="https://aws.amazon.com/about-aws/whats-new/2016/01/elastic-load-balancing-support-for-aws-certificate-manager" target="_blank">Elastic Load Balancing: Support for AWS Certificate Manager</a></li> <li><a href="https://aws.amazon.com/blogs/aws/new-gxp-compliance-resource-for-aws/" target="_blank">New – GxP Compliance Resource for AWS</a></li> <li><a href="https://aws.amazon.com/blogs/aws/new-scheduled-reserved-instances/" target="_blank">New – Scheduled Reserved Instances</a></li> <li><a href="https://aws.amazon.com/about-aws/whats-new/2016/01/amazon-ec2-container-service-supports-docker-1-9/" target="_blank">Amazon EC2 Container Service Supports Docker 1.9</a></li> <li><a href="http://aws.amazon.com/about-aws/whats-new/2016/01/run-your-appium-tests-written-in-python-with-aws-device-farm/" target="_blank">Run your Appium tests written in Python with AWS Device Farm</a></li> <li><a href="https://aws.amazon.com/blogs/aws/in-the-works-aws-region-in-canada" target="_blank">In the Works – AWS Region in Canada</a></li> <li><a href="http://aws.amazon.com/about-aws/whats-new/2016/01/aws-elastic-beanstalk-adds-support-for-t2-nano-instances-and-amazon-ec2-container-registry/" target="_blank">AWS Elastic Beanstalk Adds Support for t2.nano Instances and Amazon EC2 Container Registry</a></li> <li><a href="https://aws.amazon.com/about-aws/whats-new/2016/01/longer-format-for-ec2-resource-ids/" target="_blank">Longer Format for EC2 Resource IDs</a></li> <li><a href="https://aws.amazon.com/blogs/aws/cloudfront-update-https-tls-v1-1v1-2-to-the-origin-addmodify-headers/" target="_blank">CloudFront Update – HTTPS &amp; TLS v1.1/v1.2 to the Origin, Add/Modify Headers</a></li> <li><a href="https://aws.amazon.com/about-aws/whats-new/2016/01/amazon-redshift-supports-automatic-queue-hopping-for-timed-out-queries/" target="_blank">Amazon Redshift supports automatic queue hopping for timed-out queries</a></li> <li><a href="https://aws.amazon.com/blogs/aws/amazon-workmail-now-generally-available/" target="_blank">Amazon WorkMail – Now Generally Available</a></li> <li><a href="https://aws.amazon.com/blogs/aws/aws-cost-explorer-update-access-to-ec2-usage-data/" target="_blank">AWS Cost Explorer Update – Access to EC2 Usage Data</a></li> <li><a href="https://aws.amazon.com/blogs/aws/now-open-aws-asia-pacific-seoul-region/" target="_blank">Now Open – AWS Asia Pacific (Seoul) Region</a></li> <li><a href="https://aws.amazon.com/blogs/aws/happy-new-year-ec2-price-reduction-c4-m4-and-r3-instances/" target="_blank">Happy New Year – EC2 Price Reduction (C4, M4, and R3 Instances)</a></li> </ul>