NetOps 자동화에 선언적 모델이 중요한 이유는 무엇입니까?
모든 것을 자동화하려면 선언적 방식을 사용해야 합니다. 그 이유는 다음과 같습니다.
자동화에 대해 이야기할 때마다 우리는 꽤 오랫동안 선언적 드럼을 두드려 왔습니다. 특히 NetOps 및 애플리케이션 서비스와 관련하여 말입니다. 하지만 우리는 그것이 왜 중요한지, 그리고 어떤 이점이 있는지에 대해서는 깊이 파고들지 않았습니다. 저는 지금 당장 그 문제를 바로잡고 싶습니다.
기억을 되살려 설명하자면, 현재 모든 것의 구성과 배포를 자동화하는 데 사용되는 두 가지 모델이 있습니다.
첫 번째는 필수적입니다. 즉, 우리가 원하는 것을 어떻게 수행할지 대상 시스템에 정확하게 알려주는 것입니다. 시스템에 SSH 터널을 열고 CLI에서 특정 명령 세트를 입력한 적이 있다면 필수 구성 모델에 참여했을 것입니다.
두 번째(그리고 선호되는) 방법은 선언적 방법으로, 대상 시스템에 무엇을 해야 하는지 알려주지만 어떻게 해야 하는 지는 알려주지 않습니다. 이 모델은 대부분의 네트워크 자동화 솔루션에서 여러 가지 이유로 채택한 모델입니다. 가장 두드러진 이유는 주어진 환경에 존재할 수 있는 수백 개의 장치와 시스템을 학습하고 통합하는 데 필요한 엄청난 비용과 시간 때문입니다.
따라서 명령형 모델에서는 시스템을 구성하는 데 필요한 각 명령(또는 API 호출)을 구체적으로 지정해야 합니다. 선언적 모델에서 우리는 원하는 것을 설명하는 특정 키-값 쌍(일반적으로)만 사용하고 다른 시스템이 명령을 실행하여 원하는 것을 실행하게 합니다.
아주 간단하죠, 레몬즙만 짜면 돼요.
이제 이것이 왜 중요한지 질문에 답하겠습니다. 모든 것을 자동화하기 위해 선언적 모델을 채택하면 네 가지 주요 이점이 있습니다.
1. 인간의 오류를 줄이세요
생산 과정에서 발생하는 중단 사고의 약 22%가 인적 오류로 인해 발생한다는 사실을 알고 있습니다. 아직 다시 언급하지는 않겠지만, 꽤 눈에 띄는 몇몇 사건들은 단순한 인적 오류에서 직접 기인한 것으로 밝혀졌습니다. API 호출에 의존하는 명령형 모델에서 각 호출은 발생을 기다리는 잠재적인 사고입니다. 변수를 검증하지 않았거나 오류 코드를 확인하는 것을 잊었거나 그 밖에 가능한 시나리오가 수백 가지나 있다면 이력서 생성 이벤트가 발생할 수 있습니다. 그건 나쁜 일이야.
선언적 모델은 API 호출을 사용하여 실행하기 전에 구문 분석하고 검증되는 일종의 템플릿이나 구성 파일을 기반으로 합니다. 물론 여전히 구성 파일이나 템플릿을 엉망으로 만들 수는 있지만, 필요한 코드가 줄어들기 때문에 그럴 가능성은 제한됩니다. 그리고 일반적으로 코드가 적으면 실수를 할 가능성도 적어집니다.
2. 기술 부채 감소
기술적 부채는 개발 과정에서 접한 재밌는 은유로, 우리의 선택에 따른 장기적 비용을 상기시켜줍니다. 기술적 부채는 여러 가지 방법으로 필수 모델에서 증가합니다. 첫째, 스크립트를 대상 시스템의 API에 결합하는 것입니다. 해당 API는 다른 기능을 지원하지 않을 가능성이 높으므로 시스템별로 스크립트를 개발해야 합니다. 구성 단계는 앱마다 다를 가능성이 큽니다. 모든 것이 HTTP는 아니고 모든 HTTP 기반 애플리케이션에 정확히 동일한 서비스 구성이 필요한 것은 아닙니다. 이제 우리는 앱별, 시스템별로 스크립트를 작성하고 있습니다. 그렇게 되면 스크립트가 많아지고, 그 선택에 따라 빚이 많이 쌓이게 됩니다.
반대로, 선언적 방식은 동일한 배포 프로세스 스크립트와 시스템을 사용할 수 있습니다. 템플릿/구성은 여전히 애플리케이션과 시스템에 따라 다를 수 있지만 단일 파일입니다. 이를 통해 스크립트의 복잡성과 개수가 제거되어 기술 부채가 획기적으로 줄어듭니다. 현실은 우리의 선택으로 인해 항상 어느 정도의 빚이 발생할 것이라는 것입니다. 이를 최소화하는 것이 목표입니다.
3. 버전 충돌 제거
구성 및 배포 프로세스를 API에 연결하면 해당 버전 의 API에 연결됩니다. 인터넷에는 API 변경 사항과 앱을 변경하는 데 필요한 작업에 대해 적대적이고 화가 난 개발자가 있는 커뮤니티가 많이 있습니다. 네트워크 및 애플리케이션 서비스에서도 동일한 일이 발생할 수 있습니다(그리고 발생할 것입니다). 그러면 API의 한 버전에 묶여 있고 무언가가 변경되면 어떻게 될까요? 소들이 집에 돌아올 때까지 대본을 업데이트(또는 다시 쓰기)하게 될 거예요*.
하지만 선언적 모델을 채택했다면 API의 모든 변경 사항을 무시할 수 있을 것입니다. 결국 API를 사용하여 시스템에 서비스를 배포하는 방법을 알려주는 것이 아니라 배포해야 할 내용을 알려주는 것입니다.
4. 도메인 전문성 요구 사항 감소
솔직히 말해서, 네트워크나 애플리케이션 서비스에 API를 사용하려면 시스템을 이해해야 합니다. 가상 IP와 가상 서버의 차이를 모른다면, 글쎄요, 당신은 이미 문제에 봉착한 겁니다. 아직 노드와 멤버에 대한 내용은 간신히 다루었습니다. 필수적인 API 기반 방법을 사용하려면 구성을 탐색할 수 있을 만큼 대상 시스템을 잘 이해해야 합니다.
선언적 모델을 사용하면 대상 시스템에 대한 전문 지식이 덜 필요하므로 개발자와 DevOps 모두 셀프 서비스 애플리케이션에 이 방법을 사용할 가능성이 더 높습니다. 물론 여전히 전문가가 필요하지만 서비스 소비자의 요구 사항이 완화되고 더 광범위한 구성원에게 프로비저닝 및 배포 부담이 분산됩니다.
NetOps 자동화 노력에 선언적 모델을 채택하려는 다른 이유도 있지만, 이 네 가지가 가장 설득력이 있습니다. 이는 NetOps, 비즈니스 및 네트워크와 앱을 더 빠르고 안전하게 만드는 애플리케이션 서비스에 대한 셀프 서비스 액세스가 필요한 확대되는 구성 요소에 이점이 있기 때문입니다.