구성의 오류(생산에 배포하는 것이 왜 그렇게 어려운가)

DevOps가 소프트웨어를 제공하는 데 효과적이게 하는 기본 규칙 중 하나는 "일찍 테스트하고 자주 테스트하라"는 것입니다. 실제로 CI/CD(지속적인 통합/지속적인 전달) 도메인에는 빌드와 해당 빌드의 자동화된 테스트가 포함됩니다. 개별 구성요소뿐만 아니라 전체 애플리케이션에 대해서도 마찬가지입니다.

테스트 주도 개발(TDD)은 하나의 방법이고, 또 다른 방법은 빌드 및 릴리스 프로세스 자체의 일부로 단위 및 시스템 테스트를 통합하는 것입니다. 기능 테스트와 회귀 테스트는 필수적이며, 매우 민첩한 환경에서는 종종 저장소에 대한 간단한 "커밋"으로 트리거됩니다.

따라서 소프트웨어가 프로덕션 배포를 담당하는 사람들의 손에 "전달"될 때쯤이면 그 준비 상태에 대한 확신이 매우 클 것으로 기대할 수 있습니다.

물론 있다면 저는 이 글을 쓰지 않겠죠?

소프트웨어가 프로덕션에 제공되는 데에 대한 장벽(그리고 그 장벽은 여전히 존재한다는 사실에 유의하세요)은 우리가 종종 철학에서 "구성의 오류"라고 알려진 것에 걸려드는 곳입니다. 이 논리적 오류는 일반적으로 주장과 증명에 적용되지만, 흥미롭게도 저자 Ali Almossawi가 쓴 The Book of Bad Arguments (모든 연령대의 신진 철학자/토론 챔피언에게 강력히 추천하는 책)에서 이 "나쁜 주장"에 대한 간단한 설명의 기초를 형성하는 소프트웨어입니다.

비공식적 오류, 근거 없는 가정, 구성 및 분할

이 소프트웨어 시스템의 각 모듈은 일련의 단위 테스트를 거쳤고 모두 통과했습니다. 따라서 모듈이 통합되면 소프트웨어 시스템은 단위 테스트에서 검증된 어떤 불변성도 위반하지 않습니다 . 현실적으로 개별 부분을 통합하면 종속성으로 인해 시스템에 새로운 복잡성이 도입되고, 이로 인해 잠재적으로 오류가 발생할 가능성이 더 커질 수 있습니다. -- https://bookofbadarguments.com/ p.46

이제 CI/CD 프로세스의 마지막 단계에 이르렀으므로 소프트웨어가 반드시 이런 오류에 빠질 필요는 없습니다. 단위 테스트뿐만 아니라, 해당 단위를 통합하여 완전한 "시스템" 또는 애플리케이션을 형성하는 방법에 대한 테스트도 실시되었습니다.

하지만 생산에 들어가면 다시 세 번째 단계로 돌아가게 됩니다. 우리는 해당 테스트를 기반으로 시스템이 예상대로 계속 작동할 것이라고 가정할 수 없습니다. 그 이유는 애플리케이션의 정의가 소프트웨어와 플랫폼뿐만 아니라 앱을 구동하고 열성적인 소비자와 기업 사용자의 화면에 전달하는 데 필요한 네트워크 및 앱 서비스 구성 요소까지 포함하도록 바뀌었기 때문입니다.

네트워크 및 앱 서비스는 요청과 응답이 전달되어야 하는 데이터 경로에 영향을 미칩니다 . 모든 서비스는 아니지만, 그 중 다수는 실제로 개발자가 예상하지 못한 방식으로 요청과 응답을 수정할 수 있습니다. 따라서 모든 개별 서비스와 앱 구성 요소를 엄격하게 테스트했더라도 프로덕션 환경에 적용되면 애플리케이션에 오류가 발생할 가능성이 있습니다(그리고 그럴 가능성이 높은 경우가 많습니다). 실패. 실수를 저지르세요.

