Cloud & Haute disponibilité
Cette page présente les aspects liés à l'utilisation de services Cloud (privés ou publiques) pour déployer et héberger plateformes et bots Tock.
En effet, nous avons l'expérience d'utilisations de Tock en production sur des hébergements classiques on-premise et bare metal, mais aussi sur des Clouds privés comme OpenStack ou Clouds publiques comme AWS.
Haute disponibilité
Cette section fournit des conseils et des retours d'expérience sur les configurations haute disponibilité (ou HA - High Availability) de bots et plateformes Tock.
Redondance et résilience
Une seule instance de tock/build_worker doit exister.
Il est recommandé d'utiliser une seule instance de tock/bot_admin et tock/kotlin_compiler.
Pour les autres composants, en particulier le composant bot (non fourni) mais également tock/bot_api, tock/nlp_api,
tock/duckling et tock/gen-ai-orchestrator-server, il est recommandé de déployer plusieurs instances pour assurer
une meilleure disponibilité voire de meilleures performances.
Les sessions de Tock Studio sont conservées en mémoire : avec plusieurs instances de tock/bot_admin, activez les
sessions persistantes (sticky sessions) sur le répartiteur de charge.
La disponibilité du RAG dépend aussi de la base vectorielle et des fournisseurs de LLM et d'embeddings : voir leur documentation pour leurs propres options de haute disponibilité.
Performance
Comme indiqué dans la section installation, le premier paramètre à surveiller est la mémoire disponible.
A forte charge - nous avons expérimenté plus de 80 req/s sur nos propres bots - le facteur limitant devient la base de données MongoDB, qu'il faut alors redimensionner en conséquence quand le besoin s'en fait sentir.
Avec le RAG, le temps de réponse dépend surtout du fournisseur de LLM : ajustez
tock_gen_ai_orchestrator_client_request_timeout_ms et les délais de l'orchestrateur en conséquence
(voir Configuration).
Kubernetes
Le chart Helm déploie Tock sur Kubernetes. Quelle que soit la méthode de déploiement, appliquez les recommandations ci-dessus :
tock/build_worker: 1 réplica, avec la stratégie de mise à jourRecreatepour que deux instances ne tournent jamais en même tempstock/bot_adminettock/kotlin_compiler: 1 réplica (ou des sticky sessions pourtock/bot_admin)tock/bot_api,tock/nlp_api,tock/duckling,tock/gen-ai-orchestrator-server: plusieurs réplicas- Sondes :
/health/readinesset/health/livenesspour les composants JVM,/health-checket/liveness-checkpour l'orchestrateur Gen AI (voir Supervision) - Mémoire : fixez la limite mémoire du conteneur au-dessus du tas maximal de la JVM (
-XmxdansJAVA_ARGS, voir Installation)
Chat with Tock