Belajar GitOps dengan ArgoCD - Performance Tuning & Optimization

#Pendahuluan

Di episode 24 sebelumnya kita membangun mesin compliance dari Git dan log ArgoCD. Namun ada tegangan yang tidak bisa dihindari: semakin lengkap bukti dan semakin banyak aplikasi, semakin berat beban ArgoCD. Git yang besar dikloning berulang, ribuan aplikasi direkonsiliasi terus-menerus, dan API server yang lambat membuat operasional terasa macet. Pada episode ini kita membahas performance tuning & optimization — membuat ArgoCD tetap ringkas ketika skala bertambah.

Mengapa ini penting? ArgoCD adalah controller, dan controller memiliki biaya per unit kerja: setiap aplikasi membutuhkan perbandingan Git vs cluster. Tanpa optimasi, biaya itu tumbuh linear dan akhirnya menjadi masalah nyata — sync yang lambat, UI yang lelet, controller yang OOM. Episode ini memberikan kerangka untuk mengoptimalkan dari tempat yang paling berdampak: repo, controller, API server, dan pola arsitektur.

#Optimasi Repository

Repo adalah sumber segalanya, dan kloning adalah operasi termahal ArgoCD. Repo server mengkloning setiap repo saat perubahan dideteksi — repo besar berarti waktu tunggu.

#Shallow Clone dan Repo Caching

Repo server mendukung shallow clone (--depth 1) yang mengurangi waktu kloning drastis untuk repo besar:

Repo server dengan shallow clone

      args:
        - /usr/local/bin/argocd-repo-server
        - --depth=1

Selain itu, ArgoCD menyimpan cache manifest di Redis. Setelah kloning pertama, kubectl apply untuk resource yang sama memakai cache. Untuk repo yang jarang berubah, cache membuat reconciliation jauh lebih cepat daripada kloning ulang setiap kali.

#Connection Pooling dan Cache Invalidation

Repo server membuka koneksi HTTP ke GitHub/GitLab. Pastikan jumlah koneksi memadai lewat ARGOCD_GIT_CONCURRENCY (default 5) dan ARGOCD_GIT_SHALLOW_CLONE=true pada env deployment. Untuk cache:

• Invalidasi manual — argocd app get api --refresh atau UI dengan Hard Refresh memaksa re-clone dan re-render manifest. Ini menyelesaikan kasus di mana Git berubah tetapi ArgoCD masih memegang cache lama.
• TTL cache — cache manifest kedaluwarsa sesuai repositories.* setting; sesuaikan trade-off antara kesegaran dan beban repo server.

argocd_repoclientset_processors_run_count
argocd_repo_pending_request_total
argocd_repo_requests_total

Jika pending_request_total terus tinggi, repo server kewalahan — naikkan replicas (episode 26) atau perbesar ARGOCD_GIT_CONCURRENCY.

#Tuning Application Controller

Application controller adalah jantung reconciliation: ia membandingkan Git dan cluster untuk setiap aplikasi, lalu menjalankan operasi. Dua knob paling berpengaruh:

#Reconciliation Interval dan Worker Count

• --status-processors (default 20) — jumlah goroutine yang memproses perbandingan status. Naikkan saat banyak aplikasi: --status-processors=40.
• --operation-processors (default 10) — jumlah worker untuk operasi sync. Naikkan saat banyak sync berjalan bersamaan.
• Reconciliation interval — seberapa sering ArgoCD membandingkan Git dan cluster. Default 3 menit; untuk aplikasi yang tidak perlu sesegera itu, atur lebih jarang:

metadata:
  annotations:
    argocd.argoproj.io/reconcile-period: 10m
spec:
  ...

Perhatikan trade-off: interval jarang mengurangi beban tetapi memperlambat deteksi drift. Untuk environment production yang kritis, pertahankan 3 menit; untuk aplikasi batch atau non-kritis, 10-30 menit aman.

#Resource Limits dan Status Processors

Controller yang kehabisan memory adalah penyebab kegagalan paling umum di skala menengah. Beri resource limits yang realistis dan amati pemakaiannya:

Controller dengan limits

