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

구성 드리프트는 모든 IAAC 개발자에게 중요한 관심사입니다. 이 게시물에서는 구성 드리프트 관리, 그 중요성, 원인 및 잠재적 솔루션에 대해 알아봅니다.

구성 드리프트란 무엇입니까?

애플리케이션 소유자는 고객 경험을 지속적으로 향상시키기 위해 시간이 지남에 따라 앱과 기본 인프라를 변경해야 합니다. 이러한 고객은 회사 내부 또는 외부에 있을 수 있습니다.

이러한 업데이트 및 변경의 결과로 앱 및 인프라 구성이 변경됩니다. 이러한 수정은 시스템의 강화된 상태에 도움이 되거나 저하될 수 있습니다. 구성 드리프트는 이에 대한 용어입니다.

구성 드리프트 작동 방식

구성 드리프트의 가능성은 소프트웨어 생산 및 제공 시스템의 복잡성과 함께 증가합니다. 코드는 일반적으로 개발자의 워크스테이션에서 공유 개발 환경, 테스트 및 QA 환경, 그리고 최종적으로는 스테이징 및 프로덕션 환경으로 전송됩니다.

잠재적인 영향은 파이프라인을 따라 드리프트가 발생하는 거리에 따라 증가합니다. 개발자의 랩톱에 설치된 패키지 버전과 테스트 서버에 설치된 버전 간에 약간의 차이가 있어도 문제 디버깅이 지연될 수 있습니다. 일반적으로 스테이징과 프로덕션만 서로의 복제본이 될 것으로 예상됩니다. 많은 기업이 매일 여러 번 새 코드를 배포하기 때문에 부담이 가중됩니다.

구성 드리프트의 일반적인 원인

의사 소통의 부족

때때로 업스트림 팀은 변경 사항에 대해 다운스트림 파트너와 의사 소통하지 못하고 결과적으로 전체 다운스트림 시스템이 고장납니다.

핫픽스

핫픽스는 다음 계획된 응용 프로그램 업데이트까지 기다릴 수 없는 중요한 문제를 해결하기 위해 코드를 변경한 것입니다. 때때로 문제 해결을 위해 노력하는 엔지니어가 파이프라인의 다른 환경에 대해 변경하거나 동일한 수정 사항을 문서화하는 데 실패하여 결과적으로 드리프트가 발생합니다. 종종 원래 문제를 다시 도입하면 이 드리프트가 해결됩니다.

중요 패키지 업데이트

중요 패키지 업데이트는 핫픽스와 다소 유사합니다. 둘 다 빠른 속도로 수행됩니다. 주요 차이점은 향후 사고를 피하기 위해 중요한 패키지 업데이트가 적용된다는 것입니다. 따라서 이러한 업데이트는 핫픽스와 같은 방식으로 드리프트를 유발할 수 있습니다.

자동화 부족

자동화가 구성 드리프트의 가능성을 완전히 제거하지는 않습니다. 기회가 줄어들 뿐입니다.

편의성 변경

개발자가 변경한 사항이 일시적인 경우가 있습니다. 예를 들어, 개발자가 일부 기능을 테스트하기 위해 테스트 서버에 새 패키지를 설치하고 원래 상태로 되돌리는 것을 잊어버린 경우 드리프트가 발생합니다.

구성 관리가 중요한 이유는 무엇입니까?

구성 드리프트가 매우 피해를 줄 수 있는 이유 중 하나는 드리프트를 지속적으로 찾는 사람이 없으면 벽 뒤에 있는 집에서 약간의 누수가 있는 것처럼 드리프트가 인프라 기반을 점차적으로 약화시켜 발견되지 않을 수 있기 때문입니다.

구성 드리프트가 발견되면 이 모든 것이 발생한 구성 드리프트의 근본적인 원인을 찾는 데 시간이 걸리며 이는 긴급 상황에서 귀중한 자원입니다.

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

