728x90
목차
|
DevOps란?
- 'development(개발)' + 'operation(운영)'
- 개발과 운영의 경계를 허물고 하나의 팀으로서 소통, 협업 및 통합을 강조하는 조직 구조, 문화
- 하나의 아이디어(새로운 소프트웨어 기능, 개선 요청 또는 버그 수정 등)가 사용자에게 가치를 제공할 수 있도록 지원하는 사람, 프로세스, 기술의 합집합
- 운영 환경에서 개발 -> 배포로 진행되는 프로세스의 속도를 높이는 접근 방식.
- 원래 개발 과정: 개발자가 개발을 한 뒤에 운영자를 통해 배포를 해야함. 이 과정에서 운영자는 개발된 프로그램을 이해해야하고, 커뮤니케이션에 문제가 생긴다면 시간이 오래 걸릴 수 있다.
DevOps의 이점
- 셀프 서비스와 자동화로 다양한 이점과 경쟁력을 얻을 수 있다
속도
- 개발자는 IT 운영 담당자와 긴밀하게 협력하여 sw 빌드, 테스트, 출시 속도를 가속화할 수 있음
- 요즘 시대에 맞는 개발 속도 가능
신속한 제공
- release의 빈도와 속도를 개선하여 제품을 더 빠르게 혁신하고 개선할 수 있다.
- 고객의 요구를 더 빠르게 받아들여 개선이 가능 -> 고객 만족을 높일 수 있음.
평균 복구 시간 개선
안정성
- 더욱 빠르게 안정적으로 제공할 수 있도록 애플리케이션 업데이트와 인프라 변경의 품질을 보장함. 지속적 통합, 지속적 전달(CI/CD)과 같은 방식을 사용하여 각 변경사항이 제대로 작동하는지 테스트함.
- 모니터링과 로깅 방식을 통해 실시간으로 성능에 대한 정보를 얻을 수 있다. 시스템 안정성 및 신뢰성 유지 가능
확장 가능
- 규모에 따라 인프라와 개발 프로세스를 운영 및 관리함. 시장과 경쟁 지형에 따른 유연한 대응 가능
- 환경을 손쉽게 지속적으로 확장할 수 있음. 자동화는 반복적인 작업이나 단순 작업의 부담을 경감함으로써 기업의 우수한 인력이 가장 중요한 업무에 집중할 수 있는 환경을 조성함
협업 강화
- 주인의식 및 책임과 같은 가치를 강조하는 DevOps 문화 -> 효과적인 팀을 구축가능
- 협업을 중시하는 DevOps문화 -> 개발자와 운영팀은 긴밀하게 협력하고, 많은 책임을 공유하며, 워크플로를 결합한다.
- 이를 통해 비효율성을 줄이고 시간을 절약할 수 있다.
DevOps의 적용
- DevOps 접근 방식을 적용하려면 개발 팀과 운영 팀이 자주 커뮤니케이션하며 업무에 접근해야함
- 확장성과 유연한 프로비저닝도 필요
// 프로비저닝: 사용자의 요구에 맞게 시스템 자원을 할당, 배치, 배포해 두었다가 필요 시 시스템을 즉시 사용할 수 있는 상태로 미리 준비해 두는 것 - 코드 변경도 더 빈번해지고 인프라도 보다 역동적으로 사용해야 한다 -> 전통적인 관리 전략은 이러한 종류의 요구를 충족할 수 없음. 몇 가지 변화가 더 필요하다.
코드형 인프라(IaC, Infrastructure as code)
- 인프라의 정의를 하나 이상의 파일로 저장하는 방식
- 코드를 사용해 기본 인프라를 프로비저닝하고 유지 관리
- 초기 구성 및 후속 변경을 자동화, 버전화하는 방법으로써 IaC는 소프트웨어를 빠르게, 자주 배포하기 위해 개발자와 운영자가 협력하는 DevOps 관행의 핵심 부분
- 모든 것을 코드로 정의한다
- 작업하면서 모든 것을 지속적으로 테스트 및 전달한다
- 작고 느슨하게 결합된 조각으로 시스템을 구축한다.
- 개발자가 가장 잘하는 일에 집중할 수 있도록 하고, 시스템 관리자가 수동 프로세스로 고생하지 않도록 함.
- 개발자와 운영자가 소프트웨어 개발 라이프사이클에 더 가까이 있을 수 있고, 운영에 소프트웨어 개발 원칙, 명확성, 반복성을 주입할 수 있다.
- 데브옵스 팀은 일반적으로 JSON, YAML 등의 잘 문서화된 언어를 사용하여 환경 설명과 구성 모델 버전을 변경할 수 있다.
오픈소스 원칙의 협업 문화와 애자일(Agile) 방법론
- DevOps는 오픈소스 원칙에 부합하는 협업 문화와 투명한 애자일 작업 방식을 활용함.
- 애자일 방법론:
- 좋은 것을 빠르게 취하고, 낭비 없게 만드는 다양한 방법론의 통칭
- 앞을 예측하며 개발하지 않고, 일정한 주기를 가지고 계속 검토해 나가며 필요할 때마다 요구사항을 더하고 수정하며 개발해 나가는 모델.
- 일단 프로젝트를 시작한 후 끊임없이 개선 노력 - 오픈소스 소프트웨어 프로젝트의 문화:
- DevOps 문화를 구축하기 위한 청사진
- 자유로운 정보 공유는 오픈소스 커뮤니티에서의 협업에 대한 기본적인 접근 방식.
- 이를 통해 의사 결정 과정에서 투명성을 높이거나,
- 실패에 대한 두려움을 없앰으로써 실험적인 프로젝트를 권장하거나,
- 신뢰와 협업을 장려하는 보상 시스템을 구현하는 등의 기업 문화의 변화를 이끌어낼 수 있음 - 올바른 리더십과 인센티브 프로그램을 제공하면 개발 및 운영 팀이 열린 문화를 적극적으로 조성하는 데 도움이 될 수 있음. (이 문화가 조직 전체에 확산될 때 DevOps의 효과가 가장 크게 나타남)
- 현대화된 애플리케이션을 개발하려면 과거의 접근 방식과는 다른 프로세스가 필요함.
- 소프트웨어 개발에 애자일 접근 방식을 적용하는 많은 팀들이 가장 먼저 고려하는 사항이 바로 DevOps
CI/CD 파이프라인
- '신속하고 지속적인 소프트웨어 제공을 통한 고객 만족'은 애자일 선언문(Agile Manifesto)의 12가지 원칙 중 첫 번째 원칙
- 즉, CI/CD가 DevOps 팀에 매우 중요함
- CI(Continuous Integration, 지속적 통합)
- CD(Continuous Delivery, 지속적인 서비스 제공/ Continuous Deployment, 지속적인 배포)
- DevOps 구현의 주요 성과는 지속적인 통합 및 지속적인 배포(CI/CD) 파이프라인
- CI/CD를 통해 고객에 대한 애플리케이션 제공 주기를 단축하고 사용자 개입을 최소화하여 소프트웨어의 품질을 검증할 수 있음
- 특히, CI/CD는 애플리케이션의 통합 및 테스트 단계에서부터 제공 및 배포에 이르는 애플리케이션의 라이프사이클 전체에 걸쳐 지속적인 자동화와 지속적인 모니터링을 제공하여, 신속하게 문제 및 결함을 식별하고 수정함
- 이러한 구축 사례를 일반적으로 "CI/CD 파이프라인"이라 부르며 개발 및 운영 팀의 애자일 방식 협력을 통해 지원 됨
최종 사용자의 피드백
- 개발 및 운영 프로세스를 변경하는 것만으로는 충분하지 않음
- 소프트웨어 제공 방식을 실질적으로 최적화할 수 있도록 고안된 시스템을 적용해야 한다
- 이는 DevOps가 개발 작업을 요청하는 사업부와 최종 사용자를 지원하는 그룹에 변화를 가져온다는 의미
- 무엇보다도 최종 사용자가 비즈니스에 지속적으로 피드백을 제공하는 것이 중요함
마이크로서비스 아키텍처와 자동화
- DevOps는 기존의 동일한 모놀리식 소프트웨어의 개발을 가속화하는 것뿐 아니라 지속적인 개발 흐름에 더욱 적합한 새로운 종류의 소프트웨어를 개발하는 것과 관련이 있다
- 이런 이유로 DevOps 팀이 마이크로서비스 아키텍처를 사용하여 소프트웨어를 구축하고 API로 이러한 서비스를 함께 연결하는 경우가 많음
// 마이크로서비스: 대규모 소프트웨어 프로젝트를 마이크로 단위의 모듈로 분리하여 low coupling 을 달성하는 소프트웨어 개발 아키텍처. 각 모듈(서비스)은 API를 통해 통신함. - DevOps 팀이 각각의 기능을 더 작은 단위로 구축함으로써 서비스를 보다 신속하게 제공 가능하므로, 이러한 서비스와 API가 관리되는 방식에 중점을 두고 이 모두를 통합할 수 있는 애자일 통합과 같은 전략을 수립해야한다.
- 자동화를 활용한다면 프로세스를 가속화할 수 있으며, 최종적으로는 DevOps 워크로드를 클라우드로 마이그레이션할 수 있음
- 자동화는 DevOps 전략에 있어 매우 중요함. 자동화를 도입할 경우 DevOps에 수반되는 지속적인 코드 변경을 인프라가 견딜 수 있기 때문
DevOps 플랫폼 및 툴
- 프로세스를 지원하는 툴을 선택하는 것은 DevOps 성공의 열쇠
- 운영 팀이 빠른 개발 주기와 속도를 맞추려면 상당히 유연한 플랫폼을 사용하고 개발 팀이 코드를 다루는 방식과 마찬가지로 인프라를 다뤄야함
- 수동 배포는 속도가 느리며 오류가 발생할 가능성이 있음. 자동화를 통해 플랫폼 프로비저닝과 배포를 간소화할 수 있다
- SRE 접근 방식을 사용하면 DevOps 팀의 목표를 달성하기가 더 쉬워짐.
// 사이트 신뢰성 엔지니어링(SRE): 시스템 관리 및 애플리케이션 모니터링과 같은 IT 인프라 작업을 소프트웨어 및 자동화를 사용해 관리 - 컨테이너를 사용하면 개발, 테스트, 프로덕션 환경 사이에서 애플리케이션을 보다 쉽게 이동할 수 있다. 또한 개발자는 컨테이너를 사용하여 애플리케이션과 실행에 필요한 모든 요소 (애플리케이션 파일, 런타임 환경, 종속 라이브러리 및 설정)를 패키징하고 분리할 수 있음
DevOps tool
| 탐색단계: 프로젝트 범위 조사 및 정의 | Jira Product Discovery, MUBAL, miro |
| 계획 | Jira Software, Confluence, slack |
| 빌드 | kubernetes, docker |
| IaC | docker, puppet, Terraform, CHEF |
| 소스 제어 및 공동 작업 코딩 | Bitbucket, GitHub, GitLab |
| 지속적 배포 | Jenkins, aws, Bitbucket, circleci, conarsource |
| 테스트 | STACKHAWK, snyk, XRAY, mabl, MEND, VERACODE |
| 자동화된 배포 | Bitbucket, AWS CodePipeline |
| 인시던트, 변경 및 문제추적 | Jira Software |
| 관찰 | slack, sumo logic, splunk, dynatrace |
| 지속적인 피드백 | slack, Jira Service Management, pendo, GetFeedback |
DevOps 및 쿠버네티스
- DevOps 접근 방식은 Linux® 컨테이너와 긴밀히 연계되며, 개발 팀은 이를 통해 클라우드 네이티브 개발 방식에 필요한 기반 기술을 얻게 됨.
- 컨테이너는 개발, 배포, 통합, 자동화를 위한 통합 환경을 지원함.
- 쿠버네티스는 Linux 컨테이너 운영을 자동화할 수 있는 현대적인 방법. 쿠버네티스를 활용하면 퍼블릭, 프라이빗 또는 하이브리드 클라우드 전반에서 Linux 컨테이너를 실행 중인 클러스터를 손쉽게 효율적으로 관리할 수 있음.
DevOps 및 보안
- DevOps 접근 방식을 최대한 활용하기 위해서는 보안이 애플리케이션의 라이프사이클에서 어떤 역할을 하는지 고려해야 한다.
- 보안 팀의 작업을 통합하기 위해서는 DevOps의 문화적 변화를 기반으로 DevOps 보안을 구축해야 함
- 계획 단계에서부터 핵심 보안에 대해 생각해야 함.
- DevOps 워크플로우의 속도가 저하되지 않도록 일부 보안 기능을 자동화해야 한다
- 보안은 별도의 팀의 독자적인 책임으로 간주되어 개발의 마지막 단계에만 적용되는 것이었다. 하지만 협업을 중시하는 DevOps 프레임워크에서 보안은 초기 단계부터 통합되어 공동의 책임이 됨.
- +) DevOps는 개발과 운영 간의 격차를 해소하여 프로세스를 가속화하고 있지만 비효율적인 보안 계획으로 인해 프로세스 가속화로 인한 이점을 누리지 못할 수 있음.
참고자료들:
https://www.atlassian.com/ko/devops/devops-tools
https://www.ciokorea.com/news/218904
https://brunch.co.kr/@e9c7009de84443b/101
http://www.incodom.kr/%EC%95%A0%EC%9E%90%EC%9D%BC_%EB%B0%A9%EB%B2%95%EB%A1%A0
https://ko.wikipedia.org/wiki/%ED%94%84%EB%A1%9C%EB%B9%84%EC%A0%80%EB%8B%9D
https://azure.microsoft.com/ko-kr/resources/cloud-computing-dictionary/what-is-devops
728x90
