Абстрактный

Заключение часть 01:

Вы можете видеть, что мы хотим использовать хорошую методологию для выбора лучшего облачного сервиса для нашего проекта, потому что он будет меняться от проекта к проекту. Если вы выберете неправильный, низкокачественный, дорогой сервис, это может напрямую повлиять на ваш бизнес. Итак, перейдем к тому, какие методологии использовались ранее для выбора услуг.

Предыдущие методологии

Методы MCDA можно разделить на два типа:

1. Новая брокерская архитектура

2. Многокритериальный анализ решений

• MCDM представляет собой набор методологий для сравнения, ранжирования и выбора нескольких альтернатив, каждая из которых имеет несколько атрибутов. Это зависит от матрицы, называемой оценочной матрицей, матрицей решений, матрицей выплат или оценочной таблицей.

MCDA создан по образцу того, как люди принимают решения. MCDA помогает в принятии решений, главным образом, путем выбора, ранжирования или сортировки действий.
• MCDA — это не только набор теорий, методологий и методов, но и конкретный взгляд на решение проблем, связанных с принятием решений.[3]
• Он демонстрирует интеграцию методов MCDA и облачных вычислений на основе об их использовании и популярности. Поэтому они рассмотрели текущую литературу и определили различные типы проблем.
Цель:

• MCSP выбирает наилучшую альтернативу из конечного набора альтернатив, все из которых известны априори.
• MCMP выбирает наилучшую альтернативу из очень большого или бесконечного набора альтернатив, не все из которых известны априори.
• MAUT находит функцию полезности, отражающую полезность конкретной альтернативы.
• Теория полезности с несколькими атрибутами (MAUT) — найти функцию, отражающую полезность или полезность конкретной альтернативы.
  o Методы опережения — лучше в сценариях с небольшим количеством альтернатив (надеюсь сравнить типы), но большим количеством критериев.
• AHP (аналитический иерархический процесс) основан на попарном сравнении. популярный и широко используемый метод MCDA. После проведения сравнений обычно выбирают наилучшую альтернативу по каждому признаку.

Выбор поставщика облачных услуг

• Они представляют несколько приложений этих методов MCDA при выборе облачных сервисов. Они сравнивают несколько методов, синтезируя и анализируя существующую литературу. Приведено несколько реальных примеров с текущими приложениями различных методов.
• Облачные вычисления (CC) в последнее время привлекают огромное внимание исследователей в области ИТ и образования. CC использует свои отличительные услуги для облачных клиентов с оплатой по мере использования, в любое время и в любом месте. А также облачные сервисы предлагают динамически масштабируемые услуги по запросу. Поэтому предоставление услуг играет ключевую роль в CC. Тогда это хорошая возможность для клиентов найти подходящую и недорогую услугу для своего проекта. В частности, Заказчик должен иметь возможность выбрать подходящий облачный сервис в соответствии со своими потребностями и деньгами. Собрать необходимую информацию и проанализировать информацию обо всех поставщиках облачных услуг, чтобы принять правильное решение, отнимает много времени у потребителей. Кроме того, это также очень сложная задача с вычислительной точки зрения, поскольку несколько потребителей, имеющих схожие требования, многократно выполняют одни и те же вычисления. Для решения проблемы выбора облачных сервисов многие исследователи предложили несколько подходов, включая многокритериальный анализ решений (MCDA) и брокерский подход. Но мы не видим никакой системы прогнозирования машинного обучения для решения этой проблемы. Эта система позволяет пользователю выбирать из множества доступных вариантов. В этой статье мы создаем нейронную сеть с TensorFlow для выбора сервиса в CC. Эта система ориентирована на трех основных игроков в CC. В гонке за поставщиков облачных услуг участвуют Amazon Web Services, Microsoft Azure и Google Cloud Platform. Я выявляю и синтезирую несколько продуктов, актуальных для веб-сервисов у облачных провайдеров. Есть Featured, Compute, Storage, Database, Networking, Operation, Identity & Access и Cost. А также я ориентируюсь на малый и средний бизнес (SMB). Потому что это самый агрессивный сегмент в облачных сервисах. Это менее сложные ИТ-потребности, меньше устаревших приложений и меньше ИТ-поддержки, чем у крупных предприятий. Согласно исследованию McKinsey [1], он подтверждает использование подписки или технологических услуг по запросу как SMB (несколько 250 сотрудников) > (крупные компании) * 2. А также он классифицировал размеры компаний как очень маленькие (5–19 сотрудников). ), малые (20–99) и средние (100–250).
  Они предоставляют все продукты, которые могут вам понадобиться для переноса вашего бизнеса в облако. Но эти предложения продуктов различаются по цене, а также по названию их услуг. Некоторые Бизнесмены уже могут использовать локальную инфраструктуру или думать, какую инфраструктуру использовать для моего проекта. У них могут быть более сложные проблемы, например, как выбрать облачный сервис, какие сервисы они хотят использовать и особенно сколько затрат они хотят платить ежемесячно или ежегодно. Иногда кто-то уже использует облачные сервисы, у них есть много проблем, таких как более высокая стоимость, меньшая гибкость, сложность в использовании, огромное количество вариантов услуг, плохое управление графическим интерфейсом и инструментами, сложная схема ценообразования и другие проблемы. Однако они должны тратить больше цены и времени как бесполезные. Потому что они не могли заранее выбрать лучшего поставщика облачных услуг для своего бизнеса. Кроме того, если эти компании будут перемещать данные из одного облака в другое, это требует много времени и денег. Небольшие компании или частные лица не имеют архитектора программного обеспечения или опытных инженеров-программистов. Таким образом, некоторые предприятия могут разориться, получить низкую прибыль и потратить больше затрат, не используя при этом все предоставляемые преимущества.
  Поэтому будет разработано системное решение для прогнозирования использования облачных сервисов для вашего проекта на основе искусственного интеллекта. Предсказать, какой поставщик услуг является хорошим, и прогнозировать стоимость. Кроме того, особое внимание уделяется минимизации ваших затрат в соответствии с вашим веб-проектом (Java, Python, C++, Angular и React), который будет предоставлен через систему, и мы выделяем несколько услуг (регион, вычисления, хранилище, база данных, сеть, эксплуатация, идентификация и Модель доступа и ценообразования). Вы хотите использовать для минимизации затрат. Основным конечным пользователем системы являются данные этих поставщиков облачных услуг. Кроме того, вы можете узнать, какие расходы могут быть потрачены еженедельно, ежемесячно или ежегодно в зависимости от веб-трафика для ваших проектов. Другими косвенными конечными пользователями являются архитекторы программного обеспечения, сотрудники веб-разработки и опытные веб-фрилансеры. Мы доказываем эффективность и действенность нашего подхода на реальных и синтетических облачных данных.
