Surge Protection dans Microsoft Fabric

Phare Data

0:03[musique] [musique] Ouais, bonjour et bienvenue sur Fardata, la chaîne qui éclaire vos données. Dans l'océan des données, voir clair change tout. Sur PH data, on décrypte les services de données d'analytique CDIA, le tout avec un ton accessible, des choix techniques assumés et une touche dermare. Que vous soyez architecte, analyse, data, engénieur, productur ou simplement curieux, Fardata vous accompagne pour comprendre les enjeux réels, éclairer les compromis et prendre de meilleures décisions et parfois avec le cri des mouettes en bruit de fond. Si ce genre de contenu vous parle, n'hésitez pas à vous abonner. Cap sur l'épisode du jour, j'ai le plaisir d'être accompagné par Manel et Anne pour évoquer le Surge Protection, un sujet clé quand on parle de gouvernance dans Microsoft fabrique.

Surge Protection

0:59Bonjour. Bonjour. En janvier 2026, Microsoft a fait évoluer ses mécanismes de Surge Protection en introduisant un contrôle au niveau des workspace. Objectif: offrir aux administrateurs de capacité une gouvernance plus fine, mieux protéger les workload critiques et éviter qu'un workspace ne perturbe l'ensemble de la capacité. Avant à workspace pouvait couler toute la capacité, maintenant il coule tout seul. Mais Manel, tu peux nous rappeler ce qu'était le Search Protection avant cette évolution ? Mais bien sûr, avant de parler de la B1 de du Search Protection, il est important de revenir un petit peu aux bases et d'expliquer la consommation des C. En fait, quand on a une F64 par exemple, on a la possibilité de mettre plusieurs projets sur cette capacité. Donc quand on dit plusieurs projets, elle ça peut être réparti sur plusieurs espaces de travail. Mais ce qu'il faut savoir, c'est que quand on a une F64, on a le droit de consommer 64 CU par seconde. Donc on ne doit pas dépasser ce nombre de CU consommé. Donc toutes les requêtes qui tournent sur cette capacité, quelle que soit l'origine de l'espace de travail, que ça soit euh une requête d'axe parce qu'il y a un utilisateur qui a consommé tel ou tel rapport ou une requête un peu plus costaud parce que on a besoin de rafraîchir un modèle sémantique doivent ne doivent pas dépasser euh une un certain nombre de CU sur un intervalle de 30 secondes. Et en fait ce qu'il faut savoir c'est que dans certains cas on peut avoir ce qu'on appelle débat d'acteur, quelqu'un qui a mal développé un rapport, qui n'a pas forcément appliquer les bonnes pratiques. On peut se retrouver avec une seule requête qui elle va consommer l'ensemble des CU de cette capacité. Mais ça ça va impacter tout le reste. Donc on va avoir un bas d'acteur, quelqu'un mauvais élève qui qui sera la cause du throttling ou des ralentissements sur la capacité. Et c'est là où le Search Protection ou la version V1 du Search Protection rentré en jeu, elle consistait à dire "Ben, je vais essayer de traquer la consommation, la surconsommation euh de ma capacité et si elle se rapproche des 100 % ou qui va un petit peu me planter toute la capacité, je vais commencer par rejeter les opérations background. Je vais commencer par rejeter par exemple le refresh d'un modèle sémantique ou un datafow pour ne pas impacter la consommation des du rapport. Donc les actions interactifs. Donc c'est ça la search protection. C'était un paramètre au niveau de la capacité qui consistait à dire ben je ne veux pas attendre 100 % de surconsommation ce qui fera ce qui va un petit peu mettre chao ma capacité. Je mets un tress hold, je mets une limite et si je l'attends, je vais arrêter toutes les opérations background parce que je ne veux pas que l'accès au M rapport soit bloqué. Donc c'est ça la la V1 du Search Protection. Super, merci Manel. Anne, tu as déjà rencontré ce problème chez tes clients ? Oui, bien sûr Romain, ça m'est déjà arrivé. Euh je pense à un client par exemple euh qui utilisait une seule capacité fabrique à la fois pour du reporting réglementaire euh sur lequel il avait euh euh il avait des euh des contraintes critiques en terme de délisé de mise à disposition euh euh de rapport et en même temps qu'il qui qui utilise cette même capacité euh pour du sel

Stratégies de gestions des capacités Fabric

