🥇초보자를 위한 DevOps 가이드

DevOps의 중요성은 무엇이며, IT 전문가에게 DevOps는 무엇을 의미합니까? 방법, 프레임워크 및 도구에 대한 설명입니다.

DevOps라는 용어가 IT 세계에 자리잡은 이후로 많은 일이 일어났습니다. 대부분의 생태계 오픈 소스에서는 그것이 시작된 이유와 그것이 IT 경력에 어떤 의미인지 다시 생각해 보는 것이 중요합니다.

데브옵스란?

단일한 정의는 없지만 DevOps는 개발 팀과 운영 팀 간의 협업을 통해 반복 및 자동화 기능을 통해 코드를 프로덕션 환경에 더 빠르게 배포할 수 있는 기술 프레임워크라고 믿습니다. 우리는 이 글의 나머지 부분을 이 주장을 풀어나가는 데 할애할 것입니다.

데브옵스(DevOps)는 개발(Development)과 운영(Operations)을 합친 말이다. DevOps는 애플리케이션 및 서비스 제공 속도를 높이는 데 도움이 됩니다. 이를 통해 조직은 고객에게 효과적으로 서비스를 제공하고 시장에서 경쟁력을 높일 수 있습니다. 간단히 말해서 DevOps는 보다 효과적인 커뮤니케이션과 협업을 통해 개발과 IT 운영을 조정하는 것입니다.

DevOps에는 개발, 운영 및 비즈니스 팀 간의 협업이 중요하다고 간주되는 문화가 포함됩니다. 조직의 DevOps는 지속적으로 고객에게도 혜택을 주기 때문에 이는 단지 도구에 관한 것이 아닙니다. 도구는 사람, 프로세스와 함께 핵심 요소 중 하나입니다. DevOps는 조직이 가능한 최단 시간에 고품질 솔루션을 제공할 수 있는 능력을 향상시킵니다. DevOps는 또한 빌드부터 배포, 애플리케이션 또는 제품까지 모든 프로세스를 자동화합니다.

DevOps 토론은 개발자, 생계를 위해 소프트웨어를 작성하는 사람, 해당 소프트웨어를 유지 관리하는 운영자 간의 관계에 중점을 둡니다.

개발팀의 과제

개발자는 조직의 문제를 해결하기 위해 새로운 접근 방식과 기술을 구현하는 데 열정적이고 열정적인 경향이 있습니다. 그러나 그들은 또한 특정한 문제에 직면합니다:

경쟁이 치열한 시장에서는 제품을 제 시간에 맞춰 납품해야 한다는 압박감이 큽니다.
그들은 프로덕션에 준비된 코드를 관리하고 새로운 기능을 도입하는 일을 담당해야 합니다.
릴리스 주기가 길 수 있으므로 개발 팀은 애플리케이션을 구현하기 전에 몇 가지 가정을 해야 합니다. 이 시나리오에서는 프로덕션 또는 테스트 환경에 배포하는 동안 발생하는 문제를 해결하는 데 더 많은 시간이 필요합니다.

운영팀이 직면한 과제

운영팀은 역사적으로 IT 서비스의 안정성과 신뢰성에 중점을 두었습니다. 이것이 바로 운영팀이 리소스, 기술 또는 접근 방식의 변화를 통해 안정성을 추구하는 이유입니다. 이들의 임무는 다음과 같습니다:

수요 증가에 따라 리소스 할당을 관리합니다.
프로덕션 환경에서 사용하는 데 필요한 디자인 또는 사용자 정의 변경을 처리합니다.
애플리케이션 자체 배포 후 프로덕션 문제를 진단하고 해결합니다.

DevOps가 개발 및 운영 문제를 해결하는 방법

기업에서는 한 번에 많은 수의 앱 기능을 출시하는 대신 일련의 릴리스 반복을 통해 고객에게 소수의 기능을 출시할 수 있는지 확인하려고 노력하고 있습니다. 이 접근 방식에는 더 나은 소프트웨어 품질, 더 빠른 고객 피드백 등과 같은 여러 가지 장점이 있습니다. 이는 결과적으로 높은 고객 만족도를 보장합니다. 이러한 목표를 달성하기 위해 기업은 다음을 수행해야 합니다.

