Table des matières
1. Stratégie produit et mesures de réussite
Avant de concevoir l'infrastructure, commencez par le cas d'utilisation métier et la stratégie produit :
- Cas d'utilisation métier = quel problème vous souhaitez résoudre
- Stratégie produit = comment le produit va résoudre le problème
Exemple:
- Cas d'utilisation : proposez des recommandations de produits personnalisées pour augmenter les ventes
- Stratégie : créez un système de recommandation basé sur l'IA qui apprend du comportement des utilisateurs
Le succès doit être mesuré à l’aide de mesures à la fois commerciales et techniques.
KPI commerciaux
- Coût total de possession (TCO)
- Retour sur investissement (ROI)
- Délai de mise sur le marché / agilité
- Revenu
- Utilisateurs actifs mensuels
KPI techniques
- Disponibilité / temps de fonctionnement
- Temps de réponse
- Taux d'erreur
- Saturation
- Temps moyen de récupération (MTTR)
Les KPI commerciaux mesurent directement les résultats commerciaux. Les KPI techniques montrent si l'architecture prend en charge ces résultats.
2. Optimisation des coûts
L'optimisation des coûts consiste à obtenir la meilleure valeur, et pas seulement à réduire les dépenses :
- Valeur = résultats commerciaux obtenus par rapport aux ressources consommées
- Optimisation des coûts = éliminer le gaspillage, dimensionner correctement et choisir les bons modèles de tarification
Exemple:
- Problème : VM inactives fonctionnant 24h/24 et 7j/7 sans charge de travail
- Optimisation : arrêtez-les, planifiez-les ou utilisez la mise à l'échelle automatique
Les décisions en matière de coûts doivent tenir compte à la fois des factures cloud directes et des frais généraux opérationnels.
Pratiques de base
- Ne payez pas pour les ressources inutilisées (par exemple, les machines virtuelles inactives).
- Calcul, niveaux de stockage et capacité adaptés.
- Utilisez les machines virtuelles Spot pour les charges de travail tolérantes aux pannes.
- Utilisez les remises sur engagement d’utilisation lorsqu’une utilisation prévisible existe.
Coût total de possession
Évaluez toujours le coût total de possession. Une configuration non gérée moins chère peut coûter globalement plus cher si elle nécessite un personnel opérationnel important. Dans les scénarios d’examen, une faible charge d’administration indique généralement des services gérés.
Visibilité des coûts
- Utilisez les rapports Cloud Billing et l'exportation de facturation BigQuery pour l'analyse.
- Utilisez des étiquettes/tags pour l’attribution et la rétrofacturation.
- Configurez les quotas, les budgets et les alertes.
Les budgets ne plafonnent pas automatiquement les dépenses. Les alertes vous avertissent, mais les ressources continuent de fonctionner à moins que vous n'agissiez.
3. Prise en charge de la conception d'applications
Les décisions d'architecture doivent inclure des exigences non fonctionnelles :
- Style d'architecture (monolithe vs microservices)
- Évolutivité, performances, fiabilité
- Sécurité et conformité
- Modèle de données et comportement de stockage
Exemples de conception par modèle d'architecture
- Microservices : GKE + Apigee
- Application Web monolithique : Cloud Run ou App Engine
- Charges de travail par lots : Compute Engine, Batch, Dataproc
- Basés sur les événements : Pub/Sub, Eventarc, fonctions Cloud Run
Pratiques d’évolutivité, de performances et de fiabilité
- Déployez sur plusieurs zones.
- Éliminez les points de défaillance uniques.
- Utilisez une infrastructure élastique/évolutive.
- Préférez les services gérés lorsque cela est possible.
- Placez les ressources à proximité des utilisateurs.
- Choisissez les bons niveaux de performances.
Pratiques de sécurité et de conformité
- Chiffrez les données au repos et en transit.
- Utilisez IAM avec le moins de privilèges.
- Appliquez des garde-fous avec la stratégie de l’organisation.
- Configurez les pare-feu VPC et les périmètres de service.
Considérations sur le modèle de données
- Choisissez le stockage en fonction du type de données et des modèles d'accès.
- Configurez la sauvegarde et la récupération à un moment donné.
- Appliquez des contrôles d’accès et un cryptage pour les données sensibles.
4. Intégration avec des systèmes externes et déplacement de données
Les intégrations sont généralement :
- Privé (systèmes que vous possédez)
- Public (systèmes tiers/SaaS)
Options d'intégration privées
- VPN IPsec / Cloud Interconnect (connectivité hybride)
- Appairage de VPC
- Connexion au service privé
- API authentifiées
- Pub/Sous
- Fusion de données cloud
Options d'intégration publique
- Accès Internet (par exemple via Cloud NAT)
- API partenaires authentifiées
- Points de terminaison Private Service Connect
- Pub/Sous
Mouvement des données et temps de transfert
La durée du transfert dépend de :
- Taille des données
- Bande passante réseau
Exemple : le transfert de 10 To peut varier considérablement (heures ou minutes) en fonction de la bande passante.
Services de transfert de données Google Cloud
Service de transfert de stockage
- Transfère des données sur Google Cloud, AWS, Azure et sur site
- Chiffre les données en transit
- Utilise des sommes de contrôle pour l'intégrité
- Prend en charge les transferts incrémentiels et planifiés
Appareil de transfert
- Appareil physique, de grande capacité et inviolable
- Module de plateforme sécurisée et contrôles d'attestation
- Cryptage AES-256
- Disponible en tailles 7 To, 40 To et 300 To
« gsutil » (CLI Cloud Storage)
- Déplacer/copier/renommer des objets
- Transferts multithreads
- Téléchargements composites pour fichiers volumineux
Conseils de sélection rapide des services
- Transferts de fournisseur cloud à cloud : service de transfert de stockage
- Petits transferts sur site (< 1 To) :
gsutil - Transferts sur site plus importants (> 1 To) : service de transfert de stockage ou appliance de transfert (en fonction de la bande passante)
- Petits transferts interrégionaux Cloud Storage (< 1 To) :
gsutil - Transferts plus importants entre régions Cloud Storage (> 1 To) : service de transfert de stockage
Services de migration de bases de données
- Service de migration de base de données : migrez MySQL/PostgreSQL/Oracle/SQL Server vers Cloud SQL ou AlloyDB, avec réplication continue en option pour réduire les temps d'arrêt.
- Service de transfert de données BigQuery : déplacez des données provenant de sources telles que Cloud Storage, Amazon S3, Teradata et bien plus encore vers BigQuery ; prend en charge les transferts récurrents programmés.
5. Compromis entre les décisions d'achat et de construction et de conception
La plupart des décisions architecturales sont des compromis :
- Performance vs coût
- Sécurité vs flexibilité
- Fiabilité vs agilité
- SQL (cohérence) vs NoSQL (évolutivité/flexibilité)
Certaines décisions sont contraintes :
- Exigences réglementaires (par exemple, résidence des données)
Certaines décisions sont clairement favorables :
- Une option moins chère qui répond toujours à toutes les exigences
Raisons d'acheter
- Réduction des frais opérationnels
- Produit potentiellement plus mature
- Des modèles de tarification plus prévisibles
Raisons de construire
- Plus de personnalisation et de contrôle
- Meilleure intégration interne
- Amortissement potentiel des coûts à long terme
Refactoriser ou prendre sa retraite
Refactoriser quand :
- L'ensemble des fonctionnalités peut être étendu
- L'expertise existante est précieuse
- Un retour sur investissement positif est attendu
Prenez votre retraite quand :
- Le système est obsolète ou de faible valeur
- Un résultat équivalent est disponible à moindre coût
- La pile existante est trop chère/risquée à moderniser
6. Conformité et observabilité
L'utilisation de Google Cloud ne rend pas automatiquement une charge de travail conforme.
Ressources clés :
- Centre de ressources de conformité
- Responsable des rapports de conformité
Considérations courantes en matière de conformité :
- Chiffrement au repos et en transit
- Contrôle d'accès IAM avec moindre privilège
- VPC Service Controls pour les limites sensibles
- Stratégie de journalisation et de rétention des audits
- Sélection de région et résidence des données
Surveillance vs observabilité
- Surveillance : vous indique *si* quelque chose ne va pas (indicateurs prédéfinis)
- Observabilité : vous aide à comprendre *pourquoi* cela ne va pas et comment y remédier
Trois piliers d'observabilité :
- Mesures (santé/performance)
- Journaux (événements/contexte)
- Traces (flux de demandes et goulots d'étranglement)
Mappages de Google Cloud Operations Suite :
- Métriques : surveillance du cloud/service géré pour Prometheus
- Journaux : journalisation dans le cloud
- Traces : trace cloud
Types de journaux d'audit cloud
- Journaux d'activité d'administration : activés par défaut, ne peuvent pas être désactivés
- Journaux des événements système : activés par défaut, ne peuvent pas être désactivés
- Journaux d'accès aux données : désactivés par défaut, doivent être activés ; peut entraîner des coûts d’ingestion importants
.png)
0 Comments