Enjoy My Posts

DevOps 개요

Posted on Jul 13, 2020 By Geunwon Lim

DevOps란?

DevOps는 Development + Operation을 줄인 말로, 개발과 운영을 함께 한다는 뜻입니다. DevOps는 특정 툴이 아니라, 문화입니다. 따라서 DevOps를 한다고 해도, 회사별로 다릅니다. 이것은 개발과 운영이 분리되어 있을 때 생기는 문제점 때문에 주목받게 됐는데요. 개발과 운영이 분리되어 있는 전통적인 방식의 경우 팀은 ‘개발만 하는 팀’, ‘배포하는 팀’, ‘데이터베이스 구축 팀’ 등으로 나뉘게 됩니다. 즉 부서 중심으로 인프라 구축, 개발, 운영 등을 합니다. 이 때, 개발과 운영은 목적이 다르기 때문에 의견이 상충하게 됩니다. 개발 팀은 애플리케이션을 개발하기 때문에 변화를 추구합니다. 반면 운영 팀은 운영 시스템을 안정화하고자 합니다. 따라서 이미 잘 돌아가는 서버를 바꾸는 것에 반대하겠죠. Load balance 등의 이슈에 대해서도 서로 입장이 다릅니다. 즉, 전통적인 개발과 운영 분리 방식에서는 문제 발견 ➝ 서로에게 책임 전가 ➝ 마음의 상처 ➝ 문제 원인 분석 ➝ 문제 해결 의 방식인데, 이 때 책임 전가와 마음의 상처와 같은 불필요한 비용이 발생하게 됩니다. 그래서 개발과 운영을 함께 해보자는 DevOps가 주목받게 됩니다.

DevOps가 필요한 이유는 세상이 달라졌기 때문입니다. 90년대에는 서비스가 정적이었습니다. 또한 보통 서비스는 하드웨어였지, 소프트웨어가 서비스가 되는 경우도 드물었습니다. 이제 소프트웨어가 그 자체로 서비스인 경우가 많죠. 소프트웨어의 특징은 iteration이 하드웨어보다 빠르다는 것입니다. 코딩 후 배포하면 끝이죠. 소프트웨어의 품질 면에서 iteration이 빠를수록 좋은데, 예를 들어 한 달에 한 번 배포하는 것보다 하루에 한 번 배포할 수 있는 것이 좋습니다. 고객의 요구가 있을 때마다 배포할 수 있으면 좋은 거니까요. 좋은 it회사의 DevOps Metrics 추세를 살펴보면, 전반적으로 좋아지고 있다고 합니다.

DevOps를 시행하여 한 팀이 개발과 운영을 관장하면, 기존과 다른 점은 다른 부서의 책임도 내 부서의 책임이라고 생각하게 되는 것이라고 합니다. 뿐만 아니라 DevOps에서는 상당 부분이 자동화되어 있습니다. 예를 들어, 프로비저닝(자원이 어떻게 사용될 지 미리 생각해서 준비해놓고, 필요할 때마다 가져다 쓰는 것) 등이 그러하죠. 기존에는 프로비저닝이 수동이었습니다. 또한 각자 맡은 기능에 집중하고, 전체적인 성공에 책임지지 않죠. 그러다보니 변경에 반대하게 됩니다. DevOps에서는 개발 환경과 운영 환경에서 동일한 작동을 보장할 수 있도록 환경 프로비저닝 및 자동화를 합니다. 모두 비즈니스 성공을 추진하는 데 집중하고, 개발 뿐 아니라 소프트웨어 전달에 대한 책임도 집니다. 기존에 비해 변경에 거부감이 없게 됩니다. DevOps의 사례로는 지속적 통합, 지속적 전달, 마이크로 서비스, 코드형 인프라, 모니터링 및 로깅, 커뮤니케이션 및 협업 등이 있습니다.

DevOps에서 중요한 것

DevOps에서 특히 중요한 것은 로깅 및 모니터링을 통해 제품이 최종 사용자에게 어떤 영향을 미쳤는지 확인하는 것이라고 합니다. 빠르게 배포하고 빠르게 피드백을 받고 빠르게 개선하자는 것이죠. 즉 분석 툴이 중요합니다.

또한 구성원들의 마인드가 중요합니다. DevOps를 시행하면 커뮤니케이션 비용이 증가하게 됩니다. 따라서 구성원들의 커뮤니케이션 능력이 뛰어나야 하고, 문제가 생겼을 때 잘 전달하고 잘 해결해야 하죠. 조직 모두가 DevOps에 관심을 갖고 지속적으로 커뮤니케이션 해나가는 것이 중요합니다.