새 릴리스 출시 시 실패율 감소
배포 빈도 증가
새 애플리케이션이 출시되는 경우 평균 복구 시간을 단축합니다.
수정 시간 단축

DevOps는 이러한 모든 작업을 수행하고 중단 없는 제공을 보장합니다. 조직에서는 DevOps를 사용하여 불과 몇 년 전에는 상상할 수 없었던 수준의 생산성을 달성하고 있습니다. 하루에 수십, 수백, 심지어 수천 건의 배포를 수행하는 동시에 세계적 수준의 안정성, 안정성 및 보안을 제공합니다. (로트 크기에 대해 자세히 알아보기 및 소프트웨어 제공에 미치는 영향).

DevOps는 다음을 포함하여 과거 방법론으로 인해 발생한 다양한 문제를 해결하려고 시도합니다.

개발팀과 운영팀 간의 작업 격리
테스트와 배포는 설계 및 빌드 후에 발생하는 별도의 단계이며 빌드 주기보다 더 많은 시간이 필요합니다.
핵심 비즈니스 서비스 구축에 집중하는 대신 테스트, 배포, 설계에 과도한 시간을 소비함
프로덕션 오류로 이어지는 수동 코드 배포
개발 및 운영 팀 일정의 차이로 인해 추가 지연 발생

DevOps, Agile 및 기존 IT 간의 대결

DevOps는 다른 IT 관행, 특히 Agile 및 Waterfall IT와 관련하여 자주 논의됩니다.

Agile은 소프트웨어 생산을 위한 일련의 원칙, 가치 및 관행입니다. 예를 들어 소프트웨어로 전환하려는 아이디어가 있다면 Agile 원칙과 가치를 사용할 수 있습니다. 하지만 이 소프트웨어는 개발 또는 테스트 환경에서만 실행할 수 있습니다. 소프트웨어를 신속하고 반복적으로 프로덕션 단계로 이동하려면 간단하고 안전한 방법이 필요하며, 그 방법은 DevOps 도구 및 기술을 통해서입니다. Agile 소프트웨어 개발은 개발 프로세스에 중점을 두고 있으며 DevOps는 가장 안전하고 안정적인 방식으로 개발 및 배포를 담당합니다.

전통적인 폭포수 모델을 DevOps와 비교하는 것은 DevOps가 제공하는 이점을 이해하는 좋은 방법입니다. 다음 예에서는 애플리케이션이 85주 안에 출시되고, 개발이 XNUMX% 완료되고, 애플리케이션이 출시되고, 코드를 배송하기 위한 서버 구매 프로세스가 막 시작되었다고 가정합니다.

전통적인 프로세스
DevOps의 프로세스

새로운 서버를 주문한 후 개발팀은 테스트에 착수합니다. 태스크 포스는 기업이 인프라를 배포하는 데 필요한 광범위한 문서를 작업합니다.
새 서버를 주문하면 개발 팀과 운영 팀이 새 서버를 설치하기 위한 프로세스와 서류 작업을 함께 진행합니다. 이를 통해 인프라 요구 사항을 더 잘 이해할 수 있습니다.

장애 조치, 중복성, 데이터 센터 위치 및 스토리지 요구 사항에 대한 정보는 심층적인 도메인 지식을 갖춘 개발 팀의 입력이 없기 때문에 잘못 표시됩니다.
장애 조치, 중복성, 재해 복구, 데이터 센터 위치 및 스토리지 요구 사항에 대한 세부 정보는 개발 팀의 입력으로 인해 알려져 있고 정확합니다.

운영팀은 개발팀의 진행 상황을 전혀 모릅니다. 그녀는 또한 자신의 아이디어를 바탕으로 모니터링 계획을 개발합니다.

