About DevOps
라온화이트햇 핵심연구팀 황정식
1. DevOps?
DevOps란 무엇입니까? - Amazon Web Services(AWS)
DevOps는 애플리케이션과 서비스를 빠른 속도로 제공할 수 있도록 조직의 역량을 향상시키는 문화 철학, 방식 및 도구의 조합이라고 합니다. 기존의 소프트웨어 개발 및 인프라 관리 프로세스를 사용하는 조직보다 제품을 더 빠르게 혁신하고 개선할 수 있습니다. 이렇게 빠른 혁신과 개선 속도를 통해 조직은 고객에게 보다 좋은 질의 서비스를 제공하고, 기업 스스로 경쟁력을 가질 수 있습니다.

이러한 DevOps가 생겨난 배경은 기존의 개발 및 운영 방식을 알아보면 쉽게 이해할 수 있습니다.
1.1 DevOps의 장점
-
속도
작업속도가 빨라지므로 고객을 위해 빠른 혁신이 가능하며,시장 변화에 보다 잘 적응할 수 있습니다. 또한 좀 더 효율적으로 비즈니스 성과를 창출할 수 있습니다. DevOps 모델을 사용하면 개발자와 운영팀이 이러한 성과를 실현할 수 있습니다. -
신속한 제공
릴리즈의 빈도와 속도를 개선하여 제품을 더 빠르게 혁신하고 개선할 수 있습니다. 새로운 기능의 릴리즈와
버그 수정 속도가 빨라질수록고객의 요구에더 빠르게 대응하여 경쟁 우위를 강화할 수 있습니다. -
안정성
최종 사용자에게 지속적으로 긍정적인 경험을 제공하는 한편, 더욱 빠르게 안정적으로 제공할 수 있도록 애플리케이션 업데이트와 인프라 변경의 품질을 보장합니다.
-
확장
규모에 따라 인프라와 개발 프로세스를 운영 및 관리합니다. 자동화와 일관성이 지원되므로 위험을 줄이면서 복잡한 시스템 또는 변화하는 시스템을 효율적으로 관리할 수 있습니다.
-
협업 강화
주인의식 및 책임과 같은 가치를 강조하는 DevOps 문화 모델에서 좀 더
효과적인 팀을 구축합니다. -
보안
제어를 유지하고 규정을 준수하면서 신속하게 진행할 수 있습니다. 자동화된 규정 준수 정책, 세분화된 제어 및 구성 관리 기술을 사용함으로써 보안을 그대로 유지하면서 DevOps 모델을 도입할 수 있습니다.
2. DevOps의 특징
2.1 기존의 개발 및 운영 방식
회사에서 어떠한 제품을 개발을 할 때, 개발 뿐만 아니라 개발한 제품의 빌드, 배포, 테스트 등의 운영 업무가 필수 불가결 합니다. 보통 회사에서는 이 두 개의 일을 하는 조직을 나눠서 관리하게 됩니다. 그런데 하나의 제품 혹은 서비스를 두 개의 팀에서 관리하다보면 서로의 의사소통도 어렵거니와, 비효율적인 부분이 많았습니다.
개발자(Dev)의 입장에서는 새로운 것들을 도입하고 싶어합니다.
운영자(Ops)의 입장에서는 안정성을 최우선이므로, 기존의 상태를 안전하게 운영하기를 원합니다.
이러한 두 입장을 고려하여 탄생한 개념이 바로 DevOps입니다. DevOps라는 개념은 소프트웨어 개발 방법론 중 하나입니다.
2.2 Cross Functional Team
Cross Functional Team이라는 뜻은 하나의 팀에 개발부터 운영까지 모두 할 수 있는 사람으로만 구성하라는 뜻이 아닙니다. 개발부터 테스트 및 배포까지의 각각의 프로세스 담당자들을 하나의 팀으로 모으라는 뜻입니다. 서비스 기획부터 개발 운영 테스트 배포등 모든 제품 개발 프로세스를 하나의 팀에서 할 수 있도록 해야 한다는 의미입니다.
2.3 Widely Shared Metrics
Widely Shared Metrics란, 팀원 모두가 알고 있는 하나의 공유된 지표가 필요하다는 것입니다. 제품이나 서비스를 개발하는 것에 한정된 것이 아닌 보다 넓은 개념에서의 프로젝트 관리를 요구하는 개념입니다. 우리의 제품/서비스가 문제 없이 잘 돌아가는지, 사용자의 반응은 어떤지를 측정할 수 있는 기준이 있는지를 확인할 필요가 있다는 의미입니다. 또한 이러한 평가 지표는 객관적이고 명확한지에 대한 고민도 이루어져야 합니다.
2.4 Automating repetitive tasks
Automating repetitive tasks는 말 그대로 반복적인 일들은 자동화를 하라는 것입니다. 보다 구체적으로는 CI/CD를 이용해서 빌드-배포-테스트 프로세스를 자동화 해야 한다는 의미입니다.
CI와 CD에 대한 개념은 Redhat에 정의되어 있는 내용을 기반으로 정리해보았습니다.
CI/CD(지속적 통합/지속적 제공): 개념, 방법, 장점, 구현 과정
-
CI(Continuous Integration)
개발자를 위한 자동화 프로세스인 지속적인 통합을 의미합니다. CI를 성공적으로 구현할 경우 애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트될 수 있습니다. 이를 통해 공유 repository에 통합되므로 여러명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우, 서로 충돌하는 문제를 해결할 수 있습니다. -
CD(Continuous Delivery || Continuous Deployment)
지속적인 서비스 제공, 혹은지속적인 서비스 배포를 의미합니다. 두 가지 의미 모두 파이프라인의 추가 단계에 대한 자동화를 뜻하지만, 때로는 얼마나 많은 자동화가 이루어지고 있는지를 설명하기 위해 별도로 사용되기도 합니다.
2.5 Post Mortems
Post Mortems는 직역하면 후처리라고 할 수 있습니다. 장애나 이슈가 있을 때, 다른 팀원들과 공유해야 합니다. 서비스를 운영만 하다보면 어떤 이슈가 있을 때 이 이슈가 얼마나 큰 이슈인지를 파악할 수 없는 경우가 많습니다.
2.6 Regular Release
짧은 주기의 정기 배포를 통해서 빠르게 서비스의 기능을 개선하고 고객들의 VoC를 반영해 나가야 하는 것을 말합니다.
3. DevOps 방식
3.1 지속적 통합(CI - Continuous Integration)
지속적 통합은 자동화된 빌드 및 테스트가 수행된 후, 개발자가 코드 변경 사항을 중앙 리포지토리에 정기적으로 병합하는 DevOps 소프트웨어 개발 방식입니다. 지속적 통합은 소프트웨어 릴리스 프로세스 중 빌드 또는 통합 단계를 주로 가리키며, 자동화 구성 요소(예: CI 또는 빌드 서비스)와 문화적 구성 요소(예: 빈번하게 통합하도록 학습) 모두를 포함합니다.

