• базовую информацию о клиентах — ФИО, контакты, документы,
• информацию о продуктах и тарифах,
• историю заявок клиентов.

Что нужно сделать

1. Определите стратегию масштабирования и отказоустойчивости. Рассмотрите вертикальное и горизонтальное масштабирование для вашей системы. Оцените, какая стратегия будет эффективнее. Требуется ли использование дополнительных зон безопасности?
2. Если приняли решение деплоить приложение в нескольких зонах безопасности, то продумайте и отразите на схеме следующие вопросы:
   a. Проработайте конфигурацию развёртывания приложения в Kubernetes. Вы будете использовать независимые кластеры в каждой площадке или один растянутый? Оставьте на схеме комментарий с объяснением, почему вы выбрали тот или другой подход. b. Спланируйте балансировку нагрузки. Опишите подход к балансировке нагрузки, который обеспечит распределение трафика между вашими сервисами и географически распредёленными серверами. Явно отразите на схеме все health check. c. Определите наиболее подходящую фейловер-стратегию. Она должна отвечать заданным требованиям отказоустойчивости. Отразите её на схеме на уровне взаимодействия клиента с приложением. d. Определите конфигурацию базы данных. Учитывая требования RTO и RPO, спроектируйте конфигурацию базы данных: определите, как вы будете обеспечивать репликацию данных и их резервное копирование. Если будете использовать конкретный фреймворк конфигурации кластера БД, отразите его на схеме.
3. Определите, будете ли вы применять шардирование БД. Отразите своё решение на схеме.

• GET / — получение идентификатора пода;
• GET /metrics — получение метрик в формате Prometheus.

Обязательная часть задания: динамическая маршрутизация на основании показателей утилизации памяти

Что нужно сделать

1. Поднимите локальный кластер Kubernetes в Minikube.
2. Активируйте metrics-server.
3. Напишите манифест развёртывания (Deployment) Kubernetes для запуска тестового приложения. Для начального количества реплик установите значение, равное единице. Лимит памяти установите равный “30Mi”. Примените написанную конфигурацию в вашем кластере. В рамках пул-реквеста добавьте файл в директорию Exc2.
4. Напишите и примените манифест сервиса (Service) для доступа к приложению, которое вы установили на прошлом шаге. В рамках пул-реквеста файл с этим манифестом тоже загрузите в директорию Exc2.
5. Настройте динамическую маршрутизацию на основании показателей утилизации оперативной памяти с помощью Horizontal Pod Autoscaler (HPA). Для нашего тестового приложения оптимальный уровень утилизации памяти равен 80%. В качестве максимального количества реплик рекомендуем установить 10. Примените манифест в вашем кластере. В рамках пул-реквеста загрузите готовый манифест в директорию Exc2.
   a. Создайте Locustfile. Это сценарий на Python, где вы определяете поведение пользователей. Создайте файл с именем locustfile.py в удобной для вас директории. Скопируйте туда код:
   Скопировать код

   BASH

        from locust import HttpUser, between, task
    
        class WebsiteUser(HttpUser):
            wait_time = between(1, 5)
      
            @task
            def index(self):
                self.client.get("/") 
   Этот пример создаёт класс пользователя, который переходит на главную страницу ("/") с интервалом между запросами от 1 до 5 секунд.
   b. Откройте терминал и перейдите в директорию, где находится ваш locustfile.py. Выполните команду:
   Скопировать код

   BASH

   locust 
   c. После запуска Locust откройте веб-браузер и введите адрес http://localhost:8089. Вы увидите веб-интерфейс Locust, где можно настроить параметры теста: количество пользователей и hatch rate — скорость, с которой генерируются новые пользователи.
   d. Запустите тест и проанализируйте результаты. Проще всего посмотреть результаты в дашборде Kubernetes. В локальном кластере Minikube его можно открыть с помощью команды:
   Скопировать код

   BASH

   minikube dashboard 
   Сделайте скриншоты дашборда или выгрузите логи, которые покажут, что количество реплик базы данных поменялось в ответ на сгенерированную нагрузку. Загрузите их в директорию Exc2.

Дополнительная часть задания: динамическая маршрутизация на основании показателей количества запросов в секунду

Что нужно сделать

1. Установите Prometheus в вашем кластере.
2. Настройте экспорт метрик из приложения в Prometheus.
3. Проверьте, что метрики из вашего приложения поступают в Prometheus с помощью Prometheus Web UI: откройте раздел Graph или Targets и убедитесь, что метрики отображаются. Сделайте скриншоты интерфейса с метриками и загрузите их в директорию Exc2 в рамках пул-реквеста.
4. Настройте автоматическое масштабирование по RPS через HPA. Для этого создайте новую версию манифеста. Когда будете сдавать задание, загрузите его в директорию Exc2 в рамках пул-реквеста.
5. Теперь надо убедиться, что всё работает как задумано. Для этого сгенерируйте нагрузку на приложение. Действуйте по аналогии с шестым шагом в обязательной части задания. Сделайте скриншоты дашборда или выгрузите логи, которые покажут, что количество реплик базы данных поменялось в ответ на сгенерированную нагрузку. Загрузите их в директорию Exc2 в рамках пул-реквеста.

