feat: added CASE_3

2026-06-19 18:54:56 +03:00
1 parent 9f5e8ad4f8
commit 2c2f8d0d59
@@ -140,4 +140,6 @@ VKC_LR_04_cicd_gitops_k8s_РемизовКЛ_20260619.png,EVIDENCE,LR_04,main,К
 VKC_LR_04_cicd_gitops_s3_РемизовКЛ_20260619.png,EVIDENCE,LR_04,main,Бакет S3 с state-файлом,02_evidence/VKC_LR_04_cicd_gitops_s3_РемизовКЛ_20260619.png,VKC_LR_04_cicd_gitops_REPORT_РемизовКЛ_20260619.md,final,
 VKC_LR_04_cicd_gitops_app-config_РемизовКЛ_20260619.png,EVIDENCE,LR_04,main,ConfigMap приложения,02_evidence/VKC_LR_04_cicd_gitops_app-config_РемизовКЛ_20260619.png,VKC_LR_04_cicd_gitops_REPORT_РемизовКЛ_20260619.md,final,
 VKC_LR_04_cicd_gitops_log_РемизовКЛ_20260619.log,EVIDENCE,LR_04,main,Лог выполнения команд (установка ArgoCD),02_evidence/VKC_LR_04_cicd_gitops_log_РемизовКЛ_20260619.log,VKC_LR_04_cicd_gitops_REPORT_РемизовКЛ_20260619.md,final,
+VKC_CASE_03_migration_РемизовКЛ_20260619.md,CASE,M08,CASE_03,Анализ и выбор стратегии миграции LAMP-приложения,01_reports/VKC_CASE_03_migration_РемизовКЛ_20260619.md,,final,
+VKC_CASE_03_migration_IvanovII_20260619.drawio.png,DIAGRAM,M08,CASE_03,Схема целевой архитектуры интернет-магазина в VK Cloud,04_diagrams/VKC_CASE_03_migration_IvanovII_20260619.drawio.png,,final,
 00_manifest.csv,MANIFEST,all,all,Финальный манифест сдачи,00_manifest.csv,,final,
