구성 드리프트 및 방지 방법 안내

구성 드리프트는 모든 IaC 개발자에게 매우 중요한 문제입니다. 이 글에서는 구성 드리프트의 관리, 중요성, 발생 원인 및 잠재적인 해결책을 자세히 알아보겠습니다.

구성 드리프트란 무엇인가?

애플리케이션 소유자는 고객에게 더 나은 경험을 제공하기 위해 앱과 기반 인프라를 지속적으로 수정해야 합니다. 이러한 고객은 내부 또는 외부 고객일 수 있습니다.

이러한 업데이트와 변경으로 인해 앱과 인프라의 설정이 변경됩니다. 이러한 수정은 시스템의 상태를 향상시킬 수도 있지만, 오히려 악화시킬 수도 있습니다. 구성 드리프트는 이러한 현상을 설명하는 용어입니다.

구성 드리프트는 어떻게 발생할까?

소프트웨어 생산 및 배포 시스템이 복잡해질수록 구성 드리프트 발생 가능성은 더욱 커집니다. 코드는 일반적으로 개발자의 워크스테이션에서 공유 개발 환경, 테스트 및 QA 환경, 최종적으로는 스테이징 및 프로덕션 환경으로 이동합니다.

드리프트가 발생하는 위치가 파이프라인의 뒤쪽으로 갈수록 잠재적인 영향은 더 커집니다. 예를 들어, 개발자의 노트북에 설치된 패키지 버전과 테스트 서버에 설치된 버전 사이에 약간의 차이만 있어도 문제 해결이 지연될 수 있습니다. 일반적으로 스테이징 환경과 프로덕션 환경만이 서로 완벽하게 복제된 상태여야 합니다. 많은 기업들이 매일 여러 번 새로운 코드를 배포하므로 이러한 문제는 더욱 심각해질 수 있습니다.

구성 드리프트의 주요 원인

소통 부족

때로는 업스트림 팀이 변경 사항을 다운스트림 파트너에게 제대로 전달하지 않아 전체 다운스트림 시스템이 오작동하게 되는 경우가 있습니다.

핫픽스

핫픽스는 예정된 다음 애플리케이션 업데이트까지 기다릴 수 없는 중요한 문제를 해결하기 위해 코드를 수정하는 것입니다. 문제를 해결하는 과정에서 엔지니어가 파이프라인의 다른 환경에 대해 변경을 수행하거나, 동일한 수정 사항을 문서화하지 못해 드리프트가 발생할 수 있습니다. 종종, 원래 문제의 재발은 이러한 드리프트의 원인이 되기도 합니다.

중요 패키지 업데이트

중요 패키지 업데이트는 핫픽스와 유사한 면이 있습니다. 둘 다 신속하게 수행되어야 합니다. 주요 차이점은 중요한 패키지 업데이트가 향후 문제 발생을 방지하기 위해 적용된다는 점입니다. 따라서 이러한 업데이트 역시 핫픽스와 마찬가지로 드리프트를 유발할 수 있습니다.

자동화 부족

자동화가 구성 드리프트의 발생 가능성을 완전히 없애지는 못하지만, 그 가능성을 크게 줄여줍니다.

편의를 위한 변경

개발자가 일시적인 목적으로 변경하는 경우가 있습니다. 예를 들어, 개발자가 특정 기능을 테스트하기 위해 테스트 서버에 새 패키지를 설치한 후 원래 상태로 되돌리는 것을 잊어버리면 드리프트가 발생할 수 있습니다.

구성 관리가 왜 중요할까?

구성 드리프트가 매우 해로울 수 있는 이유 중 하나는, 지속적으로 드리프트를 감시하는 사람이 없다면, 마치 벽 뒤에서 물이 새는 것처럼 인프라 기반을 서서히 약화시켜 발견되지 않을 수 있기 때문입니다.

구성 드리프트가 발견되면 그 근본 원인을 찾는 데 많은 시간이 소요됩니다. 이는 긴급 상황 시 매우 귀중한 자원 낭비로 이어질 수 있습니다.

소프트웨어 개발에서 드리프트는 느린 릴리스 주기의 주요 원인이 될 수 있습니다. 이는 불필요한 노력과 개발자 생산성 저하를 초래할 수 있습니다.

비용 절감

IT 인프라에 대한 정확한 정보를 확보하면 중복되거나 과도하게 프로비저닝된 부분을 식별하여 전체 리소스 사용량을 줄일 수 있습니다.

생산성 향상

일관되고 잘 정의된 구성 환경은 일괄 관리 및 인프라 구축을 가능하게 합니다. 또한 특이한(또는 눈송이) 서버를 줄여 수동으로 개별 설정을 관리해야 하는 필요성을 줄입니다.

더 빠른 디버깅

일관된 구성을 통해 디버깅 팀은 구성 관련 오류 가능성을 배제할 수 있습니다. 서버, 서버 클러스터 또는 환경 간의 설정 불일치를 찾을 필요가 없으므로 티켓을 보다 빠르게 처리하고 다른 잠재적 원인에 집중할 수 있습니다.

구성 드리프트로 인한 문제점

보안 문제

