[Argo CD] Argo CD에 Redis는 왜 있을까?

바로 전에 글을 해결하면서 의문이 든게 Redis가 왜 필요할까라는 생각이 들어 글을 적어보아요. 

 

 Argo CD에 Redis는 왜 있을까? 

 

Argo CD를 처음 설치하거나 구성하다 보면, Pod 목록 중에 ‘argocd-redis’라는 컴포넌트를 보게 됩니다.
처음 보는 사람이라면 이런 의문이 들 수 있어요.

“Argo CD는 GitOps 도구잖아? Git에서 쿠버네티스 매니페스트를 가져와서 배포하면 되는 거 아냐?
그런데 왜 Redis 같은 캐시 서버가 같이 설치되지?”

사실 Redis는 Argo CD 내부 동작에서 꽤 중요한 역할을 하고 있습니다.
겉보기엔 단순히 ‘CI/CD 도구’처럼 보이지만, Argo CD는 복수의 마이크로서비스 컴포넌트로 구성되어 있고,
이 컴포넌트들 간의 빠른 데이터 공유와 상태 관리를 위해 Redis를 적극적으로 활용합니다.

 

여러 컴포넌트 간 데이터 공유가 필요하다 

Argo CD는 다음과 같은 주요 컴포넌트들로 구성되어 있습니다:

• argocd-repo-server: Git 저장소에서 매니페스트 파일을 읽고 템플릿을 렌더링함
• argocd-application-controller: 쿠버네티스 클러스터의 실제 상태와 Git의 선언적 상태를 비교하고, 필요한 동기화 작업을 수행
• argocd-server: 웹 UI 및 CLI 요청을 받아 처리

이 세 가지는 각기 독립된 역할을 수행하지만,
Git 리포지토리 정보나 템플릿 렌더링 결과, 애플리케이션의 동기화 상태 등을 서로 공유해야 합니다.

여기서 Redis가 그 중간 캐시 저장소 역할을 맡습니다.

 

왜 하필 Redis일까? 

Argo CD는 사용자 요청에 빠르게 반응해야 하고,
지속적으로 애플리케이션 상태를 감시하면서 효율적으로 처리해야 합니다.
이때 다음과 같은 이유로 Redis가 선택됩니다:

1. 속도: Redis는 인메모리 기반 저장소라서 데이터 읽기/쓰기가 매우 빠릅니다.
   수많은 매니페스트 렌더링 결과나 상태 정보를 빠르게 조회할 수 있어요.
2. 가벼움: Redis는 비교적 설치와 관리가 간단하고, 경량화되어 있어 쿠버네티스에 적합합니다.
3. 마이크로서비스에 최적화:
   여러 Pod들이 동시에 상태를 공유하고 빠르게 접근해야 할 때, Redis처럼 중앙 집중형의 빠른 캐시 시스템은 매우 유리합니다.

실제로 Redis는 어떤 역할을 할까 

아래는 Redis가 실제로 사용되는 대표적인 시나리오입니다:

• 템플릿 캐싱: argocd-repo-server가 Git에서 Helm 차트를 가져와 렌더링하면, 그 결과를 Redis에 저장합니다.
  이후 argocd-application-controller나 argocd-server가 이를 다시 사용할 수 있어, 매번 Git을 조회하거나 Helm 렌더링을 반복하지 않아도 됩니다.
• 애플리케이션 상태 정보 공유: application-controller가 주기적으로 쿠버네티스 상태를 스캔하고, 이를 Redis에 저장합니다.
  그러면 사용자가 웹 UI로 접속할 때 argocd-server는 이 정보를 Redis에서 빠르게 가져와 보여줄 수 있습니다.
• 속도 최적화: 매번 Git에서 데이터를 가져오는 것보다 Redis에서 캐시된 데이터를 활용하는 것이 훨씬 빠르기 때문에,
  전체 시스템 응답 속도와 사용자 경험이 크게 향상됩니다.

정리하자면,

Redis는 단순한 옵션이 아니라, Argo CD의 안정성과 성능에 핵심적인 역할을 합니다.
GitOps 도구라고 해서 단순히 Git에서 매니페스트만 가져오는 게 아니라,
그 과정에서 많은 상태 정보, 템플릿 결과, 사용자 요청 등을 관리하기 위해
고속 캐시 서버인 Redis를 적극 활용하는 것이죠.

Argo CD를 운영하면서 Redis에 이상이 생기면 애플리케이션 상태 동기화나 템플릿 로딩이 실패할 수 있기 때문에,
Redis도 Argo CD의 중요한 구성 요소로 함께 관리해주는 것이 좋습니다.