운영팀은 개발팀의 진행 상황을 완전히 알고 있습니다. 또한 그녀는 개발 팀과 상호 작용하며 함께 협력하여 IT 및 비즈니스 요구 사항을 충족하는 모니터링 계획을 개발합니다. 또한 APM(애플리케이션 성능 모니터링) 도구도 사용합니다.

애플리케이션이 시작되기 전에 수행된 부하 테스트로 인해 애플리케이션이 충돌하여 실행이 지연됩니다.
애플리케이션을 실행하기 전에 부하 테스트를 수행하면 성능이 저하됩니다. 개발팀은 병목 현상을 신속하게 해결하고 애플리케이션이 제 시간에 시작됩니다.

DevOps 수명주기

DevOps에는 일반적으로 허용되는 특정 관행의 채택이 포함됩니다.

지속적인 계획

지속적인 계획은 비즈니스 또는 비전의 가치를 테스트하고, 지속적으로 적응하고, 진행 상황을 측정하고, 고객 요구로부터 배우고, 민첩성을 수용하기 위해 필요에 따라 방향을 변경하고, 비즈니스 계획을 재창조하는 데 필요한 리소스와 결과를 식별함으로써 소규모로 시작하는 린(Lean) 원칙에 의존합니다.

공동개발

협업 개발 프로세스를 통해 비즈니스, 개발 팀 및 테스트 팀은 다양한 시간대에 분산되어 지속적으로 고품질 소프트웨어를 제공할 수 있습니다. 여기에는 다중 플랫폼 개발, 교차 언어 프로그래밍 지원, 사용자 스토리 생성, 아이디어 개발 및 수명주기 관리가 포함됩니다. 협업 개발에는 빈번한 코드 통합과 자동화된 빌드를 촉진하는 지속적인 통합 프로세스와 실행이 포함됩니다. 애플리케이션에 코드를 자주 배포하면 통합 문제가 라이프사이클 초기(수정하기 쉬운 시기)에 식별되고, 프로젝트가 지속적이고 가시적인 진행 상황을 보여주므로 지속적인 피드백을 통해 전체 통합 노력이 줄어듭니다.

지속적인 테스트

지속적인 테스트는 개발팀이 속도와 품질의 균형을 맞추는 데 도움을 주어 테스트 비용을 줄여줍니다. 또한 서비스 가상화를 통해 테스트 병목 현상을 제거하고 시스템 변경에 따라 쉽게 공유, 배포 및 업데이트할 수 있는 가상화된 테스트 환경을 쉽게 만들 수 있습니다. 이러한 기능을 통해 테스트 환경 프로비저닝 및 유지 관리 비용이 절감되고 테스트 주기 시간이 단축되므로 통합 테스트를 수명주기 초기에 수행할 수 있습니다.

지속적인 릴리스 및 배포

이러한 기술은 지속적인 릴리스 및 배포라는 핵심 관행을 제공합니다. 이는 주요 프로세스를 자동화하는 지속적인 파이프라인을 통해 보장됩니다. 버튼 하나만 누르면 배포가 가능해 수동 단계, 리소스 대기 시간, 재작업이 줄어들고 결과적으로 더 많은 릴리스가 발생하고 오류가 줄어들며 완전한 투명성이 확보됩니다.

자동화는 안정적이고 신뢰할 수 있는 소프트웨어 릴리스를 보장하는 데 핵심적인 역할을 합니다. 가장 큰 과제 중 하나는 빌드, 회귀, 배포, 인프라 생성과 같은 수동 프로세스를 자동화하는 것입니다. 이를 위해서는 소스 코드 버전 제어가 필요합니다. 테스트 및 배포 시나리오 인프라 및 애플리케이션 구성 데이터 그리고 애플리케이션이 의존하는 라이브러리와 패키지. 또 다른 중요한 요소는 모든 환경의 상태를 쿼리하는 기능입니다.

지속적인 모니터링

