S3 history

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

Нужно - понимать. А чтобы как раз понимать - нужно знать как оно было и почему стало как сейчас.

Итак, отметим лишь точку отсчёта:

https://aws.amazon.com/blogs/aws/amazon_s3/

В общем - #S3 вместе с #SQS и #EC2 ведут свой отсчёт с 2006-го года.

Это время расцвета VPS-хостингов со всей болью, помноженной на стоимость и ненадёжность при существенных нагрузках. Айфон лишь рождался, а крупным потребителям вычислительных мощностей всё приходилось делать самим. Потому с появлением первого крупного игрока, обещавшего SLA 99,99%, огромное количество будущих крупных клиентов Амазона бросились изучать возможности и стабильность его сервисов, в первую очередь S3.

Цена в 15 центов за гигабайт на то время была вполне себе конкурентной, потому основными в тестах была надёжность и стабильность доступа на протяжении длительного времени. Одними из первых крупных интересантов выступили штатовские универы, которые хотели избавиться от расходов на железо и перекинуть всё своё хозяйство в Амазон.

Через годик, убедившись в достаточной надёжности, они стали активно переходить туда.

За сим завершу литературно- и околомаркетинговое словоблудие о причинах и результатах создания S3. В следующей части перейду к суровым будням протодевопсов (их тогда ещё предательски называли сисадминами).

#s3_history #history

AWS SQS vs SNS vs Eventbridge:

https://beabetterdev.com/2021/09/10/aws-sqs-vs-sns-vs-eventbridge/

Use SQS when:
▪️ You’re looking for reliable 1:1 Asynchronous communication to decouple your applications from one another
▪️ You want to rate limit your consumption of messages (perhaps due to a database bottleneck or some other use case)
▪️ You want ordered message processing of vents
Use SNS when:
▪️ You want to publish messages to MANY different subscribers with a single action
▪️ Require high throughput and reliability for publishing and delivery to consumers
▪️ Have many subscribers
Use Eventbridge when:
▪️ You want to publish messages to many subscribers, and use the event data itself to match targets interested certain patterns.
▪️ Want integration with other SaaS providers such as Shopify, Datadog, Pagerduty, or others
▪️ Want to easily discover schemas that other teams produce and incorporate them into your application.
▪️ You want to use regularly scheduled events using a cron-like expression to periodically send messages to your event bus.

#SQS #SNS #Eventbridge

​​Набор различных скриптов по AWS на Python:

https://github.com/hseera/aws-python-utilities/

Под номером 13 интересная утилитка, SQS Workbench — GUI под Windows для работы с SQS:

https://github.com/hseera/aws-python-utilities/#13-sqs-workbench

#SQS

#aws #eks #sqs #CostOptimization
Материал уровня middle.

Снова про экономию.

У нас есть AWS SQS.
В него прилетает миллион вебхуков с полезным и важным payload.
Бывают пики, бывают нет.
У нас есть AWS EKS и приложение в POD-e, который вычитывает SQS, процессит и всё ок.
Нам надо настроить масштабирование не за счёт CPU/memory usage, а за счёт количества сообщений.
В этом нам помогает KEDA. Опустим этапы установки/настройки/прав и авторизации.
У нас есть готовый манифест scaledobject.

---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
...
spec:
  cooldownPeriod: 300
  maxReplicaCount: 50
  minReplicaCount: 2
  pollingInterval: 30
  scaleTargetRef:
    name: application
  triggers:
  - authenticationRef:
      name: keda-aws-credentials
    metadata:
      awsRegion: us-east-1
      identityOwner: operator
      queueLength: "500"
      queueURL: https://sqs.us-east-1.amazonaws.com/123456789/sqsname
    type: aws-sqs-queue

Всё работает, всё скейлится, всё ок.
В HPA некрасиво выглядят цифры, хочется видеть точное количество мессаджем. Добавляем metricType

---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
...
spec:
...
    metricType: Value

И теперь в kubectl get hpa blablabla видим точное количество мессаджей в TARGETS(а не системы счисления инопланетян).
Этого нам мало, нужна точная подстройка.
Читаем дальше доку, у нас есть адвансед настройки.

---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
...
spec:
  advanced:
    horizontalPodAutoscalerConfig:
      behavior:
        scaleDown:
          policies:
          - periodSeconds: 15
            type: Pods
            value: 1
          stabilizationWindowSeconds: 300
        scaleUp:
          policies:
          - periodSeconds: 15
            type: Pods
            value: 1
          selectPolicy: Max
          stabilizationWindowSeconds: 60
... (остальное так же)

Теперь у нас всё динамически скейлится, прописаны все триггеры, трешхолды.
Всё отлично и бизнес ликует(не вру, прям ликует, сильно помогло).

Однако меня, как рьяного и верного пса девопс церкви, напрягает, что в период высокой нагрузки всё упирается в максимум реплик. Да, можно поставить не 50, а 100, но я думаю, что настройка неверная.
Углубляемся дальше в доку(вру, я ничо не понял и просто спросил ребят-гуру-AWS-технологий в телеге) и вспоминаем про визибл/анвизибл настройки у sqs.
https://keda.sh/docs/2.14/scalers/aws-sqs/
https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html

Окончательно пилим манифест.

---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
...
spec:
  advanced:
...(тут тоже самое)
    metadata:
...
      scaleOnInFlight: "false"   << - - вот это вот важное нам
...

Отлично. Теперь самая точная и потрясающая настройка.