doc-locale/fr-fr/administration/reference_architectures/1k_users.md
{{< details >}}
{{< /details >}}
Cette architecture de référence cible une charge de pointe de 20 requêtes par seconde (RPS). D'après des données réelles, cette charge correspond généralement à jusqu'à 1 000 utilisateurs, incluant les interactions manuelles et automatisées.
Pour une liste complète des architectures de référence, voir les architectures de référence disponibles.
| Utilisateurs | Configuration | Exemple GCP<sup>1</sup> | Exemple AWS<sup>1</sup> | Exemple Azure<sup>1</sup> |
|---|---|---|---|---|
| Jusqu'à 1 000 ou 20 RPS | 8 vCPU, 16 Go de mémoire | n1-standard-8<sup>2</sup> | c5.2xlarge | F8s v2 |
Footnotes :
<!-- Disable ordered list rule <https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md029---ordered-list-item-prefix> --> <!-- markdownlint-disable MD029 -->Le diagramme suivant montre que bien que GitLab puisse être installé sur un seul serveur, il est composé en interne de plusieurs services. Lorsqu'une instance évolue, ces services sont séparés et mis à l'échelle de manière indépendante selon leurs besoins spécifiques.
Dans certains cas, vous pouvez utiliser le PaaS pour certains services. Par exemple, vous pouvez utiliser le stockage d'objets dans le cloud pour certains systèmes de fichiers. Pour des raisons de redondance, certains services deviennent des clusters de nœuds et stockent les mêmes données.
Dans une configuration GitLab mise à l'échelle horizontalement, divers services auxiliaires sont nécessaires pour coordonner les clusters ou découvrir les ressources. Par exemple, PgBouncer pour la gestion des connexions PostgreSQL, ou Consul pour la découverte des points de terminaison Prometheus.
@startuml 1k
card "**Prometheus**" as monitor #7FFFD4
package "GitLab Single Server" as gitlab-single-server {
together {
card "**GitLab Rails**" as gitlab #32CD32
card "**Gitaly**" as gitaly #FF8C00
card "**PostgreSQL**" as postgres #4EA7FF
card "**Redis**" as redis #FF6347
card "**Sidekiq**" as sidekiq #ff8dd1
}
card "Local Storage" as local_storage #white
}
gitlab -[#32CD32]--> gitaly
gitlab -[#32CD32]--> postgres
gitlab -[#32CD32]--> redis
gitlab -[#32CD32]--> sidekiq
gitaly -[#32CD32]--> local_storage
postgres -[#32CD32]--> local_storage
sidekiq -[#32CD32]--> local_storage
gitlab -[#32CD32]--> local_storage
monitor .[#7FFFD4]u-> gitlab
monitor .[#7FFFD4]u-> sidekiq
monitor .[#7FFFD4]-> postgres
monitor .[#7FFFD4]-> gitaly
monitor .[#7FFFD4,norank]--> redis
@enduml
Avant de continuer, consultez les prérequis pour les architectures de référence.
[!warning] Les spécifications du nœud sont basées sur des percentiles élevés des modèles d'utilisation et des tailles de dépôt en bon état. Cependant, si vous avez des grands monodépôts (de plusieurs gigaoctets ou plus) ou des charges de travail supplémentaires, ceux-ci peuvent avoir un impact significatif sur les performances de l'environnement. Si cela s'applique à votre cas, des ajustements supplémentaires peuvent être nécessaires. Consultez la documentation liée et contactez-nous si nécessaire pour obtenir des conseils supplémentaires.
L'architecture de référence 20 RPS / 1k utilisateurs est conçue pour prendre en charge la plupart des flux de travail courants. GitLab effectue régulièrement des tests de smoke et de performance par rapport aux objectifs de débit des points de terminaison suivants :
| Type de point de terminaison | Débit cible |
|---|---|
| API | 20 RPS |
| Web | 2 RPS |
| Git (Pull) | 2 RPS |
| Git (Push) | 1 RPS |
Ces objectifs sont basés sur des données clients réelles reflétant les charges environnementales totales pour le nombre d'utilisateurs spécifié, y compris les pipelines CI et d'autres charges de travail. Cela représente une composition de charge de travail typique. Pour des conseils sur les modèles de charge de travail atypiques, voir Comprendre la composition des RPS.
Pour plus d'informations sur notre méthodologie de test, voir la section résultats de validation et de test.
Des ajustements supplémentaires peuvent être nécessaires si votre environnement présente :
Dans ces cas, référez-vous à la mise à l'échelle d'un environnement pour plus d'informations. Si vous pensez que ces considérations peuvent s'appliquer à votre cas, contactez-nous pour obtenir des conseils supplémentaires si nécessaire.
Pour installer GitLab avec cette architecture de référence par défaut, utilisez les instructions d'installation standard.
Vous pouvez également configurer GitLab pour utiliser un service PostgreSQL externe ou un service de stockage d'objets externe. Cela améliore les performances et la fiabilité, mais au prix d'une complexité accrue.
{{< details >}}
{{< /details >}}
Vous pouvez utiliser Elasticsearch et activer la recherche avancée pour une recherche de code plus rapide et plus avancée sur l'ensemble de votre instance GitLab.
La conception et les exigences du cluster Elasticsearch dépendent de vos données. Pour les meilleures pratiques recommandées sur la configuration de votre cluster Elasticsearch aux côtés de votre instance, voir choisir la configuration de cluster optimale.
Dans la configuration d'architecture de référence Cloud Native Hybrid, les composants sans état sélectionnés sont déployés dans Kubernetes à l'aide de nos Helm Charts officiels. Les composants avec état sont déployés dans des VM de calcul avec le package Linux.
La plus petite architecture de référence disponible pour une utilisation dans Kubernetes est le GitLab Cloud Native Hybrid 2k ou 40 RPS (non HA) et le GitLab Cloud Native Hybrid 3k ou 60 RPS (HA).
Pour les environnements qui servent moins d'utilisateurs ou un RPS plus faible, vous pouvez réduire la spécification des nœuds. Selon votre nombre d'utilisateurs, vous pouvez réduire toutes les spécifications de nœuds suggérées selon vos besoins. Cependant, vous ne devez pas descendre en dessous des exigences générales.
Vous disposez maintenant d'un environnement GitLab tout neuf avec les fonctionnalités principales configurées en conséquence. Vous souhaiterez peut-être configurer des fonctionnalités GitLab supplémentaires et optionnelles en fonction de vos besoins. Voir Étapes après l'installation de GitLab pour plus d'informations.
[!note] Selon votre environnement et vos besoins, des exigences matérielles supplémentaires ou des ajustements peuvent être nécessaires pour configurer des fonctionnalités supplémentaires. Consultez les pages individuelles pour plus d'informations.