지속적인 모니터링은 개발 팀이 프로덕션에 배포하기 전에 프로덕션 환경에서 애플리케이션의 가용성과 성능을 이해하는 데 도움이 되는 엔터프라이즈급 보고를 제공합니다. 지속적인 모니터링을 통해 제공되는 조기 피드백은 오류 비용을 줄이고 프로젝트를 올바른 방향으로 조정하는 데 중요합니다. 이 관행에는 일반적으로 애플리케이션 성능과 관련된 지표를 나타내는 모니터링 도구가 포함되는 경우가 많습니다.

지속적인 피드백과 최적화

지속적인 피드백과 최적화를 통해 고객 흐름을 시각적으로 표현하고 문제 영역을 정확히 찾아냅니다. 판매 전 및 판매 후 단계 모두에 피드백을 포함시켜 가치를 극대화하고 더 많은 거래가 성공적으로 완료되도록 할 수 있습니다. 이 모든 기능을 통해 고객 행동과 비즈니스 영향에 영향을 미치는 고객 문제의 근본 원인을 즉시 시각화할 수 있습니다.

DevOps의 이점

DevOps는 개발자와 운영진이 팀으로 협력하여 공통 목표를 달성할 수 있는 환경을 조성하는 데 도움이 될 수 있습니다. 이 프로세스에서 중요한 이정표는 CI/CD(지속적 통합 및 지속적 전달) 구현입니다. 이러한 기술을 통해 팀은 더 적은 버그로 소프트웨어를 더 빠르게 시장에 출시할 수 있습니다.

DevOps의 중요한 이점은 다음과 같습니다.

예측 가능성: DevOps는 새 릴리스에 대해 상당히 낮은 실패율을 제공합니다.
유지 관리성: DevOps를 사용하면 새 릴리스가 실패하거나 애플리케이션이 다운되는 경우 쉽게 복구할 수 있습니다.
재현성: 빌드 또는 코드의 버전 제어를 통해 필요에 따라 이전 버전을 복원할 수 있습니다.
더 높은 품질: 인프라 문제를 해결하면 애플리케이션 개발 품질이 향상됩니다.
출시 시간: 소프트웨어 제공을 최적화하면 출시 시간이 50% 단축됩니다.
위험 감소: 소프트웨어 수명주기에 보안을 구현하면 수명주기 전반에 걸쳐 결함 수가 줄어듭니다.
비용 효율성: 소프트웨어 개발에서 비용 효율성을 추구하는 것은 고위 경영진에게 매력적입니다.
안정성: 소프트웨어 시스템이 더욱 안정적이고 안전하며 변경 사항을 감사할 수 있습니다.
대규모 코드베이스를 관리 가능한 조각으로 분할: DevOps는 대규모 코드베이스를 관리 가능한 작은 조각으로 분할할 수 있는 민첩한 개발 방법을 기반으로 합니다.

DevOps 원칙

DevOps의 채택으로 인해 여러 가지 원칙이 발전해 왔으며 계속 발전하고 있습니다. 대부분의 솔루션 제공업체는 다양한 기술을 자체적으로 수정하여 개발했습니다. 이러한 모든 원칙은 DevOps에 대한 전체적인 접근 방식을 기반으로 하며 모든 규모의 조직에서 이를 사용할 수 있습니다.

프로덕션과 유사한 환경에서 개발 및 테스트

개발 및 품질 보증(QA) 팀이 프로덕션 시스템처럼 작동하는 시스템을 개발하고 테스트하여 애플리케이션이 배포 준비가 되기 훨씬 전에 애플리케이션이 어떻게 작동하고 수행되는지 확인할 수 있도록 하는 것이 아이디어입니다.

세 가지 주요 잠재적 문제를 해결하려면 애플리케이션을 라이프사이클에서 가능한 한 빨리 프로덕션 시스템에 연결해야 합니다. 첫째, 실제 환경에 가까운 환경에서 애플리케이션을 테스트할 수 있다. 둘째, 애플리케이션 제공 프로세스를 미리 테스트하고 검증할 수 있습니다. 셋째, 이를 통해 운영 팀은 애플리케이션이 배포될 때 환경이 어떻게 작동할지 라이프사이클 초기에 테스트할 수 있으므로 고도로 맞춤화된 애플리케이션 중심 환경을 구축할 수 있습니다.