안전하지 않은 구성은 보안 침해의 주요 원인 중 하나입니다. 안전하게 구성된 환경에서 시작하더라도 구성 드리프트로 인해 다른 공격과 네트워크 침입에 노출될 위험이 커집니다.

다운타임

공격자가 DoS 공격을 실행하거나 중요한 서버를 손상시킬 수 있는 구성 오류로 인해 상당한 가동 중지 시간이 발생할 수 있습니다. 뿐만 아니라, 성능에 영향을 주는 네트워크 장치의 구성을 수정했다고 가정해 봅시다. 언제든지 "황금 설정"으로 되돌릴 수 있을 것이라고 생각할 수 있지만, 해당 설정 자체가 잘못되어 있다면 서비스 복구에 더 많은 시간이 걸릴 수 있습니다.

규정 준수 실패

ISO 27001, PCI-DSS 및 HIPAA와 같은 규정을 준수하려면 엄격한 보안 제어가 필요합니다. 구성 드리프트가 방치되면 이러한 규정을 위반할 수 있습니다.

성능 저하

일반적으로 구성은 의도된 상태에 있을 때 최적의 성능을 발휘합니다. 임시 수정은 병목 현상과 충돌을 일으켜 네트워크 최적화 시도를 방해할 수 있습니다.

시간 낭비

잘 이해되지 않거나 네트워크 문서와 일치하지 않는 네트워크 문제를 해결하는 데 많은 시간이 걸릴 수 있습니다. 즉, 구성 드리프트는 네트워크가 의도된 상태였다면 발생하지 않았거나 훨씬 쉽게 해결할 수 있었을 문제를 발생시켜 사용자에게 다운타임을 초래할 수 있습니다.

구성 드리프트 모니터링 시 주의해야 할 일반적인 실수

이상적인 환경에서 개발자를 위한 모든 환경 서버(Dev/QA/Staging/Prod)는 동일한 설정을 가져야 합니다. 그러나 실제 세계에서는 그렇지 않습니다. 상업 환경에서 애플리케이션 소유자는 소프트웨어에 새로운 기능이 도입될 때 인프라를 자주 수정합니다.

구성 드리프트 모니터링은 소프트웨어 환경이 가능한 한 균일하게 유지되도록 하는 데 매우 중요합니다. 구성 관리를 통해 비용을 절감하고, 생산성을 높이며, 디버깅 시간을 단축하고, 사용자 경험을 향상시킬 수 있습니다.

성공적인 모니터링을 위해서는 조직이 구성 관리를 사용하고 구성 드리프트를 모니터링하는 과정에서 발생할 수 있는 실수를 피해야 합니다.

일반적인 실수는 다음과 같습니다.

CMDB를 최신 상태로 유지하지 않음

구성 관리 데이터베이스(CMDB)를 최신 상태로 유지하는 것은 구성 관리의 중요한 부분입니다. 네트워크의 하드웨어 및 소프트웨어 설치에 대한 정보는 CMDB에서 통합적으로 확인할 수 있습니다. 자산 또는 구성 항목별로 데이터를 수집하여 작업 공간의 가시성과 투명성을 높일 수 있습니다.

CMDB를 유지 관리하지 못하면 한 항목의 구성이 다른 항목에 미치는 영향을 제대로 이해하지 못하게 될 수 있습니다. 조직은 그 결과를 제대로 파악하지 못한 채 인프라와 보안을 손상시킬 위험에 처하게 됩니다.

CMDB는 특히 자산 수가 증가할수록 관리하기 어려울 수 있지만, 구성 드리프트를 성공적으로 추적하고 인프라를 이해하려면 효과적인 데이터베이스 구성과 관리가 중요합니다.

구성 드리프트 모니터링 계획 부재

대부분의 조직은 감시해야 할 방대하고 복잡한 인프라를 가지고 있습니다. 어떤 구성 요소를 가장 먼저 모니터링해야 하는지 결정하는 것이 중요합니다. 그렇지 않으면 구성 관리가 복잡해지고 통제 불능 상태가 될 수 있습니다.

조직은 전체 모니터링 대상과 특정 부서에 중요한 자산을 지정해야 합니다. 가장 중요한 시스템이 감시되도록 해야 하며, 이는 부서 및 산업별로 다를 수 있습니다.

자동 모니터링 부재

조직은 다양한 방식으로 구성 드리프트를 모니터링할 수 있지만, 일부 접근 방식이 다른 방식보다 더 효과적이고 효율적입니다.

구성 드리프트를 수동으로 모니터링하는 것은 비용이 많이 들고 시간이 오래 걸립니다. 또한 인적 오류의 가능성이 높습니다. 회사 인프라 규모가 매우 작은 경우가 아니라면 수동 모니터링은 가장 좋은 방법이 아닙니다.

자동 모니터링은 구성을 원하는 상태로 유지하는 데 가장 발전되고 효율적인 방법입니다. 전용 구성 모니터링 시스템은 드리프트를 즉시 감지할 수 있으며, 빠른 해결을 위한 솔루션을 제공하는 경우가 많습니다. 이를 통해 비즈니스 인프라가 가능한 한 빠르게, 그리고 최소한의 영향으로 원하는 상태로 돌아갈 수 있습니다.

