Activer l'analyse du secteur des services financiers avec DataSynapse GridServer sur Oracle Cloud Infrastructure
Les banques et les organisations de services financiers se tournent rapidement vers le cloud pour déployer leurs analyses financières stratégiques, nécessitant souvent des ressources de calcul hautes performances (HPC) non disponibles en interne. L'augmentation de la concurrence et des réglementations incite davantage d'entreprises à se tourner vers le cloud pour faire face aux charges de travail croissantes d'analyses financières.
Oracle Cloud Infrastructure (OCI) fournit une infrastructure cloud de deuxième génération complète qui permet aux banques et aux organisations de services financiers de déployer rapidement le cloud pour l'analyse financière. Oracle possède une solide expérience en matière de gestion et d'analyse des données clients, ce qui lui permet de fournir de telles ressources dans son infrastructure cloud.
DataSynapse GridServer, un produit logiciel de TIBCO, est une infrastructure logicielle hautement évolutive qui permet aux services applicatifs de fonctionner de manière virtualisée, sans lier ces services à une ressource matérielle spécifique. GridServer provisionne de manière dynamique les demandes de service pour les ressources matérielles disponibles de manière hautement évolutive grâce à la possibilité de traiter facilement plusieurs demandes.
Architecture
GridServer a été testé sur divers clusters HPC sur OCI, composés de diverses formes d'instance de calcul, y compris Bare Metal (BM) et de machines virtuelles (VM). Ces clusters ont été instanciés à l'aide d'une pile HPC dans OCI Resource Manager, qui utilise un modèle terraform contenant les parties qui transforment un ensemble d'instances en cluster HPC fonctionnel. La pile peut ajouter des volumes de partage de fichiers réseau (NFS), des volumes de blocs supplémentaires ou un autre système de fichiers (tel que le service OCI File Storage). Une fois les clusters HPC de test créés, GridServer a été installé en suivant les instructions d'installation du logiciel.
Les clusters testés sont basés sur l'architecture suivante.
dataynapse-gridserver-oci-architecture.zip
L'architecture se compose des éléments suivants :
- Région
Une région Oracle Cloud Infrastructure est une zone géographique localisée qui contient des centres de données, appelés domaines de disponibilité. Les régions sont indépendantes les unes des autres et de grandes distances peuvent les séparer (dans des pays voire des continents).
- Domaines de disponibilité
Les domaines de disponibilité sont des centres de données autonomes indépendants au sein d'une région. Les ressources physiques de chaque domaine de disponibilité sont isolées de celles des autres, ce qui garantit la tolérance aux pannes. Les domaines de disponibilité ne partagent ni infrastructure (par exemple, alimentation, système de refroidissement), ni réseau de domaine de disponibilité interne. Ainsi, il est peu probable qu'un problème survenant dans un domaine de disponibilité affecte les autres domaines de disponibilité de la région.
- Réseau cloud virtuel (VCN) et sous-réseaux
Un VCN est un réseau personnalisable défini par logiciel que vous configurez dans une région Oracle Cloud Infrastructure. Comme les réseaux de centre de données traditionnels, les réseaux cloud virtuels vous donnent un contrôle total sur l'environnement réseau. Un réseau cloud virtuel peut comporter plusieurs blocs CIDR qui ne se chevauchent pas et que vous pouvez modifier après l'avoir créé. Vous pouvez segmenter un réseau cloud virtuel en plusieurs sous-réseaux ciblant une région ou un domaine de disponibilité. Chaque sous-réseau est composé d'une plage contiguë d'adresses qui ne chevauchent pas celles des autres sous-réseaux du réseau cloud virtuel. Vous pouvez modifier la taille d'un sous-réseau après sa création. Un sous-réseau peut être public ou privé.
- Dynamic routing gateway (DRG)
Le DRG est un routeur virtuel qui fournit un chemin pour le trafic réseau privé entre les réseaux cloud virtuels de la même région, entre un VCN et un réseau en dehors de la région, tel qu'un VCN dans une autre région Oracle Cloud Infrastructure, un réseau sur site ou un réseau dans un autre fournisseur cloud.
- VPN site à site
Le VPN site à site fournit une connectivité VPN IPSec entre votre réseau sur site et vos réseaux cloud virtuels dans Oracle Cloud Infrastructure. La suite de protocoles IPSec permet de crypter le trafic IP avant le transfert des paquets de la source vers la destination, puis de le décrypter lorsqu'il arrive.
- Réseau sur site
Ce réseau est le réseau local utilisé par votre organisation. C'est l'un des rayons de la topologie.
- Hôte de bastion
Le bastion est une instance de calcul qui sert de point d'entrée sécurisé et contrôlé vers la topologie à partir de l'extérieur du cloud. Le bastion est généralement provisionné dans une zone démilitarisée (DMZ). Vous pouvez ainsi protéger les ressources sensibles en les plaçant dans des réseaux privés inaccessibles directement depuis l'extérieur du cloud. La topologie comporte un point d'entrée unique et connu que vous pouvez surveiller et auditer régulièrement. Vous pouvez donc éviter d'exposer les composants les plus sensibles de la topologie sans compromettre leur accès.
- Table de routage
Les tables de routage virtuel contiennent des règles pour acheminer le trafic des sous-réseaux vers des destinations en dehors d'un VCN, généralement via des passerelles.
- Liste de sécurité
Pour chaque sous-réseau, vous pouvez créer des règles de sécurité qui indiquent la source, la destination et le type de trafic qui doivent être autorisés vers et depuis le sous-réseau.
- Volume de blocs
Avec les volumes de stockage de blocs, vous pouvez créer, attacher, connecter et déplacer des volumes de stockage, et modifier leurs performances pour répondre à vos exigences en matière de stockage, de performances et d'application. Une fois un volume attaché et connecté à une instance, vous pouvez l'utiliser comme un disque dur classique. Vous pouvez également déconnecter un volume et l'attacher à une autre instance sans perdre de données.
- Identity and Access Management (IAM)
Oracle Cloud Infrastructure Identity and Access Management (IAM) est le plan de contrôle d'accès pour Oracle Cloud Infrastructure (OCI) et Oracle Cloud Applications. L'API IAM et l'interface utilisateur vous permettent de gérer les domaines d'identité et les ressources au sein du domaine d'identité. Chaque domaine d'identité OCI IAM représente une solution de gestion des identités et des accès autonome ou une population d'utilisateurs différente.
- Stockage d'objets
Object Storage fournit un accès rapide à de grandes quantités de données, structurées ou non, de n'importe quel type de contenu, y compris des sauvegardes de base de données, des données analytiques et du contenu enrichi tel que des images et des vidéos. Vous pouvez stocker les données, puis les extraire directement à partir d'Internet ou de la plate-forme cloud, et ce, en toute sécurité. Vous pouvez redimensionner le stockage de manière transparente sans dégradation des performances ni de la fiabilité des services. Utilisez le stockage standard pour le stockage "à chaud" auquel vous devez accéder rapidement, immédiatement et fréquemment. Utilisez le stockage d'archive pour le stockage "à froid" que vous conservez pendant longtemps et auquel vous accédez rarement.
Une fois les clusters GridServer créés, les tests d'évaluation ont été effectués à l'aide d'un cas de la bibliothèque Stata-Examples de OpenGamma. Les tests initiaux ont indiqué que la meilleure combinaison des performances et du prix par rapport aux performances a été obtenue en plaçant le directeur GridServer, les courtiers et les clients sur une seule instance publique, avec des moteurs sur des instances de calcul distinctes. Les formes BM et VM ont été testées pour l'instance Client, Broker et directrice GridServer, sans différence de performances observée. Le tableau ci-dessous fournit une description des clusters testés.
| Forme du moteur | Moteurs par noeud | Noeuds de moteur | Nombre total de moteurs |
|---|---|---|---|
| BM.Optimized3.36 | 36 72* | 4-64 | (4608) |
| BM.Standard.E4.128 | 256* | 4-8 | 2048 |
| BM.Standard2.52 | 52* | 4-8 | (416) |
| VM.Standard.E4.Flex | 128* | 4-8 | 1024 |
L'hyperthreading a été activé ou désactivé sur certains systèmes pendant les tests. Les résultats obtenus lorsque l'hyperthreading est activé sont signalés par un astérisque (*). Dans OCI, un coeur physique est désigné en tant qu'OCPU. Par défaut, GridServer configure un seul moteur par coeur. Lorsque l'hyperthreading est activé, GridServer affecte un moteur à chacun des deux threads principaux, doublant le nombre de moteurs disponibles par noeud. La forme de machine virtuelle, VM.Standard.E4.Flex, peut être configurée avec un nombre variable d'OCPU. Pour nos tests, nous avons configuré chacune des formes avec 64 OCPU (128 moteurs au total avec Hyperthreading activé).
Nos tests ont utilisé GridServer pour effectuer 25 000 analyses OpenGamma uniques, simulant un test de référence Monte Carlo typique. Nous avons obtenu le temps écoulé pour chacun des tests à partir du récapitulatif de travail sur la console GridServer. Nous avons effectué les tests sur chacun des clusters en commençant par utiliser quatre moteurs pour la simulation, puis en doublant le nombre de moteurs par test jusqu'à ce que tous les noeuds exécutant des moteurs dans le cluster soient utilisés. Le graphique ci-dessous présente les résultats de nos tests sur le cluster en fonction de différentes instances de forme.
Ici, les résultats sont affichés dans les évaluations par seconde, la vitesse à laquelle le cluster est en mesure d'effectuer les évaluations de simulation Monte Carlo. Pour chaque référence, cette valeur était simplement le nombre total de simulations (25 000) divisé par le temps écoulé de simulation en secondes. Dans l'ensemble, pour chacun des clusters testés, les performances ont été mises à l'échelle presque linéairement avec le nombre de moteurs utilisés. En termes de performances relatives observées pour les différentes formes d'instance, il y avait une forte corrélation entre les performances du nœud et le nombre de cœurs par forme, indiquant que les performances du moteur par cœur étaient quelque peu invariantes à la forme. Le cluster avec des formes BM.Optmized3.36 a été testé avec Hyperthreading activé et désactivé. Les tests avec d'autres formes ont affiché le même effet avec Hyperthreading préféré, et ces données ont été laissées hors du graphique pour plus de clarté.
Bien que la performance soit un facteur essentiel dans les analyses Monte Carlo à grande échelle, le coût est également un facteur. Nous avons examiné ce point pour les tests ci-dessus en traçant le coût total d'OCI sur le graphique ci-dessous (à l'aide des prix publiés sur le site Web Oracle).
Idéalement, le coût total de la simulation ne doit pas varier en fonction de la taille du cluster, mais les inefficacités parallèles ont tendance à augmenter avec la taille du cluster, ce qui augmente le coût de la simulation. Il existe une hypothèse générale pour toutes les pratiques commerciales selon laquelle il existe un compromis de prix à mesure que la performance s'améliore, et cela n'est pas différent. Nos tests OpenGamma ont montré les formes basées sur l'AMD EPYC (BM.Standard.E4.128, VM.Standard.E4.Flex) offrant à la fois les meilleures performances de nœud et les meilleures performances de prix. Nous encourageons les clients à tester leurs modèles financiers sur OCI avec un essai gratuit de 30 jours, car différents modèles peuvent être mieux adaptés à d'autres formes de calcul hautes performances.