[ArgoCD] Repo Server Manifest 캐시 미스 이슈

개요

ArgoCD Repo Server의 Manifest 캐시 미스 이슈를 확인하고 해결한 내용을 다룬다.

문제 상황

Repo Server가 자꾸 죽는다

어제 홈 서버에 운영 환경과 더불어 Headlamp, Contour와 같은 리소스를 배포하고 난 이후 ArgoCD Repo Server에서 계속 이벤트가 쌓이기 시작했다.

이전에는 발견하지 못했던 이벤트였는데 Repo Server가 멀쩡히 동작하는데도 Liveness Probe에 실패해서 Unhealthy 하다고 판단, 계속해서 컨테이너를 죽이고 재생성한 모양이었다.

Manifest 캐시 미스의 지속적 발생

도대체 왜 Repo Server가 Liveness Probe에 실패하는지를 확인하기 위해 Pod 로그를 확인하고, 이를 여러 LLM에도 확인을 요청해본 결과 분석 결과는 다음과 같았다.

time="2026-01-20T04:57:39Z" level=info msg="started call" grpc.component=server grpc.method=GenerateManifest grpc.method_type=unary grpc.request.deadline="2026-01-20T04:58:39Z" grpc.service=repository.RepoServerService grpc.start_time="2026-01-20T04:57:39Z" grpc.time_ms=0.019 peer.address="10.42.0.85:51776" protocol=grpc 
time="2026-01-20T04:57:39Z" level=info msg="manifest cache miss: &ApplicationSource{RepoURL:git@github.com:<gitops 저장소>.git,Path:bootstrap/prod,TargetRevision:HEAD,Helm:nil,Kustomize:nil,Directory:nil,Plugin:nil,Chart:,Ref:,Name:,}/d3fd806f53594115af3f8fcb061f52705da05d8f" 
time="2026-01-20T04:57:39Z" level=info msg="git cat-file -t d3fd806f53594115af3f8fcb061f52705da05d8f" dir=/tmp/_argocd-repo/a537fe05-7a16-4bc0-a8d7-8ca0dd14cb2c execID=0a11b
time="2026-01-20T04:57:39Z" level=info msg=Trace args="[git cat-file -t d3fd806f53594115af3f8fcb061f52705da05d8f]" dir=/tmp/_argocd-repo/a537fe05-7a16-4bc0-a8d7-8ca0dd14cb2c operation_name="exec git" time_ms=4.570954
time="2026-01-20T04:57:39Z" level=info msg="git checkout --force d3fd806f53594115af3f8fcb061f52705da05d8f" dir=/tmp/_argocd-repo/a537fe05-7a16-4bc0-a8d7-8ca0dd14cb2c execID=501a0 
time="2026-01-20T04:57:39Z" level=info msg=Trace args="[git checkout --force d3fd806f53594115af3f8fcb061f52705da05d8f]" dir=/tmp/_argocd-repo/a537fe05-7a16-4bc0-a8d7-8ca0dd14cb2c operation_name="exec git" time_ms=7.0824929999999995 
time="2026-01-20T04:57:39Z" level=info msg="git clean -ffdx" dir=/tmp/_argocd-repo/a537fe05-7a16-4bc0-a8d7-8ca0dd14cb2c execID=a3565 
time="2026-01-20T04:57:39Z" level=info msg=Trace args="[git clean -ffdx]" dir=/tmp/_argocd-repo/a537fe05-7a16-4bc0-a8d7-8ca0dd14cb2c operation_name="exec git" time_ms=4.276432 
time="2026-01-20T04:57:39Z" level=info msg="git rev-parse HEAD" dir=/tmp/_argocd-repo/a537fe05-7a16-4bc0-a8d7-8ca0dd14cb2c execID=ac8dc 
time="2026-01-20T04:57:39Z" level=info msg=Trace args="[git rev-parse HEAD]" dir=/tmp/_argocd-repo/a537fe05-7a16-4bc0-a8d7-8ca0dd14cb2c operation_name="exec git" time_ms=3.3689229999999997 
time="2026-01-20T04:57:39Z" level=info msg="manifest cache miss: &ApplicationSource{RepoURL:git@github.com:<gitops 저장소>.git....