@@ -0,0 +1,132 @@
+---
+course_code: VKCLOUD-80
+artifact_type: CASE
+case_code: VKC_CASE_03_migration
+case_title: Анализ и выбор стратегии миграции LAMP-приложения в VK Cloud
+student_fio: Иванов И.И.
+date: 2026-06-19
+source_docs: [Д2_Тематический_план, Д3_Конспект_лекций, Д7_Шпаргалка]
+attached_files: [VKC_CASE_03_migration_IvanovII_20260619.drawio.png, VKC_ARCH_M08_highload_store.drawio]
+status: final
+---
+
+# Разбор практического кейса: Миграция интернет-магазина в VK Cloud
+
+## 1. Суть кейса и целевая архитектура
+
+Необходимо выполнить миграцию существующего интернет-магазина, работающего на классическом LAMP-стеке (Linux, Apache, MySQL, PHP), с текущей on-premise инфраструктуры (одна физическая/виртуальная машина) в облачную платформу VK Cloud.
+
+**Текущее состояние приложения:**
+- **Архитектура:** Монолитное приложение, развернутое на одной ВМ.
+- **Стек:** Ubuntu 22.04, Apache 2.4, PHP 7.4 (с расширениями gd, mbstring, xml, curl, mysqli), MySQL 8.0.
+- **Данные:** Файлы приложения (`/var/www/html`) и база данных (`/var/lib/mysql`) находятся на одном сервере.
+- **Бизнес-требования:** Допустим простой до 2 часов в ночное время (вне пиковых нагрузок), потеря данных недопустима. Бюджет на инфраструктуру ограничен.
+
+**Целевая архитектура (после миграции):**
+
+На схеме ниже представлен проект инфраструктуры после миграции по стратегии Replatform:
+
+![Целевая архитектура интернет-магазина в VK Cloud](VKC_CASE_03_migration_IvanovII_20260619.drawio.png)
+
+*Рис. 1 – Архитектура решения в VK Cloud: пользователь → DNS → Балансировщик → Веб-серверы (зоны А и Б) → Managed PostgreSQL / S3.*
+
+**Описание компонентов схемы:**
+
+1. **Внешний доступ:**
+   - **Пользователь** обращается к сайту через **DNS** (`shop.example.com`).
+   - **Балансировщик L7** с публичным IP принимает входящий HTTP/HTTPS-трафик и распределяет его между веб-серверами.
+   - **Администратор** подключается к инфраструктуре через **Бастион-хост** (SSH, порт 22).
+
+2. **Виртуальная сеть (VPC):**
+   - Вся инфраструктура развернута в виртуальном частном облаке **VPC 10.0.0.0/16**.
+   - **Публичная подсеть (10.0.1.0/24):** Содержит Бастион-хост для безопасного доступа к внутренним ресурсам.
+   - **Приватная подсеть APP (10.0.2.0/24):** Содержит два веб-сервера с Apache/PHP, размещенных в разных зонах доступности (**Зона А** и **Зона Б**) для обеспечения отказоустойчивости.
+   - **Приватная подсеть DB (10.0.3.0/24):** Содержит управляемый кластер **PostgreSQL** (Master для записи и Replica для чтения).
+
+3. **Управляемые сервисы:**
+   - **Объектное хранилище S3:** Используется для хранения статических файлов (изображения, загрузки пользователей) и резервных бэкапов БД.
+
+4. **Потоки трафика:**
+   - Балансировщик направляет HTTP/HTTPS-запросы к веб-серверам.
+   - Веб-серверы взаимодействуют с Master PostgreSQL для операций записи и с Replica для операций чтения.
+   - Веб-серверы загружают файлы пользователей в S3.
+   - Администратор подключается к бастиону, а через него — к веб-серверам по SSH.
+
+## 2. Ограничения и исходные условия
+
+| Критерий | Исходное условие / Ограничение | Влияние на выбор стратегии |
+|----------|--------------------------------|----------------------------|
+| **Технические зависимости** | Жесткая привязка к конкретным версиям PHP (7.4) и MySQL (8.0). | Необходимо сохранить версии в облаке или тщательно протестировать совместимость. |
+| **Состояние данных** | Данные хранятся в файлах БД на том же диске, что и код. | Требуется выделить этап синхронизации данных и проверки целостности. |
+| **Доступность (SLA)** | Допустим простой до 2 часов. Отказоустойчивость отсутствует (SPOF). | Желательно внедрить балансировку и репликацию БД в рамках миграции. |
+| **Бюджет** | Ограниченный. Текущие затраты ~25 000 руб./мес. | Необходимо избегать дорогих сервисов без явной выгоды. |
+| **Сроки** | Не более 3 недель. | Исключает полный рефакторинг архитектуры (микросервисы). |
+| **Компетенции команды** | Хорошее знание Linux/MySQL/PHP, минимальный опыт с облаками. | Рекомендуется использовать управляемые сервисы (DBaaS). |
+
+## 3. Варианты решения (6R)
+
+| Вариант | Плюсы | Минусы | Когда применять |
+|---------|-------|--------|-----------------|
+| **1. Rehost** | ✅ Скорость (1-2 дня). <br> ✅ Минимум изменений. | ❌ Не даёт преимуществ облака. <br> ❌ Сохраняется SPOF. | Срочная миграция без времени на оптимизацию. |
+| **2. Replatform** | ✅ Баланс скорости и качества (2-3 недели). <br> ✅ Устранение SPOF. <br> ✅ Автоматизация бэкапов. | ❌ Требует изменения конфигураций подключения к БД. | **Выбранный вариант.** Оптимальное соотношение цены и надежности. |
+| **3. Refactor** | ✅ Максимальная масштабируемость. | ❌ Очень долго (3-6 месяцев). <br> ❌ Требует высокой квалификации. | Долгосрочная стратегия при наличии ресурсов. |
+| **4. Repurchase** | ✅ Перекладывание ответственности на вендора. | ❌ Нет готового SaaS для кастомного магазина. | Миграция на типовые CRM/ERP системы. |
+
+## 4. Выбранное решение и обоснование
+
+**Выбранная стратегия: Replatform (Частичная модернизация)**
+
+**Обоснование:**
+1.  **Оптимальный баланс:** Стратегия позволяет получить основные преимущества облака (автоматические бэкапы, отказоустойчивость, масштабирование) за приемлемое время (2-3 недели) и без изменения бизнес-кода.
+2.  **Снижение эксплуатационных расходов:** Замена ручного администрирования серверов на управляемые сервисы (Managed PostgreSQL, S3) снижает нагрузку на команду.
+3.  **Повышение отказоустойчивости:** Внедрение балансировщика и размещение веб-серверов в разных зонах доступности (как показано на схеме) устраняет единую точку отказа.
+4.  **Финансовая эффективность:** Расчётная стоимость (~16 000 руб./мес) ниже текущих затрат (~25 000 руб./мес).
+
+## 5. План миграции (этапы)
+
+| Этап | Действия | Срок | Инструменты |
+|------|----------|------|-------------|
+| **1. Подготовка сети** | Создать VPC, публичную и приватные подсети, настроить Security Groups и бастион-хост. | День 1-2 | Веб-консоль / Terraform |
+| **2. Перенос данных** | Создать Managed PostgreSQL, сделать дамп существующей БД, восстановить на управляемом инстансе. | День 3-5 | `mysqldump`, DBaaS, S3 |
+| **3. Перенос приложения** | Развернуть 2 веб-сервера (образ через Packer) в приватной подсети, настроить балансировщик. | День 5-7 | Packer, Terraform |
+| **4. Тестирование** | Проверить работу сайта, формы, загрузку файлов, нагрузочное тестирование. | День 8-10 | Ручное тестирование, Grafana |
+| **5. Переключение DNS** | Установить низкий TTL, переключить DNS на IP балансировщика. Мониторинг 24 часа. | День 11 | Провайдер DNS |
+| **6. Вывод из эксплуатации** | Отключить старый сервер, удалить временные ресурсы. | День 14 | Веб-консоль / CLI |
+
+## 6. Риски и меры снижения
+
+| Риск | Вероятность | Влияние | Меры снижения (Mitigation) |
+|------|-------------|---------|----------------------------|
+| **Потеря данных БД** | Средняя | Критическое | 1. Полный бэкап перед началом. <br> 2. Использовать Hystax для репликации. <br> 3. Восстановление на тестовый инстанс. |
+| **Несовместимость версий ПО** | Средняя | Высокое | 1. Использовать аналогичные версии в облаке. <br> 2. Собрать образ через Packer, повторяющий среду. <br> 3. Регрессионное тестирование на staging. |
+| **Простой > 2 часов** | Средняя | Высокое | 1. Стратегия Blue-Green. <br> 2. Низкий TTL для DNS. <br> 3. Миграция в ночь минимальной нагрузки. |
+| **Рост затрат (FinOps)** | Высокая | Среднее | 1. Настроить бюджетные алерты. <br> 2. Использовать Spot-инстансы для тестов. <br> 3. Автоматическое выключение сред в нерабочее время. |
+
+## 7. Оценка затрат (FinOps)
+
+| № | Наименование ресурса | Конфигурация | Кол-во | Цена за ед./мес (₽) | Итого (₽) |
+|---|----------------------|--------------|--------|---------------------|-----------|
+| 1 | Веб-сервер (ВМ) | 2 vCPU / 4GB RAM / 40GB SSD | 2 | 4 015 | 8 030 |
+| 2 | Бастион-хост (ВМ) | 1 vCPU / 1GB RAM / 20GB SSD | 1 | 1 460 | 1 460 |
+| 3 | Managed PostgreSQL | 2 vCPU / 4GB RAM (кластер HA) | 1 | 7 300 | 7 300 |
+| 4 | Балансировщик L7 | Малый (до 1000 запросов/сек) | 1 | 1 460 | 1 460 |
+| 5 | Объектное хранилище S3 | 100 ГБ (стандарт) | 1 | 430 | 430 |
+| | **Итого в облаке** | | | | **~16 680 ₽** |
+| | **Текущие затраты (On-Premise)** | Аренда + электричество + обслуживание | | | **~25 000 ₽** |
+
+**Экономия:** ~33% (снижение затрат на ~8 300 ₽ в месяц).
+
+## 8. Артефакты
+
+| Файл | Назначение |
+|------|------------|
+| `VKC_CASE_03_migration_IvanovII_20260619.md` | Настоящий отчет по анализу и выбору стратегии миграции. |
+| `VKC_CASE_03_migration_IvanovII_20260619.drawio.png` | Экспорт схемы целевой архитектуры (встроен в отчет). |
+| `VKC_ARCH_M08_highload_store.drawio` | Исходный файл схемы в Draw.io для редактирования. |
+| `VKC_CASE_03_cost_calculation.xlsx` | Детальный расчет стоимости с формулами (прилагается отдельно). |
+
+## 9. Вывод
+
+В ходе анализа приложения интернет-магазина выбрана стратегия **Replatform** как оптимальный компромисс между скоростью миграции (2-3 недели), стоимостью владения (экономия ~33%) и уровнем надежности (устранение единой точки отказа).
+
+Разработанная архитектура (VPC с публичной и приватными подсетями, балансировщик, веб-серверы в разных зонах доступности, управляемая БД и S3) полностью соответствует современным стандартам облачных решений. План миграции включает обязательные этапы тестирования и имеет четкий план отката, что позволяет начать миграцию с минимальными рисками для бизнеса.