spec:
  template:
    spec:
      containers:
        - name: argocd-application-controller
          resources:
            requests:
              cpu: 500m
              memory: 1Gi
            limits:
              memory: 2Gi

Metrik pemantauan (episode 22) — argocd_app_reconcile_count dan pemakaian memory — menentukan apakah naikkan limits, naikkan worker, atau beralih ke pola sharding di bawah.

#Optimasi API Server

API server melayani UI, CLI, dan webhook. Ketika banyak user/CI aktif, ini bisa menjadi bottleneck:

• Connection limits dan timeouts — atur di argumen argocd-server untuk membatasi koneksi dan memberi timeout pada request lambat.
• Rate limiting — taruh di depan API server (Ingress NGINX limit-rpm, atau API gateway) agar satu client tidak membanjiri.
• Redis cache — cache UI dan manifest disimpan di Redis; pastikan Redis tidak jadi titik lemah (kita bahas HA-nya di episode 26).

metadata:
  annotations:
    nginx.ingress.kubernetes.io/limit-rpm: "60"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "120"
spec:
  ...

#Skala Besar: Sharding dan Multi-Instance

Ketika ribuan aplikasi tidak bisa ditangani satu controller, ada tiga pola:

1. App sharding — membagi aplikasi ke beberapa controller dalam satu ArgoCD. Tiap controller diberi subset aplikasi lewat label selector (argocd.argoproj.io/shard). Paling mudah, tanpa cluster tambahan.
2. Multiple ArgoCD instances — instance terpisah per environment/region; reduksi blast radius dan isolasi beban.
3. Federation — satu ArgoCD "hub" yang mengelola beberapa ArgoCD "spoke" (atau sebaliknya, hub terkelola Git). Untuk organisasi dengan banyak platform team.

Sharding lewat label adalah langkah pertama yang paling murah:

Controller dengan shard selector

      args:
        - --application-shard=0
        - --sharding-method=legacy

Atau gunakan label-based sharding modern: beri label argocd.argoproj.io/shard pada controller StatefulSet dan label yang sama pada Application. ArgoCD v2.15+ mendukung ini dengan mulus. Sementara itu, ApplicationSet (episode 11) membantu menjaga ribuan aplikasi tetap konsisten meski beban tersebar.

#Performa Cluster

ArgoCD juga bergantung pada kesehatan cluster itu sendiri. Tiga praktik dasar:

• Resource quotas dan LimitRanges per namespace mencegah satu tim menghabiskan sumber daya dan memperlambat semua orang (konsep dari episode 10).
• HPA pada komponen ArgoCD yang bisa diskalakan — argocd-repo-server dan argocd-server bisa di-HPA berdasarkan CPU; controller lebih cocok diskalakan secara vertikal atau lewat sharding karena stateful.
• Node affinity — jangan letakkan komponen ArgoCD di node spot yang bisa hilang sewaktu-waktu; gunakan node dedicated untuk kestabilan.

HPA untuk repo server

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: argocd-repo-server
  namespace: argocd
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: argocd-repo-server
  minReplicas: 1
  maxReplicas: 5
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

#Penutup

Episode ini membongkar performa ArgoCD per lapisan: optimasi repo dengan shallow clone dan caching, tuning application controller dengan status processors dan reconcile interval, optimasi API server dengan rate limit dan Redis, pola skala besar dengan sharding, multi-instance, dan federation, serta kesehatan cluster dengan quotas, HPA, dan node affinity.

Poin yang harus kalian bawa:

• Kloning Git adalah biaya termahal; shallow clone dan cache meringankannya.
• --status-processors dan --operation-processors adalah knob utama controller.
• Reconcile interval yang lebih jarang meringankan beban dengan harga deteksi drift lebih lambat.
• Sharding berbasis label adalah langkah skala besar pertama yang paling murah.
• Ukur baseline sebelum dan sesudah setiap perubahan.

ArgoCD yang cepat tetap bisa menjadi titik tunggal kegagalan — cepat tidak berarti tangguh. Di episode 26 selanjutnya kita membahas high availability setup — arsitektur HA, HA per komponen, Redis dengan Sentinel, HA jaringan, dan pengujian kegagalan dengan chaos. Sampai jumpa di episode 26!