LFCA: DevOps의 기본 개념 배우기 – 21부


DevOps는 꽤 오랫동안 트렌드 주제였으며 기술 전문가와 기업 모두의 관심을 끌었습니다. "초보자로서 DevOps의 개념을 둘러싸고 머리를 감싸는 것은 어려울 수 있으며, 이 주제에서는 이 인터넷 유행어의 기본 개념을 구체화할 것입니다.

먼저 DevOps는 Development와 Operations라는 두 단어의 합성어입니다. 개발 팀(Devs)과 운영(Ops) 간의 협업을 촉진하는 일련의 관행 및 도구입니다. DevOps의 목표는 소프트웨어 개발 수명 주기를 간소화하고 실패율을 최소화하며 배포 빈도를 확장하고 고품질 소프트웨어를 달성하는 것입니다.

오늘날의 현대 IT 환경에서 DevOps를 더 잘 이해하기 위해 DevOps가 도래하기 전에 배포 모델이 어땠는지 살펴보겠습니다.

전통적인 IT 관행

DevOps 이전에는 개발 팀과 QA 엔지니어가 클래식 워터폴 모델을 사용했습니다. 작업 환경은 대부분 사일로로 되어 있었고 애플리케이션 테스트 및 배포는 완전히 격리된 상태에서 이루어졌습니다. 이로 인해 업무 중복, 격차, 피드백 지연 및 프로젝트 완료에 추가 시간이 필요한 기타 비효율성이 발생했습니다. 제한적이고 지연된 피드백은 소프트웨어 품질이 개발의 마지막 단계까지 철저히 감사되지 않았음을 의미합니다.

또한 코드의 수동 배포는 사람의 실수로 인해 발생하므로 응용 프로그램 디버깅에 더 많은 시간이 필요했습니다. 또한 팀마다 작업을 완료하기 위한 다양한 타임라인이 있었고 타임라인이 동기화되지 않아 최종 제품을 구현하는 데 더 많은 지연이 발생하는 경우가 종종 있었습니다.

DevOps의 개념은 Andrew Shafer와 Patrick Debois라는 두 개발자가 2007년에서 2010년 사이에 구상했습니다. 처음부터 소프트웨어 개발 수명 주기의 모든 단계에서 운영 팀과 개발 팀 간의 원활한 협업을 촉진했습니다. 이는 CI(지속적 통합) 및 CD(지속적 전달) 및 기타 빠른 소프트웨어 전달에 기여하는 많은 새로운 개념을 예고했습니다.

DevOps 모델 및 사례

DevOps는 협업과 목표 달성에 대한 올바른 사고 방식을 갖는 것만이 아닙니다. 여기에는 가능한 한 최단 시간 내에 시장에 출시할 수 있는 품질의 소프트웨어를 제공하는 것을 목표로 하는 모범 사례가 포함됩니다. 효율성을 높이고 코드를 빠르게 전달하는 데 도움이 되는 몇 가지 모범 사례를 살펴보겠습니다.

지속적 통합은 개발자가 코드 변경 사항을 하나의 중앙 저장소로 병합하는 소프트웨어 개발 방식입니다. 그런 다음 자동화된 테스트 및 빌드가 코드에서 실행됩니다. 지속적인 통합의 목표는 응용 프로그램 디버깅 속도를 높이고 새 소프트웨어 업데이트를 릴리스하는 데 걸리는 시간을 줄이며 소프트웨어 품질을 개선하는 것입니다.

CD(Continuous Delivery)는 코드 변경 사항이 자동으로 빌드되고 강력한 테스트를 위해 배포되는 또 다른 방법입니다. 나중에 개발자가 버그를 식별하고 수정할 수 있도록 배포된 코드에 대해 자동화된 테스트가 실행됩니다. 일반적으로 코드는 표준 자동화 절차를 통해 코드가 최고 품질 마크를 달성하는 여러 테스트 환경을 점진적으로 거치게 됩니다.

인기 있는 CI/CD 도구에는 Jenkins, Travis CI, Circle CI, Azure DevOps 및 AWS Code 빌드가 있습니다.

지속적인 테스트의 목표는 최종 제품에 나타날 오류를 최소화하기 위해 소프트웨어 개발 수명 주기의 초기 단계에서 버그와 잠재적 위험을 식별하는 것입니다. 코드가 강력한 테스트에 실패하면 일반적으로 평가 및 기능 테스트를 위해 품질 보증 부서로 전달되기 전에 수정을 위해 개발자에게 다시 전송됩니다. "널리 사용되는 연속 테스트 도구에는 Travis 및 Selenium이 있습니다.