4:08service donc pour des utilisateurs avancés qui pouvaient eux-mêmes construire leur propre rapport et quand on quand les utilisateurs avancés fonctionnent bien travaillent bien ça se passe super bien et puis un jour arrive un utilisateur qui est peut-être moins formé, qui va faire des rapports ou des data flow moins efficaces et et ça impacte directement des processus métiers critiques avec des impacts lourds euh sur sur les processus clients. Ouais. C'est par exemple ce cas qu'on voit à l'écran où sur une même capacité, on a mis du dev, du test, du self service de la production et finalement euh on arrive très vite à l'utilisation de toutes nos ressources de la capacité. Exactement. Et du coup en fait la question qui se pose, qu'est-ce qu'on peut faire quand on a un use case ou un scénario comme ça ? Une seule capacité qui va contenir plusieurs espaces de travail et qui arrive à sa limite ou qui est dans un état de de throatlink. Donc là, on a plusieurs options. Euh généralement, on va recommander la stratégie une qui consiste à demander aux différents développeurs d'aller optimiser leur modèle sémantique et leur apport. Donc quand on parle d'optimisation, on va euh parler un petit peu des principes de base, suivre une modélisation star schima, ne pas ajouter des colonnes juste au cas où, euh prêter attention au format des données. Euh donc tout ça rentre dans la partie optimisation et pour ça en fait euh vous avez la possibilité d'utiliser plusieurs outils euh un petit peu comme le DAX Studio qui est qui est le maître outil pour optimisation des requêtes d'Ax. Mais aujourd'hui, avec l'arrivée de l'IA et l'arrivée des LLM, on a euh des outils euh qui peuvent réellement nous aider euh dans cette vibe optimisation de Power BI comme par exemple l'utilisation d'un MCP serveur sur Power BI Model Link. On va lui demander directement d'optimiser telle ou telle requête taxe ou alors demander euh à exécuter un best practice analyser sur un modèle sémantique et ça nous ressort avec une liste de suggestions pour mieux optimiser et réduire la consommation des CU. de ce modèle sémantique. Donc bien évidemment, cette approche et euh son coût euh elle est facile à mettre elle est plus ou moins facile à mettre en place. Ça demande bien évidemment une formation. Par contre euh le pas le point négatif mais le compromis c'est euh le temps euh parce que c'est quand même une action de fond où il faut aller se rapprocher des différents espaces de travail owner pour les aider et les accompagner dans l'optimisation. ce qui peut prendre plus de temps euh dans certains contextes et c'est ça Infin après optimisation qui va nous permettre de consommer moins de CU et du coup de faire rentrer ces quatre espaces de travail qui sont illustrés dans la même capacité. Donc ça c'est une option parmi d'autres. Ouais. Sur l'optimisation, on peut citer le fait que on peut optimiser après coup ou avoir des gardes de foot dès l'entrée, à savoir je ne permets pas qu'on publie sur ma capacité du sémantique modèle qui aurait pas été vérifié sur un certain nombre de bonnes pratiques en amont, hein. On peut on peut mettre des gardes de fou dès l'entrée aussi, si c'est possible. en plus d'éduquer comme tu l'as cité les différents développeurs. Une alternative et un peu la deuxième stratégie dans ce cas-là quand on arrive aux limites de l'optimisation parce que ça arrive forcément à un moment donné euh ça va être la solution simple. Bah j'augmente ma capacité si j'ai plus la place dans ma capacité. C'est ce qu'on appelle le scalup. Donc l'avantage c'est que immédiatement on va avoir plus de place pour exécuter mes workload. Euh on peut euh quand on est sur une capacité premium euh activer l'autoscale. On peut mettre en place un quand on a une une capacité fabrique, on peut instantanément augmenter sa taille en tout cas pour pour absorber ce ce pic de charge. Euh et donc ça permet euh très rapidement de répondre au problème. l'inconvénient, bah le premier c'est forcément le coût, c'est forcément plus cher. Et puis bah c'est pas ça va pas sur le long terme, ça va pas apprendre aux personnes qui ont mal développé ou problèmes. On rentre pas dans un circle cercle vertueux, on a plutôt tendance au contraire à laisser libre cours à des des des problématiques de de de développement et de conception des items. Une autre stratégie consisterait non pas faire du scalup mais du scalout, c'est-à-dire multiplier le nombre ben de capacités euh avec les coûts bien évidemment associés, mais ça va permettre aussi d'isoler euh les différentes capacités et donc isoler les bas d'acteurs. J'ai des entreprises, des organisations avec lesquelles je travaille ont des capacités pour le self service et du coup si euh le self service ben ne travaille pas convenablement, ils seront eux-mêmes impactés et non pas la capacité de production qui elle permettra toujours de répondre aux enjeux majeurs de l'organisation. Mais alors du coup Romain, si on a vraiment des des traits des des items qui sont enfin des data flow ou des rapports qui consomment naturellement beaucoup de CU même s'ils sont optimisés, on va pouvoir les isoler, on va pouvoir avoir une approche même en amont hein d'un projet. On peut imaginer que je crée une capacité de test pour mon projet. Comme ça, j'évalue la charge en terme de CU que ce projet va générer et donc après évaluer sur quelle capacité la créer ou le déplacer. Finalement, on a différents moyens d'isoler et voilà, on retrouve chez différentes organisations différents euh stratégie. Euh, on peut imaginer une capacité qui est toujours là euh en terme de rescue et donc on déplacerait nos workspace en fonction euh de ça pour pouvoir permettre toujours à ces workspace de répondre à la demande, hein. Il y a différentes stratégies à vous organisation d'adopter celle qui vous convient le plus. Ouais. et peut-être un peu plus de précision sur la stratégie tryout capacité. Il y avait un un on avait réalisé euh il y a quelques mois sur la chaîne Datachouette une vidéo qui montrait euh comment on peut utiliser le sémantique Linklab pour vérifier si un modèle sémantique applique les bonnes pratiques ou si le modèle sémantique a bien appliqué ou si euh il a bien on a bien partitionné ses tables correctement, on a bien mis en place le format des données correctement et ça en fait on peut le mettre dans une capacité pour dire "Ah tiens, j'ai une capacité plus petite. qui n'est pas de production où j'ai la possibilité de développer, je mets un système justement grâce au canticlab pour vérifier si les bonnes pratiques ont été appliquées et si c'est le cas, je vais le mettre dans la capacité de production qui est la plus de compute. Donc c'est un système de tryoutte capacité pour le développement et une fois que ça valide entre

