Kubernetes 개발 환경에서 프로덕션 환경으로의 전환, 핵심 노하우 공개!

저자는 개발 환경의 **minikube, 로컬 인증서, *.127.0.0.1.nip.io 도메인, 자동 생성된 자격 증명, 개발 의존성 번들, 수동 Helm 시퀀싱과 같은 요소들이 프로덕션 환경에 적합하지 않다고 지적한다. 데이터 격리 아키텍처(Data Isolation Architecture), GitOps 기반 배포, SOPS를 활용한 시크릿 관리, 데이터 미저장 정책(Zero-Retention Policy)**, 백업 및 복구, 사용자 정의된 ID 흐름, 그리고 관측 가능성을 통해 프로덕션 환경의 안정성을 확보해야 한다고 강조한다. 이는 단순히 애플리케이션을 배포하는 것을 넘어, 안전하고, 관찰 가능하며, 복구 가능하고, 진화 가능한 시스템을 구축하는 데 초점을 맞춘 것이다.

저자는 GitOps를 통해 배포 제어 능력을 향상시키고, 더 나은 저장소 구조와 검증 체크를 구현했다고 설명한다. GitOps는 수동 배포 방식에서 벗어나, Git을 배포 API로 사용하고, Flux를 통해 원하는 상태를 클러스터에 적용하는 방식이다. SOPS를 사용하여 환경 설정을 암호화하고, 런북을 명령형 설치 단계 대신 조정 워크플로우로 전환했다. GitOps 도입은 저장소 레이아웃, 릴리스 경계, 브랜칭 습관, 시크릿 처리, 그리고 일상적인 운영 방식을 변화시켰다. 특히, 환경 변화를 검토하고 감사할 수 있게 되어, 운영 효율성을 높였다.

저자는 프로덕션 환경에서는 장애를 예측하고 대비하는 것이 중요하다고 강조하며, 데이터베이스 백업 통합 및 복구 검사 자동화를 구현했다. 매일 실행되는 Cron Job은 데이터베이스를 별도의 컨테이너로 복원하고, 복원된 데이터에 대한 Sanity Check를 수행한다. 이 작업은 복구 경로에 대한 실행 가능한 운영 지침 역할을 한다. 백업 설정이 아닌, 지속적인 실행(Continuous Exercise)을 통해 복구 가능성을 검증하는 것이 핵심이다. 이를 통해, 복구 가능성, 자격 증명의 정확성, 예상된 데이터의 존재 여부를 확인할 수 있다.

저자는 Prometheus와 Grafana를 활용하여 Flux, 데이터베이스, ID, 인그레스, 캐시에 대한 타겟 대시보드를 구축하고, 몇 초마다 외부 엔드포인트에 대한 가용성 검사를 수행했다. 또한, 경고 튜닝을 통해 노이즈를 줄이고 실행 가능성을 높였다. 관측 가능성(Observability)은 단순히 대시보드를 만드는 것을 넘어, 시스템의 변화를 이해하는 데 중점을 둔다. 저자는 관측 가능성을 통해 조정 상태, 외부 엔드포인트 접근성, 데이터베이스 연결 상태, 로그인 흐름 실패 여부, 그리고 캐시 관련 문제로 인한 사용자 경험 저하 등을 파악할 수 있었다.