드리프트 감지와 드리프트 원인 분석 문제 해결

오늘날 DevOps에서 일하는 사람은 자원 코딩이 관찰, 관리 및 자동화를 쉽게 만든다는 데 동의할 것입니다. 그러나 대부분의 엔지니어는 이러한 변화가 새로운 도전 과제를 동반한다는 것도 인정할 것입니다.

아마도 IaC 운영의 가장 큰 도전 과제는 드리프트입니다. 이는 런타임 환경이 IaC로 정의된 상태에서 벗어나 발생하는 시나리오로, 심각한 장기적인 영향을 미칠 수 있는 문제를 야기합니다. 이러한 불일치는 클라우드 환경의 일관성을 저해하여 인프라의 신뢰성과 유지 관리에 잠재적인 문제를 초래하고, 심지어 중요한 보안 및 규정 준수 위험을 초래합니다.

이러한 위험을 최소화하기 위해 이러한 환경을 관리하는 책임자들은 드리프트를 인프라 운영 팀에 대한 고우선 과제(그리고 주요 시간 소모 요소)로 분류하고 있습니다.

이로 인해 원하는 구성과 인프라의 실제 상태 간의 불일치를 표시하는 드리프트 탐지 도구의 채택이 증가하고 있습니다. 드리프트를 탐지하는 데 효과적이지만, 이러한 솔루션은 경고를 발행하고 코드 차이를 강조하는 데 국한되어 있으며, 근본 원인에 대한 더 깊은 통찰을 제공하지 않습니다.

드리프트 탐지가 부족한 이유

드리프트 감지의 현재 상태는 드리프트가 설정된 CI/CD 파이프라인 외부에서 발생하고, 종종 수동 조정, API 트리거 업데이트 또는 긴급 수정으로 거슬러 올라간다는 사실에서 비롯됩니다. 그 결과, 이러한 변경 사항은 일반적으로 IaC 레이어에서 감사 추적을 남기지 않아 도구가 코드 불일치를 표시하는 것에만 국한되는 맹점을 만듭니다. 이는 플랫폼 엔지니어링 팀이 드리프트의 기원과 이를 어떻게 최선으로 해결할 수 있을지에 대해 추측하게 만듭니다.

이러한 명확성 부족은 드리프트를 해결하는 작업을 위험한 과제로 만듭니다. 결국, 그 목적을 이해하지 못한 채 자동으로 변경 사항을 되돌리는 것은 — 일반적인 기본 접근법 — 문제를 일으킬 수 있으며, 문제의 연쇄 반응을 촉발할 수 있습니다.

하나의 위험은 이것이 정당한 조정이나 최적화를 되돌려, 이미 해결된 문제를 다시 발생시키거나 가치 있는 제3자 도구의 운영을 방해할 수 있다는 점입니다.

예를 들어, 갑작스러운 생산 문제를 해결하기 위해 일반적인 IaC 프로세스 외부에서 적용된 수동 수정을 생각해 보십시오. 이러한 변경 사항을 되돌리기 전에, 그 의도와 영향을 보존하기 위해 이를 코드화하는 것이 필수적이며, 그렇지 않으면 문제가 더 악화될 수 있는 치료법을 처방할 위험이 있습니다.

감지와 맥락의 만남

조직들이 이러한 딜레마를 해결하기 위해 고군분투하는 모습을 보면서 ‘드리프트 원인’이라는 개념이 탄생하게 되었습니다. 이 개념은 AI 지원 논리를 활용하여 대량의 이벤트 로그를 분석하고 각 드리프트에 대한 추가적인 맥락을 제공하며, 변화의 기원을 추적하여 ‘무엇’뿐만 아니라 ‘누가’, ‘언제’, ‘왜’도 밝혀냅니다.

비균일 로그를 대량으로 처리하고 드리프트 관련 데이터를 수집하는 이 능력은 조정 프로세스의 판도를 바꿉니다. 예를 들어, 제가 앞서 언급한 시나리오로 돌아가 드리프트 경고를 감지 솔루션에서 받는 상황을 그림으로 그려보겠습니다 — 이번에는 추가적인 맥락이 포함되어 있습니다.