비용 절감

  IT 인프라에 대한 자세한 이미지가 있는 경우 중복 또는 과잉 프로비저닝을 식별하여 필요한 전체 양을 낮출 수 있습니다.

생산성 향상

  안정적이고 잘 알려진 구성의 클러스터를 통해 일괄 관리 및 인프라 구축이 가능합니다. 또한 고유(또는 눈송이) 서버를 제한하여 개별 설정을 수동으로 관리해야 하는 요구 사항을 줄입니다.

더 빠른 디버깅

일관된 구성을 통해 디버깅 팀은 구성 실수를 배제할 수 있습니다. 팀은 서버, 서버 클러스터 또는 환경 간의 구성 불일치를 찾을 필요가 없기 때문에 티켓을 더 빨리 해결하여 다른 잠재적 원인에 집중할 수 있습니다.

구성 편차로 인해 발생하는 문제

보안 문제들

안전하지 않은 구성은 보안 침해의 가장 흔한 원인 중 하나입니다. 보호된 구성으로 시작하더라도 구성 드리프트로 인해 다른 공격 및 네트워크 위반이 발생할 가능성이 높아집니다.

중단 시간

  공격자가 DoS 결함을 사용하거나 중요한 서버를 손상시킬 수 있는 구성 오류로 인해 상당한 가동 중지 시간이 발생할 수 있습니다. 하지만 그게 다가 아닙니다. 성능에 영향을 미치는 네트워크 장치의 구성을 수정한다고 가정해 보겠습니다. 언제든지 "황금 구성"으로 돌아갈 수 있습니다. 맞죠? 해당 구성에 결함이 있는 경우 서비스를 복원하는 데 훨씬 더 오래 걸립니다.

규정 준수 실패

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

성능 저하

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

낭비 된 시간

잘 이해하지 못하거나 네트워크 설명서와 일치하지 않는 네트워크 문제를 해결하는 데 오랜 시간이 걸릴 수 있습니다. 즉, 구성 드리프트로 인해 네트워크가 의도한 상태에 있었다면 존재하지 않았거나 해결하기 쉬웠을 IT 문제 해결 문제가 발생할 수 있으며 사용자에게 다운타임이 발생할 수 있습니다.

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

완벽한 세상에서 개발자를 위한 모든 환경 서버(Dev/QA/Staging/Prod)는 동일한 구성을 갖습니다. 불행히도 사물이 "실제" 세계에서 작동하는 방식이 아닙니다. 상업 환경에서 애플리케이션 소유자는 소프트웨어에 새로운 기능이 도입될 때 인프라를 자주 수정합니다.

구성 드리프트를 모니터링하는 것은 소프트웨어 환경이 가능한 한 동질적인지 확인하는 데 중요합니다. 관리를 구성하면 비용이 절감되고 생산성과 디버깅 시간이 향상되며 사용자 경험이 향상됩니다.

가능한 한 성공적인 모니터링을 위해 조직은 구성 관리를 사용하고 구성 드리프트를 모니터링하는 경우에도 실수를 피해야 합니다.

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

CMDB를 유지 관리하지 않음

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

CMDB를 유지 관리하지 못하면 한 항목의 구성이 다른 항목에 미치는 영향을 완전히 이해하지 못하는 위험에 노출됩니다. 조직은 결과를 이해하지 못한 채 인프라와 보안을 손상시킬 위험이 있습니다.

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

구성 편차를 모니터링하는 방법에 대한 계획이 없음

조직에는 감시해야 하는 거대하고 복잡한 인프라가 있는 경우가 많습니다. 가장 모니터링해야 하는 구성 요소를 결정하는 것이 중요합니다. 그렇지 않으면 구성 관리가 빠르게 관리할 수 없고 혼란스러워질 수 있습니다.

조직은 회사 모니터링 및 특정 사업부에 필수적인 자산을 지정해야 합니다. 가장 중요한 시스템이 감시될 것이며, 이는 단위 및 산업별로 다를 것입니다.

