Ускоряйся! Наука DevOps: Как создавать и масштабировать высокопроизводительные цифровые организации

Авторы: Николь Форсгрен, Джез Хамбл, Джин Ким

Год издания: 2020

Скачать книгу

#devops #русский

Node.js 14.x runtime now available in AWS Lambda | AWS Compute Blog
https://aws.amazon.com/blogs/compute/node-js-14-x-runtime-now-available-in-aws-lambda/

Разбор падения Slack от 4 января:

https://slack.engineering/slacks-outage-on-january-4th-2021/

Весьма полезное чтиво – хронология, детали, выводы. Кроме ставшего классическим /proc/sys/fs/file-max, есть и специфичные амазоновские причины.

Масштабирование AWS Transit GateWay (TGW)

TGW менеджится Амазоном, потому повлиять на него мы не можем. В то время, как часть проблем у Slack возникла из-за того, что резко возросший трафик через их корневой TGW, через который завязаны их окружения, давал ошибки, не успевая масштабироваться, добавляя проблем во время падения Slack. Амазоновцы вручную боролись с этой ситуацией:

However, our TGWs did not scale fast enough. During the incident, AWS engineers were alerted to our packet drops by their own internal monitoring, and increased our TGW capacity manually.

Чтобы такого избежать, нужно "прогревать" TGW, аналогично тому, как такое предусмотрено для ELB:

https://aws.amazon.com/articles/best-practices-in-evaluating-elastic-load-balancing/#pre-warming

Shared VPC vs different VPCs

Другой момент – отрицательные стороны от использования отдельных VPC. Если бы у Slack использовалась Shared VPC – и для окружения, и для мониторинга, то трафик бы не упёрся бы в узкое горлышко TGW (его скорости масштабирования), через который и соединяются отдельные VPC.

#TGW #Shared_VPC #design

Во время просмотра видео с gitlab Hackathon'а, заметил интересный момент для просмотра изменений в созданном MR'е, ревьюер использовал команду git mr origin 1234 чтобы локально переключиться на ветку из MR'а, начал копаться в доках git'а, такую не обнаружил. Лишь поискав в интернете, нашел такой алиас, мне кажется весьма интересный. https://docs.gitlab.com/ee/user/project/merge_requests/reviewing_and_managing_merge_requests.html#checkout-merge-requests-locally-through-the-head-ref

https://twitter.com/chriskalmar/status/1363759778858729482

https://github1s.com/ классная штука для гитхаба сделана

Kubernetes README: What books 📚 to read to learn more about Kubernetes
https://kubernetesreadme.com/

https://twitter.com/jetbrains/status/1361672180694716417
возможность писать код в онлайне в команде расширили в JetBrains, отличная фича, надо потестировать :)

Две подборки полезных книг и источников от Chris Short о devops и kubernetes:

- DevOps README (Github).
- Kubernetes README (Github).

#напочитать #devops #kubernetes

Описание различных deployment стратегий
https://github.com/ContainerSolutions/k8s-deployment-strategies

20–22 апреля присоединяйтесь к DevOpsDays Kyiv 2021 – бесплатной онлайн конференции о культуре и процессах, на которых строится работа инженеров. Вас ждут три вечера со спикерами из Google, VMWare, PagerDuty, Dojo and Co, Datadog, fireside чат с одним из создателей Kubernetes — Joe Beda, и не только.

💻 В программе:
— 5 докладов о культуре DevOps;
— fireside чат c одним из создателей Kubernetes — Joe Beda, вопросы Joe можно задать тут;
— 10+ докладов от украинского DevOps community;
— open space discussions;
— 1000+ участников.

✔️ Когда? 20–22 апреля
✔️ Где? Онлайн
✔️ Участие бесплатное
✔️ Язык - английский

Регистрация 👉 https://bit.ly/DevOps-Days-Kyiv

