Publishing Site tech.tf1.fr at 61c92e3 on Mon Dec 16 10:26:09 UTC 2024

post/2024/iops/cost-optimisation/index.html

@@ -7,7 +7,7 @@
 <script src=/js/collapseAuthors.js></script>
 Publié le 16 décembre 2024 • 14 minutes</div></div></header><div class=article-hero-image id=ArticleImage__Hero><img src=/post/2024/iops/cost-optimisation/images/hero.jpg></div></div></section><aside id=progressBar class=aside-container><div class=aside-align><div><div class=overlap-container></div></div></div><div class=progress-container tabindex={-1}><div class=track-line aria-hidden=true><div id=progressIndicator class=progress-line></div></div></div></aside><article id=articleContent class=post-content style=position:relative><h2 id=la-plateforme-etf1>La plateforme eTF1</h2><p>Chez TF1, la plateforme eTF1 rassemble les marques clés TF1+, TF1 Info, et TfouMax. Pour répondre aux besoins de scalabilité rapides, notamment lors de grands événements sportifs et de pics d&rsquo;audience, nous avons entrepris une démarche globale visant à rendre notre infrastructure plus dynamique, plus résiliente, et plus éco-responsable.</p><h3 id=une-infrastructure-moderne-hébergée-principalement-sur-le-cloud>Une infrastructure moderne hébergée principalement sur le cloud</h3><p>Notre plateforme repose en grande partie sur des clusters Kubernetes sur lesquels tous nos applicatifs sont déployés. A cela sont associés plusieurs services managés autour de la data, tels que RDS, Elasticache, S3, MSK et OpenSearch.</p><p>L&rsquo;infrastructure est déployée as-code via Terraform associé à <a href=https://terragrunt.gruntwork.io/>Terragrunt</a> pour la factorisation de code et <a href=https://www.runatlantis.io/>Atlantis</a> pour la CI/CD.</p><p>Toutes les ressources Kubernetes de nos cluster sont managées en GitOps via <a href=https://argo-cd.readthedocs.io>ArgoCD</a>. Nous sommes également utilisateurs d&rsquo;un certains nombre d&rsquo;opérateur kubernetes de la communauté, parmis eux : <a href=https://prometheus-operator.dev>prometheus operator</a>, <a href=https://cert-manager.io/>cert-manager</a>, <a href=https://kubernetes-sigs.github.io/external-dns>external-dns</a>, <a href=https://external-secrets.io/>external-secrets</a>, <a href=https://kyverno.io/>kyverno</a>, <a href=https://docs.stakater.com/reloader/>reloader</a>, &mldr;</p><p>L&rsquo;essentiel de cette infrastructure est hébergé sur le cloud AWS, bien que nous ayons aussi une partie on-premise, notamment avec un CDN interne pour la diffusion video.</p><h2 id=une-plateforme-de-production-élastique>Une plateforme de production élastique</h2><h3 id=un-trafic-qui-évolue-en-fonction-des-programmes-et-de-lactualité>Un trafic qui évolue en fonction des programmes, et de l&rsquo;actualité</h3><p>L&rsquo;audience de eTF1 varie au cours de la journée, avec des pics le soir et un trafic réduit la nuit. Des programmes phares tels que <code>Koh Lanta</code> ou <code>The Voice</code> génèrent d&rsquo;importants volumes d’utilisateurs, tout comme les événements sportifs majeurs.</p><p>Par exemple, la Finale de coupe du monde de foot 2022​ en chiffres​
 ​- ​2.4 millions d&rsquo;utilisateurs (source Mediametrie)​</p><ul><li>3.6Tbps en pic​</li><li>500 000 créations de compte​</li><li>576 000 rps (mesure CDN)​</li><li>30 000 rps (services backend)</li></ul><p>De plus selon les composants applicatifs, les patterns de trafic peuvent être réellement différents.