1. 지속적인 Manifest cache miss 발생
2. Manifest cache miss로 인해 GitOps 저장소에서 App별 Manifest를 git 명령어로 가져오기를 반복
3. Manifest의 Helm Dependency가 작다면 금방 끝나지만 Contour와 같이 Dependency가 큰 경우엔 가져올 때 지연이 발생
4. 이렇게 Manifest를 가져왔음에도 여전히 지속적인 Manifest cache miss 반복 -> 2~3번 과정 지속적인 반복
5. 4로 인해 Repo Sever 과부하, 이 와중에 짧은 주기로 Liveness Probe 체크 -> 응답 지연으로 인한 헬스 체크 실패 -> 재시작

즉 App별 Manifest를 계속 체크할 때 원본을 GitOps 리포지토리에서 한 번 가져오고 이를 캐시로 저장했어야 하는데, 캐시가 저장이 되지 않았거나 하는 등의 이유로 캐시 미스가 발생, 계속해서 Manifest 원본을 GitOps 리포지토리에서 가져오는 행동을 반복하여 Repo Server에 과부하가 발생하는 상황이었다.

원인 확인 및 대응

도대체 원인이 무엇인가

원인을 확인하기 위해 개발 / 운영 / 인프라별 Bootstrap 및 App 파일들을 확인했는데 뜻밖에 아주 간단한 곳에서 원인을 찾을 수 있었다. 바로 Target Revision을 HEAD로 해둔 것 때문이었다.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: bootstrap-prod
  namespace: argocd
spec:
  project: default
  source:
    repoURL: git@github.com:<GitOps 저장소>.git
    targetRevision: HEAD # 요놈이 원인
    path: bootstrap/prod
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

사실 이전에 개발을 했을 때엔 main으로 했었다가 이번에 새로 배포를 하면서 기본값인 HEAD에서 바꾸지 않고 생성을 해뒀었는데, 확인을 해보니 HEAD로 지정할 경우 다음과 같은 이유로 캐시 미스가 발생할 수 밖에 없다고 한다.

1. HEAD가 가리키는 브랜치가 명확하지 않으므로 Git 리포지토리에 질의해서 HEAD가 어느 브랜치를 가리키고 있는지 매번 확인
2. 여러 앱이 동시에 동기화될 경우 HEAD 해석에 미묘한 타이밍 차이가 발생 -> 캐시 키가 각각 다르게 생성
3. 캐시 키가 전부 다르므로 캐시 미스가 지속적으로 발생

반면 main과 같이 특정 브랜치로 고정을 시킬 경우 여러 앱이 동시에 동기화되더라도 main 브랜치의 최신 커밋 해시가 동일하기 때문에 캐시를 공유하므로 캐시 미스가 발생하지 않게 된다고 한다.

대응

일단 Bootstrap 및 App 파일들의 targetRevision을 전부 main으로 교체하였다.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: bootstrap-prod
  namespace: argocd
spec:
  project: default
  source:
    repoURL: git@github.com:<GitOps 저장소>.git
    targetRevision: main
    path: bootstrap/prod
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

그 이후 로그를 다시 확인해보니 Repo Server 가동 시에만 GitOps 리포지토리에서 Manifest들을 불러오고, 그 이후부터는 Manifest 캐시 히트가 발생, 더 이상 외부 리포지토리에서 Manifest를 불러오지 않게 되었다.

time="2026-01-20T06:38:19Z" level=info msg="started call" grpc.component=server grpc.method=GetRevisionMetadata grpc.method_type=unary grpc.request.deadline="2026-01-20T06:39:19Z" grpc.service=repository.RepoServerService grpc.start_time="2026-01-20T06:38:19Z" grpc.time_ms=0.016 peer.address="10.42.0.84:34048" protocol=grpc
time="2026-01-20T06:38:19Z" level=info msg="revision metadata cache hit: git@github.com:<gitops 저장소>.git/f7584b03ea45a1d660b55efc417bc9e645736ff8"
time="2026-01-20T06:38:19Z" level=info msg="finished call" grpc.code=OK grpc.component=server grpc.method=GetRevisionMetadata grpc.method_type=unary grpc.request.deadline="2026-01-20T06:39:19Z" grpc.service=repository.RepoServerService grpc.start_time="2026-01-20T06:38:19Z" grpc.time_ms=0.542 peer.address="10.42.0.84:34048" protocol=grpc

또한 Repo Server 자체의 Liveness Probe 설정도 완화하였고, reposerver.parallelism.limit: 1 값을 추가하여 바꾸었다.

후기

사실 Target Revision 딱 하나의 차이였음에도 그 차이로 생긴 사이드 이펙트의 스노우볼이 엄청 커진 것을 두 눈으로 목격하게 되었는데 앞으로 설정을 좀 더 꼼꼼히 확인 해야겠다...