예상대로 응용 프로그램과 기본 인프라는 성능 식별 오류 또는 결함을 확인하고 다양한 산업 표준을 준수하는지 확인하기 위해 지속적인 모니터링이 필요합니다. 다음과 같은 다양한 측정항목이 모니터링됩니다.

  1. 메모리 및 CPU 사용률
  2. 디스크 공간 사용량
  3. "
  4. 대역폭 활용
  5. 고객 상호작용
  6. "

    개발자는 애플리케이션에서 생성된 데이터와 로그를 모니터링하고 분석하여 기능이나 구성이 사용자에게 미치는 영향에 대한 통찰력을 쉽게 얻을 수 있습니다. 또한 경고를 구성하면 모든 단계에서 오류 또는 원치 않는 변경을 식별하는 데 도움이 됩니다. 궁극적으로 지속적인 모니터링은 애플리케이션의 고가용성을 보장하고 일이 예상대로 작동하고 있다는 확신을 심어줍니다.

    인기 있는 모니터링 도구에는 Prometheus, Netdata가 포함됩니다.

    IaC로 약칭되는 코드형 인프라는 대화형 구성 도구가 아닌 기계 판독 가능한 구성 파일을 사용하여 가상 서버 및 로드 밸런서와 같은 리소스를 배포 및 관리하는 것으로 설명됩니다. 이는 구성 파일에서 인스턴스의 세부 정보를 정의하고 Terraform과 같은 도구를 활용하여 리소스를 배포함으로써 컴퓨팅 인스턴스를 쉽게 가동할 수 있는 AWS와 같은 클라우드 환경에서 특히 중요합니다.

    "예를 들어 Amazon AWS는 사용자가 명령줄에서 프로그래밍 방식으로 Cloud 플랫폼과 상호 작용할 수 있도록 하는 API를 제공합니다. 이를 통해 수동 프로세스와 여유 시간을 제거하여 리소스를 신속하게 배포할 수 있습니다. 간단히 말해서 IaC는 짧은 시간 내에 더 많은 작업을 수행합니다.

    마이크로서비스 아키텍처는 단일 애플리케이션이 느슨하게 결합된 다양한 소규모 서비스의 통합 또는 융합인 곳입니다. 각 서비스는 독립적으로 실행되며 HTTP 기반 API를 사용하여 나머지 애플리케이션과 통신합니다. 마이크로서비스는 서비스 그룹 또는 단일 서비스로 배포할 수 있습니다.

    마이크로서비스 아키텍처는 기존의 모놀리식 아키텍처와 많이 다릅니다. "기존 아키텍처에서 애플리케이션은 단일 계층이며 코드 및 UI를 포함한 모든 구성 요소가 단일 프로그램에 번들로 제공됩니다.

    마이크로서비스는 리소스의 독립적인 배포 및 관리를 용이하게 합니다. 또한 단일 장애 지점을 방지하여 고가용성을 보장합니다. 단일 응용 프로그램이 충돌하면 나머지는 계속 실행됩니다.

    DevOps 모델의 이점

    DevOps 모범 사례를 살펴보았으므로 이제 DevOps 모델 채택의 이점에 집중하겠습니다.

    개발 및 운영 팀 간의 협업은 공동 책임으로 전환되어 궁극적으로 생산성을 높이고 팀 참여를 촉진합니다.

    또한 협업을 통해 팀은 최종 단계에 도달하기 전에 모든 단계에서 코드를 쉽게 디버그할 수 있습니다. 이를 통해 고품질의 시장 준비 소프트웨어를 얻을 수 있습니다.

    "DevOps가 제공하는 자동화 도구(예: Ansible, Chef, Puppet) 및 고급 CI(지속적 통합) 덕분에 애플리케이션 배포가 더욱 간소화되고 훨씬 빨라졌습니다.

    제품 지식이 여러 부서에 분산되어 있기 때문에 제품에 대한 명확한 목표와 비전이 있으며 개발의 모든 단계에서 더 나은 의사 결정을 내릴 수 있습니다.

    개발팀과 운영팀이 영원히 별개로 작업해야 한다는 뿌리 깊은 믿음은 오래 전부터 구식이며 결함이 있습니다. 일부 산업에서는 사일로화된 철학이 여전히 살아 있을 수 있지만 이는 그 과정에서 눈에 띄는 비효율성을 초래했습니다.

    DevOps는 개발 팀과 운영 팀을 통합하고 사일로에서 작업하는 기존 방식에서 협력 작업으로의 문화적 전환을 촉진하여 코드 오류를 줄이고 소프트웨어 품질을 개선하며 제공 시간을 단축하고 전반적인 생산성을 향상시키려고 합니다. 궁극적으로 최종 사용자는 적시에 고품질 제품을 얻게 됩니다.