Demo

10:46guillemets les règles, je les je leur donne la possibilité d'aller consommer des ressources dans une capacité plus grosse de production. Alors c'est c'est super et c'est des bonnes pratiques, Manel, mais ça demande énormément de travail. préparatif, d'administration, d'anticipation et on n' pas toujours la possibilité d'avoir euh la vision de ces choses là à l'avance. Effectivement et c'est pour ça qu'on on va introduire une autre stratégie qui est le Search Protection. En effet, on va parler maintenant du Search Protection et on va parler du Search Protection d'abord la version 1 qui est au niveau du capacity level, sachant que c'est additionnel avec la V2, on en parlera tout à l'heure. Donc la V1 va nous permettre de limiter les activités background sur notre capacité. à partir d'un seuil. Et donc on voit sur cette image par exemple alors qu'on a configuré le background euh rejection, on va lorsque la surge protection s'active et ben ne plus prendre en charge les activités background, ce qui va donc laisser un peu plus de marge aux activités interactives. Et on voit un deuxième cas où ici le surge protection s'est activé et donc a limiter l'impact des rafraîchissement par exemple sur les activités interactives de type requête d'Ax qui permet toujours à des utilisateurs d'accéder au rapport même si les données n'ont pas été rafraîchies. Ça peut faire sens dans certains cas. Et maintenant, on va donc évoquer en détail le Surge Protection V2 qui est actuellement preview. Et on voit qu'il est cumulatif avec le background operation qu'on connaissait avec la V1. C'est un une tuile aussi qu'on peut activer. Et là, on va donner un seuil pour l'ensemble des workspace de la capacité. C'est-à-dire ici, on voit 5 %. L'ensemble des workspace, un workspace ne devrait pas pouvoir excéder 5 % de consommation de la totalité du CU. aussi bien pour les activités interactives que background. Et à nos workspace, on a trois niveaux de statut. Soit il est available, c'est-à-dire sujet à la rejection, soit il est mission criticole et à ce moment-là, il sera jamais sujet à la rejection. Par exemple, on a un workspace où c'est pour la direction, on ne veut pas qu'il soit limité. Ou encore un workspace peut-être bloqué et là bloqué soit manuellement, soit automatiquement. automatiquement s'il a atteint le seuil, manuellement, si je décide manuellement comme on le voit en bas à droite de euh cocher le bloquet pour un workspace. Mais du coup, qu'est-ce qui se passe quand un espace de travail est bloqué ? Euh est-ce qu'on a un moyen de voir euh la liste des espaces de travail qui sont bloqués ? Oui. Alors, juste à cause du surprction, la MRI SAAP a été mise à jour récemment pour permettre aux administrateurs de capacité de voir le nombre de workspace bloqué sur une capacité. Et si je fais un drill down, j'aurai tout le détail dans le temps. Euh aussi bien des euh workspace bloqués manuellement qu'automatiquement dû au seuil qui a été atteint. Alors, regardons une démonstration où là j'ai un workspace en business critical et là je veux pas le limiter. J'ai un workspace en self service bi que j'ai bloqué et j'ai un workspace en def test qui lui va pouvoir s'agrandir mais tout en restant dans la limite des 5 % que tous les workspace sur la capacité hormis ceux qui sont critical pourront consommer. Rappelons hein, c'est la consommation des actif background et interactif. Donc imaginons que j'ai une F2. Une F2 me donne 60 CU que je peux consommer tous les 30 secondes. Ces fameux time point ce qui me donne 172800 CU que je peux consommer dans la journée. Si je fais le ratio des 5 %, ça va me donner que chacun des workspace ne peuvent pas excéder la consommation de 8640 CU par jour. Et donc ça, on peut le consommer en une seconde, soit on peut le consommer en 24 heures. Mais si le workspace atteint cette limite, il passera automatiquement bloqué. Regardons une démonstration. Et alors, ben toujours sur la MTRI, je vais pouvoir voir euh par exemple pour ce workspace qu'on a atteint les 11000. Et donc au niveau du workspace, l'utilisateur lui sera aussi averti à savoir il aura un bandeau au-dessus du nom du workspace qui lui indiquera que ce workspace a atteint son seuil limite. On va regarder une démonstration. Donc je suis sur ici ma capacité que j'ai choisi de mettre en F2 pour des besoins de démo, hein, pour montrer rapidement que j'atteins le seuil défini. Je suis sur une capacité que j'ai appelé surge et j'ai trois workspace, les fameux trois workspace qu'on a cité. Je vais pouvoir regarder si ils sont leur statut. Donc available, mission criticale ou blocket. Donc le business critical en mission criticale, le surge de test en available et donc sujet la limite que je vais donner et vous voyez que je bloque le self service. On va voir qu'est-ce que ça génère après comme erreur. Je vais au niveau du sechge protection et je vois que je peux activer soit la V1, soit la V2, la background ou les deux d'un coup. Et ici, je choisis de mettre les 5 % et de bloquer. On voit que j'ai une fenêtre de blocage aussi ici à définir. Ça va être le temps euh auquel mon workspace sera bloqué. OK. Maintenant, on va aller regarder ces différents workspace. On va commencer par celui qui est bloqué pour voir l'erreur que qu'on a. On va aussi pouvoir regarder la métrix après coup. Donc si je vais dans le workspace qui est déjà bloqué, c'est notre self service. Si j'essaie d'ouvrir un rapport comme un utilisateur le frais, il voit directement un nouveau message d'erreur en lui indiquant ben que l'administrateur a mis des limites et que les limites ont été atteintes pour ce workspace. Le message était est plutôt clair. Maintenant, si je vais sur un autre workspace, alors qu'on est sur la même capacité, hein, euh je vais pouvoir voir différentes choses. Par exemple, ici, je suis sur le def test, je vois que j'ai pas de limite. OK, vous imaginez ce que je vais vouloir faire ? Je vais créer du workload, exécuter des workloads sur mon def test pour atteindre les limites. Là, je regarde Search Protection et on voit que le Search Protection, bon je peux faire plein d'activités, jamais il ne sera limité, hormis peut-être des limites du Surge Protection V1 sur les activités background, hein, puisqu'ils sont tous sujets à ça. Et donc si je regarde maîtr, je vois actuellement j'ai un seul workspace qui est bloqué à savoir celui que j'ai bloqué manuellement. Jusqu'ici tout est clair ? Jusque là c'est très clair. OK maintenant on revient sur notre surge def test et j'ai chargé la mule. Je lui ai fait travailler. Je lui demande un certain nombre de rafraîchissements des rafraîchissements costaud jusqu'à atteindre le fait que dans pas longtemps je vais plus pouvoir effectuer d'activité sur celui-ci. OK. À quoi ça va ressembler ? Vous voyez là, c'était un peu la fin. J'ai atteint la limite et ben je retrouve le même message d'erreur que j'avais lorsqu'il était bloqué manuellement sur l'eau de capacité. Encore une fois, là je n'ai pas j'ai toujours mes fonctionnalités sur mon business critical. Lui, il n'est pas impacté. En rafraîchissant la métrix SAP, je vais pouvoir voir voilà même mes rafraîchissements he que ce soit les activités interactive ou background seront sujets à cette limitation. Et là on voit le le message d'erreur lorsque j'effectue une activité de type background. Maintenant si on regarde la matrix, je vois deux workspace bloqués. Si je drill down, je vais avoir le détail des workspace bloqués sur la capacité surge et je vais donc voir mes deux workspace. l'un bloqué manuellement et l'autre bloqué automatiquement avec le nombre d'utilisateurs affectés. C'est plutôt intéressant nombre de CU que la capacité que le workspace a utilisé. Et on voit ici les limites du fait que mon workspace qui consommait trop à savoir le def test et ben comme il a été limité ben j'atte pas les limites de ressources de ma capacité. C'est ça qui faut avoir en tête. Donc c'est plutôt intéressant. Et puis après je peux voir le détail comme on connaît des usages de ma capacité. Ce qui est intéressant de regarder aussi, c'est au niveau des notification. C'est à ce niveau-là que je vais définir OK, tu m'afficheras une bannière lorsque tu auras atteint les limites, ce qui permettra aux utilisateurs finaux alors qu'ils ont pas besoin d'ouvrir un rapport pour voir que la capacité le workspace est bloqué. H et donc si je retourne sur mon workspace, je vais pouvoir voir directement le petit message d'erreur qui est le suivant.

