2019.12.10

데브옵스 프로그램을 시작하는 3가지 방법

Isaac Sacolick  | InfoWorld
데브옵스는 개발 및 운영팀이 협력하는 방식으로의 문화 변화를 의미한다. 자동화, 안정성, 속도와 함께 변화를 전개하는 일련의 베스트 프랙티스이기도 하다. 데브옵스 환경에서는, 코드를 실무에 빈번하게 투입하려는 애자일 개발팀과, 애플리케이션, 데이터베이스, 인프라, 네트워크의 높은 안전성, 보안, 확장성을 지원해야 하는 운영팀이 공통의 이해를 바탕으로 협력한다.



지속적 통합과 배포(Continuous Integration and Continuous Delivery, CI/CD), 코드 기반 인프라 제어(Infrastructure as Code, IaC) 같은 자동화, 컨테이너를 이용한 플랫폼, AI옵스로 관리되는 환경 등이 대표적인 데브옵스 프랙티스 및 기술이다. 데브옵스 프랙티스를 고도화하려면 필수 기술을 가진 인재를 채용하고, 직원을 교육하고, 신기술을 테스트하고, 구현에 대한 이터레이션을 이행하고, 프랙티스를 확장하고 표준화하는 방식을 개발해야 한다.

이들 프랙티스를 전부 테스트하고 싶은 생각도 있겠지만, 현실적으로 이는 기술팀에게 큰 부담이다. 시작할 작은 부분을 파악하고, 성공의 경험을 축적한 후 프로그램을 확대하는 것이 더 현실적이다.

사업 및 기술 목표의 이해
기술팀이 새 툴이나 프랙티스에 투자할 때는 반드시 이를 지지할 동력, 영향, 핵심성과지표(KPI)를 고려해야 한다. 데브옵스 프로그램을 시작하기에 앞서, 기술팀은 현업 측 후원자를 확보해야 하고, 문제와 기회를 규명하고 우선순위를 정한 보고서를 개발해야 한다. 문제 상황은 다음과 같다.

- 긴 애플리케이션 평균 복구 시간(Mean Time To Recovery, MTTR)
- 개발, 테스트, 실무 환경 사이의 구성 차이로 애플리케이션 테스팅의 차질
- 수작업에 의한 애플리케이션 배포. 오류가 발생하기 쉽고, 회사 및 최종 이용자가 요구하는 만큼 빈번하게 변화를 이행하기 어려움

개선 방안은 다음과 같다.

- 온-프레미스로부터 클라우드 인프라로 마이그레이션 시 인프라 표준을 실행
- 마이크로서비스, 또는 여타 아키텍처 변화에 투자. 클라우드 네이티브 및 자동화된 구성은 장기적으로 혜택을 가져옴
- 이용이 증가하고 신기능에 투자하는 애플리케이션에 대한 테스트 자동화를 개선

리더는 데브옵스 프로그램과 연관된 KPI를 검토하고, 제반 문제, 기회, KPI의 순위를 강제적으로 정하는 방식을 고려해야 한다. 이는 어떤 데브옵스 프랙티스에 우선 집중할 것인지를 결정하는 데 유용하다.

CI/CD 및 지속 테스팅이 선행되어야 할 때
애플리케이션에 크게 투자하고 업데이트를 정기적으로 배포한다고 하자. 전문 개발팀이 애플리케이션 업데이트를 배포하는 일을 하고 있다면, 이는 CI/CD 및 지속 테스팅에서 데브옵스를 시작해야 한다는 강력한 신호다.

다른 고려 사항도 있다. 모든 애플리케이션이 회사에 똑같이 중요한 것은 아니라는 점, 또는 개발 시 같은 투자를 받는 것은 아니라는 점이다. 애플리케이션 개발은 대개 매출, 워크플로우가 업무에 주는 영향, 이용률 등의 사업 요인에 따라 우선순위가 정해진다. 우선순위가 높거나 이용이 증가하는 애플리케이션이 좋은 출발점이다.

기초 아키텍처 역시 고려사항이다. 복잡하거나, 컴포넌트가 긴밀하게 결합해 있거나, 구식 기술을 사용하거나, 기술 부채가 상당히 잠복한 아키텍처는 초기의 CI/CD 노력을 위한 최선의 선택이 아니다. 우선순위가 높거나 아키텍처가 단순한 애플리케이션 또는 플랫폼이 가장 좋다.