지속적 통합 vs 전달 vs 배포 | TeamCity 가이드
대부분의 상용 및 오픈소스 소프트웨어에서 일반적인 것처럼, 두 명 이상이 소프트웨어 제품을 개발합니다. 이럴 경우, 언젠가 각각의 개발자가 작업한 부분을 결합하여 최종 결과물이 적절히 작동하는지 확인해야 합니다. 만약 지속적인 통합을 적용한 경우, 하루에 한 번씩 이러한 일이 발생하게 됩니다. 좋은 CI 프로세스의 몇 가지 필수 요소는 다음과 같습니다.
-
소스 관리 시스템 사용
소스(버전) 관리 시스템을 반드시 사용하도록 합니다. -
조기에 자주 커밋하기
소스 관리 시스템을 사용하는 구성원들은
자주 커밋하는 습관을 기르도록 합니다. 각각의 작업을 더 작은 부분으로 나누면, 더욱 쉽게 로컬에서 변경을 완료하고 테스트할 수 있어, 커밋할 준비가 됩니다. -
모든 커밋으로 솔루션 빌드
최신 변경 사항으로 솔루션 빌드가 가능한지 확인합니다. 이러한 작업은 수동으로도 가능하지만 이를 자동으로 트리거하면 보다 효율적일 수 있습니다. 이때 CI 서버가 필요로 합니다. -
테스트 자동화
빌드가 성공적으로 완료되었다면, 기능을 테스트해야 합니다. 이때도 역시
자동으로 테스트를 수행하는 것이 훨씬 효율적입니다. -
피드백 경청
테스트를 통해
습득한 정보를 통해 피드백을 반영해야 테스트를 하는 의미가 있습니다. CI 도구는 대시보드 및 라디에이터부터 인스턴트 메시징 플랫폼과 통합 등의 다양한 피드백 메커니즘을 제공합니다. -
DevOps 문화 구축
지속적인 통합의 이점을 적절히 활용하려면 모든 팀원이 작동하지 않는 빌드를 수정하거나,
테스트 실패에 책임감을 갖는 팀 문화를 조성해야 합니다. 변경 사항을 조기에, 자주 커밋하는 편이 모두의 이익에 부합합니다.
3.2 지속적 전달(CD - Continuous Delivery || Continuous Deployment)
지속적 전달(Continuous Delivery)은 프로덕션에 릴리스하기 위한 코드 변경이 자동으로 준비되는 소프트웨어 개발 방식입니다. 현대 애플리케이션 개발의 기반인 지속적 전달은 빌드 단계 이후의 모든 코드 변경을 테스트 환경 및 프로덕션 환경에 배포함으로써 지속적 통합을 확장합니다. 적절하게 구현할 경우, 개발자는 언제나 즉시 배포할 수 있고 표준화된 테스트 프로세스를 통과한 빌드 아티팩트를 보유할 수 있습니다.