반복 가능하고 안정적인 프로세스로 배포

이 원칙을 통해 개발 및 운영 팀은 전체 소프트웨어 수명주기 동안 민첩한 소프트웨어 개발 프로세스를 지원할 수 있습니다. 자동화는 반복적이고 안정적이며 반복 가능한 프로세스를 만드는 데 중요합니다. 따라서 조직은 지속적이고 자동화된 배포 및 테스트를 가능하게 하는 전달 파이프라인을 만들어야 합니다. 또한 빈번한 배포를 통해 팀은 배포 프로세스를 테스트할 수 있으므로 라이브 릴리스 중 배포 실패 위험을 줄일 수 있습니다.

작업 품질 모니터링 및 확인

조직은 측정항목과 핵심성과지표(KPI)를 실시간으로 캡처하는 도구를 보유하고 있기 때문에 프로덕션 환경에서 애플리케이션을 모니터링하는 데 능숙합니다. 이 원칙은 모니터링을 라이프사이클 초기에 이동시켜 자동화된 테스트가 프로세스 초기에 애플리케이션의 기능적 및 비기능적 속성을 모니터링하도록 보장합니다. 애플리케이션을 테스트하고 배포할 때마다 품질 지표를 검사하고 분석해야 합니다. 모니터링 도구는 생산 중에 발생할 수 있는 운영 및 품질 문제에 대한 조기 경고를 제공합니다. 이러한 지표는 모든 이해관계자가 접근하고 이해할 수 있는 형식으로 수집되어야 합니다.

피드백 루프 개선

DevOps 프로세스의 목표 중 하나는 조직이 더 빠르게 대응하고 변경을 수행할 수 있도록 하는 것입니다. 소프트웨어 제공에서 이 목표를 달성하려면 조직이 조기에 피드백을 받은 다음 취해진 각 조치로부터 신속하게 학습해야 합니다. 이 원칙에 따르면 조직은 이해관계자가 피드백 방식으로 액세스하고 상호 작용할 수 있는 커뮤니케이션 채널을 만들어야 합니다. 프로젝트 계획이나 우선순위를 조정하여 개발을 수행할 수 있습니다. 제조업은 생산 환경을 개선함으로써 행동할 수 있습니다.

데브

계획: Kanboard, Wekan 및 기타 Trello 대안; GitLab, Tuleap, Redmine 및 기타 JIRA 대안; Mattermost, Roit.im, IRC 및 기타 Slack 대안.
코드 작성: 힘내, 게릿, 버그질라; CI/CD용 Jenkins 및 기타 오픈 소스 도구
빌드 : 아파치 메이븐, 그래들, 아파치 앤트, 패커
테스트 : JUnit, 오이, 셀레늄, Apache JMeter

작전

릴리스, 배포, 운영: Kubernetes, Nomad, Jenkins, Zuul, Spinnaker, Ansible, Apache ZooKeeper, etcd, Netflix Archaius, Terraform
모니터링: Grafana, Prometheus, Nagios, InfluxDB, Fluentd 및 이 가이드에서 다루는 기타 항목

(*운영 도구에는 운영 팀이 사용하는 순서대로 번호가 매겨져 있지만 해당 도구의 구성은 릴리스 및 배포 도구의 수명 주기 단계와 겹칩니다. 쉽게 읽을 수 있도록 번호 매기기가 제거되었습니다.)

결론적으로

DevOps는 개발자와 운영을 하나의 단위로 통합하는 것을 목표로 하는 점점 더 인기 있는 방법론입니다. 이는 독특하고 기존 IT 운영과 다르며 Agile을 보완합니다(하지만 유연성은 떨어짐).

SkillFactory에서 유료 온라인 강좌를 수강하여 원하는 직업을 처음부터 구하거나 기술 및 급여 측면에서 레벨 업하는 방법에 대한 자세한 내용을 알아보세요.

DevOps 과정 (12개월)

더 많은 강좌

유용한

출처 : habr.com

초보자를 위한 DevOps 가이드