All Things APAC
Moderator Moderator , Moderator Moderator Moderator
All Things APAC
자동화된 NetOps를 위한 5단계
Dec 7, 2018

주니퍼 네트웍스의 5단계 프레임워크가 새롭게 바뀌었습니다. 데이터센터, 캠퍼스, WAN, 브랜치를 위한 5단계와 같이 각각의 네트워크 도메인에 초점을 맞추는 대신, 모든 도메인 전반에서 네트워크 자동화를 실현하는 데 중점을 두었습니다. 이 5단계는 네트워크 어디에나 적용할 수 있습니다. 예를 들어, 데이터센터 5단계 위에도 오버레이가 가능합니다.

5kr.png

 

 

네트워크 자동화를 위한 5단계가 아님

 

사다리를 타고 올라간 후에 잘못된 벽에 서 있는 것을 깨닫는 경우가 종종 있습니다.

 

수십 년에 걸쳐 네트워크 자동화를 추구하면서, 대부분의 이야기와 발전은 NFV 및 SDN에 자리를 내어준 프로그래밍 기능에 관한 것들입니다. 이러한 발전에도 불구하고 지금 네트워크 자동화가 다시 원점으로 후퇴한 듯 합니다. 소프트웨어 엔지니어링과 관련 DevOps와 SRE는 혁신적인 발전을 이룬 반면, 일반적인 NetOps 작업은 사실상 제자리에 머물러 있습니다.

 

네트워크 자동화가 전혀 진전되지 않았다는 뜻은 아니지만, 대부분의 발전은 제품의 내부적 작동 방식에 있어 기술적인 변화가 있었을 뿐입니다. 즉, 자율적인 시스템을 조금 더 갖추었고, 네트워크의 더 많은 공개 영역에서 시스템을 추상화하고 개선했으며 API를 추가적으로 구축하여 시스템의 자동화를 약간 더 향상시켰을 뿐입니다. 그러나 이러한 모든 단편적인 네트워크 자동화 노력으로는 자동화된 네트워크를 구축하지 못합니다.

 

무엇을 바꾸지 못했을까요? 그것은 바로 자동화를 실현할 수 있는 대상인 오랜 고객와 NetOps입니다.

 

벤더에서 고객으로 전달되는 과정은 여전히 사일로화되어 있으며 무분별하게 진행됩니다. NetOps는 DevOps가 이룬 결과물을 잘 파악한 후에 이를 업무에 적용해야 합니다. 그런 다음, 설계 초기부터 판에 박힌 진부한 문제들과 동의하기 어려운 관리 업무, 그리고 수많은 지루한 일상의 노동과 문제 해결에 시달리면서 가용성을 유지하기 위해 노력해야 합니다. 또한 IT 문제를 분류하면서 가장 먼저
기본적으로 꼽히는 요소인 네트워크도 잊어서는 안 됩니다.

 

경험에 비추어 볼 때 NetOps는 자동화 가능 단계에서 자동화 단계로 진화하기 위해 자동화를 더욱 강조해야 하는 분야입니다. 그리고 변화의 과정에서는 기술과 단절된 상태로는 자동화를 고려할
수 없겠지만, 대신 사람과 프로세스를 개선하는 데 특히 관심을 쏟아야 합니다.

 

어디서부터 시작할까요?

 

사람과 프로세스를 혁신하는 것은 실로 어려운 일이지만, 쉽게 따라할 수 있는 방법이 있습니다. DevOps의 탄생은 제조 산업의 교훈을 발판으로 소프트웨어 엔지니어링 방식을 변화시켰으며, 이제 가장 성공적인 NetOps 팀도 DevOps를 모방하고 있습니다.

 

개발자와 관련 앱 팀은 종종 IT의 분위기에 편승해 네트워크 엔지니어들에게 골칫거리를 던져 놓기도
하기 때문에 네트워크 엔지니어는 개발자라고 불리는 것을 좋아하지 않는다고 합니다. DevOps 또는 DevNetOps 용어에 비해 “개발자”라는 용어는 네트워크 엔지니어에게 거부감을 줄 수도 있습니다. 또한 DevOps는 두리뭉실한 원칙들일 뿐이어서, NetOps 팀은 DevOps가 구체적으로 구현된 SRE(site reliability engineering)에서 힌트를 얻어 그들의 혁신적인 작업을 NRE(network reliability engineering)라고 지칭했습니다.

 