지속적 전달에서는 개발자가 단순한 유닛 테스트 외에도 다양한 테스트를 자동화할 수 있으므로, 고객에게 배포하기 전에 여러 차원에서 애플리케이션 업데이트를 확인할 수 있습니다. 이러한 테스트에는 UI 테스트, 로드 테스트, 통합 테스트, API 안정성 테스트 등이 포함될 수 있습니다. 이를 통해 개발자는 업데이트를 좀 더 철저히 검증하고 문제를 사전에 발견할 수 있습니다. 온프레미스에서는 힘들었지만, 클라우드에서는 테스트용으로 여러 개의 환경을 생성하고 복제하는 작업을 비용 효율적으로 손쉽게 자동화할 수 있습니다.
이러한 지속적 전달의 이점은 다음과 같습니다.
- 기존의 사일로를 방지하므로, 사용자에게 제품을 제공하기 위한
비즈니스 및 운영상 요구 사항을개발 팀에서 더욱 잘 이해할 수 있습니다. - 따라서 대체로 수동으로 진행되는 긴 호흡의 프로세스에 개발 관행을 도입할 기회를 제공합니다.
- 제품을 라이브로 전달하는 단계를
자동화하면 프로세스 속도를 개선할 수 있을 뿐 아니라오류 위험이 감소하여 더욱 안정적이고 신뢰할 수 있는 프로세스가 구축됩니다.
4. 추후 연구
추후 연구에서는 DevOps를 자동화하는 데에 활용되는 다양한 도구들을 다룰 예정입니다.
4.1 개발 및 비즈니스 민첩성 도구
- Jenkins(젠킨스)
- K8s(Kubernetes, 쿠버네티스)
- CRI-O
- ANSIBLE
4.2 보안
- GAUNTLT
- Vault
- Clair
- sonarqube