-<img src=images/profil_traffic_foot.png#darkmode alt="Profil de traffic match de foot" title="Illustration des profils de traffic lors d'un match de foot"></p><p>Ces pics de trafic, parfois prévisibles comme lors des matchs de foot ou de l&rsquo;annonces de résultats électoraux, peuvent aussi survenir de manière inattendue.</p><p>Exemple, sur le graphe suivant du 9 juin 2024, le jour des élections européennes, un pic important s’est ajouté à celui attendu de l&rsquo;annonce des résultats : l&rsquo;annonce de la dissolution de l’Assemblée Nationale.</p><p><img src=images/pic-dissolution.png#darkmode alt="Pic de traffic dissolution" title="Illustration d'un pic de traffic le jour de la dissolution de l'assemblée nationale le 9 juin 2024"></p><p>La plateforme doit pouvoir répondre avec un niveau de service satisfaisant​ en toutes circonstances, mais nous devons faire cela en maitrisant nos coûts. C&rsquo;est pourquoi nous avons du mettre un oeuvre un certain nombre de stratégies de scaling de la plateforme.</p><h3 id=scaling-des-clusters-avec-karpenter>Scaling des clusters avec Karpenter</h3><p><img src=images/karpenter.png#darkmode alt=karpenter title="Logo karpenter"></p><p>Pour répondre à ces variations de demande au niveau des cluster EKS, nous avons déployé <a href=https://karpenter.sh/>Karpenter</a>, un outil d&rsquo;autoscaling qui permet de provisionner automatiquement des nœuds Kubernetes en fonction des besoins des pods. Celui ci remplace cluster-autoscaler.</p><h4 id=les-atouts-de-karpenter->Les atouts de Karpenter :</h4><ul><li><strong>Évaluation automatique des contraintes</strong> : Karpenter détecte les pods &ldquo;Unschedulable&rdquo;, et répartit les pods en respectant les anti-affinités et les besoins de ressources.</li><li><strong>Configuration native Kubernetes</strong> : Basée sur des CRDs, Karpenter permet d’ajuster les instances en combinant SPOT et OnDemand pour une meilleure gestion des coûts et des interruptions.</li><li><strong>Visibilité améliorée</strong> : Grâce à Karpenter, nous avons une vision claire de la répartition des nœuds et de la diversité des instances.</li><li><strong>Consolidation des noeuds</strong> : Karpenter consolide en permanence le cluster pour assurer une utilisation optimale des noeuds en fonction des requests (CPU/RAM) des pods déployés ainsi que du prix des instances EC2.</li></ul><p>L&rsquo;image suivante créé avec eks-node-viewer est un extrait de notre cluster de production. Elle illustre bien :</p><ul><li>la diversité des types d&rsquo;instance</li><li>l&rsquo;utilisation d&rsquo;instances spot</li><li>la consolidation que fait karpenter pour remplir les noeuds</li></ul><p><img src=images/eks-node-viewer.png#darkmode alt=EKS-node-viewer title="Illustration du remplissage et de la diversité des noeud par kapenter"></p><p>Voici une exemple proche de la configuration des CRD Karpenter que nous utilisons. On peut voir :</p><ul><li>Une ressource <code>EC2NodeClass</code> qui définit les caractéristiques des instances des noeuds</li><li>Une ressource <code>NodePool</code> qui utilise l&rsquo;EC2NodeClass et définit les contraintes du nodepool en termes de limties, de consolidation ainsi que de choix d&rsquo;instance type.</li></ul><div class=highlight><pre tabindex=0 style=color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4><code class=language-yaml data-lang=yaml><span style=display:flex><span>---
+<img src=images/profil_traffic_foot.png#darkmode alt="Profil de traffic match de foot" title="Illustration des profils de traffic lors d'un match de foot"></p><p>Ces pics de trafic, parfois prévisibles comme lors des matchs de foot ou de l&rsquo;annonces de résultats électoraux, peuvent aussi survenir de manière inattendue.</p><p>Exemple, sur le graphe suivant du 9 juin 2024, le jour des élections européennes, un pic important s’est ajouté à celui attendu de l&rsquo;annonce des résultats : l&rsquo;annonce de la dissolution de l’Assemblée Nationale.</p><p><img src=images/pic-dissolution.png#darkmode alt="Pic de traffic dissolution" title="Illustration d'un pic de traffic le jour de la dissolution de l'assemblée nationale le 9 juin 2024"></p><p>La plateforme doit pouvoir répondre avec un niveau de service satisfaisant​ en toutes circonstances, mais nous devons faire cela en maitrisant nos coûts. C&rsquo;est pourquoi nous avons du mettre un oeuvre un certain nombre de stratégies de scaling de la plateforme.</p><h3 id=scaling-des-clusters-avec-karpenter>Scaling des clusters avec Karpenter</h3><p><img src=images/karpenter.png#darkmode alt=karpenter title="Logo karpenter"></p><p>Pour répondre à ces variations de demande au niveau des cluster EKS, nous avons déployé <a href=https://karpenter.sh/>Karpenter</a>, un outil d&rsquo;autoscaling qui permet de provisionner automatiquement des nœuds Kubernetes en fonction des besoins des pods. Celui ci remplace cluster-autoscaler.</p><h4 id=les-atouts-de-karpenter->Les atouts de Karpenter :</h4><ul><li><strong>Évaluation automatique des contraintes</strong> : Karpenter détecte les pods &ldquo;Unschedulable&rdquo;, et répartit les pods en respectant les anti-affinités et les besoins de ressources.</li><li><strong>Configuration native Kubernetes</strong> : Basée sur des CRDs, Karpenter permet d’ajuster les instances en combinant SPOT et OnDemand pour une meilleure gestion des coûts et des interruptions.</li><li><strong>Visibilité améliorée</strong> : Grâce à Karpenter, nous avons une vision claire de la répartition des nœuds et de la diversité des instances.</li><li><strong>Consolidation des noeuds</strong> : Karpenter consolide en permanence le cluster pour assurer une utilisation optimale des noeuds en fonction des requests (CPU/RAM) des pods déployés ainsi que du prix des instances EC2.</li></ul><p>L&rsquo;image suivante créé avec eks-node-viewer est un extrait de notre cluster de production. Elle illustre bien :</p><ul><li>la diversité des types d&rsquo;instance</li><li>l&rsquo;utilisation d&rsquo;instances spot</li><li>la consolidation que fait karpenter pour remplir les noeuds</li></ul><p><img src=images/eks-node-viewer.png#darkmode alt=EKS-node-viewer title="Illustration du remplissage et de la diversité des noeud par kapenter"></p><p>Voici une exemple proche de la configuration des CRD Karpenter que nous utilisons. On peut voir :</p><ul><li>Une ressource <code>EC2NodeClass</code> qui définit les caractéristiques des instances des noeuds</li><li>Une ressource <code>NodePool</code> qui utilise l&rsquo;EC2NodeClass et définit les contraintes du nodepool en termes de limites, de consolidation ainsi que de choix d&rsquo;instance type.</li></ul><div class=highlight><pre tabindex=0 style=color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4><code class=language-yaml data-lang=yaml><span style=display:flex><span>---
 </span></span><span style=display:flex><span><span style=color:#f92672>apiVersion</span>: <span style=color:#ae81ff>karpenter.k8s.aws/v1beta1</span>
 </span></span><span style=display:flex><span><span style=color:#f92672>kind</span>: <span style=color:#ae81ff>EC2NodeClass</span>
 </span></span><span style=display:flex><span><span style=color:#f92672>metadata</span>:
