Продовжуємо нашу подорож з AWS OpenSearch Service. Що ми маємо – це маленький кластер AWS OpenSearch Service, 3 трьома data nodes, використовується в ролі vector store для AWS Bedrock Knowledge Bases. Попередні частини: AWS: знайомство з OpenSearch Service в ролі vector store AWS: створення OpenSearch Service cluster та налаштування аутентифікації і авторизації Terraform: створення AWS… Читати далі »
В першій частині розібрались з основами AWS OpenSearch Service взагалі, і з типами інстансів для Data Nodes – AWS: знайомство з OpenSearch Service в ролі vector store. В другій – з доступами, AWS: створення OpenSearch Service cluster та налаштування аутентифікації і авторизації. Тепер напишемо Terraform code для створення кластера, юзерів та індексів. Створювати кластер будемо… Читати далі »
В попередній частині – AWS: знайомство з OpenSearch Service в ролі vector store – подивились на AWS OpenSearch Service взагалі, трохи розібрались з тим, як в ньому організовані дані, що таке shards та nodes, і які нам власне типи інстансів для data nodes треба. Наступний крок – створити кластер і подивитись на аутентифікацію, яка, як на… Читати далі »
Ми зараз використовуємо AWS OpenSearch Service як vector store для нашого RAG з AWS Bedrock Knowledge Base. Про RAG і Bedrock детальніше поговоримо іншим разом, а сьогодні давайте подивимось на AWS OpenSearch Service. Власне, задача – мігрувати наш AWS OpenSearch Service Serverless на Managed, в першу чергу через (сюрпрайз) питання вартості – бо з Serverless… Читати далі »
Версія v21.0.0 додала підтримку AWS Provider Version 6 Документація – тут>>>. З основних змін в модулі AWS EKS – це заміна IRSA на EKS Pod Identity для Karpenter sub-module: Native support for IAM roles for service accounts (IRSA) has been removed; EKS Pod Identity is now enabled by default Плюс “The `aws-auth` sub-module has been… Читати далі »
Після міграції на новий Kubernetes Cluster на Backend API почали виникати помилки 503. Чому з’явились саме на 1.33 – так і не зрозумів, бо в параметрах AWS ALB та Kubernetes Ingress нічого не мінялось, а на 1.30 їх не було. Може спрацювали деякі мої фікси в моніторингу – або це щось пов’язане новим AMI чи… Читати далі »
Якщо дуже просто, то Celery – це щось, за допомогою чого ми можемо виконувати задачі поза нашим основним сервісом. Наприклад, є Backend API, який має якийсь ендпоінт, на який мобілочки відправляють інформацію про те, що юзер створив новий whatever в застосунку. Задача бекенда – додати whatever в базі даних. Можна це виконати прямо в інстансі… Читати далі »
Вже згадував про можливості EXPLAIN в пості PostgreSQL: AWS RDS Performance and monitoring, але це настільки цікава і корисна штука, що варто про неї поговорити окремо. До того ж, в AWS RDS для PostgreSQL є можливість включити логування Execution Plans з EXPLAIN, що теж корисно для моніторингу і дебагу, тому подивимось як це включити і… Читати далі »
Мігруємо наш Backend API з DynamoDB на AWS RDS PostgreSQL, і кілька раз RDS падав. Власне, враховуючи те, що ми задля економії взяли db.t3.small з двома vCPU і двома гігабайтами пам’яті – то доволі очікувано, але стало цікаво чому ж саме все падало. Через кілька днів почав цю тему дебажити, і хоча причини поки не… Читати далі »
У нас в Kubernetes запускаються GitHub Runner для білда і деплоя нашого Backend API, див. GitHub Actions: запуск Actions Runner Controller в Kubernetes. Але з часом ми звернули увагу, що на NAT Gateway бігає якось забагато трафіку – див. VictoriaLogs: дашборда в Grafana з AWS VPC Flow Logs – мігруємо з Grafana Loki. Проблема: трафік… Читати далі »