Part 1: Rethinking Networking with Automation on Designing Network Automation at Scale

01 - 자동화의 필연성

Mon, 01 Jan 0001 00:00:00 +0000

1. 자동화의 필연성#

“자동화할 것인가, 하지 않을 것인가 - 그것이 문제다.”

Software-Defined Networking (SDN)과 DevOps가 등장한 이후로, 엔지니어들은 네트워크 자동화가 필수인지, 사치인지, 아니면 과도한 엔지니어링인지 논쟁해왔다. 답은? 상황에 따라 다르다. 하이퍼스케일러들은 반드시 필요하다: 그들은 선택의 여지가 없었기 때문에 2010년대 초반부터 시작했다. 소규모 기업은 전면적인 자동화가 전혀 필요하지 않을 수도 있다. 대부분의 네트워크는 그 중간 어딘가에 있다. 문화, 기술, 도구 성숙도, 비즈니스 우선순위 모두 채택 속도에 영향을 미친다. 오늘날, 이러한 요소들이 하나로 수렴되고 있다. 자동화는 불가피해지고 있다.

02 - 설계 원칙

Mon, 01 Jan 0001 00:00:00 +0000

2. 설계 원칙#

한 네트워크 자동화 팀이 6개월을 들여 진심으로 자랑스러워하는 시스템을 구축했다. 구조화된 데이터 모델에서 인텐트를 가져와 템플릿 엔진으로 장비 설정을 생성하고, 정책 라이브러리에 대한 변경 사항을 검증하며, 완전한 롤백 지원과 함께 NETCONF를 통해 푸시했다. 아키텍처적으로 견고했다. 리더십에 대한 데모는 잘 됐다. 그런 다음 그들은 네트워크 운영 팀에 넘겼다.

채택은 일어나지 않았다. 운영자들은 계속 CLI를 사용했다. 이유를 물었을 때 답변은 일관됐다: “실행하기 전에 무엇을 할지 모르겠어요.” “무언가 잘못되면 무슨 일이 있었는지 알 수가 없어요.” “출력 결과를 어떻게 읽는지 모르겠어요.” 자동화 팀은 기술적으로 인상적이지만 운영상 불투명한 것을 구축했다. 드라이런 모드도 없고, 사람이 읽을 수 있는 변경 미리보기도 없고, 운영자가 인식하는 방식으로 작성된 감사 추적도 없었다. 시스템은 아직 신뢰를 얻지 못했으면서도 신뢰를 요구하는 블랙박스였다. 6개월의 엔지니어링 노력이 사용되지 않은 채 방치됐다.

03 - 아키텍처적 사고

Mon, 01 Jan 0001 00:00:00 +0000

3. 아키텍처적 사고#

이 장은 이 책의 기초를 소개한다. 이 마인드셋을 채택해야 하는 이유를 설명하고, Network Automation Forum (NAF)이 제안하는 참조 프레임워크를 소개하며, 프로젝트에서 이를 어떻게 활용하는지 보여준다.

2부에서 이러한 주제들을 깊이 다룬다. 이 장에서는 세부 사항에 들어가기 전에 전체적인 그림을 제공하기 위해 간략하게 소개한다. 각 구성 요소를 설명한 후에 전체 그림을 갖는 것이 점들을 연결하는 데 도움이 되기 때문에 이것이 중요하다.

하지만 나는 무엇을 하기 전에 왜를 이해하는 것을 강하게 믿는다. 먼저 아키텍처를 활용해야 하는 이유를 이해해보자.