NetOps 자동화를 위한 이 5단계 프레임워크는 셀프 드라이빙 네트워크로 전환하기 위한 단계이지만, 대부분의 경우 엔지니어링 안정성과 간소화를 실현합니다. 이러한 과정에서 서비스 레벨 목표 및 안정성 지표 관리를 위한 NRE의 뛰어난 코딩 능력과 자동화 도구 활용 능력이 돋보일 것입니다.

 

프레임워크를 한 장의 지도라고 생각하십시오. 스스로 방향을 잡아 과정을 밟아나가는 것이 항상 쉽지만은 않을 것입니다. 게다가 각자 시작 지점도 다릅니다. 대부분의 네트워크 운영자는 자동화 과정의 "벤치 신세"를 벗어나지 못하고 있습니다. 즉 ITIL 교재를 참조하여 네트워크를 운영하는 1단계인 수동 운영 과정에 머물러 있습니다. 하지만, 엔지니어는 평생 배우는 전문가이어야 합니다. 이들이 1단계에서 머물러 있는 이유는 주저하고 있어서가 아니라 문제를 해결하느라 바쁘기 때문입니다. 게다가 NRE라는 개념이 나오기 전까지는 이들은 네트워크 자동화 논의에서 거론되지조차 않았습니다.

 

첫 번째 단계는 여전히 중요합니다. 하지만 소프트웨어 엔지니어링 배경 지식이 없을 경우 이 과정은 엔지니어에게 매우 어려운 것도 사실입니다. 이런 이유로 주니퍼는 자동화를 위한 첫걸음을 돕기 위해 EngNet, NRE 랩, ATOM, 무료 평가판, 호스팅된 평가판, 랩은 물론 교육과 서비스를 시작했습니다.

 

2단계에서는 일부 NetOps 워크플로우를 구체적으로 분석하고 일부 코딩 및 도구로 수동 작업을 재설계합니다. 이 단계는 자동화 진전을 위한 게이트웨이이자 기존 작업을 개선하는 단계입니다.
이러한 도구를 찾아서 공유하고 활용하면 업무 부담은 줄이면서 자동화를 위해 더 많은 시간을
확보할 수 있습니다.

 

 

단계에 대한 상세 설명

 

1단계 - 수동 운영

 

수동 운영은 진행 방식을 확인하고 함께 조율하는 데에는 실제로 매우 유용합니다. 하지만 노력이 많이 들고 시간이 오래 걸리며 반복적인 작업인 경우, 네트워크 엔지니어가 관련 정보와 워크플로우를 문서화하고 자동화 ROI 평가를 시작하는 것이 좋습니다.

 

 

 

2단계로 이동하려면:

 

  • 자동화 전문가의 사고방식을 내재화합니다. 기술자가 아닌, 빌더이자 기술 전문가가
    되어야 합니다.
  • 문서화된 워크플로우에 따라 자동화합니다. 이 단계는 처음 코딩을 시작하는 임시 워크플로우이고, 여기서 속도, 규모, 일관성을 위해 새로운 도구를 활용할 수 있습니다.
  • CLI 문서 이외에 개별 시스템을 위한 API 문서를 참조합니다.
  • 기존에 활용하던 도구를 찾아 상세 분석합니다. NetOps 워크플로우의 맥락에 맞는 맞춤형 도구를 빌드합니다.
  • 검증된 시스템이 존재하면 전방위적으로 또는 하위 수준에서 불필요하게 자동화를 재현할 필요가 없도록 추상화 및 SDN의 가치를 실현합니다. 검증된 시스템에 기반하여 자동화합니다.

 

2단계 - 워크플로우 자동화

 

2단계에서는 문서화된 워크플로우 또는 의사 코드를 사용하여 소규모로 자동화를 시작합니다. 가장 큰 이점은 반복적인 문제 해결 워크플로우입니다. 실제로 테스트 및 검증의 초기 단계로, 3단계에 유용합니다. 읽기 전용 워크플로우에서 문제를 해결하는 것이 재구성, 재배포 또는 읽기/쓰기 워크플로우에서보다 더 안전합니다. 유지 보수 기간에 변경을 자동화하면 위험이 완화됩니다. 하지만 유지 보수는 비생산적이고 비효율적인 IT 안티패턴이며, 향후 단계에서 파이프라인을 안정화한 후에는 변경 사항을 가장 효과적으로 처리할 수 있습니다.

 

