persistent-storage

연간 600시간을 절약한 쿠버네티스 한 줄 수정 (새 탭에서 열림)

쿠버네티스 환경에서 테라폼(Terraform) 운영 도구인 아틀란티스(Atlantis)의 재시작 시간을 30분에서 수 초 내외로 단축하여, 연간 600시간의 엔지니어링 대기 시간을 줄인 사례를 소개합니다. 문제의 원인은 수백만 개의 파일을 포함한 퍼시스턴트 볼륨(PV)을 마운트할 때 쿠버네티스가 기본적으로 수행하는 파일 권한 변경 작업이었습니다. 이를 해결하기 위해 `securityContext`에 단 한 줄의 설정을 추가함으로써 불필요한 재귀적 권한 검사를 방지하고 시스템 효율성을 극대화했습니다. ### 원인 불명의 느린 재시작 문제 아틀란티스는 테라폼 프로젝트의 상태를 유지하기 위해 퍼시스턴트 볼륨(PV)을 사용하는 싱글톤 스테이트풀셋(StatefulSet)으로 운영됩니다. 자격 증명 갱신이나 프로젝트 온보딩 시 재시작이 필수적인데, 이때마다 다음과 같은 심각한 지연이 발생했습니다. * **지속적인 지연:** 매 재시작 시 30분 동안 포드가 `Init:0/1` 상태에 머물며 인프라 변경 작업이 완전히 중단됨. * **운영 부담:** 매달 약 100회의 재시작이 발생하여 월 50시간, 연간 600시간의 엔지니어링 시간이 낭비되고 온콜 엔지니어에게 불필요한 알람이 전송됨. * **한계 도달:** 파일 시스템의 아이노드(Inode) 고갈로 볼륨 크기를 키워야 하는 상황에서, 재시작 지연 문제는 더욱 두드러짐. ### Kubelet 로그를 통한 기술적 병목 파악 일반적인 `kubectl events`로는 포드가 이미지를 풀링하기 전 단계에서 왜 멈춰 있는지 알 수 없었습니다. 팀은 노드 레벨의 `kubelet` 로그를 분석하여 구체적인 원인을 찾아냈습니다. * **로그 추적:** 로그상에서 볼륨 마운트 성공 메시지 이후 `context deadline exceeded` 오류가 반복적으로 발생하며 포드 생성이 지연됨을 확인. * **fsGroup 권한 설정:** 쿠버네티스는 볼륨을 마운트할 때 포드의 `fsGroup` 설정과 일치시키기 위해 볼륨 내의 모든 파일과 디렉토리에 대해 재귀적으로 `chown` 및 `chmod`를 실행함. * **파일 개수의 영향:** 아틀란티스 볼륨에 쌓인 수백만 개의 파일에 대해 매번 이 작업을 수행하면서 30분이라는 막대한 시간이 소요됨. ### 단 한 줄의 설정 변경으로 문제 해결 쿠버네티스 1.20 버전(GA 기준)부터 도입된 `fsGroupChangePolicy` 설정을 통해 이 문제를 간단히 해결할 수 있었습니다. * **기본값(Always):** 포드가 시작될 때마다 항상 모든 파일의 권한을 재귀적으로 변경함. * **해결책(OnRootMismatch):** 볼륨 루트 디렉토리의 권한이 `fsGroup`과 일치하지 않을 때만 재귀적 변경을 수행함. 이미 권한이 올바르게 설정되어 있다면 이 과정을 건너뜀. * **적용 코드:** ```yaml securityContext: fsGroup: 1000 fsGroupChangePolicy: "OnRootMismatch" ``` ### 실용적인 권장 사항 수백만 개의 작은 파일이 포함된 대규모 볼륨을 사용하는 애플리케이션(예: Prometheus, Atlantis, Jenkins 등)을 쿠버네티스에서 운영 중이라면, `fsGroupChangePolicy: "OnRootMismatch"` 설정을 기본적으로 적용하는 것이 좋습니다. 이를 통해 볼륨 마운트 시 발생하는 불필요한 디스크 I/O를 제거하고, 포드 시작 시간을 획기적으로 개선하여 인프라 운영의 가용성을 높일 수 있습니다.

Failure is inevitable: Learning from a large outage, and building for reliability in depth at Datadog (새 탭에서 열림)