• Они разрабатывают уникальный метод индексации для управления информацией большого количества поставщиков облачных услуг. Они разрабатывают эффективный алгоритм выбора услуг, который ранжирует потенциальных поставщиков услуг и при необходимости объединяет их. Они доказали это с помощью экспериментального исследования с реальными и синтезированными облачными данными.
  • Облачный брокер — это посредник между пользователями и поставщиками услуг. Это помогает пользователям выбирать услуги, адаптированные к их потребностям.
  • Облачный брокер, который имеет договор с поставщиками облачных услуг, собирает их свойства (например, тип услуги, стоимость единицы и доступные ресурсы) и информацию о потребителе. требования к обслуживанию.
  • Эта архитектура включает в себя два ключевых технических аспекта.
  o Построение индекса для управления поставщиками услуг.
  o Алгоритм запроса для выбора услуги.
  • A. Индексирование поставщиков облачных услуг
  o CSP-индекс разработан с использованием B+-дерева (важно разработать эффективную структуру индекса для облегчения управления информацией и поиска.)
  o B+-дерево широко используется в коммерческих системы баз данных и обеспечивает отличную основу для нашей новой структуры индекса, которая легко интегрируется в существующие системы.
  o Внутренние узлы индекса CSP имеют формат, аналогичный B+-дереву, и служат в качестве каталога поиска.< br /> o Они используют следующие меры в качестве структуры данных.
   Тип службы, Безопасность, Качество обслуживания, Единицы измерения, Единицы ценообразования, Размеры экземпляров, Операционная система, Ценообразование, Чувствительность к ценообразованию, Субподрядчики.
  o Структура индекса:
  типы свойств. Например: [(10G, ∞), (1G, 10G), (500M, 1G), (0,500M)]. Если емкость хранилища службы составляет от 800 МБ до 2 ГБ =› кодирование ‘0110’.
   Кодирование отношений — оно представляет отношения с использованием массива двоичных битов с тремя битами. Например: присутствует 1 бит для субподрядчиков, 2 бита для субподрядчика, предоставляющего услуги вычислений или хранения, 3 бита для субподрядчика, обеспечивающего безопасность, конфиденциальность или услуги, связанные с поиском. биты, представляющие тип службы с результатами операции XOR оставшихся кодировок свойств.
  • Например: мы предполагаем, что поставщик услуг SP1 предоставляет ниже,
  1. тип услуги «0001», от 800 МБ до 2 ГБ дискового пространства для каждого конечного пользователя по 10 центов / мин со средним качеством обслуживания и средней защитой конфиденциальности. .
  2. «0110» (хранилище), «010» (стоимость), «010» (качество обслуживания), «010» (конфиденциальность)
  3. Интегрированное кодирование (Esp1) = 0001|| (0110 ⊕ 010 ⊕ 010 ⊕ 010) = 00010100
   Алгоритм k-средних — k — количество типов услуг. Расстояние Хэмминга (обозначаемое как Dh) находится между кодировкой каждого поставщика услуг и его ближайшим центром кластера. S означает, что значение масштабирования используется для разделения размерного пространства на регионы, где каждый регион содержит группу точек. Это зависит от количества регионов, которые мы хотим создать. Espi — это кодировка свойства поставщика услуг i. Eck — это кодировка центра кластера ck, ближайшего к поставщику услуг i.
  • Keyspi — S · k + Dh (Espi, Eck)
   Определение запроса —
  • Пользователь отправляет брокеру запрос на выбор услуги, в котором указывается, какие свойства и значения он/она ожидает от поставщиков услуг.
  • Q = (QP1 : D1), (QP2 : D2),…, (QPk : Dk)< br /> • QPi (1 ≤ i ≤ k) =› свойство, которое пользователь запрашивает у поставщика услуг
  • Di — ожидаемые пользователем значения свойства (запрошенное значение)
  • Результат запрос будет поставщиком услуг, который удовлетворяет большинству требований к свойствам.
  • Например: Q = (Тип услуги: 0001), (Стоимость: [50 центов/мин, 80 центов/мин]))
   Генерация Тестирование наборов данных. Они определили и извлекли набор общих свойств на основе общих бизнес-рекомендаций по выбору услуг.
  Например: Тип службы:
  • 1- служба по запросу
  • 2 — зарезервированные экземпляры
  • 3 — специализированные службы, такие как настраиваемые IP-адреса
  • Это дало нам наш начальный набор из десяти точек данных и сформировали представление поставщиков услуг.
  • С помощью начальных точек данных мы создали 10 000 точек данных, представляющих синтетических поставщиков.
  • Они используют генератор псевдослучайных чисел для создания подмножество из 1010 возможных комбинаций и отфильтровать выбросы.