3단계로 이동하려면:

 

  • 임시 자동화 단계 이후로 진행합니다. 코드형 및 “GitOps” 개발자급 동작을 실습하기 시작합니다. 코드란 코드화하는 것을 의미하며 프로그래밍이어야 할 필요는 없습니다. 모든 아티팩트, 구성, 생성에 대해 버전 관리된 데이터 소스와 SCM 워크플로우를 사용합니다.
  • 구성은 배치되지 않고 항상 변하지만, 자동화된 워크플로우를 프로그래밍하는 것처럼 선언화, 코드화되며, 변경 사항이 검토됩니다.
  • 테스트와 센서 모두를 통해 실수와 수동 트리거를 줄이는 방법을 생각합니다.
  • “then that(다음에 수행할 작업)” 2단계 자동화된, 예정에 수동으로 트리거된 어그리게이션 작업을 이제 자동으로 트리거하도록 구성합니다. 따라서 “if this(현재 상황 분석)”를 자동화하여 “then that(다음에 수행할 작업)”을 트리거합니다.
  • Juniper AppFormix 또는 기타 텔레메트리 수집기 및 분석 시스템과 같은 시스템의 데이터와 API를 다음과 같은 용도로 사용합니다. 1. 관찰 기능 및 의사결정, NRE 서비스 수준 표시기 도구로 전환, 2. 사후 대응적 문제 해결에 의존하지 않는 사전 예방적 테스트, 3. “if this(현재 상황 분석)” 센서 자동화

 

3단계 - 자동화된 트리거 코드형 네트워크

 

프로비저닝, 스크립팅 및 프로그래밍 언어를 넘어 3단계에서는 GitOps, 버전 관리 및 코드 검토에
대해 학습합니다. 코드형 인프라를 수용하고 문제 해결 자동화를 테스트 및 사전 예방적 검증 단계로 간주합니다. 테스트 기반 네트워크 자동화는 TDD(test-driven development)에서 착안되었습니다. 스크립트를 실행하고 문제를 해결하는 것만으로는 부족합니다. 오류 예방을 위한 전반적인
테스트를 구성해야 합니다.

 

선제적 테스트 이외에 이벤트 기반 프레임워크에 도움이 되는 일부 자동화된 작업을 선제적으로 트리거할 수도 있습니다. 선제적 트리거를 위해서는 센서를 빌드하거나 사용해야 합니다. 센서는 종종 서비스 레벨 지표를 제공하거나 빌드하는 데에도 유용한 텔레메트리 및 분석 시스템을 기반으로 하기도 합니다.

 

4단계로 이동하려면:

 

  • 모든 변경 사항을 적용할 때 일관성과 더불어 정확성까지 자동화한다는 생각으로 QA 및 테스트를 수행합니다.
  • 테스트 프로세스는 파이프라인의 “코드화”와 배포 프로세스 사이에 삽입됩니다. DevOps 파이프라인을 사용하는 소프트웨어 엔지니어와 마찬가지로, 필요에 따라 이를 DevNetOps 파이프라인 또는 네트워킹 CICD 파이프라인(예: 주니퍼의 NITA 프레임워크)이라고 부를 수 있습니다.
  • 자동화된 변경 테스트의 신뢰도가 높기 때문에 유지보수 없이도 빈번하고 신속하게 구축을 처리할 수 있습니다.

 

4단계 - 지속적인 프로세스 파이프라인

 

기술 및 자동화 런타임이 프로덕션 단계 이전의 프로덕션 전 단계에 포함됩니다. 4단계에서는 자동화된 테스트를 실행하기 위한 CICD 파이프라인을 추가합니다.

 

CI(Continuous integration)를 통해 언제든지 코드 변경 사항을 통합할 수 있습니다. 예를 들어, 프로그래밍 변경, 구성 변경 등이 이에 해당될 수 있습니다. 자동화된 테스트 덕분에 안정적인 변경이 가능해졌습니다. 때때로 수행되는 동시 변경을 안전하게 테스트된 메인 라인에 자동으로 통합하고 배포에 필요한 아티팩트를 구축하는 것이 CD(continuous delivery)입니다.

 