구성 드리프트를 모니터링하는 방법:

구성 드리프트로 인해 발생할 수 있는 손해를 고려할 때, 구성 드리프트를 감지하는 것이 왜 최우선 과제가 되어야 하는지 분명해집니다. 무엇을 보존해야 하고, 왜 특정 변경이 드리프트를 유발했는지 파악하는 것이 첫 번째 단계입니다.

모니터링 대상 파악

조직 전체에 중요한 구성 요소와 각 부서에 중요한 구성 요소를 파악하여 조직을 분류할 수 있습니다.

이러한 요소는 부서에 따라 다를 수 있으며, 규제가 심한 산업의 경우에는 더 광범위하거나, 시스템에 중요한 파일/애플리케이션에만 집중할 수도 있습니다. 시스템의 중요도는 모니터링 시스템의 빈도와 심각도를 결정합니다.

기준선 설정

설정의 차이로 인해 프로덕션 환경과 테스트 단계 간에는 항상 차이가 있습니다. 각 단계의 설정과 허용 가능한 편차 유형을 정의하여 드리프트 확인을 위한 기준선을 설정할 수 있습니다.

초기 테스트 단계는 사용자 승인 테스트 설정 또는 무결점 제조 단계보다 더 높은 수준의 드리프트 허용량이 적용될 수 있습니다.

시스템 모니터링

필요한 모니터링 수준은 조직의 성숙도, 현재 시스템, 도구, 확인해야 하는 구성 요소의 수, 필요한 조사 수준에 따라 달라집니다. 요구 사항 및 규정 준수에 따라 조직 내의 각 부서에 대한 모니터링 수준이 다를 수 있습니다.

구성 드리프트를 방지하는 방법

모니터링은 구성의 기준선과 허용 가능한 편차가 정의된 후 인프라가 적절한 구성으로 유지되도록 해야 합니다. 모니터링 전략이 없다면 구성 계획과 문서화에 투자하는 시간은 낭비될 수 있습니다.

다양한 접근 방식을 사용하여 구성 드리프트를 모니터링할 수 있으며, 많은 기업이 성숙도 및 규정 준수 요구 사항에 따라 방법론과 도구를 결합하여 사용합니다.

지속적인 수동 모니터링

개별 시스템 구성을 수동으로 검토하고 기존에 알려진 구성 파일과 비교할 수 있습니다. 하지만 이 프로세스는 인적 오류의 가능성이 높으며, 직원 시간과 관련하여 비용이 많이 듭니다. 따라서 소수의 특정 서버 클러스터 또는 비교적 작은 인프라 환경을 가진 회사에서만 제한적으로 사용해야 합니다.

감사

팀은 구성 감사의 일부로 서버 구성을 수동으로 검사하여 지정된 모델과 비교합니다. 이러한 감사는 시스템 구축 방법을 결정하기 위해 전문 지식이 필요하고, 시스템을 유지해야 하는지 여부를 판단하기 위해 문서화되지 않은 부분에 대한 철저한 조사가 필요하므로 비용이 많이 들 수 있습니다.

감사 팀은 또한 다음 감사 시 적용할 구성 문서에 필요한 조정을 수행합니다. 감사는 일반적으로 시간과 비용을 고려하여 고가치 또는 규정 준수 요구 사항이 높은 클러스터에 대해 유지되며, 일반적으로 일 년에 여러 번 정기적으로 실행됩니다.

감사를 통해 미리 결정된 일정에 따라 일관되고 반복 가능한 서버 구성을 보장할 수 있습니다.

그러나 다음 감사 시점까지 설정이 드리프트될 수 있으며, 이러한 드리프트는 시간이 지날수록 누적됩니다.

실시간 자동 모니터링

자동화된 실시간 모니터링은 구성을 원하는 상태로 유지하는 데 가장 발전된 방법입니다. 이를 위해서는 서버 또는 서버 그룹을 생성하고, 전용 서버 설정 도구를 사용하여 구성을 설명해야 합니다.

이러한 프로그램은 경량 에이전트를 사용하여 해당 그룹 내의 서버 구성을 모니터링하고 정의된 설정과 비교합니다.

이 자동화된 프로세스는 드리프트가 발생하면 즉시 경고를 보내고, 일반적으로 서버 드리프트를 수정하기 위한 몇 가지 옵션을 제공합니다.

결론:

컴퓨터 또는 장치 간의 CI(구성 항목) 불일치는 구성 드리프트의 근본적인 원인입니다. 구성 드리프트는 소프트웨어 및 하드웨어 수정이 제대로 문서화되거나 추적되지 않고 즉흥적으로 수행될 때 데이터 센터 환경에서 자연스럽게 발생합니다.

많은 고가용성 및 재해 복구 시스템 오류는 구성 드리프트로 인한 것입니다. 관리자는 구성 드리프트를 최소화하기 위해 하드웨어 장치의 네트워크 주소뿐만 아니라 하드웨어 장치에 설치된 소프트웨어 버전 및 업그레이드에 대한 세심한 기록을 유지해야 합니다.