Весёлый ролик от Corey Quinn не всем понятен, а весьма полезен. Потому далее расшифровка каждого пункта (моя версия).

💸 Managed NAT Gateway — популярная проблема, когда кажущиеся пустыми окружения жрут деньги из-за цены за NAT GW для private subnets.

💸 Amazon EBS — забытые неиспользуемые (не примонтированные) диски в разных аккаунтах жрут деньги, а в случае, если они Provisioned IOPS, то огромные деньги.

💸 Insecure S3 buckets - 450 independent "Security" researchers — в данном случае здесь, видимо, какая-то пародия на аудит безопасности, хотя при большом количестве данных расходы на S3 могут быть огромными. В помощь S3 Intelligent-Tiering и Amazon S3 Storage Lens.

💸 The Data Science team — так понимаю, команда резвящихся датасайенсистов стоит дорого.

💸 Cross AZ Data Transfer — малоприметная проблема пожирает незаметно деньги (и может большие), прикрытая общей уверенностью, что трафик внутри одного региона бесплатен.

💸 Your AWS Account Team — видимо шарж на команду AWS, которая лениво смотрит, как вы спонсируете их коктейли.

💸 RIs in the wrong region — про то, что Reserved Instances берутся на конкретный регион, иначе они просто проедают деньги. В помощь Savings Plans!

💸 CloudWatch Metrics и DataDog polling — одни из самых дорогих источников расходов на мониторинг, соревнующиеся в первенстве, кто дороже. Настраивайте нужные метрики с нужным интервалом. Как вариант – используйте Amazon Managed Prometheus.

💸 OverProvisioned IOPS — EBS диски с IOPS-ами дорогое удовольствие, потому не стоит привычно "брать с запасом", а руководствоваться адекватными метриками.

💸 Infrastructure in us-west-1 — регион N.California географически совсем рядом с Oregon (us-west-2), однако ресурсы в N.California на 20+ процентов дороже.

💸 Deployed Amazon Macie — первая версия Macie была (есть) негуманно дорогая. Используйте вторую.

💸 Amazon Redshift — серьёзные вещи стоят серьёзные деньги и требуют серьёзного отношения.

💸 AWS Marketplace Vendors — поставленные из Marketplace продукты могут стоить (больших) денег – нужно не забывать отписываться от ставшего ненужным.

💸 Extra Snowball days — за каждый день свыше 10 включённых изначально, списываются деньги за пользование Snowball и это могут быть большие деньги (от десятков до сотен долларов в день).

💸 Business support on Developer accounts — план техподдержки Business стоит 100 долларов в месяц и привязан к конкретному аккаунту. Если это аккаунт для разработки, то по сравнению с Developer планом за 29$ в месяц в нём нет ничего, кроме дополнительных коктейлей для AWS Account Team выше.

💸 No expiry configured - CloudWatch logs everywhere — логи, которые никогда не удаляются, вечные ненужные бэкапы, ECR образы и куча всего другого ­­- всё это пожирает деньги. Даже если не самые большие, но умноженное на всегда получается бесконечно много. Настраивайте lifecycle policy для всего.

💸 Frequent Glacier Retrievals — получение данных из Glacier – дорогая операция, не нужно увлекаться, а лучше использовать S3 Intelligent Tier Archive, который теперь умеет сам складывать в Glacier и забирать оттуда бесплатно.

💸 EMR without Spot fleets — использование Spot fleets для EMR существенно экономит, стоит их использовать.

💸 Creds leaked on Github — не нужно публиковать свои ключи доступа на GitHub, это может стоить дорого.

💸 AWS Contracts Team — вот это я не расшифровал, буду признателен объяснению в комментариях. 


p.s. Хороший пост про 10 простых и очевидных способов уменьшить стоимость вашей AWS инфраструктуры есть и на русском:

https://aws.amazon.com/ru/blogs/rus/10-things-you-can-do-today-to-reduce-aws-costs/

#cost_optimization