• запрашивает информацию из всех страховых компаний (сейчас их пять),
• агрегирует её в единый список,
• возвращает этот список в рамках того же синхронного запроса.

Что нужно сделать

1. Проанализируйте текущую архитектуру. Создайте текстовый документ и напишите там список проблем и рисков, которые связаны с планируемым ростом нагрузки. Когда всё будет готово, загрузите документ в директорию Exc3 в рамках пул-реквеста.
2. Обновите диаграмму контейнеров InsureTech, предложив решения для выявленных вами рисков и проблем. При этом:
   • Не меняя декомпозицию функциональности между сервисами, подумайте, какие взаимодействия стоит переделать на Event-Streaming.
   • Решите, будете ли вы использовать паттерн Transactional Outbox.
   Когда схема будет готова, загрузите её в директорию Exc3 в рамках пул-реквеста..

• создать заявку на ОСАГО,
• получить предложение по заявке.

1. Сохранить подход, который использовался для получения данных о продуктах и тарифах из страховых компаний.
2. Выделить отдельный сервис для взаимодействия со страховыми компаниями — osago-aggregator.

1. Проработайте реализацию osago-aggregator. Решите:
2. Требуется ли ему своё хранилище данных?
3. Какой API он предоставляет core-app?
4. Определите средство интеграции между сервисами core-app и osago-aggregator.
5. Подумайте над API для веб-приложения в core-app.
6. Определите средство интеграции между веб-приложением и core-app. Если будете использовать средство, отличное от REST, отразите интеграцию новой стрелкой.
7. В зависимости от выбранных средств интеграции подумайте, требуется ли где-то применение паттернов отказоустойчивости:

   • Rate Limiting,
   • Circuit Breaker,
   • Retry,
   • Timeout.
   Отобразите применение паттернов на схеме с помощью обозначений из этой библиотеки.
8. Примите во внимание, что сервисы задеплоены в нескольких экземплярах. Подумайте, зависит ли ваше решение от этого.

Что нужно сделать

1. Проанализируйте Swagger контракт client-inf. Оцените существующую структуру API, выделите ключевые ресурсы и операции.

   Контракт Swagger

   Скопировать код

   YAML

   swagger: '2.0'
   info:
    description: API сервиса управления клиентскими данными
    version: 1.0.0
    title: Клиентский Сервис
   host: api.client-service.com
   basePath: /v1
   schemes:
    - https
   paths:
    /clients/{id}:
      get:
        tags:
          - Клиент
        summary: Получить информацию о клиенте по ID
        description: Возвращает информацию о клиенте.
        produces:
          - application/json
        parameters:
          - name: id
            in: path
            description: ID клиента
            required: true
            type: string
        responses:
          '200':
            description: Успешный ответ
            schema:
              $ref: '#/definitions/Client'
    /clients/{id}/documents:
      get:
        tags:
          - Документы
        summary: Список документов клиента
        description: Возвращает список документов клиента по ID.
        produces:
          - application/json
        parameters:
          - name: id
            in: path
            description: ID клиента для поиска его документов
            required: true
            type: string
        responses:
          '200':
            description: Успешный ответ
            schema:
              type: array
              items:
                $ref: '#/definitions/Document'
    /clients/{id}/relatives:
      get:
        tags:
          - Родственники
        summary: Информация о родственниках клиента
        description: Возвращает информацию о родственниках клиента по ID.
        produces:
          - application/json
        parameters:
          - name: id
            in: path
            description: ID клиента
            required: true
            type: string
        responses:
          '200':
            description: Успешный ответ
            schema:
              type: array
              items:
                $ref: '#/definitions/Relative'
   definitions:
    Client:
      type: object
      properties:
        id:
          type: string
        name:
          type: string
        age:
          type: integer
    Document:
      type: object
      properties:
        id:
          type: string
        type:
          type: string
        number:
          type: string
        issueDate:
          type: string
        expiryDate:
          type: string
    Relative:
      type: object
      properties:
        id:
          type: string
        relationType:
          type: string
        name:
          type: string
        age:
          type: integer
     
2. На основе анализа REST API разработайте эквивалентную схему GraphQL, которая позволит избежать дублирования за счёт гибкости в выборе запрашиваемых данных.
3. Определите сущности, их поля, а также необходимые запросы (queries), которые покроют все операции REST API.

Что нужно сделать

1. Перед вами конфигурационный файл Nginx. Доработайте его таким образом, чтобы обеспечить ограничение количества отправляемых запросов. Должно быть не более 10 запросов в минуту.
   Скопировать код

   JSX

   http {
      # Настройка upstream для балансировки нагрузки
      upstream backend_servers {
          server backend1.example.com;
          server backend2.example.com;
          server backend3.example.com;
      }
   
      server {
          listen 80;
   
          location / {
              proxy_pass http://backend_servers;
          }
   
      }
   }
     
2. Сделайте так, чтобы при превышении лимита запросов клиент получал HTTP-ошибку с кодом 429.