전달 및 배포 툴체인: 여전히 가장 약한 링크 공리의 적용을 받음

요즘은 DevOps 지원 툴체인을 언급하지 않고는 돌아볼 수 없을 정도입니다. 누구나 하나씩 갖고 있고 (우리도 마찬가지) 모두 (다른) API 경제를 통해 가능해졌습니다. Wikipedia에 따르면 DevOps 툴체인은 " DevOps 관행을 사용하는 조직에서 조정하는, 소프트웨어 개발 라이프사이클 전반에 걸쳐 애플리케이션의 제공, 개발 및 관리를 지원하는 도구 세트 또는 조합"입니다.

이제 주로 앱에 초점을 맞추지만, 소프트웨어가 일반적으로 수명의 상당 부분을 보내는(적어도 그럴 것이라고 바라는) 프로덕션 측면도 있습니다. 동일한 정의가 이 경우에도 적용되지만, 초점은 (내 관점에 따르면) "DevOps 관행을 사용하는 조직에서 조정하는 앱 수명 주기 전반에 걸친 네트워크 및 앱 서비스의 프로비저닝, 구성 및 관리"에 맞춰져 있다는 단서가 있습니다. 기존 DevOps 맥락에서 이러한 초점은 사이클의 "릴리스" 단계를 확장하고 소프트웨어를 프로덕션에 프로비저닝하고 배포하는 것을 포함하는 "릴리스 관련 활동"을 포괄합니다. 여기에는 대상 사용자에게 안전하고 보안된 애플리케이션을 제공하는 데 필요한 네트워크 및 앱 서비스가 반드시 포함됩니다(또는 포함되어야 합니다).

문제는 어떤 단일 공급업체나 오픈 소스 프로젝트도 지속적인 배포(그건 그렇고, 프로덕션 측면에서 말이죠)라는 이상적인 꿈을 이루는 데 필요한 모든 도구를 갖추고 있지 않다는 것입니다. 실제로 앱 개발 측면에서 사용되는 도구 중 일부는 프로덕션 측면에서도 사용됩니다. 점점 더 두 세계 사이의 교차를 보고 있는데, 이는 "DevOps" 전반에 좋은 신호입니다. 이는 앱을 제외하고는 공통점이 거의 없는 두 개의 매우 뿌리 깊은 조직 간의 어느 정도 정상화를 보여주기 때문입니다.

따라서 VMware와 Cisco와 함께 Puppet이나 Chef를 사용하면 앱의 보안, ID, 확장성 요구를 충족하는 전체 네트워크 및 앱 서비스 스택을 자동화할 수 있습니다. 이를 위해 필요한 적용 가능한 템플릿과 스크립트를 만들고 그것들이 올바른지 확인했으며, 아마도 Postman과 그 스크립팅 기능을 사용하여 실험실에서 가상 인프라를 테스트했을 것입니다. 앱 개발자가 이미 git을 사용하고 있으며 지침을 제공하고 심지어 1~2회의 교육 세션을 개최할 수도 있으므로, 구성 아티팩트의 저장소로 git이 좋은 선택이라고 결정했습니다. 그리고 더 나아가 앱을 구축하거나 OpenStack 구현을 시작하여 프로세스를 조율하고 개별 서비스의 셀프 서비스를 제공할 수도 있습니다. 기본적으로 배포 툴체인을 정의하는 것입니다.

여기서 가장 약한 고리 공리(Weakest Link Axiom)가 추악한 모습을 드러내기 시작합니다. 여러분은 전제를 알고 있을 겁니다. 사슬은 가장 약한 고리일 뿐이라는 거죠. 여기서 "강력함"이 강조되는 이유는 이를 "신뢰할 수 있는" 또는 "안전한" 또는 "확장 가능한"과 같은 다른 특징으로 대체할 수 있고 이 공리 역시 사실로 유지되기 때문입니다. 이는 지속적인 배포를 지원하는 툴체인을 정의하기 시작하면 해당 체인의 각 "링크"가 보안, 규모 또는 가용성이 손상되는 장애 지점이 될 수 있기 때문에 중요합니다.

DevOps 툴체인에서 계획, 검증, 모니터링이 중요한 링크인 것처럼 NetOps 툴체인에서도 이러한 링크가 반드시 필요합니다. 이는 특히 모니터링의 경우 중요한데, 프로덕션 환경에서 앱과 인프라(네트워크 및 앱 서비스)가 가장 많이 교차하기 때문입니다. 장애 발생 시 비즈니스 거래부터 개별 요청 및 응답까지 모든 것을 종합적으로 볼 수 있는 모니터링(가시성)을 통해 파악할 수 있습니다.

구성은 네트워크 및 앱 서비스의 구성이 주어진 애플리케이션에 고유할 수 있으므로(종종 고유할 수도 있음) 툴체인을 반드시 연결해야 합니다. 

패키징과 릴리스 메커니즘이 비슷한 도구를 활용할 수 있지만, 이 둘은 별개의 문제이며 요구 사항 측면에서 종종 큰 차이를 보입니다. 네트워크 및 앱 서비스가 공유 인프라에 배포될 수 있으므로 단일 시스템 접근 방식을 가정하는 도구는 NetOps에 적합하지 않을 수 있습니다. 반대로, 프로덕션에서 표준화된 서비스를 빠르게 배포하기 위해 템플릿을 사용하는 경우가 점차 늘어나고 있지만, 애플리케이션이 높은 수준의 고유성을 보이는 DevOps에는 거의 적용되지 않습니다.

그럼에도 불구하고 두 툴체인 모두 공통점이 있습니다. 즉, 하나의 링크가 취약해서 전체 체인에 영향을 미친다는 것입니다. 스크립트를 활용하는 수동 기반 배포에 주로 의존하더라도 전반적인 전달 및 배포 프로세스를 나타내는 툴체인이 여전히 있습니다. 사람들은 오늘날 소프트웨어를 제공하고 배포하는 툴체인의 링크가 될 수 있으며, 실제로 링크가 됩니다. 그리고 중요한 연결 고리가 없으면(예: 밥이 최근 독감에 걸려 외출하는 경우) 프로세스가 중단됩니다. 툴체인이 전달(또는 배포)에 실패합니다.

내부 디지털 혁신을 계속 진행하면서 DevOps 및 NetOps 툴체인의 중요성을 인식하고 이를 구성하는 링크 중 어느 것도 간과하지 않는 것이 중요합니다. 지속적인 배포라는 목표를 달성하는 데 있어 단 하나의 링크에만 주의를 기울이지 못하면 전체 체인이 약화됩니다. 기업이 이런 상호 연결된 사슬에 점점 더 의존하게 되면서, 약한 고리는 프로세스만을 망가뜨리는 것이 아니라 기업 자체도 망가뜨립니다.