구축 자체를 자동화하는 것도 유용하며(예제) 지속적인 구축(마찬가지로, CD라고 함)으로 이어집니다. 실제 지속적인 구축에는 여전히 수동적인 판단이 필요합니다. 특히 변경할 수 없는 인프라 패턴을 따라도 언제든지 구축 가능하므로, 가동 중단을 염두에 둔 설계 및 자동화가 필요한 제어되고 격리화된 중단으로 가용성을 유지하고 트래픽 손실을 방지할 수 있습니다. 마이크로서비스로 제작된 소프트웨어에서는 Blue-Green, Canary, 롤링 업그레이드 등과 같은 구축 패턴이 가능하지만, 네트워크는 기본적으로 그런 것을 염두에 두고 설계되지 않았습니다. 오늘날의 일부 SDN 시스템은 그런 경우도 있고 중복되거나 조각난 하드웨어 시스템을 통해 거의 근접하게 실현할 수도 있습니다.

 

CICD를 넘어선 CR(continuous response)은 3단계의 이벤트 기반 if-this then-that(현재 상황 분석을 통해 다음에 수행할 작업) 개념을 확장합니다. 또한 CR은 대체적으로 프로덕션 전 단계와 배포 단계가 아닌 프로덕션 도중 단계에서 작동합니다. 머신 러닝, 딥 러닝, 빅데이터 분석을 지원하는 CR을 네트워킹 시스템의 관찰 기능 및 자동화된 규정에 활용하면 사람이 직접 관리할 때에 비해 궁극의 최적화와 효율성을 실현할 수 있습니다. 이 개념에 대한 자세한 내용은 셀프 드라이빙 네트워크에 대한 주니퍼 블로그를 참조하십시오.

 

 

 

5단계로 이동하려면:

  • 도구 및 사고 방식을 NRE/SRE 개념으로 발전시킵니다.
  • 데이터 중심의 운영 문화, 관찰 기능, 계획을 구축합니다.
  • 시스템 효율성, 효과 및 고객 만족도를 파악합니다(예: 상위 IT 조직 또는 SP의 실제 고객).
  • 카오스 엔지니어링 및 실험을 활용하여 시스템 경계, 한계 및 종속성을 이해함으로써 용량 및 what-if(가상) 시나리오를 최적화하고 계획합니다.

 

5단계 - 엔지니어링 결과

 

5단계는 맨 마지막 과정으로서 지속적인 학습 및 성장 과정 중 하나입니다. 이 단계에서는 네트워크 상에서의 신속하고 안전한 반복 및 프로세스 상에서의 세부적인 조정을 통해 우선순위가 높은 안정성 지표와 기타 목표에 집중할 수 있습니다. 네트워크 운영 중에는 중단이 있어서는 안 됩니다. 심층 분석을 통해 문제 및 변화에 대응할 수 있는 능력을 지속적으로 강화하세요.

 

이 단계에서는 네트워크가 더 이상 중심이 되지 않습니다. 대신에 네트워킹에 정통한 NRE가 다른 SRE와 마찬가지로 Error Budget, Toil Budget, SLI(service-level indicator) 등을 통해 안정성을 관리합니다. SLO(service-level objectives)와 SLA(service-level agreements)가 적용되는 사용자를 대상으로 이 작업을 수행합니다. 안정성의 종속 관계를 고려합니다. 예를 들어, 소프트웨어가 통제권에서 벗어난 인프라에서 실행 중인 경우 소프트웨어의 안정성은 해당 인프라의 안정성에 달려 있습니다.

 

이 단계에서 NRE는 개별 문제를 레이어로 보고 스택에서 해당 위치를 파악하는 경향이 있습니다.

 

계약, 자동화 및 절충을 통해 안정성을 관리하되 필요 이상으로 극대화되지 않도록 해야 합니다. 속도, 민첩성, 효율성, 기타 성과는 안정성과 가용성을 최우선으로 하는 NRE에 있어서 부차적인 요소입니다.

 

자세한 내용은 5가지 단계 프레임워크 슬라이드를 참조하십시오. 기술자들은 대부분 5단계 슬라이드에 집착하는데, 발전을 위해서는 무엇을 사용할지보다 어떻게 사용할지가 더 중요합니다.

 

본 교육 과정에 대해 아래에 의견을 남겨 주시기 바랍니다. 그동안 자동화에 대해 얘기하지 못했던 주제들을 이번에 함께 공유할 수 있게 되어 감사드립니다.

0 Kudos