자동으로 모니터링하지 않음

조직은 여러 가지 방법으로 구성 드리프트를 모니터링할 수 있습니다. 그러나 일부 접근 방식은 다른 접근 방식보다 더 세련되고 성공적입니다.

구성 드리프트를 수동으로 모니터링하려면 비용과 시간이 많이 소요됩니다. 수동 모니터링은 또한 인적 오류의 가능성을 노출합니다. 회사의 인프라 공간이 매우 작은 경우가 아니면 구성 드리프트를 모니터링하는 가장 좋은 기술이 아닙니다.

자동 모니터링은 구성을 원하는 상태로 유지하는 가장 개발되고 효율적인 방법입니다. 전용 구성 모니터링 시스템은 드리프트를 즉시 감지할 수 있으며 빠른 수정을 포함한 솔루션을 자주 제공합니다. 이렇게 하면 비즈니스 인프라가 가능한 한 빨리 최소한의 영향으로 원하는 상태로 돌아갈 수 있습니다.

구성 편차를 모니터링하는 방법:

구성 드리프트가 야기할 수 있는 손상을 알게 되면 구성 드리프트를 감지하는 것이 가장 중요한 관심사가 되어야 하는 이유가 분명해집니다. 무엇을 보존해야 하고 왜 그것이 드리프트를 생성한 변화로 제시되었는지를 아는 것이 그 과정의 첫 번째 단계입니다.

당신이 찾고있는 것을 알고

조직 전체에 중요한 구성 요소와 각 사업부에 중요한 구성 요소를 식별하여 조직을 분류할 수 있습니다.

이는 단위에 따라 다르며 규제가 심한 산업에서 광범위하거나 시스템에 중요한 파일/응용 프로그램에만 집중할 수 있습니다. 시스템의 중요성은 모니터링 시스템의 빈도와 심각성을 결정합니다.

기준선 설정

다양한 설정으로 인해 프로덕션 환경과 테스트 단계 사이에는 항상 차이가 있습니다. 드리프트를 확인하기 위한 기준선은 각 단계가 무엇이어야 하고 허용 가능한 편차 유형을 정의하여 생성됩니다.

초기 테스트 단계는 사용자 승인 테스트 설정 또는 제로 드리프트 제조 단계보다 더 높은 드리프트 허용량에 더 적합할 수 있습니다.

시스템 모니터링

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

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

모니터링은 구성의 기준선과 허용 가능한 간격이 정의된 후 인프라가 적절한 구성으로 유지되도록 해야 합니다. 모니터링 전략이 없으면 구성 계획 및 문서화를 구성하는 데 시간이 낭비됩니다.

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

지속적인 수동 모니터링

개별 시스템 구성을 수동으로 검토하고 알려진 구성 파일과 비교할 수 있습니다. 인간적인 측면으로 인해 이 프로세스는 여전히 오류가 발생하기 쉽고 직원 시간과 관련하여 비용이 많이 듭니다. 나는 소수의 특정 서버 클러스터나 적당한 인프라 공간을 가진 회사를 위해 소규모로만 사용해야 합니다.

감사

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

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

감사는 미리 결정된 일정에 일관되고 반복 가능한 서버 구성을 보장합니다.

그러나 다음 감사까지 설정이 드리프트되어 점점 더 유지됩니다.

실시간 자동화 모니터링

자동화된 실시간 모니터링은 구성을 원하는 상태로 유지하는 가장 정교한 방법입니다. 이렇게 하려면 전용 서버 설정 도구를 사용하여 구성해야 하는 방법에 대한 설명과 함께 서버 또는 서버 그룹을 만들어야 합니다.

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

이 자동화된 프로세스는 드리프트에 대해 즉시 경고하고 일반적으로 서버 드리프트를 수정하기 위한 몇 가지 선택 사항을 제공합니다.

마지막 단어:

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

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