이제 드리프트 원인이 제공하는 정보를 통해 드리프트를 인지할 뿐만 아니라, 변경이 오전 2시에 John에 의해 이루어졌고, 그 시점에 애플리케이션이 트래픽 급증을 처리하고 있었음을 알 수 있습니다.

이 정보가 없다면 드리프트가 문제가 있다고 가정하고 변경을 되돌려 중요한 작업을 방해하고 하류 실패를 초래할 수 있습니다.

하지만 추가된 맥락 덕분에 상황을 연결할 수 있고, John에게 연락하여 수정이 즉각적인 문제를 해결했음을 확인하고, 무작정 조정하지 말아야 한다고 결정할 수 있습니다. 게다가 이 맥락을 활용하여 향후를 생각하고 구성을 조정하여 확장성을 추가하고 문제가 재발하지 않도록 예방할 수 있습니다.

이것은 단순한 예시이지만, 추가적인 원인 근본 컨텍스트를 가지는 이점을 보여주는 데 좋은 역할을 할 것으로 기대합니다 — 이는 드리프트 감지에서 표준적으로 사용되는 다른 디버깅과 문제 해결 영역에서 오랫동안 부재해온 요소입니다. 물론 목표는 변경된 것 뿐만 아니라 변경된 이유까지 이해하여, 팀이 자신감을 갖고 최상의 조치를 취할 수 있도록 돕는 것입니다.

 

IaC 관리를 넘어

그러나 드리프트에 대한 추가적인 컨텍스트를 갖는 것이 중요하다 할지라도, 이는 훨씬 더 큰 퍼즐의 한 조각에 불과합니다. 코드화된 자원을 활용한 대규모 클라우드 플릿 관리는 규모에 따라 특히 드리프트 문제 외에도 더 많은 도전 과제를 도입합니다. 현재 세대 IaC 관리 도구는 자원 관리에 효과적이지만, 기업 규모 환경에서 더 큰 가시성과 통제 수요는 새로운 요구 사항을 도입하고 필연적인 진화를 촉진하고 있습니다.

이 진화가 향하는 한 가지 방향은 클라우드 자산 관리(CAM)입니다. CAM은 클라우드 환경에서 IaC, API 또는 수동 작업을 통해 프로비저닝된 모든 자원을 추적하고 관리하여 자산의 통합된 보기를 제공하며, 구성, 의존성 및 위험을 이해하는 데 도움을 주어 규정 준수, 비용 최적화 및 운영 효율성에 필수적입니다.

IaC 관리는 운영 측면에 중점을 두는 반면, 클라우드 자산 관리는 클라우드 포지처의 가시성과 이해를 강조합니다. 추가적인 관측 레이어로 작용하여, 코드화된 워크플로와 즉석 변경 사항 간의 간극을 메워 인프라의 포괄적인 전망을 제공합니다.

1+1 Will Equal Three

IaC 관리와 CAM의 결합은 복잡성을 명확하게 이해하고 제어하기 위해 팀에게 권한을 부여합니다. 연말이 다가오면 ‘예측 시즌’입니다 – 그래서 제 예측이 있습니다. 지난 10년 동안 가장 인기 있는(IaC 관리 플랫폼 중 하나로 꼽을 수 있다면) 하나를 구축하고 정제한 경험을 토대로, 이것은 우리 산업의 자연스러운 진화로 보입니다: IaC 관리, 자동화, 그리고 감사를 비코드화된 자산에 대한 강화된 가시성과 결합합니다.

나는 이러한 시너지가 보다 정밀하고 적응 가능하며 미래 지향적인 클라우드 거버넌스 프레임워크의 기초가 될 것이라고 믿습니다. 이제 거의 당연한 것으로 여겨지는 것은 IaC가 클라우드 인프라 관리의 기초임에도 불구하고, 우리는 모든 자산이 항상 코드화될 수는 없다는 점을 인정해야 합니다. 이러한 경우에는 끝-끝 인프라 관리 솔루션이 IaC 레이어에만 국한되어서는 안됩니다.

따라서 다음 단계는 팀이 비코드화된 자산에 대한 가시성을 확대하는 데 도움을 주어, 인프라가 진화함에 따라 시시각각 원활하게 수행될 수 있도록 보장하는 것입니다 – 한 번에 조화된 드리프트를 넘어서.