[데브옵스] 데브옵스란?

데브옵스

- 소프트웨어의 개발(Development)과 운영(Operations) 합성어

- 소프트웨어 개발자와 정보기술 전문가 간의 소통, 협업 및 통합을 강조하는 개발 환경이나 문화를 말한다.

- 데브옵스는 소프트웨어 개발조직과 운영 조직간의 상호 의존적 대응이며 조직이 소프트웨어 제품과 서버스를 빠른 시간에 개발 및 배포 하는 것을 목적으로 한다.

 

-DevOps는 개발(Development)과 운영(Operations)의 합성어입니다

 

왜 이 두 가지 개념이 합쳐 졌을까요?

 

서비스의 패치를 위해서 몇 달간의 작업 후 배포하던 고전적인 방식과 달리, 현재는 빈번한 서비스 배포가 주류를 이루고 있습니다.
대부분의 서비스가 설치 기반에서 웹 기반으로 바뀌었으며 마이크로 서비스와 애자일 개발 방법론에 대한 관심이 많아졌고 그로 인해 빈번한 서비스의 배포가 필요해 졌습니다. 

하지만 개발팀은 서비스 개발에 매진하고, 운영팀은 보안과 안정적인 인프라 구축에 집중을 하므로 빈번한 배포 전략이 유연하게 동작할 수 없습니다.

이런 새로운 전략을 위해서 두 팀이 병합되어 개발, 테스트, 배포, 운영에 이르는 애플리케이션 수명주기를 개발하게 됩니다.

이를 데브옵스라고 하며, 이는 아래와 같은 이점이 있습니다

DevOps의 이점

• 속도
  배포까지의 빠른 작업속도를 효율적으로 제공하기 때문에 시장 변화에 빠르게 대처하고 비즈니스 성과를 창출 가능.

• 빠른 배포
  새로운 릴리즈와 버그픽스를 빠르게 배포할 수 있으며, 그로 인해 고객의 요구를 빠르게 대응 가능.

• 안정성
  지속적 통합, 지속적 전달, 모니터링, 로깅을 통해 안정적인 서비스 품질을 고객에게 제공 가능.

• 확장 가능
  복잡하거나 변화하는 시스템을 효율적으로 관리 가능.

• 협업 강화
  개발자와 운영팀이 긴밀하게 협력할 수 있기 때문에 책임을 공유하고 워크플로우를 결합할 수 있음.
  이를 통해 비효율을 줄이고 시간 절약 가능.

클라우드 기반의 웹서비스를 제공하는 경우 빠른 고객 응대와 배포로 인해서 시장우위를 점할 수 있습니다.

Facebook, Netflix, Flickr같은 회사들은 하루에 10번이 넘는 배포주기를 가지고 있다고 합니다.

뭘해야 하나요?

그럼 저런 이점을 얻기 위해 DevOps는 무엇을 해야 할까요?
위 이미지의 DevOps Flow 구현을 위한 중요한 개념들을 정리해 보았습니다.

SCM (Source Code Management)

우선 팀 단위로 개발되는 소스를 지속적으로 관리해줘야 합니다.
아래와 같은 버전 관리 시스템을 이용해 소스코드 관리를 합니다.

이를 위해 Git, SVN 등을 사용합니다

CI/CD

보통 하나의 서비스를 여러 명이 팀 단위로 작업을 하게 됩니다. 이렇게 각각 개발한 코드 빌드부터 배포까지 걸리는 시간 단축을 위해서 CI/CD 구축이 필요합니다.

CI (Continuous Integration)

지속적인 통합.
CI는 Build와 Test를 실시하는 프로세스입니다.
서비스의 품질관리를 위해서 지속적인 빌드와 테스트 과정을 지원합니다.

• Build
• Unit Test
• Code Coverage

일반적으로 CI를 위해 Jenkins, Travis CI 등을 사용합니다.
자동화 테스트의 경우 프로그래밍언어나 프레임워크에 따라 다양하게 사용됩니다.
e.g) Jest, Mocha, PHPUnit, NUnit, etc...

 

CD (Continuous Deploy (or Continuous Delivery))

지속적인 배포.
빌드단계 이후의 소프트웨어의 배포를 자동화합니다.
개발자가 원할 때 언제나 즉시 테스트 혹은 프로덕션에 지속적으로 배포할 수 있습니다.

Configuration Management

안정적인 지속적 배포를 위하여 서버 및 서비스의 설정을 관리 합니다.
서버 OS, 라이브러리 및 버전, 설치 순서, 컴파일, 등을 특정하여 더욱 안정적인 배포를 할 수 있게 해줍니다.
이를 위해 일반적으로 사용되는 도구는 아래와 같습니다.

Ansible, Chef, Puppet, etc...

모니터링 및 로깅

배포 이후 모니터링 및 로깅을 하여 제품이 최종사용자 경험에 어떤 영향을 미치는지 확인합니다.
데이터에 대한 실시간 분석을 수행하거나 알림을 생성 할 수 있으며, 사용자 데이터를 모니터링하여 서비스 발전에 방향을 잡고 계획할 수 있습니다.

서비스 상태를 확인 및 알람 - Datadog, PagerDuty, etc...
로깅 - Papertrail, Loggly, etc...
사용자 분석 - Google Analyics, Mixpanel, Segment, etc...

마치며

• 여기까지 기본적인 개념을 살펴보았습니다.
  현재는 Docker Kubernetes, Terraform + Ansible, 혹은 Netflix의 Spinnaker를 사용하는 등 다양한 방식이 있습니다.

• DevOps는 회사의 개발 문화와 밀접하게 연관이 되어 있습니다.
  그렇기 때문에 정답이 없으며, 회사 개발 문화에 자연스럽게 녹아드는 DevOps가 최선이라고 생각합니다.
  갑작스레 DevOps 전문가를 뽑아서 이렇게 해! 저렇게 해! 한다고 되는 부분이 아니며, 팀 내 개발자들의 관심을 통해 그 서비스의 맞춘 DevOps 환경을 만들어 가야 합니다.

• 회사에서 DevOps 작업하며 공부한 것들을 작성했으며, 더 많은 내용을 여기에 담으려 했으나!
  그러면 매우 길고 지루해질 것 같아 제목에 소개를 붙였습니다.
  DevOps 관련하여 자동화 배포, 마이크로서비스, 서버패턴, 배포전략 등의 내용을 추가적으로 쓸 예정입니다.
  포스트 하나로 때우기에는 생각보다 너무 방대하네요...

• 상황에 따라서는 AWS에서 관련 서비스를 많이 제공하기 때문에 위에 열거한 툴을 사용하지 않아도 됩니다.

• GitLab 자체에서도 CI/CD 도구를 제공하고 있습니다. 회사 동료가 쓰는걸 봤는데 인상적이더군요.

출처: https://blog.sonim1.com/231 [Kendrick's Blog]