@@ -82,7 +82,7 @@
 </span></span><span style=display:flex><span>        - <span style=color:#ae81ff>c</span>
 </span></span><span style=display:flex><span>        - <span style=color:#ae81ff>m</span>
 </span></span><span style=display:flex><span>        - <span style=color:#ae81ff>r</span>
-</span></span></code></pre></div><p>Si une chose est à retenir avec l&rsquo;utilisation de Karpenter : le <code>sizing des requests des containers est essentiel</code>. Le choix des noeuds et la compaction du cluster nécessite que les workloads soient dimensionnées au plus juste de leur utilisation réelle.</p><p>L&rsquo;utilisation des <code>TopologySpreadConstraints</code> des <code>AntiAffinity</code> ainsi que des <code>PodDisruptionBudget</code> est également essentielle pour garantir la <code>Haute Disponibilité</code> des applicatifs dans un contexte où Karpenter va continuellement consolider le cluster et donc rescheduler des pods et des noeuds.</p><p>Voici par exemple un extrait de configuration que nous mettons sur chacun de nos deployment :</p><div class=highlight><pre tabindex=0 style=color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4><code class=language-yaml data-lang=yaml><span style=display:flex><span>  <span style=color:#75715e># avec l&#39;antiaffinity on s&#39;assure que les pods ne soit pas tous sur le même host</span>
+</span></span></code></pre></div><p>Si une chose est à retenir avec l&rsquo;utilisation de Karpenter : le <strong>sizing des requests des containers est essentiel</strong>. Le choix des noeuds et la compaction du cluster nécessite que les workloads soient dimensionnées au plus juste de leur utilisation réelle.</p><p>L&rsquo;utilisation des <code>TopologySpreadConstraints</code> des <code>AntiAffinity</code> ainsi que des <code>PodDisruptionBudget</code> est également essentielle pour garantir la <strong>Haute Disponibilité</strong> des applicatifs dans un contexte où Karpenter va continuellement consolider le cluster et donc rescheduler des pods et des noeuds.</p><p>Voici par exemple un extrait de configuration que nous mettons sur chacun de nos deployment :</p><div class=highlight><pre tabindex=0 style=color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4><code class=language-yaml data-lang=yaml><span style=display:flex><span>  <span style=color:#75715e># avec l&#39;antiaffinity on s&#39;assure que les pods ne soit pas tous sur le même host</span>
 </span></span><span style=display:flex><span>  <span style=color:#f92672>affinity</span>:
 </span></span><span style=display:flex><span>    <span style=color:#f92672>podAntiAffinity</span>:
 </span></span><span style=display:flex><span>      <span style=color:#f92672>preferredDuringSchedulingIgnoredDuringExecution</span>: