Nail/SQS-service
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore: миграция на Nubes Managed — правила, README, registry Gitea, легаси помечено

Browse Source
This commit is contained in:
Naeel
2026-08-13 20:42:18 +03:00
parent 6af635afee
commit 5c1c021bb4
15 changed files with 2125 additions and 87 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/decisions/LEGACY.md
+5
View File
@@ -0,0 +1,5 @@
# ⚠️ ЛЕГАСИ — НЕ ИСПОЛЬЗОВАТЬ
Исторические решения этапа разработки (апрель 2026).
**ЭТИМ НЕ РУКОВОДСТВОВАТЬСЯ.** Только для истории.
Помечено: 2026-08-13.
doc/errors/LEGACY.md
+5
View File
@@ -0,0 +1,5 @@
# ⚠️ ЛЕГАСИ — НЕ ИСПОЛЬЗОВАТЬ
Исторические инциденты/ошибки этапа разработки.
**ЭТИМ НЕ РУКОВОДСТВОВАТЬСЯ.** Только для истории.
Помечено: 2026-08-13.
doc/legacy/BENCHMARK-COMPARISON.md
+93
View File
@@ -0,0 +1,93 @@
<!-- ⚠️ ЛЕГАСИ — НЕ ИСПОЛЬЗОВАТЬ КАК РУКОВОДСТВО.
Исторические сравнительные тесты vs Yandex MQ (апрель 2026).
Перенесён из корня репозитория в doc/legacy 2026-08-13.
Замеры устарели, только для справки. -->
# Сравнительный анализ shared-sqs vs Yandex MQ
**Дата:** 2026-04-12 06:05 UTC
Итог сравнительных тестов shared-sqs и Yandex MQ.
## Главное
- shared-sqs показал конкурентоспособные результаты относительно Yandex MQ.
- На основных API-операциях shared-sqs в текущем прогоне быстрее или на уровне Yandex MQ.
- На batch-операциях shared-sqs также выглядит сильно.
- Проверкой охвачены все 17 поддерживаемых SQS-операций.
## Короткий вывод
Если смотреть на практические сценарии отправки, чтения и batch-обработки сообщений, shared-sqs уже выглядит как сильная реализация с хорошей latency и без явного проигрыша managed-сервису.
## Самые важные цифры
Формат: `min / avg / max / p95`, миллисекунды.
| Операция | Yandex MQ | shared-sqs | Что это значит |
|---|---:|---:|---|
| GetQueueUrl | 766 / 1346 / 2266 / 2060 | 739 / 752 / 770 / 760 | shared-sqs намного стабильнее |
| GetQueueAttributes | 804 / 820 / 847 / 828 | 738 / 752 / 768 / 765 | shared-sqs быстрее |
| SendMessage 1KB | 804 / 811 / 824 / 823 | 748 / 760 / 770 / 767 | shared-sqs быстрее |
| SendMessage 10KB | 916 / 967 / 996 / 987 | 880 / 913 / 965 / 951 | shared-sqs быстрее |
| SendMessage 32KB | 905 / 930 / 948 / 947 | 883 / 904 / 939 / 928 | shared-sqs быстрее |
| SendMessageBatch 10 | 784 / 803 / 827 / 820 | 718 / 746 / 782 / 759 | shared-sqs быстрее |
| ReceiveMessage | 782 / 826 / 869 / 864 | 738 / 748 / 777 / 751 | shared-sqs быстрее |
| DeleteMessage | 783 / 800 / 823 / 814 | 727 / 742 / 757 / 755 | shared-sqs быстрее |
| DeleteMessageBatch 10 | 818 / 845 / 872 / 864 | 742 / 783 / 821 / 810 | shared-sqs быстрее |
| ChangeMessageVisibilityBatch 10 | 806 / 829 / 848 / 841 | 803 / 824 / 838 / 836 | почти паритет, но shared-sqs чуть быстрее |
## Покрытие тестов по всем операциям
Ниже показано покрытие по каждой из 17 операций.
Обозначения:
- `Сравнение latency` — операция вошла в прямое сравнение shared-sqs и Yandex MQ.
- `Функциональная проверка` — операция отдельно проверялась на корректную работу.
- `Функционально проверено` — операция подтверждена в shared-sqs, без отдельной публичной latency-таблицы.
| Операция | Статус проверки | Комментарий |
|---|---|---|
| CreateQueue | Функциональная проверка | Использовалась в setup и проверялась как часть queue lifecycle |
| DeleteQueue | Функциональная проверка | Проверялась как часть queue lifecycle |
| GetQueueAttributes | Сравнение latency | Полноценное сравнение с Yandex MQ |
| GetQueueUrl | Сравнение latency | Полноценное сравнение с Yandex MQ |
| ListQueues | Сравнение latency | Полноценное сравнение с Yandex MQ |
| PurgeQueue | Сравнение latency | Контрольный замер, без многократного цикла |
| SetQueueAttributes | Сравнение latency | Полноценное сравнение с Yandex MQ |
| SendMessage | Сравнение latency | Сравнение для 1KB, 10KB и 32KB |
| SendMessageBatch | Сравнение latency | Batch из 10 сообщений |
| ReceiveMessage | Сравнение latency | Полноценное сравнение с Yandex MQ |
| DeleteMessage | Сравнение latency | Полноценное сравнение с Yandex MQ |
| DeleteMessageBatch | Сравнение latency | Batch delete на 10 сообщений |
| ChangeMessageVisibility | Сравнение latency | Полноценное сравнение с Yandex MQ |
| ChangeMessageVisibilityBatch | Сравнение latency | Batch visibility на 10 сообщений |
| TagQueue | Функционально проверено | Операция поддерживается и отдельно проверена |
| UntagQueue | Функционально проверено | Операция поддерживается и отдельно проверена |
| ListQueueTags | Функционально проверено | Операция поддерживается и отдельно проверена |
Итог по покрытию:
- `10` операций вошли в прямое latency-сравнение.
- `4` queue/control-plane операции дополнительно подтверждены функциональными сценариями.
- `3` tag-операции отдельно подтверждены функционально.
## Throughput
Тест: `SendMessage 1KB`, `5` воркеров по `10` сообщений.
| Провайдер | Успешно | Общее время | Грубая оценка |
|---|---:|---:|---:|
| Yandex MQ | 50 / 50 | 9116 ms | ~5 msg/s |
| shared-sqs | 50 / 50 | 8580 ms | ~5 msg/s |
Практический смысл:
- По грубой оценке `msg/s` здесь паритет.
- По общему времени shared-sqs завершает тест немного быстрее.
- Основное ограничение этого сценария задаётся AWS CLI, а не backend обоих сервисов.
## Финальный вывод для пользователя
shared-sqs уже выглядит достаточно сильным решением: latency на уровне или ниже Yandex MQ, batch-операции быстрые, а в общей рабочей зоне сервис показывает уверенные результаты.
doc/legacy/ONBOARDING.md
+173
View File
@@ -0,0 +1,173 @@
<!-- ⚠️ ЛЕГАСИ — НЕ ИСПОЛЬЗОВАТЬ КАК РУКОВОДСТВО.
Старая памятка для агента/нового чата (апрель 2026).
Перенесена из корня репозитория в doc/legacy 2026-08-13.
Описывает устаревший k8s-деплой и порядок работы. -->
# ONBOARDING.md — Памятка для нового чата / агента
# Дата: 2026-04-10
# Автор: GitHub Copilot (Claude Opus 4.6)
---
## Что это за проект
**SQS-service** — multi-tenant сервис очередей сообщений, совместимый с AWS SQS API.
Единственный в open source проект такого рода (подтверждено поиском по GitHub: 0 результатов по `multi-tenant sqs compatible`).
Ближайшие аналоги — ElasticMQ (Scala) и GoAws (Go), но оба **single-tenant** и предназначены только для local dev/testing.
---
## Откуда взялся код
Основан на **GoAws** (https://github.com/Admiral-Piett/goaws).
Первый коммит в `sless`: `shared-sqs: Этап 1 — клон GoAWS, удаление SNS, go build OK`
Затем поверх GoAws построены: мультитенантность, auth, admin API, WebUI, Redis persistence.
---
## Текущая версия
**v0.1.14** — работает в кластере iot-naeel
| Параметр | Значение |
|----------|---------|
| Endpoint | `https://qu.kube5s.ru` |
| IP | `185.247.187.151` |
| Admin token | `sqs-admin-7a7d8bd0c060a75c198d48680f34077a` |
| Demo Access Key | `SSAK-demo-shared-sqs` |
| Demo Secret Key | `demo-secret-key-shared-sqs-ngcloud-2026` |
| Docker image | `naeel/shared-sqs:v0.1.14` |
| Redis | `rfrm-redisk8s.54467f74-67f5-4ca7-9b4a-bdd50e8c23d6.svc.cluster.local:6379` |
| Kubeconfig | `/home/naeel/.kube/iot-naeel.yaml` (на ВМ) |
| Namespace | `shared-sqs` |
---
## Инфраструктура — ВАЖНО
### ВМ и монтирование
- **ВМ**: `naeel@5.172.178.213`
- **SSH-ключ**: `~/.ssh/naeel_vm_id_ed25519`
- **Реальный путь на ВМ**: `/home/naeel/terra/SQS-service`
- **Смонтировано как**: `/home/naeel/remote_dev/SQS-service` (sshfs)
### ⛔ КРИТИЧЕСКОЕ ПРАВИЛО
`/home/naeel/remote_dev/SQS-service` — это **СМОНТИРОВАННАЯ ПАПКА**.
Физически файлы на ВМ. **ВСЕ команды выполнять ТОЛЬКО через SSH на ВМ:**
```bash
ssh -i ~/.ssh/naeel_vm_id_ed25519 -o StrictHostKeyChecking=no -o ConnectTimeout=10 \
naeel@5.172.178.213 'cd /home/naeel/terra/SQS-service && <КОМАНДА>'
```
Через IDE — ТОЛЬКО редактирование файлов. Терминальные команды — ТОЛЬКО SSH.
---
## Архитектура кода
```
app/
├── cmd/goaws.go — точка входа, HTTP сервер
├── cmd/seed.go — загрузка демо-данных
├── models/ — Queue, Message, Tenant, SyncQueues (глобальный мьютекс!)
├── gosqs/ — реализация SQS API (CreateQueue, SendMessage, ReceiveMessage и т.д.)
├── admin/admin.go — Admin API: создание/получение тенантов
├── tenant/tenant_store.go — хранилище тенантов (access key → tenant)
├── auth/auth_middleware.go — AWS Signature V4 парсинг credential
├── persistence/redis.go — Redis write-through adapter
├── router/router.go — маршруты HTTP
├── ui/index.html — WebUI (встроен через embed.go)
└── utils/, interfaces/ — утилиты
```
---
## Известные проблемы (не трогать пока не попросят)
1. **Глобальный мьютекс** `models.SyncQueues` — Lock/Unlock на ВСЕ операции. Bottleneck при нагрузке.
2. **Нет DLQ** (Dead Letter Queue)
3. **Long Polling naïve** — sleep loop вместо push
4. **Нет rate limiting** per tenant
5. **Нет метрик** (Prometheus)
6. **Single pod** — нет горизонтального масштабирования
---
## Что делать дальше (от пользователя)
### 1. Статистика для биллинга
Нужен сбор метрик по каждому тенанту:
- Количество отправленных/полученных сообщений
- Количество созданных очередей
- Объём данных (bytes in/out)
- Время жизни сообщений
**Где встраивать**: `app/gosqs/send_message.go`, `app/gosqs/receive_message.go`, `app/gosqs/create_queue.go`
**Где хранить**: Новый пакет `app/billing/` или расширить `app/persistence/redis.go`
**Формат**: Redis HINCRBY per tenant per day, или отдельная таблица в PostgreSQL
### 2. Защита конфиденциальности
- Тела сообщений не должны логироваться
- Admin API должен быть доступен только из внутренней сети (или по отдельному порту)
- Тенанты не должны видеть друг друга (уже реализовано на уровне auth)
- Рассмотреть шифрование тел сообщений at rest (в Redis)
- Audit log: кто, когда, что делал
**Где встраивать**: middleware в `app/router/router.go`, новый пакет `app/audit/`
### 3. Рекомендации по порядку
1. Сначала **биллинг** — простой счётчик в Redis, можно сделать за 1 сессию
2. Затем **audit log** — middleware логирует tenant_id + action + timestamp
3. Затем **encryption at rest** — обёртка над Redis get/set
4. В последнюю очередь — rate limiting (зависит от биллинга)
---
## Тесты
| Скрипт | Описание | Как запускать |
|--------|----------|--------------|
| `tests/quick_test.sh` | 6 базовых тестов | `bash tests/quick_test.sh` |
| `tests/hardcore_test.sh` | Суровые тесты | `bash tests/hardcore_test.sh` |
| `tests/shared_sqs_test.sh` | E2E тесты | `bash tests/shared_sqs_test.sh` |
**ВАЖНО**: В `tests/quick_test.sh` используются demo credentials (`SSAK-demo-shared-sqs`).
В `tests/hardcore_test.sh` может быть admin token — НЕ КОММИТИТЬ в публичные репы!
---
## Git workflow
- Репо: `https://gitea.services.ngcloud.ru/Nail/SQS-service`
- Ветка: `main`
- Коммитить и пушить после каждого завершённого этапа (правило из copilot-instructions)
- Все команды git — через SSH на ВМ
---
## Сборка и деплой
```bash
# На ВМ:
cd /home/naeel/terra/SQS-service
# Сборка
docker build -t naeel/shared-sqs:v0.1.15 .
docker push naeel/shared-sqs:v0.1.15
# Деплой
export KUBECONFIG=/home/naeel/.kube/iot-naeel.yaml
kubectl set image deployment/shared-sqs shared-sqs=naeel/shared-sqs:v0.1.15 -n shared-sqs
kubectl rollout status deployment/shared-sqs -n shared-sqs
```
---
*Создано: 2026-04-10. Обновлять при значимых изменениях.*
doc/legacy/PLAN.md
+1693
View File
File diff suppressed because it is too large Load Diff
doc/progress.md
+3
View File
@@ -1,3 +1,6 @@
<!-- ⚠️ ЛЕГАСИ — история версий разработки (апрель 2026).
ЭТИМ НЕ РУКОВОДСТВОВАТЬСЯ. Только для истории. Помечено 2026-08-13. -->
# SQS-service Progress
## Версия v0.1.x
doc/thinking/LEGACY.md
+5
View File
@@ -0,0 +1,5 @@
# ⚠️ ЛЕГАСИ — НЕ ИСПОЛЬЗОВАТЬ
Исторические размышления/заметки этапа разработки.
**ЭТИМ НЕ РУКОВОДСТВОВАТЬСЯ.** Только для истории.
Помечено: 2026-08-13.