DevOps의 이점

  1. 속도

    DevOps 방식을 사용하여 속도가 느리고 수동으로 수행되던 프로세스를 자동화합니다. 또한 애플리케이션을 안정적으로 빠르게 운영하고 개선하는 데 도움이 되는 기술 스택과 도구를 사용합니다. 이러한 도구 덕분에 엔지니어는 이전 같았으면 다른 팀의 도움이 필요했을 코드 배포 또는 인프라 프로비저닝과 같이 작업을 독립적으로 수행할 수 있으며, 따라서 팀의 작업 속도가 더욱 빨라집니다. 작업 속도가 빨라지므로 고객을 위해 더 빠르게 혁신하고, 시장 변화에 더 잘 적응하고, 좀 더 효율적으로 비즈니스 성과를 창출할 수 있습니다. 예를 들어 마이크로 서비스와 지속적 전달을 사용하면 팀에서 서비스를 주도적으로 운영하여 업데이트를 좀 더 빠르게 릴리스할 수 있습니다.

  2. 신속한 제공

    릴리스의 빈도와 속도를 개선하여 제품을 더 빠르게 혁신하고 개선할 수 있습니다. 새로운 기능의 릴리스와 버그 수정 속도가 빨라질수록 고객의 요구에 더 빠르게 대응하여 경쟁 우위를 강화할 수 있습니다. 빌드에서 배포까지 소프트웨어 릴리스 프로세스를 자동화하는 방식인 지속적 통합과 지속적 전달을 통해 이를 달성할 수 있습니다.

  3. 안정성

    지속적 통합 및 지속적 전달과 같은 방식을 사용하여 각 변경 사항이 제대로 작동하며 안전한지 테스트합니다. 모니터링과 로깅 방식을 통해 실시간으로 성능에 대한 정보를 얻을 수 있습니다.

  4. 확장

    자동화와 일관성이 지원되므로 위험을 줄이면서 복잡한 시스템 또는 변화하는 시스템을 효율적으로 관리할 수 있습니다. 예를 들어 코드형 인프라를 사용하면 개발, 테스트 및 프로덕션 환경을 반복 가능하고 좀 더 효율적인 방식으로 관리할 수 있습니다.

  5. 협업 강화

    주인의식 및 책임과 같은 가치를 강조하는 DevOps 문화 모델에서 좀 더 효과적인 팀을 구축합니다.

  6. 보안

    예를 들어 코드형 인프라와 코드형 정책을 사용하면 규모에 따라 규정 준수를 정의하고 추적할 수 있습니다.

DevOps Metrics

DevOps가 원활히 실행되면 리드 타임 단축, 배포 빈도 증가, 서비스 복구 시간 단축, 변경 실패율 감축으로 이어집니다.

  1. Deployment frequency

    배포는 소프트웨어를 프로덕션 환경이나 앱 스토어에 배포하는 걸 뜻합니다. 배포 빈도가 중요한 이유는 최종 사용자에게 가치있는 것을 제공하거나 사용자로부터 피드백을받는 빈도를 알려주기 때문입니다. DORA 2018 리포트에 따르면, 뛰어난 회사들은 하루에 다수의 배포를 하고 좋지 않은 회사들은 일주일에 한 번 혹은 한 달에 한 번 꼴로 배포를 한다고 합니다.

  2. Lead time for changes

    리드 타임은 커밋 된 코드가 프로덕션 환경에서 성공적으로 실행되는 데 걸리는 시간을 뜻합니다. DORA 2018 리포트에 따르면, 뛰어난 회사들은 특정 변경에 대해 1시간 미만의 리드 타임을 갖고, 좋지 않은 회사들은 1개월에서 6개월 사이의 리드 타임을 갖는다고 합니다.

  3. Time to restore service

    서비스 복원 시간은 말 그대로 서비스를 복원하는 데 걸리는 평균 시간을 뜻합니다. DORA 2018 리포트에 따르면, 뛰어난 회사들은 1시간 이내의 서비스 복원 시간을 갖고, 좋지 않은 회사들은 1주에서 1달 사이의 서비스 복원 시간을 갖는다고 합니다.

  4. Change failure rate

    변화 실패율은 즉각적인 해결책 (특히 롤백)이 필요한 프로덕션에서 배포 실패가 발생하는 빈도를 측정한 것입니다. DORA 2018 리포트에 따르면, 뛰어난 회사들은 0~15%의 변화 실패율을 보였고, 좋지 않은 회사들은 46~60%의 변경 실패율을 보였다고 합니다.