DevOps의 '실패를 위한 구축' 철학은 보안 위험일까요?

베터리지의 헤드라인 법칙을 어기면, 짧은 대답은 '예'입니다. 하지만 오늘날 기술과 관련된 모든 것이 그렇듯, 긴 대답은 그보다 좀 더 복잡합니다.

저는 DevOps가 모든 산업에 널리 퍼졌다고 생각합니다. 모든 조직이 이 접근 방식의 모든 측면을 채택하거나 Netflix처럼 그 원칙에 똑같이 열렬히 집착하는 것은 아니지만, 분명히 일어나고 있는 '일'입니다.

직접적인 증거는 아니지만 2018년 애플리케이션 제공 상태에 대한 우리의 3,000명 이상의 응답자에게 디지털 변환이 애플리케이션 결정에 어떤 영향을 미쳤는지 물었을 때, 가장 많이 나온 답변 3개 중 2개는 'IT 시스템 및 프로세스에 자동화 및 오케스트레이션 도입'과 '애자일로 전환 등 애플리케이션 개발 방식 변경'이었습니다. 저는 두 가지 모두 현대 아키텍처에서 애플리케이션을 개발하고 제공하기 위해 DevOps 접근 방식의 일부를 최소한 도입하는 것에 대한 추론된 반응이라고 생각합니다.

따라서 조직이 DevOps와 관련된 일부 도구와 기술을 도입하는 경우 다른 도구와 기술도 도입한다고 가정할 수 있습니다. 그 중 하나는 (극적인 음악이 흘러나옴) 실패를 위해 노력하는 것일 수도 있습니다.

글쎄, 그 표현은 다소 부정확할 수 있다. 아무도 실패할 시스템을 설계하는 사람은 없기 때문이다. 하지만 그들이 하는 일은 실패에 회복력이 있는 시스템을 설계하는 것입니다. 즉, 예를 들어 인스턴스(서버)가 충돌하면 시스템은 자동으로 해당 인스턴스를 제거하고 새 인스턴스를 시작하여 그 자리를 채울 수 있어야 합니다.

보세요! 실패하기 위해 만들어졌다.

이는 확실히 바람직한 반응입니다. 특히 시스템에 과부하와 수요가 있을 때 더욱 그렇습니다. 그러나 이 접근 방식에는 고려해야 할 위험이 있으며, 이를 나중에 해결해야 한다고 생각합니다.

2017년 초 Cloudflare의 취약점을 생각해 보세요. 문제를 보고하는 데 있어 놀라울 정도로 투명성을 보인 Cloudflare는 기본적으로 문제가 HTTP 파서 확장 프로그램의 결함으로 인해 발생한 메모리 누수(잠재적인 데이터 유출로 이어짐)라고 언급했습니다. 간단히 말해서, 버그로 인해 메모리 누수가 발생하여 인스턴스가 충돌했습니다. 해당 인스턴스는 종료되었다가 다시 시작되었습니다. 실패하도록 설계되었기 때문입니다.    

기록상으로는 이 게시물은 '버그 때문에 Cloudflare를 비난하는' 게시물이 아닙니다. 개발자로서, 저는 자신의 결함이 공개적으로 드러나는 것에 대해 매우 공감합니다. 왜 무언가가 충돌하거나 메모리가 누출되거나 아예 실패하는지에 대한 이유가 거의 없는 상황에서는 그다지 동정심을 느끼지 못합니다.

오늘 포스트의 요점은 바로 이것입니다. 때로는 DevOps 철학이 지지자들에게 실패 후 조사에 대한 방임주의적 접근 방식을 제공하기 때문입니다.

가용성을 보장하기 위해 서비스/앱 장애가 발생하면 서비스를 중단했다가 다시 시작하는 것이 합리적입니다. 물론, 그런 다음 충돌 원인을 조사하여 원인을 파악해야 합니다. 앱은 아무 이유 없이 작동 중단되지 않습니다. 그것이 넘어지면, 무언가가 그것을 밀어냈습니다. 열 번 중 아홉 번은 악용할 수 없는 오류와 같습니다. 블로그에 쓸만한 내용이 없습니다. 하지만 악용될 수 있는 심각한 취약점이 한 번 발생하면 다른 9개에 허비한 노력만큼 가치가 있습니다. 그건 블로그에 글을 쓸 만한 주제이거든요.

이를 무시하는 것은 합리적이지 않습니다.

장애 및 기타 문제를 모니터링하고 경고하는 것 역시 포괄적인 DevOps 프로그램의 핵심 구성 요소입니다. 이는 전체적인 DevOps 접근 방식을 구성하는 CAMS의 "S"입니다. 문화, 자동화, 측정 및 공유. Damon 과 John (2010년에 이 약어를 만들어낸 사람)은 단순히 피자와 맥주에 대해서만 이야기한 것이 아니었습니다(하지만 이는 DevOps 문화의 "C"를 장려하는 좋은 방법이긴 합니다). 이는 데이터와 시스템 상태에 대한 내용이기도 합니다. 알아야 할 사람들이 알 수 있도록 보장하는 것이 중요합니다. 여기에는 시스템 장애도 포함됩니다.

실패, 특히 충돌은 방치되어서는 안 됩니다. 파이프라인의 시스템이 고장나면, 누군가가 그것에 대해 알아야 하고, 누군가가 점검해야 합니다. 이를 무시하는 것은 보안상 위험합니다. 더 나쁜 점은, 이는 사용자의 환경, 사용자의 시스템, 사용자의 코드로 인해 발생 하는 피할 수 있는 위험이라는 점입니다. 당신은 완전한 통제권을 가지고 있으므로 이를 무시할 변명의 여지가 없습니다.

따라서 간단히 말해서 '실패를 위해 구축'하면 앱과 비즈니스의 보안 위험이 노출될 수 있습니다. 좋은 소식은 철학이 '실패하도록 만들어졌다'고 문서상으로 표현되지 않고 실제로는 '실패를 무시하도록 만들어졌다'고 표현된다면 그러한 위험은 완전히 관리할 수 있다는 것입니다.

가용성을 높게 유지하기 위해 다시 시작하더라도 충돌이 발생하는 항목에 주의하세요. 당신은 트위터에서 잘못된 이유로 트렌드에 오르는 것을 피할 수도 있습니다.