Iac 및 컨테이너로 데브옵스를 시작해야 할 때
애플리케이션의 개발과 배포를 자주 하는 것은 아니지만, 여러 업무 목적으로 다양한 컴퓨팅 환경을 유지하고 있다고 하자. CRM 또는 CMS 시스템, BPM 툴이 프라이빗 또는 퍼블릭 클라우드 환경에 구축돼 있을 수도 있다. 이들 플랫폼상에서 개발이 많이 이루어지는 것은 아니라고 해도, 어찌 됐든 이들은 개발 환경, 테스팅 환경, 스테이징 환경, 실무 환경, 재난 복구 환경, 그리고 여러 수명 주기를 지원할 수 있는 여타 환경이 필요하다.

이들 상용 내지 오픈 소스 플랫폼을 CI/CD로 지원할 필요까지는 없을 수 있지만, 운영팀은 인프라를 코드로 구성함으로써 상당한 이익을 도출할 수 있다. 또 다른 사례는 대규모 데이터 과학팀을 지원하는 것이다. 이들은 모델을 테스팅하고, 데이터베이스를 구축하고, 새로운 데이터 출처를 통합하는 일을 한다. 데이터 과학팀을 위해 인프라를 표준화하면 요구에 따라 컴퓨트 역량을 크게 늘리고 재조정할 수 있다.

인프라가 중점 영역이라면 셰프(Chef), 퍼핏(Puppet), 앤서블(Ansible) 등 자동화 플랫폼을 선정하는 것이 중요하다. 또한 컨테이너화된 워크로드와 서비스가 혜택을 제공하는지, 어떻게 혜택을 제공하는지, 그리고 쿠버네티스, 도커 등의 기술을 사용할 것인지 판단하는 것 역시 매우 중요하다.

 

AI 옵스의 정의와 이를 우선으로 고려해야 할 때

AWS, 애저 같은 퍼블릭 또는 프라이빗 클라우드에서 이미 애플리케이션을 운영 중이고, 환경이 빈번하게 변하지 않고 안정적이라고 하자. 그렇다면 IaC로 환경을 재구축할 이유가 별로 없을 것이다. 마찬가지로, 애플리케이션 배포가 드문 편이고, 애자일 개발 잔무가 소소한 지원과 유지보수에 불과하다면, CI/CD에 투자하는 것은 거의 무의미할 수 있다.

데브옵스로의 세 번째 길은 모니터링과 머신러닝 이용의 수준을 높여 사건 대응을 지원하는 것이다. 흔히 AI옵스(AIops)라 불리는 것이다. 이 데브옵스의 길은 안정적이지 않은 애플리케이션이나 멀티 클라우드 환경 지원을 강화할 때, 또는 여러 모니터링 툴에 의해 시스템 경보가 넘쳐나는 환경에서 특히 유용하다.

AI옵스 플랫폼은 빅팬더(BigPanda), 스플렁크(Splunk) 등이 있고, 로그 파일과 여러 모니터링 플랫폼에서 데이터를 취합하고, 머신러닝을 이용해 데이터를 가공하고, 적정 당사자에게 사건을 전송하는 역할을 한다.

AI옵스는 엔지니어 팀이 MTTR을 개선하는데 기여할 수 있고, 개발자가 애플리케이션 문제의 근본 원인을 발견하는 데 활용할 수 있다. AI옵스 솔루션은 기술 부채를 우선 처리해야 할 곳을 파악할 때, 그리고 확장 또는 안정성 문제를 가진 애플리케이션을 전면적으로 수정할 것인지의 여부를 정할 때 이에 필요한 데이터를 제공할 수 있다.

데브옵스 프로그램을 시작할 최적의 시기
타이밍이 가장 중요하다. 기술 프랙티스와 플랫폼에 투자할 때는 특히 그렇다. 데브옵스 투자는 암암리에 이루어지기 어렵기 때문에, 우선 순위와 시기를 정해 전사적인 지지를 얻는 것이 필수다. 데브옵스 프로그램이나 프랙티스를 시작하는 최적의 시기는 아래와 같다.

- 클라우드 마이그레이션은 IaC와 컨테이너에 투자할 좋은 시기이다.
- 개발팀이 새 아키텍처를 고려하고 있다고 하자. 개념 증명은 끝났지만, 아직 개발이 시작되지 않았을 때가 IaC를 자동화하고 CI/CD를 구성하는 것을 고려할 가장 좋은 시기이다.
- 협업 리더들이 IT 시스템의 안정성을 우려하거나, 특정 애플리케이션 사용이 증가할 때

단, 언제 어디서 시작하든, 플랫폼과 프랙티스를 배치하는 것만으로 비즈니스 성과를 달성하고, KPI를 개선할 수 있는 것은 아님을 기억해야 한다. 문화 변화가 선행돼야 하고, 이에 의해 개발자, 엔지니어, 기술 리더가 협력하는 환경이 조성돼야 회사와 최종 이용자가 실질적인 혜택을 누릴 수 있다. ciokr@idg.co.kr