이는 우리가 제작 환경에서 구성의 오류에 빠졌기 때문입니다. 앱 개발자(및 DevOps)는 이런 오류를 알고 사전 프로덕션 테스트에서 이를 해결하지만, 네트워크 계층의 통합은 여전히 통합이며, 실제로 전체의 운영 무결성에 영향을 미칠 수 있다는 점을 인식하지 못하는 경우가 많습니다.

답은 분명해 보입니다. 그럼, 프로덕션에서 테스트해 보겠습니다!

하지만 우리는 그러지 않을 겁니다. 당신과 저는 우리가 그러지 않을 거라는 걸 알고 있습니다. 생산은 공유 환경이기 때문에, 생산 환경에서 엄격한 테스트를 실시하면 공유 리소스와 시스템에 부수적 피해가 발생할 위험이 커지고, 그로 인해 중단이 발생할 수 있습니다. 정전은 수익과 생산성의 감소를 의미하는데, 누구도 그에 대한 책임을 지고 싶어하지 않습니다. 프로덕션에서 가능한 개별 테스트를 수행한 다음, 광고한 대로 무언가가 망가지거나 작동하지 않을 때 나중에 개발자를 비난하는 것이 훨씬 쉽습니다.

이는 결국 프로덕션 네트워크를 잠식하는 소프트웨어 혁명을 조용히 주도하는 요인 중 하나입니다. 과거에는 운영 환경과 일치하는 테스트 환경을 복제하고 유지하는 것이 너무 어렵고 비용이 많이 들었습니다. 공유 인프라 중 일부는 비용이 많이 들고, 많은 공간을 차지합니다. 그 네트워크를 복제하는 것은 재정적으로나 운영적으로 현명하지 않습니다.

그러나 클라우드 컴퓨팅과 가상화로 인해 소프트웨어가 도입되고 널리 사용되면서 소프트웨어 기반 네트워크 복제가 저렴할 뿐만 아니라 코드로서의 인프라와 같은 개념 덕분에 더 쉬워진다는 개념이 대두되기 시작했습니다. 그뿐만 아니라, 이를 복제하고, 테스트하고, 해체할 수도 있습니다. 즉, 리소스를 재활용하여 다른 애플리케이션에서도 동일한 작업을 수행할 수 있습니다.

우리는 아직 거기에 이르지 못했지만, 점점 가까워지고 있습니다. 가상(소프트웨어) 기반 네트워크와 애플리케이션 서비스를 CI/CD 파이프라인에 통합하는 것은 일부 사람들이 생각하는 것보다 실제로 훨씬 더 현실적입니다. 전통적으로 인프라(네트워크) 기반 서비스(로드 밸런싱, 앱 라우팅, 웹앱 보안)는 컨테이너 기반 아키텍처와 같은 환경에 통합되어 소프트웨어 빌드 주기에 긴밀하게 통합되고 있습니다. 소프트웨어 기반 솔루션이므로 최소한 빌드 프로세스의 테스트 단계에 포함될 수 있으며, 이를 통해 프로덕션에서의 배포 시 오류나 결함이 발생하지 않을 것이라는 확신을 가질 수 있습니다.

해당 소프트웨어를 기반으로 " 코드로서의 인프라 "를 적용하면 더욱 발전할 수 있습니다. 정책과 구성을 빌드 및 릴리스 주기 동안 설계하고 세부 조정한 다음 거의 또는 전혀 변경하지 않고 프로덕션에 배포할 수 있다면 프로덕션 환경에서 존재하는 구성적 오류를 제거하는 데 확실히 더 가까워질 것입니다.

앱 서비스 중 가장 앱 중심적인 이러한 서비스가 CI/CD 테스트 단계에 통합될수록 모든 사람이 성공적인 프로덕션 배포에 대한 확신을 가질 수 있습니다.

오늘날 존재하는 또 다른 오류는 "생산"에 대한 테스트가 "생산 시스템"을 의미한다는 것입니다. 프로덕션에서 데이터 경로를 형성하는 앱 서비스가 포함되지 않는 경우가 많습니다. 그래야 오류를 정말로 난해한 수준으로 줄이고 이를 해결하기 위한 시간과 자원을 확보할 수 있습니다.