Yeşil DevOps: CI/CD Pipeline’larınızın Karbon Ayak İzini Nasıl Takip Edersiniz?
Modern mühendislik ekipleri olarak FinOps dashboard’larına bakıp AWS faturasından yüzde üç kırpınca kendimizi zafer kazanmış sayıyoruz. Ancak altyapı maliyetini optimize ederken gözden kaçırdığımız çok daha somut bir parametre var: Watt tüketimi. CI/CD süreçlerimizin tükettiği ham enerji ve açığa çıkardığı karbon ayak izi, yazılım dünyasında sürdürülebilirlik başlığı altında artık doğrudan ölçülebilir bir mühendislik metriği. Carbon-Aware DevOps yaklaşımı, bu süreci “ağaç diktik” sertifikalarından çıkarıp doğrudan pipeline konfigürasyonlarına, Prometheus metriklerine ve eBPF seviyesine indiriyor.
Her PR açıldığında tetiklenen devasa entegrasyon testleri, gereksiz katman inşa eden Docker build’leri ve 32 vCPU’luk runner’larda 2 dakika koşan linter’lar sadece fatura değil, şebekeden doğrudan kirli elektrik tüketiyor. Peki bu tüketimi hissi yaklaşımlarla değil, production-grade araçlarla nasıl ölçer ve optimize ederiz?
SCI (Software Carbon Intensity) ve Ölçüm Mantığı
Green Software Foundation tarafından standardize edilen SCI spesifikasyonu karmaşık bir fizik denklemi değil. Bir CI/CD pipeline’ı için denklemi şu şekilde özetleyebiliriz:
SCI = ((E * I) + M) / R
- E (Energy): Pipeline çalışırken harcanan toplam enerji (kWh).
- I (Location-Based Carbon Intensity): İşlemin yapıldığı veri merkezinin bağlı olduğu elektrik şebekesindeki emisyon oranı (gCO2eq/kWh).
- M (Embodied Carbon): Sunucu donanımının üretimi ve bertarafından düşen amortisman payı.
- R (Functional Unit): Bizim durumumuzda tek bir “Pipeline Run”, “Build Başına PR” veya “Deployment”.
Geliştirici ortamında M parametresini çoğunlukla sabit kabul ederiz. Mühendislik olarak doğrudan müdahale edebileceğimiz iki değişken var: Harcanan enerji (E) ve bu enerjinin tüketildiği andaki grid karbon yoğunluğu (I).
Runner Seviyesinde Enerji Tüketimini Ölçmek: Kepler ve eBPF
Eğer self-hosted runner kullanıyorsanız (Kubernetes üzerinde Actions Runner Controller – ARC veya GitLab Runner), bare-metal ya da sanal makine seviyesindeki enerji tüketimini RAPL (Running Average Power Limit) sayaçları ve eBPF kullanarak pod bazında ayrıştırabilirsiniz. Bu noktada sektör standardı araç Kepler (Kubernetes-based Efficient Power Level Exporter).
Kepler, eBPF tracing ile CPU döngülerini, bellek erişimlerini pod ve container seviyesinde dinler; ardından RAPL arayüzünden okunan watt değerini bu metriklerle ilişkilendirir. Kubernetes tabanlı runner kümenize Kepler’i Helm ile deploy etmek oldukça yalındır:
helm repo add kepler https://sustainable-computing-io.github.io/kepler-helm-chart
helm repo update
helm install kepler kepler/kepler \
--namespace kepler-system \
--create-namespace \
--set serviceMonitor.enabled=true \
--set canMount.usrSrc=trueKepler ayağa kalktıktan sonra, CI runner’larınızın namespace’i için Prometheus üzerinden doğrudan anlık tüketimi Joule cinsinden sorgulayabilirsiniz. Tek bir pipeline pod’unun toplam enerji tüketimini (kWh cinsinden) çıkarmak için şu PromQL sorgusu işinizi görür:
# Belirli bir CI pod'unun tükettiği toplam enerji (kWh)
sum(
increase(kepler_container_joules_total{container_namespace="ci-runners", pod_name=~"runner-build-.*"}[1h])
) / 36000003.600.000’e bölmemizin nedeni Joule’ü kWh’a çevirmek. Elinizde artık soyut bir “build 8 dakika sürdü” verisi değil, “bu build 0.042 kWh tüketti” metrik verisi var.
Carbon-Aware Scheduling: Testleri Ne Zaman Koşmalı?
CI pipeline’larını sadece “hızlı bitsin” diye tasarlamak yerine, işin doğasına göre sınıflandırmak gerekir. Kritik bir hotfix PR’ı hemen koşmalıdır; ancak nightly build’ler, periyodik regression testleri veya end-to-end sentetik yük testleri zamana duyarlı değildir. İşte burada Carbon-Aware Execution devreye girer.
Elektrik şebekesindeki karbon yoğunluğu rüzgar ve güneş üretimine göre gün içinde radikal biçimde değişir. Örneğin Almanya (eu-central-1) şebekesi öğlen saatlerinde güneş panelleri devredeyken 150 gCO2eq/kWh seviyesindeyken, akşam rüzgar kesildiğinde ve kömür devreye girdiğinde 600 gCO2eq/kWh seviyesine fırlayabilir.
Aşağıdaki GitHub Actions workflow örneğinde, Electricity Maps API’sini kullanarak o anki grid karbon yoğunluğunu sorguluyoruz. Eğer emisyon eşik değerin üzerindeyse ve acil olmayan bir batch job koşuyorsak, build’i postpone ediyoruz veya düşük karbonlu bir bölgedeki runner’a route ediyoruz:
name: Carbon-Aware Integration Suite
on:
schedule:
- cron: '0 * * * *' # Saatlik tetikleme
workflow_dispatch:
jobs:
check-carbon-intensity:
runs-on: ubuntu-latest
outputs:
should_run: ${{ steps.carbon_check.outputs.should_run }}
steps:
- name: Fetch Carbon Intensity
id: carbon_check
env:
EMAPS_API_TOKEN: ${{ secrets.ELECTRICITY_MAPS_TOKEN }}
ZONE: "DE" # Almanya şebekesi
THRESHOLD: 250 # gCO2eq/kWh sınırı
run: |
RESPONSE=$(curl -s -H "auth-token: $EMAPS_API_TOKEN" \
"https://api.electricitymap.org/v3/carbon-intensity/latest?zone=$ZONE")
INTENSITY=$(echo $RESPONSE | jq '.carbonIntensity')
echo "Güncel Karbon Yoğunluğu: $INTENSITY gCO2eq/kWh"
if [ "$INTENSITY" -lt "$THRESHOLD" ]; then
echo "Şebeke temiz. Pipeline çalıştırılıyor."
echo "should_run=true" >> $GITHUB_OUTPUT
else
echo "Şebeke kirli. Ağır testler erteleniyor."
echo "should_run=false" >> $GITHUB_OUTPUT
fi
heavy-tests:
needs: check-carbon-intensity
if: needs.check-carbon-intensity.outputs.should_run == 'true'
runs-on: arc-runner-set
steps:
- uses: actions/checkout@v4
- name: Run E2E Tests
run: make test-e2eNeden Böyle Yapıyoruz?
Çünkü saatte 200 kWh tüketen devasa bir staging test kümeniz varsa, sadece çalıştırma saatini kaydırarak (carbon-shifting) pipeline altyapısına tek bir satır kod optimizasyonu yapmadan emisyonu yüzde 40 ila 60 oranında azaltabilirsiniz. Bu, production iş yüklerini taşımaktan çok daha risksiz ve anında etki eden bir yöntemdir.
Pipeline Seviyesinde Optimizasyon: Boşa Yanan CPU Döngülerini Kesmek
Yalnızca zamanlama yetmez; tüketilen ham enerjiyi (E) kısmak için pipeline anatomisini elden geçirmek gerekir. Tipik kurumsal CI/CD süreçlerinde en çok enerji israfına yol açan pratikler ve çözümleri şunlardır:
1. Docker Katman Önbelleği (BuildKit Cache Thrashing)
CI ortamında her build’de sıfırdan pip install veya npm ci yapmak sadece pipeline süresini uzatmaz; runner üzerinde disk I/O ve network adaptörü aracılığıyla gereksiz CPU watt tüketimi üretir. GitHub Actions Cache veya harici S3/Registry cache backend kullanmak doğrudan enerji tasarrufudur.
# Kaniko veya Buildx ile GitHub Actions Cache backend kullanımı
docker buildx build \
--cache-to type=gha,mode=max \
--cache-from type=gha \
--tag my-service:${{ github.sha }} \
--file Dockerfile .mode=max kullanımı sadece son imajı değil, ara katmanları da saklar. Bu sayede multi-stage build’lerde dependency stage’i değişmediği sürece CPU neredeyse rölanti modunda kalır.
2. Mimari Değişimi: x86_64 Yerine ARM64 Runner’lar
AWS Graviton veya Ampere Altra tabanlı ARM64 instance’lar, modern Intel/AMD eşdeğerlerine kıyasla Watt başına kayda değer oranda daha yüksek işlem kapasitesi sunar (Performance-per-Watt). CI/CD runner filolarınızı ARM mimarisine taşımak, build sürelerini dramatik olarak değiştirmese bile doğrudan tüketilen toplam enerjiyi yüzde 20-30 oranında aşağı çeker.
Aşağıdaki gibi basit bir Docker buildx multi-arch matrix konfigürasyonu yerine derlemeyi doğrudan hedef donanımda (native) yapmak CPU emülasyon maliyetini (QEMU overhead) ortadan kaldırır:
# QEMU üzerinden emüle edilmiş ARM build (YÜKSEK ENERJİ TÜKETİMİ - KAÇININ)
docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
docker buildx build --platform linux/arm64 -t app:latest .
# DOĞRU YAKLAŞIM: Native ARM64 Runner ayağa kaldırıp doğrudan derlemek
# GitHub Actions: runs-on: [self-hosted, linux, arm64]Emülasyon ile derleme yapmak CPU döngülerini 4 ila 10 kat artırarak ciddi bir enerji israfı yaratır. Build’i native runner’a devretmek doğrudan watt tasarrufudur.
Emisyon Verisini PR Seviyesine İndirmek
Mühendise geri bildirim vermediğiniz hiçbir metrik iyileşmez. Code-coverage raporu veya lint hatası gibi, her pull request’in ne kadar karbon emisyonuna yol açtığını PR yorumu olarak basmak ekip kültürünü dönüştürür. Açık kaynak araçlardan Eco-CI bu iş için doğrudan GitHub Actions içine entegre olabilen hazır step’ler sağlar:
steps:
- name: Eco-CI Init
uses: green-coding-solutions/eco-ci-energy-estimation@v4
with:
task: start-measurement
- name: Build and Test Project
run: |
mvn clean verify
- name: Eco-CI Measurement
uses: green-coding-solutions/eco-ci-energy-estimation@v4
with:
task: get-measurement
label: 'Maven Test Suite'
- name: Eco-CI PR Comment
uses: green-coding-solutions/eco-ci-energy-estimation@v4
with:
task: display-results
send-pr-comment: trueBu konfigürasyon, GitHub API üzerinden PR altına çalıştırılan donanımın ortalama enerji katsayılarına göre tüketilen kWh ve üretilen CO2eq gramajını yazar. Bir geliştirici, yazdığı verimsiz bir integration testinin pipeline süresini 10 dakika uzatmasının sadece kendisini değil, ölçülebilir bir emisyonu tetiklediğini gördüğünde optimizasyon soyut bir hedef olmaktan çıkar.
Sonuç: FinOps ve GreenOps Ayrımı Ortadan Kalkıyor
Yeşil DevOps, marjinal bir çevreci PR çalışması değil; modern sistem mimarisinin kaçınılmaz bir optimizasyon evresidir. Pipeline’larınızdaki CPU kullanımını optimize etmek, katmanları doğru önbelleğe almak, runner’ları doğru mimariye geçirmek ve zamana duyarsız işleri şebekenin temiz olduğu anlara kaydırmak teknik borcu azaltır. Daha az CPU döngüsü, daha az fatura ve nihayetinde daha düşük bir karbon ayak izi demektir.