2019.12.10

데브옵스 프로그램을 시작하는 3가지 방법

Isaac Sacolick  | InfoWorld
데브옵스는 개발 및 운영팀이 협력하는 방식으로의 문화 변화를 의미한다. 자동화, 안정성, 속도와 함께 변화를 전개하는 일련의 베스트 프랙티스이기도 하다. 데브옵스 환경에서는, 코드를 실무에 빈번하게 투입하려는 애자일 개발팀과, 애플리케이션, 데이터베이스, 인프라, 네트워크의 높은 안전성, 보안, 확장성을 지원해야 하는 운영팀이 공통의 이해를 바탕으로 협력한다.



지속적 통합과 배포(Continuous Integration and Continuous Delivery, CI/CD), 코드 기반 인프라 제어(Infrastructure as Code, IaC) 같은 자동화, 컨테이너를 이용한 플랫폼, AI옵스로 관리되는 환경 등이 대표적인 데브옵스 프랙티스 및 기술이다. 데브옵스 프랙티스를 고도화하려면 필수 기술을 가진 인재를 채용하고, 직원을 교육하고, 신기술을 테스트하고, 구현에 대한 이터레이션을 이행하고, 프랙티스를 확장하고 표준화하는 방식을 개발해야 한다.

이들 프랙티스를 전부 테스트하고 싶은 생각도 있겠지만, 현실적으로 이는 기술팀에게 큰 부담이다. 시작할 작은 부분을 파악하고, 성공의 경험을 축적한 후 프로그램을 확대하는 것이 더 현실적이다.

사업 및 기술 목표의 이해
기술팀이 새 툴이나 프랙티스에 투자할 때는 반드시 이를 지지할 동력, 영향, 핵심성과지표(KPI)를 고려해야 한다. 데브옵스 프로그램을 시작하기에 앞서, 기술팀은 현업 측 후원자를 확보해야 하고, 문제와 기회를 규명하고 우선순위를 정한 보고서를 개발해야 한다. 문제 상황은 다음과 같다.

- 긴 애플리케이션 평균 복구 시간(Mean Time To Recovery, MTTR)
- 개발, 테스트, 실무 환경 사이의 구성 차이로 애플리케이션 테스팅의 차질
- 수작업에 의한 애플리케이션 배포. 오류가 발생하기 쉽고, 회사 및 최종 이용자가 요구하는 만큼 빈번하게 변화를 이행하기 어려움

개선 방안은 다음과 같다.

- 온-프레미스로부터 클라우드 인프라로 마이그레이션 시 인프라 표준을 실행
- 마이크로서비스, 또는 여타 아키텍처 변화에 투자. 클라우드 네이티브 및 자동화된 구성은 장기적으로 혜택을 가져옴
- 이용이 증가하고 신기능에 투자하는 애플리케이션에 대한 테스트 자동화를 개선

리더는 데브옵스 프로그램과 연관된 KPI를 검토하고, 제반 문제, 기회, KPI의 순위를 강제적으로 정하는 방식을 고려해야 한다. 이는 어떤 데브옵스 프랙티스에 우선 집중할 것인지를 결정하는 데 유용하다.

CI/CD 및 지속 테스팅이 선행되어야 할 때
애플리케이션에 크게 투자하고 업데이트를 정기적으로 배포한다고 하자. 전문 개발팀이 애플리케이션 업데이트를 배포하는 일을 하고 있다면, 이는 CI/CD 및 지속 테스팅에서 데브옵스를 시작해야 한다는 강력한 신호다.

다른 고려 사항도 있다. 모든 애플리케이션이 회사에 똑같이 중요한 것은 아니라는 점, 또는 개발 시 같은 투자를 받는 것은 아니라는 점이다. 애플리케이션 개발은 대개 매출, 워크플로우가 업무에 주는 영향, 이용률 등의 사업 요인에 따라 우선순위가 정해진다. 우선순위가 높거나 이용이 증가하는 애플리케이션이 좋은 출발점이다.

기초 아키텍처 역시 고려사항이다. 복잡하거나, 컴포넌트가 긴밀하게 결합해 있거나, 구식 기술을 사용하거나, 기술 부채가 상당히 잠복한 아키텍처는 초기의 CI/CD 노력을 위한 최선의 선택이 아니다. 우선순위가 높거나 아키텍처가 단순한 애플리케이션 또는 플랫폼이 가장 좋다.