Considérations et limites

19:52Mais du coup Romain, comment qu'est-ce qui peut nous aider à mettre le bon seuil de blocage ? Là durant ta sur ta démonstration, tu as mis 5 % mais dans un scénario de production, qu'est-ce qu'on peut mettre qu'en pourcentage ? Ouais. Alors très bonne question. Ben déjà la MRIX SAP va pouvoir nous renseigner sur la consommation des items et donc la consommation d'un workspace. On pourrait aussi utiliser le chargeback reporting qui donne déjà en pourcentage l'usage d'un workspace sur une capacité. Donc je pense que je commencerai comme ça et puis après je ferai attention, je mettrai pas 5 % on comprend bien mais je mettrai peut-être 80 %. un workspace qui consomme 80 % de ma capacité, c'est peut-être il est peut-être déjà trop courmand et donc je descendrai comme ça petit à petit euh en faisant du test and learn comme tu l'as cité. Ouais. Alors comme toute fonctionnalité, elle arrive avec des limitations ou en tout cas des choses auxquelles il faut il faut avoir conscience avant de la mettre en œuvre. Euh la première, c'est ça s'applique pas forcément à tous les items et donc il y a des items qui ne sont pas euh support qui ne supportent pas en tout cas qui qui ne rentrent pas dans le calcul de la consommation de euh de la capacité euh pour le Search protection comme les datas flogè 2, les rapports paginés, les scorecard, les modèles graphes, des data activator ou même des datas flow 2 quand on les édite, donc quand on vient créer ou modifier un datafow gè 2. Le deuxième deuxème point à avoir en tête, c'est qu'on vient vérifier toutes les 5 minutes la consommation de la de la capacité. Ça veut dire que si on consomme 100 % de la capacité en moins de 5 minutes, la search protection n'aura pas le temps de se déclencher. Euh mais aussi et ça c'est important euh l'applic la les vérifications euh se font sur période de 24 heures. Ça veut dire que je peux si j'ai 8000 disponible pour mon pour mon workspace, je peux je peux les consommer en 5 minutes ou plusieurs fois en 24 he mais c'est la limite va s'appliquer sur par fenêtre glissante de 24 he enfin si j'ai surconsommé et que mon workspace est bloqué pour pouvoir venir débloquer mon workspace je vais être soit obligé d'attendre la fin de la période d'expiration qui a été mise paramètre par l'administrateur, soit je vais devoir demander à l'administrateur d'agir manuellement pour venir débloquer mon workspace. Ouais. Et on peut rappeler aussi que le mission critical ne remplace pas au niveau de la capacité le surge protection au niveau des background hein. C'est additionnel. C'est c'est aussi à voir avoir en tête. Et si je peux rajouter une limitation qui n'est pas forcément une, on a tendance à penser que le Search Protection va bloquer les requê en cours qui consomme justement plus de CU. Ben le Search Protection en fait, il va commencer à arrêter ou à bloquer les requêtes qui viennent après. Donc on va jamais interrompre une requête qui est déjà lancée, qui est en cours. On va plutôt commencer le blocage des requêtes interactives ou background. euh une fois qu'on détecte qu'on détecte que justement un espace de travail a atteint le seuil. Donc ça vient après.

Conclusion

22:57Super. Merci Anne. Merci Manel. On comprend un peu mieux ce qu'est le Surge Protection. Si vous avez questions, n'hésitez pas à nous le faire savoir, des retours d'expérience aussi. Si on doit creuser un point en particulier, n'hésitez pas à nous le faire savoir dans les commentaires. Encore une fois, merci pour cet échange et on vous dit à très vite pour de nouveaux épisodes et d'ici là, n'hésitez pas à vous abonner à la chaîne. À bientôt. À bientôt. Bientôt.