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