A Datadog Git-tükre 20-szoros forgalomnövekedést bírt el lassulás nélkül
A Datadog saját Git-tükröt épített a folyamatos integrációs munkafolyamatok kiszolgálására. A gitretriever a vállalat szerint a rajt óta húszszoros forgalomnövekedést kezelt úgy, hogy a medián késleltetés továbbra is körülbelül 40 ezredmásodperc maradt.
- A gitretriever hetente több mint 100 millió Git-kérést kezel.
- A medián késleltetés a húszszoros forgalomnövekedés után is körülbelül 40 ms maradt.
- Az első négy hónapban több mint egymilliárd kérést és több száz terabájt kódot szolgált ki.
- A rendszer független podok saját, friss helyi adattárpéldányaiból szolgál ki.
- Az AI-kódoló ügynökök nagyságrenddel növelték a Git-forgalmat a Datadognál.
A CI-munkák egyik szűk keresztmetszete a kód letöltése
A folyamatos integrációban minden feladat azzal kezdődik, hogy a rendszer lekéri a kódot. A Datadognál a CI több ezer adattárból hetente több millió alkalommal kér le kódot. A legnagyobb adattárak monorepók, amelyek több évnyi előzményt és több százezer fájlt tartalmaznak.
A vállalat 2026. augusztus 19-én közzétett mérnöki beszámolója szerint a gitretriever első négy hónapjában több mint egymilliárd Git-kérést szolgált ki, több száz terabájtnyi kód továbbításával. A rendszer jelenleg hetente több mint 100 millió kérést kezel. A forgalom a rajt óta húszszorosára nőtt, miközben a medián késleltetés nagyjából 40 ms maradt. A korábbi Git-háttérrendszerben a lekérések kiszolgálásához szükséges processzorterhelés három-négyszeresére csökkent.
Az AI-kódoló ügynökök tovább növelték a terhelést
A Datadog sajátos CI-felépítést használ. A GitHub az elsődleges kódtár, a belső CI-feladatok többsége azonban egy saját üzemeltetésű GitLab-telepítésen fut. A CI a GitLab Gitaly rendszeréből kér le, amely előtt a Praefect végzi az útválasztást és a replikáció kezelését. A GitHub és a GitLab közötti szinkronizálásért egy belső, codesync nevű szolgáltatás felel.
A Git-forgalom nagyságrenddel nőtt, részben az AI-kódoló ügynökök terjedése miatt. Ezek az ügynökök a Datadog szerint jóval gyakrabban és nagyobb intenzitással érik el a Gitet, mint a legaktívabb fejlesztők. Erre rakódik rá a belső telepítési, auditálási és biztonsági szolgáltatások folyamatosan növekvő terhelése.
A nyomás különösen a nagy monorepókon jelentkezett. Nőtt az üzemeltetési teher, hosszabbodtak a CI-futások, és gyakoribbá váltak a többórás CI-kiesések.
A hagyományos skálázás nem oldotta meg a problémát
A Datadog többféle megoldást kipróbált: kapacitást bővített, nagyobb példányokra váltott, egyes adattárakat dedikált háttérrendszerekre helyezett, és a buildfolyamatokat is optimalizálta. Ezek a változtatások egy-két hétig javulást hoztak, később azonban a CI-infrastruktúra ismét leromlott vagy teljesen elérhetetlenné vált.
Egy nagy monorepóból indított lekérés több másodpercnyi szerveroldali processzoridőt is igényelhet. Csúcsterheléskor több száz feladat indít lekérést egyszerre, gyakran ugyanazon néhány csomóponton. A replikált felépítésben minden írást minden replikára át kellett másolni, így új csomópontok hozzáadása növelte a replikációs terhet.
A CDN vagy gyorsítótáras proxy sem jelentett megoldást, mert a lekérés költséges része az egyes klienskérésekhez kötött számítás, nem egy változatlanul továbbítható bájttartomány. A GitHubról történő igény szerinti klónozás pedig a terhelést az upstream rendszerre helyezte volna át, ahol szerveroldali sebességkorlátokba ütköztek.
Független Git-tükrök osztják szét a számítási terhet
A gitretriever megközelítése a terhelés elosztására épül. A rendszer független podokat futtat, amelyek saját, friss helyi példányt tartanak fenn a kiszolgált adattárakból. Az egyes podok közvetlenül a saját másolatukból szolgálják ki a kéréseket, a társak közötti konszenzus és több írási szereplőt használó replikáció nélkül.
A Datadog magyarázata szerint a Git-lekérés kiszolgálása azért lehet erőforrás-igényes, mert a kliens és a szerver először egyezteti, milyen objektumokra van szükség, ezután a szerver létrehoz egy packfile-t, amelyet elküld a kliensnek. A packfile összeállítása processzort és tárhelyet igényelhet, különösen sok párhuzamos lekérés, nagy monorepó vagy hosszú változási előzmény esetén.
A vállalat szerint a független tükrök erre a koncentrált terhelésre adnak választ. A rendszer részletes megvalósítását a Datadog mérnökei, Mike Thompson és Daniel Esponda ismertették.