Iac 및 컨테이너로 데브옵스를 시작해야 할 때
애플리케이션의 개발과 배포를 자주 하는 것은 아니지만, 여러 업무 목적으로 다양한 컴퓨팅 환경을 유지하고 있다고 하자. CRM 또는 CMS 시스템, BPM 툴이 프라이빗 또는 퍼블릭 클라우드 환경에 구축돼 있을 수도 있다. 이들 플랫폼상에서 개발이 많이 이루어지는 것은 아니라고 해도, 어찌 됐든 이들은 개발 환경, 테스팅 환경, 스테이징 환경, 실무 환경, 재난 복구 환경, 그리고 여러 수명 주기를 지원할 수 있는 여타 환경이 필요하다.

이들 상용 내지 오픈 소스 플랫폼을 CI/CD로 지원할 필요까지는 없을 수 있지만, 운영팀은 인프라를 코드로 구성함으로써 상당한 이익을 도출할 수 있다. 또 다른 사례는 대규모 데이터 과학팀을 지원하는 것이다. 이들은 모델을 테스팅하고, 데이터베이스를 구축하고, 새로운 데이터 출처를 통합하는 일을 한다. 데이터 과학팀을 위해 인프라를 표준화하면 요구에 따라 컴퓨트 역량을 크게 늘리고 재조정할 수 있다.

인프라가 중점 영역이라면 셰프(Chef), 퍼핏(Puppet), 앤서블(Ansible) 등 자동화 플랫폼을 선정하는 것이 중요하다. 또한 컨테이너화된 워크로드와 서비스가 혜택을 제공하는지, 어떻게 혜택을 제공하는지, 그리고 쿠버네티스, 도커 등의 기술을 사용할 것인지 판단하는 것 역시 매우 중요하다.

 

AI 옵스의 정의와 이를 우선으로 고려해야 할 때

AWS, 애저 같은 퍼블릭 또는 프라이빗 클라우드에서 이미 애플리케이션을 운영 중이고, 환경이 빈번하게 변하지 않고 안정적이라고 하자. 그렇다면 IaC로 환경을 재구축할 이유가 별로 없을 것이다. 마찬가지로, 애플리케이션 배포가 드문 편이고, 애자일 개발 잔무가 소소한 지원과 유지보수에 불과하다면, CI/CD에 투자하는 것은 거의 무의미할 수 있다.

데브옵스로의 세 번째 길은 모니터링과 머신러닝 이용의 수준을 높여 사건 대응을 지원하는 것이다. 흔히 AI옵스(AIops)라 불리는 것이다. 이 데브옵스의 길은 안정적이지 않은 애플리케이션이나 멀티 클라우드 환경 지원을 강화할 때, 또는 여러 모니터링 툴에 의해 시스템 경보가 넘쳐나는 환경에서 특히 유용하다.

AI옵스 플랫폼은 빅팬더(BigPanda), 스플렁크(Splunk) 등이 있고, 로그 파일과 여러 모니터링 플랫폼에서 데이터를 취합하고, 머신러닝을 이용해 데이터를 가공하고, 적정 당사자에게 사건을 전송하는 역할을 한다.

AI옵스는 엔지니어 팀이 MTTR을 개선하는데 기여할 수 있고, 개발자가 애플리케이션 문제의 근본 원인을 발견하는 데 활용할 수 있다. AI옵스 솔루션은 기술 부채를 우선 처리해야 할 곳을 파악할 때, 그리고 확장 또는 안정성 문제를 가진 애플리케이션을 전면적으로 수정할 것인지의 여부를 정할 때 이에 필요한 데이터를 제공할 수 있다.

데브옵스 프로그램을 시작할 최적의 시기
타이밍이 가장 중요하다. 기술 프랙티스와 플랫폼에 투자할 때는 특히 그렇다. 데브옵스 투자는 암암리에 이루어지기 어렵기 때문에, 우선 순위와 시기를 정해 전사적인 지지를 얻는 것이 필수다. 데브옵스 프로그램이나 프랙티스를 시작하는 최적의 시기는 아래와 같다.

- 클라우드 마이그레이션은 IaC와 컨테이너에 투자할 좋은 시기이다.
- 개발팀이 새 아키텍처를 고려하고 있다고 하자. 개념 증명은 끝났지만, 아직 개발이 시작되지 않았을 때가 IaC를 자동화하고 CI/CD를 구성하는 것을 고려할 가장 좋은 시기이다.
- 협업 리더들이 IT 시스템의 안정성을 우려하거나, 특정 애플리케이션 사용이 증가할 때

단, 언제 어디서 시작하든, 플랫폼과 프랙티스를 배치하는 것만으로 비즈니스 성과를 달성하고, KPI를 개선할 수 있는 것은 아님을 기억해야 한다. 문화 변화가 선행돼야 하고, 이에 의해 개발자, 엔지니어, 기술 리더가 협력하는 환경이 조성돼야 회사와 최종 이용자가 실질적인 혜택을 누릴 수 있다. ciokr@idg.co.kr


X