2023년 3월에 발생한 대규모 장애를 계기로 데이터독(Datadog)은 시스템 가용성에 대한 근본적인 철학을 재정립했습니다. 당시 인프라의 50~60%가 작동 불능 상태에 빠지자 플랫폼 전체가 완전히 멈춘 것처럼 보이는 '정사각형 파형(Square-wave) 실패' 패턴이 나타났으며, 이는 완벽한 데이터 정확성에만 집착하던 기존 설계의 한계를 드러냈습니다. 이에 데이터독은 모든 장애를 막으려는 시도 대신, 극단적인 상황에서도 일부 기능을 유지하며 가치를 제공하는 '우아한 성능 저하(Graceful Degradation)'를 핵심 전략으로 채택했습니다. ### 장애의 교훈: 정사각형 파형 실패의 발견 * **이진법적 실패:** 2023년 3월, 글로벌 보안 업데이트 과정에서 쿠버네티스 노드의 약 절반이 연결을 소실했습니다. 인프라의 절반은 여전히 작동 중이었음에도 불구하고, 사용자 입장에서는 서비스가 아예 응답하지 않거나 데이터가 전혀 보이지 않는 '전부 아니면 전무(All-or-Nothing)' 식의 장애가 발생했습니다. * **정확성 편향의 부작용:** 기존 시스템은 데이터의 정확성을 보장하기 위해 모든 태그와 메트릭이 완전히 처리될 때까지 쿼리 결과 표시를 대기하도록 설계되었습니다. 평상시에는 올바른 선택이지만, 대규모 장애 시에는 일부 데이터 누락이 전체 시스템의 데이터 가독성을 차단하는 결과를 초래했습니다. * **사후 분석의 한계:** 단순히 장애의 트리거(레거시 업데이트 메커니즘)를 제거하는 것만으로는 충분하지 않았습니다. 인증서 만료, 윤초, 설정 오류 등 장애의 원인은 무한하기 때문에, 원인 차단보다는 장애 발생 시 시스템이 어떻게 반응하느냐가 더 중요하다는 점을 깨달았습니다. ### 실패를 위한 설계: 우아한 성능 저하의 원칙 * **복구력 중심의 사고 전환:** 절대 실패하지 않는(Never-fail) 아키텍처는 불가능하다는 것을 인정하고, '더 잘 실패하는(Failing better)' 시스템을 구축하는 데 집중하기 시작했습니다. * **우선순위의 재정립:** 장애 상황에서도 고객의 비즈니스 연속성을 보장하기 위해 세 가지 원칙을 세웠습니다. ① 데이터는 늦더라도 절대 유실되지 않아야 한다. ② 가용한 자원은 실시간 데이터 처리에 우선 할당한다. ③ 아무것도 보여주지 않는 것보다 부정확하더라도 부분적인 결과를 보여주는 것이 낫다. ### 데이터 유실 방지를 위한 영구 흡수 저장소(Persistent Intake) * **메모리 기반 버퍼의 위험성:** 분석 결과, 초기 데이터 흡수(Intake) 단계에서 데이터가 메모리나 로컬 디스크에만 머물러 있다가 노드 장애 시 복구 불가능하게 유실되는 문제가 확인되었습니다. * **디스크 기반 영구 저장:** 데이터 처리 파이프라인의 가장 앞단에 디스크 기반의 복제 저장소를 도입했습니다. 이를 통해 수집 노드가 중단되더라도 데이터가 유실되지 않도록 보장하며, 다운스트림 시스템이 마비되었을 때도 버퍼 역할을 수행하여 데이터 에이전트의 재시도 실패를 방지합니다. * **지연 시간과 안정성의 균형:** 응답 속도를 위해 최적화되었던 기존 방식에서 벗어나, 데이터 수신 확인(Acknowledgment)을 보내기 전에 복제된 저장소에 안전하게 기록하는 구조로 변경하여 신뢰성을 높였습니다. ### 실용적인 결론 및 제언 대규모 시스템을 운영하는 엔지니어링 팀은 시스템의 **신뢰성(Reliability)**을 단순히 '장애가 없는 상태'로 정의해서는 안 됩니다. 시스템의 일부가 마비되더라도 핵심적인 기능은 작동을 멈추지 않도록 설계해야 합니다. 특히 데이터 정확성과 가용성 사이의 트레이드오프를 재검토하여, 장애 시나리오에서는 '완벽한 데이터'보다 '부분적이지만 즉각적인 가시성'을 제공하는 것이 비즈니스 관점에서 훨씬 유리할 수 있음을 명심해야 합니다.